CSでの生成AI活用：問い合わせ分類から回答ドラフト・FAQ整備までの実践ガイド

カスタマーサポート（CS）部門に生成AI（Generative AI、大規模言語モデルを用いてテキストを生成するAI技術）を導入しようとすると、最初に「無人化してクレームが増えないか」という不安が浮かぶことが多い。しかし実際に業務改善に役立っているのは、もっと手堅い場面だ。

問い合わせの仕分けが自動化される。回答の下書きが数分で手に入る。FAQ（よくある質問）が問い合わせ履歴から自動で草案化される。

CS部門での生成AI活用がもたらす変化は「顧客対応の自動化」ではなく、「一次対応の高速化と品質の標準化」である。この区別を冒頭で確認しておきたい。なぜなら「自動化」という軸で設計すると、顧客満足度（CSAT）が下がる失敗パターンに陥りやすいからだ。

本記事では、CS部門の責任者・業務改善担当者・AI（人工知能）導入を検討する実務者に向けて、すぐに試せる5つのユースケースを順番に整理する。読了後には「どのユースケースから始めるか」と「何に気をつけるか」の判断材料が一通り揃う。各セクションは独立して読めるので、今最も課題を感じている箇所から読み始めても構わない。

なお、営業部門での活用事例と比較して読みたい場合は営業での生成AI活用：商談前リサーチから提案書・フォローアップまでの実践ガイドを、CS業務全体の生成AI位置づけを部門横断で把握したい場合は生成AI ビジネス活用大全を先に確認するとよい。

CSでの生成AI活用は「無人化」ではなく「一次対応の高速化と品質の標準化」

CSで生成AIが得意とするのは、「情報を整理して文章にする」という種類の作業だ。問い合わせのカテゴリを判定する、回答の下書きを作る、ナレッジベースを整理する——これらはいずれも「情報の入力→文章の出力」という構造を持っている。

逆に、生成AIが苦手とするのは「判断の責任を伴う対応」だ。顧客の怒りや不安を読み取ること、例外的な状況でどの規約を適用するかを判断すること、クレームの背景にある顧客の本音を引き出すこと——ここは依然として人間の仕事である。

イメージとしては、自動操縦（オートパイロット）ではなく副操縦士（コーパイロット）だ。航路の判断と最終責任は機長＝オペレーターが持ち、AIは計器の読み上げや下書きで負荷を下げる。あなたのチームは今、AIを「機長の代わり」に使おうとしていないだろうか。そう設計してしまうと、誤った情報を顧客に提示したり、テンプレ的な回答を繰り返して顧客不満を積み上げたりする結果になりやすい。

この記事で扱う5つのユースケース

本記事では次の5つを順番に解説する。

1. 問い合わせ分類——カテゴリと優先度の自動タグ付け
2. 回答ドラフト生成——オペレーターの下書き支援
3. FAQ整備——問い合わせ履歴からの自動草案化
4. ナレッジ検索補助——社内資料から回答根拠を探す
5. 応対品質チェック——対応履歴のスコアリングとフィードバック

5つ全部を同時に始める必要はない。まず1つを選んで今週試す、というのが現実的な入口だ。では本論に入る。

---

ユースケース①：問い合わせ分類（カテゴリ・優先度の自動タグ付け）

問い合わせが届くたびに「これは返品か、操作質問か、クレームか」を手作業で判定しているチームは多い。この仕分け作業——ひとつひとつは数分だが、1日に何十件と繰り返すと相応の時間が消える——が、生成AIの最初の適用先として適している。

使い方

問い合わせ本文をそのまま（あるいは匿名化したうえで）生成AIに渡し、「カテゴリ」「優先度」「対応担当者区分」の3点を出力させる設計が基本だ。

プロンプト例の方向性

以下のお問い合わせ本文を読み、次の3点を出力してください。
①カテゴリ（返品・交換 / 操作方法 / 請求・支払い / クレーム / その他）
②優先度（高 / 中 / 低）の理由つきで
③対応区分（一次対応完結 / エスカレーション要）

【問い合わせ本文】
（ここに本文を貼り付ける）

カテゴリの選択肢は自社の問い合わせ分類体系に合わせて事前に定義しておく。AIが自由に分類を作ってしまうと、後工程のCRM（Customer Relationship Management、顧客関係管理システム）連携や集計が崩れる。

before / after

問い合わせ分類を手作業で行っている場合、1件あたり30秒〜2分かかるケースがある（件数・内容の複雑さによる）。生成AIで自動分類すると、人間の確認コストは「分類結果の妥当性チェック」に変わり、慣れれば10〜20秒程度になる場合がある。あくまで目安であり、分類精度はプロンプト設計と選択肢の明確さに大きく依存する。

問い合わせを仕分けたら、次はその問い合わせへの返答を速くする段階だ。

---

ユースケース②：回答ドラフト生成（オペレーターの下書き支援）

「回答の品質がオペレーターによってばらつく」という課題は、CS部門で頻繁に挙がる悩みのひとつだ。経験の浅いオペレーターは回答に時間がかかり、ベテランでないと対応できない問い合わせが積み上がる。

生成AIは、この「初稿を用意する」フェーズで力を発揮する。オペレーターが0から文章を書くのではなく、AIが出した下書きを確認・修正する流れに変えることで、対応時間の短縮と品質の底上げが同時に期待できる。

使い方

問い合わせカテゴリ・問い合わせ要旨・利用可能な回答方針（ポリシーや製品仕様のサマリ）を入力し、顧客向けメール本文の下書きを出力させる設計が基本だ。

プロンプト例の方向性

以下の条件で顧客向け回答メールの下書きを作成してください。
トーンは丁寧かつ簡潔に。本文は300〜400字程度でまとめてください。

【問い合わせカテゴリ】返品・交換
【問い合わせ要旨】購入から5日以内、未開封品を返品したいとのこと
【対応方針】公式ポリシー：購入から14日以内・未開封であれば返品受付
【含めること】返品手続きの手順（①返品フォーム入力 ②着払いで発送 ③受取り後3営業日で返金）

対応方針の部分は、必ず実在するポリシー文書から正確に転載する。AIが方針を推測して書くことのないよう、入力に含める。

before / after

経験の浅いオペレーターが類似の問い合わせ1件を処理するのに15〜20分かかっていた場合、AI下書きを起点にすることで5〜10分程度に短縮される場合がある。ベテランオペレーターでも「考える時間をゼロにする」効果があり、繁忙期のキャパシティ確保に使える。

個別の問い合わせへの回答が速くなったとして、次に検討したいのは「同じ質問が繰り返し来ている状況を解消する」こと——つまりFAQ整備だ。

---

ユースケース③：FAQ整備（問い合わせ履歴からの自動草案）

「FAQ（よくある質問）を更新したいが、誰が書くか決まっていない」というチームは少なくない。CS担当者は対応に追われ、FAQ整備は後回しになりがちだ。その結果、同じ問い合わせが何度も届き続けるという悪循環が生まれる。

生成AIは、この「FAQの素材を問い合わせ履歴から拾い上げる」作業を大幅に加速できる。

使い方

過去1ヶ月〜3ヶ月分の問い合わせ履歴から、頻度の高いカテゴリを抽出し、そのカテゴリの問い合わせ群を束にして生成AIに渡す。AIが「よくある質問と標準的な回答」の草案を出力し、それを人間がレビュー・修正してFAQページに転記する流れだ。

プロンプト例の方向性

以下は【返品・交換】カテゴリの問い合わせ文（個人情報は削除済み）の抜粋5件です。
これをもとに、FAQページに掲載するQ&A形式の草案を3〜5問作成してください。
質問文は顧客が検索しやすい表現に整えてください。回答文は200字以内で簡潔に。

【問い合わせ抜粋】
（ここに匿名化した問い合わせ文を複数貼り付ける）

ここで注意するのは、AIが作ったFAQ草案の「回答内容」に対して、必ず担当者がポリシー文書と照合することだ。AIは問い合わせ文から「おそらくこういう回答だ」と推論するため、実際のポリシーとずれた記述が紛れる可能性がある。

before / after

FAQ草案をゼロから作成するとしたら、カテゴリ1つあたり2〜3時間かかるケースもある。AIの出力をたたき台にすることで、レビューと修正作業に集中でき、1〜2時間で完成させられる場合がある。積み重なると、年間の運用コスト削減に効く。

FAQが整ったとして、次に必要になるのはオペレーターが「ナレッジを素早く引き出せる」仕組みだ。

---

ユースケース④：ナレッジ検索補助（社内資料から回答根拠を探す）

CS部門には「ナレッジベースはあるが、使いこなせていない」という状況がよく起きる。製品仕様書・規約文書・FAQが社内サーバに散在していて、対応中にどこを見ればいいか分からないまま、ベテランに聞いて時間が消える、というパターンだ。

ここで一度、問いを置きたい。自部署の問い合わせ対応で、「この情報がどこにあるか分からない」と感じたことは、ここ1週間に何回あっただろうか？ その回数が多いチームほど、ナレッジ検索補助での生成AI活用が効きやすい。

使い方

社内文書（PDF・マニュアル・FAQなど）を検索可能な形式でAIツールに接続し、「この問い合わせに答えるための情報はどこにあるか」「この規約のどこに返品条件が書いてあるか」を自然言語で問い合わせられる設計をつくる。

技術的な実装方法は複数あるが、業務レベルで試す最初の入口としては、MicrosoftのCopilot（Microsoft 365の業務AIアシスタント）やGoogleのNotebookLM（Googleの調査支援AI）のような既製品を使い、自社文書をアップロードして検索させる方法が比較的導入しやすい（各サービスの利用可否・契約条件は公式情報で確認すること）。

プロンプト例の方向性（文書接続型ツールでの例）

次の問い合わせへの回答根拠を、アップロードしたナレッジベースから探してください。
該当する箇所を引用し、どの文書の何ページ（または何番の項目）にあるかも示してください。

【問い合わせ要旨】購入5日後の未開封品を返品したい

生成AIが「該当する情報が見つかりません」と返答した場合は、ナレッジベース自体にその情報が存在しないか、文書の構造上検索に引っかかりにくい可能性がある。出力されない理由の診断が、ナレッジ整備の改善アクションにつながる。

before / after

ベテランオペレーターが社内で情報を探すのに「感覚で知っている」ため数秒で済む一方、新人が同じことをすると5〜15分かかるというケースがある。ナレッジ検索補助があると、新人でも「まずAIに聞く→引用箇所を確認する→回答に使う」という流れで精度が上がりやすい。

ここまでで、問い合わせの受け口から対応・ナレッジ活用まで4つのユースケースを見てきた。最後の1つは、対応が終わった後の「品質を測り改善につなげる」フェーズだ。

---

ユースケース⑤：応対品質チェック（対応履歴のスコアリングとフィードバック）

CS部門のKPI（Key Performance Indicator、重要業績評価指標）のひとつに「応対品質」がある。ところが、品質チェックをすべて人間の上長がサンプル確認で行うには限界がある。規模が大きくなるほど、確認できる割合は下がる。

生成AIは、対応履歴を自動でスコアリングし、フィードバックの素材を生成するユースケースに使える。

使い方

対応完了後のやり取り（顧客メールとオペレーター回答のセット）を生成AIに渡し、「丁寧さ」「正確性」「解決速度への配慮」「次のアクションの明示」などの評価軸でスコアと改善コメントを出力させる設計だ。

プロンプト例の方向性

以下の対応履歴（顧客メール＋オペレーター回答）を読み、次の4軸で100点満点でスコアを付けてください。
各軸のスコアと、1〜2文のフィードバックコメントを出力してください。

①丁寧さ（敬語・語調）
②正確性（事実の誤りや曖昧な記述がないか）
③解決への明確さ（何をすればよいか顧客に伝わっているか）
④クロージング（次のアクションや問い合わせ先が示されているか）

【対応履歴】
（顧客メール本文と回答メール本文を貼り付ける）

ここでも、顧客の個人情報（氏名・アドレス・注文番号）は入力前にマスキングする。スコアはあくまでAIの評価であり、最終的な人事評価や業績評価に直結させることには慎重であるべきだ。「改善点の気づきを得る素材」として位置づけるのが現時点での現実的な使い方だ。

before / after

品質チェックを上長が手動で行う場合、1件あたり5〜10分かかることが多い。これをAIのスコアリング結果を起点に確認する方式にすると、「スコアが低い案件を優先的にレビューする」トリアージが可能になり、同じ時間でより多くの案件を確認できるようになる場合がある。

---

CS業務に固有の注意点：誤案内・個人情報・規約断定を避けるために

ここまで5つのユースケースを見てきた。それぞれの末尾でも触れたが、CS業務に特有のリスクをまとめて整理しておく。

ハルシネーション（事実誤認）による誤案内

生成AIは「もっともらしい文章」を出力するが、事実を保証しない。特に規約・補償・返金条件に関わる記述は、AIが推測で補ったものが混在しやすい。回答ドラフトをそのまま顧客に送ると「AIが言ったから」ではなく「企業として案内した内容」として扱われる。ポリシーや規約に関わる文言は、必ず人間が一次情報（社内文書）と照合する習慣を制度として設計すること。

個人情報の入力管理

規約・補償の断定禁止

AIが出力した「返金可能です」「〇日以内であれば対応できます」といった断定的な表現を、確認せずそのまま顧客に伝えると、後から「そう言われた」というトラブルになるリスクがある。AIの出力は必ず「仮案」として扱い、最終的な対応内容はオペレーターが判断して送信する運用設計が必要だ。

---

CS KPIから見る生成AI効果の確認方法

「導入してみたが効果がわかりにくい」という声は多い。CS部門での生成AI活用を評価するためのKPIとして適しているのは、主に以下の3つだ。

① 平均処理時間（AHT: Average Handle Time）：問い合わせ1件あたりの処理時間。ユースケース①（問い合わせ分類）とユースケース②（回答ドラフト生成）が直接影響する。使用前後で1〜2週間単位で比較すると変化が見えやすい。

② 初回解決率（FCR: First Contact Resolution）：1回の問い合わせで解決できた割合。ユースケース③（FAQ整備）とユースケース④（ナレッジ検索補助）が効いてくる指標だ。「そのまま二次問い合わせになった件数」を合わせて見ると精度が上がる。

③ 顧客満足度（CSAT）：問い合わせ後のアンケートで測る。ユースケース②とユースケース⑤が間接的に影響する。AI活用で回答品質が上がれば改善傾向が出る一方、AI出力の誤案内が増えれば悪化するため、導入前後のCSATを比較することで質の方向性を確認できる。

PoC（概念実証）として試す場合は、この3つの指標からまず2つに絞るのが現実的だ。全指標を同時に測ろうとすると、何が効いているのか判断しにくくなる。PoCの設計全般については生成AIのPoC設計ガイドで詳しく整理している。

---

よくある失敗：無人化の急ぎすぎ・テンプレ化・属人ナレッジの放置

CS部門で生成AIを試したチームが経験した失敗パターンを3つ整理する。

「無人化」から始めて顧客不満が増加

チャットボットで全問い合わせを自動対応させようとした結果、解決できない問い合わせが増え、最終的に有人対応に戻したというケースがある。顧客は「早さ」より「解決すること」を求めている。自動化は「よくある質問で完結する問い合わせ」の一部に留め、それ以外は有人に引き継ぐ設計を最初から組み込む必要がある。

AI出力をテンプレートとして使い回す

回答ドラフトをほぼ同じ文面でコピペ送信し続けたところ、「同じ返答が何度も来る」という苦情が増えたケースがある。AIの初稿は必ず顧客ごとの文脈に合わせて修正することを、運用ルールとして明文化する必要がある。

ベテランのナレッジを引き出さないまま導入する

AIにナレッジを使わせようとしたが、肝心の社内ナレッジベースが未整備だったため、AIが参照できる情報がないケースがある。「ベテランの頭の中にある対応パターン」はFAQ整備を通じて先に文書化しておく。ユースケース③（FAQ整備）が、他の4つのユースケースの土台になる理由はここにある。

---

CS AIの本質は「チームで共有・改善するナレッジとレビュー基準」

5つのユースケースを一通り見てきた。振り返ると、どのユースケースでも共通して出てくるテーマがある。

生成AIの効果は、チームで共有できるナレッジとレビュー基準の質に比例しやすい。

問い合わせ分類のカテゴリが曖昧なら、AIの分類もぶれる。回答ドラフトのレビュー基準が人によって違うなら、品質のばらつきはAI導入後も残る。FAQが最新の状態に保たれていなければ、ナレッジ検索補助で引き出される情報も古くなる。

これはバックオフィスの仕込み部屋に例えると分かりやすい。どれだけ優れた調理器具（生成AI）を入れても、食材の品質（ナレッジ）と調理基準（レビュー基準）が整っていなければ、料理の品質（対応品質）は上がらない。AIは作業を加速するが、判断の質を保証するのは人間の設計と運用体制だ。

最初の一手：1ユースケースを選んで今週試す

本記事の結論を一文で言えば、「まず1つのユースケースを選んで今週実際に試すことが、最速の学びになる」だ。

どれから始めるかに迷ったら、「現在最もオペレーターの手間がかかっている作業」に着目するとよい。問い合わせの仕分けに時間がかかっているなら問い合わせ分類から。回答品質のばらつきが課題なら回答ドラフト生成から。同じ質問が繰り返し来て対処できていないならFAQ整備から始めるのが自然だ。

最初の検証は不完全でかまわない。「プロンプトをこう変えたら出力が変わった」「このカテゴリは精度が低い」という差分が、次のステップの判断精度を上げる材料になる。

CS業務全体での生成AI活用の位置づけを部門横断で整理したい場合は、生成AI ビジネス活用大全で営業・マーケティング・バックオフィスとの比較ができる。プロンプト設計の技術的な詳細についてはChatGPTプロンプトテクニック完全ガイドも参照するとよい。

CS活用の全体像を部門横断で確認する

部門別ユースケース・PoC設計・ガバナンス・KPI測定を一冊に整理した生成AIビジネス活用の総合ガイドと、AI出力の品質チェックに役立つレビュー基準の記事を合わせて確認すると、CS導入の判断材料が揃う。

生成AI ビジネス活用大全を読む AI出力のレビュー基準を確認する