プロンプトインジェクションという、少し厄介な話

子どもの頃、兄弟姉妹にうまく言いくるめられて、気づいたら自分だけが家事を全部やっていた――そんな経験はありませんか。

「お母さんは、全部自分でやる君のことが一番好きなんだよ」
「君は何もしなくていいから、僕が代わりにやってあげる」

そう言われて、なぜか納得してしまい、結果的に自分が全部やることになる。
今振り返ると、少し苦笑いしてしまう話ですが、当時は本気でした。

実は、LLM（大規模言語モデル）に対するプロンプトインジェクションも、この感覚によく似ています。

プロンプト注入とは？

プロンプトインジェクションとは、言語モデルに与える入力を工夫することで、意図しない振る舞いを引き出す手法です。

何か特別な脆弱性を突く、というよりも、言葉の流れや前提の置き方を少しずらすことで、モデルの判断をこちらの意図した方向に誘導してしまう。そんなイメージに近いかもしれません。

その結果、本来は守られるはずの制限をすり抜けたり、想定していなかった情報が応答として返ってくることがあります。

ここで重要なのは、これが「高度な技術を持った一部の攻撃者だけの話」ではない、という点です。

LLMは非常に優秀で、自然な文章を理解し、文脈を踏まえて応答するよう設計されています。
ただ同時に、与えられた言葉を前提として受け取ってしまう性質も持っています。

少し強い言い回しや、「これは例外だ」「前のルールは無視してほしい」といった表現が混ざると、モデルはそれを“新しい前提”として解釈してしまうことがあります。

人間同士の会話であれば、「それはおかしい」と立ち止まる場面でも、LLMは疑問を持たず、素直に応答を続けてしまう。

この“素直さ”こそが、プロンプトインジェクションが成立してしまう背景にあります。

プロンプトとシステムプロンプトの関係

普段、私たちが入力している文章は「ユーザープロンプト」と呼ばれます。
一方で、アプリケーション側では、ユーザーには見えない形で「システムプロンプト」と呼ばれる指示が裏側に用意されています。

このシステムプロンプトには、LLMがどのような前提で振る舞うべきかがまとめて書かれています。例えば、次のような内容です。

• どんな役割で振る舞うか
• 何をしてはいけないか
• 出力のトーンや制約

これらは、LLMを特定の用途に合わせて使うための“土台”のようなものです。
開発者はコードを書き換えなくても、システムプロンプトを通じて、モデルの振る舞いをある程度コントロールできます。

重要なのは、こうした前提条件が、ユーザーの入力とは完全に分離された形で扱われているわけではない、という点です。
実際には、システムプロンプトとユーザープロンプトは同じ文脈としてLLMに渡され、まとめて解釈されます。

ここがポイントになります。

LLMにとっては、

• 「守るべきルール」
• 「今入力された文章」

この二つは、どちらも同じ“言葉”です。
そのため、表現が強かったり、巧妙に組み立てられた言い回しが含まれていると、モデルの判断がそちらに引きずられてしまうことがあります。

人間であれば立ち止まって考えるような場面でも、LLMは与えられた文脈を前提として受け取り、そのまま応答を続けてしまう。
この性質が、プロンプトインジェクションが成立してしまう背景にあります。

なぜ成立してしまうのか

プロンプトインジェクションは技術的な攻撃というよりもソーシャルエンジニアリングに近い性質を持っています。

相手を力づくで騙そうとするのではなく

• 相手に疑問を持たせない
• 自然な流れの中で受け入れさせる
• 判断の前提をこちらの都合の良い形にそっと合わせていく

そうした形で結果的に意図した行動を取らせる点がよく似ています。

LLMは感情を持ちませんが会話全体の流れや文脈を強く重視するように設計されています。
個々の文章を独立して評価するのではなく前後の関係を含めて意味のあるストーリーとして解釈します。

そのため

• 「これは特別な指示です」
• 「前のルールは無視してください」

といった表現が文脈の中に自然に混ざるとモデルの判断が徐々にそちらへ引き寄せられることがあります。

必ずしもその一言で制限を突破できるわけではありません。
ただ判断の軸が揺らぐきっかけになることは確かです。

もちろん多くのLLMにはセーフガードが組み込まれています。
危険な指示や不適切な出力を抑制するための仕組みは実際に年々強化されてきています。

ただしそれらは完璧な壁ではありません。
あくまでリスクを下げるための現実的な対策に過ぎずすべてのケースを確実に防げるわけではないという前提があります。

この前提を理解した上で向き合うこと。
それがプロンプトインジェクションを過度に恐れずかつ軽視もしないための最初の一歩になります。

プロンプト注入の種類

プロンプトインジェクションには、大きく分けて二つの考え方があります。
どちらも言葉を使ってモデルの判断に影響を与える点では共通していますが、成立の仕方と現実での危険度には違いがあります。

直接プロンプト注入

ユーザーがそのまま、モデルを操作する指示を書き込む方法です。
入力内容の中で、モデルの役割や振る舞いを明示的に書き換えようとします。

• 役割を上書きする
• 制限を無視するよう求める

構造が分かりやすく、挙動も想像しやすいため、最初に試されやすい手法です。
一方で、露骨な表現になりやすく、セーフガードに検知されやすい傾向もあります。

間接プロンプト注入

こちらは、より現実的で厄介なケースです。

ユーザーが直接指示を書くのではなく、モデルが参照する文章やデータの中に、指示そのものを埋め込む形になります。
外部コンテンツや説明文の一部として読み込まれた情報が、結果的にモデルの判断に影響を与えることがあります。

一見すると普通の文章であっても、LLMがそれを「従うべき文脈」や「優先すべき前提」として解釈してしまうことがあります。
このため、開発者や運用者が気づかないまま、意図しない挙動につながるケースもあります。

実際に試してみると分かること

有名な「ガンダルフ」系のチャレンジを試してみると、プロンプトインジェクションの挙動が非常に分かりやすく見えてきます。

最初の段階では、単純な質問に対して、そのまま素直に答えが返ってきます。
この時点では、モデルが特別な制限を意識していないことが分かります。

次の段階に進むと、同じ聞き方では応答が拒否されるようになります。
ここで初めて、モデルの中に「守るべきルール」が存在していることがはっきりと見えてきます。

それでも、質問の言い回しを少し変えたり、前提条件をずらしたりすると、意図していなかった応答が返ってくることがあります。
直接的な要求ではなく、会話の流れの中で条件を変えていくことで、モデルの判断が揺らぐ瞬間が生まれます。

この体験から分かる重要な点は、正解のプロンプトが一つだけ存在するわけではないということです。

人によって通る表現もあれば、同じ内容でも通らない表現もあります。
その違いは非常に微妙で、明確な境界線があるわけではありません。
だからこそ、この問題は単純なルールだけでは片付けられず、実運用の中で慎重な扱いが求められます。

予防側として見ている現実

現場で診断をしていると、「そんな入力、普通はしないですよね」と言われることがあります。

その通りです。
一般的なユーザーが、あえて不自然な言い回しや回りくどい入力を試すことはほとんどありません。

ただ、攻撃は普通の前提では起きません。
むしろ、普通ではない状況を前提に考えなければ、見落としてしまうケースの方が多いと感じています。

• 想定外の入力
• 想定外の文脈
• 想定外の組み合わせ

プロンプトインジェクションは、こうした「想定外」が重なったところを静かに突いてきます。
単体では問題に見えない要素でも、組み合わさることで初めて挙動が変わる。
そのため、事前に想定していないと、なかなか気づきにくいのが実情です。

何も起きていない今だからこそ

プロンプトインジェクションは、ランサムウェアのように目に見える被害がすぐに表面化するものではありません。システムが止まるわけでも、警告が派手に出るわけでもないため、どうしても気づきにくく、対応が後回しにされがちです。

ただ、LLMを業務の中に組み込む以上、「言葉は本当に安全か」という視点を避けて通ることはできません。
入力される文章や参照する文脈が、そのまま判断材料になるという特性は、便利さと同時にリスクも内包しています。

何か問題が起きてから振り返るよりも、まだ何も起きていない段階で、仕組みや前提を一度整理しておく。
それだけでも、見える景色は大きく変わります。

予防や診断の立場にいる人間として感じるのは、こうした分野こそ「静かなうちに向き合っておく」ことの価値が高いということです。
それが、プロンプトインジェクションと付き合っていくうえで、一番現実的な姿勢だと思っています。

自社のセキュリティに不安を感じたら

投稿者プロフィール

イシャン ニム

Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）

最新の投稿

• Black Hat2026.01.23ランサムウェア交渉という仕事──混乱の中で「主導権」を取り戻すために
• Black Hat2026.01.22北朝鮮IT人材は、どのようにしてリモート採用市場に入り込んでいるのか
• リスクマネジメント2026.01.21エシカルハッキングサービスとは何をしているのか
• Black Hat2026.01.20ディープウェブとダークネットを正しく理解する――安全に向き合うための現場感覚