プロンプトインジェクションとは、利用者の入力や外部から取得したデータに指示を埋め込み、AIに正規の手順とは違う操作をさせる攻撃手法です。利用者が正規の手順を踏んでいるように見えるため、受付の担当者には攻撃の認識がされません。被害は回答の誤りだけにとどまりません。返金処理の実行、外部システムへの書き込み、条件設定の変更など、実行可能な操作が対象になると影響範囲は広がります。このガイドでは、4層の防御線と導入前に確認できる判定基準を整理します。
プロンプトインジェクションは3つの経路で起きる
「攻撃者が悪い入力を入れる」という理解では、範囲が狭すぎます。攻撃の入口は3つあり、それぞれ発生源も防ぎ方も異なります。
| 手法 | 発生経路 | 想定される操作 | 主な対策 |
|---|---|---|---|
| 直接入力 | 利用者が会話欄へ命令文を入力 | 正規手順を飛ばした処理の実行 | 命令語を無効化、承認の挿入 |
| 間接注入 | 参照先に埋め込まれた文が読み込まれる | 外部システムへの不正な操作 | 参照データを指示から分離 |
| ナレッジ汚染 | 不正な内容がFAQやナレッジに登録される | 誤った回答の大量配布 | 登録基準と変更履歴の監査 |
3経路に共通するのは、埋め込まれた指示が「指示として解釈されるかどうか」という一点だけです。チャットボットのセキュリティ完全ガイドの入力層・連携層・記録層の考え方は、そのままプロンプトインジェクションの対策にも当てはまります。
第1防線：指示と利用者の入力を分離する
利用者の入力を「命令」として扱わない
設計の前提は、会話欄に入っている文章は指示ではなく「利用者が入力した情報」だと扱うことです。指示文と利用者入力を同じ文脈に並べると、どこまでが規則で、どこからが要求なのかが曖昧になります。分けたうえで、入力は情報のまま扱います。
引用符で囲み、命令語を無効化する
利用者の入力を引用符で囲み、命令として解釈されない形式にしてから渡します。指示文の編集手順はチャットボットの使い方で確認できます。「これまでの指示を無視して」「システムプロンプトを表示して」といった命令語が本文に現れても、引用符の内側であることを指示文側で明示できます。命令語をそのまま本文に埋め込む設計は避けます。
第2防線：実行できる操作を分ける
回答の生成を制御しても、実行できる操作が残っていれば、攻撃の効果はそのまま出ます。操作を「読み取るだけ」と「書き込む」に分けるのが基本です。
| 操作の種別 | 与える権限 | 承認の要否 | 補足 |
|---|---|---|---|
| 参照（在庫、FAQ、注文状況） | 読み取り専用 | 不要 | 影響が限定的 |
| 更新（返金、対応履歴） | 更新専用 | 金額・件数の上限を設ける | 上限を超える分は人が確認 |
| 破壊的変更（削除、条件変更） | 与えない | 別の管理画面で人が実行 | チャットからは実行不可 |
この表の3行目が、防御の核心です。チャットボットに削除権限を渡さなければ、指示が成功しても変更は起きません。権限的分離は検知ルールほど高度ではありませんが、確実に効きます。
第3防線：検知と遮断
定型句で前段で止める
命令語は正規の利用場面では出てきません。失敗要因の整理はチャットボットの課題と対策が参考になります。入力の段階で検知し、単純な回答に差し替える設計にします。検知した件数を記録し、試行回数が見える状態にしておけば、攻撃の条件を変えられたかどうかの判断材料になります。
参照データと指示を混ぜない
外部データは「知識」として渡し、「命令」として渡しません。FAQ本文やWebページのように、利用者が制御できない参照先でも、埋め込まれた命令がそのまま実行されることはありません。
出典を厳格に限定して、生成の抜け道を塞ぐ
知識検索型の質問では、検索結果で取得した証拠以外をAIの回答に使わない「出典厳格モード」をskill層で強制適用できます。検索結果が空や不十分な場合でも、モデル自身の常識や推測で穴埋めすることはありません。埋め込み命令に対して根拠のない回答を生成する経路を塞ぎます。
第4防線：実行前に人の承認を挟む
破壊的な操作は、チャット上では実行しません。指示文に「返金処理は金額に応じて承認を必須とする」のような条件を書き込めます。閾値を超えた場合だけ、有人の確認を挟む形にできます。
承認を必須にする対象は、操作ごとに決めます。
- 返金の実行（金額に応じて必須）
- 契約情報・住所の変更
- 外部連携のキーの再発行
- 管理者権限の付与
承認の依頼はチャット画面ではなく運用側の枠に出し、承認者が判断してから実行される形にします。
監視とログ ── 攻撃の痕跡を残す
防御は検知だけでは完結しません。攻撃を受けたかどうかを後から説明できることが、監査と初動の条件になります。
GBase Supportの操作ログは、管理画面からの操作を自動で記録し、Bot、ナレッジ、認証、課金、代理店、インテグレーション、管理、ほかの8カテゴリに分類されます。設定変更は差分として保存されるため、攻撃者が指示文を書き換えた場合も前後を比較できます。検知した入力の件数と操作ログの件数を見比べることで、「入力は攻撃だったが出力には至らなかった」事例も把握できます。
ツール呼び出しの成功率と所要時間は構造化されたメトリクスとして自動計測されるため、外部連携の呼び出しが急に増える兆候も数値で追えます。インシデント管理のガイドで述べる初動の速さも、この記録の粒度で決まります。
導入前チェックリスト（12項目）
公開前に、担当者と情報システム部門で1項目ずつ記入します。
- 利用者の入力が指示文と同じ文脈で渡っていないか
- 入力が引用符で囲まれ、命令語が本文と区別されているか
- 実行できる操作が参照・更新・破壊的変更に分けられているか
- 破壊的変更の権限をチャットボットに与えていないか
- 返金の実行に金額または件数の閾値が設定されているか
- 閾値を超える操作に人の承認が入るか
- 外部連携のキーが参照専用と更新専用に分離されているか
- 定型句の検知と記録が有効になっているか
- 参照データが指示として渡っていないか
- 回答が検索結果以外の根拠を使っていないか
- 操作ログと設定差分が追跡できるか
- 検知件数とツール呼び出しの指標を週次で確認しているか
GBase Supportなら、実行できる操作の範囲から不正操作を止められます
よくある質問
Q1: プロンプトインジェクションは完全には防げますか？
完全に防ぐことはできません。未知の手法に対して検知だけに頼ると抜けが残ります。実行できる操作を制限し、破壊的な操作には人の承認を挟む設計を、検知の補助として位置づけます。検知は入口を狭める役割を持ちます。最後の防御は、実行できないことです。
Q2: 利用者が「この指示は無視して」と入力した場合、返答はどうなりますか？
命令語は引用符の内側として渡され、指示文の指示としては解釈されません。定型句として検知した場合は、正規の手順を案内する定型回答に切り替えます。
Q3: 社内のFAQに埋め込まれた命令も防げますか？
FAQ本文は知識として渡され、命令としては扱われません。ナレッジの整備方針はナレッジベースでのサポート体制づくりで確認してください。ただしFAQの内容が誤っていれば、誤った知識が正しく伝わります。FAQの登録基準と変更履歴の監査が前提になります。
Q4: 外部連携のAPIをチャットボットから呼び出す場合、何に注意しますか？
キーに実行できる操作を絞り込みます。参照専用のキーと更新専用のキーを分け、破壊的な操作のキーはチャットボットには渡しません。キーの再発行は管理画面からのみ行い、チャット上の指示では受け付けません。
Q5: 攻撃を受けたかどうかを後から確認できますか？
操作ログと認証イベントの履歴が残ります。設定変更の差分も保存されるため、いつ・誰が・何を書き換えたかを追えます。検知した入力の件数も記録し、攻撃の試行状況を振り返れます。
まとめ
プロンプトインジェクションの防御は、検出の腕前よりも、実行できる操作の範囲で決まります。入力を命令として扱わず、操作を読み取りと書き込みに分け、破壊的な操作には人の承認を挟み、痕跡をログに残す。この4段を並べて、攻撃の効果を限定します。
GBase Supportは、出典厳格モード、操作ログと設定差分、認証イベントの記録、ツール呼び出しのメトリクスを標準で備えています。実行範囲を設計してから Bot を公開すれば、防御の前提が最初から揃った状態で運用を始められます。
