2025年11月7日、OpenAIは「Understanding prompt injections: a frontier security challenge」を公開し、プロンプトインジェクションを“hard, open problem”と明記した。さらに2025年12月22日の「Continuously hardening ChatGPT Atlas against prompt injection attacks」では、エージェント安全性における未解決課題として「years to come（今後何年にもわたり取り組む課題）」と位置づけ、決定論的な安全保証が難しいことを明示した。これは単なる実装バグではなく、AIエージェントの設計原理に近い脆弱性であることを意味する。

本稿では、OWASP LLM Top 10でLLM01に置かれる背景、AIブラウザに固有の攻撃面、そして「完全防御」ではなく「確率を下げ続ける」運用設計への転換を整理する。

OpenAIが示した「パッチ不可能に近い長期リスク」の技術的意味

OpenAIの2025年12月22日付の公開情報は、プロンプトインジェクションを「open challenge for agent security」と定義し、同時に「deterministic security guarantees are challenging」と述べる。ここで重要なのは、攻撃が単一の入力バリデーション不備ではなく、モデルが自然言語命令を解釈する方式そのものを突く点である。

従来のWeb攻撃（SQLi/XSS）では、構文境界を厳密に分離すれば防御可能性が高まる。一方、エージェント型LLMは「命令」と「データ」が同じ自然言語空間に共存するため、境界が統計的にしか表現できない。OpenAIが“長期戦”を公言したのは、この構造的制約を踏まえた現実的評価と解釈できる。

OWASP LLM01がTop 1であり続ける理由

OWASP GenAI Security ProjectのLLM Top 10 for 2025では、LLM01がPrompt Injectionである。ここでの定義は、ユーザー入力や外部コンテンツがモデルの意図しない挙動を誘発する脆弱性であり、可視テキストに限らず機械可読コンテキスト全体が攻撃面になる点を強調している。

このリスクが上位から落ちない理由は3つある。第一に、メール、カレンダー、Web、添付ファイル、ツール出力など入力経路が増えるほど攻撃面が非線形に拡大すること。第二に、モデル能力向上で実行可能アクション範囲（送信、購入、更新、削除）が広がり、成功時の被害が大きくなること。第三に、防御が主として確率低減策であり、ゼロリスク化が困難であることである。

「73%検出」データの読み方: 何が確かで、何が不確かか

「本番環境の73%で検出」といった数値は市場で広く流通しているが、一次情報として再現可能な測定設計が添付されない場合があるため、意思決定では注意が必要である。例えば2025年8月21日のAugment Code記事は「73% of production AI systems」と述べるが、母集団・測定条件の透明性には限界がある。

一方、学術側では2025年11月19日公開のarXiv論文「Securing AI Agents Against Prompt Injection Attacks」が、847件の攻撃ベンチマークで防御前ASR 73.2%→防御後8.7%を報告している。これは“本番実測”ではなくベンチマーク結果だが、少なくとも測定条件が明示され、比較可能性がある。実務では、マーケティング由来の単一パーセンテージを鵜呑みにせず、攻撃成功率（ASR）を自社ワークフローで継続測定する姿勢が不可欠である。

現実的対処戦略: 「防ぎ切る設計」ではなく「被害を閉じ込める設計」へ

OpenAIのComputer Useガイド（2026年2月18日閲覧）は、高リスク用途で人間承認を必須化し、信頼済み分離環境（sandbox/container）での運用、allowlist/blocklist、安全チェック発火時の手動介入を推奨している。これは、モデル単体防御の限界を前提にしたシステム設計指針である。

実装優先度は次の順でよい。第一に権限最小化（トークン範囲、操作可能ドメイン、ツール能力の厳格化）。第二に行為ベースの承認（送金・送信・削除は必ず人間確認）。第三に観測性（安全チェック、異常遷移、外部送信先の監査ログ）。第四に継続レッドチーミング（新規攻撃テンプレートの週次追加）。第五にインシデント前提運用（ロールバック・資格情報失効・通知手順の自動化）。

要するに、確率的システムの安全保障は「単発パッチで終了する問題」ではない。防御の目的は、突破確率を下げ、突破時の被害半径を狭め、検知から復旧までの時間を短縮することである。OpenAIの“完全防御は難しい”という認識は悲観ではなく、エージェント時代に必要な設計原則の出発点である。

FAQ

Q1. なぜプロンプトインジェクションは従来の入力検証だけでは不十分なのか？

LLMでは命令とデータが同じ自然言語空間に入り、境界分離が構文レベルで固定しにくいからである。よって入力検証は必要条件だが十分条件ではない。

Q2. 「確率的脆弱性」とは具体的に何を指すのか？

同一防御設定でも攻撃文面・文脈・反復回数で成功率が変動する性質である。脆弱性の有無を二値でなく、ASRの分布として管理する必要がある。

Q3. 実務で最初に着手すべき対策は何か？

高権限アクションへの人間承認ゲートと、実行環境のサンドボックス化である。これだけでも攻撃成功時の被害を大幅に制限できる。

Q4. 73%のような単一指標を経営判断に使ってよいか？

単独では不十分である。出典の測定設計、対象業務、母集団を確認し、自社の攻撃シナリオで再計測した値と併用すべきである。

Q5. 将来的に「完全防御」は可能になるのか？

現時点の公開知見では、完全防御を前提にした設計は現実的でない。防御層の多重化と運用継続でリスクを管理するのが実務的である。

参考文献