AIによるコードレビューで脆弱性の候補が大量に見つかっても、そのまま修正作業に移れるとは限りません。実際に攻撃が成立するのか、同じ問題を重複して報告していないか、修正後も別の経路から悪用されないかを確かめる必要があります。開発現場にとっての負担は、問題の発見だけでなく、報告を検証して対応の優先順位を決める過程にもあります。

Googleがオープンソースとして公開したMantisは、この検証までをAIコーディングエージェントの作業に組み込むツールキットです。疑わしい欠陥を探し、誤検知を取り除き、隔離環境で不具合を再現します。その後、必要最小限のパッチを作成し、修正済みのコードに再び攻撃を試みて、残るリスクを評価する構成です。



注目すべき点は、AIの説明がもっともらしいかどうかではなく、再現と修正後の検証を判断の根拠に据えていることです。脆弱性らしいコードを指摘する能力と、現実に成立する問題を示す能力は同じではありません。企業が修正に人員を割くには、影響を受ける条件や確認できた挙動まで把握したいところでしょう。

Googleは、単純なAIコードスキャンでは真陽性率が7％未満にとどまることを、Mantisが取り組む課題として挙げています。ただし、この数値を自社の環境にも当てはまる普遍的な精度と受け取るべきではありません。入力コードや評価条件で結果は変わりますし、Mantis自体の達成精度を示す数字でもありません。導入を考える際の中心的な問いは、検出件数が増えるかよりも、開発者が確認する価値のある報告に絞り込めるかです。

Mantisは、リポジトリを指定すれば単独で診断が完了するスキャナーではありません。既存のAIコーディングエージェントが読み込む「スキル」の集合です。ここでいうスキルは、特定の作業を進めるための指示や手順をまとめたもので、利用者はスラッシュから始まるコマンドを通じて各工程を呼び出します。

各スキルは独立したディレクトリとして公開され、順番につないで実行する設計です。全体を継続的なセッションで進めるための監督役として、`/mantis-meta-agent`も用意されています。調査、再現、修正、報告という役割が分かれているため、どの工程で何を確認するのかを追いやすい構造といえるでしょう。



利用先として挙げられているのは、Gemini CLI、Antigravity CLI、Google ADK、および同等のエージェントフレームワークです。CLIはコマンドラインから操作するインターフェース、ADKはエージェントを開発するためのツール群を指します。Mantisは特定の技術スタックを前提としない設計ですが、それだけで、どのリポジトリでも同じ設定のまま動くことを保証するものではありません。実際の評価では、対象のビルド方法や検証環境に合わせた準備が必要になります。

企業の視点では、既存の開発エージェントにセキュリティレビューの手順を追加する仕組みとして捉えると理解しやすくなります。モデルを呼び出すだけでなく、コードをどこで実行してよいかという厳格なルールも構成要素です。利用するモデルの性能と、実行環境の制御を分けて検討する必要があります。なお、MantisはGoogleがサポートする製品ではなく、公開されたツールキットです。この位置づけは、社内の運用担当や障害時の対応範囲を決めるうえでも押さえておきたい点です。

Mantisの初期工程は、すぐに怪しいコードを列挙する作業ではありません。`/mantis-history`がバージョン管理履歴から過去のセキュリティ修正を調べ、`/mantis-summarize`がディレクトリの対応関係を整理します。`/mantis-architecture`は構造に関する知識をMarkdown形式で蓄積し、後続の調査が参照できる土台を作る役割です。

続く`/mantis-threat-model`では信頼境界を導き、`/mantis-plan`が対象を絞った調査計画を作成します。信頼境界とは、外部からの入力を内部処理に渡す場所や、異なる権限の処理が接する場所など、相手の情報や操作をどこまで信用するかが変わる境目です。個々のコード片だけでは見えにくい、攻撃の入口と重要な処理のつながりを考えるための概念と理解するとよいでしょう。



計画に沿ってファイルを調べるのが`/mantis-researcher`です。その後、`/mantis-dedupe`、`/mantis-review`、`/mantis-critic`が重複をまとめ、問題として扱わない条件を適用し、リリース用ビルドでは発生しない指摘を除外します。開発用のコードに危険そうな記述があることと、利用者に提供するソフトウェアで攻撃が成立することを分けて判断する工程です。

Googleによると、階層的な要約ツリーによってトークンのオーバーヘッドを85％超削減できるとしています。トークンは、モデルが文章やコードを処理する際の単位です。大きなコードベースの情報を階層的に整理する考え方は、調査に必要な文脈を扱ううえで意味があります。ただし、この数字をレビュー全体の料金や所要時間が同率で減るという意味に読み替えることはできません。企業で確認したいのは、情報量を抑えながら、重要な依存関係や攻撃条件を取りこぼさずに調査できるかです。

候補の絞り込みを終えると、Mantisは問題を実行によって確かめる工程に進みます。`/mantis-reproduce`は、ネットワークを無効にしたgVisorまたは仮想マシン内で、攻撃用の入力やコードを実行します。gVisorはアプリケーションの実行を隔離するための技術です。仮想マシンも含め、ここでは対象コードを通常の作業環境から切り離して動かす役割を担います。

この工程が確かめるのは、危険そうに見える処理に対して、想定した条件で実際に問題が起きるかです。コードの読み取りだけでは、入力の制約や実行時の状態を見落とす場合があります。再現結果があれば、開発者は説明文だけでなく、確認に使った条件と挙動を手がかりに修正を検討できるでしょう。



`/mantis-chain`は、個別に確認できた問題から複数段階の攻撃経路を組み立てます。単体では限定的な影響しか見えなくても、別の問題と組み合わさることで影響が変わる可能性を検討する工程です。`/mantis-patch`は修正を適用して検証し、修正済みのコードへの再攻撃も通じて、対処が機能しているかを確かめます。

その後、`/mantis-calibrate`が1〜10のリスクスコアを付け、`/mantis-reflect`が次回の調査に向けた学びを書き戻し、`/mantis-report`が人間の読めるレビュー資料を作成する流れです。ただし、再攻撃で問題が再現しなくなっても、すべての攻撃経路がなくなったという証明にはなりません。検証した条件と、まだ検証していない範囲を区別する必要があります。リスクスコアも、自社サービスの公開範囲や扱う情報の性質と合わせて読むべき判断材料です。Mantisの価値は、人の判断を不要にすることより、その判断を支える証拠を整える点にあります。

Mantisは、各工程が受け渡す情報や満たすべき条件を定めた取り決めも公開しています。これにより、企業はスキルの実行順序や条件を、決まったルールで動く制御プログラムに組み込めます。AIエージェントが自律的に作業する場合でも、どの段階へ進んでよいかを外側の仕組みで管理できる設計です。

セキュリティレビューでは、調査対象のコードを読むことと、そのコードや攻撃用の入力を実行することでは、必要な管理が異なります。工程が明確に分かれていれば、読み取り中心の調査と隔離環境での検証を別の扱いにしやすくなります。これは導入時の設計上の示唆であり、Mantisを読み込むだけで社内規程に沿った運用が完成するわけではありません。



企業が評価する際には、再現結果を修正担当者に渡せるか、パッチと検証結果の対応を追えるか、途中で失敗した工程を把握できるかを確認するとよいでしょう。検出数だけを成果指標にすると、確認の手間が増えた状態を改善と見誤るおそれがあります。人間が報告を理解し、修正の要否を判断するまでの負担も含めて評価することが必要です。

こうした設計は、AIセキュリティツールの比較軸にも示唆を与えます。説明が詳しいか、数多くの候補を出せるかに加えて、根拠を再確認できるか、実行範囲を制御できるかが選定の論点になります。とりわけ複数の開発チームで共通運用する場合は、モデルの出力だけでなく、工程の受け渡しを一定に保てることに意味があるでしょう。ただし、公開された取り決めがあることと、自社の既存システムに簡単に接続できることは別です。評価では、スキル自体の動作に加えて、周辺の制御や記録にどの程度の実装が必要かも見積もりたいところです。

MantisはApache 2.0ライセンスで公開されており、ローカル環境や社内での評価に利用できます。ただし、現段階で本番運用は推奨されていません。公開コードを入手して試せることと、継続的な業務運用に必要な成熟度やサポートが備わっていることは、分けて判断する必要があります。

日本企業が試す場合、評価対象を限定し、結果を人が照合できる課題から始める方法が考えられます。例えば、社内で修正済みの脆弱性について、修正前後のコードを安全に扱える環境を用意し、問題の発見、再現、修正確認までを追う進め方です。これは導入評価の一案であり、Mantisの性能について確認された実績を示すものではありません。



確認したいのは、既知の問題を見つけたかだけではありません。誤検知の除外理由が妥当か、再現条件が開発者に伝わるか、提案パッチが必要な範囲に収まるか、修正後の検証が同じ問題を適切に確認しているかも判断材料です。自社の対象コードで一連の証拠を追えるかどうかが、運用の検討につながります。

新しいスキルの`/mantis-advise`は、この流れをコードを書く前にも広げます。蓄積した脅威モデル、過去の不具合の系統、検証済みの修正パターンを参照し、同種の欠陥を再び持ち込まないよう助言する仕組みです。修正の記録を、その後の設計や実装に役立てる方向性が見えてきます。ただし、助言の有用性を判断するにも、蓄積された情報が対象の開発に合っているかを確かめる必要があるでしょう。最初の一歩として、過去の修正を一件選び、発見から再攻撃までの報告を担当者が追えるかを確認してみると、導入価値を具体的に判断しやすくなります。