Googleの脆弱性検証を自動化する「Mantis」、トークン使用量を85％超削減
検出から修正までを分離して処理
AIによるコード解析では、存在しない脆弱性を報告するハルシネーションが問題になる。GIGAZINEの記事では、精度の低いAIコードスキャンの場合、検出結果のうち実際に脆弱性だった割合である真陽性率が7％未満になる場合があると、Googleが指摘している。
Mantisは、単一のAIモデルに判定を任せる構成ではない。まず脆弱性の候補を探し、その後に複数のAIエージェントが候補をレビューする。批判的に検証するエージェントが、問題の成立条件や悪用可能性を確認する設計である。
次の段階では、隔離されたサンドボックス環境で脆弱性の再現を試みる。実際に問題を確認できた場合に限り、修正コードの作成へ進む。検出、検証、再現、修正を分けることで、候補の大量出力をそのまま脆弱性として扱うリスクを下げている。
この構成は、Laravelアプリケーションのように依存関係やミドルウェアが多いコードベースを扱う際にも考え方を適用しやすい。重要なのは、AIの指摘を結論ではなく、再現テストへ渡す入力として扱うことである。
大規模リポジトリ向けの要約方式
大規模リポジトリでは、全ソースコードをAIモデルへ一度に渡すと入力トークン数が増える。処理負荷が上がるだけでなく、必要なコードへ到達するまでの計算量も膨らむ。
Mantisは、ファイル単位の情報をディレクトリ単位でまとめ、さらにリポジトリ全体の要約へ積み上げる階層型のセキュリティ要約を採用する。AIは最初に全体構造を要約から把握し、詳細が必要な箇所だけソースコードを確認する。
Googleによれば、この方式は重要な構造情報を維持しながら、トークンのオーバーヘッドを85％超削減できる。すべてのコードを均等に読むのではなく、概要から対象範囲を絞り込む。検索対象を段階的に縮小する設計であり、セキュリティ解析におけるボトルネックを入力サイズから探索効率へ移すアプローチといえる。
また、Mantisは解析前にリポジトリの変更履歴を調査する。過去に修正された脆弱性やセキュリティ上の問題を収集し、ソースコードの構造も解析する。その情報をもとに、攻撃される可能性がある場所や保護すべき対象をまとめた脅威モデルなどを自動構築する。
設計資料や脅威モデルが整備されていない個人開発プロジェクトでは、この前処理が実務上の意味を持つ。AIへ単に「脆弱性を探せ」と指示するのではなく、変更履歴と構造情報を調査対象へ含めることで、解析時の前提条件を増やせるためである。
個人開発で確認すべき運用上の境界
Mantisは、Gemini CLIやAntigravity CLIから利用できる。GitHubから取得したMantisの場所と調査対象のコードをAIコーディングエージェントへ指定し、解析を開始する構成である。過去の脆弱性や修正方法を開発時の助言に利用する「mantis-advise」も用意されている。
ただし、AIが生成した脆弱性報告や修正コードが常に正しいわけではない。Googleは、セキュリティ専門家による手作業の確認を求めている。さらに、AIが生成したコードなどは、本番システムや内部ネットワークから隔離された環境で実行する必要があるとしている。
Laravel・PHP開発で導入を検討する場合、最初に確認すべき点は導入可否そのものではない。次の依存関係を分離できるかである。
- 対象リポジトリと本番環境を接続しない
- AIが生成した修正を直接デプロイしない
- 脆弱性の成立条件を再現テストで確認する
- 脆弱性と判断する基準を事前に定義する
- 変更履歴と設計上の前提を解析対象へ渡す
Mantisの価値は、AIが自動で修正コードを書くことだけではない。候補の発見から再現、修正案の作成までを複数の段階へ分割し、各段階で人間が検証できる状態を作る点にある。
- 改善点：巨大リポジトリでトークンのオーバーヘッドを85％超削減
- 構成上の特徴：複数エージェントによるレビューとサンドボックス再現
- 注意点：報告と修正コードは専門家の確認が必要
- 運用上の境界：本番環境や内部ネットワークから隔離して実行する
AIによるセキュリティ解析を導入する場合、検出数よりも誤検出をどの段階で排除できるかがボトルネックになる。Mantisは、その検証工程をフレームワークとして構造化する試みである。