Googleが公開した脆弱性自動化ハーネス「Mantis」とは
米Googleは2026年9月2日、公式ブログのGoogle Cloud Blogにおいて「Mantis」を発表しました[1]。Mantisはソフトウェアの脆弱性発見から修正までを扱うオープンソースのハーネスです。ここで言うハーネスとは、複数の処理やツールを連結して制御する実行の枠組みを指します。
本プロジェクトのソースコードはGitHubの「google/mantis」リポジトリで公開されており、Apache License 2.0が適用されています[2]。単一の脆弱性検出ツールではなく、AIコーディングエージェントを実行基盤とし、発見、トリアージ、再現、パッチ適用という一連の処理をつなぐセキュリティ専用パイプラインとして設計されています[8]。
標準の対象はWebやクラウドアプリケーションのソースコードとリポジトリ履歴です[9]。過去のセキュリティ修正履歴を読み解き、アーキテクチャや脅威モデルを組み立てた上でレビュー計画を策定します。さらに特定言語にとどまらず、ハードウェア記述言語（RTL）、インフラ構成コード（IaC）、データや機械学習（ML）のパイプライン、コンパイル済みバイナリやファームウェアなど、多様な環境に適応できる設計とされています[10, 33]。
ただし、公式リポジトリにはデモ用途（demonstration purposes only）であることが明記されています[21, 55, 69]。本番環境での利用を想定したものではなく、検証用の開始点として提供されている点には留意が必要です。
後輩公開されたリポジトリをそのまま本番のシステムに導入すれば、脆弱性の対応がすべて自動化できるという話ではないんですね。
先輩その通りです。Google自身もデモ用途と位置付けていて、本番環境向けではないと明記しています。
後輩では、開発現場としてはこの公開をどう受け止めればよいのでしょうか。
先輩脆弱性への対応を単一のツールで終わらせず、複数の工程をいかに多段で検証するかという設計の枠組みを学ぶための基盤と捉えるのが自然です。
なぜ今「自律的な防御」が求められているのか
ソフトウェアを取り巻く環境では、コードや依存関係、システムや運用プロセスが複雑化し、不正な変更を招く経路が増加しています[28]。Google Threat Intelligence Group（GTIG）の報告によると、2025年から2026年前半にかけてオープンソースのサプライチェーン侵害が拡大しており、AIの普及がこの傾向をさらに加速させると予測されています[29, 30]。
攻撃側の能力向上も指摘されています。Googleは、AIエージェントによる脆弱性の発見速度が防御側の修正速度を上回りつつあると説明しています[23]。GTIGは、攻撃者がAIで開発されたとみられるゼロデイ脆弱性を利用した初の実例を確認しました。Google CloudのCISO（最高情報セキュリティ責任者）は、AIの台頭によって脆弱性悪用の経済性が変化し、従来のパッチ適用までの猶予期間が事実上消失したため、防御の自律化が必要になったと述べています[24]。AIモデルが人間の介入をほとんど必要とせずに脆弱性を発見・悪用できる状況では、見逃しや不完全な修正がこれまで以上に短期間で攻撃されるリスクを招きます[70]。
一方で、防御側の人材不足も顕著です。欧州連合サイバーセキュリティ機関（ENISA）が実施した2025年の調査では、サイバーセキュリティ人材の採用難に直面している組織が76%、人材の定着難を抱える組織が71%に達しました[31]。また、同調査では重大な脆弱性に対するパッチ適用に3カ月以上を要している組織が28%に上ることが示されています。
しかし、単純なAIによるコードスキャンでは課題が残ります。Googleの比較説明によると、単純な分散型AIコードスキャンでは幻覚（ハルシネーション）による誤ったバグの指摘が頻発し、真陽性率が7%未満にとどまるとされています[25, 41]。なお、この7%未満という数値はGoogleによる比較用の説明値であり、調査のサンプル数などは記事に記載されていません。また、Mantis自身の精度を示す数値ではありません。こうした誤検知の多さを克服するため、Mantisでは批評やレビューの工程、サンドボックスでの再現検証が組み込まれました[22]。
Mantisが自動化する4つの工程と検証の仕組み
Mantisは、脆弱性への対応を「発見」「トリアージ」「再現」「パッチ適用」という4つの工程に分解して自動化します[3]。
第1の発見工程では、リポジトリのコードや変更履歴を読み込みます。システムの構造や脅威モデルを分析してスキャン計画を立て、脆弱性の網羅的な探索（スイープ）を実行します[4]。階層的なセキュリティ要約ツリー技術を用いることで、構造的な文脈を保ちながらトークン消費のオーバーヘッドを85%以上削減したとされています[42]。
第2のトリアージ工程では、検出された候補から重複を排除します。コードとしての妥当性を精査し、誤検知や本番環境で成立しない問題を除外した上で、影響度と尤度から0.1〜10.0の範囲で「mantis_risk_score」を算出します[5, 19]。外部の静的解析ツール（SAST）の所見を取り込むことも可能ですが、それらは暫定候補として扱われ、後続の検証を通過しなければ採用されません[49]。
第3の再現工程では、脆弱性が本当に成立するかを隔離環境で検証します。欠陥の種別によってアプローチが分かれており、論理・認可の欠陥に対しては機能テストやスクリプトを作成して実行します[38]。一方で、メモリ安全性やバイナリの欠陥に対しては、クラッシュ信号やサニタイザの痕跡を検出することで再現と判定します。実行は直接のマイクロハーネスから段階を踏み、最終的な権威ある再現判定（reproduced）は、公開APIを用いた完全なサンドボックス実行環境でのみ下されます[37, 51]。実行環境にはネットワークを無効化したコンテナ、gVisor、VM、QEMUなどが想定されています[11]。
第4のパッチ適用工程では、最小限の修正コードを生成します[6]。パッチを安全とみなす検証基準（VERIFIED_SECURE）は厳格に定義されています。未修正版での脆弱性再現、修正版でのビルド成功、無害な入力の通過、攻撃入力の遮断を確認します。その上で、独立した再攻撃として少なくとも3種類以上の有効な変異入力を与え、そのすべてを阻止できることが求められます[39, 50, 61]。変異入力が不足している場合は不完全な検証（VERIFICATION_INCOMPLETE）として扱われます。
利用するAIモデルは固定されておらず、エージェント基盤を差し替え可能です。トリアージや重複排除には軽量で高速なFlashやLiteクラスのモデルを割り当て、推論負荷の高い再現やパッチ生成には上位の推論モデルを割り当てることが推奨されています[12, 48]。
後輩なぜパッチの検証で、元の攻撃コードを防ぐだけでなく3種類以上の変異入力を試す必要があるんですか？
先輩AIが生成する修正が、特定の攻撃入力の文字列だけをピンポイントで弾くような狭い修正になってしまう失敗パターンを防ぐためです。
後輩3種類以上の変異入力を防げれば、その脆弱性は完全に塞がれたと言えるのでしょうか。
先輩試験した変異入力の範囲外にある攻撃経路まで保証されるわけではありません。だからこそ、最後には人によるレビューが必須とされています。
従来のセキュリティツールとのアプローチの違い
Mantisは、既存の各種セキュリティツールと異なる出力やアプローチを持っています。
| ツール種別 | 主な対象と手法 | 出力 | Mantisとの役割の違い |
|---|---|---|---|
| 静的解析（SAST） （例: CodeQL） | コードデータベースへのクエリ実行による解析[14] | アラート（SARIF、CSV形式など） | MantisはSASTの所見を取り込みつつ、誤検知レビュー、PoC再現、パッチ検証を後段で行う[14] |
| ファジング （例: OSS-Fuzz） | ランダム・変異させた入力の大量投入によるカバレッジ誘導実行[15] | クラッシュスタックトレース、サニタイザ痕跡 | Mantisは疑わしいコード所見を起点にAIが再現コードを設計し、成立性を確かめる[15] |
| 既知脆弱性スキャナー （例: Dependabot, Trivy） | マニフェストやイメージと既知脆弱性情報の照合[16] | 既知コンポーネントの更新先、重大度 | Mantisは既知情報との照合ではなく、未知のコードロジックや認可経路の欠陥を調べる[16] |
| 一般的なAIコーディングエージェント | プロンプトからのコード生成・テスト実行[17] | ソースコード差分、プルリクエスト | Mantisはエージェント基盤上で動作し、専門的な検証ゲートや再現判定を規律として組み込む[17] |
GTIGは、従来の静的解析やファジングがクラッシュやデータの到達点（シンク）の検出に強みを持つ一方、フロンティアLLMはより上位の論理的な意味論（セマンティック）に基づく欠陥の発見に適していると説明しています[26]。Mantisはテスト対象として、Pythonアプリケーションにおけるパストラバーサルやコマンドインジェクション、SQLインジェクション、evalを用いた任意コード実行などを扱っています[34, 35]。また、評価用データセットでは、到達不能コードやクライアント側のみの制約といった誤検知の除外ルールが定義されています[36]。
入力情報としては対象コードやリポジトリ履歴、脅威モデル、人手による運用知識、サンドボックス環境の条件を受け取ります。出力は所見のJSONデータ、再現コードと実行結果、パッチ差分、状態更新、計画や学習履歴、レビュー報告書で構成されます[13]。
誰に影響するか：セキュリティチームと開発者に求められる役割
Mantisの導入によって、セキュリティ担当者と開発者の協調形態にも変化が求められます。
GoogleおよびMandiantの実運用に近い実績として、社内ハーネスである「AVDH（Agentic Vulnerability Discovery Harness）」の事例が報告されています。企業の盗難リポジトリを対象としたインシデント対応調査において、2日間で100件を超える真陽性の重大脆弱性を発見したとされています[27, 43, 56]。AVDHではWebアプリケーションや拡張機能などを対象に、SQLインジェクションやRCE（リモートコード実行）などが扱われました[44]。ただし、これは社内の独自ハーネスによる事例であり、公開されたMantis OSS自体の網羅率や再現率を示すものではありません。
Mantisの公式ガイドラインでは、完全無人の運用を前提としていません。AIモデルの出力には非決定性があり、幻覚による誤検知や不完全なパッチを生成する可能性があるため、すべての所見は報告前にセキュリティ専門家が手動で確認することが求められています[7, 20, 32, 45, 47, 57]。また、オープンソースのメンテナーに対して、AIが生成した未検証のレポートを大量に送りつける行為は明示的に禁止されています。
運用においてセキュリティチームは、単にログを監視するだけでなく、組織の脅威モデルやリスク許容度に応じた判断基準の設定、サンドボックスの監査などを担います。開発者は、提示された再現コードやパッチ差分を確認し、システム全体の設計と整合しているかをレビューした上で、リポジトリへの適用とコミットを行います[46]。
後輩ツールが自動で修正案まで作ってくれるなら、開発チームのコードレビューの負担は減るのでしょうか？
先輩ゼロから修正案を考える手間は減るかもしれませんが、レビューの責任自体がなくなるわけではありません。
後輩具体的にどういう点を確認しなければならないのですか？
先輩提示されたパッチが他の機能や性能を壊していないか、そして根本的な設計思想に合致しているかを判断するのは人間側の仕事になります。
導入・運用におけるリスクと限界
Mantisを実際に検証・運用するにあたっては、いくつかの技術的な限界や運用上のリスクを把握しておく必要があります。
第一に、コード全体のカバレッジは保証されていません。AIモデルの非決定性により、1回の実行パスではビジネスロジックの欠陥や認可の迂回を見逃す可能性があります[58]。また、自動再現に失敗したからといって、その脆弱性が存在しない、あるいは安全であると断定することはできません[52, 59]。環境制約で再現できない場合に静的解析のみで確定とする区分（statically_confirmed）も用意されていますが、これは最後の手段として強く非推奨とされています[60]。
第二に、パッチの検証範囲に関する制約です。再攻撃の検証を通過したとしても、試験された変異入力を超える未知の攻撃経路が存在する可能性は排除できません[62]。また、パッチ検証はビルド成功や無害入力の疎通を確認するものの、システム全体の包括的な回帰テストではないため、別の機能や性能、互換性を破壊していないかの確認が別途必要です[63]。さらに、複数の脆弱性が連鎖する複雑なエクスプロイトチェーンについては構成要素ごとの検証にとどまり、チェーン全体の自動再現やパッチ検証は行われません[40, 67]。
第三に、実行環境とセキュリティのリスクです。AIが生成する再現コードはホスト環境に悪影響を与える可能性があるため、サンドボックスの隔離設定を誤ると、内部ネットワークやホストOSに損害を及ぼす恐れがあります[68]。リモート環境で動かす際は、対象コードを信頼できない入力として扱い、ネットワークを遮断した非特権コンテナや合成データ環境を用意することが推奨されます[53]。また、悪意あるコードに仕込まれたプロンプトインジェクションによって、AIエージェントが特定の脆弱性を意図的に無視させられるリスクも公式資料で指摘されています[66]。
認証情報や機密データの漏洩にも注意が必要です。Mantisは実行ログなどを蓄積するため、コードに含まれる認証情報がログへ混入し、エージェントが侵害された場合に外部流出する危険性があります[65]。利用にあたっては、ゼロデータ保持（ZDR）の契約締結や、短期間・最小権限のトークン設定が求められます[54]。スナップショットの固定を行わない既定の運用では、分析中に対象コードが変更されてレビュー結果と実コードが乖離する恐れもあります[64]。
評価手法に関しても、公開資料には網羅的な成功率や処理時間のエンドツーエンドの集計値は提示されておらず、ツールエラー率やGive Up率などを代理指標として自ら計測することが推奨されています[18]。自組織の環境に適した運用設計と、人間による厳格な検証体制を構築することが、安全な活用の前提条件となります。
