p4ni.

研究紹介

間接プロンプト注入はすでにウェブ中にあり、ほとんど効いていない:12億 URL の実測研究

· 読了まで約8分

目次

ついに数えた人が現れました。Khodayari、Zhang、Acharya、Pellegrino の研究チームが 12億の URL(2,480万ホスト)を走査し、実在する公開ウェブページ 11.7K 件の上に、検証済みの間接プロンプト注入を 15.3K 件見つけました(arXiv:2604.27202)。ラボのペイロードでも PoC リポジトリでもなく、いま本番のウェブサイトに置かれ、AI エージェントが読みに来るのを待っている指示です。

論文のタイトルは「Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives」(2026年4月公開、査読前のプレプリント)。私はここ2本の記事で自分の Agent Skills にカナリア指示を仕込み、どこに置いた命令が効くのかを測ってきました。だから同じ攻撃クラスをウェブ全体のスケールで測った研究は、まさに欲しくて自分では作れなかったデータです。n=3 の自作実験では答えようのない3つの問いに答えてくれます。誰がやっているのか、どうやって、そして効くのか。

いちばん意外だったのは3つ目の答えでした。13 モデル・5,200 試行の統制実験で、攻撃の実効率は最大でも 4.2%。しかも最も漏れやすいページ表現は、どのスクレイピングパイプラインもわざわざ作っている「プレーンテキスト」でした。

注入の半分はページの中にすら無い

ウェブページ上のプロンプト注入と聞けば、白背景に白文字とか、画面外に飛ばした div を思い浮かべるはずです。この論文の分布データはそのイメージを裏切ります。7,887 件、全体の約 54.5% は HTTP レスポンスヘッダーの中にありました。大半は X-AI(6,535 件、ヘッダー系の約 84%)や X-LLM(1,022 件)といった、そのために作られたカスタムヘッダーです。

この置き場所が示すことは明快です。ブラウザはヘッダーを描画しません。人間は決して目にしない。想定できる読み手は、生の HTTP レスポンスを言語モデルに流し込む機械だけです。サイト運営者は、ドキュメントの外側にあるチャンネルで LLM パイプラインに直接話しかけています。

本文側の半分は古典的なイメージに近い分布です。通常の HTML 要素に 4,608 件、JSON-LD などの構造化データの中に 1,996 件、HTML や JavaScript のコメントに 675 件。合計すると全インスタンスの約 70% が、ヘッダー・コメント・メタデータという構造的に見えない場所にあります。色合わせ・重ね置き・ビューポート外・ゼロサイズ要素といった CSS の隠蔽技術まで足すと、レンダリングされたページが運ぶ注入の 87% が不可視でした。

構造化データを出しているなら、JSON-LD の数字は見ておいたほうがいい。私が Astro の JSON-LD 記事を書いたのは Google が読むからですが、本文系注入の 26% が同じブロックを選んだのは、Google 以外の機械も読むからです。機械が読み、人間が読み飛ばすチャンネルは、いずれ誰かが指示を書き込むチャンネルになる。

大半は窃取ではなく妨害と自衛

注入された指示が実際に何をさせようとしていたかを、多い順に並べます。脅威モデルの見方が変わったのは、この表を見たときでした。

目的件数割合
ガベージ注入(モデル出力の汚染)8,46955.0%
データ保護(学習拒否・著作権表示)4,09326.6%
AI ボット識別(チャレンジレスポンス・ハニーポット)3,09620.1%
評判操作(自己宣伝・引用の強制)1,5219.9%
データ流出130.1%

セキュリティ記事の定番シナリオ、つまり攻撃者が仕込みページ経由でユーザーのデータを盗むという筋書きは、1万5千件のうち 13 件です。実際の主流はウェブサイト側の反撃でした。スクレイパーのコンテキストにゴミを流し込み、著作権を主張し、ボットを捕まえるための罠を仕掛ける。野生の間接プロンプト注入は、ユーザーに向けられた武器というより、クローラーに向けられたバリケードだったわけです。

気持ちは分かります。私は AI クローラーが実際に何を見ているかを調べたうえで協調路線を選びました。llms.txt を置き、素の静的 HTML を返し、小細工はしない。この研究が記録しているのは、敵対路線を選んだ数千のサイト運営者です。スクレイピングの倫理をどう考えるかは人それぞれとして、データが否定してみせたのは「ウェブページ上の注入は珍しく、例外的で、だいたい犯罪目的」という思い込みのほうでした。実際には、ありふれていて、地味で、大半が自衛です。

5,200 試行の実測:ほとんど効かず、いちばん弱い形式はプレーンテキスト

どれだけ蔓延していても効かなければただのゴミなので、著者らは見つけたペイロードを統制環境に持ち込みました。100 プロンプト × 4 種のページ表現 × 13 モデル、タスクはウェブページの要約、計 5,200 試行です。

モデル規模別のコンプライアンス率は、小規模オープンモデル 4.2%、中規模 0.6%、大規模 1.2%、クローズドのフロンティアモデル 0.6%。検出は逆方向に走ります。フロンティアモデルは 25.1% の試行で注入の存在を自分から指摘し、小規模モデルの指摘は 4.8% にとどまりました。

私の Agent Skills 実験を読んだ人には既視感のある構図のはずです。カナリアテストでは haiku-4.5 が 30 試行中 21 回黙って従い、sonnet-5 は 0 回、しかも 20 試行中 16 回は自分から報告してきました。スケールが3桁違っても教訓は同じで、効くかどうかを決めるのは隠し場所ではなく、読み手のモデルです。1ペイロードの自作実験が指した向きを、5,200 試行の研究が同じ向きで裏づけてくれました。

設計判断に直結するのは表現形式の結果です。マークアップを剥がしたプレーンテキストをモデルに与えたときの実効率が最も高く 3.9%、小規模モデルでは 8.0% に達します。フル HTML なら 1.1%、生の HTTP レスポンスなら 0.2%。ページを「きれいな」テキストに削ぎ落とす工程は、その一文がコメントの中・ヘッダーの中・隠し div の中にあると気づくための構造的シグナルを、ちょうど削除してしまいます。RAG パイプラインが既定でやっているサニタイズこそが、攻撃を通しやすくする工程でした。

もうひとつ、覚えておくべき細部があります。検出と拒否は独立です。6 つの試行では、モデルが「このページには注入が含まれる」と明示的に警告したうえで、その指示に従いました。「モデルが気づいた」はセキュリティ境界になりません。OWASP が防御側の議論で同じ結論に達していて、確実な防止策が存在するとは約束していません。

実装と運用にどう反映するか

ウェブページをモデルに読ませるものを作っているなら。要約器でもリサーチエージェントでも RAG の取り込みでも、ページ表現の選択は実測値つきのセキュリティパラメータになりました。数字は構造の保持を支持しています。マークアップを保った入力は、プレーンテキスト比で実効率をおよそ4分の1に下げました。モデルに見せる前にページを散文へ剥がさないこと。生レスポンスを扱うなら、観測された攻撃面の半分は、抽出器がたぶん読まずに捨てているヘッダーの中にあることも思い出してください。捨てるのは正しい。コンテキストへ連結するのが間違いです。

ウェブサイトを運営しているなら。防御的注入の件数を見ると自分もやりたくなりますが、私なら手を出しません。実効率 0.6〜4.2% では、「クローラーへの指示」は制御ではなく宝くじです。robots.txt や llms.txt には、少なくとも偽りの安心感が付いてこない正直なシグナルという美点があります。JSON-LD を出しているなら中身の監査を。あのブロックはもう、あなたと Google とあらゆる LLM パイプラインの共用チャンネルです。

エージェント向けのツールを公開しているなら。この研究とスキル特化の実験は、反対側から同じ一点を指しています。ペイロードはそこら中にあり、結果を分ける変数はモデルで、ユーザーがどのモデルで走らせるかは選べない。注入がコンテキストに届く前提で設計し、届いたときに触れる範囲を絞ることです。エージェント自身はすでにそう動いています。エージェント専用 SNS の Moltbook では、フィードに紛れた悪意ある skill.md をエージェントたちが自分でスキャンしています。あそこでは投稿の一つひとつが、他のエージェントにとって信頼できない入力だからです。

最後は論文自身の読みを引きます。著者らは、データセットの過半が防御目的だったことを、サイト運営者にまともな伝達手段が無いことの証拠と解釈しています。機械に読まれることへのウェブの返答は、いまのところ機械へ話しかけ返すこと。1万5千回、そして増え続けています。