AIコールの本人確認｜電話番号の一致と情報を開示する権限を分ける

AIコールが着信番号から顧客情報を見つけ、「登録のお電話番号ですね」と応答する。便利な動きですが、その時点で契約内容や問い合わせ履歴まで読み上げてよいかは、別に判断する必要があります。

企業の代表番号を複数人で使う場合や、家族が同じ連絡先を登録している場合もあります。顧客候補を見つけること、電話の相手を認証すること、その人が希望する情報や操作への権限を持つことを、受付の設計で分けておきます。

この記事は、一般的な問い合わせ窓口を想定した運用設計の解説です。特定の新機能の発表を扱うものではありません。以下の業務例は仮想例で、製品の機能や導入効果を保証するものではありません。

発信番号について分かることを確認する

Twilioの公式資料は、発信者番号を偽って表示する問題と、番号の信頼性を扱うSHAKEN/STIRの仕組みを説明しています。最も高い認証区分では、発信側の通信事業者が発信者を把握し、その番号を利用する権利を確認しているとされています。

ただし、これは自社の顧客アカウントで「誰が何を依頼してよいか」を決める情報とは別です。通信側の判定を、そのまま個別契約の閲覧許可や変更権限に置き換えない設計が必要です。

また、同資料が記載するTwilioの対応範囲は米国とフランスです。日本のすべての着信に同じ判定値が届く前提にはできません。利用する回線・サービスで取得できる情報を確認し、値がない場合は未確認として扱います。TwilioのSHAKEN/STIR公式資料（2026年10月29日確認）。

導入担当者は、電話番号、顧客候補、認証結果を一つの「確認済み」表示にまとめず、何を根拠に進めているかを説明できるようにします。

用件ごとに、確認前に答えられる範囲を決める

すべての電話で同じ認証を要求すると、営業時間を知りたいだけの人にも負担がかかります。一方、番号が一致しただけで個別情報を伝えると、共有電話を使う別の人に内容を知らせる可能性があります。

次のように、用件と開示する情報を組み合わせて整理します。以下はIvyLeapの設計例であり、そのまま各社へ適用できる認証基準ではありません。

• 一般案内：公開済みの営業時間やサービス概要を伝える。個別の利用状況は付け加えない。
• 個別照会：顧客が自社で定めた認証を通過してから、許可された範囲の情報を取得して案内する。
• 変更依頼：認証に加えて、その変更を依頼できる権限と変更内容を確認する。
• 代理人からの問い合わせ：本人の認証と代理権限の確認を分ける。判断できないときは担当窓口へ渡す。

AIが先に顧客情報をすべて読み、その後で「この内容は話してはいけない」と指示する構成は見直しの対象です。確認前に必要な情報だけを照会し、個別情報を取得する入口でも認証結果を確認する方法を検討します。

登録連絡先の確認と、今回の認証を分ける

Twilioの認証設計ガイドは、連絡先を初めてアカウントへ関連付ける際の確認と、ログインや顧客対応など継続的なやり取りでの認証を区別しています。また、新しい連絡先を追加する際の確認、認証時の連絡先表示の一部伏せ、再送の間隔や代替手段の用意も案内しています。Twilioの認証設計ガイド（2026年10月29日確認）。

AIコールでは、これを自社の既存の認証手順と接続して考えます。例えば、認証済みの会員画面へ案内してそこで確認を完了し、電話側には結果だけを返す方式が候補になります。具体的な方式は業務の重要度、既存アカウント、利用者が使える手段に合わせて選びます。

電話の相手がその場で伝えた新しい番号にコードを送り、届いたことだけで既存顧客の本人確認を済ませる設計にはしません。その番号を使えることと、照会対象の顧客アカウントを利用する権限は同じではないためです。

確認用の秘密情報をAIの自由な会話へ集めることを前提にせず、認証基盤が受け持つ部分とAIへ渡す結果を整理します。認証手段が使えないときにも、会話だけで条件を緩めず、定めた代替窓口へ案内します。

「確認済み」は、今回の相手と用件へ結び付ける

仮に、顧客Aの契約内容を照会する電話の途中で、別の契約名義の相談へ変わったとします。最初の確認結果をそのまま使うと、対象が変わったことを見落とすおそれがあります。

認証結果を受け取る仕組みには、少なくとも次の対応関係が必要です。

1. 今回の通話と認証の結果が結び付いている。
2. 認証された顧客と、照会対象の顧客が一致している。
3. 許可された案内・操作の範囲が分かる。
4. 認証結果の期限や失効を確認できる。
5. 対象の変更や再接続時に、再確認が必要か判断できる。

これらはシステム側で判定し、AIが「先ほど確認しました」と文章を作ったことを判定の代わりにしません。共通する実行前の確認は、AIエージェントの実行条件でも解説しています。本記事では、そのうち電話の相手と顧客の対応付けに焦点を当てています。

未確認の人へ、余分な情報を返さない

番号に顧客候補が見つからない場合も、認証が失敗した場合も、AIが理由を推測して案内しないようにします。例えば、認証前に登録済みの住所や契約名を読み上げて「こちらで合っていますか」と聞くと、確認のために情報を開示してしまいます。

「このお電話では個別情報の確認が完了していません。所定の確認窓口をご案内します」のように、確認できていない状態と次の手段を伝える構成が考えられます。実際の案内文は、自社のサポート方針に合わせて用意してください。

担当者へ引き継ぐ際は、何を確認できて、どこからが未確認かを残します。担当者につながったことだけで認証を完了扱いにしません。引き継ぎ条件と情報共有の設計は、AIコールから人への引き継ぎを参照してください。

認証の記録には、通話の識別情報、確認方式、結果、確認日時、許可範囲など、調査に必要な項目を定めます。パスワードや確認コードそのものを、会話の要約や自由記述の受付メモへ残さないようにします。

導入前に試したい六つの場面

検証では、正しい利用者が最後まで進めることに加え、確認できない状態で個別情報が出ないことを見ます。テスト用の顧客と連絡先を使い、本番の秘密情報を持ち込まないでください。

1. 一つの会社番号から、権限の異なる利用者が問い合わせる。
2. 非通知や番号の信頼性情報がない着信で、一般案内だけを求める。
3. 正しい番号から着信しても、個別照会の認証は完了していない。
4. 会話中に別の顧客・契約へ対象が変わる。
5. 認証処理が失敗、期限切れ、応答不明になる。
6. 代理人を名乗る人や、登録連絡先を使えない人が問い合わせる。

各場面で、取得した顧客情報、実際に読み上げた内容、実行した操作、担当者へ渡した確認状態を照合します。認証失敗件数だけでは、正常な利用者が進めない問題と、確認不足で情報が出る問題を見分けられません。

AIコールを導入する際は、現在の本人確認手順を整理し、どの用件なら一般案内で完了でき、どこから個別認証が必要かを先に決めます。必要な確認方式を維持したまま、説明や窓口の切り替えを分かりやすくすることが改善の出発点です。

AIコール関連サービスを見る
電話受付の確認手順を相談する

参考情報と対象範囲

• Twilio：Trusted calling with SHAKEN/STIR
• Twilio：Verification and two-factor authentication best practices

両資料は2026年10月29日に確認しました。日付付きの新規発表として紹介するものではありません。番号の信頼性と継続的な顧客認証の違いを参考に、IvyLeapが運用の検討項目を整理しています。特定製品の設定手順、日本での機能提供、各社の業務に必要な認証水準を保証するものではありません。