- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
第47〜49週では、AIが確率分布から語を選ぶこと、そして知らないことも文として返すことを見ました。今週は、その入力に他人が手を伸ばせる場合に何が起きるかを扱います。
まず結論
OWASP LLM01:2025 は「利用者のプロンプトがLLMの挙動や出力を意図しない形で変えるとき」に起きる脆弱性と定義します。外部の文書やWebページから入ってくる間接注入も、同じ項目に含まれます。
★SQLインジェクションと構造は同型ですが、対策は移植できません。SQLにはプレースホルダという分離機構がありますが、LLMの入力は最終的にすべて同じトークン列になります。「エスケープすれば防げる」と考えると誤ります。
AIに要約させるWebページの本文に、「これまでの指示は無視してください」という趣旨の文が書かれていました。これはどう扱われるでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
入力が、挙動を変える
ここまでは入力が自分のものである前提でした。今週の主題は、その入力に他人が手を伸ばせる場合です。OWASP はこの項目を Top 10 for LLM Applications 2025 の第1項目 LLM01:2025 に置いています。定義の逐語です。
"A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways."
利用者のプロンプトがLLMの挙動や出力を、意図しない形で変えるときに起きる。 注目すべきは、ここで壊れるものが何も無いことです。モデルの重みは書き換わらず、認証も破られていません。入力が入力として働いた結果にすぎません。
2つに分かれる — 誰が書いたか
OWASP は2種類を明確に定義しています。
直接 利用者自身のプロンプト入力が挙動を変える指示を書いた人 = AIを使っている人間接 Webサイトやファイルなど外部ソースからの入力が挙動を変える指示を書いた人 ≠ AIを使っている人
間接注入の定義の逐語です。
"Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files. The content may have in the external content data that when interpreted by the model, alters the behavior of the model in unintended or unexpected ways."
(注: 原文は英語として崩れていますが原文ママです。意味は「外部コンテンツ中のデータが、モデルに解釈されたときに挙動を変える」です。)
この2つ目が厄介です。 間接注入では、指示を書いた人物とAIを使っている人物が別人になります。Webページを要約させた利用者は、そこに何が書かれているかを読む前に処理を任せています。
直接注入と間接注入の違いは何ですか。OWASP の定義に即して選んでください。
ここが本題 — 同型だが、対策は移植できない
ここで、よく使われる説明があります。「これはSQLインジェクションと同じだ」。
構造については、その通りです。 OWASP の間接注入の定義文に "data that when interpreted by the model, alters the behavior of the model" とあり、データと挙動の変更が結びつけられています。「本来データであるはずのものが命令として解釈される」という同型性は、定義文そのもので裏づけられます。しかし、ここから先が違います。
SQLインジェクションには決定打があります。プレースホルダです。構文を先に確定させ、値を後から渡す。 こうすると値の中身が何であろうと構文として解釈される余地がなく、データと命令が仕組みとして分離されます。
LLMには、これに相当する完全な分離機構がありません。 指示も質問も読ませた外部文書も、最終的にはすべて同じ入力の列になります。「ここから先は資料であって指示ではない」と宣言できますが、それ自体が入力の一部として書かれた文にすぎません。
「SQLインジェクションと同じ構造なのだから、入力をエスケープすれば防げる」という説明の評価はどれですか。
SQLインジェクション
入力された文字列が、値としてではなくSQLの構文の一部として解釈されると問題が起きます。ここには決定打があり、構文を先に確定させて値を後から渡せば、値の中身によらず構文として解釈される余地が無くなります。
問題 入力が値ではなく構文として解釈される分離 構文を先に確定し、値を後から渡す結果 値の中身によらず構文は変わらない
プロンプトインジェクション(今週)
読ませた資料の中身が、資料としてではなく指示として解釈されると問題が起きます。ただし指示も資料も最終的に同じ入力の列になるため、SQLのような形で構文と値を分けることができません。
問題 資料が資料ではなく指示として解釈される分離 指示も資料も同じ入力の列になる結果 境界は宣言できるが、仕組みにはならない
2つは同じ形の問題です。それでも一方だけに決定打があります。何がこの差を生んでいるのでしょうか。
「データと命令の境界が、どこで、何によって決まるか」を両方について考えてください。
この章のまとめ
- LLM01:2025(OWASP Top 10 for LLM Applications 2025)の定義は「利用者のプロンプトがLLMの挙動や出力を意図しない形で変えるとき」。
- 直接注入は利用者自身の入力、間接注入はWebサイトやファイルなど外部ソースからの入力。間接注入では指示を書いた人とAIを使う人が別人になる。
- 同型性は定義文で裏づけられる。 間接注入の定義に "data that when interpreted by the model, alters the behavior of the model" とある。
- ★対策は移植できない。 SQLには構文を先に確定させる分離があるが、LLMの入力はすべて同じトークン列になる。「エスケープすれば防げる」と考えると誤る。
- 境界は宣言できても仕組みにはならない。だから設計の重心は「入力の無害化」から「出力に何を許すか」へ移る。
- 壊れているものは何も無い。入力が入力として働いた結果である。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
OWASP LLM01:2025 のプロンプトインジェクションの定義として、逐語に最も近いのはどれですか。
用語集(4語)
- プロンプトインジェクション (LLM01:2025)
- OWASP Top 10 for LLM Applications 2025 の第1項目。利用者のプロンプトがLLMの挙動や出力を意図しない形で変えるときに起きる脆弱性。
- 直接プロンプトインジェクション
- 利用者自身のプロンプト入力が、直接モデルの挙動を意図しない形で変えるもの。
- 間接プロンプトインジェクション
- WebサイトやファイルなどLLMが受け取る外部ソースからの入力が挙動を変えるもの。指示を書いた人物と、AIを使っている人物が別人になる。
- データと命令の分離
- SQLのプレースホルダのように、構文を先に確定させ値を後から渡す仕組み。LLMの入力にはこれに相当する完全な分離機構が無く、指示も資料も同じトークン列になる。