AIエージェントの出荷前に攻撃への耐性を試したい企業が知っておきたいOSS「Argus」の使いどころ

「社内の問い合わせや経費の処理をAIエージェントに任せる仕組みが、来月から本番に入る。道具を呼び出し、文書を読み、ときには支払いまで扱うのに、攻撃への耐性を誰も測っていない」「監査やガバナンスの担当から、どの基準に照らして何を試したのかを説明できる形で出してほしいと言われている」——AIエージェントを自社の業務や製品に組み込み始めた企業の、開発とセキュリティの担当者から出てくる声です。求められているのは、試験の道具を一つ回して合格の印をもらうことではありません。本当は、何を試し、何を試していないのかを、社内の基準と結びつけて記録に残すことです。この記事では、AIエージェントの窓口に外から試験を当てるOSS「Argus」（作者アカウント gy15901580825 のリポジトリ）について、試験の範囲、判定の仕組み、結果の出し方、安全性の評価と注意点、社内で決めておくことを、一次情報で確かめられる範囲で整理します。導入や操作の手順、試験項目の具体的な中身は扱いません。

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

Argus は、GitHub上で公開されている、AIエージェントのための攻撃役の目線の試験（レッドチーム試験）の道具です。READMEでは、ソースコードを見ずに、ネットワークの向こうにあるエージェントの窓口へ外から働きかけ、攻撃にどこまで耐えるかを確かめる道具と説明されています。対象は、ウェブの窓口や、ブラウザを操作するエージェント、AIに道具をつなぐ規格（MCP）を使うエージェントなどです。

公開の時期と規模を確かめておきます。リポジトリは2026年5月28日に作られ、2026年10月27日時点でスターは206、複製（フォーク）は28、記録された変更は161件です。最後の更新は2026年10月26日で、開発は続いています。GitHub上のリリースの登録はありませんが、Python の部品の配布場所（PyPI）には2026年10月26日に0.1.1版と0.1.2版が登録されています。READMEも、まだ1.0前の段階だと明記しています。

ライセンスは Apache-2.0 で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。PyPI のライセンス欄では、著作権者は Veyon Solutions と記されています。スターの伸びは1日あたり1.4前後と緩やかで、急な水増しをうかがわせる動きは見られません。日本語での紹介は、確認した範囲ではほとんど見当たりませんでした。

なお、「Argus」という名前のセキュリティや監視の道具はほかにもあり、このラインが集めた候補の中にも、別の作者が2026年10月に公開した、エージェント向けのセキュリティ運用の基盤という同名の別のプロジェクトがありました。この記事が扱うのは、作者アカウント gy15901580825 が公開している、AIエージェントの試験の道具としての Argusです。似た名前の別物を入れてしまうと、ライセンス、運営体制、データの通り道がすべて変わるため、社内で検討するときや調達の記録に残すときは、リポジトリの持ち主の名前と所在、配布場所での部品の名前（argus-probe）まで書いておくと取り違えを防げます。

どんな問題に応えるのか：モデルの評価と、エージェントの出荷前試験の違い

READMEの「動機」の節は、大規模言語モデル（大量の文章から学習し、文章を生成するAI）の評価の仕組みの多くは、一つの問いと一つの答えの組を採点するものだと指摘しています。しかし実際に出荷されるのは、計画を立て、道具を呼び出し、失敗から立て直し、文書を読み、ブラウザを開き、会話をまたいで状態を持つエージェントという仕組みだ、というのが作者の問題意識です。

こうした仕組みの弱さは、性能の点数ではなく、外からの働きかけへの耐性で決まると README は述べています。参照した文書に紛れ込んだ命令、道具の呼び出しの取り違え、訪れたページを通じた間接的な命令、何往復かに分けた働きかけなどです。社内の文書をAIに参照させる仕組み（RAG）や、AIに道具を渡して作業させる仕組みを持つ企業にとっては、モデルの提供元が安全対策をしていても、自社のつなぎ方による弱さは自社で測るしかないという点がそのまま当てはまります。

もう一つの狙いは、セキュリティの担当者に渡す報告です。README は、結果を OWASP の一覧、MITRE ATLAS、NIST の枠組みの管理項目に「翻訳なしで」対応づけられる形で出すことを目標に掲げています。開発者が回した試験の結果を、監査やガバナンスの担当がそのまま読める形にする、というのがこの道具の立ち位置だと読めます。

試験の範囲：205の試験項目と、三つの枠組みへの対応づけ

試験の一つひとつの項目は「プローブ」と呼ばれます。READMEによると、同梱の項目は205あり、内訳は OWASP の一覧に沿って作者が書いたもの15、大規模言語モデルの提供元が公開した安全性の報告書に由来するもの5、ブラウザを操作するエージェント向け31、支払いを扱うエージェント向け26、MCP の道具の悪用に関するもの12、エージェントのスキル（手順書）の危うい作りを見つける検出16、独自のもの1、そして NVIDIA の検査用OSS「garak」の項目を包んだもの99です。この記事では、個々の試験項目の名前や文面、手口の中身は扱いません。防御側に必要なのは、どの種類の弱さを測れるかの見取り図です。

スキルの検出の例として README が挙げているのは、人の承認を挟む仕組みの欠落、導入のときに処理が動く作り、正規の手順の外にある認証情報の扱いなどです。これらは攻撃の手口というより、エージェントを作る側の設計の抜けを見つける観点であり、社内の設計審査の項目としても参考になります。

試験はまとめて回す単位（スイート）でも指定でき、OWASP の一覧、MITRE ATLAS、NIST の枠組み、欧州の AI に関する規則（AI法）、支払い、MCP の六つが用意されています。対応づけの表は人手で管理せず自動で作る、とされています。どの基準に照らして試したかを同じ単位で繰り返し測れることは、変更のたびに測り直す運用と相性がよいと考えられます。

OWASPの一覧への対応：厚い分野と薄い分野

対応づけの文書によると、205の項目は、一つの項目が複数の分野に属しうるため、合計246の対応づけになっています。OWASP による、大規模言語モデルを使う仕組みの主要な危険の一覧（10分野）への対応は次の表のとおりです。数字は作者の文書の自己申告で、数え方は今後変わる可能性があります。

OWASP の分野	対応づけの数	文書での扱い
紛れ込んだ命令（プロンプトインジェクション）	87	厚い
機微な情報の開示	45	厚い
過大な権限（エージェントの行き過ぎた動作）	72	厚い
検索用の文書の保管と埋め込みの弱さ	19	厚い
供給網（部品・モデルの調達）	9	厚い
出力の扱いの不備	8	厚い
データやモデルへの毒の混入	2	薄い
指示文（システムプロンプト）の漏えい	1	薄い
誤った情報	1	薄い
際限のない資源の消費	2	薄い

表から分かるのは、Argus の重心が紛れ込んだ命令と、エージェントの過大な権限、情報の開示にあることです。エージェントの試験の道具としては筋の通った配分ですが、毒の混入や誤った情報、資源の消費の分野は1〜2項目にとどまり、文書自身も「薄い」と記しています。

ガバナンスの観点で押さえたいのは、一覧の全分野に項目があることと、全分野を十分に試せることは別だという点です。MITRE ATLAS への対応は14、NIST の枠組みへの対応は13、欧州の AI法 への対応は7の区画に触れる、とだけ記されていて、どの技法や管理項目かの内訳は対応づけの文書では確かめられませんでした。報告書で「対応済み」と読めるものも、項目の数と中身を確かめたうえで扱うべきです。

試験の相手：9種類の接続の部品と、エージェントならではの対象

READMEによると、Argus は9種類の接続の部品を持っています。OpenAI の形式に合わせた窓口、Anthropic の窓口、宛先と送る中身のひな形を自分で決める汎用のウェブの窓口、別の通信方式の窓口、ファイルを受け取って表示する窓口、ブラウザを操作するエージェント、支払いを扱うエージェント、MCP の道具の悪用、そして試験用の環境の汎用の形です。

防御側にとって大きいのは、汎用のウェブの窓口を相手にできることです。つまり、提供元のモデルそのものではなく、自社が指示文や社内の文書、道具を組み合わせて作った「自社のエージェントの窓口」を、外から見えるのと同じ形で試験できます。一方、支払いと MCP の接続の部品は、READMEの説明では同梱の試験用の環境に対して動くとされています。自社の支払いの仕組みや自社の MCP の道具にどう当てるのかは、READMEの範囲では確かめきれませんでした。

README は、本番の窓口に対して、ソースを見ずに攻撃者と同じ立場で試すと書いています。これに対し、セキュリティの方針の文書は、道具を持つエージェントには試験が実際の副作用を起こしうるので、本番より検証用の環境を優先するよう勧めています。メールの送信や支払い、ファイルの書き換えができるエージェントを試すときは、この指摘のほうを社内の決まりの土台にするのが安全です。

判定の仕組み：判定役のAIと、記録に基づく判定

働きかけへの答えに問題があったかどうかは、項目ごとの採点基準に沿って、判定役の大規模言語モデルが決めます。READMEによると、既定ではAnthropic の速い小型のモデルがすべての答えを判定し、重大度が高く確信度が0.7以上と判定されたときだけ、同社のより強いモデルがもう一度判定します。OpenAI のモデルや Azure のサービス、手元で動かすモデルも判定役に選べるとされています。

一方、支払いと MCP の項目は、判定役のAIの意見ではなく、試験中に記録したやり取りの証拠に対する決まった条件の照合で合否を決め、判定役を通さないと説明されています。README の冒頭の説明文にある「判定はAIの意見ではなく記録した証拠から」という言い方は、この部分を指しています。結果がAIの判断に左右されない分、説明がしやすい仕組みです。

注意したいのは二点です。一つは、README 自身が小さな手元のモデルを判定役にすると多くの見落としが出ると警告していることです。もう一つは、Azure のサービスを判定役に使う場合、既定の有害な内容の遮断が判定の呼び出しを止めてしまうため、その配備に限って脱獄の検知を外した設定を使うよう案内していることです。判定役のために事業者側の安全のための設定を緩めるかどうかは、試験の担当者だけで決めず、管理の責任者が判断すべき事項です。

結果の出し方：SARIF・JUnit・HTMLと「試していないこと」の明示

結果は三つの形式で出力できます。開発の基盤である GitHub の、コードの問題を一覧する画面に取り込める SARIF 形式、開発の自動の流れ（CI）で合否の関門に使う JUnit 形式、そして人が読むための HTML 形式です。README は、配布されている部品を使い、指定した重大度以上の結果が出たら自動の流れを止める仕組みも案内しています。

この道具の説明文で目を引くのは、報告書が試していないことも明記するという点です。SARIF と HTML の報告には、基準ごとに、同梱の項目が何を試し、何を試していないかを示す節が付くとされています。合格の結果だけが並ぶ報告は、試験の範囲が狭くても安全に見えてしまいます。試していない範囲が報告に残ることは、監査やガバナンスの担当が結果を読むうえで実務的な価値があります。

このほか、判定役のAIの利用料が膨らみすぎないよう、1日あたりと1回あたりの費用の上限を設け、上限を超えそうだと予測した時点で打ち切る仕組みがあるとされています。ただし セキュリティの方針の文書 は、この上限は試験の相手の側でかかる費用までは抑えないと注意しています。試験の相手が有料のモデルを使う自社のエージェントなら、その費用は別に見積もる必要があります。

作者が公開した測定結果から読み取れること

リポジトリには、作者が実際に測った結果をまとめた文書があります。わざと弱く作った試験用の対話の窓口に、選んだ15項目・35の働きかけを当てたところ、対策のない状態では35のうち8、およそ23％で攻撃が通りました。入力の側で紛れ込んだ命令を見分ける分類のモデル（ProtectAI の公開モデル。Meta の同種のモデルの代わりに使用）を前に置くと、通ったのは35のうち1、およそ3％に下がったと報告されています。

同じ文書は、副作用も隠さずに書いています。問題のない働きかけ27のうち、およそ12、割合にして44％ほどまで分類のモデルが止めてしまい、止めすぎを抑えるための調整が必要だとしています。CPU で動かした場合の判定の待ち時間は、中央値でおよそ275ミリ秒でした。

作者自身が挙げる限界もあります。相手は作り物の窓口で、判定は決まった文字列の照合であり判定役のAIではなく、項目は全体の一部だけで、出力の側の対策は試していません。文書の時点の項目の総数は167で、今の205とは異なります。ここから読み取れるのは、一つの対策を足すと攻撃は減るが、正当な利用も止まりうるという、守りの調整でよく起きる関係です。数字そのものを自社に当てはめることはできません。

比べる表：既存の点検との違い

Argus のような道具は、ほかの点検の手段を置き換えるものではありません。README も、モデルを学習させたり、性能の点数を測ったり、既存のモデルの評価の仕組みを置き換えたりはしない、と明記しています。下の表は、出荷前の点検の手段を、防御側に関係する観点で並べたものです。Argus の欄は README の説明に基づき、ほかの欄は一般的な特徴の整理です。

観点	機能の試験	モデルの評価の仕組み	Argus（本記事）	外部の専門家による点検
見るもの	決めた動作の正しさ	一つの問いと答えの質	エージェントの窓口の攻撃への耐性	仕組み全体と運用
ソースが要るか	要る	場合による	要らない（外から試す）	契約しだい
結果の形	合否	点数	基準に対応づけた結果と試していない範囲	報告書と改善の提案
繰り返しやすさ	高い	高い	高い（自動の流れに組み込める）	低い（費用と日程）
新しい手口への強さ	低い	低い	同梱の項目の範囲まで	専門家の知見しだい

表から分かるのは、Argus の持ち味が同じ物差しで繰り返し測り、結果を基準に結びつけて残せることにあることです。一方で、同梱の項目の外にある新しい手口は測れません。重要な窓口では、自動の試験で日々の変化を追い、節目では外部の専門家の点検を受ける、という組み合わせが現実的です。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Argus の判定は「注意付き」です。ライセンスは OSI 承認の Apache-2.0、作者のアカウントは2020年1月に作られたもので、確認した時点でセキュリティ勧告は公開されていません。精査の範囲では、導入の際に自動で動く処理の仕組みも見当たりませんでした。

それでも注意付きとした根拠は二つあります。一つ目は、自社のエージェントへの攻撃を模した試験を行う、両用の道具であることです。自社の点検に役立つ一方で、許可のない他者の窓口に向ければ攻撃になります。セキュリティの方針の文書 自身も、これは攻撃のための道具だと明記しています。

二つ目は、作者の実績が乏しいことです。作者のアカウントの公開リポジトリは15、フォロワーは18で、長く使われてきた道具の作り手とは言えません。ただし、勧告が出ていないこと、自動で動く処理が見つからなかったことは、安全の保証ではありません。この道具は、外部の事業者の鍵を扱い、大量の働きかけを送り、有害になりうる答えを記録します。ほかの業務用のソフトウェアと同じ確認を経て使うべきです。

注意点の詳細：運営体制・版・データの通り道

一つ目は運営体制です。変更の記録を見ると、最近の変更の多くは同じ一人の開発者のアカウントによるもので、AIの開発支援の道具が共同の作成者として並んでいます。AIの支援を使った開発自体は珍しくありませんが、少人数で速く変わる道具は、変更の中身を誰が確かめているかが外から見えにくいという点は、調達のときに考慮しておきたいところです。PyPI での配布も2026年10月26日に始まったばかりです。

二つ目は版です。README は1.0前と明記しつつ、操作の窓口や結果の形式などは安定させる対象だとしています。一方、セキュリティの方針の文書 では、セキュリティの修正は最新の流れにだけ入り、古い版には戻して当てないとされています。古い版に固定して使い続けると修正が届かないため、版の記録と更新の担当を決めておく必要があります。脆弱性の報告は非公開のメールで受け付け、2営業日以内の受付の返事と、重大度に応じて30日以内の修正または緩和を目安にすると書かれています。

三つ目はデータの通り道です。セキュリティの方針の文書 は、試験の働きかけは試験の相手に、相手の答えは外部の判定役のAIに送られると明記しています。判定役に外部の事業者のモデルを選べば、自社のエージェントが返した答え、つまり社内の情報が混じりうる文章が、その事業者のもとを通ります。判定役のモデルの選び方は、精度だけでなく、データの扱いの決まりとあわせて決める必要があります。

悪用されうるリスク

試験の道具は、立場を変えれば攻撃の道具にもなります。Argus は汎用のウェブの窓口を相手にでき、配布場所から手軽に入手できるため、許可のない他者のAIエージェントの窓口に向けて使われる可能性は否定できません。これは推測であり、そうした使われ方の報告を確認したわけではありません。セキュリティの方針の文書 は、自分が持つ仕組みか、文書で明確な許可を得た仕組みだけを試すよう明記しています。

README によると、会話を重ねながら攻め方を変えていく仕組みは、エンジンの中にはあるものの、まだ操作の窓口からは使えない状態です。今後これが表に出れば、道具の攻撃の力は強まる可能性があります。守る側から見れば、社外に開いた自社のエージェントの窓口も、同じ種類の道具で外から試されうるという前提に立つことが大切です。ただし、こうした手口の多くはすでに公開の研究として出回っており、この道具に固有の危険というより、すでにある現実を映したものと見るのが妥当でしょう。

社内での悪用の余地も考えておく必要があります。試験の名目で、社員が許可なく取引先や他社のAIの窓口を試すことは、契約や法律の上の問題になりえます。道具を使える人、試してよい相手、記録の残し方を社内の決まりとして書いておくことが、自社を守ることにもつながります。

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

Argus を社内の出荷前試験に使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Argus を使うかどうかにかかわらず、AIエージェントを社内外に出す企業が取るべき対策は共通しています。第一に、攻撃役の目線の試験の道具を、侵入テスト（攻め手の目線で弱点を確かめる検査）の道具と同じ扱いで台帳に載せることです。使う人、置き場所、版、登録した鍵を記録し、持ち出しや私的な利用を禁じます。

第二に、道具を持つエージェントの出荷には、攻撃への耐性の試験を条件にすることです。試験の結果と、試していない範囲、見つかった弱さへの対応を記録に残し、公開の可否を決める人を明確にします。第三に、試験の結果に含まれる有害な答えや働きかけの記録を、通常の業務文書より厳しい閲覧の範囲で保管します。

第四に、モデルの入れ替え、指示文の改訂、道具や権限の追加を、測り直しのきっかけとして手順に組み込みます。第五に、自社の窓口が外から試されうる前提に立ち、利用の記録に、短い時間に似た働きかけが続く、普段と違う道具の呼び出しが増えるといった不自然な使われ方が残っていないかを見る観点を、監視の手順に加えます。道具を入れることより、試験を回す決まりと、結果を受けて直す流れを先に作ることが要点です。

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

Argus は、多数の働きかけを自動で送り、答えを判定役のAIが評価する道具です。効率のよい設計ですが、試験の結果を最終的な判断としてAIに委ねてはいけません。作者自身も、判定役を二段にし、支払いや MCP の項目では記録した証拠で判定するなど、AIの判定だけに頼らない作りにしています。AIに任せてよいのは、大量の働きかけを試し、怪しい答えを拾い上げるところまでです。

人が決めるのは、何を試験の相手にするか、どの結果を問題とみなすか、試していない範囲をどう補うか、何を直すか、どこまで試したら出荷してよいとするかです。判定役のAIを使う場合は、判定の根拠となるやり取りを記録に残させ、問題とされた答えも問題なしとされた答えも、人が抜き取りで読んで確かめることを手順に入れます。避けたい使い方を挙げます。

• 自動の流れが通ったことだけを理由に、AIエージェントを出荷してよいと判断する
• 報告書の「試していない範囲」を読まずに、OWASP の一覧に全分野対応済みと社内に報告する
• メールの送信や支払いができる本番のエージェントに、許可や事前の連絡なしで試験を当てる
• 判定役のために事業者側の安全のための設定を、担当者の判断だけで外す
• 許可を得ていない取引先や他社のAIの窓口を、試験の相手として設定する

どの例も、道具の能力ではなく運用の決まりで防げる失敗です。人が確認する範囲を先に決めておくことが、試験を意味のあるものにします。

よくある質問：結果が出れば、監査への説明はこれで足りるのか

答えは「説明の材料にはなるが、それだけでは足りない」です。Argus の報告は、試験項目を OWASP の一覧、MITRE ATLAS、NIST の枠組みに対応づけて示しますが、それは同梱の項目がその基準のどこに触れるかを示すものであって、基準を満たしていることの証明ではありません。

監査やガバナンスの担当に示すときは、試験の結果に加えて、試していない範囲をどう補ったか、見つかった弱さをどう直したか、誰がそれを確認したかを添えると、説明として成り立ちます。モデルの提供元が更新すれば、同じ設定でも結果は変わりえます。試験した日付と版を記録し、変更のたびに測り直していることを示すことも大切です。

もう一つ、「無料のOSSで試験できるなら、外部の点検は要らないのか」という問いもありそうです。自動の試験は、既知の種類の弱さを繰り返し安く測ることに向いています。新しい手口や、業務の流れに固有の弱さは、人の専門家の目でなければ見つけにくいものです。「安全の証明」ではなく「弱いところを見つけ、変化を追う道具」として位置づけるのが現実的です。

• Argus の機能・試験の範囲・判定の仕組み・結果の形式・安全に関する方針は、GitHubのリポジトリ（README・対応づけの文書・測定結果の文書・セキュリティの方針の文書・変更の記録）と PyPI の配布ページを2026年10月27日に確かめた範囲に基づきます。1.0前の版で更新が多く、内容は変わる可能性があります
• MITRE ATLAS・NIST の枠組み・欧州の AI法 への対応の内訳、自社の支払いの仕組みや MCP の道具への当て方、道具から作者へ送られる情報の有無は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、試験項目の具体的な文面・手口は扱いません

まとめ

Argus は、作者アカウント gy15901580825 が2026年5月から Apache-2.0 で公開している、AIエージェントの窓口を外から試験するOSSです。205の試験項目を持ち、結果を OWASP の一覧、MITRE ATLAS、NIST の枠組みに対応づけて、開発の流れに組み込める形式で出し、試していない範囲も報告に残します。支払いや MCP の項目では、AIの意見ではなく記録した証拠で判定する作りも備えています。

一方で、攻撃を模した試験を行う両用の道具であり、作者の実績は限られ、版はまだ1.0前で、OWASP の一覧のうち薄い分野もあります。試してよい相手と環境を文書で決め、働きかけと答えが通る先を管理し、使った版と試していない範囲を記録し、判定は人が読んで確かめることが、Argus を自社のエージェントの出荷前試験とガバナンスに生かすための現実的な付き合い方です。

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