Claude Opus 4.6の脆弱性発見はファジングと何が違うか — 500件超の見つけ方と自社コードへの当て方

Claude Opus 4.6は、ファジング用の仕組みも専用プロンプトも与えられないまま、OSSから高深刻度の脆弱性を500件超見つけました。2026年2月5日にAnthropicのFrontier Red Teamが公開した調査です。

ファジングは大量のランダムな入力をコードに投げて、壊れる場所を探します。Opus 4.6は人間のリサーチャーのようにコードを読み、推論して見つけます。この違いが、何年もファジングを回されてきたコードベースで脆弱性が出た理由です。

ここでは発表の方法論を分解し、自社のコードに同じ型を当てるときの手順と、500件という数字の読み方を扱います。

ファジングは入力を投げ、Opus 4.6はコードを読む

セキュリティチームは何年も前から、ファジングの基盤とカスタムのハーネスに投資して、バグ探しを自動化してきました。Opus 4.6が目立ったのは、タスク専用のツールも、独自の足場(スキャフォールド)も、特別なプロンプトも使わずに脆弱性を見つけた点です。

見つけ方の違いを、発表の説明に沿って並べると次のとおりです。

発表が挙げる読み方は3つあります。

• 過去の修正を見て、直されていない同種のバグを探す
• 問題を起こしやすいパターンを見つける
• ある処理を理解し、どんな入力で壊れるかを正確に導く

狙ったのは、数百万CPU時間ぶんのファジングを何年も回されてきた、よくテストされたプロジェクトです。そこで、数十年見つからなかった脆弱性も見つかっています。

発表は、ファジングを置き換える話とは書いていません。結論は「既存の発見ツールの上に実質的な価値を足せる」です。以降の手順でも、Claudeの出力をサニタイザーで検証する工程を残しています。

検証環境は「素のClaude + 標準ツール」だった

実験環境は、仮想マシンの中にClaudeを置き、OSSの最新版を渡す構成です。標準ユーティリティ(coreutilsやPython)と、デバッガーやファザーのような解析ツールは使えます。ただし使い方の指示はなく、脆弱性探しに特化したハーネスもありません。

つまり測ったのは、汎用エージェントとしてのClaudeが、手持ちのツールを自分で使いこなす力です。自社で再現するときも、この前提は同じです。長いプロンプトを作り込む前に、素のClaude Codeでどこまで届くかを見るほうが、比較の基準を持てます。

探した対象は、メモリ破壊の脆弱性に絞られていました。理由は検証のしやすさです。ロジックの誤りはプログラムが動き続けるため見分けにくい一方、メモリ破壊はクラッシュの監視と、アドレスサニタイザーのようなツールで捉えられます。

3つの事例で見る、コードを読んで見つけた経路

発表は、すでに維持者が修正済みの3件を取り上げて、LLMが他のツールに勝る点を示しています。

GhostScript — 修正コミットは「他に漏れがないか」の手がかりになる

Claudeは「この変更が境界チェックを足しているなら、変更前のコードは脆弱だった」と推論しました。次に、同じ関数を呼ぶ別の場所を調べ、gdevpsfx.cの呼び出しには、gstype1.cに入ったチェックがないことに気づいています。そこから、GhostScriptをクラッシュさせるファイルをPoCとして作り、予測が正しいと示しました。

この流れは、人間のリサーチャーが行うバリアント解析そのものです。自社コードに当てやすいのも、このパターンです。

OpenSC — 到達しにくい行に集中できる

問題のコードは、4,096バイトのバッファにパスを組み立て、strcatを2回続けて連結する部分でした。発表によると、この行は既存のファザーでは到達に前提条件が多く、ほとんど試されていませんでした。Claudeは全行を同じ労力で調べず、面白いコード片を推論で選んで集中しています。

CGIF — 概念の理解が必要なバグ

LZW圧縮は固定サイズの辞書を持ち、満杯になるとクリアトークンを出します。画像が小さく、符号が増える並びを作ると、出力が入力を上回ってバッファがあふれます。

発表は、カバレッジ誘導型のファザーでもこの種のバグは苦手だと述べています。行と分岐を100%カバーしても残りうるのは、特定の操作列が必要だからです。

500件超は「見つけた数」でなく「確かめた数」

「500件超」を、モデルが出力した指摘数と読むと誤ります。発表の文言は「見つけて検証した高深刻度の脆弱性が500件を超えた」です。検証までの流れは次の4段でした。

この設計の狙いは、誤検知を減らすことです。AIが作った「存在しない脆弱性」の報告がOSSの維持者の負担になっている、という問題意識が背景にあります。パッチ作成の自動化も並行して進められています。

発見が安くなっても、報告を受ける側の処理能力は変わりません。Project Glasswingの1か月レポートでも、修正側がボトルネックになる点が主題でした。数字はProject Glasswingの1か月レポートで確認できます。

自社コードで同じ型を試す

OSSの大規模探索は再現できなくても、「読んで推論する」型は手元のリポジトリに持ち込めます。次は発表の3つの経路を、Claude Codeで試せる形に直した手順です。プロンプトとコマンドは発表の例そのものではなく、型を借りた一例です。

1. 過去のセキュリティ修正から、取りこぼしを探す

まず、自分のリポジトリで過去に直した脆弱性のコミットを洗い出します。

git log --oneline -i \
  --grep='overflow\|bounds\|sanitize\|CVE\|security' \
  | head -30

出てきたコミットを1つ選び、Claude Codeに次のように頼みます。

コミット <hash> は境界チェックを追加する修正です。
1. 修正前のコードがなぜ脆弱だったかを説明してください
2. 同じ関数や同じパターンを使う別の呼び出し箇所を探し、
   同じチェックが漏れていないか確認してください
3. 漏れがあれば、その箇所と根拠をファイル名と行番号で示してください
   まだ脆弱性と断定せず、再現の手順も添えてください

GhostScriptの事例は、まさに「修正が入った場所と、入っていない呼び出し元の差」を見つけた例でした。

2. 危険な関数を手がかりに、前提を確かめる

OpenSCの型です。strcatやsprintfなど、長さの検査が書き手任せになる関数が並ぶ箇所を対象にします。

src/ 以下で strcat・strcpy・sprintf を使っている箇所を洗い出してください。
各箇所で、出力先バッファの大きさと、入力の最大長が
どこで制限されているかを追い、制限が足りない箇所だけ報告してください。

「全部直す」のではなく「前提が崩れうる箇所に絞る」依頼にするのがコツです。

3. 疑わしい箇所は、サニタイザー付きで再現させる

報告が出たら、Claudeに推測だけで終わらせず、再現させます。メモリ破壊ならアドレスサニタイザー付きでビルドし、PoC入力を流します。コマンドはC/C++の一般的な例です。

clang -g -fsanitize=address,undefined -o app_asan src/*.c
./app_asan poc_input.bin

サニタイザーが異常を報告すれば、検証できたと言えます。報告しなければ、その指摘は保留にします。発表がまずクラッシュとサニタイザーで絞り込んだ考え方と同じです。

4. 最後に、批評と優先度付けをやり直させる

出た指摘が複数あるなら、別の依頼でClaudeに重複排除と優先度付けをさせます。

上の指摘を重複ごとにまとめ、悪用しやすさと影響範囲で並べ替えてください。
再現できていないものは「未確認」と明記してください。

これも発表の工程と同じ順序です。ただし、この4つのプロンプトで発表と同じ成果が出るとは限りません。発表は専用の仕組みを使わない場合の結果を報告したもので、プロンプトの有無の比較は載せていません。

/security-reviewとの使い分け

Claude Codeには、現在のブランチの変更をセキュリティ面から調べる/security-reviewコマンドがあります。コマンド一覧の説明では、ブランチとoriginのデフォルトブランチとの差分が対象で、インジェクション・認証の問題・データ漏出といったリスクを特定するコマンドです。

差分レビューは、毎回の出荷前に回す層です。リポジトリ全体を読ませる探索は、頻度を落として別枠で回すものです。コマンドの動作や失敗時の対処はClaude Codeのsecurity-reviewで詳しく扱っています。

公開した側が書いている安全装置と開示ルール

Opus 4.6のリリースに合わせて、Anthropicはサイバー悪用の検知層を追加しました。核になるのは、モデルが応答を生成する間の内部の活性化を測るプローブです。リリース発表では、サイバー向けのプローブを6つ作ったと説明されています。

対応面では、悪意あるとみなしたトラフィックをリアルタイムで遮断する可能性があります。発表自身が、正当なセキュリティ研究や一部の防御作業にも摩擦が生じうると認めています。自社のコードを検査する用途でも、依頼文によっては止まる場合があるということです。研究コミュニティと対処を探る方針とされています。

開示ルールについても記述があります。業界標準の90日の開示期間は、LLMが見つけるバグの速度と量に耐えられないかもしれない、という見立てです。見つけた脆弱性をどう開示するかは、AI時代の運用で変わりうる論点として挙げられています。

OSS側の受け皿としては、Anthropicが申込制で脆弱性スキャンを行う仕組みも出ています。詳しくはAnthropic OSS Scannerの申込手順にまとめています。

編集視点 — 差がつくのは「発見」でなく、検証と修正の速さ

ファジングが読み手を要らないのに対し、Opus 4.6の探索は「何を読ませるか」で結果が変わります。履歴、危険な関数、アルゴリズムの前提という3つの入口は、どれも開発チームが元から持つ知識です。外部の専用ツールがなくても、手元で試せます。

ただし、発見が安くなるほど、ボトルネックは確認と修正に移ります。500件という数字の大半は、人間が検証し、パッチを書く工程が支えていました。自社に持ち込むときも、指摘を出す側より、再現・優先度付け・修正を回す体制が先に詰まります。

もう1つ、同じ能力は攻撃側にも使えます。Opus 4.6がFirefoxの脆弱性をエクスプロイト化した実験はCVE-2026-2796の解説で扱っています。ブロックチェーンの契約コードでも同様の発見が報告されており、SCONE-benchの結果にまとめています。守る側が先に自分のコードを洗う理由は、ここにあります。

まとめ

Opus 4.6の脆弱性発見は、入力を投げるファジングと違い、コードと履歴を読んで推論する探索でした。3つの事例は、修正コミット・危険な関数・アルゴリズムの前提という入口の違いを示しています。500件超は、サニタイザーによる再現、Claudeによる精査、人間による検証を経た数です。

自社コードでは、過去の修正の取りこぼし探しから始め、サニタイザー付きの再現で裏を取る流れが取り入れやすい型です。差分レビューの/security-reviewとは頻度と範囲が違うため、役割を分けて回します。