「脆弱性の“発見”はもう民主化した」 Mythos時代、Claudeでコードを保護するベストプラクティス：“修正”は6％しかできていない

Anthropicは公式ブログで、同社の「Claude Opus」を活用してソースコードを保護するためのベストプラクティスを紹介した。

[＠IT]

　「Claude Mythos Preview」をはじめとするフロンティアAIが従来と比較にならないほどの膨大な脆弱（ぜいじゃく）性を発見するようになり、企業・組織には脆弱性対応の根本的な見直しが迫られるとされる中、「Claude Mythos 5」の限定提供が始まった（参考）。

　これに先立ちAnthropicは2026年5月27日（米国時間、以下同）、同社の大規模言語モデル（LLM）「Claude Opus」を活用し、ソースコードを保護するためのベストプラクティスを紹介したブログ記事を公開。LLMを用いて脅威モデルを構築し、コードベースに潜む脆弱性を発見し、効率的にそれらの検証、トリアージ（重複排除と優先順位付け）、修正を行う体系的な手法を解説している。本稿では、記事の内容を要約する。

脆弱性の「発見」は、もはやボトルネックではない

　AIの能力が急速に進化する中、ソースコード保護プロセスにおいて脆弱性の発見は、容易に並列化できるようになった。その結果、このプロセスのボトルネックは、検証、トリアージ、修正に移行していると、Anthropicは指摘する。

　例えば、同社は、オープンソースソフトウェア（OSS）を対象としたセキュリティスキャン結果として、2026年5月22日時点で1596件の脆弱性が見つかったと報告した。だが、5日後の今回のブログ記事公開時点で、これらのうち修正されたことが確認できたのは97件だったという。修正率にすると、わずか6％という数値だ。

Mythos時代に対応できる“防御のループ”の回し方

　Anthropicは、開発チームとセキュリティチームが自社のコードやOSSの脆弱性を発見、修正してきた実績を基に、「最も多くの脆弱性を発見、修正しているチームは共通して、既存のベストプラクティスを応用して実践している」と述べ、それらを以下の6つのステップにまとめている。

1. 脅威モデルの作成
   自動スキャンを開始する前に、何が脆弱性に該当するのかを正確に定義する
2. サンドボックスの構築
   AIエージェントを隔離し、脆弱性の悪用可能性を安全に検証するためのサンドボックス環境を構築する
3. 発見
   AIモデルにソースコードの脆弱性を探させる
4. 検証
   検出結果が実際に悪用可能かを独立して確認する
5. トリアージ
   検出結果の重複を排除し、各結果に深刻度を割り当て、修正の優先順位を決める
6. 修正
   コードに修正を加え、脆弱性が解消されたことを確認し、バリエーションを探す

「脅威モデルの作成」と「サンドボックスの構築」への1回の投資が、防御のループ（「発見」「検証」「トリアージ」「修正」のサイクルを繰り返す）を支える。ボトルネックは「発見」ではなく、以降の全てのステップだ（提供：Anthropic）

　最初の2ステップ、1．脅威モデルの作成と2．サンドボックスの構築は通常、コードベースごとに1回行い、基盤となるシステムを変更した際に見直す。

　以降の4つのステップ（3．発見、4．検証、5．トリアージ、6．修正）のサイクルは、ソースコードに対して繰り返し実行する。

　その最初のループの発見ステップにおけるコードベースのスキャンにより、最も多くの脆弱性が検出されるのが通例だ。その後のループでは、検出件数は減る傾向にあるが、その多くはより複雑なものとなる。モデルは確率的に動作するため、大規模なコードベースでは、コードに変更がなくても、脆弱性が少しずつ発見され続ける“ロングテール”現象が生じ得る。

　コードベースに対する最初のループでは、4ステップのサイクルを複数回繰り返し、新たに発見された脆弱性の数と、当該システムのリスク許容度に基づいて、ループを終了するタイミングを判断する。その後は、定期的に、またはコードに重要な変更があった際に、このサイクルの一環としてスキャンを実行する。

1．脅威モデルの作成：何を脆弱性と見なすかを定義する

　脅威モデルは、上の3．発見ステップでスコープを設定するために、5．トリアージステップで深刻度を適切に調整するために使用される。

　Anthropicは、誤検出の最も一般的な原因として、AIモデルがシステムの信頼境界を十分に理解していないことを挙げ、その解決の決め手となる脅威モデルを2つの手順で作成することを推奨している。

　まず、新人のセキュリティエンジニアが入社初日に受け取るような資料（アーキテクチャドキュメント、Wiki、エントリポイント、「Git」履歴、過去の脆弱性情報）をAIモデルに与える。システムのコンテキストや資産、エントリポイント、信頼境界を含む脅威モデルの作成をAIモデルに指示する。AIモデルに過去のバグを分類させ、関連する脆弱性クラスをリストアップさせる。

　次に、脅威モデルを効率的に作成するために、システムに精通した担当者に対するインタビューをAIモデルに行わせる。インタビューでは、「何を作っているのか」「何が問題になり得るのか」「それに対してどのような対策を講じているのか」「その対策は適切なのかどうか」といったポイントを押さえさせる。インタビューは任意だが、コードやドキュメントからは得られないコンテキストを追加できるため、脅威モデルの質を高めるのに役立つ。

　Anthropicは、脅威モデル作成のヒントとして、依存関係のセキュリティポリシーを考慮することを挙げている。「vLLM」「SQLite」「ImageMagick」といったOSSプロジェクトがこれを公開している。信頼する設定ファイルや認証済みクライアントなどについては、脅威モデルにその旨を明記するのも有効だ。リポジトリに脅威モデルファイル「THREAT_MODEL.md」を置き、コードの変更に合わせて更新し、発見エージェントが探索を行う前に読み取れるようにすることも推奨している。

2．サンドボックスの構築：エージェントの安全な実行と、悪用可能性の検証を可能にする

　サンドボックスの構築には、2つの目的がある。1つ目は、エージェントを隔離して自社のシステムを守ることだ。自律的なエージェントは、対象を越えて想定外の動作をする恐れがあるからだ。

　Anthropicは、隔離のレベルを脅威モデルに合わせることを推奨している。対象とそのPoC（概念実証）コードは、本番システムに到達できないように、アウトバウンド通信を制限したマイクロ仮想マシン（VM）やフルVMで実行し、認証情報は決してエージェントに渡さないようにすべきだとしている。

　2つ目の目的は、悪用可能性の実証だ。静的スキャンでは、モデルはコードを読み取って「何が破綻する可能性があるか」を推測するが、パスに到達できるかどうかは確認できない。

　エージェントがコードをコンパイルし、テストを実行し、PoCを行えるサンドボックスを構築したところ、悪用不可能な検出結果は大幅に減ったという。

　Anthropicは、本番環境に忠実なサンドボックスの重要性も指摘する。依存関係（キューやデータストアなど）を除外すると、本番環境に存在する可能性のあるバグを見落としかねず、逆に本番環境の防御策（Webアプリケーションファイアウォールや認証ゲートウェイなど）を無視すると、本番環境で緩和済みで悪用不可能な検出結果を、モデルが報告してしまう。

　ただし、本番環境に忠実なサンドボックスの構築が現実的でない場合は、3．発見ステップから始めても構わないという。フロンティアモデルは、ソースコードの分析だけでも脆弱性をよく見つけるからだ。発見された脆弱性が多ければ、後からサンドボックスに投資するという手もある。

3．発見：豊富なコンテキスト、短いプロンプト、有用なツールを提供する

　Anthropicは3．発見ステップについて、直感に反する教訓を提示する。指示が細かいプロンプトは、かえって検出のパフォーマンスを悪化させるというものだ。長いチェックリストは、モデルの創造性を低下させ、新規バグの発見数を減らす傾向がある。

　代わりに同社は、モデルに目的とコンテキストを与えることを勧める。「なぜスキャンするのか」「重要な検出結果とはどのようなものか」を伝え、「どう探すか」はモデルに委ねるという考え方だ。

　その他にも推奨事項として、必要に応じて特定の脆弱性クラスを指定することや、構造化された出力形式を定義すること、grep、SAST（静的アプリケーションセキュリティテスト）スキャナ、ファジングツールといったツールをモデルに与えることが挙げられている。

　Anthropicは、まずコードベースを分割し、領域ごとに発見エージェントを並列に展開することも勧めている。エージェントをむやみに増やす力任せのやり方は、すぐに効果が頭打ちになるからだ。

4．検証：悪用不可能な検出結果を除外する

　3．発見ステップでは発見の網羅性を重視するのに対し、4．検証ステップでは精度を追求し、悪用できない検出結果を除外することを重視する。

　Anthropicは、この2つは別のステップに分けるべきだと強調する。1つのエージェントが3．発見と4．検証を同時に行おうとすると、自己検閲によって本物の脆弱性まで除外してしまう可能性があると説明している。

　同社によると、検証エージェントは、発見エージェントとの共有ファイルシステムや会話履歴がない新しいコンテナで実行し、発見エージェントの推論に影響されることなく、独立して動作させる必要がある。概念実証または検出結果報告のみを渡し、検証エージェントが発見エージェントの見落とした緩和策を探せるようにすべきだという。

　Anthropicは、検証エージェントに対する指示では、発見エージェントの各検出結果を、「誤検出として反証する」よう促すことを勧める。

　同社が協力してきたチーム全体の実績として、こうした敵対的な検証エージェントの導入により、悪用不可能な検出結果の割合がほぼ半減したと報告している。さらに、それらの検証エージェントに、悪用可能性を裏付けるPoCコードの構築を求めたところ、誤検出率はほぼゼロになったという。

5．トリアージ：重複排除と優先順位付け

　適切な5．トリアージは、多忙な製品エンジニアやOSSメンテナーの“アラート疲れ”を防ぐのに役立つ。

　Anthropicは、根本原因に基づいた重複排除を勧める。まず低コストな決定論的処理で絞り込んだ上で、モデルに定性的なルールを適用させるという手順だ。

　その後、各検出結果の深刻度を、到達可能性、攻撃者による制御、前提条件、認証の要否、読み取りか書き込みか、影響範囲といった観点で評価する。

　Anthropicは、モデルがバグの種類にとらわれて深刻度を誇張したりしないように、モデルに各観点での評価結果を記述させた上で、スコアを付けさせることを勧めている。コンテキストが不十分なためにモデルが深刻度を過大評価することがないように、トリアージステップで脅威モデルを提供し、システムにおいてどの種類の脆弱性を重視し、どの種類を重視しないかをモデルに伝えることも勧めている。

6．修正：ループを閉じ、次のサイクルのコンテキストを改善する

　この最終ステップでは、特定された脆弱性を修正し、次のサイクルに向けてコンテキストを改善する。Anthropicはテスト駆動開発の手法を推奨する。コードの修正前に、既存コードで失敗するような修正内容のテストを作成し、想定通りにテストが失敗することを確認してから、6．修正を実装し、他の機能を壊すことなく、同じテストが通ることを確認するという流れだ。

　モデルは、根本原因ではなく単一の呼び出し箇所だけを修正することがある。そこでAnthropicは、モデルに根本原因の特定と修正を指示した上で、「同じパターンが別の場所にないか」「同じクラスのバグが他にないか」という観点から、バリエーションを探させることを勧める。

　各修正は、一連のチェックで検証できる。

1. ビルド：パッチがコンパイルされ、新しいテストが通るかどうか
2. 再現を試みる：元のPoCコードが動作しなくなるかどうか
3. リグレッションの確認：元のテストスイートが依然として通過するかどうか
4. 再攻撃：新しい発見エージェントが敵対的チェックを実行する。これにより、不完全なパッチが検出される

コンパニオンリポジトリも提供

　Anthropicは、「攻撃者がLLMを用いてソフトウェアの脆弱性を発見し、悪用することは、ますます容易になっている」との認識を示す。防御側の役割は、攻撃者が悪用する前にコードの脆弱性を3．発見し、6．修正することであり、以上のベストプラクティスを活用して適切に取り組めば、大きな変革の始まりとなると述べている。

　なお、同社はこのブログ記事のコンパニオンリポジトリ「defending-code-reference-harness」を公開し、脅威モデリングからスキャン、トリアージまでのインタラクティブなワークフローを、順を追って体験できるようにしている。このリポジトリには、自律型ハーネスと、環境に合わせてハーネスを更新するための「/customize」スキルも含まれている。