GoogleのMantisを実機で試した——AI脆弱性スキャナーの「導入しない」という結論の作り方

■ 界隈で話題のMantis

最近、AIエージェントの界隈で話題になっているのが、Googleが出したMantisだ。

GitHubのstarは1758つほど。セキュリティの脆弱性スキャンを、LLMのパイプラインで自動で行うというツールだ。ただ、releaseは1つも出ていない。つまり、製品として出荷されたものではなく、Googleが研究目的で公開したプロトタイプという位置づけだ。

僕はこれを、自分の環境で実際に動かして検証した。この記事は、その実測の記録だ。

■ Mantisとは何か

Mantisは、対象のソースコードをLLMに読み込ませ、脆弱性を検出・報告・修正まで行うAIエージェントだ。

特徴は、単発の「LLMに脆弱性を見ろ」という呼び出しではなく、人間のセキュリティレビューの工程をそのまま機械化した11ノードのパイプラインで構成されていることだ。

・history（履歴解析）

・structural_index（構造解析）

・planner（計画）

・threat_modeler（脅威モデリング）

・researcher（脆弱性検出）

・deduplicator（重複排除）

・reviewer（レビュー）

・reviewer_classifier（誤検知分類）

・calibrator（較正）

・reflector（振り返り）

・reporter（報告生成）

検出するだけではない。重複排除、レビュー、誤検知の分類、較正、という工程が並ぶ。これは、人間のセキュリティレビュアーがやることを分解して、各工程をLLMに割り当てた設計だ。

■ パイプラインの巧妙さ——見習うべき設計

このパイプラインの巧妙さは、見習うべきだと思う。

128行の小さなファイルでも、MantisはOS Command Injectionを6件検出した。しかも、単に「ここが危ない」と言うのではなく、ユーザー入力がどこから来て、どのsink（危険な関数）に到達するのか、というsourceからsinkへの追跡まで、証拠付きで報告する。

さらに、レビュー工程で「確認できる到達可能な脆弱性主張が1件も無かった」と判定して、誤検知を排除する。過検出しない設計だ。

人間のレビュー工程を分解してLLMパイプラインに落とし込む、という発想そのものが、AIエージェント設計の教科書になると思う。

■ 僕が実機で走らせたとき——犯人はMantisではなかった

ここで、僕が実際に動かしたときの顛末を書く。

僕はMantisを、無料のfable-distillというLLMで動かした。すると、脆弱性検出はうまくいったのに、最後に「findingsをデータベースに保存できない」というエラーで落ちた。

エラーは本物だった。ログに cannot access local variable 'findings' というUnboundLocalErrorが載っていた。

最初の推測は「Mantis本体のバグだ」というものだった。ただ、ここで一度立ち止まった。有名なプロジェクトに、そんな自明なバグがあれば、issueに報告されているはずだ。GitHubのissueを検索したら、該当は0件だった。

ここから、前提の認識を疑い直した。

犯人を確定させるために、Mantisのコードにtrace行を仕込んで、実際に report_findings 関数に何が渡るかを観測した。結果、渡ってきたのはJSONの文字列だった。本来オブジェクトであるべき値が、文字列のまま渡っていた。

原因はこうだった。fable-distillは、ツール呼び出しの引数で、オブジェクトであるべき値を稀に「JSON文字列（二重エンコード）」で返す癖がある。一方、Mantisが使うADKというフレームワークは、引数の外側だけをパースして、中身のネストされた値は再パースしない。だから、二重エンコードされた文字列がそのまま関数に到達して、落ちた。

つまり、犯人はMantis本体でも、ADKでもなかった。fable-distillの癖と、ADKの設計が組み合わさって起きた互換性の問題だった。

■ Gemini前提——LLMによっては改造を要する

ここで、Mantisの設計の本質が見えてくる。

Mantisは、Geminiを前提に設計されている。Geminiは引数を正しい形で返すから、この経路は発現しない。だからGitHubに騒ぎがなかったのだ。

つまり、Mantisは「Geminiで動けば完璧、でも他のLLMでは改造を要する」という設計だ。

僕はfable-distillで動かしたかったので、2つの回避策を実装した。

・シム: ADKとfable-distillの境界に薄い正規化層を挟み、二重エンコードされた文字列をオブジェクトに戻す。Mantis本体もADKのソースも1行も触らない。

・リトライ: スキャンが失敗したら、外側から最大2回まで再実行するラッパー。

この2つを組み合わせることで、Mantis本体に手を触れずにfable-distillで動かすことに成功した。

■ 導入の是非——オンデマンド限定で残す

では、Mantisを常設に導入すべきか。僕の結論は「しない」だ。ただし、オンデマンドで使える経路は残す。

理由は3つある。

・トークン消費が桁違い: 1ファイルのスキャンで10万〜45万トークン。検出される脆弱性の数によって大きく変わる。毎日回す常設ツールとしては非効率すぎる。

・スタックがパッチワーク: シム、リトライ、確率的な癖の吸収、という3層の回避策の上に乗っている。Geminiなら1層も要らないが、無料経路で回す以上はこれが許容範囲。

・成熟度が0 release: releaseが1つも無い。常設に組み込むと、upstreamの破壊的変更に晒され続ける。

ただし、経路は検証済みで再利用可能だ。「このコードをスキャンしてくれ」と言ったとき、venvの再構築に数分、スキャンに1〜2分で結果が出る。これは実用的な価値がある。

だから、裁定はこうなる。常設にはしない。オンデマンドで使う経路として残す。もし「コードの脆弱性スキャンを定期的に回したい」という必要が生まれた瞬間、この裁定は覆る。そのときは、課金OKならGemini経路（パッチワーク不要）を第一候補にする。

■ まとめ

Mantisは、Googleが内部で使っているセキュリティレビューの工程を、研究目的で公開したプロトタイプだ。工程設計は本物で、人間のレビューをLLMパイプラインとして具現化している点は見習うべきだ。

ただ、「製品として導入する」段階ではない。Gemini前提の設計ゆえに、他のLLMで動かすには改造が要る。僕の裁定は、常設にはせず、オンデマンド経路として残す、というものだ。

AIエージェントを試すとき、大事なのは「すごいな」で終わらせないことだ。実機で走らせて、犯人を確定し、導入の是非を自分の環境の制約に対して裁定する。その過程こそが、技術の位置づけを正確に捉える方法だと思う。

#Mantis #Google #AIエージェント #脆弱性スキャン #LLM #セキュリティ #fable_distill #ADK