Google Mantis：AIによるバグ発見を実用化するために必要なこと

まず押さえる要点：AIセキュリティには検証ループが必要

Google Cloudが紹介したMantisは、AIを使ったアプリケーションセキュリティが向かう方向を示す例です。モデルにリポジトリをスキャンさせて疑わしい箇所を大量に返すのではなく、Mantisは脆弱性の発見、トリアージ、再現、重複排除、パッチ検証を調整するハーネスとして説明されています。重要なのは、エージェントがセキュリティエンジニアを置き換えることではありません。リポジトリの履歴、脅威モデル、隔離された実行環境、再利用できるツール、修正が効いたかを判定するテストを持つことで、エージェントが役立つという考え方です。

開発者がツールを選ぶときの基準も変わります。最も多く警告を出す製品ではなく、疑わしいコードを再現可能な問題、レビューできるパッチ、回帰が消えた証拠へつなげられる製品が有用です。

Mantisが解決しようとしている問題

Google CloudのMantis紹介では、MantisをAIエージェントでバグを見つけて修正するオープンソースのハーネスとして説明しています。Mantisのリポジトリには、セキュリティ分析のためのワークフローやスキルも含まれています。つまり、エージェントは空のチャット画面ではなく、構造化された環境で作業します。

セキュリティの発見は、単なる文章生成ではありません。機能がどのように変化したかを調べ、入力の信頼境界を特定し、小さな概念実証を作り、サンドボックスでテストを実行し、候補パッチと元の挙動を比較し、重複した報告を整理する必要があります。コードを説明できるモデルでも、悪用可能性を証明したり、修正が別の経路を壊していないことを確認したりできるとは限りません。

リポジトリ履歴と脅威モデルの意味

静的スキャンが見るのは現在のコードです。リポジトリ履歴を使えるエージェントは、権限チェックがなぜ追加されたのか、どの入力が危険と考えられたのか、以前の修正が不完全ではなかったかも確認できます。この文脈は誤検知を減らし、実際の境界に影響する変更を優先する助けになります。

脅威モデルでは、誰が入力を制御するのか、攻撃者がどこまで到達できるのか、どのIDやデータが影響を受けるのか、成功した攻撃で何が変わるのかを考えます。これがなければ、エージェントは珍しいパターンをすべて重大と判定したり、単独では普通に見えるコードにある問題を見逃したりします。

だからこそ、AIセキュリティツールは自信のあるスコアだけでなく証拠を示すべきです。対象ファイル、前提、再現手順、想定される影響、分析の限界を示せば、チームは修正、補完的な対策、対応不要のどれを選ぶか判断できます。

再現できるかが分かれ目になる

エージェント型セキュリティの価値は、安全な方法で問題を再現しようとする点にあります。サンドボックスなら、ネットワーク、認証情報、ファイルシステム、破壊的なコマンドを制限しながら、狭い仮説をテストできます。単なるパターン一致より具体的な結果になります。

再現はコミュニケーションも改善します。開発者は小さなテストケースを確認でき、レビュアーは信頼境界を越えたかを見られ、リリース担当者は修正後にも同じテストが通ることを要求できます。会話の外でも使える成果物が残ります。

AIセキュリティツールを選ぶ前の確認項目

導入前に、次の境界を確認しましょう。

1. 権限： シークレットの読み取り、プロダクションブランチへの書き込み、外部サービスの呼び出しが可能か。
2. 隔離： 再現が使い捨て環境で行われ、ネットワークとファイルの方針が明確か。
3. 証拠： 発見がコード、テスト、ログ、再現手順に結び付いているか。
4. 復旧： 人が一時停止、ロールバック、パッチ拒否をできるか。
5. データ： リポジトリやプロンプト、生成パッチの保持と学習利用が明記されているか。

コード支援、スキャナー、テストツールを比較するなら、BTTCソフトウェアディレクトリで権限、連携、エクスポート、レビュー機能を確認してください。実用的な技術解説はBTTCブログにもあります。

実際の導入で設計すべき境界

Mantisのような仕組みを実際の開発環境に導入する場合、スキャンを開始する前に作業の境界を決める必要があります。最初から全リポジトリ、すべての資格情報、無制限のネットワークを渡すのではなく、読み取り専用の複製と限定されたテスト環境から始める方が安全です。エージェントが作成したファイル、実行したコマンド、呼び出した外部サービスは記録し、レビュー担当者が後から追跡できるようにします。

優先順位も重要です。まずは入力検証、認証、認可、シークレット処理など、結果を比較的確認しやすい領域を選びます。小さな対象で再現性が確認できたら、複雑な依存関係や本番に近い設定へ広げます。この段階的な導入なら、ツールの精度だけでなく、チームが証拠をレビューし、誤検知を修正し、修正後のテストを維持できるかも評価できます。

セキュリティの自動化では、速さよりも停止条件が大切です。高い権限が必要な操作、外部への送信、データ削除、設定変更は、エージェントが説明を返しても人の承認を要求するべきです。自動化の範囲を狭く保つことは能力を制限するためではなく、失敗したときに影響を理解し、元に戻せるようにするためです。

よくある質問：エージェントとアプリケーションセキュリティ

AIエージェントはセキュリティエンジニアを置き換えられますか？

いいえ。調査や証拠整理は速くできますが、リスク、前提、変更承認、本番環境の判断には人が必要です。

再現できたバグは必ず重大な脆弱性ですか？

いいえ。深刻度は公開範囲、攻撃者の制御、影響を受ける資産、必要な権限、業務影響によって変わります。

エージェントにパッチを自動マージさせるべきですか？

通常は初期設定で許可すべきではありません。提案パッチと回帰テストを作らせ、人的レビューと独立した確認を通す方が安全です。

まとめ

Google Mantisは、AI支援セキュリティのより信頼できる形を示しています。エージェントが文脈を集め、限定した仮説を試し、レビュー可能な証拠を残し、管理された範囲で修正を検証する形です。開発者ツールを評価するときは、問題を安全に証明して解決できるか、それともレビュー対象のリストを増やすだけかを確認することが大切です。