カスタマーサポートでChatGPT・Claude・Geminiをどう使い分ける？

カスタマーサポートでChatGPT・Claude・Geminiを選ぶときは、回答の賢さを想像で順位付けするより、どの作業に使うか、社内情報がどこにあるか、どのデータを扱うかを先に決めます。FAQ整理、問い合わせの分類、返信案作成、顧客向け自動応答は、必要な接続・権限・確認の重さが違います。最初は人が確認する下書き支援から始め、実データを入れる前に組織の契約と設定を確認してください。

まずCSの仕事を4段階に分ける

「サポートにAIを導入する」を一つの機能として選ぶと、目的とツールがずれます。次のように仕事を分けると、導入の最小単位が見えます。

表は横にスクロールできます

段階	AIに任せる候補	成功条件	人が止める条件
ナレッジ整備	FAQ候補・重複・不足の整理	正本に紐づいた修正案ができる	出典がない、規約が矛盾
問い合わせ分類	topicや緊急度の候補	担当キューへ正しく振り分ける	誤分類で期限・権利に影響
返信案作成	既存ルールに沿った文章	参照元と条件が確認できる	返金・契約・本人確認・障害
顧客向け自動回答	承認済み情報の回答	限定範囲で正答と引継ぎを検証	個別判断、質問不足、矛盾

問い合わせを減らしたいからといって、いきなり顧客向けの回答を自動化する必要はありません。まず過去の問い合わせからFAQ不足を見つけ、次に返信案を担当者が承認する形にし、それで根拠の確認と修正負担を測ります。

選定は社内ナレッジの置き場所から始める

FAQやルールがChatGPTのProjectやClaudeのProject knowledgeで管理されているなら、同じ文脈を繰り返し使う下書き業務で候補になります。Google Workspace内の資料から情報を探す運用なら、GeminiのWorkspace連携や管理設定が候補になります。ただし「連携できる」は「社内の全資料を常に正しく読める」という意味ではありません。製品・契約・ユーザー権限ごとに検索範囲と操作範囲をテストします。

表は横にスクロールできます

現状の置き場 / 条件	最初に試す候補	試す作業	導入前に確認すること
Help Center、手順書を毎回同じ前提で使う	ChatGPT Project / Claude Project knowledge等	FAQに沿った返信案	ファイルの更新方法、権限、参照範囲、組織の利用契約
Gmail・Drive・Docsを中心に作業する	GeminiのWorkspace連携等	社内文書から回答根拠を探す	管理者設定、接続対象、ユーザー権限、データの扱い
Ticket systemが中心	既存CS製品のCopilotやAI機能を含めて比較	分類・返信案を同じ画面で作る	対応するticket、監査ログ、権限、引継ぎ、費用
顧客向けに自動回答する	まず限定FAQで小さく検証	回答と根拠を限定して公開	例外時の停止、誤答監視、承認、有人への切替

この表はサービス間の性能比較ではなく、試験を始める入口です。既存システム内で完結させた方が、データを別サービスへコピーせずに済む場合もあります。一方、必要な検索や管理機能がなければ、契約済みツールだけで無理に実装せず、対象範囲を縮めます。

ChatGPT・Claude・Geminiは機能名でなく仕事の置き場所で比較する

ChatGPT Projectsは、関連する会話・ファイル・プロジェクト指示を一か所にまとめる機能として案内されています。Claude Projectsは、プロジェクト内の会話で共有する知識ベースや指示を設定できると案内されています。Geminiは、Workspace関連アプリを接続して情報を参照する機能がありますが、利用できるアプリ・アカウント・管理者設定は変わり得ます。いずれも、記事執筆時点の一般的な機能説明であり、個別プランや組織のアクセス権を保証するものではありません。

そのため、同じFAQ文書を使って次の小さな試験をします。

1. 使う文書を一つ選び、更新日と正本の場所を確認する。

2. 個人名・注文番号・問い合わせ本文を含まない架空の質問を作る。

3. 3サービスのうち、社内で承認済みの環境へ同じ入力を渡す。

4. 回答文だけでなく、根拠の引用、条件の抜け、答えない判断、修正時間を記録する。

5. 画面名や契約が異なる場合は同条件ではないと記し、優劣を決めない。

この試験で比較するのは、モデルの総合性能ではありません。「情報に到達できるか」「担当者が根拠をすぐ確認できるか」「修正してticketへ移す工程が短いか」です。

返信案作成は、事実・条件・文章を分ける

サポート返信では、流暢さよりも正しい条件が重要です。AIへ渡す前に、顧客の質問と、参照してよい最新資料を切り分けます。回答テンプレートは次の構造にすると誤りを見つけやすくなります。

• 確認できた事実：顧客が伝えた内容と、正本から確認した条件。

• 適用条件：製品、契約、注文時期、地域など、回答の前提。

• 返信案：確認できた範囲で書く文章。

• 未確認：資料にない事項、個別アカウントの状態。

• 次の担当：人が管理画面や契約記録を見て判断する項目。

たとえば「返金できますか」という問い合わせに、共通の返品規約だけで個別の返金可否を答えてはいけません。AIは一般条件を案内する案を作り、注文日・利用状況・個別契約の確認が必要なら担当者へ戻します。契約、請求、障害、個人情報に関わる返信は、承認済みの情報源と人の確認を残してください。

データを入力する前に確認する

各サービスのプライバシー説明は、消費者向け・Business / Enterprise向け、学習利用、保存、アクセス制御などで条件が異なります。「学習に使われない」だけで、顧客データをどこへでも入れてよいとは判断できません。組織が契約している商品名、管理者設定、接続先、保持・削除条件、利用規程を確認します。

テストでは架空データを使い、承認が取れるまで顧客名、メール、注文番号、認証情報、未公開の障害情報を入力しません。管理者が必要なデータ制御を設定できない、または利用履歴を監査できない場合は、そのデータを使う業務をAI対象から外します。各公式ページは一般案内なので、組織の契約条項や管理者画面を置き換えるものではありません。

顧客向け自動回答へ進む条件

返信案で効果を測れた後も、すぐ全問い合わせを自動化する必要はありません。顧客に送信する回答は、誤ったときの影響と、問い合わせ側で訂正できるかを基準に段階を分けます。

• 自動回答候補：正本が一つで、条件が一般化でき、誤答時にも人へ渡せる定型質問。

• Agent支援：個別情報や複数資料が必要で、担当者が根拠を見て送る回答。

• 自動化しない：返金可否、本人確認、法的・契約上の判断、重大障害、例外対応。

小規模テストでは、回答正答率だけでなく、根拠不一致、答えないべき質問への回答、人への引継ぎ漏れ、修正時間、問い合わせ再開率を記録します。エラーが出た場合、モデル、Knowledge source、権限、指示、担当フローのどこが原因かを分けます。件数が少ない試験では、数字を一般的な性能とみなさず、運用上の問題を探す材料として扱います。

次にすること

まず直近の問い合わせを個人情報抜きで10件ほど分類し、FAQ不足・分類・返信案のどこに時間がかかるかを記録します。次に対象工程を一つ決め、社内で承認された環境だけで架空データを使って試します。比較結果はサービス名でなく、作業時間、修正内容、根拠確認のしやすさ、停止条件で判断してください。顧客データを扱う段階へ進むのは、管理者・情報セキュリティ・CS責任者が契約とデータフローを確認した後です。

3サービスを比べるときの評価シート

同じ業務・同じ架空質問・同じ正本で確認できるように、以下のような記録を作ります。実際に試すまでは結果欄を空欄にし、製品説明と実測を混ぜないでください。

表は横にスクロールできます

質問ID	正本	期待する要点	使った契約/環境	出典を示したか	条件を守ったか	修正時間	判定
Q-01	返品規約v3	一般条件と窓口	承認済み試験環境	—	—	—	未試験
Q-02	FAQ記事	対象プランの操作手順	同上	—	—	—	未試験
Q-03	該当なし	分からないと答えて担当へ渡す	同上	—	—	—	未試験

採点は「いい文章か」だけでなく、必須条件を落としたか、出典が追えるか、答えない質問で止まったかを含めます。質問数が少ない段階では、割合を一般性能のように扱わず、失敗モードの発見に使います。

どこまで任せるかを作業ごとに決める

• FAQを見つける：候補出しまでAI、正本の決定と公開は担当者。

• 返信案を作る：承認済みルールから下書き、送信前に担当者が条件と根拠を確認。

• チケットを分類する：誤分類時の担当・期限への影響が小さい範囲で候補付けから開始。

• 顧客へ自動回答する：正答条件が明確で、対象外を検出し、人へ切り替えられる問い合わせに限定。

作業ごとにAIが触れる情報を最小化し、出力を次のシステムへ自動送信しないところから始めると、誤りを修正する余地が残ります。データを連携する段階では、管理者にアクセス権・ログ・削除・保持を確認し、一般のチャット画面で使う条件と業務システム連携の条件を分けて記録します。