google/mantis を導入前に読む: セキュリティレビュー用スキルの実態と境界
A modular, stack-agnostic toolkit of security review skills for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.
ひと目でわかる
- これは何？
- AIコーディングエージェントに脆弱性の発見、再現、パッチ作成を順番に実行させるスキル群である。READMEが示すのは万能のスキャナではなく、サンドボックス前提の出発点という位置づけだ。
- 誰に向いている？
- Mantis が向くのは、すでにコンテナやVMで隔離された開発環境を持ち、そこでAIエージェントを動かしているチームだ。隔離環境を用意できず、生成コードをホスト上で走らせるしかない状況では使うべきではない。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Mantis が埋めようとしている穴は「レビューの順番」である
静的解析ツールは候補を大量に出すが、その候補が実際に悪用できるかどうかまでは面倒を見ない。Mantis はこの工程を、コーディングエージェントが順番に実行するスキルの並びとして定義する。対象はソフトウェアとハードウェアの両方で、README は Hardware/RTL、Infrastructure as Code、ML パイプライン、コンパイル済みファームウェアといった領域への適応にも触れている。読み手として想定されているのは、自社スタック向けにプロンプトと手順を調整する余力のあるアプリケーションセキュリティ担当者や DevSecOps の担当者だ。完成品のスキャナを入れるのではなく、レビューの型を自組織向けに組み立てるための素材として配布されている。
スキルは逐次パイプラインで、段の間には契約がある
Mantis は decoupled かつ sequential なスキル群だと README は説明する。エージェントは /mantis-plan で計画を立て、その後 /mantis-reproduce と /mantis-patch に進む。各段の間には inter-stage contracts があり、その詳細は README_AGENTS.md の Agent Reference Guide に分離されている。つまり本体の README は導線であり、パイプラインの入出力仕様は別ファイルを読まないと分からない構成だ。この分割自体は妥当だが、導入検討時に最初に読むべき文書が README ではないという点は覚えておきたい。スキルの実体は Python リポジトリとして配布され、ライセンスは Apache-2.0 である。
導入は npx skills add の一行から始まる
インストールはグローバルまたはワークスペース単位のどちらでもよく、CLI からは次の一行で入る。
npx skills add google/mantis
リポジトリを clone してからコーディングエージェントに「このスキルを使ってコードベースをレビューしたい」と伝える方法も README は案内している。前提として Docker が挙げられ、信頼できないAI生成の再現コードを走らせる場合は gVisor の runsc を登録する。README が示すコマンドは sudo runsc install -- --network=none && sudo systemctl restart docker で、あるいは /etc/docker/daemon.json に runtimes として runsc を追加し、runtimeArgs に --network=none を書く。クラウドのサンドボックスをリモートで使う場合は、対応する Cloud SDK が必要になる。
最初は --yolo を付けずにスラッシュコマンドを1つずつ打つ
README は入門者向けに Interactive Mode を強く勧めている。エージェントを通常の開発フローで起動し、/mantis-plan のようなスラッシュコマンドを個別に打つ。--yolo や --dangerously-skip-permissions のような自動承認フラグは、影響をよく検討しない限り使うなと明記されている。/mantis-reproduce や /mantis-patch がファイルに書き込んだりコードを実行したりする前に、人間の承認を挟ませるのがこのモードの狙いだ。自動で回したい場合、README は「strong boundaries を実装することが条件」だと述べる。ここは運用設計の話であり、フラグを外せば安全になるという話ではない。
再現とパッチはコンテナ内実行が指示されているが、保証はない
/mantis-reproduce と /mantis-patch は、ペイロードをネットワーク無効の隔離コンテナ内で実行するよう指示されている。ただし README 自身が、AIエージェントは非決定的であり、この手順を飛ばしたり、環境が許せば意図した制約を回避しようとしたりすることがあると明記している。したがって、この指示は安全の証明ではなく、多層防御の一层にすぎない。README が繰り返し述べる結論は、専用の隔離VMで動かすことだ。ホスト上で生成コードを走らせるなという no host-run の原則は、スキルの指示内容ではなく利用者の責任として書かれている。
誤検知はレビュー段のネガティブフィルタで削る
AIベースのスキャンは誤検知を出す。Mantis はこれをレビュー段で negative rules によって濾す設計だと README は説明し、/mantis-review のネガティブ検証フィルタを自社コードベースに合わせて書き換えるよう求めている。同時に、再現に失敗したからといって誤検知と断定はできず、再現に成功したからといってあらゆる文脈で悪用可能とは限らない、とも書かれている。この両方向の留保は重要だ。フィルタを緩めればノイズが増え、厳しくすれば本物を取りこぼす。README が「Day 1 にリポジトリ全体を走らせるな、狭い範囲から始めろ」と述べるのは、この調整に時間がかかるからである。
モデルは段ごとに使い分ける前提で書かれている
README は、すべての段で最も重いフロンティアモデルを使う必要はないとし、AI model class とタスクを戦略的に対応させるよう勧めている。具体的な対応表は README_AGENTS.md の Model Selection の節に置かれている。これはコストの話であると同時に、速度の話でもある。計画立案のような推論寄りの段と、パッチ生成のようなコード生成寄りの段では、要求される能力が違う。ただし README は特定のモデルや CLI を推奨していない。Gemini CLI と Antigravity CLI で使った実績に触れつつ、any coding agent framework should work という立場を取っている。
万能のSASTとして導入すると期待を裏切られる
Mantis は既存の SAST を置き換えるものではない。ルールベースの静的解析は決定的で、CI に組み込みやすく、同じ入力に同じ出力を返す。Mantis はその逆で、非決定的なモデルに発見と再現を委ねる。README が「starting point rather than a rigid set of instructions」と書くのは謙遜ではなく、そのまま導入して終わりにはならないという意味だ。向かないのは、CI のたびに再現性のある結果が必要なチーム、出力を人手で検証する体制がないチーム、そして隔離環境を用意できないチームである。逆に向くのは、隔離されたVMやコンテナの中でエージェントをすでに走らせており、プロンプトとフィルタを自社向けに調整する担当者を割けるチームだ。Apache-2.0 なので改変と再配布は許されるが、生成されたパッチやレポートの扱いについては、法務ではなく社内のポリシー側で決めておく必要がある。
編集部の結論
Mantis が向くのは、すでにコンテナやVMで隔離された開発環境を持ち、そこでAIエージェントを動かしているチームだ。隔離環境を用意できず、生成コードをホスト上で走らせるしかない状況では使うべきではない。導入前に確認するのは、/mantis-review のネガティブフィルタを自社コードベース向けに書き換えられるか、gVisor の runsc を --network=none で登録できるか、そして発見事項を検証するセキュリティ担当者を確保できるかの3点である。このいずれかが欠けるなら、パイプライン全体を回す前に /mantis-plan だけを狭い範囲で試すべきだ。
コミュニティノート