エージェントが脆弱性を発見するとき

Anthropicの研究者Nicholas Carliniは、Claude CodeをLinuxカーネルのソースコードに向け、脆弱性を探すよう指示しました。セットアップは10行のbashスクリプトとASANでインストルメントされたビルドを含むDockerコンテナのみ。ソースファイルを順にループし、モデルにバグを探させ、次のファイルへ進むという流れです。¹³

Michael Lynchがこの講演について詳述した記事によると、²結果は衝撃的でした。NFSv4のLOCKリプレイキャッシュにリモートから悪用可能なヒープバッファオーバーフローが見つかったのです。この脆弱性は2003年3月から存在していました——Git自体よりも古いものです。2つのNFSクライアントが協調すれば、112バイトのバッファに1,024バイトのロックオーナーIDを溢れさせることで、カーネルの機密メモリを読み取ることができます。Carliniは同じスキャンでさらに少なくとも4つのカーネル脆弱性を発見しました。同じ手法をMozillaにも適用し、122件のクラッシュ入力を送信、うち22件がCVEとして認定されています。³まだ検証・報告する時間がないクラッシュが「数百件」あるとのことです。²

これらはメンテナーに報告された確認済みの脆弱性であり、Opus 4.6を使用したエージェントが発見したものです——実務者がコードレビュー、リファクタリング、機能開発に日常的に使っているのと同じモデルクラスです。Carliniは2026年4月の[un]prompted AIセキュリティカンファレンスでこの調査結果を発表しました。¹

要約

Carliniの手法はミニマルなものでした。ソースファイルを繰り返し処理し、各ファイルの脆弱性を見つけるようClaudeにプロンプトを与え、ASANアサーションでヒットを検証する。Opus 4.6はOpus 4.1（8ヶ月前のモデル）やSonnet 4.5（6ヶ月前のモデル）よりも大幅に多くの脆弱性を発見しており、最近能力の閾値を超えたことを示唆しています。²ボトルネックは今やAIの発見能力ではなく、人間による検証です。これはセキュリティフック構築、コードレビュー実施、エージェント支援型監査の考え方に直接的な影響を及ぼします。

重要ポイント

• セキュリティエンジニア向け： この能力は現実のものであり、急速に向上しています。エージェント支援型コードレビューを実施しているなら、PreToolUseセキュリティフックはこれまで以上に重要です——Claudeをブロックするためではなく、発見した内容に対して何ができるかを制御するためです。
• ハーネス構築者向け： 検証のボトルネック（「まだ検証できていないクラッシュが数百件」）はハーネスの問題です。自動トリアージ、重複排除、深刻度分類が次のインフラ層となります。
• その他すべての方へ： 446倍のパフォーマンス低下を引き起こすのと同じモデルが、23年間の人間のレビューで見逃されたバグを発見します。両方が同時に真実なのです。

手法

Carliniのアプローチには、カスタムセキュリティフレームワークもファインチューニングされたモデルも専門的なプロンプトも不要でした。本人は「10行のbashスクリプトとDockerコンテナ」と説明しています。³

1. ASAN（AddressSanitizer）インストルメンテーション付きでターゲットをコンパイル
2. ソースファイルを順に処理し、モデルにセキュリティ関連度を評価させる
3. 関連度の高いファイルに対して、CTF（Capture The Flag）形式のフレーミングでClaude Codeにプロンプトを与える
4. ターゲットごとに複数パスを実行（コードベースに応じて5〜20回）
5. 開示前に自動批評エージェントで発見内容を検証

CTF形式のフレーミングが重要です。モデルに「このコードにはバグがある」と伝えると、「このコードに問題がないか確認して」とは異なるモードが活性化されます。日常的な開発でも同じパターンに気づいている開発者は多いでしょう——Claudeは、問題が存在するかもしれないと尋ねるよりも、問題が存在すると伝えた方がより多くの問題を発見します。²

このスキャンのコストは人月ではなく、APIトークン単位で測定されます。Carliniはコモディティ化されたエージェントCLIを使い、Linuxカーネルの確認済み脆弱性5件とFirefoxのCVE 22件を発見しました。³ユニットテストを書いたりインポートを整理したりするのと同じツールです。

能力の閾値

最も印象的な発見はモデル世代間の差です。Carliniは古いモデルでの再現を試みました。²

• Opus 4.6（講演の約2ヶ月前にリリース）：ヒープオーバーフローおよび複数の追加脆弱性を発見
• Opus 4.1（8ヶ月前）：ごくわずかしか発見できず
• Sonnet 4.5（6ヶ月前）：ごくわずかしか発見できず

モデル世代間で何らかの閾値を超えたのです。複雑なコードベースをコンテキストに保持し、関数境界を越えたデータフローを推論し、微妙な仕様の不一致を特定する能力は、徐々に向上したのではなく、ある時点で出現したように見えます。

Carliniは率直にこう述べています。「私はこれまでの人生でこのような脆弱性を一度も見つけたことがありません。これは非常に、非常に、非常に難しいことです。これらの言語モデルを使えば、たくさん見つかるのです。」²

パラドックス

パフォーマンス低下を引き起こすのと同じエージェントアーキテクチャ——118の関数で3倍から446倍のスローダウン——が、数十年にわたる専門家の人間レビューで見逃されたセキュリティ脆弱性も発見します。これらは同じ能力プロファイルの補完的な側面です。脆弱性研究は本質的に、既知のクラス（バッファオーバーフロー、Use-After-Free、整数の符号問題）に対するパターンマッチングであり、これはLLMの強みです。⁴一方、パフォーマンス最適化にはその逆が求められます。特定の実行コンテキスト、キャッシュの振る舞い、アルゴリズムの計算量について推論する能力です。モデルは数百万行のコードからバッファオーバーフローを認識できますが、あなたのアクセスパターンにおいてハッシュマップがソート済み配列より遅いかどうかは判断できません。それに応じてハーネスを設計しましょう——発見をフラグするセキュリティフック、コミット前に計測するパフォーマンスフック。

検証のボトルネック

Carliniの最も示唆に富む告白はこれです。「Linuxカーネルにバグがあまりにも多くあり、まだ検証していないため報告できていません。」²

ボトルネックは発見からトリアージへと移行しました。潜在的な脆弱性の発見は、それが本物であると確認するよりも安価になったのです。これはセキュリティチームにとって新たなインフラ課題を生み出します。

発見は自動化されています。エージェントは数時間でコードベースをスキャンできます。

検証は手動のままです。潜在的な脆弱性ごとに概念実証、影響評価、責任ある開示プロセスが必要となります。

トリアージがギャップです。エージェントが生成した数百の発見を、本物の脆弱性、誤検知、低深刻度のノイズに分類する作業には、まだ良いツールがありません。

これはエージェント支援型コードレビューで見られるのと同じパターンです。エージェントは人間が評価できる速度よりも速く生の出力を生成します。価値は生成にあるのではなく、出力を処理・フィルタリング・ルーティングするインフラにあるのです。

ハーネス構築者にとって、次に価値の高いフックはセキュリティスキャナーではありません。セキュリティトリアージシステムです。重複排除、深刻度分類、誤検知フィルタリング、概念実証の自動生成。エージェント出力をゲートするガバナンスフックは、スキャン能力そのものよりも重要です。

実務者への示唆

本番コードベースでClaude Codeを実行しているなら、すでに本物の脆弱性を発見できるシステムを運用していることになります。問題は能力が存在するかどうかではなく、エージェントが発見したものに対してハーネスが適切に対処できる設計になっているかどうかです。

3つの実践的なアクション：

レビューパイプラインにセキュリティスキャンを追加する。 Write/Editに対するPostToolUseフックで、変更されたファイルに対してターゲットを絞ったセキュリティスキャンをトリガーできます。フックはstdinからファイルパスを読み取ります（Claude CodeはイベントJSONをstdin経由でフックに渡します）：

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking — runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

これは出発点であり、本番対応ではありません。重複排除、深刻度フィルタリング、レート制限を追加する必要があるでしょう。しかし、コアパターンはCarliniの手法と一致しています。ターゲットを絞ったプロンプトでファイルをループする仕組みです。³

トリアージインフラを構築する。 深刻度分類のない生の脆弱性発見はノイズにすぎません。エージェントが1回のスキャンで50件の発見を生成するなら、人間がリストを見る前に自動的な重複排除と優先度スコアリングが必要です。これはハーネスの問題であり、モデルの問題ではありません。

パラドックスを受け入れる。 パフォーマンスのガードレールが必要な同じモデルが、セキュリティのパターンマッチングには本当に優れています。強みを活かし、弱みを補うようにハーネスを設計しましょう。スキャンするセキュリティフック。計測するパフォーマンスフック。検証するクオリティフック。それぞれが他のフックの見逃しをカバーします。

23年間潜んでいたLinuxの脆弱性は隠れていたわけではありません。何千人ものエンジニアが読んだファイルの中に、明白に存在していました。モデルがそれを発見できたのは、大規模なパターンマッチングこそがこれらのシステムの本質だからです。教訓は、エージェントが人間よりセキュリティに優れているということではありません。エージェントは異なる表面をカバーするということです。そして、両者を統合するハーネスこそが、その組み合わせを信頼できるものにするのです。

出典

よくある質問

Claude CodeでCarliniのアプローチを再現できますか？

手法はポッドキャストのインタビューで文書化されています。³コアループは、ASANでコンパイルし、ソースファイルを順に処理し、CTF形式のフレーミングでClaudeにプロンプトを与え、ヒットを検証するというものです。CarliniはOpus 4.6が古いモデルよりも大幅に多くの脆弱性を発見したと報告しており、他のモデル世代での結果は異なる可能性があります。

AIエージェントは人間よりセキュリティバグの発見に優れているということですか？

いいえ。エージェントは異なる表面をカバーするということです。エージェントは大規模なコードベース全体にわたる既知の脆弱性クラスに対するパターンマッチングに優れています。人間は新しい攻撃ベクトル、ビジネスロジックの欠陥、コンテキストに依存するセキュリティ特性の理解に優れています。両者の組み合わせはどちらか単独よりも強力です。

攻撃者がこの能力を使うことを心配すべきですか？

Carliniは「大きな波が来る」と明確に警告しています。防御者が脆弱性を発見するのを助けるのと同じ能力は、攻撃者にも利用可能です。非対称性として、防御者はトリアージとパッチ適用を自動化できる一方、攻撃者はエクスプロイトの開発が必要です。しかし、発見のギャップは縮まりつつあります。