プロンプトインジェクション — 読ませた文章が、命令に変わる

What — LLM には境界が作れない

XSS・CSRF・SQLi は、どれもデータとして扱うべきものが命令として解釈される問題でした。プロンプトインジェクションも同じ形です。違うのは、境界を仕組みで作る方法が存在しないことです。

// 構文と値を別々に渡す
db.query(
"SELECT * FROM orders WHERE id = ?",
[userInput]
);
// userInput に何が入っていても、
// パーサは「値」としてしか扱わない

直接と間接

入口は 2 つあります。

• 直接: 利用者本人がチャット欄に「前の指示を無視して」と書く。被害を受けるのは多くの場合、運営側（隠したい設定の流出、利用規約外の出力）
• 間接: モデルが読む外部の文章に指示が入っている。Web ページ、受信メール、アップロードされた PDF、検索でヒットした社内文書、コードのコメント。被害を受けるのは利用者で、本人は何もしていない

危険なのは間接のほうです。 冒頭の事故がこれで、攻撃者はアシスタントに一度も触れていません。モデルに外部の文章を読ませる機能は、すべてこの入口になります。

出力も入力として扱う

見落とされやすいのが④です。モデルの出力は、攻撃者が書かせた可能性のある文字列です。それを HTML に入れれば XSS、SQL に入れれば SQLi、シェルに渡せばコマンド実行になります。

冒頭の事故は、XSS ですらありません。Markdown の画像記法 ![](url) を画像として表示しただけです。ブラウザが画像を取りに行く = URL に載せたデータを外部へ送る、という普通の動作が持ち出し経路になりました。

Why — なぜ「騙されないモデル」を待てないのか

XSS には「出力時にエスケープする」という確実な根本対策がありました。プロンプトインジェクションには、それにあたるものがありません。理由は、この問題がバグではなく、LLM が役に立つ理由そのものから来ているからです。

• LLM は、文章の中の指示を読み取って従うように訓練されている
• 「利用者の指示には従い、ページの中の指示には従わない」を区別するには、どれが誰の文章かを知る必要がある
• しかしモデルに届くのは 1 本の文字列で、その区別は文脈からの推測でしかない

モデルの改良で、騙される確率は下がっています。ただし 0 にはなりません。攻撃者は何千通りでも試せます。1% の確率で通るなら、100 回試せば通ります。

検知で防ぐ案が弱い理由

「怪しい指示を検知するモデルを前に置く」という案があります。これは XSS の記事で見た拒否リストと同じ形です。言い換え、別の言語、画像の中の文字、2 回に分けた指示。列挙から漏れた書き方で通ります。層の 1 枚としては意味がありますが、それを主な守りにはできません。

守りは「行動」と「出口」に置く

モデルが騙されることを前提にすると、守りの場所が変わります。被害が出るのはモデルの中ではなく、モデルの出力を受け取る普通のコードです（上の図の③④）。そこは従来どおり、確実に書けます。

危険が大きくなるのは、次の 3 つが同じ会話にそろったときです。

1. 外部の文章を読む（攻撃者が指示を入れられる）
2. 秘密に触れる（社内文書、他人のデータ、利用者の個人情報）
3. 外へ送る経路がある（画像やリンクの表示、メール送信、外部 API の呼び出し）

冒頭の事故は、3 つともそろっていました。どれか 1 つを外せば、持ち出しは成立しません。 Web ページを要約する会話では社内検索を使えなくする。あるいは、回答の中の外部画像を表示しない。どちらか 1 つで、この事故は起きませんでした。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。