Google DeepMind「CO-REDTEAM」が示す自律型脆弱性診断の未来

はじめに

現代のソフトウェア開発現場において、セキュリティエンジニアが直面する課題は複雑化の一途を辿っています。バイブコーディングによって開発サイクルは高速化し、コードベースは巨大化し、依存関係は網の目のように広がりました。これに対し、人間の専門家による手動のレッドチーミングやペネトレーションテストは、その品質の高さと引き換えに、拡張性（スケーラビリティ）の欠如という課題に直面しています。

私たちは今、生成AIとセキュリティが交差する新たな転換点に立っています。これまでの「チャットボットにコードのバグを尋ねる」という段階から、AIが自律的にシステムを調査し、攻撃を計画し、実行し、その結果から学習する段階への移行です。

本稿では、Google DeepMindの研究チームが2026年2月に発表した論文「Co-RedTeam: Orchestrated Security Discovery and Exploitation with LLM Agents」を題材に、最新のAIセキュリティエージェントのアーキテクチャと能力を詳細に解説します。論文紹介にとどまらず、CybenchやBountyBenchといった最新のベンチマーク環境での評価、既存の自動化ツールとの比較、そして2026年以降のセキュリティ業務に与える影響について、掘り下げていきます。

本論文が示唆するのは、脆弱性診断における「自律的動的実証」へのパラダイムシフトです。CO-REDTEAMがどのようにして既存のLLMの限界、幻覚（ハルシネーション）、コンテキストの欠如、実行能力の欠如を克服したのか、その内部構造を解き明かします。

なぜLLMはハッキングに失敗するのか

静的推論の限界と「実行」の欠落

LLMの黎明期、多くの研究者が「コードを理解できるなら、脆弱性も見つけられるはずだ」と期待を寄せました。実際、GPT-4やClaude 3といったモデルは、既知の脆弱性パターン（SQLインジェクションやXSSなど）をコードスニペットから指摘することには長けています。しかし、実世界のレッドチーミングにおいては決定的な成果を上げられずにいました。

最大の障壁は「実行フィードバックの欠如」です。脆弱性診断において、コードの記述が「怪しい」ことと、それが「実際に悪用可能である」ことの間には大きな隔たりがあります。入力値がサニタイズされているか、WAF（Web Application Firewall）で遮断されるか、OSレベルの保護機構（ASLRやDEPなど）が有効かといった実行環境のコンテキストは、静的なコードだけでは判断できません。

LLMによるカスタマイズされていない従来のエージェントや汎用的なコーディングエージェント（例：OpenHands 3）は、コードを生成することはできても、そのコードを実行して得られたエラーメッセージを解釈し、攻撃コードを修正して再試行するという「試行錯誤のループ」を回す能力に特化していませんでした。結果として、CyBenchのようなCTF（Capture The Flag）形式のベンチマークにおいて、単純なモデルは10〜18%程度の成功率に留まっていました。

既存の自動化ツールの壁

RepoAuditやVulTrailといった先行研究では、リポジトリレベルの監査や、複数のエージェントによる模擬裁判（Mock Court）形式での脆弱性判定が試みられてきました。これらは静的解析の精度向上には寄与しましたが、「攻撃の実証（Proof of Conceptの作成）」という点では課題を残していました。

VulTrailのような静的アプローチは、実行能力を持たないため、BountyBenchのExploitタスクにおいて成功率0%〜10%という結果に終わっています。CO-REDTEAMが画期的であるのは、この実行プロセスをシステムの中核に据え、失敗から学ぶプロセスをシステム設計として具現化した点にあります。

CO-REDTEAMのアーキテクチャ：組織化された専門家集団

CO-REDTEAMの設計思想は、一人の天才ハッカーを模倣するのではなく、役割分担された「レッドチーム」を組織することにあります。システムは、全体を統括する「オーケストレータ」と、特定のタスクに特化した複数のエージェントで構成されています。

オーケストレータ：PMとしての役割

システムの中心に位置するオーケストレータは、ユーザからの入力（コードベースのパスや脆弱性のヒント）を受け取り、プロジェクト全体を管理します。人間で言えば、レッドチームのリーダーやプロジェクトマネージャに相当します。

オーケストレータの主な責務は次の通りです。

1. 初期化と権限委譲: 各エージェント（分析、計画、実行など）をインスタンス化し、それぞれの役割に応じたツール（コードブラウザ、Docker実行権限など）を割り当てます。
2. フロー制御: 脆弱性発見フェーズから実証フェーズへの移行を判断します。十分な証拠が集まった場合や、逆に手詰まりになった場合の終了判断を行います。
3. 状態管理: エージェント間の情報の受け渡しを管理し、共有メモリへのアクセスを調整します。

この中央集権的な制御により、エージェントが暴走して無限ループに陥ったり、無関係なタスクにリソースを浪費したりするリスクを抑制しています。

ステージ I：脆弱性を発見するメカニズム

最初のステージでは、対象のコードベースを探索し、攻撃の糸口を見つけます。ここでは「解析エージェント」と「評価エージェント」がペアとなって動作します。

解析エージェント：根拠に基づく仮説生成

解析エージェントは、単にコードを読むだけではありません。コードブラウジングツールを駆使して、ファイル構造の把握、READMEの解読、依存関係の確認を行います。 特筆すべきは、このエージェントがCWEやOWASPといったデファクトスタンダードの知識にアクセスできる点です。エージェントは次の戦略を用いて分析を行います。

• テイント解析（Taint Analysis）: 信頼できない入力がどこから入り、危険な関数（Sink）へどう流れるかを追跡します
• 信頼境界のマッピング: 認証が必要な領域と不要な領域の境界線を特定します。
• 設定監査: Dockerfileや設定ファイルから、デバッグモードの有効化や既知の脆弱なライブラリの使用を検出します。

評価エージェント：内部レビューによるフィルタリング

生成された脆弱性候補は、即座に評価エージェントに回されます。このエージェントは厳格なレビュアーとして振る舞います。証拠（ファイル名、行番号、ロジック）が不十分な場合や、リスクが低い（Informationalレベル）と判断された場合、その提案を「却下（REJECTED）」または「要修正（NEEDS_REFINEMENT）」として差し戻します。このプロセスにより、LLM特有のハルシネーションによる誤検知（False Positive）を劇的に削減しています。

ステージ II：反復的実証のダイナミクス

脆弱性の候補が特定されると、システムは「実証」フェーズへと移行します。ここがCO-REDTEAMの真骨頂であり、Planner、Execution、Evaluationの3つのエージェントが連携して攻撃を成功させます。

動的に変更される攻撃計画

計画エージェントは、いきなり攻撃コードを書くのではなく、まず「研究計画（Research Plan）」を立案します。計画はステップごとに「予定（PLANNED）」「完了（DONE）」「ブロック（BLOCKED）」のステータスで管理されます。

もし実行が失敗した場合、Plannerは計画を動的に書き換えます。「ペイロードがWAFに弾かれた」という結果を受ければ、「エンコーディングを変えて再送する」という新しいステップを追加します。この「動的な計画修正能力」こそが、静的なスクリプトキディと自律型エージェントを分かつ決定的な違いです。

安全な実行環境

作成された攻撃コマンド（BashやPythonスクリプト）は、まずバリデーションエージェントによって構文チェックと安全性確認が行われます。その後、隔離されたDockerコンテナ内で実行エージェントによって実行されます。これにより、ホストシステムへの悪影響を防ぎつつ、実際の環境での挙動を確認します。

結果の分析

実行結果（標準出力、エラーログ）は評価エージェントによって分析されます。単に「エラーが出た」だけでなく、「なぜ失敗したのか」「サーバはどのような反応を返したか」を言語化し、計画エージェントにフィードバックします。

長期記憶：経験による進化

CO-REDTEAMが他のシステムと一線を画すもう一つの要素が「長期記憶」の実装です。人間が経験を通じて勘を養うように、このシステムも過去の成功と失敗から学習します。

記憶は次の3つのレイヤで構成されています。

システムは、ベクトルデータベースを用いて現在の状況に類似した過去の記憶を検索・取得（RAG）します。

コールドスタート問題の解消

実験データによれば、記憶を持たないエージェントに比べ、過去のセキュリティ知識を初期ロード（Warm Start）されたエージェントは、初期段階から高いパフォーマンスを発揮します。さらに、タスクをこなす過程で新たな記憶を蓄積することで、成功率は右肩上がりに向上していきます。これは、組織内でのレッドチーミング運用において、実施回数を重ねるほど診断精度が向上することを意味します。

ベンチマーク評価に見る実力

CO-REDTEAMの実力を客観的に評価するため、3つの主要なベンチマークでの結果を分析します。

CyBench：CTF形式での評価

Cybenchは、CTF（Capture The Flag）大会の問題を集めたベンチマークであり、パズル的な要素や高度な悪用技術が求められます。 Gemini-3-Proをバックボーンに使用したCO-REDTEAMは、63.7%の成功率を記録しました。対照的に、汎用エージェントであるOpenHandsは45.2%、チューニングされていない、素のLLMは18.5%に留まっています。この差は、複雑な手順を要する問題において、計画と実行のループがいかに重要かを示しています。

BountyBench：実世界の脆弱性

BountyBenchは、実際のバグバウンティ（脆弱性報奨金制度）で報告された実在の脆弱性を再現した環境です。ここでの結果は、実務への適用可能性を直接的に示唆します。 CO-REDTEAMは、攻撃タスクにおいて65.0%の成功率を達成しました。

さらに注目すべきは検知タスクにおける20.0%という数字です。一見低いように見えますが、OpenHandsなどの他手法が0%〜5%程度であることを考慮すると、圧倒的な差です。実世界の脆弱性は教科書通りのパターンで現れることが少なく、コンテキストの深い理解が必要とされるためです。

適合率と再現率のバランス

特筆すべきデータとして、BountyBenchの検知タスクにおける適合率（Precision）があります。CO-REDTEAMは14.3%を記録し、C-Agentの2.4%を大きく引き離しました。これは、評価エージェントによるフィルタリングが機能しており、無差別な試行を抑制し、エンジニアが確認すべき「質の高いアラート」を出力できていることを意味します。

速度とコスト

処理時間を比較すると、CO-REDTEAMはOpenHandsと比較して高速に動作しています（BountyBenchで平均198.7秒 vs 219.6秒）。複雑なマルチエージェント構成でありながら、役割分担が明確で無駄な推論が少ないため、効率的にタスクを完了できていることがわかります。

自律型エージェントがもたらすリスクと対策

CO-REDTEAMのような強力なツールは、防御者だけでなく攻撃者にとっても有用であるという「デュアルユース」のリスクを孕んでいます。

防御側の進化：AIファイアウォール

これに対抗するため、2026年には「AIファイアウォール」や「AIサーキットブレーカー」といった防御技術の普及が予測されています。これらは、入ってくるプロンプトやトラフィックをリアルタイムで分析し、自律エージェントによる攻撃の兆候（高速な試行錯誤、不自然なコンテキストの変更など）を検知して遮断します。セキュリティは「人間 vs 人間」から「AIエージェント vs AI防御システム」の構図へと移行しつつあります。

幻覚と誤検知の制御

CO-REDTEAMは評価エージェントによって誤検知を減らしていますが、ゼロではありません。実運用においては、AIが出力したレポートを人間が最終確認する「Human-in-the-loop」の体制が当面は不可欠です。しかし、AIが一次フィルタリングを行うことで、人間はより高度な判断や、AIが見落とす「ビジネスロジックの欠陥」の発見に集中できるようになります。

技術的な詳細とプロンプトエンジニアリング

読者の皆様の中には、具体的にどのようなプロンプトを与えればエージェントがこのように振る舞うのか、関心をお持ちの方も多いでしょう。論文の付録資料から、重要なプロンプト設計のエッセンスを抽出して紹介します。

解析エージェントへの指示

「あなたはシニアセキュリティアナリストです。創造的かつ証拠に基づいて脆弱性をブレインストーミングしてください。次のメンタルモデルを使用してください：

1. テイント分析: 入力（request.argsなど）から危険なシンク（evalなど）への経路を追跡せよ。
2. 信頼境界マッピング: データが「信頼できない」領域から「信頼できる」領域へ移動する境界にチェックがあるか確認せよ。
3. 設定監査: デバッグモードやハードコードされた秘密情報を探せ。

評価エージェントへの指示

「あなたは評価エージェントです。提案された脆弱性リストを厳密に検証してください。各脆弱性について、証拠が説得力を持つか、リスクの論理的根拠が健全かを評価し、リスクレベル（Critical〜Informational）を判定してください。証拠が不足している場合は「REJECTED」または「NEEDS_REFINEMENT」とし、具体的な修正フィードバックを記述してください。」

計画エージェントへの指示

「あなたは脆弱性再現プランナーです。現在の状況と前回の実行結果に基づき、計画を更新してください。ステップが「BLOCKED」になった場合、即座に修正ステップ（例：代替コマンドの試行）を挿入してください。新たに得られた情報が将来のステップを無効にする場合、積極的に将来のステップを修正してください。」

これらのプロンプトから読み取れるのは、AIに対して「何をすべきか」だけでなく、「どのように思考すべきか（メンタルモデル）」や「どう失敗に対処すべきか」を具体的に指示することの重要性です。

結論と今後の展望

CO-REDTEAMは、LLMを活用したセキュリティ診断における一つの到達点を示しました。それは、静的な知識と動的な実行能力を、組織化されたエージェント群と長期記憶によって統合するアプローチです。

この技術の登場は、セキュリティエンジニアの仕事を奪うものではなく、質を変えるものです。定型的な脆弱性スキャンや既知のパターンの悪用はAIに任せられるようになります。セキュリティエンジニアに求められる能力は次のようにシフトするでしょう。

1. AIオーケストレーション能力: どのようなツールを与え、どのような権限でエージェントを動かすかを設計する能力。
2. 高度な論理的脆弱性の発見: AIが苦手とする、複雑なビジネスロジックや仕様の矛盾に起因する脆弱性の特定。
3. AI防御の構築: 自律型エージェントからの攻撃を防ぐための、AIネイティブな防御策の策定。

今後、CO-REDTEAMのようなフレームワークは商用ツール化が進み、DevSecOpsパイプラインに標準的に組み込まれるようになるでしょう。開発者がコードをプッシュした瞬間に、AIレッドチームがその変更に対して攻撃を仕掛け、脆弱性を修正するプルリクエストまで自動生成する——そんな未来はすぐそこまで来ているのかもしれません。

セキュリティは「守る壁」から「自律的に免疫を獲得するシステム」へと進化しています。CO-REDTEAMはその進化の過程における重要なマイルストーンとして、長く参照されることになるでしょう。