エージェントが脆弱性を発見したとき

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として認定されています。³ 氏は「検証して報告する時間がないクラッシュが数百件ある」と語っています。²

Carlini氏はこれらの脆弱性を確認し、メンテナーに報告しました。発見に使ったのはOpus 4.6、実務者がコードレビュー、リファクタリング、機能開発に日々使っているのと同じモデルクラスです。Carlini氏はこの成果を2026年4月の[un]prompted AIセキュリティカンファレンスで発表しました。¹

そう、AIエージェントは人間の専門家が何十年も見落としてきた実在のセキュリティ脆弱性を発見できるのです。 Anthropicの研究者がClaude Codeと10行のbashスクリプトを使い、Linuxカーネルに23年間潜んでいたリモート攻略可能なヒープバッファオーバーフローを発見し、122件のクラッシュ入力から22件のFirefox CVEを生み出しました。方法論にカスタムフレームワークは不要です。ASAN計装ビルドでソースファイルを反復処理し、モデルにバグを探すよう促すだけです。

TL;DR

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. 関連度の高いファイルに対し、capture-the-flagのフレーミングでClaude Codeにプロンプトを送る
4. 対象ごとに複数回のパス（コードベースに応じて5〜20回）を実行
5. 自動クリティークエージェントで、開示前に発見内容を検証

capture-the-flagのフレーミングが重要です。「このコードにはバグがある」とモデルに伝えると、「このコードの問題点をレビューせよ」と言うのとは異なるモードが起動します。開発者は日々の使用で同じパターンに気づくものです。Claudeは、問題が存在するかもしれないと尋ねるときよりも、問題が存在すると告げるときの方が多くの問題を見つけるのです。²

このスイープにかかるコストは人月ではなく、APIトークンです。Carlini氏は汎用エージェントのCLIで、Linuxカーネル脆弱性5件とFirefox CVE 22件を発見しました。³ ユニットテストを書き、importを整形しているのと同じツールです。

能力のしきい値

もっとも印象的な発見は、モデル世代間のギャップです。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フックは、変更されたファイルに対するターゲット型セキュリティスキャンを起動できます。このフックは標準入力からファイルパスを読み取ります（Claude CodeはイベントJSONを標準入力経由でフックに渡します）。

#!/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氏の方法論と一致します。ターゲット型プロンプトでファイルをループするのです。³

トリアージインフラを構築する。 深刻度分類のない生の脆弱性発見はノイズです。エージェントがスイープごとに50件の発見を生み出すなら、人間がリストを見る前に自動重複排除と優先度スコアリングが必要となります。ボトルネックはモデルの問題ではなく、ハーネスの問題です。

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

23年前のLinux脆弱性は、隠れていたわけではありません。数千人のエンジニアが読んだファイルの、目の前にあったのです。モデルがそれを見つけたのは、スケールでのパターンマッチングこそがこれらのシステムの得意技だからです。教訓は、エージェントがセキュリティにおいて人間より優れているということではありません。教訓は、エージェントが異なる面をカバーするということであり、両方を編成するハーネスこそが、その組み合わせを信頼できるものにするということです。

更新（2026年4月7日）: AnthropicはProject Glasswingを発表し、Carlini氏のアプローチを主要プラットフォーム全体にまたがる数千件のゼロデイへとスケールさせた、Claude Mythosという新モデルを公開しました。Mythosは現在12社のパートナーに限定されており、一般には公開されていません。上記の記事はCarlini氏のオリジナルの研究を扱うものです。続編が製品化を扱います。

出典

よくある質問

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

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

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

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

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

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