AIエージェントを使う企業が知っておきたい点検用OSS「AI-Infra-Guard」の使いどころ

「社内で作ったAIエージェントやMCPサーバーが増えてきたが、誰がどう安全を確かめているのか分からない」「外部から取り込んだスキルや、社内に立てた推論サーバーに既知の弱点が残っていないか、まとめて調べる方法はないのか」——AIの社内展開を任された情報システム部門やセキュリティ部門からは、こうした相談が増えています。多くの場合、答えは強力な点検の道具を一つ入れることだと考えられがちです。しかし本当に先に決めるべきなのは、誰が、どの範囲を、どの権限で点検し、結果を誰が判断するのかという運用の枠組みです。この記事では、テンセントのセキュリティ研究チームが公開したOSS「AI-Infra-Guard」を取り上げ、何を点検できるのか、点検の道具そのものにどんな注意が要るのか、企業が使う前に決めておくべき点を、自社のAI環境を守る立場から整理します。導入や操作の手順、試験の中身は扱いません。

AI-Infra-Guardとは何か。2026年10月時点で確かめられる事実

AI-Infra-Guardは、GitHubで公開されているOSSで、略称はAIGです。リポジトリの説明は「エージェント、スキル、MCP、AI基盤の点検と、言語モデルの脱獄評価を通じてAIの環境を守る、総合的なAIの赤チーム基盤」というものです。日本語版のREADMEでは、目指す姿を「AIセキュリティリスクの自己診断において最も包括的でインテリジェント、かつ使いやすいソリューション」と表現しています。つまり、自社のAI環境の危うさを、自社で洗い出すための道具という位置づけです。

公開元を確かめます。リポジトリは2016年4月に作られたTencentの組織アカウントの下にあり、この組織は公開リポジトリを303件持っています。READMEによると、開発を率いるのはテンセントのセキュリティ部門に属する研究チームのZhuque Labです。リポジトリは2024年12月25日に作られ、ライセンスはApache-2.0です。このラインが精査した2026年10月19日時点で、スターは6,906、派生は670でした。

開発は活発です。最後の更新は10月18日で、リリースの一覧によると、確認した時点の最新は10月15日の4.6.6版でした。8月下旬から10月にかけて、ほぼ毎週のように新しい版が出ています。READMEによると、本ソフトは2025年のブラックハット・ヨーロッパ（セキュリティ分野の国際会議）の道具の展示枠で発表されています。また、本ソフトを引用した外部の論文が19本挙げられており、研究の場でも参照されている道具であることがうかがえます。

なぜ今、AI環境をまとめて点検する道具が求められているのか

企業のAI利用は、チャットの画面で質問する段階から、社内のデータや業務の道具につないだエージェントを動かす段階へ移りつつあります。そうなると、守るべき対象が一気に増えます。推論を動かすサーバー、画像生成やワークフローの基盤、エージェントの開発基盤、エージェントに道具を渡すMCPサーバー、外部から取り込むスキル。どれもそれぞれ別の弱点を抱え、別の担当者が管理していることが多いはずです。

従来の脆弱性の点検の道具は、ウェブサーバーや業務システムを主な対象にしてきました。一方、AIの部品には、モデルの配信ソフトや生成の基盤のように新しく出てきたものが多く、既知の弱点の情報も急速に増えています。さらにMCPサーバーやスキルには、コードの弱点だけでなく、道具の説明文にまぎれた不正な指示のような、従来の点検では見落としやすい種類の危険があります。

AI-Infra-Guardは、こうした散らばった点検を一つの画面に集めることを狙っています。READMEは、AI基盤の点検、MCPサーバーとスキルの点検、エージェントの点検、脱獄評価を一つの基盤に統合していると説明しています。AIの部品ごとに別々の道具を探して比べる手間を減らし、自社のAI環境の全体を同じ物差しで棚卸しするための選択肢の一つと言えます。

点検できる範囲の全体像

READMEと各機能の説明資料で確かめられた点検の範囲を、表にまとめます。ここでの整理は「何を点検できるか」に限ります。試験の中身や操作の方法は書きません。

機能	点検の対象	主に見るもの	防御側での使い道
AI基盤の点検	稼働中のAIの部品（推論サーバー、生成やワークフローの基盤など）	部品の種類と版を見分け、既知の弱点（CVE）に当たるか	社内に立てたAIの部品の棚卸しと、更新漏れの発見
MCPサーバーとスキルの点検	MCPサーバーやスキルのソースコード、または稼働中のMCPサーバー	秘密情報の露出、権限の広げすぎ、道具の説明への不正な指示など	取り込む前の審査と、社内で作ったものの見直し
エージェントの点検	稼働中のエージェントの応答の窓口	権限のすり抜け、情報の漏れ、外部の文書を経由した指示の乗っ取りなど	公開前のエージェントの評価
脱獄評価	利用するモデルのAPI	安全のための制限がどこまで保たれるか	業務に使うモデルを選ぶときの比較の材料
モデルと中継APIの確認	利用しているモデルのAPIや中継サービス	モデルのすり替えや、裏口の仕込みの危険	調達したAPIが説明どおりかの確認
OpenClawの点検	OpenClawという自前で動かすAIエージェントの環境	危うい設定、スキルの危険、既知の弱点、個人情報の漏れ	社員が使うエージェント環境の見直し

表のとおり、対象はAIの部品から、部品をつなぐ道具、その上で動くエージェント、背後のモデルまで及びます。どの機能も、自社が管理している、または点検を許されている対象に向けて使うことが前提です。次の節から、企業の守りに関わりの深い機能を順に見ていきます。

AI基盤の既知の弱点を探す機能

AI基盤の点検は、稼働しているAIの部品の住所を指定して、その部品が何で、どの版かを見分け、既知の弱点に当たるかを調べる機能です。日本語版のREADMEによると、見分けられる部品は100種類を超え、既知の弱点の規則は2,000件を超えます。例としてOllama、ComfyUI、vLLM、n8nなどが挙げられています。対象はソースコードではなく、いま動いているサービスの住所です。

規則は頻繁に足されています。9月17日の4.6.2版では、40種類を超えるAIの部品について155件の新しい規則が加わったとREADMEにあります。AIの部品は版の更新が速く、弱点の公表も相次いでいます。点検の規則が追いついているかどうかは、この種の道具の価値を左右します。週ごとに規則が更新されている点は、新しい部品の弱点を早めに拾える可能性を示しています。

企業での使い道として分かりやすいのは、部署ごとに勝手に立てられたAIの部品の棚卸しです。検証のつもりで立てた推論サーバーや、ワークフローの基盤が、更新されないまま社内の網に残っていることは珍しくありません。一方で、住所の範囲をまとめて指定できる作りでもあるため、点検してよい範囲を文書で決めてから使うことが欠かせません。範囲を誤れば、他部署や取引先の設備に点検の通信を送ってしまうおそれがあります。

MCPサーバーとスキルを取り込む前の点検

MCPサーバーとスキルの点検は、エージェントに道具や手順を渡す部品の危うさを調べる機能です。READMEによると、ソースコードか遠隔の住所を入力にして、14の分類の危険を点検します。MCPの点検の説明資料には、秘密情報の露出、権限の広げすぎ、道具の説明文への不正な指示の仕込み、供給網を経由した攻撃、命令の注入、認証や認可の不足、監査の記録の欠如、管理外のMCPサーバーなどの分類が並んでいます。

点検には、ソースコードを読む静的な点検と、稼働中のMCPサーバーに接続して振る舞いを確かめる動的な点検があります。スキルについては、説明書きと実際のコードが食い違っていないかを照らし合わせる点検も用意されています。スキルの点検は単独の道具としても公開されており、判定は「悪意あり」「疑わしい」「問題なし」の三段階です。結果は、コードの置き場の点検画面に取り込める共通の形式で書き出せると説明されています。

企業にとっての使いどころは、外部のMCPサーバーやスキルを社内に取り込む前の審査です。社員が便利だと思って入れた部品が、裏で情報を外へ送る作りになっていないかを、取り込む前に一度ふるいにかける工程を作れます。ただし、この点検の判定は言語モデルが担う部分が大きく、後の節で触れるように、結果をそのまま合否にしない運用が要ります。

稼働中のエージェントを外から確かめる機能

エージェントの点検は、稼働しているエージェントの応答の窓口に外から問いかけ、危うい振る舞いがないかを確かめる機能です。説明資料では「稼働中のAIエージェントの基盤に向けた、動的なブラックボックスの点検の道具」とされています。対応先としてDifyやCozeのほか、一般的なAPIの窓口が挙げられています。

点検の分類は、OWASPがまとめたエージェントの危険の分類に沿っています。説明資料には、権限のすり抜け、情報の漏れ、外部の文書を経由した指示の乗っ取り、道具の悪用、ウェブを経由した情報の持ち出し、予期しないコードの実行、エージェント同士のやり取りの安全などの10の分類が載っており、既定で動くのはそのうち5つとされています。結果は、深刻度とOWASPの分類を付けた報告として出ます。

社内向けのエージェントを公開する前に、こうした分類で一度点検しておくことには意味があります。開発した担当者は、自分が想定した使い方でしか試さないことが多いからです。ただし、この機能は攻撃者のふるまいを模して問いかける試験です。本番のエージェントに向けると、実際の業務データや外部への連絡の道具に影響が出る可能性があります。検証用の環境で動かすこと、業務の担当者に事前に知らせることを前提にすべきでしょう。

モデルの耐性評価と中継APIの確認は、選定の材料として

脱獄評価は、利用するモデルが安全のための制限をどこまで保てるかを確かめる機能です。READMEによると、用意された試験の材料と複数の手法でモデルの耐性を試し、モデル同士を比べられます。この機能は攻撃の手口を模すものなので、この記事では中身には立ち入りません。防御側にとって押さえておくべきなのは、業務に使うモデルを選ぶときの比較の材料になるという点です。

もう一つ、8月26日の4.6.0版で加わったのが、モデルのAPIの確認です。READMEによると、外から複数の問いを投げて、モデルのすり替えや裏口の仕込みの危険を調べるとされています。安価な中継サービスを経由してモデルを使う場合、本当に契約したモデルが応答しているのかは利用者から見えにくいものです。調達の確認の一つとして、こうした点検の考え方は参考になります。

どちらの機能も、評価に使うモデルのAPIの鍵を道具に登録する必要があります。READMEでは、脱獄評価の設定で対象のモデルの住所と鍵を入れる作りが示されています。業務用の鍵をそのまま使うと、試験の通信が業務の利用と混ざり、費用や利用規約の面でも問題になりえます。評価専用の鍵を用意し、使い終わったら止めるという扱いが妥当です。

点検の担い手もAIであることの意味

AI-Infra-Guardの点検の多くは、言語モデルが担っています。MCPの点検の説明資料によると、点検役のエージェントは利用者が選んだモデルで動き、情報の収集、コードの点検、弱点の見直しの三段階で進みます。スキルの点検も、言語モデルがファイルを読みながら判定する作りです。つまり、点検の結果そのものが、AIの判断を含んでいるということです。

公開元もこの点を意識しています。9月17日の4.6.2版では、スキルの点検で根拠のない誤検知を減らしたとREADMEにあります。READMEには、複数のモデルでスキルの点検の正確さを比べた結果も載っていますが、これは公開元が用意した評価の材料での数値です。自社が取り込む部品で同じ正確さが出るとは限らず、見逃しも誤検知も起こりうる前提で扱う必要があります。

もう一つ見落としやすいのが、点検の対象がどこへ送られるかです。スキルの点検の説明資料では、言語モデルが道具を使ってファイルを読む作りになっており、外部のモデルのAPIを使う場合は、点検するソースコードの内容が外部のモデルに渡る可能性があります。何が送られるかは資料で明確に書かれていませんでした。社外秘のコードを点検するなら、使うモデルの提供元と、送ってよい情報の範囲を先に決めておく必要があります。

企業での使いどころ：三つの場面

一つ目は、社内のAIの部品の棚卸しです。部署ごとに立てた推論サーバーやワークフローの基盤を洗い出し、既知の弱点に当たる版が残っていないかを確かめます。点検の道具は、情報システム部門が管理する点検用の機械に置き、点検の範囲を決めた住所だけに向けるのが基本です。結果は、各部品の管理者に修正を依頼する材料として使います。

二つ目は、外部のMCPサーバーやスキルを取り込むときの審査です。社員から利用の申請があったとき、取り込む前に点検にかけ、「疑わしい」と出たものは人が中身を確かめてから判断します。これを申請の手続きに組み込めば、誰が何をいつ入れたかの記録と、点検の結果が一緒に残るようになります。

三つ目は、社内向けのエージェントを公開する前の評価です。検証用の環境に置いたエージェントに対して、権限のすり抜けや情報の漏れの分類で点検し、見つかった問題を開発の担当者に返します。どの場面でも共通するのは、点検の結果を最終的な合否にせず、人が判断するための材料の一つとして扱うことです。

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

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。AI-Infra-Guardの判定は「注意付き」です。

問題の少なさを示す事実から挙げます。運営は2016年に作られたTencentの公式の組織アカウントで、公開リポジトリは303件あります。ライセンスはApache-2.0です。スターの伸びは1日あたり約10.4件で、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下にはコンテナを組み立てるための定義ファイルがありますが、利用者が自分で組み立てるもので、取り込んだだけで自動的に動く処理ではありません。

それでも「注意付き」としたのは、本ソフトが脱獄評価など攻撃を模した試験の機能を含む、守りにも攻めにも使える両用の赤チーム基盤だからです。点検してよい範囲を決めずに使えば、他者の設備への無断の試験になりえます。また、後の節で触れるとおり、ログインの仕組みを持たない作りです。なお、勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

導入前に知っておきたい注意点

第一に、認証がない点です。日本語版のREADMEは「現在、認証メカニズムがないため、パブリックネットワークにデプロイすべきではありません」と明記し、企業や個人の内部での利用を想定しているとしています。セキュリティ方針の文書でも、本ソフトは一人の運用者が使う道具で、利用者のアカウントもログインも権限の区別もなく、画面に届く人は誰でも運用者として扱われると説明されています。

第二に、守りの責任の線引きです。方針の文書によると、画面は既定では自分の機械からしか届かない設定ですが、コンテナで動かすと外から届く口が開くため、防火壁や網の分離、認証を加える中継の仕組みで絞るよう勧めています。そして、認証なしで公開の網にさらすことは運用者の設定の誤りとして扱い、弱点の報告の対象外としています。複数の利用者の間の権限の問題も対象外です。置き方の守りは、導入する側の責任になります。

第三に、点検の道具が抱える情報の重さです。モデルのAPIの鍵、点検した部品の一覧と弱点の結果、取り込んだソースコードが一か所に集まります。方針の文書は、鍵を保護された場所に置き、規則の更新の窓口を信頼できる運用者に限るよう求めています。また、4.5.2版では、動的なMCPの点検で、点検対象からの不正な指示によって点検する側の機械で命令が実行されることを防ぐ修正が入ったとリリースノートにあります。点検の道具も攻撃の的になりうることを示す例です。

第四に、帰属の表示の決まりです。READMEは、配布するときに許諾の文書と通知の文書を残すこと、製品に組み込む場合は説明書などに帰属の表示を入れることを求め、出所を示さずに自社の製品として再包装することを禁じています。社内での利用だけなら影響は小さいものの、点検の結果を顧客向けの報告に使う場合などは、表示の決まりを確かめておく必要があります。また、上位版は招待の番号が要るとされており、無料で使えるのは公開されている版の範囲です。

悪用されうるリスク

AI-Infra-Guardは、自社のAI環境の危うさを自社で調べるための道具です。それでも、攻撃を模した試験を含む以上、使い方しだいで生まれる危険はあります。最も分かりやすいのは、点検を許されていない他者のAIサービスに向けて試験を行うことです。住所の範囲をまとめて指定できる作りは、使い方を誤れば無断の調査になりえます。

次に挙げるのは推測ですが、検討の材料になります。点検の道具には、社内のAIの部品の一覧と、それぞれの弱点の結果が蓄積されます。認証のない画面に社内の誰でも届く状態なら、社内のどこに弱い部品があるかを示す地図を、意図しない人にも見せることになります。悪意のある内部の人や、社内の端末に入り込んだ攻撃者にとって、価値のある情報になる可能性があります。

もう一つは、点検の対象から点検する側への逆流です。方針の文書は、点検の対象と言語モデルの応答を「信頼しない入力」として扱うと書いています。実際に、点検対象からの不正な指示を通じた命令の実行を防ぐ修正が入ってきました。怪しいMCPサーバーやスキルを点検するときは、点検用の機械を業務の網から切り離しておくのが安全側の考え方です。なお、本ソフトが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

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

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、点検の範囲と、点検の道具そのものの守りを同時に決めることです。どちらかが欠けると、守りのための点検が、かえって新しい危険の入口になります。

企業が取るべき対策

一つ目は、AIの部品の台帳づくりです。AI-Infra-Guardを使うかどうかにかかわらず、社内で動いている推論サーバー、ワークフローの基盤、MCPサーバー、スキル、エージェントを一覧にし、管理者と版を記録します。何があるか分からないものは点検できないからです。点検の道具は、この台帳を確かめる手段の一つにすぎません。

二つ目は、取り込みの審査の手続きです。外部のMCPサーバーやスキルを社内で使う前に、点検にかけ、結果と判断を記録に残す流れを社内規程に書き込みます。三つ目は、点検の許可の決まりです。誰が、どの対象を、いつ点検してよいかを事前に承認する仕組みを作ります。攻撃を模した試験を含む道具を、担当者の判断だけで自由に使える状態にはしないことが大切です。

四つ目は、点検の道具そのものの守りです。置き場所、届く人、鍵の保管、結果の保管を決め、点検用の機械を業務の網から分けます。五つ目は、調達のときの確認です。勧告の有無、弱点の報告の窓口、受領の目安（方針の文書では5営業日以内）、帰属の表示の決まりを確かめ、社内で使える段階かどうかを文書で判断します。

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

AI-Infra-Guardは、AIの安全をAIの力も借りて点検する道具です。点検役の言語モデルが、コードを読み、危うさを判定し、報告を書きます。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どの対象を点検してよいか、点検の結果を受けてどの部品を止めるか、どのスキルの取り込みを認めるか、点検の道具に誰が触れてよいか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。点検役のモデルには、判定ごとにどのファイルのどの部分を根拠にしたかを書かせ、人が確認する範囲を先に決めておくと、見逃しや誤検知に気づきやすくなります。やってはいけない向き合い方を挙げます。

• 点検の結果が「問題なし」だったことを理由に、外部のスキルを人の確認なしで全社に配る
• 認証のない点検の画面を、社内の誰でも届く網に置いたままにする
• 点検してよい範囲を決めずに、住所の範囲をまとめて指定して点検する
• 業務用のモデルの鍵を点検の道具に登録し、使い終えても残したままにする
• 社外秘のソースコードを、送り先を確かめないまま外部のモデルで点検する
• 攻撃を模した試験を、本番のエージェントに業務の担当者へ知らせず実施する

裏を返せば、人が決める範囲ははっきりしています。何を点検し、誰が触れ、どの結果で何を止め、どこまでを外に送るか。この四つが決まっていないまま点検の道具を入れても、守りの厚みは増えません。

よくある質問：無料の点検道具を入れれば、AIの安全確認は足りるのか

答えは「それだけでは足りない」です。AI-Infra-Guardが見られるのは、既知の弱点の規則に当たるもの、点検の分類に沿って見つけられるもの、言語モデルが気づけたものです。未知の弱点や、業務の流れの中でしか表れない問題、点検の対象に入れなかった部品は見つかりません。点検の結果は、その時点、その範囲での手がかりにとどまります。

では入れる意味がないのかというと、そうではありません。AIの部品の既知の弱点をまとめて調べられること、MCPサーバーやスキルを取り込む前にふるいにかけられること、エージェントを公開前に分類に沿って点検できることは、守りの抜けを減らす助けになります。公開元が大手の研究チームで、規則が週ごとに更新されている点も、継続して使う上での安心材料です。

もう一つ、「攻撃を模した機能を含む道具を社内で使ってよいのか」という問いもありそうです。自社が管理する対象に、許可された担当者が、決められた範囲で使う限り、点検の道具として使えます。ただし、使う人と対象と記録の決まりを先に作り、担当者の判断だけで動かせる状態にはしないことが条件です。

• AI-Infra-Guardの機能・版・注意点は、GitHubのリポジトリとREADME（英語版と日本語版）、セキュリティ方針の文書、リリースの一覧、各機能の説明資料を2026年10月19日に確かめた範囲に基づきます。版の更新が速いため、内容は変わる可能性があります
• 点検の正確さを示す数値は公開元が用意した評価の材料でのもので、自社の環境で同じ結果になるとは限りません。点検の際に外部のモデルへ送られる情報の範囲は、確認した資料では明確に書かれていませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、攻撃を模した試験の中身は扱いません

まとめ

AI-Infra-Guardは、テンセントのセキュリティ研究チームが公開した、AI環境をまとめて点検するOSSです。AI基盤の既知の弱点、MCPサーバーとスキルの危うさ、稼働中のエージェントの振る舞い、モデルの耐性や中継APIのすり替えの危険まで、一つの基盤で調べられます。Apache-2.0で公開され、規則は週ごとに更新されています。GitHub上にセキュリティ勧告は登録されていません。

一方で、攻撃を模した試験を含む両用の道具であり、ログインの仕組みを持たず、判定の多くを言語モデルが担います。点検してよい範囲、点検の道具の置き場所と触れる人、結果の確かめ方は、道具ではなく人が決める範囲です。点検の範囲と道具の守りを先に決め、AIの判定を人が確かめる形で使うことが、AIエージェントやMCPを社内に広げる企業にとってのAI-Infra-Guardの使いどころです。

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