カスタマーサービスにAIを導入する方法：段階的な計画

著者: Linh Ngo · 更新日: 2026年10月11日

カスタマーサービスへのAI導入とは、測定できるベースラインから出発し、AIが対応または支援する問い合わせタイプを絞り込み、完了テストを定めたパイロットを実施し、その後で初めて展開を広げていく進め方です。 ツールの選定よりも順序のほうが重要です。失敗するチームの多くは、1番目の段階（ベースラインがないため、何かが改善したかどうかを判断できない）か、3番目の段階（誰も整理していないナレッジベースからAIが回答する）を飛ばしています。

このガイドは、AI for Customer Serviceコレクションのうち、導入、指標、ガバナンスのセクションの中心となる記事です。5つの段階について、それぞれの目標、活動、完了基準、一般的な担当者を示し、各テーマの詳細は内容を繰り返さずに、より詳しい記事にゆだねます。

重要なポイント

• 展開は5つの段階で進みます。ベースライン、スコープ、ナレッジ準備、パイロット、拡大です。各段階には完了基準があり、次の段階に進む前に満たす必要があります。
• サポート担当者5,179人を対象とした調査では、生成AIアシスタントを利用することで、1時間あたりの解決件数が平均で14%、新人や低スキルの担当者では34%向上し、経験豊富な担当者への影響はわずかでした（NBER）。
• この結果は、AIが担当者を置き換えるのではなく支援する場合のものです。経験レベルによって効果が大きく異なるため、自社のチームもセグメント別に測定してください。
• CFPBの銀行チャットボットに関する報告書は、人間につながる道のない、繰り返しの応答による「doom loops（抜け出せない堂々巡り）」を警告し、チャットボットは主要なカスタマーサービスの手段としては適していないと述べています（CFPB）。
• 失敗した展開の多くは、段階の省略に行き着きます。ベースラインがない、ナレッジが整理されていない、完了テストのないパイロットなどです。

段階的な計画が一斉ローンチより優れている理由

ツールを購入し、ヘルプセンターに接続して、すべての顧客に向けて一斉に有効化したくなるものです。ただし問題は、不具合を、テストグループではなく顧客を通じて知ることになる点です。古い返金ポリシーを1万人に案内するボットのインシデントは、200人に案内する場合よりはるかに大きくなります。

段階を設けることには、立ち止まる理由を持てるという利点もあります。パイロットが完了基準を満たさなければ、原因を修正するか、スコープを絞ります。段階がなければ、「すでにローンチしたのだから」が続行の根拠になってしまいます。

5つの段階の概要

この表はテンプレートとして使ってください。20人規模のチームなら、段階1と2を2週間にまとめられるかもしれません。規制の厳しい大企業では、段階3だけで1四半期かかることもあります。変えてはならないのは順序と、すべての段階がテストで終わるという点です。

段階1：現在のサポートのベースラインを作る

測定していない改善は証明できません。ベンダーのデモを見る前に、現在のサポートの実態を示す数値を集めてください。問い合わせ理由別のチケット件数、初回応答時間、解決までの時間、対応時間、再オープン率、エスカレーション率、CSATです。メール、チャット、電話は動きがまったく異なるため、チャネル別に分けて集計します。

この段階を有益にする習慣が2つあります。1つ目は、定義を文書で合意することです。「解決済み」は、担当者が解決ボタンを押したことを指す場合も、顧客が7日以内に戻ってこなかったことを指す場合もあります。どちらかに決めてください。2つ目は、後のビジネスケースで同じ条件で比較できるよう、コスト面も記録しておくことです。含めるべきコスト項目については、AIカスタマーサービスのコストの記事で解説しています。

仮定の例を挙げます。あるソフトウェア企業は、チャット件数の31%が「パスワードをリセットするには、請求先情報を更新するにはどうすればよいか」という内容であり、一方で返金トラブルは件数の4%にとどまるものの、上級担当者の時間の大半を占めていることに気付きます。この1枚の表だけで、AIの役割が2種類あることが見えてきます。次の段階の要点はここにあります。

ローンチ後にどの数値を追跡し、どう定義するかについては、AIカスタマーサービスの指標の記事が参考になります。20個の指標を追跡したくなる気持ちは抑えてください。誰にも読まれない20個より、毎週確認する5個のほうが優れています。

完了基準： サポート責任者と財務の双方が「導入前」の状態として受け入れる、1ページのベースライン。

段階2：問い合わせタイプを選ぶ

次に、AIをどこから適用するかを決めます。問い合わせ理由を2つの軸で順位付けします。発生頻度と、誤った回答のコストの大きさです。件数が多くリスクが低いトピック（注文状況、パスワードのリセット、文書が整っているハウツーの質問）は、最初の候補として自然です。件数が少なくリスクが高いトピック（返金トラブル、アカウントの解約、法務や安全に関わるもの）は、通常は人間の担当のままにします。

候補に挙げた問い合わせタイプごとに、はっきりとした判断を1つ下します。AIが最初から最後まで対応するのか、それとも対応する担当者をAIが支援するのか、という判断です。この選択は、顧客に見える信頼の度合いから成功の測定方法まで、以降のすべてを左右します。トピックごとに判断する方法は、自動化か支援かの記事で紹介しています。

また、新しいメッセージがどの問い合わせタイプに属するかを確実に判別する方法も必要です。AIがインテントを読み違えると、その後のすべてのステップに影響します。実際のトラフィックをルーティングする前に、顧客のインテント検出の仕組みと、どの程度の精度が必要かを確認してください。

ACEの用語を使うと、チームの言葉を揃えられます。受信メッセージを読み取るのがingest（取り込み）、理由と緊急度を分類するのがanalyze（分析）、返信を下書きするのがgenerate（生成）、返金の実行や住所の更新がexecute（実行）です。最初の導入の多くは、ingest、analyze、generateまでをカバーし、信頼が得られるまでexecuteは人間に任せます。

完了基準： 3〜5件の名前の付いた問い合わせタイプ。それぞれに、文書化された自動化か支援かの判断と担当者がいる状態。

段階3：ナレッジとデータを準備する

実際の作業の大半は、ここに隠れています。AIアシスタントは、与えられたもの（ヘルプセンターの記事、マクロ、ポリシー文書、過去のチケット）から回答します。2つの記事が返金期間について食い違っていれば、AIはどちらかを選びますが、常に正しいほうとは限りません。

対象範囲内のすべてのトピックについて、次の4点を押さえます。

• 唯一の信頼できる情報源。 重複を統合し、古いページを廃止し、公開のヘルプセンターと社内ポリシーとの食い違いを解消します。
• 担当者と見直し日。 すべての記事に、名前の付いた担当者と再確認の日付が必要です。ナレッジは静かに劣化します。
• 平易で完結した回答。 記事は単独で成り立つように書きます。「料金表を参照」とだけ書かれたページは、AIに何も与えません。
• 整理されたチケット履歴。 過去の会話から学習させる場合は、まず個人データを削除またはマスキングし、品質の低い返信を除外します。

監査の手順と最初に何を修正するかは、サポートデータのAI向け準備の記事で順を追って解説しています。

プライバシーは最後ではなく、この段階で扱うべきものです。AIがどの顧客データを見られるのか、どこで処理されるのか、どれだけの期間保持されるのか、誰が会話をレビューできるのかを決めます。実際のチケットを流す前にベンダーと法務チームに確認すべき質問は、AIサポートにおける顧客データのプライバシーの記事で取り上げています。

完了基準： 対象範囲内のすべてのトピックに、担当者と見直し日のある最新の記事があり、プライバシーに関する判断が文書化されている。

段階4：本物のテストを伴うパイロットを実施する

パイロットはソフトローンチではありません。問い、限られた対象者、事前に合意した合格ラインを備えた実験です。

露出を限定する。 1つのチャネル、1〜2件の問い合わせタイプ、トラフィックの一部から始めます。支援ツールの場合は、担当者1チームだけで始めます。どのステップでも、人間への明確な経路を確保してください。CFPBの報告書は、顧客が人間につながれないとどうなるかを率直に述べています。顧客は繰り返しの応答のループに陥り、チャットボットは主要なカスタマーサービスの手段としては適していないと明記されています（CFPB）。

開始前に目標を設定する。 例を挙げます。「AIが対応したパスワードのリセットは、人間が対応した場合と少なくとも同じ頻度で、再問い合わせなしに解決される」、あるいは「下書きを使う担当者は、CSATを下げることなく、ベースラインより速くチケットを完了する」などです。必ず書き留めてください。結果を見てから設定した目標は、単なる説明にすぎません。

毎週、会話をサンプリングする。 実際の会話を無作為に抽出して読みます。誤った回答、不自然なトーン、AIがエスカレーションすべきだったのにしなかったケースを数えます。最初の1か月は、どのダッシュボードよりも多くのことが分かります。

ベースラインと、セグメント別に比較する。 サポートにおける生成AIの最もよく知られた研究が、その理由を示しています。5,179人の担当者を対象としたNBERの調査では、平均の生産性は14%向上しましたが、新人は34%改善した一方、経験豊富な担当者への影響はわずかでした（NBER）。チーム全体の平均だけを見ていると、実際に誰が恩恵を受けているのかを見逃します。皆さんのパイロットでも同じ差が出るかもしれませんし、違う差が出るかもしれません。

顧客に、誰と話しているのかを伝える。 会話にAIが関わっていることを開示する際の文言と配置を決めます。何を伝えるべきか、いつ義務になりうるかは、カスタマーサービスにおけるAIの開示の記事で解説しています。

リスクログをつける。 ポリシーを誤って案内した、トーンに関する苦情があった、プライバシーの不備があったなど、すべてのインシデントを記録します。注意すべき失敗パターンは、AIカスタマーサービスのリスクの記事に一覧があり、パターンを早期に見つけるのに役立ちます。

完了基準： 事前に合意した目標が1回の報告期間を通して達成され、重大なインシデントが解消され、パイロットを運営する人々（担当者を含む）が継続したいと答えている。

段階5：1歩ずつ拡大する

拡大とは「あらゆる場所で有効にする」ことではありません。小さく、再現可能なパイロットを順に重ねていくことです。一度に1つずつ追加します。新しい問い合わせタイプ、新しいチャネル、新しい言語、あるいはAIの自律性の拡大です。追加のたびに、それぞれの完了基準に照らした短いテストを行います。

多くのチームにとって妥当な順序は次のとおりです。

1. パイロットに合格した問い合わせタイプで、トラフィックの割合を広げます。
2. リスクが同程度の、隣接する問い合わせタイプを追加します。
3. チャネルを追加します（たとえば、最初にチャット、次にメール）。
4. 言語を追加し、ネイティブのレビュアーにサンプルを確認してもらいます。
5. その後で初めて、レコードの更新や少額のクレジットの発行など、AIに行動を取らせることを、承認の上限を設けた上で検討します。

週次のサンプリングは続けますが、結果が安定している間は負荷を軽くしても構いません。ベースラインは四半期ごとに見直してください。AIが単純な質問を引き受けるにつれて、件数の構成が変わるためです。人間に残るのは平均して難しい案件になるので、全体の成果が改善していても、人間が対応するチケット1件あたりの対応時間は増えることがあります。事前に伝えておかないと、失敗のように見えてしまいます。

職種別の実例

同じ計画が、職種に応じて柔軟に使えます。以下は仮定の例ですが、典型的なものです。

カスタマーサポート（ティア1）。 段階2で、注文状況とパスワードのリセットを選びます。AIは「担当者と話す」ボタンを付けて、最初から最後まで対応します。担当者には、プランに関する質問への返信の下書きが提供されます。パイロットでは、再問い合わせをベースラインと比較します。

ITヘルプデスク。 従業員は、VPNへのアクセス、ソフトウェアのインストール、アカウントのロックアウトについて質問します。ソフトウェアの更新のたびに手順が変わるため、ここでは段階3が最も重要になり、すべての記事に短い見直しサイクルを設けます。

カスタマーサクセスとオンボーディング。 AIが設定に関する質問に答え、顧客が同じ質問を3回した場合はそのアカウントにフラグを立てます。サクセスマネージャーが実際に使うのは、回答ではなく、そのフラグです。

人、役割、チェンジマネジメント

展開において、技術は簡単な部分です。難しいのは、担当者が自分たちが置き換えられると感じないようにすること、そして、ナレッジ、サンプリング、エスカレーションのルールを誰かが管理することです。ナレッジの編集者、会話のレビュアー、AIの品質を管轄する担当者など、新しい仕事が生まれます。

役立つ取り組みをいくつか挙げます。

• 段階2と段階4に、経験豊富な担当者を数人巻き込みます。簡単そうに見えて簡単ではない質問を、彼らは知っています。
• マネージャーに、ダッシュボードだけでなく、サンプルレビューの読み方を教えます。

よくある落とし穴

ベースラインがない。 「導入前」の状態がなければ、あらゆる結果は物語になってしまいます。段階1は地味で低コストですが、人が省いてしまうステップです。

最も難しいトピックから自動化する。 チームは最大のコスト項目を追いかけがちですが、それは最もリスクの高い問い合わせタイプであることが多いものです。間違いのコストが小さい領域から始めてください。

整ったサンプルでパイロットを行う。 簡単な会話を選別すると、パイロットは合格しても本番で失敗します。実際のトラフィックから無作為に抽出したサンプルを使ってください。

人間への経路を隠す。 人間につながりにくくすると、コンテインメント率は上がっても、静かに信頼が下がるおそれがあります。出口は見えるようにしておいてください。

ローンチを終わりと考える。 ポリシーも製品も変わり、ナレッジベースはドリフトします。担当者と見直し日がなければ、正確性は数か月で低下します。

1つにまとめた数値で報告する。 単一の「AI成功率」は、簡単なトピックと難しいトピックを混ぜてしまい、誰が恩恵を受けているのかを隠します。問い合わせタイプ別、担当者のセグメント別に報告してください。

ガバナンスを省く。 開示、プライバシー、リスクに関する判断は、ローンチ後に行うと元に戻すコストが高くつきます。担当者を決めて、段階3と4の一部にしてください。