カスタマーサポートの対応をAIで自動化するときは、いきなり回答を自動で送るのではなく、「チケットの分類」と「回答の下書き作成」をAIに任せ、最終的な回答は担当者が確認して送る形から始めるのが確実です。生成AIは、過去の回答やヘルプ記事を参照しながら、問い合わせに沿った回答文を短時間で作れます。担当者は一から文章を考える代わりに、下書きの内容を確かめて手直しするだけで済むため、一件あたりの対応時間を縮めながら、回答の品質と責任は人が保てます。
そしてもう一つ大切なのが、担当者が確定させた回答を、次の下書きの材料となるナレッジへ戻していく仕組みです。この循環ができると、使い続けるほど下書きの質が上がり、新しい担当者でも経験者に近い回答ができるようになります。逆に、ナレッジが古いまま放置されると、AIは古い情報に基づいた下書きを作り続けます。
この記事は、カスタマーサポートの責任者やリーダー、問い合わせ対応の効率化を任された事業担当者、サポート業務に生成AIを取り入れたいと考えている経営者に向けて書いています。AIに任せる範囲の決め方、チケット分類と回答下書きの仕組み、ナレッジ更新の流れ、導入の手順、品質を保つための運用までを順番に説明します。
カスタマーサポートでAIに任せる範囲を決める
カスタマーサポートの業務は、問い合わせの受付、内容の確認と分類、担当者への割り当て、調査、回答の作成、送信、記録、ナレッジの更新、という流れで進みます。このうち、生成AIが力を発揮しやすいのは、文章を読んで整理する工程と、文章を作る工程です。
| 工程 | AIの役割 | 人の役割 |
|---|---|---|
| 受付・分類 | 種類・緊急度の判定、要約、情報の抽出 | 判定不能や誤分類の修正 |
| 割り当て | 分類結果に基づく担当チームの提案 | 割り当てルールの管理 |
| 調査 | 関連する過去チケットやヘルプ記事の検索 | 個別の契約・利用状況の確認 |
| 回答作成 | 参照情報に基づく下書きの生成 | 内容の確認、修正、送信の判断 |
| 記録・ナレッジ化 | 対応内容の要約、ナレッジ候補の作成 | ナレッジとして採用するかの判断 |
人が担い続けるべきなのは、回答内容に責任を持つ判断です。返金や補償の可否、契約条件の解釈、障害の原因の説明、強い不満を持つ顧客への対応などは、AIの下書きを参考にすることはあっても、判断と文面の最終決定は担当者が行います。
自動送信を検討してよい範囲
一部の問い合わせについては、人の確認なしに回答を送る運用も考えられます。たとえば、パスワード再設定の手順や営業時間の案内のように、答えが一つに決まっていて、間違えても影響が小さい問い合わせです。ただし、自動送信を始めるのは、下書きの運用で品質を十分に確認した後にしてください。最初から自動送信を前提にすると、誤った回答が顧客に届いたときの影響を抑えられません。顧客が直接AIとやり取りするチャットボットの設計については、問い合わせ対応をAIチャットボットで自動化する設計と導入手順で詳しく扱っています。
チケット分類の自動化
問い合わせをチケット管理のツールで管理している場合、新しいチケットが作られた時点でAIに内容を読ませ、分類・緊急度・要約・抽出情報をチケットに書き込む仕組みにします。
分類項目を設計する
分類は、「対応する担当」と「回答の型」が決まる単位で作ります。たとえば「ログイン・アカウント」「請求・支払い」「操作方法」「不具合の報告」「機能の要望」「解約・契約変更」といった分類です。分類ごとに、入るものと入らないものの定義、代表的な問い合わせの例を用意し、AIへの指示に含めます。
緊急度と感情を判定する
分類と同時に、緊急度（業務が止まっているか、期限があるか）と、顧客の感情の強さ（強い不満や怒りが書かれているか）を判定させます。緊急度の高いチケットや、強い不満が表れているチケットは、経験のある担当者に優先的に回します。
抽出した情報を調査に使う
問い合わせ本文から、顧客の企業名、アカウントID、注文番号、エラーメッセージ、発生日時などを抽出してチケットの項目に入れておくと、担当者の調査が速くなります。抽出した情報を使って、顧客の契約状況や直近の利用履歴を自動で取得し、チケットに添えておく仕組みにすることもできます。
メールの分類と担当割当の設計の詳細は、問い合わせメールの振り分けを生成AIで自動化する方法と注意点で解説しています。
過去回答を元にした回答下書きの生成
回答下書きの質は、AIに何を参照させるかでほぼ決まります。生成AIに問い合わせ文だけを渡して回答を作らせると、自社のサービスの仕様や運用ルールを知らないまま、一般論やもっともらしい誤りを書いてしまいます。自社の情報を参照させる仕組みが必要です。
参照させる情報源
- ヘルプ記事・FAQ：公開しているヘルプページやよくある質問
- 社内の対応マニュアル：問い合わせの種類ごとの対応手順、回答の方針、言ってはいけないこと
- 過去の回答：担当者が実際に送った回答のうち、品質が確認できたもの
- 最新のお知らせ：障害の発生状況、仕様変更、キャンペーンなどの一時的な情報
これらの情報を検索できる形で整理しておき、問い合わせが来たら内容に近い情報を探し出して、AIに下書きの材料として渡します。この仕組みは一般にRAGと呼ばれ、手元の文書に基づいて回答を作らせるための代表的な方法です。
下書きの作らせ方
下書きを作らせるときは、次のような指示を組み込みます。
- 渡した参照情報に書かれていることだけを根拠に回答する
- 参照情報で答えられない場合は、推測で書かずに「確認が必要」と明記する
- 下書きの末尾に、根拠にした参照情報の名前やリンクを示す
- 自社の回答の文体（敬語の程度、署名、決まった挨拶）に合わせる
- 返金・補償・契約条件に関する約束は書かない
根拠を示させておくと、担当者は下書きが正しいかを参照元と見比べて確かめられます。根拠がない部分は、担当者が特に注意して確認すべき箇所になります。
障害の発生中や仕様変更の直後など、一時的に回答の方針が変わる場面にも備えておきます。たとえば障害の発生中は、関連する問い合わせの下書きの冒頭に障害のお知らせを自動で差し込む、仕様変更の告知から一定期間は新旧どちらの仕様についての質問かを担当者が確認するよう促す、といった工夫です。一時的な情報は、有効期限を付けて参照情報に登録しておくと、期限が過ぎた後に古い案内が下書きに混ざるのを防げます。
担当者の確認画面
下書きは、担当者が普段使っている問い合わせ管理の画面の中に表示されるのが理想です。別の画面やツールを開いて下書きをコピーする手間があると、担当者は使わなくなります。下書きを採用したか、修正したか、使わなかったかを記録しておくと、後で下書きの品質を評価する材料になります。
ナレッジ更新までの仕組み
回答下書きの仕組みを長く使えるものにするには、ナレッジを更新し続ける流れが欠かせません。用語解説のナレッジベースも参考にしてください。
確定した回答をナレッジ候補にする
担当者が修正して送った回答のうち、他の問い合わせにも使えそうなものを、ナレッジの候補として登録します。AIに回答内容を一般化させ、個人名や契約固有の情報を除いた形でナレッジの下書きを作らせることもできます。
採用はリーダーが判断する
ナレッジ候補をそのまま参照情報に加えるのではなく、サポートのリーダーなど決まった人が内容を確認し、採用するかどうかを判断します。誤った回答がナレッジに入ると、その誤りが以後の下書きに繰り返し使われるためです。
古い情報を外す
仕様変更や料金改定があったときに、古い情報が参照情報に残っていると、AIは古い内容で下書きを作ります。ナレッジには最終更新日と担当者を付け、仕様変更の際に影響する記事を見直す手順を決めておきます。一定期間参照されていない記事や、更新されていない記事を定期的に洗い出すことも有効です。
問い合わせの傾向をサービス改善に返す
分類の結果を集計すると、どんな問い合わせが増えているかが分かります。同じ操作方法の質問が繰り返し来ているなら、画面の分かりにくさが原因かもしれません。問い合わせの傾向を開発チームや企画チームに定期的に共有することで、問い合わせそのものを減らす改善につなげられます。
導入の手順
- 現状を把握する：問い合わせの件数、種類ごとの割合、一件あたりの対応時間、回答までの時間を確認します。
- 参照情報を整える：ヘルプ記事、対応マニュアル、品質の確認できた過去回答を集め、古い情報や矛盾する情報を整理します。この作業が最も時間がかかり、最も効果に影響します。
- 分類と下書きの方針を決める：分類項目、緊急度の基準、下書きの文体、AIに書かせないことを決めます。
- 評価用の問い合わせを用意する：過去の問い合わせから代表的なものを選び、担当者が送った回答を正解として用意します。
- 試作して評価する：分類と下書きを試作し、評価用の問い合わせで品質を確認します。根拠のない内容を書いていないか、言ってはいけないことを書いていないかを重点的に見ます。評価方法は生成AIの出力品質をどう評価するか：評価セットと採点基準の作り方が参考になります。
- 一部の担当者・分類で試行する：特定の分類や一部の担当者に限定して、実際の対応で下書きを使ってもらいます。
- 使われ方を確認して改善する：下書きの採用・修正・不採用の記録と担当者の意見をもとに、参照情報と指示を改善します。
- 範囲を広げ、ナレッジ更新を定着させる：対象の分類と担当者を広げ、ナレッジ候補の登録と採用の流れを日常業務に組み込みます。
具体例：会計ソフトのサポート窓口
架空の例として、中小企業向けのクラウド会計ソフトを提供する会社のサポート窓口を考えます。問い合わせは操作方法の質問が多く、担当者は過去の回答をメールの送信履歴から探してコピーし、手直しして送っていました。経験の浅い担当者は過去回答を見つけられず、同じ質問に一から回答を作っていました。
この会社では、まずヘルプ記事と対応マニュアルを見直し、古い画面の説明を更新しました。そのうえで、問い合わせが届くと分類と要約を付け、関連するヘルプ記事と過去回答を参照した下書きをチケットに表示する仕組みを作りました。税務の判断を求める質問は、下書きを作らず「税理士への確認を案内する」型の回答を表示するようにしました。担当者が修正した回答はナレッジ候補として登録され、リーダーが週に一度確認して採用します。経験の浅い担当者でも、下書きと根拠を見ながら回答できるようになりました。
この会社が試行の段階でつまずいたのは、過去回答の中に、すでに廃止された機能の説明が含まれていたことです。下書きに古い操作手順が混ざり、担当者が修正する手間がかえって増えました。そこで、過去回答を参照情報に加える条件を「直近の一定期間に送ったもの」かつ「リーダーが確認したもの」に絞り直したところ、修正の手間は落ち着きました。参照情報は多ければよいわけではなく、正しさが確認できたものに絞る方が下書きの質は安定します。
効果をどう測るか
AIによるサポート自動化の効果は、対応時間の短縮だけで判断しないようにします。対応が速くなっても、回答の誤りが増えたり、顧客の再問い合わせが増えたりしていれば、全体としては改善していないからです。次のような指標を、導入前と導入後で比べます。
| 指標 | 見る理由 | 注意点 |
|---|---|---|
| 一件あたりの対応時間 | 下書きによる作業短縮の効果を見る | 難しい問い合わせが残ると平均は下がりにくい |
| 初回回答までの時間 | 顧客の待ち時間が減ったかを見る | 夜間・休日の受付分を分けて見る |
| 下書きの採用状況 | そのまま使えた・修正した・使わなかったの割合 | 不採用の理由を担当者に聞いて改善に使う |
| 再問い合わせの件数 | 回答が問題を解決できているかを見る | 同じ顧客・同じ件での追加質問を数える |
| 回答の誤りの件数 | 品質が落ちていないかを見る | リーダーの抜き取り確認で把握する |
| 分類の修正件数 | 分類の精度を見る | どの分類間の取り違えが多いかを確認する |
数字だけでなく、担当者の声も定期的に集めてください。「この分類の下書きはいつも的外れ」「根拠のリンク先が古い」といった現場の指摘は、参照情報や指示を直す具体的な手がかりになります。効果の測り方全般については、業務自動化の費用対効果の測り方：削減時間だけで判断しないでも詳しく扱っています。
品質と安全を保つための注意点
個人情報の扱い
問い合わせには顧客の個人情報や契約情報が含まれます。生成AIのAPIにデータを送る場合は、送信したデータが学習に使われないか、どこにどれだけ保存されるかを、利用するサービスの規約やデータ処理の条件で確認します。社内の生成AI利用ガイドラインとの整合も確認してください。法令上の扱いは、必要に応じて専門家に相談してください。
よくある失敗と避け方
- 参照情報を整えずに始める：古いヘルプ記事や矛盾するマニュアルを参照させると、下書きの品質が上がりません。導入前に参照情報を整理します。
- 最初から自動送信する：品質を確認しないまま自動で回答を送ると、誤った回答が顧客に届きます。下書きの運用から始めます。
- 根拠を示させていない：根拠が示されていない下書きは、担当者が正しさを確かめにくく、確認が甘くなります。根拠の明示を必須にします。
- ナレッジの更新を誰も担当しない：使い始めは品質が高くても、ナレッジが古くなると徐々に下書きの質が下がります。更新の担当と頻度を決めます。
- 担当者の作業画面と切り離す：下書きを見るために別のツールを開く必要があると、使われなくなります。普段の画面の中に組み込みます。
導入前のチェックリスト
- 問い合わせの種類と件数、対応時間の現状を把握している
- 分類項目ごとの定義と例を用意している
- ヘルプ記事・マニュアル・過去回答を整理し、古い情報を除いている
- 下書きに書かせないこと（返金・補償の約束など）を決めている
- 下書きに根拠を示させる設計になっている
- 評価用の問い合わせと正解の回答を用意している
- 下書きの採用・修正・不採用を記録できる
- ナレッジ候補の登録・採用・更新の担当者と頻度を決めている
- 問い合わせデータをAIに送る際の取り扱いを確認している
よくある質問
Q. 回答下書きを使うと、担当者のスキルが育たなくなりませんか？
下書きに根拠となる記事や過去回答を示させておけば、担当者は下書きを確認する過程で自社の仕様や対応方針を学べます。むしろ、経験者の回答に近い下書きを日常的に目にすることで、新しい担当者が早く育つ効果も期待できます。
Q. チャットボットを導入すれば、サポート担当者の仕事は不要になりますか？
チャットボットで解決できるのは、答えが明確な定型の問い合わせが中心です。個別の調査や判断が必要な問い合わせは、引き続き担当者が対応します。チャットボットと担当者向けの下書き支援は役割が違うため、両方を組み合わせるのが一般的です。
Q. 問い合わせの件数が少なくても効果はありますか？
件数が少なくても、一件あたりの調査や回答作成に時間がかかっている場合や、回答の品質が担当者によってばらついている場合には効果があります。まずはヘルプ記事と過去回答の整理から始め、下書き生成の効果を小さく試してみるとよいでしょう。
Q. どんなツールで実現できますか？
問い合わせ管理ツールの中には、生成AIによる要約や下書きの機能を備えたものがあります。標準機能で足りるかをまず確認し、自社の業務システムと連携した調査や、独自のナレッジの参照が必要な場合に、個別の開発を検討します。ツールの機能は更新されることが多いため、最新の情報を確認してください。
Otsumuに相談できること
問い合わせの種類がそれほど多くなく、ヘルプ記事や対応マニュアルが整っているなら、問い合わせ管理ツールの生成AI機能を使って、自社で分類や下書き生成を始めることは十分可能です。この記事の手順のうち、参照情報の整理と評価用の問い合わせの準備だけでも先に進めておくと、どのツールを使う場合でも効果が出やすくなります。
一方で、顧客の契約情報や利用履歴を自動で参照して調査を短縮したい場合、社内のマニュアルや過去チケットなど複数の情報源を横断して下書きを作りたい場合、ナレッジの更新を業務の流れに組み込みたい場合は、仕組みの設計と開発が必要になります。個人情報を含むデータを安全に扱う構成を整えたいときも、外部の知見が役に立ちます。
Otsumuでは、サポート業務の棚卸しとAIに任せる範囲の設計から、チケット分類や回答下書きの仕組み、ナレッジ更新の流れづくり、導入後の改善までを一貫して支援しています。目的から逆算して必要な機能に絞り、小さく試して効果を確かめながら広げる進め方を取ります。詳しくは自社サービス運用の自動化コンサルティングやRAGシステム開発のページをご覧ください。
自社のサポート業務のどこからAIを取り入れられそうか、状況を伺いながら一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01