Google Mantis徹底解説 ― AIによる脆弱性の発見・再現・修正を自動化するセキュリティHarness

サマリー

Googleが公開した「Mantis」は、単にAIへソースコードを読ませて脆弱性候補を列挙させるツールではない。

本質は、

脆弱性候補の発見 → 批判的検証 → サンドボックスでの再現 → 修正コード生成 → 再検証

までを、複数のAIエージェントとプログラム側のオーケストレーションで閉ループ化する「Security Harness」である。

Googleは、精度の低いAIコードスキャンでは真陽性率が7%未満となる場合があると指摘している。Mantisは、AIの出力をそのまま信じず、別エージェントによる反証、再現実験、修正後の検証を組み込むことで、この問題を緩和しようとしている。

また巨大リポジトリに対しては、ファイル→ディレクトリ→リポジトリ全体という階層型のセキュリティ要約を作成し、必要なコードだけを詳細に読む方式を採る。Googleはこれにより、重要な構造情報を維持しつつ、リポジトリ文脈を与える際のトークンオーバーヘッドを85%以上削減できたとしている。

Mantisの技術的な重要点は「85%削減」そのものよりも、AIを「答える機械」から「実験して証明する機械」へ移行させている点にある。

色付けアラート

1. Mantisとは何か

Googleは2026年9月2日、AIを利用してソフトウェアの脆弱性を発見し、候補の検証、再現、修正まで進めるオープンソースフレームワーク「Mantis」の詳細を公開した。

Mantisは、LLMそのものではない。

Gemini CLIなどのAIコーディングエージェントを動かし、その行動を制御・整理・検証するための「Harness」である。

概念的には次のようになる。

AI Model
   |
   v
Mantis
- orchestration
- state management
- repository research
- vulnerability review
- reproduction
- patching
- verification
   |
   v
Repository / Sandbox

したがってMantisは、

AIセキュリティモデル

というより、

AI Security Engineerを組織化する実行基盤

と考える方が正確である。

2. 従来型AI脆弱性検査との違い

従来型のAIコード検査では、次のような流れになりやすい。

Source Code
   |
   v
LLM
   |
   v
"ここにSQL Injectionがあります"
"ここにメモリ破壊の可能性があります"

最大の問題は、AIが「脆弱性らしいもの」を大量に列挙してしまうことである。

Googleは、精度の低いAIコードスキャンでは、実際に正しい脆弱性だった割合、すなわち真陽性率が7%未満になる場合があると説明している。

仮に100件の警告が出ても、本物が7件未満なら、残りの大半を人間が確認しなければならない。

これはセキュリティ担当者の負担削減にならない。

Mantisは、この問題を「AIの出力を別のAIと実験で検証する」ことで解決しようとしている。

Repository Understanding
        |
        v
Vulnerability Discovery
        |
        v
Critic / Review
        |
        v
Sandbox Reproduction
        |
     成立するか
        |
      Yes
        v
Patch Generation
        |
        v
Re-verification

つまり、

AIの回答を信じるのではなく、AI自身に証拠を作らせる

という設計である。

3. 複数AIエージェント化が核心

Mantisでは、単一のLLMに全工程を任せない。

役割を分けた複数のエージェントまたはスキルを使う。

これは、人間のセキュリティチームに近い。

Security Researcher
        |
        v
Peer Review
        |
        v
Red Team / Reproduction
        |
        v
Developer
        |
        v
QA / Verification

この構造をAIエージェントで実装する点がMantisの特徴である。

4. Git履歴を見る意味

Mantisは現在のソースコードだけを見るわけではない。

解析前に、

• 過去のcommit
• 過去のsecurity fix
• バグ修正履歴
• アーキテクチャ
• リポジトリ構造

などを調べる。

これは重要である。

例えば、過去に認証処理で脆弱性が修正されていたとする。

auth_check()

その履歴からAIは、

このプロジェクトでは認証境界が脆弱になりやすい

という背景知識を得られる。

さらに類似実装を検索し、同系統の未修正脆弱性を探せる。

医学的にたとえるなら、

現在の所見だけではなく、既往歴・過去検査・治療歴まで参照して診断する

ことに近い。

5. 脅威モデルまでAIが構築する

通常、本格的なセキュリティ評価では脅威モデルを作成する。

典型的な要素は次の通りである。

• Asset
• Trust Boundary
• Attack Surface
• Authentication
• Authorization
• Data Flow
• Privilege
• External Interface

しかし現実の開発プロジェクトでは、脅威モデルや設計文書が十分に整備されていないことも多い。

Mantisは、

Repository
   |
   v
Architecture Model
   |
   v
Attack Surface
   |
   v
Threat Model

という形で、コードと履歴から背景情報を自動生成する。

これにより、ドキュメントが不十分なリポジトリでも、AIがセキュリティ解析に必要なコンテキストを自ら構築できる。

6. 85%以上のトークン削減とは何か

巨大リポジトリでは、全ファイルをそのままLLMへ送ると入力トークン数が膨大になる。

Mantisは、この問題に対して階層型のセキュリティ要約を採用する。

例えば次のようなリポジトリがある。

Repository
|
+-- auth/
|   +-- login.py
|   +-- session.py
|   +-- oauth.py
|
+-- database/
|   +-- sql.py
|   +-- models.py
|
+-- api/

まずファイル単位で要約を作る。

login.py   -> summary
session.py -> summary
oauth.py   -> summary

次にディレクトリ単位でまとめる。

auth/
-> authentication subsystem
-> OAuth
-> session management
-> privilege boundary

さらにリポジトリ全体を上位要約する。

Root summary
+-- Authentication
+-- Database
+-- API
+-- External interfaces

AIはまず要約で全体像を把握し、怪しい箇所だけ原文コードを読む。

Googleによると、この方式で重要な構造情報を保持しながら、リポジトリ文脈を与える際のトークンオーバーヘッドを85%以上削減できた。

ただし、これは

LLM利用料金全体が85%削減される

という意味ではない。

より正確には、

巨大リポジトリをAIへ理解させるためのコンテキスト投入オーバーヘッドを85%以上削減

という意味である。

7. Mantisの核心はLLMではなくHarness

Mantisで特に重要なのは、LLM自身に全体の行動順序を自由に決めさせない設計である。

危険な設計は次のようになる。

LLM
"次に何をするか自分で決める"
        |
        v
自由行動

Mantisでは、より決定論的に流れを制御する。

Harness
   |
   v
Research
   |
   v
Review
   |
   v
Reproduce
   |
   v
Patch
   |
   v
Verify

つまり、LLMは各工程の知的処理を担当するが、工程順序そのものはプログラム側で制御する。

これはAIエージェントの暴走や意図しない行動を抑えるうえで重要な考え方である。

8. AIエージェント暴走問題との関係

AIエージェントでは、

• 指示外の行動
• サンドボックス逸脱
• 外部システムへのアクセス
• ゴール達成のための迂回
• 想定外ツール実行

などが問題になる。

Mantisはセキュリティ検査のためにPoCコードや修正コードを生成し、実際に動かす。

そのためGoogleは、AI生成コードを本番環境や内部ネットワークへアクセス可能な場所で実行しないよう強く警告している。

Mantisは防御ツールである一方、

AI Security Agent自体も危険なプログラムになり得る

という前提で設計されている。

9. Mantisのdual-useリスク

Mantisの能力は防御にも攻撃にも使える。

防御側では、

Repository
   |
   v
Vulnerability Discovery
   |
   v
PoC
   |
   v
Patch

となる。

しかし攻撃側なら、

Repository
   |
   v
Vulnerability Discovery
   |
   v
PoC
   |
   v
Exploit

となる。

つまり、脆弱性の自動発見・再現能力はそのまま攻撃自動化にも利用可能である。

Google自身も、人間のセキュリティ専門家による確認、隔離環境、明確な脆弱性判定基準を推奨している。

10. SASTの次に来るものか

従来のSASTは、

SAST
  |
  v
Warning
  |
  v
Human Review
  |
  v
Patch

という流れだった。

Mantis型では、

Agentic Security
  |
  v
Discovery
  |
  v
Critic
  |
  v
Reproduction
  |
  v
Patch
  |
  v
Verification
  |
  v
Human Approval

へ進む。

これは単なる「セキュリティスキャナー」の高度化ではない。

Security ScannerからSecurity Engineer Agentへの進化

と見る方が適切である。

11. DevSecOpsはどう変わるか

現在の一般的な流れは、

Developer
   |
   v
CI
   |
   v
SAST
   |
   v
Security Team
   |
   v
Patch

である。

今後は、

Developer
   |
   v
AI Coding Agent
   |
   v
Mantis-like Security Agent
   |
   v
PoC Verification
   |
   v
Automatic Patch
   |
   v
CI
   |
   v
Human Approval

という形へ近づく可能性がある。

さらにMantisには「mantis-advise」があり、過去に見つけた脆弱性や修正方法を、コードを書く段階の助言へフィードバックすることを狙っている。

最終的には、

脆弱性を後から探す

より、

最初から脆弱性を作らせない

方向へ発展する可能性がある。

12. CGTAが見る重要ポイント

Mantisのニュースでは「トークン85%以上削減」が目を引く。

しかし技術的な重要度は次の順と考える。

核心は、

AIを「答える機械」から「実験して証明する機械」へ変えている

ことである。

13. 5段階シナリオ分析：2030年前後

以下は推測であり、Mantisそのものではなく「Mantis型Agentic Security」の普及シナリオである。

CGTAの中心シナリオはS4である。

14. 最終評価

Mantisは、

AIにコードを読ませて脆弱性を聞く技術

ではない。

より正確には、

AI Security Engineerチームをソフトウェア化する試み

である。

大きな流れとしては、

Human Coding
   |
   v
AI Coding
   |
   v
AI Review
   |
   v
AI Attack Simulation
   |
   v
AI Patch
   |
   v
AI Verification

へ進んでいる。

ここまで進めば、ソフトウェア開発は、

AIが作り、AIが攻撃し、AIが修正する閉ループ

へ近づく。

Mantisは、その方向性を明確に示した重要な事例である。

なおGoogleは、Mantisを内部リポジトリで使い、実際の脆弱性を発見したとしている一方、現時点では検出件数、precision、recall、false positive rateなどの包括的benchmarkは公開していない。

この部分は未確認であり、Mantisの実運用性能を数値的に断定することはできない。

略語・専門用語解説用語集

出典

1. Google Cloud Blog

"Getting started with the Mantis harness to find and fix bugs" https://cloud.google.com/blog/products/identity-security/getting-started-with-the-mantis-harness-to-find-and-fix-bugs

1. Google Mantis GitHub Repository

README https://github.com/google/mantis

1. Google Mantis Agent Reference

README_AGENTS.md https://github.com/google/mantis/blob/main/README_AGENTS.md

1. Google Mantis Pipeline Adapter

SKILL.md https://github.com/google/mantis/blob/main/mantis-pipeline-adapter/SKILL.md

1. GIGAZINE

"Googleが脆弱性の発見・再現・修正を自動化するオープンソースフレームワーク「Mantis」の詳細を公開、巨大リポジトリでもトークンのオーバーヘッドを85％超削減" 2026-09-03

Fact Checkメモ

• MantisがGoogleからオープンソースで公開されていること：確認済み。
• 脆弱性候補の発見・検証・再現・修正を複数工程で処理すること：確認済み。
• 粗いAIコードスキャンで真陽性率7%未満となる場合があるとのGoogleの記載：確認済み。
• 階層型要約でトークンオーバーヘッドを85%以上削減したとのGoogleの説明：確認済み。
• Googleが本番環境や内部ネットワークから隔離した環境での実行を推奨していること：確認済み。
• Mantisの包括的なprecision、recall、false positive rate、検出件数：現時点で十分な公開benchmarkは確認できず、未確認。
• 将来シナリオの出現確率：CGTAによる推測値であり、実測値ではない。