自動化か支援か:AIが担うべきサポート業務を見極める

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
自動化か支援かを決めるとは、顧客からの問い合わせの種類ごとに、複雑さとリスクという2つの基準で振り分け、AIに3つの役割のうち1つを与えることです。その役割とは、単独で解決する(自動化)、人が判断する間に下書きや提案を行う(支援)、関与しない(人間)の3つです。 注文状況の確認やパスワードのリセットのような、複雑さもリスクも低い問い合わせは、自動化の候補になります。込み入っていたり判断が必要だったりするものの、間違えても修正しやすい問い合わせは、支援の候補です。誤った回答が法的、金銭的、安全上の被害につながる問い合わせは、訓練を受けた担当者が引き続き担い、AIの役割は準備に限定します。
このガイドは、「AIならサポートを任せられる」という話をすでに耳にし、それがキューごとに何を意味するのかを決める必要があるサポートリーダー、CXディレクター、サポートマネージャーの方を対象としています。全体像については、まずカスタマーサービスにおけるAIをご覧ください。このガイドでは、「誰がその業務を担うのか」という1つの問いに絞って解説します。
重要なポイント
- 生成AIアシスタントを使ったカスタマーサポート担当者5,179人の調査では、1時間あたりの解決件数で測った生産性が平均14%向上し、新人やスキルの低い担当者では34%向上しました。経験豊富な担当者への影響はわずかでした(Brynjolfsson、Li、Raymond、NBER)。
- Klarnaは2024年2月27日、AIアシスタントが導入後1か月で230万件の会話を処理し、これはカスタマーサービスのチャットの3分の2にあたると発表しました。解決時間は従来の11分から2分未満になり、同じ内容の再問い合わせは25%減少しました(Klarnaのプレスリリース)。
- 2025年5月、KlarnaのCEOは、自動化の推進が行き過ぎて品質を損なったと述べ、同社は人間の担当者の採用を再開しました(Maginative、Bloombergのインタビューを報道)。
- Moffatt v. Air Canada(2024 BCCRT 149)では、同社のチャットボットが誤った忌引運賃の案内をしたことについて、審判所が航空会社に不実表示の過失責任があると判断し、$650.88の損害賠償を命じました(EH Lawによる概要)。
- 米国の消費者金融保護局(CFPB)は、大手商業銀行上位10行がいずれもカスタマーサービスでチャットボットを使っていることを確認し、誤った回答や、人にたどり着けない「抜け出せない堂々巡り(doom loop)」について警告しました(CFPB)。
「すべて自動化」も「支援のみ」も誤りである理由
チームは、たいてい判断ではなくツールから出発します。ベンダーがチケットをデフレクションするボットや、返信を下書きするコパイロットを提案し、「どこで有効にするか」という話になります。これでは順序が逆です。同じAI機能でも、ある問い合わせの種類には最適な答えとなり、別の種類にはリスクになります。
Klarnaは、その両極を示す最も分かりやすい公開事例です。同社自身の発表は、チャットの3分の2、より速い解決、減った再問い合わせという、高速かつ大量の成果を伝えていました。それから1年余り後、同社のCEOはBloombergに対し、コストが重視されすぎて品質が損なわれたと語り、顧客が望めばいつでも人間に連絡できるべきだと述べました(Maginative)。ここから得られる教訓は、自動化が失敗するということではありません。すべての問い合わせの種類に一律の方針を適用すると、いずれ適用すべきでなかった問い合わせにぶつかる、ということです。
逆の間違いも同じくらい高くつきます。すべての問い合わせをコパイロット付きの担当者に回せば、ボットなら数秒で終わるパスワードのリセットにも、人の対応時間を払うことになります。支援のみとする方針は、品質を守る一方で、処理能力向上の大半を手放すことになります。
AIが担える3つの役割
自動化。 AIが、アクションも含めて、人を介さずに問い合わせを最初から最後まで解決します。システムが現実世界で何かを変更するため、最もリスクの高い設定です。通常は、根拠に基づいて回答するアシスタントと、アクションを実行できる自律型エージェントを組み合わせます。

支援。 AIが準備し、人が判断します。関連するポリシーを取得し、スレッドを要約し、返信を下書きし、次のステップを提案し、フォームを入力します。担当者が編集、承認、送信を行います。AIは下書きまでで止まり、自ら行動することはありません。支援の有効性を裏づけるエビデンスは強力です。前述のNBERの調査では、最も大きな効果が最も経験の浅い担当者に表れました。トップクラスの担当者がすでに知っていることを、ツールが表示したためです(NBER)。
人間。 訓練を受けた担当者が問い合わせを担います。AIは、適切な担当者へのルーティング、緊急度の判定、履歴の要約といった形で裏方として働くことはありますが、顧客向けの文面を下書きすることも、結果を決めることもしません。
ルーティングは、特に取り上げる価値があります。分類と優先順位付けは、このガイドのあらゆる判断の上流にあるためです。問い合わせの種類を何かが見分けなければ、適切な役割に振り分けることはできません。詳しくはAIサポートトリアージエージェントをご覧ください。
2つの基準:複雑さとリスク
問い合わせの種類ごとに、2つの問いでスコアを付けます。

複雑さ:正しく解決するのに、どの程度の判断が必要か。
- 低: 安定した情報源から得られる明確な答えが1つあります。「注文はどこですか」「パスワードをリセットするにはどうすればよいですか」などです。
- 中: 答えはありますが、状況によって変わります。どのプランか、どの地域か、どの例外が適用されるかなどです。適切な文書を取得し、顧客のアカウントを確認する必要があります。
- 高: 唯一の正解がありません。担当者がトレードオフを比較検討したり、曖昧なポリシーを解釈したり、感情に対応したりします。重要アカウントからの解約の示唆や、複数の原因が絡むクレームなどです。
リスク:誤った、または配慮に欠けた対応のコストはいくらか。また、元に戻せるか。
- 低: 間違いのコストが小さく、修正できます。ヘルプ記事へのリンクが誤っていても、次のメッセージで訂正できます。
- 中: 間違いによって金銭や信頼を失いますが、回復できます。配送見込みの誤りや、適用漏れの割引などです。
- 高: 間違いが法的、金銭的、安全上、規制上の被害を生むか、元に戻せません。上限を超える返金、医療や安全に関する情報、アカウントの解約、紛争対応、配慮が必要な顧客に関わるものすべてです。
リスクが支配的な基準です。Moffatt v. Air Canadaがその理由を示しています。チャットボットの回答は、一見ごく普通のものでしたが、顧客はそれを信頼して行動し、審判所は航空会社に対し、自社のチャットボットが述べた内容への責任があると判断しました(EH Law)。賠償額は小さいものでした。しかし、その原則は小さくありません。審判所は、チャットボットの回答を航空会社自身の表示として扱ったのです。これは、ユースケースでどの程度のハルシネーションを許容できるかという問いに直結します。
判断マトリクス
この表を使って、問い合わせの種類ごとに既定の役割を割り当てます。自社のキューにとっての出発点と考え、その後、自社のエラーデータに基づいて調整してください。

| 問い合わせの種類 | 複雑さ | リスク | 既定の役割 | 理由 |
|---|---|---|---|---|
| 注文や配送の状況 | 低 | 低 | 自動化 | 照会は1回で答えも1つ、訂正も容易 |
| パスワードのリセット、ログインの支援 | 低 | 低から中 | 本人確認つきで自動化 | 手順は定型だが、アカウントを変更する前に本人確認が必要 |
| 使い方や製品に関する質問 | 低から中 | 低 | 自社ドキュメントの引用つきで自動化 | 承認済みのナレッジベースに基づく回答 |
| プラン、料金、ポリシーに関する質問 | 中 | 中 | 支援、またはロックされたポリシー文面に限って自動化 | ポリシーに関する誤答は約束になってしまう(Air Canadaの事例を参照) |
| 請求の紛争、請求ミス | 中 | 高 | 支援 | 金銭と信頼がかかっており、紛争には規制上の重みもある |
| 返金や返品のリクエスト | 中 | 中 | 上限までは自動化、上限を超える場合は支援 | AIが対応できる金額の上限を設定する |
| 技術的なトラブルシューティング | 中から高 | 低から中 | 支援 | 担当者に必要なのはスクリプトではなく、診断の提案や過去の解決策 |
| クレームやエスカレーション | 高 | 高 | 人間、AIは要約を準備 | 感情と判断が中心となる |
| 解約や離脱リスクのある問い合わせ | 高 | 高 | 人間、AIがアカウントの文脈を提供 | 収益と関係性がかかっている |
| 医療、安全、法務、配慮が必要な顧客のケース | 高 | 高 | 人間のみ | 被害は元に戻せない |
| 営業の見込みがある問い合わせやアップセルの問い合わせ | 中 | 中 | 支援 | 返信は下書きし、オファーは担当者が判断する |
このマトリクスを現実的なものに保つルールが2つあります。1つ目は、リスクが複雑さに優先することです。単純でもリスクの高い問い合わせは、支援か人間に回します。2つ目は、役割が問い合わせの種類だけでなく顧客セグメントによっても異なり得ることです。そのため、初めての顧客からの返金リクエストと、エンタープライズアカウントからのリクエストでは、振り分けが異なる場合があります。
職種別の実例
Eコマースと小売のサポート。 注文状況、返品の可否、配送の変更はリスクの低い照会で、通常は問い合わせ量の最大の割合を占めます。自動返金に上限を設けたうえで、これらから先に自動化します。Klarnaの公表数値は、大量で構造化された問い合わせをアシスタントが処理するとどうなるかを示しています。最初の1か月でチャットの3分の2を処理しました(Klarna)。ただし、これはKlarna自身の報告であって中立的なベンチマークではなく、対象もチャットであって全チャネルではない点に注意してください。
金融サービス。 CFPBの調査は、顧客対応のチャットボットのリスクについて率直に指摘しています。生成モデルによる誤った回答、顧客が想定された言葉を使わない場合に紛争だと認識できないこと、人間への出口がない堂々巡りです(CFPB)。残高の問い合わせは自動化して問題ありません。紛争は人が担い、AIは裏方として支援します。
SaaSと技術サポート。 ティア1の使い方の質問は、答えが自社のドキュメントにあれば、自動化の有力な候補です。トラブルシューティングは支援のケースです。3つの連携にまたがるログインエラーに対応する担当者は、診断の提案、類似する過去のチケット、返信の下書きから恩恵を受けますが、どの修正が当てはまるかは自分で判断する必要があります。
旅行と物流。 料金、運賃、ポリシーを述べるものはすべて約束になります。Air Canadaは、忌引運賃に関するチャットボットの回答が、航空会社自身の表示として扱われることを思い知らされました。ボットがポリシーを述べられるなら、ロックされてバージョン管理されたポリシーの文面から引用し、答えが見つからないときは回答を控えるべきです。
ユースケースを一覧形式で確認したい方は、カスタマーサポート向けAIエージェントをご覧ください。
判断を実行に移す手順
- 問い合わせの種類を棚卸しする。 90日分のチケットを取り出し、15から30の問い合わせの種類にグループ分けします。自社のタグが信頼できるならそれを使うか、モデルにテキストをクラスタリングさせて、人がクラスターに名前を付けます。それぞれについて、件数と平均対応時間を記録します。
- 種類ごとに複雑さとリスクをスコア化する。 上記の低、中、高の尺度を使います。リスクの判断は部門によって異なるため、サポート、法務またはコンプライアンス、チームリーダーが一緒にスコアを付けます。意見の食い違いは有益です。理由を書き留めておきましょう。
- マトリクスから既定の役割を割り当てる。 各種類を、自動化、支援、人間のいずれかにします。まずは件数が多くリスクの低い種類を、キューの先頭に置きます。
- 自動化の候補ごとに、その裏にあるデータを確認する。 自動化された回答の質は、取得するナレッジの質で決まります。ポリシーのページが古かったり、別のページと矛盾していたりする場合は、何かを有効にする前に元の情報を修正してください。そのクリーンアップについては、AIのためのサポートデータの準備で解説しています。
- アクションの上限を設定する。 AIが行動するものについては、上限(返金額、アカウントの変更)と、引き継ぎを必須とする条件を定義します。条件とは、顧客が人を求めた、感情がネガティブに傾いた、同じ質問が2回された、信頼度が低い、などです。上限は、誰も読まないポリシー文書ではなく、システムの中に組み込みます。
- 逃げ道を設ける。 自動化されたすべての経路には、会話の全文を引き継いで人に到達できる、目に見える経路が必要です。監督の設計については、ヒューマン・イン・ザ・ループのAIエージェントで解説しています。CFPBが指摘する「抜け出せない堂々巡り(doom loop)」は、モデルの失敗ではなく設計上の失敗です。
- 1つか2つの問い合わせの種類でパイロットを行う。 自動化は、一部のトラフィックで実施し、人がトランスクリプトを抽出してレビューします。支援は、提案ごとに承認、編集、却下ができる担当者とともに実施し、どれを選んだかを記録します。
- デフレクションだけでなく、解決の質を測定する。 再問い合わせ率、エスカレーション率、問い合わせ後の満足度、抽出レビューに基づくエラー率を追跡します。Klarnaの再問い合わせの数値は、品質を意識した指標のよい例です(Klarna)。デフレクションだけを見ていると、人をうんざりさせて諦めさせるボットを評価してしまいかねません。
- 根拠に基づいて、問い合わせの種類を役割間で移す。 編集率が低いままで、エラー率が測定されて許容範囲にあれば、問い合わせの種類は支援から自動化に昇格できます。逆に、元に戻すこともあります。マトリクスは四半期ごとに見直してください。
- チームの役割を見直す。 AIの下書きをレビューする担当者の仕事は、すべての返信を自分で書く担当者の仕事とは異なります。詳しくはAIとサポートチームの役割をご覧ください。
よくある落とし穴
問い合わせの種類ではなく、チャネルで決めてしまう。 「チャットは自動化、電話は人間」という考え方は、チャットのメッセージが請求の紛争であることもあれば、電話が注文状況の確認であることもある、という事実を無視しています。顧客が必要としていることで判断してください。
デフレクションを成功とみなす。 担当者に届かなかった問い合わせが、必ずしも解決したとは限りません。再問い合わせや、別のチャネルから戻ってくる顧客に注意してください。
ボットに約束をさせてしまう。 料金、適用資格、返金、期限は約束です。ボットがそれらを述べられるなら、管理された元の文面に基づくべきで、ボットは即興で答えるのではなく、答えられないと伝えるべきです。
データが整う前に自動化する。 ナレッジベースが薄かったり矛盾していたりすると、ボットは自信満々の誤った回答を大規模に生み出します。まずコンテンツを直してください。
支援の恩恵が誰に及ぶかを見落とす。 NBERの調査では、最大の効果は新人の担当者に表れ、経験豊富な担当者への影響はわずかでした(NBER)。これはオンボーディングやパイロットの対象を計画するうえで役立つ一方、トップクラスの担当者から大きな時間短縮の報告は期待できない、ということでもあります。
次に読む記事
今月1つだけ行うなら、件数の多い上位20の問い合わせの種類を挙げ、サポート、法務、オペレーションの担当者が同席する1回のワークショップで、それぞれの複雑さとリスクをスコア化してください。その1枚の表は、どんなベンダーのデモよりも、AIをどこに置くべきかを教えてくれます。そのうえで、AIパターンのリスクグラデーションで、パターンごとにリスクがどこにあるかを確認してください。

Customer Success Operations Manager