プロンプトインジェクション完全防御は数学的に不可能—情シスの現実解

研究・論文

プロンプトインジェクション攻撃の完全防御は、現在のLLMアーキテクチャでは数学的に不可能——2026年6月、arXivに投稿された研究論文がこう証明しました。これまで提案されてきた防御策がすべて回避されてきたのは偶然ではなく、構造的な必然だったのです。

この記事でわかること：

  • 論文が示す「完全防御不可能」の数学的根拠
  • なぜ現在のLLMは命令とデータを区別できないのか
  • 既存の防御策の限界と、情シスが取るべき現実的な多層対策

※本記事は査読前のプレプリント（arXiv:2606.27567）に基づく内容です。結論は今後の査読により変わりうる点にご留意ください。

何が証明されたのか

Pant・Lohani・Kumarによる論文「On the Inseparability of Instructions and Data in Shared-Embedding Sequence Models」（arXiv:2606.27567、2026年6月25日投稿）は、現行のLLM（GPT・Claude・Geminiなど）が採用する「共有埋め込みアーキテクチャ」において、命令（システムプロンプト）と外部データ（ユーザー入力・取得コンテンツ）を完全に分離することが原理的に不可能であると主張しています。

論文はSemantic-Faithful Control（SFC）という概念を定義し、「信頼できない入力の意味にのみ依存し、その符号化方法には依存しない動作」が実現不可能であることを、以下の3つの証明で示しています。

  • Provenance-Recovery不可能性：共有埋め込み表現では「信頼できるトークン」と「信頼できないトークン」を統計的に区別できない
  • Control-Path曝露：信頼できないトークンが、出力決定と同じアテンション機構を通じてモデルの動作制御に干渉できる
  • 有限カバレッジ不変性ギャップ：有限の訓練データでは、意味的に等価な無限のプロンプトバリエーションに対し不変性を保証できない

要するに「悪意あるテキストをどんな形式で書こうとも、意味的に等価なバリエーションは無限に存在し、訓練済みモデルがそのすべてを拒絶することは不可能」という証明です。

なぜ「完全防御が不可能」なのか——仕組みの理解

現在のLLMは、開発者が書いたシステムプロンプトと、ユーザーの入力や外部から取得したコンテンツを、同じ数値ベクトル（埋め込み）として処理します。モデルは「これは命令」「これはデータ」という構造的な区別を持っていないため、悪意ある外部コンテンツが「命令として振る舞う」ことを根本的に防ぐ手段がありません。

論文はこれをVon Neumannアーキテクチャにおけるバッファオーバーフロー問題に類比しています。命令とデータを同一メモリ上に置く設計上の制約が、当時の「理論上は安全なコード」をすべて脆弱にしたように、現在の共有埋め込みLLMも同じ構造的問題を抱えているという指摘です。

既存の防御策の限界

これまで提案されてきた主な防御策と、その限界を整理します。

防御策 限界
プロンプトフィルタリング 意味的に等価な変形バリエーションを網羅できない
入力サニタイズ LLMの埋め込み空間ではサニタイズの効果が限定的
防御的ファインチューニング 有限の訓練では無限の攻撃バリエーションを学習できない
RAG・外部データソースの隔離 共有埋め込み上ではデータが命令として作用しうる

OWASP LLM Top 10でも「プロンプトインジェクション（LLM01）」は最大の脅威として挙げられており、完全な防御手段は存在しないという認識は業界共通です。今回の論文はその事実を数学的に裏付けた形です。

現場目線：「完璧な防御がある」という過信が危ない

「こんな仕組みのものを本当に業務で使っていいのか」という問いは、LLM活用を検討・推進する情シス担当者なら一度は抱いたはずです。ベンダーは「プロンプトエンジニアリングで対策できる」「ファインチューニングで改善できる」と説明しますが、今回の論文はそのような主張に根本的な疑問を投げかけています。

特に危険なのは「防御策を入れたから安全」という過信です。限られた人員でLLM連携システムを管理する情シスにとって、「完璧な防御は存在しない」という事実を前提に設計・運用方針を決めることが、現実的な安全確保の第一歩になります。

情シスはどうすべきか

論文が示唆するのは、ソフトウェア的なプロンプト防御に依存せず、アーキテクチャレベルの分離と多層防御を組み合わせることです。

AIシステムのリスク管理の指針として、IPAの「情報セキュリティ関連情報（IPA）」やOWASP GenAI Security Projectの「LLM Top 10」が参考になります。現実的な対策の軸として、以下の4点が重要です。

  • LLMに与える権限を最小化する：メール送信・ファイル削除・外部API呼び出しなど「高権限アクション」をLLMが直接実行できる構成を避け、必ず人間の承認ステップを挟む
  • 外部コンテンツ処理と内部命令処理を分離する：可能であれば、Webページ取得・メール処理など外部コンテンツを扱うLLMと、業務ロジックを制御するLLMを別インスタンスにする（アーキテクチャ的分離）
  • 重要アクションの前に人間確認フローを設ける：特にメール送信・データ変更・承認処理など不可逆な操作は、LLMの出力をそのまま実行せず人間が最終確認する
  • インシデント発生を前提に、ログとモニタリングを整備する：攻撃を完全に防ぐのではなく「攻撃されたことを即座に検知する」体制が現実的な安全確保の核心

中長期の視点：根本的解決はアーキテクチャの変革

論文は「命令チャネルとデータチャネルの建築的分離」が根本的な解決策だと述べています。つまり、現在の共有埋め込みLLMではなく、命令とデータを明示的に別ルートで処理するアーキテクチャへの移行が必要という提言です。

これは数年単位の変化を要するものであり、現時点では「完璧な防御がないことを前提に運用する」という姿勢が現実的です。LLMを組み込んだシステムを構築・導入する際は、プロンプトインジェクション耐性への過度な期待を捨て、「攻撃された場合の被害を最小化する設計」を優先することが重要です。

まとめ

  • 査読前研究（arXiv:2606.27567）が、現行の共有埋め込みLLMにおけるプロンプトインジェクションの完全防御が数学的に不可能であることを証明した
  • 原因は「命令とデータを同じ埋め込みで処理する」構造的制約にあり、フィルタリングやファインチューニングでは根本解決できない
  • 情シスとしては「完璧な防御の過信を捨て」、LLMの権限最小化・アーキテクチャ的分離・人間による確認フローという多層防御で対応する

出典

タイトルとURLをコピーしました