WordPressの調査と運用をAIにどこまで任せてよいか

AIはどこまで指示と資料を見分けられるのか

サイトの記録や設定ファイルをAIに読ませるとき、その中に攻撃者が書いた文章が混ざっていることがあります。閲覧に使われたソフトウェアの名称や、アクセス先として指定されたパスは、アクセスしてきた側が中身を決められるためです。AIがそれを依頼の一部として扱えば、返ってくる内容はその文章に沿って変わります。この手口は「プロンプトインジェクション」（AIに読ませる文章の中へ指示を紛れ込ませ、動作を乗っ取る手口）と呼ばれます。

提供元各社は、指示と資料を見分けられるよう対策を重ねてきました。モデルの訓練で見分けを覚えさせ、入ってくる文章を検査する仕組みを別に置きます。訓練と検査を組み合わせるのが基本です。2026年時点では、その効果が、提供元や第三者の試験で数値として公表されています。任せる範囲を決めるには、まずこの数値が何を測ったものかを見ておく必要があります。

AIの安全性を試験する会社Gray Swanが2026年3月に公表した競技形式の試験（外部サイト）は、複数のモデルを横並びで測っています。同社によると、13種類の主要なモデルに対して464人が27万回を超える攻撃を試み、8,648件が成功しました。同社は、成功率はモデルによって0.5%から8.5%まで幅があったと報告しています。この試験で成功と数えられるには、有害な操作をさせることに加えて、それを利用者に気づかせないことの両方が必要だったと、同社は説明しています。同社は、気づかれない形で通る攻撃が、試験した13種類のモデルのすべてで見つかったと報告しています。

提供元自身も、完全に防げるとは説明していません。OpenAIは、2026年2月に外部との接続を制限する保護設定をChatGPTの法人向けプランに入れ、6月に個人向けへの提供を始めたと公表しています。同社の説明ページは、設定を有効にしても、取り込んだWebの内容やアップロードされたファイルに含まれる指示が応答の挙動や正確さに影響する可能性は残ると書いています。データの持ち出しが起きないことを保証するものではない、とも明記しています。

利用者が自分で貼り付けた文章に混ざった指示でも、AIの動きは変わります。Anthropicは2026年9月に公表したClaude Opus 5.5の技術文書（システムカード）で、README（ソフトウェアに添える説明書き）やメール、Webページのように他人が書いた文章を利用者が貼り付ける場面を取り上げています。同社は、他人が書いた文章を貼れば、その人にプロンプト（AIへの依頼文）の一部を書かせることになると説明しています。同社は例として、貼り付けたnpm install（部品を取り込むコマンド）の出力の最終行に、攻撃者がAIへの指示を書いていたものを挙げています。サーバーのログを自分で貼り付けて調べる場面も、他人が書いた文章を貼る場面にあたります。ログには、攻撃者が書き込める欄があるためです。

同社によると、コーディングの作業で測った試験では、公開された版のOpus 5.5が仕込まれた指示に沿って動いた割合は、考える量を既定にした設定で約2%、最大にした設定で約7.4%でした。同社は、この試験はあからさまに有害な指示に絞って測ったものだとしています。同社は、以前のモデルのうちClaude Opus 5とClaude Sonnet 5は同じ試験で一度も従わなかったとしています。Opus 5.5では、この点が以前のモデルより弱くなっています。同社は、同じ条件で製品の対策を加えると実行は0件だったとしています。そのうえで、Anthropicは、貼り付けた文章に印を付けるといった製品の変更を加えているところだとしています。また、攻撃者が細工した文章を利用者が貼った場合に完全に耐えられるモデルは無いとしつつ、訓練と安全対策の変更が、この弱さによるデータや認証情報の持ち出しといった問題を防ぐ助けになるとしています。

検算できる作業、文章やコードを書かせる作業、実行を伴う作業

公表されている成功率だけでは、自社の使い方が危ないかどうかは決まりません。同じ手口でも、すり抜けられたときに何が起きるかは、AIに何をさせているかで変わるためです。WordPressの運用でAIに頼む作業は、次の3つに分けて考えられます。以下の区分は、引用する研究が使っている分類ではありません。答えを検算できるかどうかと、AIに与える権限の大きさで分けています。

1つ目は、答えを元の記録から機械的に確かめられる作業です。特定の時間帯のアクセスを抜き出す、404が返ったパスを多い順に数える、更新日時が変わったファイルを並べるといった作業がこれにあたります。指示が混ざって狂っても、元の記録と突き合わせれば違いが分かります。ただし、狂った件数や並び順をそのまま受け取れば、侵害の痕跡を見落としたり、確認する順番を誤ったりします。直接の操作は起きませんが、初動が遅れる原因にはなります。

2つ目は、自由な文章やコードを書かせる作業です。この改ざんの入口はどこか、このプラグインが原因かといった問いや、ログ全体の要約がこれにあたります。査読前の論文として2026年5月に公開された検証（外部サイト）は、GPT-4o-miniを調査役に置き、48通りの条件でログ経由の攻撃を試しました。著者らは、この検証で最も攻撃が通りやすかったのは要約を頼んだ場面だと報告しています。著者らによると、要約に対して文脈を操作する手口を使った場合、防御を何もしない条件では96%、出力の形式を制限した条件でも38%が通りました。4種類の手口と3種類の作業（分類・要約・対処の提案。どれも答えを返すだけで、操作は伴いません。分類は決まったラベルを選ぶ作業で、自由な文章は書きません）をすべて平均すると、防御なしで26.6%、研究内で最も強い防御（出力の形式の制限）で11.8%だったと、著者らは報告しています。答えを一つずつ元の記録に戻して確かめない限り、狂いは表面化しません。

3つ目は、操作まで実行させる作業です。プラグインを止める、ファイルを消す、アクセス制御の設定を書き換えるところまでAIに任せる使い方です。査読前の論文として2026年4月に公開された検証（外部サイト）では、クラウド上のログを読んで復旧の操作まで行うAIエージェントを対象に、8種類のモデルで試験が行われました。著者によると、コマンドを実行して直せるとAIに伝えただけの条件で、文章に混ざった指示のとおりのコマンドを、実行するための道具（ツール）へ渡した割合はモデルによって大きく違い、0%のものから86.2%に達したものまであります（0%は、この条件で指示どおりのコマンドを渡さなかったという結果で、そのモデルが安全という意味ではありません）。著者は、8種類のうち6種類が、外部から任意の命令を実行させるコマンドを渡したと報告しています。著者は、渡されたコマンドを実行せずに止めて分類する形で試験したとしています。著者によると、クラウド事業者2社が提供する検査機能が仕込みを検知したのは、それぞれ32件中1件と0件でした（3社目の検査機能は、ツールが返した結果を検査しないとして、値を出していません）。検査機能が動いていることを理由に操作の権限を渡す判断は、この検証の条件では支えられません。言えるのはそこまでで、1本の査読前研究の結果です。

操作を任せたときの結果の大きさは、攻撃がなくても表に出ます。Decryptによると、PocketOSは、レンタカー事業者向けのソフトウェアを提供する会社です。2026年4月、同社の創業者は、AIのコーディング支援（CursorでClaude Opus 4.6を使用）が、本番とは別の試験用の環境での日常的な作業の途中で、API（サービスを外から操作する窓口）を1回呼び出して本番のデータベースを消したと公表しています。創業者は、データベースの入った領域ごとに取っていたバックアップも消え、戻せる最新のバックアップは3か月前のものだったとしています。使ったAIと経緯は創業者の投稿にもとづくもので、Decryptの記事（外部サイト）は、CursorとAnthropicが取材にすぐには答えなかったとしています。クラウド事業者のRailwayは、使われた操作用の鍵（APIトークン）はあらゆる操作を許されたもので、削除は取り消しの猶予が無い古い経路を通ったと説明しています。Decryptによると、PocketOSは、Railwayが戻した3か月前のバックアップで事業を再開しました。Railwayは、問い合わせへの対応が社内で24時間以上止まっていたと認め、同社の創業者がPocketOSの創業者と連絡を取ってから30分で利用者のデータを戻したと説明しています。PocketOSの創業者は、大きな欠落が残っているとしています。

ここで挙げた検証と事故は、いずれもWordPressの運用そのものではありません。使えるのは、同じ性質の作業で何が起きたかという目安までです。それでも線を引く位置は決まります。1つ目は、結果を元の記録で確かめる手順とセットなら任せられます。2つ目は、AIの答えを候補として受け取り、人が確かめてから採用する形にします。3つ目は、AIの判断が誤ったときの結果が最も大きくなります。操作の実行だけを人の手元に残せば、人が中身を確かめてから実行する機会が残ります。ただし、確かめずに承認するだけなら止める役には立ちません。Anthropicは2026年5月に公表した説明（外部サイト）で、以前のClaude Code（同社のコーディング支援の道具）では、利用者が承認の確認画面の約93%をそのまま通していたと書いています。

攻撃がなくても問題が起きるのは、操作だけではありません。AIが考えた直し方でも、脆弱性が残ることがあります。1Passwordの研究チームOff-by-1 Labsは、公表されて間もない6件の脆弱性について、ChatGPT-5.5とOpus 4.8に修正案を作らせ、2026年8月に結果を報告しています（外部サイト）。同チームによると、動作を変えずに脆弱性を解消できた修正案は、原因や直し方について誤った情報を混ぜた指示も含めた平均で26.0%です。同チームは、確かめた正しい情報だけを渡した場合でも31%、誤った情報を渡した場合は15%だったとしています。同チームは、同じ平均で、解消はしたものの動作が変わってしまったものが20.1%、脆弱性が残るか新しく作り込むかしたものが53.9%を占めたと報告しています。修正案を作らせる条件は、開発者が最初に選ぶ妥当な設定と費用の上限に合わせたと、1Passwordは説明しています。2026年10月26日付で更新された現在の版で、1Passwordは、公表の後に、AIエージェントで修正案を作る場合にはその条件が出力を縛りすぎていたという指摘を受けたとも書いています。

対象の6件に、WordPressの脆弱性は入っていません。研究チームは、公表されて間もなく、修正に複雑な変更が要る脆弱性を選んだとしています（公表されて間もないものを選んだのは、AIの学習データに修正が含まれていない可能性が高いものを試すためだと説明しています）。設定を一行書き換えるような作業まで、同じ割合になるとは限りません。それでも、研究チームが測ったのは修正案の中身であって、誰が適用したかは検証の対象に含まれていません。返ってきた修正案をそのまま当てれば、手を動かしたのが人でも結果は同じです。1Passwordは試験したモデルの提供元に意見を求め、Anthropicからの意見と推奨として、いまのモデルの能力では専門家を最終の確認役に残すことを載せています。修正案を作らせる作業は3つのうち2つ目にあたり、攻撃者がいなくても、候補として受け取って確かめる扱いが要ります。

なぜ完全には防げないのか

対策を重ねても0にできると保証できないのは、指示と資料の境界をモデルが推定で決めているためです。実装を足せば解消する問題ではなく、言語モデルの作りに由来します。

モデルは、渡された文章を一続きの並びとして読みます。文章の中のどこまでが依頼で、どこからが調べる対象の資料なのかを、モデル単体で完全に保証することはできません。各社の対策は、その境界を訓練と検査によって推定しているにすぎず、推定である以上は外れる余地が残ります。OWASPは2025年版のプロンプトインジェクションの解説（外部サイト）で、モデルの仕組みに確率的な揺らぎがある以上、確実に防ぐ方法があるかは分からないとしています。

確実に区切れるのは、モデルの外側です。実行できるコマンド、書き換えられるファイル、通信できる相手をシステム側で制限すれば、モデルが誤って従っても行える範囲は決まります。Anthropicも、まず環境の側で封じ込め、そのうえでモデルの側で振る舞いを導くことを、自社の設計の原則に挙げています。運営者の側でこれにあたるのが、AIに操作の権限を渡さないという線引きです。

対策を打ちにくい事情は、時間の面にもあります。査読前の論文として2026年7月に公開された検証（外部サイト）は、記録を生む欄に仕込まれた文章が保存され、担当者がAIに問い合わせたときに実行される形の攻撃を、受け身のプロンプトインジェクションと名づけて整理しています。文章が書き込まれた時点では何も起こりません。攻撃を受けた日と記録を読ませた日が離れていても、攻撃は成立します。

著者らは、2024年ごろの世代の3種類のモデルと、約1万3,000行のログを使った試験の結果も報告しています。防御の効き方はGPT-4oで測っており、入力の検査、指示の固定、出力の点検を組み合わせた条件でも、攻撃の成功率が8.4%残ったと報告されています。これは1本の査読前研究の条件下での値です。防御を重ねても0にできると保証できないという点は、前掲した各社の説明とも一致します。

拒否されるか、誤作動するか

サイトを守るためにAIを使う側は、2つの不確かさを抱えます。

1つは、断られることです。市販のAIには、悪用につながりかねない内容を断る安全機能があります。Hugging Faceは、2026年7月の侵害対応で、攻撃者が実際に使った命令を市販のAIに分析させようとしたところ、提供元の安全機能に止められ、自社の環境で動かす別のAIに切り替えたと公表しています。同社は、安全機能には対応にあたっている人と攻撃者を見分ける手立てがない、と説明しています。

もう1つが誤作動です。市販のAIが備える対策では、調べる対象に紛れた指示を確実には防げません。前に挙げた測定のとおりです。

市販のAIが侵害の調査を断った実例を確認する →

調べる対象そのものを減らす

AIの側の不確かさは、使い方を工夫しても消えません。運営者の側で減らせるのは、AIに任せる範囲と、そもそも調べなければならない対象の量の2つです。任せる範囲は、3つの作業に分けて線を引きました。ここでは対象の量を扱います。

WordPressのページをあらかじめ作っておき、公開側では見せるだけにする構成（WordPress静的移行）にすると、公開側でPHPとデータベースが動かなくなります。侵害の経路が減るぶん、改ざんが起きたときに照合する対象も、公開側のPHPファイル、データベースの中身、公開側で動くプラグインの分だけ減ります。公開しているファイルは手元のデータから生成したものなので、正しい状態がいつでも定義でき、書き換えられても生成し直せます。記事の編集は管理画面で従来どおり行えます。ただし、管理環境と配置の仕組みは残るので、別に対策が要ります。

減らせるのはここまでです。アクセスログには静的移行後も攻撃者が書いた文字列が残りますし、AIの出す答えを元の記録で確かめる作業もなくなりません。調べる対象が減れば確認は速くなりますが、何が起きたのかを決めるのは引き続き人の仕事です。任せる範囲を先に決めておけば、返ってきた内容をどこまで信用するかで迷わずに済みます。