チャットボットのプロンプトインジェクション対策｜多層防御の設計

公開チャットボットへ禁止文を追加し、不審な入力を拒否する設定を入れても、プロンプトインジェクション対策は完了しません。攻撃に使われる指示は、利用者の入力だけでなく、会話履歴、アップロードファイル、RAGの検索文書、取得したWebページ、外部ツールの応答にも紛れ込むためです。

必要なのは、すべての自然言語と外部データを信頼しない前提で、防御を重ねることです。指示とデータを分離し、モデルへ秘密情報を渡さず、ツールを最小権限にします。高リスク操作には承認を設け、出力と送信先を検査し、異常時に停止できる状態も整えます。

一つのフィルターですべての侵入を防ごうとせず、一部の防御を通過されても、情報漏えいや不正操作へ直結しない構成にすることが、多層防御の中心です。本稿では、攻撃面の棚卸しから権限、承認、監視、停止、回帰試験までを実務の順序で整理します。

プロンプトインジェクション対策はなぜ禁止文だけでは不十分なのか

プロンプトインジェクションとは、信頼できない自然言語によって、本来の指示に反する判断や処理をモデルへ行わせる攻撃です。攻撃者は回答方針を変えさせるだけでなく、参照情報の開示や外部ツールの実行を誘導する可能性があります。通常の入力値検証とは異なり、自然言語には同じ意図を表す書き方が多数あります。そのため、特定の禁止語だけで安全な入力と危険な入力の境界を定めることは困難です。

直接型では、利用者がチャット欄へ不正な指示を入力します。間接型では、モデルが参照する文書やWebページなどに指示が含まれます。たとえば、RAGへ取り込んだ外部PDFに、従来の指示を無視するよう求める文が含まれている場合です。その文を業務上の命令として扱う構成では、利用者がチャット欄へ攻撃文を入力していなくても、モデルの判断が変わるおそれがあります。

OWASPのLLM Prompt Injection Prevention Cheat Sheetは、直接型と間接型を含む攻撃類型を示し、入力検査、構造化、出力監視、最小権限、人による承認などを組み合わせています。OpenAIのエージェント設計に関する解説も、悪意のある入力を見分ける処理だけに依存せず、攻撃された場合の影響を抑える設計を重視しています。

入力フィルターが不要なのではありません。一つの防御層として位置付ける必要があります。「侵入を防ぐ対策」と「侵入後の影響を限定する対策」を切り分け、後者まで設計してください。完全防御や一定の防御率を前提にせず、情報漏えい、外部送信、更新、削除などの結果へ至る経路を一つずつ閉じます。

最初に直接型と間接型の攻撃経路を台帳へ整理する

対策製品や禁止語を選ぶ前に、信頼できない内容がどこから入り、どこまで到達するかを一覧にします。対象はチャット欄だけではありません。会話履歴、ファイル、RAG文書、Web取得データ、メールなどの外部データ、ツールの応答も確認します。

実際の台帳には、データの所有者、更新経路、保持期間、モデルへ渡す範囲も加えます。さらに、入口ごとに「回答文へ使われるだけか」「外部操作の判断材料にもなるか」を分けてください。同じ文書でも、商品説明に引用するだけの構成と、記載内容を根拠にメールを送る構成とでは、攻撃された場合の影響が異なります。

棚卸しでは、モデルから後段へ至る経路も追います。基本の流れは「利用者または外部データ→モデル→出力検査→ツール実行または回答」です。この流れの各境界で、どの入力を信頼したのか、どの検証を通ったのか、検証に失敗した場合はどこで止めるのかを記録します。入口だけを確認すると、ツールの応答に含まれた指示が次の処理へ渡る経路を見落としやすくなります。

指示とデータを分離し、秘密情報をモデルから隔離する

モデルへ渡す情報は、アプリケーションが定める制御条件、利用者入力、検索文書、ツール結果に分けます。制御条件の具体的な内容を回答へ含めず、検索文書やツール結果は参照データとして扱います。これらの参照データだけでは権限変更や外部実行ができないよう、アプリケーション側の処理でも区別します。

RAG文書内に命令調の文章があっても、その文章は回答根拠の候補にとどめます。外部送信、更新、削除などを実行する根拠にはしません。ツールを呼び出す必要がある場合は、利用者が明示した目的と、アプリケーションが許可した操作の両方を別の処理で確認します。

APIキー、データベースの認証情報、管理者用トークン、非公開の復旧情報を、モデルへ渡す指示や会話コンテキストへ記載してはいけません。モデルが利用する必要があるのは秘密情報そのものではなく、認証済みの実行基盤が返す限定的な結果です。認証情報は実行基盤側で保管し、許可された処理を実行するときだけ使用します。

認証情報の保管、更新、失効まで含めて整理する場合は、チャットボットのAPIキー管理で確認する項目も参照してください。プロンプトから秘密情報を削除しても、共有ファイルやログへ平文で残っていれば、隔離は完了していません。

ツール権限を操作単位で分け、最小権限にする

ツール連携がある場合、モデルの判断を変えられても実行できる操作が少なければ、影響範囲を限定できます。「顧客管理システムへ接続できる」という大きな権限ではなく、読み取り、下書き作成、外部送信、更新、削除、決済などの操作単位へ分けます。

商品案内だけを行う公開チャットボットなら、商品情報の読み取りは許可しても、在庫更新や注文取消しのツールを接続する理由はありません。将来使う可能性だけを理由に権限を先に渡さず、必要になった時点で利用目的、対象範囲、承認条件を確認します。

権限は、接続先のアカウントでも制限します。アプリケーション上で「読み取りのみ」と指示していても、接続先の資格情報に更新権限があれば、設定不備や別経路による実行の余地が残ります。モデル、実行基盤、接続先サービスの三つで、許可する権限が一致しているかを確認します。

利用者、担当者、システムの役割ごとに権限表を作る手順は、チャットボットのアクセス権限設計で詳しく整理しています。この記事の攻撃面台帳と権限表を対応させると、入口ごとに到達できる操作を確認できます。

高リスク操作は利用者の意図と照合し、実行直前に承認する

承認は、会話の途中で一度「よろしいですか」と尋ねるだけでは足りません。外部送信、個人情報の表示、予約変更、削除、決済などでは、対象、操作、送信先、変更内容を実行直前に表示します。その内容が、利用者が明示した本来の目的と一致するかを確認してから実行します。

予約変更では、対象予約、変更前後の日時、利用者確認の有無を検証します。会話履歴に変更希望があるだけで更新してはいけません。対象を一意に確認できない場合や、本人確認の条件を満たさない場合は有人対応へ切り替えます。モデルが生成した要約だけでなく、業務システム上の対象IDと確定値を承認画面へ表示することが重要です。

承認者には、判断に必要な情報を過不足なく提示します。「AIが推奨したため承認する」という判断にならないよう、依頼者、操作理由、変更前後の内容、送信先、参照した情報を確認できる形にします。承認後に引数が変わらないよう、承認した内容と実行する内容を同じ識別子で結び付けます。

自動処理を止めた後の受け皿も必要です。保留になった問い合わせの通知先、担当範囲、回答期限、利用者への案内を決める際は、チャットボットから有人対応へ引き継ぐ設計を参考にしてください。承認拒否を単なるエラーにすると、利用者が同じ操作を繰り返し、監視上の異常と通常の再試行を切り分けにくくなります。

出力検査と送信先制限で情報漏えいと不正実行を封じ込める

入口で見逃した攻撃は、モデルの出力後と外部実行前にも止めます。回答文では、秘密情報、内部指示、許可されていない個人情報、実行用の内部識別子などが含まれていないかを検査します。ただし、出力検査だけで安全を保証しようとせず、不要な情報をそもそもモデルへ渡さない設計と組み合わせます。

モデルが作った文章を、そのままツールへの命令として実行してはいけません。ツール呼び出しでは、許可した操作名、引数の型、文字数、値の範囲、対象ID、利用者との関係をアプリケーション側で検証します。不明な引数を無視して実行するのではなく、処理を拒否して記録します。

メール送信なら、宛先を許可済みドメインまたは顧客台帳の登録先に限定します。本文の生成と実際の送信を別工程にし、未知の宛先や大量送信は拒否します。URLへのアクセスを伴う場合も、モデルが任意の送信先を指定できる構成を避け、許可リストや業務上の対象情報と照合します。

連続実行による被害を抑えるため、利用者、時間帯、操作ごとに実行回数や処理量の上限を設けます。通常と異なる大量実行が起きた場合は、高リスクツールだけを停止できるキルスイッチを用意します。チャット画面全体を止める前に、外部送信、更新、削除などを無効化し、読み取り回答または有人対応へ限定する段階的な停止も検討します。

監視項目と停止・復旧手順を運用前に決める

監視では、入力文だけでなく、参照データ、判定結果、ツール名、検証済みの引数、承認者、出力、送信先、拒否理由、停止操作を追えるようにします。一方で、秘密情報や個人情報をログへ無制限に複製してはいけません。調査に必要な項目、閲覧できる担当者、保存期間を決めます。

通知候補には、大量の拒否、権限外操作の反復、未知の送信先、短時間の連続実行、同一利用者による機能や境界の探索的な質問があります。一つの事象だけで攻撃と断定せず、通常業務の利用パターンと照合します。通知条件には、確認担当、初動期限、誤検知だった場合の終了条件も設定します。

保存項目や閲覧権限を具体化する際は、チャットボットの監査ログ設計も合わせて確認してください。ログを保存するだけでは対応につながりません。誰が確認し、異常を見つけた場合に誰へ引き継ぐかまで決めます。

一次停止者、調査担当者、業務部門への連絡担当、再開承認者を事前に割り当てます。停止権限を持つ人が営業時間外に不在では、キルスイッチがあっても使えません。連絡先と代行者を手順書へ記載し、連絡と判断の手順が機能するかを定期的に確認します。

攻撃系と正常系を同時に受入・回帰試験する

受入試験では、禁止語を含む単発の入力だけを試しても不十分です。表現の言い換え、別言語、文字の分割、複数ターンに分けた誘導、RAG文書内の間接注入、取得Webページ内の命令、ツール応答内の命令を試験対象にします。攻撃文を公開資料へそのまま残さず、管理された試験環境で承認済みのケースだけを実施します。

同時に、返品条件、営業時間、在庫の確認など、正当な質問へ回答できるかを確認します。予約変更など許可された操作では、必要な本人確認と承認を通れば実行できることも試します。攻撃を止める代わりに通常業務まで止める設定は、現場で解除されやすくなり、防御を維持できません。

完了条件を「攻撃文に拒否回答が出た」だけにしてはいけません。権限外ツールが実行されていないこと、秘密情報が出力されていないこと、必要なログが残ること、有人対応へ引き継げることを確認します。正常系では、業務上必要な回答と許可済み操作が過剰に止まらないことを記録します。

モデル、モデルへ渡す制御指示、RAG文書、ツール定義、権限、出力検査を変更したら、同じ試験を再実行します。公開前試験全体へ組み込む方法は、チャットボットの公開前テストケースを使うと整理しやすくなります。

多層防御の導入順序と担当範囲を決める

対策は、攻撃面の棚卸し、秘密情報の隔離、権限縮小、承認追加、出口制御、監視と停止手順、回帰試験の順で進めます。最初に高度な検知機能だけを導入しても、モデルが広い権限と秘密情報を持ったままでは、検知漏れが起きた場合の影響を限定できません。

最初の実務では、公開中のチャットボットを一つ選び、接続しているデータとツールを並べます。次に、回答へ不要な秘密情報と権限を外します。その後、高リスク操作を承認対象へ移し、出口制御と停止手順を設定します。最後に、設定値を確認するだけでなく、本番と同等の権限条件で実際に試験します。

開発会社や社内担当者へ依頼するときは、「プロンプトインジェクションへ対応する」とだけ伝えないことが重要です。攻撃面台帳、操作別権限表、承認条件、送信先制限、記録項目、停止権限、試験ケースを成果物として指定します。実装できない項目があれば、残るリスク、代替策、見直し期限も記録します。

プロンプトインジェクション対策でよくある質問