メールを読ませただけなのに、AIが勝手に情報を送る？――問い合わせ対応AIで確認したい権限の範囲
問い合わせ対応AIが、顧客から届いたメールと添付資料を読み、回答の準備をしています。担当者が頼んだのは、契約状況の確認と案内文の作成でした。
ところが、取得した資料の記述を受けて、別の情報を取り出したり、予定していない送信をしたりする動きが生じたらどうでしょうか。
これは、外部の文章とAIの実行権限を考えるための想定場面です。メールを読む権限があることは、メールの中に書かれた操作を許可することと同じではありません。
外部の文章は、判断に使う資料として扱い、操作を許す権限の根拠にはしません。不正な指示を見抜く対策に加え、見逃した場合も許されない実行へ進めない境界を設計する必要があります。
顧客の要望と、処理を支配する指示を分ける
顧客の問い合わせには、手続きを変えてほしい、情報を送ってほしいという要望が含まれます。それ自体をすべて悪意ある文章として排除すれば、顧客対応の仕事ができなくなります。
重要なのは、その要望を受け取ることと、実行を認めることを分けることです。住所変更を依頼されたなら、依頼内容として理解した上で、本人確認と変更を許す条件を確かめます。文章の強さや丁寧さは、その条件の代わりにはなりません。
間接的なプロンプトインジェクションは、AIが読む外部の文書やツールの結果などに、行動を別の方向へ誘導する指示が混ざる問題です。Anthropicの公式文書も、信頼する利用者のために第三者の内容を処理する場合の脅威として、直接の入力操作と区別しています。
この区別をすると、対策は怪しい文面を探すことだけではなくなります。どこから来た文章か、何のために読むか、その文章に何を決めさせてよいかという、業務と権限の設計になります。
添付資料が読めるなら、その中の命令にも従うのか
想定場面では、担当者が正当な目的でAIへ添付資料を読ませています。資料の閲覧許可はあります。しかし、資料の中に別の処理を求める記述がある場合、その処理まで担当者が許可したことにはなりません。
例えば、問い合わせを要約する仕事と、顧客リストを別の宛先へ送る仕事は違います。前者のために資料を読む権限を与えたからといって、後者へ権限を広げる必要はありません。この二つを同じ会話の流れだけでつなげないことが重要です。
資料の出所や種類を明示し、業務の指示と区別して渡す方法は、AIの判断を助けます。ただし、形式を整えればすべての不正指示が無効になると考えてはいけません。モデル側の防御と、実行先での制約は別に持っておきましょう。
Microsoftの公式資料も、間接的な不正指示への備えとして、複数の防御を組み合わせ、封じ込めや復旧まで設計する考え方を示しています。ここからAILが提案するのは、検出できなかった場合にどこまで届くかを、業務の流れで確認することです。
被害へ至る連鎖を、途中で切る
AIが外部の記述を誤って指示として扱ったとしても、直ちに顧客情報の外部送信までできる構成にしなければ、被害の広がりを抑えられる可能性があります。
まず、その業務に不要なデータやツールを使えないようにします。問い合わせの回答案を作る機能なら、住所の更新や広い一覧の出力まで持たせる必要があるかを問います。機能をまとめた方が便利でも、必要な範囲を超えた実行権限が増えていないかを確認します。
次に、利用者と取得対象を接続先で確認します。AIが別の会員情報を要求しても、その利用者の権限を超えるなら拒否します。外部の文章によって、実行主体や許可対象が自由に書き換わらないことを確かめます。
送信が必要な業務では、送信先や内容の条件を決めます。送信機能があることを、任意の宛先へ何でも送ってよい許可と同一にしません。変更や送信に人の承認が必要なら、承認した操作と実際の操作が一致する仕組みも必要になります。
見抜いた件数だけで、防御を評価しない
不正な指示を何件検出したかは、検査の性能を確認する材料になります。ただし、その数字だけでは業務被害を防いだかはわかりません。検査を通った後、何を実行できるかが残るからです。
想定場面の試験では、文面の判定、ツール呼出し、接続先の認可（誰にどの操作を許すかの判断）、送信の結果を分けて確認します。不審と判定されたのに後続の処理が続いたなら、検知はしたが遮断できていません。検知されなくても、不要な操作が接続先で拒否されたなら、その統制は働いています。
結果の整理では、どの層で止まり、何の被害が起きなかったかを残します。すべてを攻撃阻止という一つの分類へまとめない方が、改善する場所を選びやすくなります。
また、何も起きなかった場合も、試験が対象の経路へ到達したかを確認しておきましょう。添付資料が取り込まれていなかったために反応しなかっただけなら、取り込まれた場合の安全性は未確認です。評価対象の設定と実行証拠を合わせて読む必要があります。
通常の顧客の文章まで止めていないか
防御を強めると、正常な問い合わせを拒否してしまう場合も考えられます。契約変更、代理の相談、強い不満の表現など、業務では多様な文章を受け取ります。禁止する単語の一覧だけでは、必要な処理まで止めるおそれがあります。
そこで、悪意ある入力だけでなく、実際の業務を代表する通常の入力も用意します。不正な操作をしないことと、正当な依頼を必要な確認へ進められることを、別の評価結果として見ます。
本人確認が未完了の変更依頼に対し、すべてを拒否して会話を終えることが最適とは限りません。案内できる範囲を示し、正式な本人確認へつなぐ設計が考えられます。処理の実行を止めながら、顧客対応を続ける選択肢があります。
この違いを業務責任者と合意しておけば、検査の設定を緩めて全部通すという調整を避けやすくなります。何を答えてよいか、何を実行してはいけないか、人へ戻す条件は何かを先に決める方がよいでしょう。
外部の情報を要約し直しても、出所は消えない
もう一段、情報の流れを進めて考えてみましょう。最初のAIが外部のメールを要約し、その要約を別のAIが受け取る構成です。短く整った文章になったため、二つ目のAIが社内の正式な指示だと受け止めないでしょうか。
要約や翻訳によって、内容が読みやすくなることと、権限の根拠が増えることは別です。外部から来た要望は、加工されても外部の要望です。誰が確認したか、どの操作を正式に許可したかを別に示す必要があります。
AI同士をつなぐときも、文章だけを渡して元の出所を失わないようにしましょう。情報の出所、対象の業務、確認の状態、許可された操作を整理し、次の処理が何を信頼できるかを明確にします。
これは、内部のメッセージをすべて疑って仕事を止めるためではありません。内容の要約と実行の承認を分け、必要な情報を必要な役割で受け取るための設計です。途中で整形された文章が、意図せず強い命令にならないようにします。
不審な文章を見つけた後、何を顧客へ返すか
想定場面の担当者は、怪しい指示を含む資料を発見した後も、問い合わせへの対応を考えなければなりません。資料全体を拒否するか、一部の情報だけを使えるか、人が内容を確認するかで、運用は変わります。
AIだけに、この資料は悪意があると断定させる必要はありません。確認が必要な状態として扱い、危険な操作を止め、担当者へ必要な情報を渡す方法もあります。顧客への案内は、確認できた事実と次の手続きに絞ります。
不審な内容を含む元の文章を、通知や別のAIへそのまま転載する運用にも注意が必要です。確認のための情報が、別の処理で再び指示として使われないようにする必要があります。保存と共有の範囲は、調査の必要性に合わせて決めます。
対応記録には、検出したこと、止めた操作、すでに実行されたこと、残る確認を分けて残します。検査が反応したので事故はなかった、と自動的に結論付けません。実際の操作の状態を見て、必要な調査を選びます。
内容を捨てる判断と、業務を止める判断を分ける
不審な添付を検知したとき、その問い合わせを丸ごと消してしまうと、正当な顧客の相談まで失われるかもしれません。想定場面なら、危険な内容を後続のAIへ渡さず、受付番号と安全に取り出せた申告内容だけを担当者へ引き継ぐ運用を考えてみましょう。
ただし、別のAIで要約したから安全になったとは判断しません。要約の中に、外部送信や権限変更を求める文が残れば、次の処理が同じ混同を起こす可能性があります。要約も顧客から来た情報として扱い、業務上の命令を出す権限まで与えないことが重要です。
例えば、申告された注文番号や困り事を決まった項目へ取り出し、システム側の正式な受付手続きへ渡す設計が考えられます。それでも、その注文を照会できる本人かという判断は、抽出結果の自然さではなく、認証・認可の条件で行います。項目を分けたことと権限を確認したことを混同しません。
不審な内容の保管にも判断が要ります。調査に必要な証拠は保護して残し、通常の顧客対応画面や検索用の資料へ無制限に再配布しません。担当者が調査のために開いた文書を、そのまま別の自動処理が読み込むことがないかも確認します。
受付の継続率だけを成果にすると、危険な内容を処理へ戻してしまうかもしれません。遮断件数だけを成果にすると、顧客の相談を失うかもしれません。受付できたか、権限外の操作を止めたか、必要な引継ぎができたかを別々に確かめると、現場が守るべき条件を共有しやすくなります。
一つの問い合わせで、越えてはいけない線を決める
自社で始めるなら、メールを読み、顧客情報を確認し、回答案を作る一つの流れを選びます。外部の文章が入る場所と、実際のデータ取得・変更・送信が行われる場所を並べます。
その上で、文章の内容にかかわらず守る条件を決めます。利用者が見てよい対象だけを取得します。許可されない変更を実行しません。送信先を勝手に増やしません。必要な承認を省略しません。条件をどこで強制し、何の記録で確かめるかまで具体化します。
検証では、許可された環境と合成データを用い、通常の依頼と不正な誘導を含む条件を比較します。攻撃文を再現して公開することより、検出・拒否・引継ぎの結果が業務要件に合うかを確認することが目的です。
顧客の文章を正しく読むAIであることと、どんな文章でも実行権限を変えないシステムであることを、両方確かめておきましょう。
参考情報
公表情報の確認基準日：2026年10月22日。本文は防御設計と評価の論点です。問い合わせ、AI間の要約、引継ぎはAILの想定例であり、実在の事故の再現ではありません。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
