LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AIチャットボットの有人切替とは、AIから人への引き継ぎ設計を指す

AIチャットボットの有人切替（エスカレーション）とは、AIが対応しきれない会話を、文脈を保った状態で人間のオペレーターへ引き継ぐ設計を指します。Zendeskはこの動きを、AIエージェントが会話の最初の対応者から外れ、人間のエージェントがその役割を担う変化と説明しています^*1。

AIがどれだけ高度でも、会話の相手が理解できない発話や、自動化できない依頼に行き当たる場面はなくなりません。Microsoftのボット設計ガイドも、AIの限界や人手を要する依頼への対応として、ボットから人への引き継ぎが必要になると位置づけています^*2。

有人切替は一方通行の仕組みではありません。Zendeskは、対応済みの会話をAIの管轄に戻す動きを「ハンドバック」と呼び、チケットのステータスが解決から終了に変わった時点で自動的に発生する設計を採用しています^*1。既定では解決から4日後に終了する設定になっており、この期間は変更できます^*1。

信頼度低下・感情検知・特定意図・明示要求——エスカレーションの4トリガー

エスカレーションのきっかけは、大きく4種類に整理できます。第一に、AIの意図認識の確信度が一定の水準を下回る場合です。第二に、顧客の発話から強い不満や困惑がうかがえる場合です。第三に、契約解除や重大なクレームなど、あらかじめ人が対応すべきと定めた特定の意図に触れた場合です。第四に、顧客が「オペレーターに代わってほしい」のように明示的に要求する場合です。

明示要求への対応は、プラットフォームごとに実装の仕組みが異なります。Genesys Cloudは、専用のインテント(発話から読み取る意図の分類)を用意しなくても、あらかじめ用意された表現の一覧と発話を照合してエスカレーション要求を検知する機能を備えています^*5。検知後は確認の問いかけを挟む設計が既定ですが、Confirmationの設定を空にすれば、確認を挟まず直接オペレーターへ引き継ぐ動作に変更できます^*5。

特定意図でのエスカレーションは、意図設計と紐づけて組み込みます。Dialogflow ESでは、特定のインテントが一致した際にliveAgentHandoffパラメータの値をWebhookやAPIの応答へ渡し、以降の引き継ぎ処理を自社システム側に委ねる設計です^*6。endInteractionパラメータを併用すると、AI側がその会話から完全に退場します^*6。

Salesforceも、AIが処理できないエラーや例外が生じた場面、あるいはあらかじめ設定した業務ルールに沿って、Transfer to Agentという標準ダイアログで引き継ぎを実行します^*7。感情検知を追加のトリガーとして組み込む場合は、どの発話パターンを対象にするかを自社の業務要件に合わせて個別に設計する必要があります。

会話履歴・顧客属性・意図分類——コンテキスト引き継ぎで渡す情報

有人切替の質を左右するのは、引き継ぎが発生すること自体ではなく、そのときに何を人に渡すかです。Microsoft Bot Frameworkは、引き継ぎの開始を「handoff.initiate」という名前のイベントで通知する設計を定めています^*2。このイベントには会話IDに加え、ルーティングに使うJSON形式の値と、会話のトランスクリプト(発話ログ)を添付できます^*2。

添付されたトランスクリプトを使うと、引き継ぎを受けたオペレーターは、顧客が事前にAIと何を話していたかを読める状態で対応を始められます^*2。引き継ぎが完了したかどうかは、エージェントハブ側から返す「handoff.status」イベントで通知され、状態はaccepted・failed・completedのいずれかで表現されます^*2。

Amazon Connectでは、チャットを開始する際にJWT(JSON Web Token。署名付きで改ざんを検知できる形式のトークン)へ顧客の氏名や会員IDといった属性を含め、コンタクトコントロールパネル上でオペレーターに表示する仕組みが用意されています^*4。同じ属性はフロー内の分岐条件にも利用でき、ボットからオペレーターへの転送時にも既存のキューへ文脈を保った形で引き継がれます^*3。

エージェントハブ型とAPI連携型——有人チャット・CRMとの統合方式

有人チャットやCRM(顧客関係管理システム)との統合方式は、大きく4つの型に整理できます。どの型を選ぶかによって、外注先に求める開発範囲は変わってきます。

Microsoft Bot Frameworkが定義する「bot as agent」は、ボット自体をエージェントハブに参加させ、既存のライブエージェントと同じ扱いで応答させる方式です^*2。既存のボットを最小限の変更でハブに参加させられる手軽さが特徴です^*2。

もう一方の「bot as proxy」は、ユーザーがボットと直接やり取りを続け、ボットが必要と判断した時点でメッセージルーターがエージェントハブへ会話を振り分ける方式です^*2。ボットが会話に残るため、トランスクリプトの収集やメッセージの加工など、柔軟な制御を利かせやすくなります^*2。

Salesforceは、標準のEinstein Botではチャネルやデプロイメントに指定したキューへ自動転送し、拡張版のボットでは、Bot Overviewページで指定したOmni-Channel(複数チャネルを横断してルーティングする仕組み)のフローへ転送する設計です^*7。Amazon ConnectのStartChatContact APIを使う方式は、自社アプリケーションからチャットを開始し、属性の受け渡しまで自由に設計できます^*3*4。実装の自由度が高いぶん、開発負荷も大きくなる点は見込んでおく必要があります。

営業時間外・エージェント不在時のハンドバック設計

有人切替の設計では、オペレーターが対応できない時間帯の振る舞いを決めておく必要があります。Salesforceは、チャットやメッセージングのチャネルで担当者が不在の場合に知らせる「No Agent」という専用のダイアログを標準で用意しています^*7。

営業時間外に切替要求が発生した場合、選択肢は主に3つです。問い合わせ内容を記録して後ほど対応する、待機時間の見込みを伝えて待たせる、あるいはAIによる自己解決の範囲へいったん戻す、のいずれかになります。どの選択肢を選ぶかは、業種や問い合わせの緊急度によって変わってきます。

ハンドバックの設計も欠かせません。Zendeskでは、対応済みのチケットが解決から終了の状態に変わった時点で、以降の会話の最初の対応者をAIに戻す設計が採用されています^*1。既定では解決から4日後に終了しますが、即時に終了させる運用ルールへ変更することもできます^*1。ハンドバックの条件を明確にしておかないと、対応済みの会話にオペレーターが待機し続ける状態になりかねません。

内製で担うために必要な知識と見落としやすい落とし穴

有人切替の仕組みそのものは、各プラットフォームがAPIやイベントとして公式に用意しています。しかし実装を内製で担うには、複数領域の知識が要ります。NLU(自然言語理解。発話から意図を推定する技術)によるトリガー設計、Webhook・APIを使ったイベント連携の実装、CRMやコンタクトセンター側のルーティング設定、そして稼働後の継続的なチューニングです。

設計を誤ると、顧客体験を損なう事態につながります。Genesys Cloudの確認プロンプトを省略する設定を誤って本番に反映すると、顧客の何気ない発話を誤ってエスカレーション要求と判定し、不要な有人対応が増える可能性があります^*5。反対に確認を挟みすぎると、明示的に要求した顧客を待たせる時間が延び、不満につながりかねません。

コンテキストの引き継ぎ漏れも見落としやすい落とし穴です。Microsoft Bot Frameworkのhandoff.initiateイベントは、トランスクリプトの添付を必須にしていません^*2。実装時に添付を省略すると、オペレーターは会話の経緯を知らないまま対応を始めることになり、顧客が同じ内容を繰り返し説明する事態になりかねません。

自己解決率とエスカレーション率——内製と外注の判断軸

有人切替の設計を評価する指標としては、AIだけで会話が完結した割合を示す自己解決率と、人間のオペレーターへ引き継がれた割合を示すエスカレーション率がよく使われます。両者は表裏の関係にあり、どちらか一方だけを最適化すると、もう一方に無理が生じます。

自己解決率を高めようとトリガーを絞り込みすぎると、AIが対応しきれない会話を無理に自己解決の範囲に留め置くことになり、顧客の不満につながる可能性があります。反対にエスカレーション率を抑えることだけを優先すると、オペレーターの負荷が増え、対応品質の維持が難しくなります。指標は単独で見るのではなく、顧客体験と運用負荷の両面から併せて確認することが大切です。

内製と外注の判断は、対応チャネルの数、既存CRM・コンタクトセンターとの連携範囲、そして社内に運用体制があるかどうかで分かれます。Bot Framework・Dialogflow・Salesforce・Amazon Connectなど、プラットフォームごとに引き継ぎの実装仕様が異なるため、複数チャネルをまとめて設計する場合は、各仕様を横断して理解した実装者が必要になります^*2*6*7*3。外注する場合は、トリガー設計からコンテキスト連携、稼働後のチューニングまでを一括して依頼できるかどうかを確認します。

まとめ：AIチャットボットの有人切替設計で押さえる3つの判断軸

本稿ではAIチャットボットの有人切替（エスカレーション）の設計を、主要プラットフォームの公式情報をもとに整理しました。要点は3つに集約できます。第一に、有人切替は信頼度低下・感情検知・特定意図・明示要求という4種のトリガーで発生し、Genesys CloudやDialogflow ESのように検知の仕組みが公式に用意されています^*5*6。第二に、引き継ぎの質は会話履歴や顧客属性といったコンテキストの渡し方で決まり、Microsoft Bot FrameworkやAmazon Connectが具体的な連携方式を示しています^*2*3。第三に、営業時間外の扱いとハンドバックの条件を事前に決めておくことが、顧客体験を損なわない運用の前提になります^*1*7。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Zendesk「Managing conversation handoff and handback」（https://support.zendesk.com/hc/en-us/articles/4408824482586-Managing-conversation-handoff-and-handback）
2. *2　出典：Microsoft「Transition conversations from bot to human」（Azure Bot Service、Microsoft Learn）（https://learn.microsoft.com/en-us/azure/bot-service/bot-service-design-pattern-handoff-human?view=azure-bot-service-4.0）
3. *3　出典：AWS「Transfer a chat to an agent’s queue, with all context preserved」（Amazon Connect管理者ガイド）（https://docs.aws.amazon.com/connect/latest/adminguide/transfer-chats.html）
4. *4　出典：AWS「Pass contact attributes to an agent in the CCP when a chat starts」（Amazon Connect管理者ガイド）（https://docs.aws.amazon.com/connect/latest/adminguide/pass-contact-attributes-chat.html）
5. *5　出典：Genesys「Agent escalation in voice and digital bot flows」（Genesys Cloud Resource Center）（https://help.genesys.cloud/articles/agent-escalation-in-voice-and-digital-bot-flows/）
6. *6　出典：Google「Dialogflow ES handoff」（Google Cloud Agent Assistドキュメント）（https://docs.cloud.google.com/agent-assist/docs/handoff-es）
7. *7　出典：Salesforce「Understand System Bot Dialogs」（Salesforce Help）（https://help.salesforce.com/s/articleView?id=sf.bots_service_system_bot_dialog.htm&language=en_US&type=5）

Tweet