カスタマーサポートへのAI導入と有人対応の分け方

カスタマーサポートでは、AIを問い合わせへの自動回答だけでなく、担当者の回答作成や問い合わせログの分析にも活用できます。一方で、すべての問い合わせをAIに任せればよいわけではありません。

導入時に重要なのは、何をAIに任せ、どの場面で人が判断するかを先に決めることです。誤回答時の影響や個別判断の必要性、AIに許可する操作範囲まで確認しておくと、AIと有人対応を無理なく組み合わせやすくなります。

この記事では、カスタマーサポートでAIにできることを整理したうえで、AIと人の役割分担、有人対応への切り替え、導入手順、運用後の改善まで順に解説します。

カスタマーサポートでAIにできること｜3つの活用領域

カスタマーサポートにおけるAIは、問い合わせに直接答える仕組みだけを指すものではありません。顧客への対応、オペレーターの支援、問い合わせデータの分析など、複数の業務で利用できます。

生成AIは回答・要約・返信案などを生成する技術として、顧客向けにも担当者向けにも利用できます。チャットボットは顧客と対話するための応対方式であり、生成AIを使うものもあれば、あらかじめ決めたルールで動くものもあります。AIエージェントは、回答だけでなく、許可されたツールや外部システムを使って処理を進める構成を取り得ます。米国国立標準技術研究所（NIST）のAIエージェントに関する資料でも、AIエージェントは環境を認識して行動し、ツールを使ってテキスト出力を超える操作を行うシステムとして説明されています。

1. 顧客への直接対応

ナレッジと対応ルールが整っている問い合わせでは、AIがFAQへの回答や一次対応を担えます。営業時間、手続き方法、サービスの利用条件など、参照元が明確で回答の影響を管理しやすい問い合わせが代表例です。

外部システムの操作までAIに任せる場合は、情報を答えるだけの場合より確認事項が増えます。本人確認、操作権限、実行範囲、記録、停止・復旧方法まで設計したうえで、自動実行の可否を判断します。

2. オペレーター支援

AIは、問い合わせ分類、ナレッジ検索、会話の要約、返信案の作成など、担当者が判断する前の準備にも利用できます。最終回答や承認を人に残せるため、完全自動化が難しい問い合わせでもAIを活用できる余地があります。

たとえば、例外条件を含む問い合わせでは、AIが関連情報を探して回答案を作り、担当者が根拠と顧客の状況を確認してから送信する運用が考えられます。

3. 分析・業務改善

問い合わせログを分析し、頻出する質問や未解決になりやすいテーマを把握する用途でもAIを利用できます。顧客の声（VoC）を整理し、FAQやナレッジの不足、対応フローの見直し候補を見つける使い方です。

ただし、利用できる機能や分析項目は製品によって異なります。3つの活用領域は「製品の種類」ではなく、AIにどの仕事を担わせるかを整理するための見方として捉えるとよいでしょう。

AIに任せる業務・人が担う業務をどう分ける？

AIと人の役割を分けるときは、「簡単な問い合わせはAI、複雑な問い合わせは人」とだけ決めないことが重要です。同じ問い合わせカテゴリでも、実際に行う作業によって必要な判断や権限が異なります。

たとえば「返金」という問い合わせでも、返金ルールを説明する、例外条件を判断する、返金を承認する、実際に返金処理を実行する、という複数の作業に分けられます。まずは問い合わせを具体的な作業単位に分け、そのうえで次の順に確認します。

この考え方は、NIST AI Risk Management Frameworkや、経済産業省のAI事業者ガイドラインなどの一次資料を、カスタマーサポートの実務判断へ落とし込んだものです。公的機関が「AI直接・AI支援＋人・有人」の3分類を共通標準として定めているわけではありません。

4つの軸は合計点で評価しません。重大な影響や許可できない操作権限がある場合に、ナレッジの充実度など別の項目で相殺しないことが重要です。

AIが直接対応しやすい業務

この区分では、AIが回答や処理を確定するところまで担当します。公式FAQや営業時間の案内などが代表例ですが、業務名だけで決めず、上のフローで影響、権限、ナレッジ、個別判断の条件を確認します。

AIが支援し、人が判断する業務

AIは問い合わせ分類、ナレッジ検索、要約、返信案などの範囲が明確な作業を担い、最終判断や承認は人に残します。担当者が根拠を確認し、必要に応じて修正・拒否できることが前提です。

AIと有人対応を組み合わせた不動産チャットボットの事例も、AIが一次対応や情報整理を担い、人が必要な場面を引き取る役割分担の参考になります。

人が対応する業務

AIに情報を渡すことや補助させること自体に許容できないリスクがある場合、または担当者がAIの出力を実質的に確認できない場合は、人が対応する候補です。説明責任や関係修復そのものが中心となる問い合わせも、人が担うほうが適しています。

たとえば「返金」を作業単位に分けると、同じ問い合わせの中でも分類は変わります。

AIから有人対応へ切り替える条件と引き継ぎをどう設計する？

AIと人の役割を決めても、運用中にはAIだけで解決できない問い合わせが発生します。そこで、いつ切り替えるか、誰へ渡すか、何を引き継ぐかを事前に決めておきます。

有人対応へ切り替える条件を決める

切り替え条件は、すべての問い合わせに同じ回数やスコアを当てるのではなく、問い合わせの影響と組み合わせて設計します。優先度の高い条件から確認すると、次のように整理できます。

• 顧客が有人対応を希望：独立した強い条件として扱います。追加質問をする場合も、引き継ぎに必要な情報収集に限定します。
• 高影響・機微・権限外、または人の承認が必要：失敗回数を待たずにAIを一時停止するか、有人対応へ切り替えます。
• AI・連携先システムのエラー：安全に再試行できるかを確認し、同じ失敗が続く場合は処理を止めて人へ渡します。
• 解決不能・同じ失敗の反復：低リスクの問い合わせでは再検索や確認質問を許容できますが、回数はPoCや運用ログを見て調整します。
• 感情・信頼度などの補助シグナル：対応製品で利用できる場合も、単独では判断せず、顧客の明示的な希望や業務ルールと組み合わせます。

感情分析や回答の信頼度は、すべてのAIサポート製品に共通する機能ではありません。また、スコアだけで正答を保証できるわけでもないため、高影響の問い合わせを自動継続する根拠にはしないほうが安全です。

引き継ぎ先と会話の担当を決める

有人対応へ切り替えるときは、空いている担当者へ無条件に振り分けるのではなく、例えば、対応責任と必要な権限を確認したうえで、商品・技術などのスキル、言語、対応チャネル、優先度、在席状況や負荷から候補を絞ります。実際の優先順位は、自社の体制や問い合わせ内容に応じて調整します。

• 人が確認し、AIが継続する：AIはいったん処理を止め、人が承認・修正した後にだけ再開します。「AI支援＋人」の業務に向く方式です。
• 人が会話を引き取る：会話の担当を人へ切り替え、AIの自動返信を止めます。人が対応を終えるまでAIへ戻さない運用です。

営業時間外や担当者不在で割り当てできない場合は、別のキューやチケット、代替チャネルへつなぐ方法も決めておきます。顧客には、次の連絡方法や応答の見込みを案内できる状態にしておくことが重要です。

会話内容と対応状況を引き継ぐ

有人対応への切り替えは、チャネルを変えるだけでは不十分です。担当者がそれまでのやり取りを把握できなければ、顧客が同じ説明を最初から繰り返すことになります。

有人対応へ引き継ぐ際は、少なくとも次の情報を確認します。

• 会話の識別情報・履歴：会話やチケットのID、チャネル、開始時刻、判断に必要な会話履歴。
• 問い合わせ要旨：顧客が何を希望しているか、何に困っているか。要約だけで判断せず、必要に応じて原文へ戻れるようにします。
• 確認済み情報：顧客が明示した事実、本人確認の状態、参照した情報源など。AIの推測は「確認済み」と扱いません。
• 対応状況：AIが質問・検索・提案・実行した内容と、その結果、完了・未完了の状態。
• 切り替え理由と次の判断：顧客の希望、解決不能、業務ルール、システムエラーなどの理由と、承認待ち・未回答点・次に必要な作業。
• 担当・優先度・顧客への約束：現在の担当、優先度、次回連絡予定、案内済みの待ち時間や折り返し方法。

引き継ぐ情報は多ければよいわけではありません。担当者が対応を続けるために必要な範囲に絞り、個人情報や社内情報は権限に応じて扱います。

LiveDeskの公式仕様では、AIからHuman Agentへ会話を引き継ぐフローを構成できます。Rule AgentのAssign AgentでHuman Agentまたはチームへ会話を割り当て、担当者は会話画面で同じ会話記録や顧客・会話関連情報を確認しながら対応できます。また、OverviewではHand-off件数とHand-off Rateを確認できます。

LiveDeskのRule Agentで、条件分岐からHuman Agentのチームへ会話を割り当てるフロー例（EngageLab Docs掲載画面）

これらは現在の製品ワークフローを示す公式仕様であり、すべてのリスクを自動判定する機能や、自動要約が毎回生成されることを意味するものではありません。

カスタマーサポートへのAI導入を6ステップで進める

役割分担と有人対応への切り替えルールを決めたら、対象を絞って検証し、本番運用へ広げます。最初から全問い合わせを自動化するのではなく、導入前の実績と比較できる小さな範囲から始めることが重要です。

• 1

  問い合わせの現状と導入目的を整理する

  まず、問い合わせ件数、カテゴリ、チャネル、対応時間、未解決や繰り返し発生する問い合わせ、現在の担当者負荷を把握します。

  そのうえで「問い合わせ負荷を減らす」「初回応答を早める」「夜間の一次対応を補う」「オペレーターの回答作成を支援する」など、改善したい業務を決めます。AI導入そのものを目的にしないことが重要です。

• 2

  分類済みの対象からPoC範囲と目標を決める

  前章で分類した作業のうち、導入目的に合い、範囲が明確で検証しやすいものからPoC（概念実証）を始めます。自動応答を検証する場合は「AIが直接対応」の候補、オペレーター支援を検証する場合は「AIが支援し、人が判断」の候補から選び、対象カテゴリやチャネルを限定します。

  開始前に、同じ対象条件の導入前実績を残します。成功条件はAI完結率だけにせず、人手負荷、品質監査、顧客満足度（CSAT）などを組み合わせます。具体的な目標値は、自社の導入前実績と許容できるリスクに合わせて決めます。

• 3

  AIが参照するナレッジとデータを整える

  FAQ、マニュアル、過去の対応履歴などについて、AIが参照してよい情報源、適用範囲、最新性、更新担当者、更新フローを決めます。情報が存在するだけでなく、誰が正しさを維持するかまで明確にします。

  顧客データや個人情報を外部のAIサービスへ送る場合は、利用目的、第三者提供、学習への利用有無、保存条件、アクセス権限、ログを確認します。個人情報保護委員会も、生成AIサービスへ個人データを入力する場合は、提供者側での利用条件を十分確認するよう注意喚起しています。詳しくは個人情報保護委員会の注意喚起を確認してください。

• 4

  必要な機能・連携・運用条件を決める

  導入目的と役割分担から、自動応答、ナレッジ検索、オペレーター支援、担当者への振り分け、有人対応への引き継ぎ、問い合わせ管理・CRM・チャネル連携など、必要な能力を整理します。

  AIに外部システムの操作を任せる場合は、読み取りだけか、データ変更まで許可するかを分け、認証、操作権限、記録、停止・復旧条件まで要件に含めます。

  製品候補を確認する段階では、ライブチャットシステム・チャット接客ツールの比較や、問い合わせ管理システムの比較も参考にし、自社の連携先や運用体制に合うかを確認するとよいでしょう。

• 5

  対象を絞って小規模に検証する

  本番に近い条件で、限定したカテゴリ・チャネルをテストします。有人対応への切り替え条件は保守的に設定し、人による確認を残した状態で、誤回答、誤操作、未解決、引き継ぎの状況を確認します。

  導入前実績とPoCの結果は、同じ対象条件と同じ指標定義で比較します。問題が見つかった場合は、ナレッジ、ルール、権限、引き継ぎ条件を修正してから対象を広げます。評価を一度で終わらせず、開発・提供・利用の各段階で見直す考え方は、AIセーフティ・インスティテュート（AISI）のAIセーフティに関する評価観点ガイドでも示されています。

• 6

  本格導入し、運用担当と改善フローを決める

  本格導入時は、ナレッジを更新する担当者、未解決・有人対応への引き継ぎログを確認する担当者、プロンプト・ルール・切り替え条件を調整する担当者を決めます。

  あわせて、見直し頻度、問題を役割分担の再分類へ戻す手順、AIの対象範囲を縮小・停止する条件、復旧方法を決めます。AI導入は、システムを公開した時点で終わりではありません。

導入後はログを見てAIと人の役割分担を改善する

AIの対応範囲は、導入時に決めたまま固定するものではありません。未解決や有人対応への引き継ぎ理由を分析し、ナレッジ、ルール、操作権限、引き継ぎ方法を見直しながら、AIに任せる範囲を広げる・維持する・縮小する判断を続けます。

AIの効果と対応品質を確認する

自動化率だけを成功指標にすると、誤回答や不適切な操作、再問い合わせ、顧客不満を見落とす可能性があります。最低限、効率、品質、顧客体験（CX）の3つの視点から、次の4つの確認項目を見ます。

製品によって「解決率」「自動化率」などの分母や判定条件は異なります。指標名だけを比較せず、分子・分母・除外条件・確認期間・判定方法を記録し、定義を変えた場合は変更日も残しておきましょう。

未解決・有人対応への引き継ぎログを分析する

有人対応への引き継ぎが発生したこと自体を失敗扱いすると、安全のために意図して切り替えたケースまで悪い評価になります。総件数だけでなく、理由を分けて分析します。

• ナレッジが不足していた
• ルールやプロンプトに問題があった
• AIに許可した操作範囲を超えた
• そもそもAI直接対応に適していなかった
• 顧客が有人対応を希望した
• 安全のため想定どおり有人対応へ切り替えた
• システムエラーや想定外の失敗が発生した

たとえば、顧客の希望や高影響業務での安全な切り替えが多い場合は、AI完結率（全対象ベース）が低くても設計どおりに動いている可能性があります。一方、ナレッジ不足や同じ失敗が繰り返されている場合は、AIの対象範囲を広げる前に原因を修正します。

AIに任せる範囲を広げる・維持する・縮小する

業界共通の「AI完結率○％なら拡大」といった固定値はありません。問い合わせ量、導入前実績、誤りが与える影響、自社が許容できるリスクに合わせて判断基準を決めます。目標は自動化率を上げることではなく、品質と顧客体験を保ちながら、任せられる範囲だけを段階的に広げることです。

まとめ

カスタマーサポートへのAI導入は、ツール選定から始めるのではなく、まず既存の問い合わせを棚卸しし、作業単位でAIと人の役割を分けることが重要です。誤回答時の影響、操作権限、ナレッジ、個別判断の必要性を確認すると、「AIが直接対応」「AIが支援し、人が判断」「人が対応」の3つに整理しやすくなります。

最初の一歩として、過去の問い合わせを作業単位に分け、「AIが直接対応」「AIが支援し、人が判断」「人が対応」の3つに仮分類します。その中から、条件が明確でナレッジが整い、影響を管理しやすい作業を選び、対象カテゴリやチャネルを絞ってPoC候補にしてみましょう。その後は、有人対応への引き継ぎログと品質・CXを確認しながら、AIの対応範囲を広げる・維持する・縮小する判断を続けます。

AI対応から有人対応への引き継ぎを含め、自社のサポート運用でどのような構成が可能か確認したい場合は、LiveDeskの導入についてご相談ください。