自社の資料を使うチャットボットには便利さがあります。一方で、「社内向けの値段まで答えないか」「別のお客様の情報が出ないか」という不安も自然なものです。
その不安に対し、「AIに秘密を話さないよう指示します」だけでは十分ではありません。独自型チャットボットを公開するなら、答え方だけでなく、そもそも何を見られ、何を操作できるかを設計します。
要点
- 公開情報と社内・顧客の機密情報を分け、初期状態では見せない設計にします。
- プロンプトへの指示だけに頼らず、権限・記録・有人引き継ぎを組み合わせます。
- 公開前に悪意ある質問、範囲外の質問、停止手順までテストします。
結論：指示、資料、権限、人の確認を重ねる
公開用と社内用の情報を分け、利用者に必要な資料だけを参照させます。予約変更などの操作には、システム側の本人確認と権限確認を設けます。判断が難しい相談は、人へ戻せるようにします。
AIがルールを守ることだけに、安全性を預けない。 これが導入時の基本です。対策してもリスクがなくなるわけではないため、監視と停止の手順も必要です。
誤回答と情報漏えいは、違う問題
古い料金を答えるのは、資料更新や回答の問題です。一方、他人の予約を表示するのは、アクセス権限の問題です。前者を直すために指示文を改善しても、後者の認証の不足は解消しません。
さらに、利用者の入力や参照資料に含まれる指示によって、AIの動作が誘導されるリスクもあります。これはプロンプトインジェクションと呼ばれます。
OWASPの対策資料でも、必要最小限の権限、入力や操作の検証、人の承認などを重ねる考え方が示されています。別のAIに検査させるだけで、すべて解決するものではありません。
想定例：公開ボットに社内資料を混ぜない
富士市の架空の小売店で、公開価格表と仕入れ原価表を同じ資料群へ入れたとします。「原価は答えない」と指示していても、公開ボットが原価表を検索できる構成そのものがリスクになります。
最初の対策は、原価表を公開ボットの参照先から外すことです。社内でも役割ごとに見られる情報が違うなら、ログイン状態と権限に応じた検索をシステム側で行います。
また、公開ボットの回答ログに個人情報が残るなら、そのログも誰でも読める場所に置いてはいけません。回答に出る情報だけでなく、裏側に残る記録も対象です。
開発前に確認する六つの項目
1．資料の公開範囲
公開用、顧客ごとの限定情報、社内専用を分けます。利用者が閲覧してよい範囲は、AIの自己判断ではなく、アプリ側で決めます。
2．操作できる範囲
案内だけのボットに、予約削除や顧客情報変更の権限を渡す必要はありません。必要な操作だけを許可し、読み取りと変更を分けます。
3．本人確認
名前や予約番号を入力しただけで、他人の情報を表示しないようにします。どの操作に何の確認が必要かを、予約・顧客管理側の仕様と合わせて確認してください。
4．入力と出力の扱い
利用者の文章、アップロード資料、外部ページを、システムへの正式な命令として扱わない設計が必要です。出力には、機密情報や危険なリンクなどが混ざらないかの確認も検討します。
5．記録と保存
会話、添付、検索記録の保存先、期間、閲覧者、削除方法を決めます。利用者への説明も含め、必要以上に集めないことを基本にします。
6．停止と連絡
誰が停止できるか、止めた後に何を表示するか、開発会社へどう連絡するかを決めます。担当者が不在でも対応できる手順を用意します。
人へ戻す条件は、通常運用の一部にする
苦情、補償、健康や安全に関わる相談、情報の矛盾など、ボットが判断しない場面を定義します。「答えられません」で終わらせず、確認先と、対応できる時間を案内します。
引き継ぎメモは、相談内容、確認済み事実、未確認事項、操作済みのことを分けます。AIの推測を、利用者が申告した事実として渡さないようにしてください。
安全に行う公開前テスト
実在の個人情報や本番の予約を使わず、権限の異なるテスト利用者と架空データで確認します。
公開前確認の観点
・公開用ボットが社内専用資料を取得できないか
・利用者Aが利用者Bの情報を閲覧・変更できないか
・資料中の文章が、設定変更の指示として扱われないか
・根拠がない料金や対応可否を断定しないか
・担当者への引き継ぎ先が実際に機能するか
・停止後に従来の問い合わせ方法へ戻れるかテストで問題がなかったことは、安全の永久保証ではありません。モデル、資料、連携、設定が変わったら再確認します。重要な処理を含む構成では、専門家によるセキュリティ確認も検討してください。
問題が起きたときの順番
まず影響する応答や操作を止め、必要な記録を権限のある場所に保全します。何が起きたかを確認し、責任者と開発担当へ連絡します。原因調査前に、都合の悪いログを消してはいけません。
個人情報に関わる場合は、影響範囲を確認し、必要な報告・通知などを担当者や専門家と判断します。対策後は、問題を再現したテストと通常の動作を確認してから再開します。
よくある質問
Q. 「答えないで」と書けば十分ですか？
十分ではありません。参照できる情報と操作権限を制限し、システム側の確認を組み合わせます。
Q. RAGなら漏えいを防げますか？
RAGは資料参照の仕組みで、権限管理の代わりではありません。誰がどの資料を取得できるかを別に制御します。
Q. 個人情報を扱わなければ安全ですか？
リスクは減らせますが、誤案内、非公開情報、意図しない操作、運用停止なども確認が必要です。
Q. 小さな店でも停止手順が必要ですか？
必要です。担当者、停止方法、代替窓口を短くまとめ、実際に操作できるか確認しましょう。
まとめ：答えの注意書きより、見せない・動かさない設計を
独自型チャットボットの安全は、一つの指示文では決まりません。情報を分け、権限を絞り、人へ戻し、止められる形にする。この土台を導入時から確認しましょう。
FUJI PRESSでは、富士市の会社やお店の業務を整理し、チャットボットに渡す情報と操作の範囲を一緒に考えます。実装やセキュリティの確認範囲は、要件に応じて個別に検討します。
関連記事と公式情報
参考情報
OWASP：LLM Prompt Injection Prevention Cheat Sheet（確認日：2026年9月6日）。本記事は一般的な設計上の確認事項であり、個別システムの安全性を認証するものではありません。