AIに脆弱性の修正まで任せる企業が知っておきたいOSS「Mantis」の使いどころ

「AIに自社のコードを読ませて、脆弱性を探して直すところまで任せられないか」「AIが出した脆弱性の報告が多すぎて、どれが本物か見分けられない」——開発部門とセキュリティ部門の間に立つ、情報システムや品質管理の担当者から聞こえてくる声です。AIで脆弱性を探す話は、検出の精度の問題に見えがちです。しかし本当の論点は精度だけではありません。AIが自分で書いたコードを自分で動かす以上、どこで動かし、誰が結果を確かめるかを企業が決めているかどうかが分かれ目です。この記事では、Googleが公開したOSS「Mantis」を取り上げ、何ができるのか、なぜ隔離された環境が前提とされるのか、企業が導入前に決めておきたい範囲を、一次情報に基づいて整理します。導入や設定の手順は扱いません。

Mantisとは何か。2026年10月時点で確かめられる事実

Mantisは、GitHubで公開されているOSSです。リポジトリの説明では、AIのコーディングエージェントが脆弱性を自律的に見つけ、再現し、修正するための道具一式とされています。特定の言語や開発の仕組みに縛られない、部品を組み替えられる構成だと説明されています。

配布の形を確かめておきます。リポジトリはGoogleの組織アカウントで2026年6月15日に作られ、ライセンスはApache-2.0です。2026年10月20日時点でスターは2,474、フォークは227、最後の更新は10月17日でした。正式な版の公開はまだありません。Googleのクラウド部門の公式ブログでは、2026年9月3日に、Googleのセキュリティ技術者2人の名前で紹介記事が出ています。

ただし、READMEの末尾にはGoogleが公式にサポートする製品ではないと書かれています。実証を目的としたもので、本番の環境での利用は想定していないとも明記されています。また、Googleのオープンソース向けの脆弱性報奨金の対象外とされています。Googleの名前で出ていることと、製品として保証されていることは別です

なぜ今、AIに脆弱性の発見から修正まで任せる動きが出てきたのか

公式ブログは、背景を率直に書いています。AIのモデルは、人の手をほとんど借りずに脆弱性を見つけ、悪用する力をすでに示している。だからこそ、守る側がAIで先に手を打てるように、脆弱性の発見、仕分け、再現、修正を自動でつなげる仕組みを作った、という説明です。

同じブログは、雑なAIによるコードの検査では存在しない問題がでっち上げられ、本物を当てる割合が7%を下回ることも多いと指摘しています。この数字は一般的なAIの検査について述べたもので、Mantis自身の成績ではありません。Mantisは、批判役や見直し役のエージェントと、隔離した環境での再現を組み合わせることで、根拠のある結果に絞ることを狙ったとされています。

企業にとっての意味は二つあります。一つは、攻撃する側もAIで脆弱性を探す前提に立つと、守る側も同じ速さで探して直す手段が要るということです。もう一つは、AIの検査結果が増えるほど、本物を見分けて直す人の負担が増えるということです。Mantisは、この二つ目の負担を減らそうとする試みとして読むと位置づけが分かりやすくなります。

主な機能1：過去の修正と脅威の想定から、どこを探すかを決める

READMEによると、Mantisはいきなりすべてのファイルを調べるのではなく、まずコードの変更履歴を見て、過去に直した脆弱性を洗い出します。同じ種類の過ちを繰り返さないための手がかりとして使う、という考え方です。

次に、コード全体を効率よく見て回るための索引や要約を作り、脅威モデル（どこに信頼の境目があり、誰がどこから攻めてくるかを整理したもの）を自動で作るとされています。その上で、個々のエージェントに調べさせる仮説を立て、調べる計画を作ります。公式ブログは、ファイルの要約をフォルダごと、全体ごとに積み上げる仕組みで、AIに読ませる量を85%以上減らしたと述べています。これは提供元の説明で、条件は示されていません。

補足の文書には、履歴、索引、構成の把握、脅威モデル、計画、調査、重複の整理、誤検知の除外、実際の配布物で成り立つかの確認、再現、組み合わせ、修正、評価、振り返り、報告という段階が並んでいます。段階ごとに役割を分け、前の段階の結果を次が使う作りで、一度の調査で終わらず繰り返すことも想定されています。

主な機能2：見つけた問題を再現し、修正が効くかを確かめる

Mantisの特徴は、見つけた問題を文章で報告するだけで終わらない点です。READMEは、使える環境に応じて、攻撃が成り立つかの机上の見立てから、単体の試験、さらに模擬のサーバーを立ち上げて試すところまで、再現の深さを変えると説明しています。この再現の段階で、AIが書いたコードが実際に動きます。

修正の段階では、修正案を作ったあとに、別のエージェントがその修正を攻めて、本当に直ったかを確かめる仕組みだとされています。補足の文書では、確かめられた、対策を提案した、確認しきれなかった、といった状態で結果を分けるとされます。また、確かめ済みの問題同士を組み合わせて、より影響の大きい攻撃の流れにならないかも調べるとしています。

ここで注意したいのは、READMEが自ら限界を書いていることです。自動で再現できなかったからといって誤検知とは限らず、再現できたからといって、どんな状況でも悪用できるとは限らないとしています。再現の成否は、判断の材料であって結論ではありません

主な機能3：重大度の水増しを抑える評価と、学びの蓄積

AIに脆弱性を探させると、どれも重大だと言いがちになる問題があります。READMEは、定めた基準ですべての結果を評価し直し、AIが重大度を大げさに見積もる傾向を抑えると説明しています。数千件の「重大」を並べるのではなく、本当に危ないものを人の目に届けるのが狙いです。

補足の文書によると、評価は影響、証拠、成り立つ見込みをもとに、1から10の点数で付けるとされます。ただし、点数の細かな基準は公開されていません。READMEは、評価の基準を自社の環境と許容できる危険の度合いに合わせて調整するよう強く勧めています。軽微な問題や守りを固めるための指摘も、誤検知として捨てるべきではないとされています。

もう一つの特徴は、調査のたびに学んだことを振り返り、知識としてためる点です。ためた脅威モデルや過去の発見をもとに、開発中に同じ過ちを繰り返さないよう助言する機能もあるとされています。見つけて直すだけでなく、次に書くコードに生かすところまでを一つの流れにしようとしています。

READMEによると、調べた結果から学んだことは、調べた対象のリポジトリの中に知識として書き出し、次の調査で読み戻せるとされています。補足の文書は、最後の段階で人が読める形の報告書をまとめるとしています。ためた知識そのものが、自社の弱点の一覧になる点にも注意が要ります。どこに保管し、誰が読めるかは、脆弱性の情報と同じ扱いで決めるべきです。

想定される使い方と使う場面

Mantisは、AIのコーディングエージェントが必要に応じて読み込む手順書（スキル）の集まりと、それを順番に動かす参考実装の二つで成り立つとREADMEは説明します。参考実装はGoogleのエージェント開発の仕組みで作られていますが、ほかの仕組みに移し替えてもよいとされています。補足の文書は、GeminiやAntigravityのコマンドラインの道具などで使えると書いています。

READMEは、Mantisを決まった手順書ではなく出発点として扱い、自社の技術の組み合わせに合わせて調整・拡張するよう求めています。補足の文書は、半導体の設計記述、設定をコードで書く基盤、機械学習のデータ処理、ソースのない組み込みの配布物など、専門の分野にも合わせて使い回せるとしています。

社内の文書やコーディングの規約、ビルドの仕組みを脅威モデルに取り込むことも勧められています。公式ブログも、人がまとめた知識を加えると結果の質が大きく上がると述べ、利用者が自分の作ったプログラムを自分で止められるだけの問題は対象から外す、といった例を挙げています。自社の前提を教えるほど、結果は役に立つものになります

似た手段と比べた違い

脆弱性を探す方法はほかにもあります。ここでは、一次情報で確かめられる範囲で、従来の手段との違いを整理します。表は方向づけのためのもので、成績を比べたものではありません。

観点	決まった規則で調べる従来の静的解析	人による診断	Mantis
探し方	決まった規則に当てはまる箇所を探す	経験をもとに怪しい箇所を探す	履歴と脅威モデルから仮説を立て、AIが調べる
再現	通常は行わない	必要に応じて人が行う	隔離した環境でAIが再現用のコードを作って動かす
修正	通常は提案まで	開発者が直す	AIが修正案を作り、別のエージェントが攻めて確かめる
動かす場所の危険	比較的小さい	診断の手順で管理する	AIが書いたコードが動くため、隔離が前提
結果の扱い	誤検知の確認が要る	診断者が責任を持つ	専門家が必ず確かめてから扱う

表から分かるとおり、Mantisは従来の静的解析に置き換わるものというより、仮説を立てる、再現する、直すという人の作業の一部をAIに渡すものです。その分、動かす場所の危険と、結果を確かめる責任が新しく生まれます。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを、公開されている事実だけをもとに精査しています。OSSをダウンロードしたり動かしたりはしていません。Mantisの判定は「注意付き」です。

問題がないと言える事実もあります。Googleの組織アカウントは2012年に作られ、公開リポジトリは2,900件を超えます。スターの伸びは1日あたり20件ほどで、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、リポジトリの直下に、取り込み時に自動で動く処理を含むファイルは見当たりませんでした。

それでも注意付きとしたのは、README自身が、自律的に生成したコードを実行する道具であり、不安定な動きや予期しない動作をしうると強く警告しているからです。隔離され、制限された環境でだけ使うよう求めています。加えて、実証用で本番向けではないこと、変更提案を自動で調べる機能が実際の開発で試されていないことも明記されています。なお、ここで問題が見つからなかった点があっても、安全の保証ではありません。この精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

READMEが求める隔離と、人を介さずに動かすときの条件

READMEは冒頭で、自己責任で、細心の注意を払って使うよう求め、本番の設備、機密データ、社内ネットワークに届く端末では決して動かさないよう警告しています。さらに、最先端のモデルを使う場合は、付属の隔離の例にとどまらず、抜け出そうとする動きを強く監視する隔離の層をもう一つ重ねるよう勧めています。

補足の文書は、隔離の選択肢として、コードを動かさない読み取りだけの方式、軽量な隔離の仕組み、小さな仮想の機械、使い捨てのクラウド上の仮想の機械を挙げ、ネットワークにつながない実行を勧めています。人を介さずに動かす場合は、外部のインターネットにつながないか許可した先だけに絞ること、権限を最小にしたサービス用の利用者、追記だけができて履歴が残る保管先などを厳格な条件としています。

注目すべきは、無人で動かす形では、操作の確認を自動で承認する設定を使うと書かれている点です。補足の文書は、信頼できないコードの上でAIが命令を組み立てる以上、読み込んだコードに紛れ込んだ指示でAIが操られる危険が大きな論点になると認めています。手順書の変更は人が承認するよう求めているのも、その対策の一つとされています。

変更提案を自動で調べる機能は、まだ試験前という点

Mantisには、開発の変更提案ごとに変わったファイルを調べ、通してよい、見直しが要る、止めるべき、の三つで判定を返す仕組みも含まれています。ただしREADMEは、この機能は模擬の環境でしか動かしておらず、実際の開発で通しで試していないと警告しています。合流の可否をこの機能で決めないよう求めています。

説明の文書によると、この仕組みは既定では警告を出すだけで、検査が失敗しても合流は止まらない作りです。長く使える鍵をリポジトリに置かずにAIのサービスへ接続し、費用の上限を一回ごと、一日ごとに設けるとされます。一方で、文書自身が、攻撃者が手を加えうる入力を読みながら、モデルを使う権限を持っていることを認め、紛れ込んだ指示で判定が左右されうるため、人の確認を残すとしています。

外部から寄せられた変更提案には権限を渡さず、調べないとされています。また、変更提案に含まれる自動処理の設定はそのまま動くため、実行の前に承認者を置くことは任意ではないと強調しています。費用の上限についても、権限の統制ではなく費用の統制だと明記しています。企業が開発の流れに組み込むかを考えるときは、この「まだ試験前」という位置づけを前提にする必要があります。

悪用されうるリスク

Mantisは守る側のために作られたものですが、使い方しだいで生まれうる危険があります。最も直接的なのは、隔離が不十分な環境で動かしたときに、AIが生成した再現用のコードが、意図しない範囲に影響を与えることです。READMEが本番の設備や社内ネットワークに届く端末での利用を禁じているのは、この危険を前提にしたものです。

次に、推測であることを断ったうえで挙げます。脆弱性を見つけて再現し、複数の問題を組み合わせる機能は、守る側だけでなく、他人のコードの弱点を探す目的にも転用されうると考えられます。公式ブログが、AIはすでに人の手を借りずに脆弱性を見つけて悪用できると書いているとおり、同じ種類の能力が攻撃する側の手にもある前提で守りを考えるほうが現実的です。

もう一つは、確かめていない結果をそのまま外に出す危険です。READMEは、AIが生成した確認前の報告を、オープンソースの開発者に大量に送らないよう求めています。自社の名前で誤った報告を大量に出せば、相手の負担になるだけでなく、自社の信用にも響きます。なお、本記事の執筆時点で、Mantisの悪用事例は一次情報からは確認できませんでした。

導入を検討するときに確かめること

導入の検討では、機能の多さより先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めによって確かめられることに絞っています。

この手順の要は、道具を動かす前に、動かす場所と確かめる人を決めておくことです。Mantisは調整して使うことを前提にした出発点であり、決め事のないまま使い始めると、結果の山と隔離の不備の両方を抱えることになります。

企業が取るべき対策

五つの対策を挙げます。一つ目は、AIに再現用のコードを動かさせる道具を、社内規程上の扱いを決めた対象として明示することです。通常の開発の道具とは別に、隔離の条件と承認の流れを決めます。二つ目は、隔離した環境の点検です。ネットワークの出口、使う権限、記録の残し方を、導入前と定期的に確かめます。

三つ目は、記録を残すことです。補足の文書が、追記だけができて履歴が残る保管先を条件に挙げているとおり、AIが何を動かし、何を見つけ、何を直そうとしたかを後からたどれるようにします。誰の承認で、どの環境で、何が動いたかを説明できる状態にします四つ目は、紛れ込んだ指示への備えです。調べる対象のコードは信頼できない入力として扱い、AIが読む手順書の変更は人が承認します。

五つ目は、外への報告の統制です。社外のオープンソースに問題を報告する場合は、専門家の確認を経たものだけを、相手の報告の窓口と作法に沿って出します。AIの結果を自社の名前で出すかどうかは、人が判断します。あわせて、配布元、ライセンス、更新の状況、公式の製品ではないことを、調達の記録に残しておきます。

AIに任せる範囲と、人が決める範囲

Mantisは、仮説を立て、調べ、再現し、直すところまでをAIに任せる設計です。AIのモデルは毎回同じ答えを出すとは限らず、存在しない問題を挙げたり、誤った修正を作ったりすることがあるとREADMEは書いています。どこで動かすか、何を調べるか、どの結果を本物とみなすかは、AIに決めさせず人が先に決めます。AIには、判断の根拠として、再現の結果や確かめた範囲を書かせます。

やってはいけない向き合い方を挙げます。

• 本番の設備や社内ネットワークに届く端末で、そのまま動かす
• AIが「重大」と判定した結果を、専門家の確認を経ずに社内外へ報告する
• AIが作った修正案を、開発者の見直しなしに取り込む
• 変更提案を自動で調べる機能の判定で、合流の可否を決める
• 自社が権利を持たないコードを、許可なく調べる
• 再現できなかった問題を、それだけで誤検知として捨てる

裏を返せば、人が決める範囲ははっきりしています。動かす場所、調べる対象、結果を本物とみなす基準、外に出すかどうか、の四つですAIに任せてよいのは、人が決めた範囲の中で、候補を探し、再現を試み、修正案を出す部分です。

公開された数字と、確かめられていないこと

公式ブログには、二つの数字が出てきます。一つは、雑なAIの検査で本物を当てる割合が7%を下回ることが多い、という一般論です。もう一つは、要約を積み上げる仕組みでAIに読ませる量を85%以上減らした、というMantisの工夫についての説明です。Mantis自身が本物の脆弱性をどれだけの割合で当てるかは、公表されていません。

公式ブログは、Google社内の多くのリポジトリで実際の脆弱性を見つけるのに使ったとも書いていますが、件数などの数字は示していません。報道や紹介の記事では公開の時期やスターの数が食い違うものもあり、紹介記事の数字ではなく、リポジトリと公式の文書で確かめますという姿勢が必要です。

自社で使うかを判断するときは、すでに原因が分かっている過去の脆弱性を含むコードを、隔離した環境で調べさせ、見つかるか、誤った報告がどれだけ出るかを確かめる方法が考えられます。提供元の説明を出発点にしつつ、自社のコードと基準で確かめてから使う範囲を広げます。確かめた結果は、見つかった件数だけでなく、専門家が確認に使った時間や、誤った報告の割合もあわせて記録しておくと、続けるかどうかの判断材料になります。AIの検査は結果の数が増えやすいため、人の確認にかかる手間まで含めて効果を見ることが大切です。

• Mantisの機能・構成・警告の内容は、GitHubのリポジトリとREADME、補足の文書、公式ブログを2026年10月20日に確かめた範囲に基づきます。開発が続いており、内容は変わる可能性があります
• 変更提案を自動で調べる機能は、README自身が実際の開発で通しで試していないと明記しています
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Mantisは、AIのコーディングエージェントに、脆弱性の発見、再現、修正、評価までを自律的に進めさせるためのOSSです。過去の修正と脅威モデルから探す場所を決め、隔離した環境で再現し、修正が効くかを別のエージェントに確かめさせ、重大度の水増しを抑える評価を加える構成です。Googleの組織アカウントからApache-2.0で公開されていますが、公式にサポートされた製品ではなく、実証用とされています。

一方で、AIが生成したコードを自律的に動かす道具である以上、動かす場所を誤れば自社の設備に影響が及びえます。結果には誤りが混ざり、変更提案を自動で調べる機能はまだ試験前です。どこで動かすか、何を調べるか、誰が結果を確かめるか、外に何を出すか。これらは道具ではなく、企業が先に決めることです。

守る側がAIで脆弱性を探して直す流れは、今後広がっていくと考えられます。そのときに問われるのは、AIの速さを生かしながら、隔離と人の確認という土台を崩さないことです。Mantisは、その土台をどう作るかを考える材料としても読めるOSSです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。