- DX
- 生成AI
カスタマーサポートのAI活用|オペレーター支援から始める理由

問い合わせ対応にAIを入れるとなると、多くの場合まずチャットボットが候補に挙がります。ただ金融庁の資料によると、対顧客サービスに生成AIを導入している金融機関等の多くが、顧客に直接回答を提示せず、人の判断を介する形で活用しているとのことです。この設計は、他の業種でも参考になります。
そこでこの記事では、カスタマーサポートでのAI活用を6つの領域に分けて整理します。どこから着手すべきか、有人対応にどう切り替えるか、効果をどう測るか。あわせて現場で起きやすい失敗も5つ挙げました。自社のどの業務から始めるかを決める材料としてお使いください。
目次
CS領域でのAI活用|2つの入口がある
カスタマーサポートにAIを入れる、と言ったとき。多くの場合、顧客がチャットボットとやり取りする画面が思い浮かびます。
ただ入口は2つあり、準備が軽いのは顧客から見えないほうです。
| 顧客が直接使う | オペレーターを支える | |
|---|---|---|
| やること | チャットボット、自動応答 | 回答のサジェスト、情報の検索、応対後の記録作成 |
| 誤回答のリスク | そのまま顧客に届く | 人が確認してから伝える |
| 期待できること | 定型的な問い合わせの自己解決を促す | 対応時間や教育負担の軽減、対応品質の安定化 |
| 必要な準備 | FAQの整備、導線の設計、品質の検証 | 参照情報の整備と、利用範囲・確認手順の設計 |
実務では、支援型が先に広がっている
金融庁が2026年3月に公表した「AIディスカッションペーパー(第1.1版)」に、この傾向を示す記述があります。
コールセンター業務などの対顧客サービスに生成AIを導入済の先は相応に存在するものの、ハルシネーション等のリスクを考慮して生成AIのアウトプットを顧客に直接提示することはなく、人の判断を介するユースケースが大半となっていることが確認された。
金融業界の調査ですが、誤回答が直接届くリスクをどう扱うかという論点は、業種を問いません。規制の厳しい業界で採られている設計は、他の業種でも参考になります。
6つの領域に分かれる
| 領域 | 何をするか | 着手のしやすさ |
|---|---|---|
| オペレーター支援 | 回答候補の提示、社内情報の検索 | 最もやさしい |
| 応対記録の作成 | 通話内容の要約、対応履歴の整形 | やさしい |
| FAQの自動生成 | 過去の問い合わせからFAQ案を作る | 元データの整備による |
| 一次対応の自動化 | 定型的な問い合わせに自動で回答する | FAQの整備と導線設計が前提 |
| 応対品質の分析 | 録音・ログから傾向を把握する | 記録の蓄積による |
| 有人切り替えの設計 | AIから人へ引き継ぐ仕組み | 自動化と同時に設計する |
これはAI活用の領域を整理したもので、表の上から順に導入すべきという意味ではありません。実際の着手順序は、オペレーターの構成や既存のFAQの整備状況に応じて判断します。この記事の最後で、判断の目安を示します。
なお有人切り替えは独立した導入段階というより、一次対応を自動化する際に同時に設計すべき仕組みです。
オペレーター支援|効果の出方は現場の構成で変わる
対応中のオペレーターに、回答候補や参照すべき情報を提示する使い方です。最も着手しやすく、誤回答が直接顧客に届かない点でも安全です。
何が提示されるか
- 回答候補 — 問い合わせ内容から、過去の回答や規程をもとに文案を出す
- 参照先 — 該当するマニュアルや約款の箇所を示す
- 関連情報 — その顧客の過去の問い合わせ履歴、契約内容
- 次の確認事項 — 聞き漏らしやすい項目を提示する
4つ目は地味ですが、効果が期待できる機能です。確認漏れによる折り返しを減らせれば、1件あたりの総対応時間の短縮につながります。
ベテランへの効果は限定的な場合がある
ここが導入判断で最も重要な点です。金融庁の同じ資料に、率直な記述があります。
こうした活用方法について、すでに業務に習熟している職員に追加的にもたらす便益は限定的である一方、新たに職務に従事する職員にとっては大きな助けとなっているとされています。そして職場全体の離職率低下に大きく寄与しているといった評価も聞かれているとのことです。
つまり効果の大きさは、現場の構成で決まります。ベテランが長く定着している職場では、期待したほどの時短は出ません。逆に入れ替わりが多く、新人が常にいる職場では効果が大きくなります。
検討の段階で、在籍1年未満のオペレーターが何割いるかを確認してください。この数字は、教育支援による効果を見積もる際の重要な判断材料になります。
チャネルによって、使える形が違う
| チャネル | 支援の形 | 注意点 |
|---|---|---|
| 電話 | 通話内容をリアルタイムで文字化し、 回答候補を画面に出す |
音声認識の精度。 環境音や専門用語の多い業種では事前検証が要る |
| チャット | 顧客の文章から回答候補を提示する | 文字で来るため精度は出やすい。 そのまま送信させない設計にする |
| メール | 返信文の下書きを作る | 最も導入しやすい。既製ツールでも試せる |
メールから試すのが最も手軽です。リアルタイム性が求められず、送信前に必ず人が確認するためです。電話での利用を検討する場合は、自社の通話環境で音声認識の精度を先に確かめてください。
教育コストで見ると、評価が変わる
時短だけで評価すると、この領域は過小評価されます。新人が独り立ちするまでの期間が短くなるという効果があるためです。
これまで「3か月の研修+2か月のOJT」が必要だった業務で、OJT期間が1か月短くなれば、採用のたびにその分が浮きます。離職率が高い職場ほど、この効果は繰り返し発生します。
測るべきは、1件あたりの対応時間だけではありません。独り立ちまでの日数、ベテランへの質問回数、エスカレーションの件数。これらも記録してください。
応対記録の作成|後処理時間を削る
通話やチャットの内容を要約し、対応履歴として残す作業です。見落とされやすいのですが、実は削減効果が大きい領域です。
後処理時間は、意外と長い
1件の対応が終わったあと、内容を記録する時間が発生します。この後処理が1件3分なら、1日40件で120分です。
しかも記録中は次の対応ができません。待ち時間の増加にも直結しています。
効くのは要約より「項目の抽出」
単に会話を要約するだけでは、記録として使いにくいことがあります。実務で効くのは、定められた項目に沿って情報を取り出す使い方です。
- 問い合わせの区分(手続き/不具合/苦情/その他)
- 対象の商品・サービス
- 顧客が求めていたこと
- 対応した内容と、その結果
- 未解決の事項と、次のアクション
この形で抽出できると、そのまま管理システムに入力でき、後の分析にも使えます。自由記述の要約だけでは、集計ができません。
「事実」と「所感」を分ける
記録には、顧客が話した事実と、オペレーターが受けた印象の両方が含まれます。
AIに任せてよいのは前者です。「3日前に注文した商品が届かない」といった発言内容の整理は、確認も容易です。一方「かなりお怒りの様子」といった所感は、担当者が書いてください。
記録の様式を分け、AIが抽出した内容を担当者が確認することで、事実と所感を区別しやすくなります。音声認識や要約には誤りが含まれることもあるため、確認の工程は省かないでください。クレーム対応の経緯を追う場面で、この区別が効いてきます。
リアルタイムか、事後かで難易度が違う
同じ応対記録でも、2つの形があります。
- 事後に処理する — 通話終了後に録音を処理し、記録を生成する。精度を優先でき、導入もしやすい
- リアルタイムに処理する — 通話中に文字化し、終了と同時に記録ができている。後処理時間はほぼゼロになるが、設備と精度の要件が上がる
まず1つ目から始めてください。後処理時間が3分から1分になるだけでも、1日40件なら80分の削減です。リアルタイム化はその効果を確認してからで間に合います。
録音の扱いを確認しておく
通話内容を外部のサービスで処理する場合、音声や文字起こしがどこに保存され、どう扱われるかを確認してください。顧客の氏名や契約内容を含むためです。
入力内容が学習に利用されない設定・契約になっているか。保存期間はどうか。この2点は契約前に確認します。
社内ルールの作り方は生成AIの導入で整理しています。
FAQの自動生成|元データが整っていないと成立しない
過去の問い合わせ履歴から、FAQの案を作る使い方です。一次対応の自動化を検討する前に、ここを通ってください。
なぜ先にFAQなのか
チャットボットの回答精度は、参照する情報の質に大きく左右されます。FAQが古い、分散している、そもそも整理されていない。この状態で自動化すると、誤った回答が返りやすくなります。
しかも回答の精度が低いと「このチャットボットは使えない」と判断され、再利用されにくくなる可能性があります。
過去ログからFAQを作る手順
- 1|問い合わせを分類する — 直近半年〜1年分の履歴から、内容ごとにまとめる
- 2|件数の多い順に並べる — 件数の多い問い合わせから、順にFAQ化を進める
- 3|回答案を作らせる — 実際の対応履歴をもとに、FAQの文面を生成する
- 4|担当者が確認・確定する — 内容の正確性は人が判断する
2つ目で止まっても価値があります。「どんな問い合わせが多いか」が数字で見えるだけで、Webサイトの導線や商品説明の改善点が分かります。
この作業自体に副次的な効果がある
問い合わせを分類していくと、そもそも問い合わせが発生しなくて済む改善点が見えてきます。
- 注文確認メールに書いてあれば聞かれない内容
- 商品ページの記載が分かりにくいために起きている質問
- 手続きの画面が分かりにくく、途中で止まっている
AIで対応を速くするより、問い合わせ自体を減らすほうが効果的な場合もあります。問い合わせの分類は、こうした改善点を見つける有効な手段です。
更新の担当を先に決める
FAQは作って終わりではありません。商品が変わる、価格が変わる、手続きが変わる。そのたびに反映しないと、古い情報を答え続けることになります。
導入時に、誰がいつ更新するかを決めてください。後から決めようとすると、誰も引き受けません。
社内文書を参照させる仕組みについては、別記事でも扱っています。
一次対応の自動化|全件を任せない
顧客が直接AIとやり取りする形です。件数そのものを減らせる反面、設計を誤ると満足度を下げます。
任せる範囲を決める
| 問い合わせの性質 | 自動化の可否 | 理由 |
|---|---|---|
| 配送状況、営業時間、手数料 | 任せやすい | 答えが一意に決まり、システムから取得できる |
| 返品・交換の手順、各種手続きの流れ | 任せやすい | 手順が定まっている |
| 商品の選び方、使い方の相談 | 一部のみ | 条件によって答えが変わる。範囲を絞る |
| クレーム、個別事情を含む相談 | 任せない | 対応を誤ると問題が拡大する |
上2行から始めてください。この範囲だけでも、問い合わせ全体の相当割合を占めることが多くあります。
段階を踏んで広げる
金融庁の資料でも、設計上の工夫として事務的な手続などからAIの活用を始め、知見を蓄積しながら中核的な業務へ適用領域を広げていくことが挙げられています。
最初から全件対応を目指すと、答えられない質問が多発します。対応範囲を狭く始めて、実際の質問ログを見ながら広げるほうが、結果的に早く仕上がります。
「AIが答えている」ことを隠さない
同資料では、顧客向けサービスでの対応として利用開始前に、生成AIによる回答であることと、その特性上誤りが含まれうることを注意喚起することも挙げられています。
隠して人が対応しているように見せると、誤りが見つかったときの不信感が大きくなります。最初から明示しておくほうが、結果的にトラブルが減ります。
どこに置くかで、使われ方が変わる
チャットボットを設置しても使われない、という相談があります。多くは設置場所の問題です。
- 全ページに固定で出す — 接触は増えるが、関係ない質問も増える
- よくある問い合わせが発生するページに置く — 商品ページ、手続き画面、配送情報のページ
- 問い合わせフォームの手前に置く — 件数削減の効果が最も直接的に出る
3つ目は効果を測りやすい配置です。設置前後のフォーム送信数や、チャットでの自己解決率を比較すると、効果を把握しやすくなります。
ただしフォームへの導線を分かりにくくしないでください。「問い合わせたいのにできない」という体験は、問い合わせ内容そのものより強い不満になります。
やってはいけない設計
- 有人対応への導線を隠す — 問い合わせ件数は減りますが、不満は蓄積します
- 同じ質問を繰り返させる — 「もう一度入力してください」が続くと離脱します
- 断定的な表現を使わせる — 「必ず」「確実に」といった表現は、後の紛争につながります
- 個人情報の入力を促す — 「詳しい状況をご記入ください」と書くと、想定以上の情報が入力されます
1つ目が最も多い失敗です。数字は改善しているのに、顧客満足度が下がっているという状態になります。
有人切り替えの設計|ここが満足度を決める
自動化を検討するなら、同時に設計しなければならないのがここです。後回しにすると、必ず問題になります。
金融庁が示している考え方
同資料では、顧客向けサービスの設計上の工夫として次が挙げられています。
- AIが対応するサービスと人間が対応するサービスを、利用者が選択できるようにすること
- 顧客の選択により、いつでもAI対応から有人対応へ移行できるようにすること
「いつでも」という点が重要です。AIが答えられなかったときだけでなく、顧客が望んだ時点で人に替われる設計にします。
切り替えの条件を決める
顧客の意思による切り替えに加えて、システム側から切り替える条件も決めておきます。
- 同じ質問が2回繰り返された — AIが理解できていないサイン
- 一定のやり取り回数を超えた — 解決に向かっていない可能性が高い
- 特定の語が含まれた — 解約、苦情、事故、故障など。対応を誤れない内容
- 金額や契約内容に関わる質問 — 誤回答の影響が大きい
3つ目の語のリストは、自社の業種によって決めてください。医療・金融・不動産など、誤回答の影響が大きい業種ほど広く取ります。
引き継ぎで同じ説明をさせない
最も不満が生まれるのがここです。AIとのやり取りを人が引き継ぐとき、顧客に最初から説明させてはいけません。
「さきほどチャットで話したのに、また同じことを聞かれた」という体験は、自動化しなかった場合より評価を下げます。
やり取りの内容をオペレーター側に引き渡す仕組みを、必ず設計に含めてください。ここが技術的に難しい場合、自動化の範囲を狭めるほうが賢明です。
引き継ぎの形は3つある
| 形 | 内容 | 向いているケース |
|---|---|---|
| 即時に有人チャットへ | 同じ画面のまま、オペレーターが入る | 有人チャットの体制がある |
| 電話への案内 | やり取りの要約を提示し、番号を案内する | 電話が主チャネル。要約を顧客にも見せる |
| 折り返しの予約 | 内容と連絡先を受け取り、後から対応する | 営業時間外、問い合わせ集中時 |
2つ目を採る場合、やり取りの要約を顧客にも表示してください。電話口で「さきほどチャットでお伝えした内容ですが」と顧客自身が説明できる状態になります。
営業時間外の扱いを決める
夜間や休業日にAIが対応し、有人に切り替えられない時間帯があります。この場合の設計も決めておきます。
折り返しの予約を受ける、翌営業日の対応を明示する、緊急時の連絡先を示す。「対応できません」で終わらせないことが、最低限の条件です。
応対品質の分析と、効果の測り方
蓄積された応対記録を分析する領域と、導入効果をどう測るかを扱います。
記録が貯まると、分析に使える
応対記録を構造化して残していれば、次のことが分かるようになります。
- どの商品・サービスで問い合わせが多いか
- どの時間帯・曜日に集中するか(人員配置の判断材料)
- 解決までに時間がかかっている問い合わせの種類
- 繰り返し発生している不具合や不明点
4つ目が最も価値があります。個別の対応としては処理されていたものが、記録として集まると傾向が見えます。商品改善や説明資料の見直しにつながります。
公表されている削減率は、自社の根拠にならない
導入効果については、各社から数値が公表されています。ただしこれをそのまま自社の見込みにはできません。
問い合わせの性質、既存のFAQの整備状況、オペレーターの習熟度。前提が違えば結果も変わります。前述のとおり、ベテランが多い職場と新人が多い職場では、同じツールでも効果がまったく違います。
導入前に記録する4項目
この数字は導入後には取れません。着手前に必ず記録してください。
- 1件あたりの対応時間 — 通話時間と後処理時間を分けて測る
- 1日の対応件数と、担当者数
- 問い合わせの内訳 — 区分ごとの件数。自動化できる範囲の見積もりに使う
- 独り立ちまでの期間 — 新人が一人で対応できるようになるまでの日数
4つ目を入れている記事は多くありませんが、オペレーター支援の効果はここに最も表れます。
効果測定、半数以上が未実施という調査結果
日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査2025」(2024年度調査)によると、言語系生成AIを導入した企業に効果測定の方法を尋ねたところ、最も多かった回答は「効果測定を行っていない」で59.8%でした。その後の調査で数値が変わっている可能性があります。最新の状況はJUASの公表資料でご確認ください。
測っていなければ、続けるべきか、どこを直すべきかを判断できません。翌年度の予算を通す根拠も作れません。
業務の選び方や削減時間の測り方はAIによる業務効率化で整理しています。
失敗パターン5つと、着手の順序
最後に、CS領域でのAI導入で起きやすい失敗を挙げます。
1|FAQが整っていないまま自動化した
最も多い失敗です。参照する情報が古い、分散している、矛盾している。この状態で導入すると誤回答が出ます。一度失った信頼は戻りません。
2|有人切り替えを後回しにした
自動応答だけ先に作り、引き継ぎを設計しなかったケースです。AIで解決できなかった顧客が最初から説明し直すことになり、満足度が低下するおそれがあります。
3|ベテランばかりの職場に支援ツールを入れた
前述のとおり、習熟した担当者への便益は限定的です。効果が出ないのは当然なのですが、「AIは使えない」という結論になってしまいます。対象を選び直せば結果は変わります。
4|件数だけを指標にした
問い合わせ件数が減ったことを成果として報告する形です。有人への導線を隠せば件数は減りますが、不満は別の場所に表れます。解決率や満足度とあわせて見てください。
5|更新する人を決めなかった
FAQも参照文書も、商品や制度が変われば古くなります。半年後に「答えが古い」と言われて使われなくなるのが典型的な経過です。
着手の順序
| 順序 | 領域 | 理由 |
|---|---|---|
| 1番目 | オペレーター支援 | 誤回答が顧客に届かない。新人が多い職場ほど効果が大きい |
| 2番目 | 応対記録の作成 | 後処理時間が減り、記録が分析の材料になる |
| 3番目 | FAQの整理・生成 | 自動化の前提。この作業自体に改善の示唆がある |
| 4番目 | 一次対応の自動化+有人切り替え | 必ずセットで設計する |
| 5番目 | 応対品質の分析 | 記録が貯まってから |
相談する前に整理しておく4項目
- 問い合わせの件数と内訳 — 月に何件、どの区分が何割か
- 1件あたりの対応時間 — 通話と後処理を分けて
- オペレーターの構成 — 在籍1年未満が何割か
- FAQや参照文書の状況 — どこにあり、誰が更新しているか
3つ目と4つ目が、どの領域から着手すべきかを決めます。新人が多ければ支援型から、FAQが整っていれば自動化も視野に入ります。
つまずきの型はAI導入でよくある失敗、費用の考え方はAI導入の費用相場、全体の進め方はAI導入支援で整理しています。小売・EC事業者向けには小売・ECのAI導入でも接客の観点から扱っています。
問い合わせの件数と内訳、オペレーターの構成を伺えれば、どの領域から着手すべきかを絞り込めます。FAQの整備状況次第では、その整理を先にご提案することもあります。
ドコドア やまだ
現在はアプリ開発にも取り組み、Web・アプリの両面から使いやすいサービスづくりを目指しています。
このブログでは、制作・開発の現場で得た気づきやノウハウ、Web・アプリ開発、AI活用に関する情報を発信しています。
【主な技術スタック】 PHP / HTML / CSS / SCSS / JavaScript / WordPress / Shopify / Dart / Flutter
また、SNSでもWeb制作やAI活用に関する情報を発信中です。
Instagram : https://www.instagram.com/docodoor_yamada/