プロンプトインジェクションの本質は「役割の混同」—LLMの脆弱性を理論的に解き明かす

LLMが見ている世界—「トークンスープ」の現実

LLMの動作原理を理解するには、ユーザー側の視点ではなく、モデル自身が何を受け取っているのかを知る必要があります。

私たちチャットインターフェースでは、システムプロンプト、ユーザーメッセージ、ツール出力といった各要素が明確に区切られているように見えます。しかし、LLMが実際に受け取るのは、これらすべてが連結された単一の長い文字列です（出典）。

LLMの知識や推論、記憶のすべては、重みを除けば一本の文字列の中に存在します。

システムプロンプット、ユーザーの指示、外部データ、LLM自身の前の出力—これらが区別されずに同じチャネルから流れ込むため、モデルは「どこからのテキストが信頼できるのか」を判断する特別な感覚がありません。

人間であれば、自分の思考と他者の言葉は脳に到達するチャネルや感覚的性質（耳から聞こえるか、考えているのか）で自動的に区別できます。しかし、LLMにはそのような感覚的な区別がないのです。すべてがトークンの連続なので、文字列を編集すれば、モデルの「現実」そのものが書き換わります。

役割タグ—構造を与える試み

この問題に対する対策が「役割タグ（role tags）」です。OpenAIなどのプロバイダーは、テキストをモデルに送る前に自動的に役割タグを挿入します（出典）。

一般的な役割タグは以下の通りです：

• system：システムプロンプト、モデルのふるまい方を定義
• user：人間からの指示や質問
• assistant：LLM自身の出力（推論を除く）
• think：LLM自身の内部推論（信頼できるプライベートな思考）
• tool：外部ツールやAPI呼び出しの結果

各タグは、その後に続くテキストをどのように扱うべきかをモデルに指示します。userタグなら「人間からの指示」として受け取り、toolタグなら「外部データ」として警戒的に扱い、thinkタグなら「信頼できる内部推論」として受け入れるといった具合です。

役割タグは、LLMが知覚や身体を通じて得られる構造を、ラベルによって再構成する唯一の離散的な制御手段です。

役割の過負荷—セキュリティの脆弱性へ

しかし、役割タグは設計当初よりもはるかに多くの責任を背負わされるようになりました（出典）。

このような過負荷状態が、プロンプトインジェクション攻撃を可能にしているのではないでしょうか。設計者が想定した役割の使い方と、実際にモデルが処理する役割の意味のあいだにズレが生じやすくなるからです。

プロンプトインジェクションが成功する条件

この研究の重要な貢献は、「なぜプロンプトインジェクション攻撃が成功するのか」を役割の概念から説明している点です。

攻撃者がuserタグの領域に悪意あるテキストを挿入しても、理論上はmodelがそれを「ユーザーからの指示」として認識して動作すべきです。しかし、実際には攻撃が成功するケースが多い。これは、役割タグがモデルの内部表現にどの程度影響するのか、あるいは特定の役割の組み合わせでその影響が弱まるのかという点で、まだ完全に理解されていないことを示唆しています。

役割システムが完全に機能していないからこそ、プロンプトインジェクションという脅威が生まれています。

実装への示唆

この理論的フレームワークは、AI開発者にとって実務的な指針になりえます。

• マルチエージェント環境での役割設計：参考記事でも触れられているように、エージェント同士がプロンプトで連鎖的に動作する「ループ」構造（出典）では、各エージェント間の役割境界が曖昧になりやすい
• ローカルLLMでの役割タグの実装：自作PCでStable DiffusionやローカルLLMを運用するエンジニアの方であれば、公開モデルの役割タグをカスタマイズする際に、この理論が役立つかもしれません
• Prompt Optimization戦略：Cisco AIが発表した自動プロンプト最適化システム「FAPO」（出典）のような自動最適化ツールでも、役割の混同を検出・修正するロジックが組み込まれる可能性があります

セキュリティとロバストネスの未来像

この研究は、LLMのセキュリティ問題を「パッチあたりの試行錯誤」ではなく「原理的な設計の見直し」として捉え直すきっかけになるのではないでしょうか。役割システムの過負荷状態を解消し、より明確な役割階層や新しい区別メカニズムを導入することで、より堅牢なLLM応用を実現できるはずです。