Claude Codeのセキュリティ監査スキルで脆弱性発見はどれだけ変わる？security-auditを徹底検証

security-auditの有無で発見数はどれだけ変わるのか？

頼み方を含めて比べると、差は9件中で0〜1件から8〜9件まで開きました。ただし、スキルの有無だけで決まるわけではありません。入れただけの場合は、スキルなしで徹底的にと頼んだ場合と同程度で、差が明確になったのは全工程を指定したときです。

読み取れることは3つあります。1つ目は、普通の依頼はこの規模のコードにはほぼ歯が立たなかったことです。3回とも危険な語の検索を軸に調べ、指摘の中心は既定の秘密鍵やpickleといった設定や書き方の問題でした。2つ目は、「徹底的に」の一言とサブエージェントの許可だけで3〜7件まで増えたことです。スキルを入れるより先に試す価値があります。3つ目は、全工程には明確な上積みがある一方で、費用は平均で約12倍になることです。1件あたりでは丁寧な依頼の約0.44ドルに対し、全工程は約3.5ドルでした。

複数回の実行も効きます。丁寧な依頼は3回を合わせると7件（計7.05ドル）で、全工程の1回の費用を大きく下回ります。全工程3回を合わせると9件すべてに届きました。

どのような条件で比べたのか？

答えが分かっている実在のアプリを使い、依頼文だけを変えて同じモデルで3回ずつ実行しました。対象は文書管理のオープンソースアプリ paperless-ngx の v2.20.3（2025年12月18日の版）で、テストと移行を除くPythonは約2万8千行あります。

答えには、この版より後の v2.20.4〜v2.20.15 で修正された公開アドバイザリ9件をすべて使いました。すでに修正済みで、開発元が内容を公開しているものです。古い版をあえて監査したのは比較のためで、このアプリの品質を評価する意図はありません。利用中の方は最新版への更新をおすすめします。

どの脆弱性で差がついたのか？

差がついたのは、ソースを横断して読まないと気づきにくい権限確認の抜けです。全工程は7件を3回とも見つけ、グローバル検索の権限漏れは全工程だけが見つけました。一方、共有リンクのように、入れただけのスキルが3回とも見つけた項目もあります。

この差は、読んだ量で説明できそうです。権限確認の抜けは「書かれていないこと」なので、危険な語を検索しても見つかりません。普通の依頼は検索と部分的な読み取りで40秒前後で終わりました。Readで開いたファイルの数は、徹底的にと頼むと36〜68、全工程では150〜269でした。もちろん相関であって、読む量だけが原因と断定はできません。

なぜ入れただけでは全工程が動かないのか？

スキルは手順書であって、実行を強制する仕組みではないからです。今回、普通の依頼で起動したスキルは3回とも自らquick相当の手順を選び、そのうち1回はエージェントを1つも使わず、手順を実行していないと自ら報告しました。

Cloudflareの開発者向けアカウントが11月5日に紹介したこの6段階は、全工程を指定すれば実際に動きました。3回とも standard で完了し、93〜129のエージェントが動いています。依頼文では、工程の省略を明示的に禁じるのがポイントです。なお、公開されているのはスキルで、同社のブログにある社内ハーネスそのものではありません。ブログの大規模な数字は、スキル単体の性能を示すものではないので注意してください。

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit --agent claude-code

このリポジトリは当社が開発したアプリです。
セキュリティ監査をしてください。修正はしないでください。
security-audit スキルの standard プロファイルの全工程を、
手順を省略せずに実行してください。
出力先は ~/audits/portal にしてください。

実行後は、報告書の冒頭と run-metadata.json のプロファイル、完了状態、エージェント数を確認してください。導入時の注意は次のとおりです。

小さなアプリで差が出ないのはなぜか？

小さなコードなら、普通の依頼でも全体を読み切れてしまうからです。お手本どおりの脆弱性を仕込んだ架空のアプリでは、スキルの有無で検出数にほぼ差がありませんでした。自社の小さなツールなら、まず普通の依頼で十分な可能性があります。

この記事の初版は11ファイルのアプリの結果だけを載せ、スキルは「見つける数を増やしませんでした」と書いていました。小さなアプリの結果としては正しいものの、実在の規模には当てはまらなかったので、今回の検証に差し替えました。誰もが満点を取るテストでは、道具の差は測れません。脆弱性診断の記事で扱った比較も、この点を踏まえて読んでください。

監査結果はどこまで信じてよいのか？

見つかった候補は事実の一覧ではなく、人が確かめる順番の案として読むのが安全です。全工程の3回でも判定は大きく揺れ、対象のコードは一度も実行していません。発見数が増えた分、確認の仕事も増えます。

「1回の実行で見つかるのは、複数回の実行で捕まえられるバグのおよそ半分だけです。」

"a single run finds only about half the bugs you'd catch across multiple runs."

Cloudflare — Build your own vulnerability harness

Cloudflareは社内の実験について、見逃しの割合は主張していません。今回の結果でも、9件すべてを見つけたのは全12回の実行のうち1回だけで、9件はあくまで公開された分です。全部で何件あるのかは、誰にも分かりません。

Claude Codeでどう使い分けるべきか？

当研究所の見解では、対象の規模と失敗したときの影響で決めるのが現実的です。全工程を常に動かす必要はなく、まず徹底的にと頼み、重要な節目で全工程に切り替えるのが費用に見合います。

全工程の価値は件数だけではありません。調べた範囲を coverage-ledger.json に記録し、検証役による判定が残るので、前回の続きから再監査することもできる設計です（再監査は今回未検証）。一方で利用枠の消費は大きく、並列で動かした初回は定額プランの5時間枠の上限で止まって取り直しました。大きなリポジトリでは、まず範囲を絞るか「エージェントは最大30回まで」のように予算を指定してください。予算はエージェント数の指定で、金額の上限ではありません。

士業や中小企業の社内ツールなら、公開や大きな改修の前に1回監査し、needs_validation の項目を開発担当者や委託先と確認する流れが無理のない形です。最終的な優先順位は、誰がコードに触れるか、本番の鍵は別かといった事情を知る人にしか決められません。基本の設定はClaude Codeの必須セキュリティ設定、スキル自体の考え方はCLAUDE.mdとskillsの使い分けで解説しています。

まとめ