チャットでの本人確認はどう設計する？Intercom のメール認証（OTP）でAIサポートの安全性を高める方法
AIを活用したカスタマーサポートが広がるなかで、あらためて見直したいのが「本人確認をどう設計するか」というテーマです。
チャットは便利でスピーディーな反面、相手の確認があいまいなまま会話が進みやすく、個別情報の案内や手続きの案内には注意が必要です。
特にAIエージェントを活用する場合は、「どこまで自動化するか」だけでなく、「どの場面で確認を入れるか」まで設計しておくことが大切です。
その点で、IntercomのEmail OTPは、AI対応とセキュリティを両立させるための現実的な選択肢のひとつです。
ワークフローの中に認証ステップを入れられるため、必要な場面だけ確認を挟む設計がしやすくなります。
参照：Intercom Help「ワークフロー内のEmail OTPステップによる顧客本人確認」
1. チャットサポートで本人確認が重要になる理由
チャットサポートでは、電話のように声で相手を判断することも、対面のように本人確認書類を直接確認することもできません。
そのため、メールアドレスや名前が一致しているだけで個別情報を返してしまうと、なりすましや誤案内のリスクが生じます。
注文状況、契約情報、チケット履歴、登録情報の変更など、相手を誤ると問題になりやすい対応ほど、確認の仕組みが欠かせません。
AI活用が進むほど、この課題はさらに重要になります。
有人対応であれば、担当者が違和感を覚えて対応を止めることもありますが、AI運用では「どの条件で何を返してよいか」をあらかじめ定義しておかなければなりません。
つまり、AI時代のカスタマーサポートでは、本人確認は現場判断ではなく、ワークフロー設計の一部として考える必要があります。
参照：Intercom Help「ワークフローでFin AIエージェントを使用する」
2. まず整理したい「Messengerの保護」と「問い合わせ時の確認」の違い
ここで一度整理しておきたいのが、Intercomにおけるセキュリティの考え方です。
実務上は「チャットの安全性」とひとまとめにされがちですが、実際には役割の異なる二つのレイヤーがあります。
ひとつは、Messengerそのものを安全に利用するための認証です。
もうひとつは、問い合わせの途中で、個別情報に進む前に確認を入れるための認証です。
参照：Intercom Help「本人確認からJWTを使用したメッセンジャーセキュリティへの移行」
前者について、Intercomはログインユーザー向けのMessenger保護としてJWTを推奨しています。
JWTは、セッション管理やトークン有効期限、属性更新の安全性といった観点で、従来のIdentity Verificationよりも強化された方式として案内されています。
これは「誰がMessengerを利用しているか」を安全に扱うための仕組みです。
一方で、今回注目したいEmail OTPは、WorkflowsやData connector（外部システムのデータを安全に参照・更新するための連携機能）の実行前に、ユーザーが登録済みメールアドレスにアクセスできるかを確認するための仕組みです。
つまり、JWTが「Messenger利用時のセッション保護」であるのに対し、Email OTPは「問い合わせ途中の確認フロー」に近い役割を持ちます。
この違いを押さえておくと、AIサポート設計の議論がぐっと整理しやすくなります。
参照：Intercom Help「Email OTPによる顧客本人確認ワークフロー手順」
参照：Intercom Help「ワンタイムパスコードによるセキュアなデータコネクタ」
3.IntercomのEmail OTPとは何か
IntercomのEmail OTPは、ユーザーのメールアドレス宛に6桁のワンタイムコードを送り、そのコードをMessenger上で入力してもらうことで確認を行う仕組みです。
公式ヘルプでは、Email OTPステップがユーザーのメールアドレスにコードを送信し、入力されたコードが正しいかどうかによって、ワークフローが成功または失敗のブランチへ進むと説明されています。
ここで注意したいのは、Email OTPが確認しているのは、厳密には「登録済みメールアドレスにアクセスできること」だという点です。
したがって、Email OTPは“本人そのものの完全証明”というより、メールアドレスベースの確認フローとして捉えるのが適切です。
参照：Intercom Help「Email OTPによる顧客本人確認ワークフロー手順」
参照：Intercom Help「ワンタイムパスコードによるセキュアなデータコネクタ」
4. Workflowsに組み込むことで実現できること
Email OTPの価値は、単体の認証機能というより、Workflowsの中に組み込めることにあります。
問い合わせ内容に応じて、確認が不要な一般案内はそのままAIが回答し、個別性の高い問い合わせだけ認証付きフローへ進める、といった設計が可能になります。
これにより、利便性を損なわずに、必要な場面だけ確認を求める運用を作りやすくなります。
たとえば、配送状況や登録情報、請求内容、契約状況、過去のチケット履歴といった個別情報にアクセスする前にOTPを挟み、認証に成功した場合のみ次のステップへ進める、といった導線です。
逆に認証に失敗した場合は、一般案内に切り替える、再試行を案内する、有人対応へ引き継ぐなど、失敗時のハンドリングもあらかじめ設計できます。
Workflows内でEmail OTPを条件に設定し、認証成功・失敗に応じて後続フローを分岐できます。
参照：Intercom Help「Email OTPによる顧客本人確認ワークフロー手順」
参照：Intercom Help「ワークフロー内で、メールアドレスを使ってユーザーの本人確認」
5. Fin やData connectorと組み合わせるメリット
AIエージェント活用の観点で見ると、Email OTPはFin やData connectorとの組み合わせで特に効果を発揮します。
Intercomの公式ヘルプでは、OTPが有効なData connectorが呼び出されると、Fin が顧客のメールアドレスにワンタイムコードを送り、顧客が会話内でそのコードを入力し、正しければData connectorが実行されると説明されています。
この構成により、あらかじめ設計したワークフローに基づいて、AIが最初の問い合わせを受け、FAQや一般的な案内はそのまま処理しつつ、機密性の高いデータ参照や個別手続きの直前だけ確認を入れる運用がしやすくなります。
すべての会話を厳重な認証つきにするのではなく、必要な場面だけ認証を求めることで、利用者の体験と安全性のバランスを取りやすくなるのが大きな利点です。
参照：Intercom Help「ワンタイムパスコードによるセキュアなデータコネクタ」
6. 導入時に押さえたい3つのポイント
①どの問い合わせで認証を求めるかを決める
導入時にまず考えたいのは、どの問い合わせに認証を求めるかです。
すべての問い合わせにEmail OTPを求めると、便利なはずのチャット体験が重くなってしまいます。
一方で、個別性の高い情報まで認証なしで返してしまうと、なりすましや誤案内のリスクが高まります。
したがって、重要なのは一律で認証をかけることではなく、問い合わせ内容に応じて必要な場面だけ確認を挟む設計です。
たとえば、FAQのような一般的な案内はそのまま回答し、契約内容、請求情報、注文状況、登録情報の変更といった個別対応の前だけ認証を求める運用が現実的です。
②認証に失敗したときの導線を先に考えておく
認証を設計する際は、成功時だけでなく、失敗した場合の導線もあらかじめ決めておくことが大切です。
Intercomのアップデートでも、Email OTPをもとにしたワークフロー条件を設定し、認証成功時と失敗時で分岐できることが示されています。
たとえば、認証に成功した場合は個別情報の案内やData connectorの実行に進み、失敗した場合は再試行を案内する、一般案内に切り替える、または有人対応へ引き継ぐといった設計が考えられます。
こうした失敗時の扱いまで先に整理しておくことで、運用のブレを減らし、ユーザーにもわかりやすい体験を提供しやすくなります。
③メール到達性と実装条件も確認しておく
Email OTPはメールを使った確認フローであるため、メールアドレスが登録されていないユーザーには利用できません。
Intercomでも、メールアドレスがない場合はData connectorを実行できないため、必要に応じて事前にメールアドレスを取得するフローを設計することが案内されています。
また、OTPを利用する際は、6桁のコード、有効期限10分、入力試行は3回までといった基本仕様も押さえておきたいポイントです。
加えて、メールの到達性や運用の安定性を考えると、カスタムドメインの設定も確認しておくと安心です。
機能そのものだけでなく、実際にユーザーへ確実にコードが届き、スムーズに認証を完了できるかという観点まで含めて設計することが重要です。
参照：Intercom Help「ワンタイムパスコードによるセキュアなデータコネクタ」
7. まとめ
チャットサポートにおける本人確認は、これからのAI活用において避けて通れないテーマです。
IntercomのEmail OTPは、Workflowsの中に確認ステップを組み込み、認証結果に応じて分岐できるという点で、非常に実務的な選択肢です。
とくにFin やData connectorと組み合わせることで、AIが対応を進めながら、必要な場面でのみ確認を求める設計がしやすくなります。
ただし、Email OTPは万能ではありません。
これは「登録メールにアクセスできること」を確認する仕組みであり、Messengerそのもののセッション保護とは役割が異なります。
だからこそ、JWTによるMessenger保護と、Email OTPによる問い合わせ時の確認を適切に組み合わせることが、AIサポートの安全性を高める近道です。
参照：Intercom Help「メッセンジャーにおけるJSONウェブトークン（JWT）を用いたユーザー認証」
参照：Intercom Help「本人確認からJWTを使用したメッセンジャーセキュリティへの移行」
AIエージェントの導入では、「どこまで自動化するか」だけでなく、「どこで確認を入れ、どこで個別情報へのアクセスを許可するか」の設計が成果を大きく左右します。
IntercomやFin を活用する場合も、JWTによるMessenger保護と、Email OTPによる確認フローを組み合わせることで、利便性と安全性の両立を目指せます。
自社の問い合わせ導線に合ったAIサポート設計や、認証を含む運用フローの見直しをご検討中でしたら、ぜひお気軽にご相談ください。
お問い合わせはこちら
https://eclect.co.jp/form/contact_fin
