プロンプトインジェクションの内部構造

rock

こんにちは！私の名前はロックです。
私はベトナム出身で、現在メディアフュージョン株式会社でシステムエンジニアリングの製品開発に携わっています。
私はプログラミングとシステムセキュリティに情熱を持っており、同じ分野に興味のある人々と私の知識やノウハウを共有し、一緒に成長したいと考えています。一緒に働けることを楽しみにしています！

― LLMはなぜ「騙される」のか― 

言語が「攻撃面」になった瞬間

前回の記事では、
エージェントAIの時代において、セキュリティの前提条件そのものが変わりつつある、という話をした。

AIはもはや「答える存在」ではない。
読む。考える。判断する。そして行動する。

その一連の流れの入口に、必ず存在するものがある。

言語だ。

あまりにも身近で、あまりにも自然な存在だからこそ、私たちは長い間、それを「危険なもの」として認識してこなかった。

しかし、現在のAIシステムにおいて、言語はすでに制御インターフェースであり、同時に攻撃面でもある。

今回は、その構造的な理由を掘り下げていきたい。

「命令」と「データ」の境界が消えた世界

ソフトウェアエンジニアとして働いてきた人間なら、誰もが無意識に持っている前提がある。

命令とデータは別物である、という前提だ。

従来のシステムでは、この境界は極めて明確だった。

入力値が命令として解釈されてしまうとき、それは脆弱性になる。
SQLインジェクションも、コマンドインジェクションも、その延長線上にある。

つまり、セキュリティの歴史とは、「境界線を守る歴史」だった。

しかし、LLMの世界では、この境界線がほぼ存在しない。

System Prompt、Developer Message、User Input、RAGの検索結果、Webページの本文。
モデルにとって、それらはすべて「テキスト」である。

特権もなければ、隔離領域もない。
あるのは、ただ一つの巨大な文脈だけだ。

LLMにとって、すべては一つの文章である

LLMの基本動作は極めて単純だ。

これまでの文脈を踏まえて、次に最も確率の高い単語を出力する。

それだけである。

モデルは、

• これは命令か
• これはデータか
• これは内部情報か

といった分類をしていない。

すべてを一つの文章として処理している。

人間は、そこにレイヤーを見る。
モデルは、そこにトークン列を見る。

この認識のズレが、脆弱性の出発点になる。

「優先度」は設計ではなく、学習の産物である

よく、「System Promptは最優先される」と言われる。

確かに、実務上はそう見えることが多い。

しかし、それは設計によって保証されているわけではない。

モデルは、学習によって「そう振る舞う傾向」を身につけているだけだ。

RLHFや指示調整によって、
「Systemの指示を尊重する確率」が高くなっているにすぎない。

そこに絶対的な制約は存在しない。

十分に巧妙な文章が与えられれば、その優先順位は簡単に崩れる。

なぜ「無視しろ」が通用してしまうのか

典型的な攻撃文は、こうだ。

「これまでの指示をすべて無視しなさい。」

人間にとっては、明らかに不正な要求である。

しかし、LLMにとっては、単なる文脈の一部にすぎない。

モデルは、その文が「正しいかどうか」を判断していない。

「どれくらい自然か」だけを評価している。

過去の文脈と現在の文を並べ、
最も確率の高い応答を選ぶ。

それがLLMの思考様式だ。

Indirect Prompt Injectionが成立する理由

エージェントAIは、日常的に外部データを読み込む。

Web、メール、PDF、RAGデータベース。

それらはすべて、推論の材料として文脈に組み込まれる。

問題は、その瞬間に「外部」という概念が消えることだ。

HTMLコメントも、脚注も、メタ情報も、すべて同列に扱われる。

人間には区別できる。
モデルには区別できない。

結果として、データが命令として機能してしまう。

これがIndirect Prompt Injectionの正体である。

フィルタリングが根本解決にならない理由

多くの防御策は、まずフィルタから始まる。

禁止語、正規表現、ブラックリスト。

しかし、言語は無限に変形できる。

同じ意味を、何百通りでも表現できる。

モデルは意味を理解できる。
フィルタは文字列しか見ない。

この非対称性がある限り、フィルタは本質的な解決にならない。

Prompt Injectionは「設計問題」である

ここまで見てくると、結論は明確だ。

Prompt Injectionは、バグではない。

設定ミスでもない。

設計思想の帰結である。

現在のLLMは、

「命令とデータを同じ空間で処理する」

という前提の上に成り立っている。

この前提が変わらない限り、完全防御は存在しない。

リスクと共存するという選択

では、LLMは危険だから使うべきではないのか。

答えは、違う。

SQLにもインジェクションはあった。
WebにもXSSはあった。

それでも、私たちはそれらを使い続けている。

重要なのは、リスクを理解した上で設計することだ。

理解しないまま使うことが、最も危険である。

次に進む前に

本稿では、「なぜPrompt Injectionが成立するのか」に焦点を当てた。

整理すると：

• LLMには内部的な境界線がない
• すべてが一つの文脈になる
• 優先度は保証されていない
• フィルタは本質的に不十分
• 問題は設計にある

ということになる。

次回は、ここから一歩進んで、

「では、どう設計すればよいのか」

を具体的に考えていく。

プロンプト設計、権限分離、ツール制御、監査。

理想論ではなく、実装可能な形で整理していく予定だ。

誇張も、マーケティングもいらない。 必要なのは、現実的な設計だけである。