ツールの出力に紛れた不正指示の検知器をOSS「buried-injections」はどう検証したのか

「AIエージェントにメールや社内文書を読ませ始めたが、そこに紛れた命令に従ってしまわないか心配だ」「検知の製品を一つ入れておけば、紛れ込んだ命令はだいたい止められるのではないか」——AIエージェントの業務への組み込みを任された、情報システム部門からよく聞こえてくる二つの声です。検知器を入れれば守れる、と考えたくなるのは自然です。けれども本当は、検知器は守りの一枚にすぎず、すり抜けを前提に、AIに渡す権限と人の承認で被害の範囲を決めておくことが守りの中心です。この記事では、AIエージェントが受け取るツールの出力に紛れた不正な指示を、公開されている検知器がどこまで捕まえるかを測った個人のベンチマーク「buried-injections」について、確かめられる事実、結果の読み方と限界、そして検知器だけに頼らない企業の守りを整理します。攻撃文の例や作り方、検証を動かす手順は扱いません。

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

buried-injections は、GitHub上で公開されているベンチマーク（性能を同じ条件で比べるための試験の一式）です。READMEによると、AIエージェントが受け取るツールの出力の中に、不正な指示が埋め込まれていたとき、公開されている検知器がそれをどこまで捕まえられるかを測るために作られました。名前は「埋もれた注入」といった意味で、普通の出力の中に紛れた指示を対象にしていることを表しています。

公開の時期と規模も押さえておきます。リポジトリが作られたのは2026年9月23日で、最後の更新は2026年10月4日です。2026年10月21日時点のスターはおよそ30、複製（フォーク）は8です。ライセンスはMITで、OSI（オープンソースの定義を管理する団体）が承認したライセンスにあたるため、この記事では「OSS」と呼びます。検証の結果は保存した記録から再計算できる作りだとREADMEは説明しています。

作者は個人で、アカウントは2024年9月に作られ、公開リポジトリは26、フォロワーは1です。READMEには所属する組織の名前は書かれていません。つまりこれは、研究機関や製品の提供元が出した評価ではなく、一人の作者が公開した検証の記録です。この点は、数値の読み方と安全性の評価の両方に関わるので、後の見出しで改めて扱います。

間接プロンプトインジェクションとは。なぜツールの出力が狙われるのか

プロンプトインジェクションとは、AIへの入力に指示を紛れ込ませ、AIの振る舞いを意図しない方向へ変えてしまう攻撃の総称です。利用者が直接打ち込む場合を直接型、AIが読み込む外部の内容に指示が仕込まれている場合を間接プロンプトインジェクションと呼びます。OWASP（ウェブの安全性に関する国際的な非営利の団体）は、言語モデルを使う仕組みの主要な危険の一覧で、これを筆頭の項目に挙げています。

AIエージェントは、メールを読む、予定を調べる、ウェブの頁を取ってくる、といったツールを呼び出し、その結果を読んで次の行動を決めます。ここで問題になるのは、ツールの出力は、外部の誰かが書いた文章を含みうるという点です。受け取ったメールの本文や、共有された文書の一部に指示が紛れていれば、AIはそれを利用者からの依頼と取り違える可能性があります。

この攻撃が厄介なのは、利用者が何も悪いことをしていなくても起きる点です。業務の流れの中で普通に外部の情報を読ませるだけで、入口が開いてしまいます。そのため、ツールの出力を通る文章を見張って怪しい指示を見つける「検知器」が、守りの手段として注目されてきました。buried-injections は、その検知器が現実に近い条件でどこまで働くかを問うたものです。

検証の土台：研究用のAgentDojoのデータをどう使ったか

buried-injections が攻撃のデータとして使っているのは、AgentDojo という研究用のベンチマークです。AgentDojo は、チューリッヒ工科大学などの研究者が公開した、AIエージェントへのプロンプトインジェクションの攻撃と防御を評価するための環境で、論文は2024年の機械学習の国際会議の、データセットとベンチマークの部門に採録されたと記載されています。ライセンスはMITです。

READMEによると、buried-injections は AgentDojo の第1版から、攻撃を含むツールの出力629件と、攻撃を含まない安全な出力97件を取り出して使っています。対象の業務の場面は、仕事の道具、旅行、銀行、社内のチャットの四つです。攻撃は、ツールが返す普段どおりの出力の中に埋め込まれた形で検知器に渡されます。

ここが、この検証の一番の特徴です。攻撃の文章だけを単独で検知器に見せる試験はこれまでもありましたが、実際のAIエージェントの見張り役が目にするのは、普通の出力にまぎれた攻撃です。READMEは、見張り役が実際に見る形に合わせて測った、と説明しています。比較のために、攻撃の文章だけを単独で見せた場合の結果もあわせて示されています。

既定の設定での結果：捕まえる力と誤検知の両立はできていなかった

READMEの結果の表から、主な数値を抜き出します。比べられた検知器は10種で、公開されている検知用の言語モデル、Meta社の「Prompt Guard 2」の大小二つ、別の検知の道具「LLM Guard」、そして正規表現（文字の並びの規則で照合する仕組み）による単純な照合です。数値はすべてREADMEに作者が記載したもので、この記事では再現していません。

検知器（READMEの記載）	攻撃を捕まえた割合（629件中）	安全な出力を誤って止めた割合（97件中）
最もつり合いがよかった検知モデル	51%	2%
LLM Guard（出荷時の設定）	20%	2%
Prompt Guard 2（大きいほう）	1%	0%
Prompt Guard 2（小さいほう）	0%	0%
正規表現による単純な照合	0%	0%
攻撃をすべて捕まえた二つの検知モデル	100%	98%

作者のまとめは、既定の設定のままでは、攻撃の大半を捕まえつつ安全な出力を止めない検知器は一つもなかったというものです。最もつり合いのよかったものでも半分ほどを見落とし、すべてを捕まえたものは安全な出力のほとんども止めていました。1回の判定にかかる時間の中央値は、単純な照合の0.05ミリ秒から、検知モデルの160ミリ秒前後までと記載されています。

三つの失敗の型：見落とす、薄まる、何でも止める

READMEは、検知器のつまずき方を三つの型に分けて説明しています。一つ目は言い回しを見落とす型です。Prompt Guard 2 は、人が手で書いたいかにもな攻撃文には高い点を付ける一方、AgentDojo の攻撃は普通の依頼のような文面のため点が低く、既定の判定の線を越えなかった、とされています。

二つ目は周りの文章に薄まる型です。ある検知モデルと LLM Guard は、攻撃の文章だけを単独で見せると全27種類をすべて捕まえたのに、普通の出力に埋め込むと捕まえた割合が2割前後まで落ちました。作者は、文章を重なり合う区切りに分けて最も高い点を採る方法で測っているため、文章の長さで切り捨てられたのではなく、周りの文章によって攻撃の気配が薄まったのだと見ています。

三つ目は何でも止める型です。攻撃を100%捕まえた二つの検知モデルは、安全な出力の98%も止めていました。別の二つも、安全な出力の半分ほどを止めています。誤検知がこれほど多いと、業務が回らなくなり、結局は検知器を止めることになる、と作者は指摘しています。止めすぎる検知器は、外されて何も捕まえない検知器になるという指摘は、運用の現場の感覚にも合うものです。

しきい値を自社の通常の通信で決め直すと、順位が入れ替わる

検知器の多くは、点数がある値（しきい値）を超えたら攻撃とみなします。READMEは、既定のしきい値のままではなく、安全な出力を誤って止めるのを一定以下に抑えたうえで、攻撃をどれだけ捕まえられるかという別の物差しでも比べています。しきい値は四つの場面のうち三つの安全な出力で決め、残る一つの見たことのない場面で測る、という入れ替えを四回繰り返しています。

この物差しでは順位が大きく入れ替わりました。既定ではほぼ何も捕まえなかった Prompt Guard 2 の大きいほうが、しきい値を大きく下げると、見たことのない場面でも97〜100%を捕まえ、そのときの誤検知は約5%だったと記載されています。逆に、既定ですべてを捕まえていた検知モデルのいくつかは、誤検知を抑える線に合わせると、最も悪い場面で捕まえた割合がほぼ0%に落ちました。

作者は、この結果を「解決した」と読まないよう注意を添えています。決め直したしきい値は AgentDojo の共通の攻撃の型に合わせたものであり、攻撃の型そのものを覚えただけの可能性があるからです。企業にとっての教訓は、特定の検知器の優劣よりも、しきい値は製品の既定に任せず、自社の通常の通信で確かめる必要があるという点にあります。

作者自身が挙げている限界

READMEには、作者自身が検証の限界を項目として挙げています。まず、攻撃の種類は27で、攻撃の書き方の型は一つだけです。629件という数は、同じ27種類の攻撃を、さまざまな依頼とツールの出力に埋め込んで増やしたものです。作者は結果を「一般に当てはまる定数」ではなく「一つの傾向」として示している、と述べています。

次に、使ったベンチマークは AgentDojo の一つだけで、ほかの研究用のデータや、実際に動くAIエージェントでの評価は今後の課題とされています。実際のAIエージェントを動かしていないため、攻撃が成功してAIが乗っ取られたかどうかは測っていません。測っているのは、あくまで検知器が文章を怪しいと判定したかどうかです。

さらに、ツールの呼び出しを規則で許可・拒否する仕組みは試験していないとされます。命令口調の攻撃を丁寧な依頼の言い回しに書き換えた比較も行われていますが、言い回しと語彙が同時に変わっているため、原因を切り分けきれていないと作者は書いています。また、Meta社の Prompt Guard 2 は利用に申請が要るため、有志が変換した写しを使って測っているとも明記されています。公式の版と完全に同じ結果になるかは、この記事では確かめていません。

数値をどう読むか：第三者の検証がない個人のベンチマーク

ここまでの数値は、すべてREADMEの記載です。読み手としては、第三者が同じ条件で再現した報告は、この記事の確認の範囲では見つかっていないことを前提に置く必要があります。READMEには、閲覧者がこの検証の保存済みの点数を使って一部の集計をやり直し、その指摘を受けて報告の仕方を改めた経緯が書かれていますが、独立した評価とは性格が異なります。

また、AgentDojo のデータは研究用に作られたもので、自社のAIエージェントが実際に受け取るメールや文書とは、文章の長さも話題も違います。検知器の成績は、どんな文章を、どんなしきい値で測ったかで大きく変わることを、この検証自体が示しています。だからこそ、この表の順位を、そのまま製品選びの答えにするのは避けるべきです。

一方で、この検証の価値は、数値の正確さよりも問いの立て方にあると考えられます。攻撃の文章を単独で見せる試験だけで検知器を評価すると、実際の運用で見落としが起きうること。既定の設定が自社の環境に合っているとは限らないこと。この二つは、検証の細部が今後修正されたとしても、自社で検知器を評価するときの観点としてそのまま使えます。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。buried-injections の判定は「注意付き」です。主な根拠は、作者の実績を外から確かめにくいことです。作者は所属の分からない個人で、フォロワーは1、リポジトリの公開から1か月ほどしかたっていません。

一方で、精査の範囲では、公開済みのセキュリティ勧告はなく、スターの伸びも1日あたり1前後で、不自然な急増は見られませんでした。ライセンスはMITです。リポジトリの最上位には作業をまとめて実行する定義の文書が置かれており、READMEによれば、初回に5ギガバイトほどの検知モデルの重みを外部から取得する作りです。社内の端末で動かす場合は、何がどこから取得されるかを一般のソフトウェアと同じ手順で確かめる必要があります。

また、ベンチマークの性格上、作者の評価がそのまま正しいとは限りません。結果の数値は作者の環境での一回の測定であり、検知器の版や設定が変われば結果も変わりえます。なお、精査で問題が見つからなかったことは、安全の保証ではありません。検証のための道具であっても、取り込む前の確認は省かないでください。

悪用されうるリスクと、公開された検証の二面性

検知器の弱点を公開する検証には、二面性があります。守る側には、どの条件で検知器が外れやすいかを知る手がかりになります。一方で、攻める側にとっても、どの検知器を、どういう条件ですり抜けやすいかの参考になりうることは否定できません。READMEは、言い回しの違いで検知の結果が変わることにも触れています。

ただし、使われている攻撃のデータは、すでに研究用として広く公開されている AgentDojo のものです。buried-injections が新たな攻撃の手法を作り出したわけではなく、既存の攻撃と既存の検知器を、条件をそろえて比べた記録だと読めます。作者も、言い回しの比較は検知器のすり抜けを示したもので、AIの乗っ取りを示したものではないと書いています。

守る側が受け取るべき示唆は、検知器の弱点は、すでに外から調べられる状態にあるという前提に立つことです。検知器が一種類だけで、しかも既定の設定のまま、という守りは、弱点を知る相手には通じにくいと考えておくべきでしょう。この記事では、すり抜けの具体的な方法には触れません。

検知器だけに頼らない多層の守り

buried-injections の作者も、READMEの最後で、文章を見分ける検知器だけに頼らないよう勧めています。指示が利用者から来たのかツールの出力から来たのかという出どころを追うこと、ツールの呼び出しが実際に何をするのかを見ること、そしてツールと引数ごとに許可・拒否・承認を決める規則で止めることです。OWASPも、プロンプトインジェクションへの備えとして権限の最小化と、危険の大きい操作での人の承認を挙げています。

多層の守りを考えるときは、「検知器が外れたらどうなるか」から逆算すると整理しやすくなります。紛れ込んだ命令にAIが従ってしまっても、AIに渡した権限の外のことはできません。社外へのメールの送信や支払いのように取り返しのつかない操作の前に人の承認を挟めば、被害は承認の前で止まります。AIの出力をそのまま別の仕組みに流さず、決まった形かどうかを確かめれば、被害が次の仕組みへ広がりにくくなります。

つまり守りの順番は、まず検知器が見落としても被害が限られる作りを整え、そのうえで検知器を早期の警報として重ねる、というものです。検知器は、この順番の最後に来る部品と考えると、過信も軽視もせずに位置づけられます。

企業が取るべき対策：権限・承認・出力の扱い

第一に、AIエージェントに渡す権限を最小にすることです。外部の文書を読ませる仕事と、社外へ送信する・記録を書き換えるといった仕事を、同じAIエージェントに同じ権限でまとめて持たせないようにします。読むだけで済む仕事には、読む権限だけを渡します。外部の内容を扱うAIほど、できることを狭くしておくのが原則です。

第二に、取り返しのつかない操作の前に人の承認を挟むことです。社外への送信、支払い、権限の変更、データの削除などを洗い出し、AIが実行する前に人が中身を確かめる流れにします。承認を求めるときは、AIに「なぜその操作をするのか」の根拠と、その根拠になった情報の出どころを書かせると、紛れ込んだ命令に由来する操作かどうかを人が見分けやすくなります。

第三に、AIの出力の扱いを決めることです。AIの出力をそのまま別の仕組みへの命令として流さず、決まった形かどうかを確かめます。第四に、外部から来た内容を、利用者の依頼と区別できる形で扱い、どこから来た指示かを記録に残します。第五に、検知器を入れる場合は、既定のしきい値に任せず、自社の通常の通信で誤検知と見落としの両方を確かめてから使います。

社内で検知器を評価するときに確かめること

buried-injections の問いの立て方は、自社で検知の製品や部品を評価するときの観点として使えます。数値をそのまま借りるのではなく、自社の条件で同じ問いを立て直すことが大切です。次の順で確かめると、評価の抜けを防ぎやすくなります。

AIに判断させない範囲と、人が決める範囲

検知器もAIエージェントも、文章を見て判断する仕組みです。どちらも外れることがある以上、最終的な判断をAIに任せてはいけません。AIに任せてよいのは、怪しい出力を拾い上げる、操作の根拠を書き出す、といった人の判断を助ける部分までです。

人が決めるのは、どの操作をAIに許すか、どの操作の前に承認を挟むか、検知器のしきい値をどこに置くか、どの頻度で見直すかです。人が確認する範囲を、導入の前に先に決めておくことが、運用が始まってから線を引き直す手間を減らします。避けたい使い方を挙げます。

• ベンチマークの順位表だけを見て、自社で試さずに検知器を選ぶ
• 検知器を一つ入れたことを理由に、AIエージェントに社外への送信や支払いの権限まで渡す
• 製品の既定のしきい値のまま、誤検知と見落としを測らずに運用を始める
• 検知器が通した出力を、そのまま別の仕組みへの命令として流す
• AIが示した操作の根拠を、人が読まずに承認する

とくに二つ目は起きやすい失敗です。検知器はすり抜けを前提にした守りの一枚であり、権限を広げてよい理由にはなりません。検知器の導入と権限の設計は、別々に決めるものだと考えてください。

よくある質問：この結果を見て、検知器は入れなくてよいのか

答えは「入れる意味はあるが、それだけに頼らない」です。buried-injections が示したのは、既定の設定のままでは見落としや誤検知が大きくなりうることであり、検知器が役に立たないということではありません。しきい値を自社の条件で決め直すと結果が大きく変わったという記載は、逆に言えば、調整と評価をすれば早期の警報として働く余地があることも示しています。

もう一つ、「表で成績のよかった検知器を選べばよいのか」という問いもありそうです。この検証は一つのデータと一つの攻撃の型による個人の測定で、第三者の再現もまだありません。自社が受け取る文章の性質は研究用のデータと違うため、表の順位は候補を絞る参考にとどめ、自社の通常の通信で確かめるのが現実的です。

最後に、「このベンチマークを社内で動かして確かめるべきか」という問いです。動かす場合は、外部から大きなモデルの重みを取得する作りであることを踏まえ、社内のソフトウェアの取り込みの手順に沿って確かめてください。このラインでは実行しておらず、動作や結果の再現は確かめていません。

• buried-injections の内容・数値・限界は、GitHubのリポジトリ（README・ライセンス文書）を2026年10月21日に確かめた範囲に基づきます。数値は作者の記載で、この記事では再現していません。版の更新で内容は変わる可能性があります
• AgentDojo の概要はリポジトリと論文の頁、プロンプトインジェクションの分類と対策はOWASPの項目を同日に確かめました
• 第三者による再現の報告、作者の所属、有志が変換した写しと公式の版の結果の一致は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。攻撃文の例や作り方、検証の実行の手順は扱いません

まとめ

buried-injections は、AIエージェントが受け取るツールの出力に紛れた不正な指示を、公開の検知器10種がどこまで捕まえるかを測った、MITライセンスの個人のベンチマークです。READMEによると、既定の設定のままでは、攻撃の大半を捕まえつつ安全な出力を止めない検知器はなく、しきい値を決め直すと順位が大きく入れ替わりました。ただし攻撃の型は一つで、実際のAIエージェントは動かしておらず、第三者の検証もまだありません。

企業にとっての教訓は、特定の検知器の優劣ではありません。検知器はすり抜けを前提にした一枚にとどめ、権限の最小化、取り返しのつかない操作の前の人の承認、出力の扱いの決まりを先に整えること。そのうえで、検知器は自社の通常の通信で確かめてから重ねることが、buried-injections の結果との現実的な付き合い方です。

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