AIはどこまで指示と資料を見分けられるのか
サイトの記録や設定ファイルをAIに読ませるとき、その中に攻撃者が書いた文章が混ざっていることがあります。閲覧に使われたソフトウェアの名称や、アクセス先として指定されたパスは、アクセスしてきた側が中身を決められるためです。AIがそれを依頼の一部として扱えば、返ってくる内容はその文章に沿って変わります。この手口は「プロンプトインジェクション」(AIに読ませる文章の中へ指示を紛れ込ませ、動作を乗っ取る手口)と呼ばれます。
提供元各社は、この見分けに対策を重ねてきました。モデルの訓練で見分けを覚えさせ、入ってくる文章を検査する仕組みを別に置く、という組み合わせが基本です。2026年時点では、その効果が数値として公表されています。任せる範囲を決めるには、まずこの数値が何を測ったものかを見ておく必要があります。
Anthropicが2026年5月に公表した説明では、外部のベンチマークで測ったClaude Opus 4.7への攻撃の成功率は、単発の試行で約0.1%、結果を見ながら手を変える100回の試行のあとで5%から6%とされています。同社のコーディング支援では、行き過ぎた操作の約83%を実行前に捕捉したとも報告されています。ただしこの83%は捕捉できた割合であり、プロンプトインジェクションの成功率とは別の指標です。
複数のモデルを横並びで測った結果もあります。2026年3月に公表されたGray Swanの競技形式の試験(外部サイト)では、13種類の主要なモデルに対して464人が27万回を超える攻撃を試み、8,648件が成功しました。成功率はモデルによって0.5%から8.5%まで幅があり、まったく破られなかったモデルはありません。この試験で成功と数えられるには、有害な操作をさせることに加えて、それを利用者に気づかせないことの両方が必要でした。気づかれない形で通る攻撃が、主要なモデルすべてに存在したということです。
提供元自身も、完全に防げるとは説明していません。OpenAIは2026年2月、外部との接続を制限する保護設定をChatGPTに追加した際、この設定を有効にしても、取り込んだWebの内容やアップロードされたファイルに含まれる指示が応答の挙動や正確さに影響する可能性は残ると明記しています。
効き方には経路による差もあります。AIサービスが自分で取りに行った外部の情報は、モデルへ渡る前に検査を通せます。ところがAnthropicは同じ2026年5月の説明で、モデル側の対策は利用者の意図を手がかりにしているため、利用者自身が打ち込んだ指示には、分類器が異常として捉える手がかりがないと述べています。サーバーのログを自分で貼り付けて調べる場面は、この後者にあたります。
攻撃の段階
- 1
外部の文章へ指示を紛れ込ませる
攻撃者は、後でAIに読まれる可能性のある場所に、AIへの指示として読める文章を残します。Webページ、記録、送られてくる文書などが対象です。
- 2
検査の網から外れる
利用者が自分で貼り付けた内容は、AIサービスが自分で取りに行った情報とは別の経路で入るため、検査の効き方が変わります。
- 3
依頼の一部として扱われる
モデルは渡された文章を一続きの並びとして読むため、混ざった文章を依頼の続きとして扱うことがあります。
- 4
気づかれない形で結果に出る
事実と違う説明が返るか、作業を任せている場合はその指示どおりの操作が実行されます。改変を出力に書かせない指示が併せて仕込まれることもあります。
検算できる作業、できない作業、実行を伴う作業
公表されている成功率だけでは、自社の使い方が危ないかどうかは決まりません。同じ手口でも、すり抜けられたときに何が起きるかは、AIに何をさせているかで変わるためです。WordPressの運用でAIに頼む作業は、次の3つに分けて考えられます。以下の区分は、引用する研究が使っている分類ではありません。答えを検算できるかどうかと、AIに与える権限の大きさで分けています。
1つ目は、答えを元の記録から機械的に確かめられる作業です。特定の時間帯のアクセスを抜き出す、404が返ったパスを多い順に数える、更新日時が変わったファイルを並べるといった作業がこれにあたります。指示が混ざって狂っても、元の記録と突き合わせれば違いが分かります。ただし、狂った件数や並び順をそのまま受け取れば、侵害の痕跡を見落としたり、確認する順番を誤ったりします。直接の操作は起きませんが、初動が遅れる原因にはなります。
2つ目は、自由な文章で説明させる作業です。この改ざんの入口はどこか、このプラグインが原因かといった問いや、ログ全体の要約がこれにあたります。査読前の論文として2026年5月に公開された検証は、GPT-4o-miniを調査役に置き、48通りの条件でログ経由の攻撃を試しました。この検証で最も攻撃が通りやすかったのは要約を頼んだ場面です。要約に対して文脈を操作する手口を使った場合、防御を何もしない条件では96%、出力の形式を制限した条件でも38%が通りました。48通り全体を平均すると、防御なしで26.6%、研究内で最も強い防御を適用した条件で11.8%でした。答えを一つずつ元の記録に戻して確かめない限り、狂いは表面化しません。
3つ目は、操作まで実行させる作業です。プラグインを止める、ファイルを消す、アクセス制御の設定を書き換えるところまでAIに任せる使い方です。査読前の論文として2026年4月に公開された検証(外部サイト)では、クラウド上のログを読んで復旧の操作まで行うAIエージェントを対象に、8種類のモデルで試験が行われました。文章に混ざった指示のとおりにコマンドを実行した割合はモデルによって大きく違い、0%のものから86.2%に達したものまであります。8種類のうち6種類では、外部から任意の命令を実行できる状態まで到達しました。この検証で仕込みを検知できたのは、クラウド事業者が提供する検査機能で32件中1件と0件です。検知できることと被害を防げることは別ですが、検査機能に任せて操作権限を渡す使い方が成り立たないことは分かります。
ここで挙げた検証は、いずれもWordPressの運用そのものを試験したものではありません。使えるのは、同じ性質の作業でどの程度すり抜けが起きたかという目安までです。それでも線を引く位置は決まります。1つ目は、結果を元の記録で確かめる手順とセットなら任せられます。2つ目は、AIの答えを候補として受け取り、人が確かめてから採用する形にします。3つ目は、すり抜けられたときの結果が最も大きく、モデルによる差も最大です。操作の実行だけは人の手元に残すのが、最も少ない手間で効く区切りです。
なぜ完全には防げないのか
対策を重ねても0にならないのは、実装が足りないからではありません。言語モデルの作りに由来します。
モデルは、渡された文章を一続きの並びとして読みます。文章の中のどこまでが依頼で、どこからが調べる対象の資料なのかを、モデル単体で完全に保証することはできません。各社の対策は、その境界を訓練と検査によって推定しているにすぎず、推定である以上は外れる余地が残ります。2026年時点でも、この問題は業界として未解決の課題に分類されています。
確実に区切れるのは、モデルの外側です。実行できるコマンド、書き換えられるファイル、通信できる相手をシステム側で制限すれば、モデルが誤って従っても行える範囲は決まります。Anthropicも、モデル側の確率的な対策に加えて、この種の封じ込めを重ねることを勧めています。運営者の側でこれにあたるのが、AIに操作の権限を渡さないという線引きです。
この性質は、時間の面でも現れます。査読前の論文として2026年7月に公開された検証は、仕込まれた文章が「保存され、後から読まれたときに初めて効く」という形で作用することを整理しました。文章が書き込まれた時点では何も起こりません。攻撃を受けた日と、その記録を読ませた日が離れていても成立するということです。
同じ検証では、3種類のモデルと約1万3,000行のログを使った試験で、入力の検査、指示の固定、出力の点検を組み合わせた条件でも、攻撃の成功率が8.4%残ったと報告されています。これは1本の査読前研究の条件下での値です。それでも0にはならないという点は、前掲した各社の説明とも一致します。
拒否されるか、誤作動するか
AIを守るために使う側は、攻撃に使う側にはない不確かさを2つ抱えます。
1つは、断られることです。市販のAIには、悪用につながりかねない内容を断る安全機能があります。Hugging Faceは2026年7月の侵害対応で、攻撃者が実際に使った命令を分析させようとしましたが、提供元の安全機能に止められ、自社の環境で動かす別のAIに切り替えました。同社は、安全機能には対応にあたっている人と攻撃者を見分ける手立てがない、と説明しています。
もう1つが誤作動です。同じ安全機能を持つAIが、調べる対象として渡された文章に紛れた指示には従うことがあります。断るべきでないものを断り、従うべきでないものに従う、という向きの食い違いが両方とも起きています。攻撃する側にこの不確かさはありません。記録に文章を残すために生成AIを使う必要はないためです。
調べる対象そのものを減らす
AIの側の不確かさは、使い方を工夫しても消えません。運営者の側で減らせるのは、そもそも調べなければならない対象の量です。
WordPressのページをあらかじめ作っておき、公開側では見せるだけにする構成(WordPress静的移行)にすると、公開側でPHPとデータベースが動かなくなります。侵害の経路が減るぶん、改ざんが起きたときに照合する対象も、公開側のPHPファイル、データベースの中身、公開側で動くプラグインの分だけ減ります。公開しているファイルは手元のデータから生成したものなので、正しい状態がいつでも定義でき、書き換えられても生成し直せます。記事の編集は管理画面で従来どおり行えますが、その管理環境と配置の仕組みは残るため、そちらの運用対策は別途必要です。
減らせるのはここまでです。アクセスログには静的移行後も攻撃者が書いた文字列が残りますし、AIの出す答えを元の記録で確かめる作業もなくなりません。調べる対象が減れば確認は速くなりますが、何が起きたのかを決めるのは引き続き人の仕事です。任せる範囲を先に決めておけば、返ってきた内容をどこまで信用するかで迷わずに済みます。
参考情報(外部サイト)
本文で参照した外部の公開情報です。
- How we contain Claude(2026年5月。攻撃成功率と、利用者自身の入力に対策が効きにくい理由)(外部サイト)(Anthropic)
- Your AI Agent Can Be Compromised. You'd Never Know.(2026年3月。13モデルを対象とした試験結果)(外部サイト)(Gray Swan AI)
- Introducing Lockdown Mode and Elevated Risk labels in ChatGPT(2026年2月)(外部サイト)(OpenAI)
- LogJack: Indirect Prompt Injection Through Cloud Logs Against LLM Debugging Agents(査読前の論文、2026年4月公開)(外部サイト)(arXiv)
- Poisoning the Watchtower: Prompt Injection Attacks Against LLM-Augmented Security Operations Through Adversarial Log Content(査読前の論文、2026年5月公開)(外部サイト)(arXiv)
- Context Contamination in LLM Analysis of Network Security Logs(査読前の論文、2026年7月公開)(外部サイト)(arXiv)
- LLM01:2025 Prompt Injection(外部サイト)(OWASP Gen AI Security Project)
- Security incident disclosure — July 2026(外部サイト)(Hugging Face)