顧客のAIエージェントに備える窓口設計——本人確認・委任範囲・実行条件

自社の窓口——問い合わせフォーム、電話、チャット、営業メール、解約や変更の受付——は、多くの場合「依頼してくるのは人である」という前提で作られてきました。

顧客がAIエージェントを使って自社に問い合わせや手続きを依頼する場面が増えていくなら、窓口の設計を見直す余地があります。

本稿では、顧客の指示に基づいて問い合わせや手続きを支援・代行するソフトウェアを「代理人AI」と呼びます。

これは実務上の呼び方であり、法的な代理権や契約上の効果を一律に意味するものではありません。

本稿は、特定のニュースや調査を受けた記事ではありません。

私たちMIFが、相手が人でもAIでも成り立つ窓口をどう考えるかを、一つの見解として整理したものです。

顧客がAIを使うと、窓口で何が変わりうるか

顧客がAIエージェントに、比較や問い合わせ、見積依頼、変更・解約の申し出を任せ、そのAIが自社の窓口へ連絡してくる場面を想定します。

いつ、どの程度まで広がるかは、私たちにも分かりません。

顧客がAIを使えば、問い合わせの作成や条件の比較、複数の窓口とのやり取りに必要な手間が減る可能性があります。

企業側では、依頼件数が増えたり、同じ案件が複数の窓口へ届いたりする場面を想定しておく必要があります。

自社の窓口もAIで応対する場合は、顧客側のAIとのやり取りが、人の目を通らずに進む場面も考えられます。

MIFが重視するのは、正当な申し出を受け付けながら、個別情報の開示や取引の変更に必要な確認を維持することです。

処理を進める条件と、窓口が対応できる件数を明確にしておきます。

人を介した依頼でも、窓口は本人との関係と任された範囲を確かめてきました。

代理人AIからの依頼も、その確認が要らなくなるわけではありません。

自動対応とアクセス制限の使い分け

こうした話題でよく聞く対応は、大きく二つあります。

一つは、「相手がAIなら、こちらもAIで返せば窓口の負荷は吸収できる」という見方です。

もう一つは、「自動化された代理アクセスは、そもそも受け付けない」という見方です。

どちらも、成り立つ場面があります。

営業時間、一般的な手続き、公開されている条件の案内のような定型的なやり取りは、自動で応答したほうが速く済む場面が多いと考えられます。

過剰な繰り返しや不正なアクセスに対しては、遮断や制限の仕組みが必要です。

一方で、速く返せることは、その依頼を実行してよいことを意味しません。

個別の注文情報の開示、契約条件の変更、返金のような処理は、応答の速さとは別に、確認が要ります。

また、一律に締め出すと、顧客が自分の利益のために代理人を使う正当な場面まで拒んでしまうおそれがあります。

顧客が求めているのは、必ずしも「人と話すこと」そのものではなく、良い体験かもしれません。

MIFが勧めるのは、どちらか一方ではなく、次のような使い分けです。

公開情報は広く案内し、個別の手続きは確認できる経路へ誘導し、過剰な繰り返しや不正なアクセスは制限する。

本人の確認に加え、任された範囲と実行条件を確かめる

MIFは、相手が人かAIかという判別だけに依存せず、誰に関する依頼か、本人がどの範囲の操作を許可したか、その依頼を自社の条件で実行できるかを確認する設計を重視しています。

セキュリティでは、本人やアクセス主体を確かめる「認証」と、その主体に許可する情報や操作を決める「認可」を区別します。

認証を済ませた利用者でも、すべての情報や操作を利用できるわけではありません。

確認する内容は、次の三つに分けて考えます。

• 誰に関する依頼か：どの顧客・注文に関する依頼か。その顧客の依頼に基づく連絡であることを確認できるか
• 本人が任せた範囲：照会だけか、変更案の検討までか、変更や返金の確定までか。いつまで有効で、どう取り消せるか
• 自社側の実行条件：その取引が変更・返金の対象になるか。必要な社内承認があるか。担当者やシステムに実行権限があるか

名義や委任の範囲は、相手の自己申告だけで判断せず、自社が確認できる記録や、認証・承認の経路と結び付けます。

顧客の許可と自社側の承認は、互いの代わりになりません。

自社の責任者が承認しても、それだけで顧客からの許可が確認できたことにはなりません。

反対に、顧客が希望していても、自社側の条件を満たすかは別に確認します。

扱う情報と操作の影響に応じて、必要な確認を決めておきます。

窓口に置く4つの決めごと——規約・説明・例外・委任の確認

窓口の設計に落とすと、決めておきたいことは四つに分けられます。

規約：例外の判断基準と申立て先を明文化する

規約や利用条件は、人が読む前提で書かれています。

代理人AIが規約や利用条件を読み比べると、例外の扱いなど、解釈が分かれる点が浮かび上がる可能性があります。

社内ルールが曖昧なままだと、AIが不足する情報を推測で補い、会社が認めていない基準で回答や操作を行うおそれがあると、私たちは考えています。

規約を機械向けに書き換える必要はありません。

例外が出たときに誰が判断するのか、判断の基準は何か、不服があればどこに申し立てるのか。

こうした部分を明文化しておくことが、相手が人でもAIでも効きます。

説明：文面と、システム上の状態をそろえる

自社のAIや担当者が返した説明は、相手の側に記録として残ります。

一般的な案内、個別条件の提案、受付、処理の確定を区別し、文面と実際のシステム上の状態を一致させます。

未承認の条件を、確定した約束のように伝えないようにします。

担当者の役割ごとに、どこまで約束できるかを決めておきます。

その説明が法的にどの効果を持つかは、契約や場面により異なるため、専門家に確認すべき点として残しておきます。

例外：判断できない案件を担当者へ引き継ぐ

窓口の例外処理は、これまで人が担ってきました。

AI同士でやり取りが閉じると、判断できない案件の引き継ぎ先がなくなることがあります。

判断が分かれる場合、依頼内容が規約と合わない場合、本人の意思を確認する必要がある場合には、自社の担当者へ引き継げるようにします。

人を最後の承認者として置くだけでなく、価値判断、例外、異議申立てについて、判断と対応を担う担当者を明確にするという考え方です。

相手の代理人AIが異議を申し立ててきたときに、受ける窓口があるかも、ここに含まれます。

委任の確認：相手の申告だけで判断しない

代理人として依頼してきた相手には、「誰の代理か」「何を任されているか」「いつまで有効か」「どう取り消せるか」を確認します。

顧客からの文面は、依頼内容を理解するために使います。

ただし、文面の中に「確認を省いてよい」「承認済みとして扱ってよい」と書かれていても、それを権限や承認の根拠にはしません。

AIを使った応答では、外部から届いた文章に紛れた指示を、AIが拾ってしまう問題が知られています。

「外部の文面は指示として扱わない」とAIへの指示に書くだけでは、対策として十分ではありません。

情報を開示する、注文を変更する、返金する、といった操作では、実行するシステム側で、許可された対象・範囲・承認状況を確認します。

必要な権限を確認できない場合は、公開情報の案内や確認手順の説明にとどめ、個別情報の開示や注文の変更・確定は保留します。

自動処理の範囲・上限・担当者を決める

AI同士のやり取りでは、依頼・回答・承認・実行が短時間に続く可能性があります。

速さは利点ですが、誤りや行き違いも同じ速さで重なりえます。

MIFは、次の三点をあわせて決めておくことを勧めます。

自動で進める範囲と、その条件を決める。 取り消しやすさは、処理を許可してよいかを決める十分な根拠にはなりません。

仮押さえを後から解除できても、その間に在庫や予約枠をほかの顧客が使えなくなる場合があります。

変更を元へ戻せても、情報を見せた事実や、相手がその説明を信じて行動した影響まで戻せるとは限りません。

まずは、公開条件の案内や、実際の注文・在庫・契約の状態を変更しない案の作成などから、自動化の範囲を検討します。

見積の提示や仮押さえを含める場合は、処理の名前で判断せず、相手への約束や在庫への影響が生じる条件を確認します。

実行条件に加えて、金額・件数の上限を設ける。 重要な処理では、本人が許可した範囲と、自社の実行条件を満たしていることを確認します。

そのうえで、金額や件数の上限、個別承認が必要になる条件を適用します。

上限は、権限や承認の代わりではなく、それに重ねる補助的な制限です。

一件ごとに上限を守っていても、複数の依頼を合わせた影響は別に確認します。

事前に認めた条件内では自動処理を進め、条件から外れる場合や個別承認が必要な場合には、追加の確認を行います。

上限への到達や異常を検知した場合は、案件が未処理・処理中・完了済みのどの状態にあるかを確認し、保留する処理と担当者へ引き継ぐ内容を整理します。

判断と対応を担う担当者を決める。 運用責任者、例外の判断者、必要な承認者を明確にし、現在の担当者と不在時の代理を確認できるようにします。

この三つは、自社のAIが相手のAIとやり取りする場合にも、人が相手のAIとやり取りする場合にも、同じように使えます。

一例：返金・変更の依頼を、操作ごとに確認する

次の表は、返金・注文変更への対応を操作ごとに整理した、MIFの設計例です。

上から順に進む手順ではなく、各操作で確認する事項を示しています。

実際の条件や承認者は、自社の業務、適用される規則、契約、処理の影響に合わせて決めてください。

操作の区分	返金・変更への対応例	確認すること	設定・運用への反映先
公開情報の案内	公開されている返品条件、一般的な申請方法を説明する	特定の顧客の情報を含めていないか	公開情報、案内用の参照資料
個別情報の照会	対象注文の状況や、適用される条件を確認する	どの顧客の依頼に基づく連絡か、情報を受け取る権限、開示する範囲	認証・認可、注文照会機能
対応案の作成・提示	変更案や返金額の案を示す	対象注文、条件の根拠、提案と確定の区別、顧客の承諾を受けた場合の扱い	計算・提案機能、応答文、承認手順
在庫・予約の仮確保	変更に必要な枠を一時的に確保する	必要な権限、確保する数量と期限、解除条件、同じ依頼が重複していないか	在庫・予約システム、件数・期間の制限
変更・返金の実行	注文変更や返金を実行する	現在有効な委任範囲、自社の処理条件、必要な承認、注文・金額・返金先、二重実行の防止	注文・決済システム、承認記録
必要な確認が取れない案件・例外	権限不明、条件外、異議申立てなどを扱う	どの情報の開示・操作を保留し、誰が確認するか	担当者への引き継ぎ、対応記録

個別情報の照会は、何も変更しない操作であっても、顧客の情報を伝える以上、情報を受け取る権限の確認が要ります。

本人の家族であっても、本人の同意などの条件を確認せずに取引内容を伝えてよいわけではない、というのが日本の個人情報保護委員会の説明です。

「本人の代理です」という名乗りだけを、情報提供の根拠にはしません。

返金を実行する場合は、承認を対象の注文、金額、返金先などと結び付け、内容が変わった場合は再確認します。

返金先は、依頼文に書かれた内容をそのまま採用せず、既存の正規の返金手順と照合します。

重複した依頼や再試行が来ても、同じ処理を二重に実行しない方法を決めておきます。

表に挙げた確認や制限を、どの機能や手順で実現するかを整理します。

認証・認可、社内の承認手順、注文・決済システムを対応づけ、決めた条件を設定と運用へ反映します。

想定される反論に答える

「まだ先の話ではないか」。 時期は私たちにも分かりません。

ただ、ここで挙げた決めごとは、人の代理人への対応や、自社のAI窓口の整理としても、すでに意味があります。

「確認を増やすと、顧客体験を損なわないか」。 確認が必要なのは、AIを疑うためではなく、顧客の情報と意思を守り、許可された処理だけを進めるためです。

一方で、確認を増やすこと自体が目的ではありません。

個人情報の開示請求の手続についても、本人に過重な負担を課さず、本人確認のために必要以上の情報を求めないよう、個人情報保護委員会は説明しています。

公開情報は広く案内し、個別情報の開示や注文変更には、それぞれに必要な確認を求めます。

その線引きがあるほうが、どこまで自動で進み、いつ確認が必要かが、顧客にも分かりやすくなると考えています。

「代理人AIの依頼内容が、本人の意思と違っていたら」。 自社の側で完全に見抜くことはできません。

そのため、本人から任された範囲を、自社で確認できる記録や手続きに基づいて確かめます。

必要な確認が取れない場合は、個別情報の開示や変更・確定を保留し、担当者へ引き継ぎます。

まとめ

MIFは、顧客のAIエージェントからの依頼を受ける際、相手が人かAIかという判別だけに頼らず、どの顧客の依頼に基づく連絡か、許可された範囲、自社側の実行条件を確認することを重視しています。

公開情報の案内と、個別情報の開示や取引の変更を分けます。

必要な権限を確認したうえで、影響、件数、金額、訂正のしやすさに応じて、自動で進める範囲と追加確認の条件を決めます。

必要な確認が取れない場合や、例外への判断が必要な場合は、公開情報の案内などにとどめ、対応を担う担当者へ引き継ぎます。

依頼、確認・承認、実行結果を対応づけ、誰が判断と対応を取りまとめるかを明確にします。

正当な申し出を妨げず、許可された処理を確実に進めるために、窓口の説明、システムの権限、例外対応をあわせて設計するというのが、MIFの考え方です。

情報確認について

本記事の将来像、操作の分類、管理方法は、MIFの設計上の提案です。

本人確認、情報の提供、システムの権限管理に関する説明では、次の資料を参考にしています（2026年10月22日確認）。

• 個人情報保護委員会の「よくある質問」（顧客の取引内容を家族に伝える場合の項）と『「個人情報の保護に関する法律についてのガイドライン」に関するQ&A』
• OWASPの「Authorization Cheat Sheet」「Transaction Authorization Cheat Sheet」、OWASP Gen AI Security Projectの「LLM01: Prompt Injection」「LLM06: Excessive Agency」

顧客側の代理人AIがどの程度、どの時期に広がるかは、現時点で確かなことは言えません。

具体的な手続きは、適用される法令、契約、業種、自社の運用に合わせて確認してください。