【2026年最新】Claude CodeでCSエージェント構築｜プロンプト30選

結論：Claude CodeのAPIを使えば、月額数万円のSaaSを契約せずとも、自社業務にフィットしたCSエージェントを4週間で本番稼働させることができます。

この記事の要点：

• 要点1：Tier 1（一般FAQ）の問い合わせはClaude Codeで80%以上を自動解決できる
• 要点2：プロンプト設計・分類・エスカレーションの3フェーズを正しく組めば、DecagonやAda CXと同等の仕組みを自社で構築できる
• 要点3：個人情報保護法・記録管理への対応をプロンプト設計に組み込むことが長期運用の鍵

対象読者：CS担当者・エンジニア・DX推進部門（中小〜中堅企業）

読了後にできること：今日からコピペで動くCSプロンプトを試し、自社CS業務の自動化ロードマップを描くことができます。

「CSツールを入れたのに、オペレーターへのエスカレーションが減らない……」

企業向けAI研修で、最近ものすごく増えた相談です。DecagonやZendesk AIを導入しても、初期設定が大変すぎて現場が使いこなせなかったり、料金が高くて費用対効果を感じられなかったり。そういう声を本当によく聞くんです。

あるECサイト運営の顧問先では、既存チャットボットのFAQ改訂に毎月10時間以上かかっていました。それがClaude CodeのAPIを活用したCSエージェントに切り替えてから、FAQ更新の工数が8割削減されました。プロンプトを書き直すだけでFAQが刷新できるので、担当者が「自分で改善できる」と実感できるのが大きな変化だと言っていました。

この記事では、Claude CodeのAPIを使ってCSエージェントを自社構築する方法を、コピペで使えるプロンプト30選とともに全公開します。既存SaaSとの差別化ポイント、失敗パターン、個人情報保護法対応まで、実装者が迷わないよう徹底的にまとめました。今日から試せるものを順番に紹介しますので、ぜひ手を動かしながら読んでください。

AIエージェントの基本概念や導入ステップについては、AIエージェント導入完全ガイドで体系的にまとめています。まず全体像を押さえたい方は先にそちらをご覧ください。

まず結論：Claude Code×CSで何が変わるのか

結論から言います。Claude CodeのAPIをCSに使う最大のメリットは「プロンプトを書き換えるだけで業務ルールを更新できる」という柔軟性です。既存のチャットボットSaaSは、フロー設計画面でシナリオを書き直す必要があり、エンジニアなしには変更できないことが多い。でも、Anthropic APIを直叩きする自社実装であれば、CSスーパーバイザーがプロンプトを修正するだけで翌日から挙動が変わります。

カスタマーサービスにおける生成AI市場は世界全体で急速な拡大が続いており、日本でも問い合わせの最大30%をAIで解決している先進企業が現れています（出典：コールセンタージャパン・ドットコム「自動対話システム市場の現状と展望 2025年版」）。チャットボット市場はCAGR22.9%で成長し、2029年度には445億円規模に達すると予測されています。

ただし、「プロンプトを書けば全部解決」というほど甘くはありません。Tier 1（一般FAQ）とTier 2（複雑な問い合わせ）とTier 3（クレーム・法的対応）を明確に分けた設計が不可欠です。この記事では、その分け方と30本のプロンプトを一気に解説します。

既存CS SaaSとの違い：なぜ自社構築を選ぶか

まず、市場の主要プレイヤーと自社構築（Claude Code API）を比較して、どのケースで自社実装が有利かを整理しましょう。

主要CSプラットフォームとの比較表

自社構築が向いているケース：

• 業種特有の専門用語・業務ルールが多く、既存SaaSのFAQ設計では対応しきれない
• 社内システム（基幹DB・CRM・在庫管理等）との深い連携が必要
• 月間問い合わせ件数が少なく、高額SaaSの費用対効果が出にくい
• 個人情報をサードパーティに渡したくないセキュリティポリシーがある

SaaSが向いているケース：エンジニアリソースがなく、UI込みで即日稼働させたい場合は、Zendesk AIやIntercom Finのほうが現実的です。自社構築はプロンプト設計と保守に責任を持てる体制があることが前提です。

CSプラットフォームの詳細な機能比較はカスタマーサポートAIプラットフォーム完全比較2026もあわせてご覧ください。

【即効3選】今日から試せるCSプロンプト

まず成功体験を作ることが大切です。難しい設計は後でいい。最初の週はこの3本を試してください。

即効プロンプト#1：問い合わせ内容の一次仕分け

研修先のEC企業で試したところ、オペレーターが一次仕分けに費やしていた時間が1日2時間から20分に縮まりました。まずはこれだけで十分効果を実感できます。

あなたはカスタマーサポートの一次トリアージ担当AIです。
以下のお客様からの問い合わせを分析し、カテゴリと優先度を判定してください。

【問い合わせ内容】
{INQUIRY_TEXT}

【判定ルール】
カテゴリ:
- FAQ: 公開済みFAQで答えられる一般的な質問
- ORDER: 注文・配送・返品に関する問い合わせ
- ACCOUNT: アカウント・ログイン・パスワードに関する問い合わせ
- COMPLAINT: クレーム・不満・感情的な表現を含む
- LEGAL: 法的・コンプライアンス・個人情報に関する内容
- ESCALATE: 上記で判断できない複雑な内容

優先度:
- HIGH: 感情的・緊急性が高い・法的リスクあり
- MEDIUM: 標準的な問い合わせ
- LOW: 情報提供のみ

【出力フォーマット（JSON）】
{
  "category": "カテゴリ名",
  "priority": "HIGH/MEDIUM/LOW",
  "summary": "問い合わせ内容の30字以内の要約",
  "suggested_action": "推奨する次のアクション",
  "escalate_required": true/false
}

不足している情報があれば、最初に質問してから作業を開始してください。

即効プロンプト#2：FAQ自動回答（知識ベース参照型）

このプロンプトは、社内FAQドキュメントをコンテキストに貼り付けて使います。ドキュメントは最大10万トークン（約7万字程度）まで貼れるので、ほとんどの中小企業のFAQはそのまま入ります。

あなたは{会社名}のカスタマーサポートAIです。
以下の社内FAQドキュメントのみを根拠に回答してください。

【社内FAQドキュメント】
{FAQ_DOCUMENT}

【回答ルール】
1. FAQに記載のない内容は「確認の上、改めてご連絡します」と答え、escalate_required: true を設定する
2. 個人情報（氏名・住所・電話番号・メールアドレス・注文番号）は絶対に確認・出力しない
3. 回答は200字以内で、丁寧かつ簡潔に
4. 根拠となるFAQ番号があれば末尾に記載する

【お客様の質問】
{CUSTOMER_QUESTION}

【出力フォーマット】
回答文: ...
参照FAQ番号: ...
escalate_required: true/false

仮定した点は必ず「仮定」と明記してください。

即効プロンプト#3：返信メール下書き生成

オペレーターの返信作成時間を半分以下にする即効ツールです。ある顧問先では、返信下書き生成を導入してから1通あたりの対応時間が平均12分から5分に短縮されました（測定期間：2025年9月〜12月、対象：CS担当者4名）。

あなたは丁寧で共感力の高いカスタマーサポート担当者です。
以下の情報をもとに、お客様への返信メールの下書きを作成してください。

【お客様の問い合わせ内容】
{CUSTOMER_INQUIRY}

【解決策・回答内容】
{RESOLUTION_NOTES}

【返信メールのルール】
- 書き出しはお客様のお名前＋ご不便をおかけした場合はお詫びから
- 解決策を分かりやすく箇条書きで
- 追加質問への窓口を案内して締める
- 文体：丁寧語（ですます調）、感情的な表現はなし
- 文字数：300〜500字

【出力フォーマット】
件名: ...
本文: ...（下書き）

数字と固有名詞は、根拠（出典/計算式）を添えてください。

問い合わせ受付・分類プロンプト10選

一次仕分けから感情分析、優先度付けまで、問い合わせを受け取った瞬間に実行すべきプロンプトをまとめました。

プロンプト#4：感情・緊急度スコアリング

以下の問い合わせテキストを分析し、感情状態と緊急度をスコアリングしてください。

【問い合わせテキスト】
{INQUIRY_TEXT}

【スコアリング基準】
感情スコア（1-5）:
1 = 非常に穏やか　2 = 穏やか　3 = 中立　4 = 不満あり　5 = 強い不満・怒り

緊急度スコア（1-5）:
1 = 急ぎでない　2 = 数日以内　3 = 本日中　4 = 2時間以内　5 = 即時対応

感情スコア4以上または緊急度4以上の場合はフラグを立てる。

【出力（JSON）】
{
  "emotion_score": 数値,
  "urgency_score": 数値,
  "emotion_keywords": ["感情を示す語句"],
  "urgency_keywords": ["緊急性を示す語句"],
  "requires_immediate_attention": true/false,
  "recommended_response_tone": "謝罪優先/情報提供優先/共感優先"
}

プロンプト#5：問い合わせ意図の多段分類

以下の問い合わせを、一次カテゴリと二次カテゴリに分類してください。

【問い合わせテキスト】
{INQUIRY_TEXT}

【分類体系】
一次カテゴリ: 商品・注文・配送・返品交換・アカウント・決済・クレーム・その他
二次カテゴリ: 一次カテゴリをさらに詳細化（例：配送→遅延・紛失・誤配）

【出力（JSON）】
{
  "primary_category": "...",
  "secondary_category": "...",
  "confidence": 0.0〜1.0,
  "alternative_categories": ["可能性のある別カテゴリ"],
  "key_entities": {
    "product_name": "...",
    "order_number": "検出された場合のみ",
    "date_mentioned": "..."
  }
}

信頼度（confidence）が0.6未満の場合は、お客様に追加質問を促す文章も生成してください。

プロンプト#6：マルチチャネル問い合わせの統合サマリー

同一顧客から複数チャネル（メール・チャット・電話）で寄せられた問い合わせ履歴を統合し、現状サマリーを作成してください。

【問い合わせ履歴】
{CONTACT_HISTORY_JSON}

【サマリー出力項目】
1. 課題の本質（50字以内）
2. 顧客の感情推移（最初→現在）
3. 解決済みの事項
4. 未解決の事項
5. 次に取るべきアクション（担当者向け）
6. 対応SLA残時間（もし初回接触日時が含まれる場合）

出力は担当者が1分で状況把握できる形式にしてください。
不足している情報があれば、最初に質問してから作業を開始してください。

プロンプト#7：重複問い合わせ検出と既存チケットのマッチング

新規問い合わせと既存オープンチケットのリストを比較し、重複・関連の可能性を判定してください。

【新規問い合わせ】
{NEW_INQUIRY}

【既存オープンチケット一覧（JSON配列）】
{EXISTING_TICKETS}

【判定基準】
- 同一顧客IDの場合は即時マッチ
- 商品名・注文番号・問い合わせ内容の類似度70%以上で「関連あり」
- 全く別の問い合わせは「新規」と判定

【出力（JSON）】
{
  "is_duplicate": true/false,
  "related_ticket_ids": ["ticket_id1"],
  "match_confidence": 0.0〜1.0,
  "recommendation": "既存チケットに統合/新規チケット作成/要確認"
}

プロンプト#8：問い合わせ言語・翻訳・地域判定

以下の問い合わせの言語を特定し、必要であれば日本語に翻訳してください。

【問い合わせテキスト】
{INQUIRY_TEXT}

【処理内容】
1. 言語を検出（ISO 639-1コード）
2. 日本語以外の場合は日本語に翻訳
3. 地域特有の表現・慣習があれば注記
4. 原文のトーン（フォーマル/カジュアル/感情的）を保持して翻訳

【出力】
検出言語: ...
地域: ...（可能な場合）
日本語翻訳: ...
トーン: ...
翻訳上の注意点: ...（特殊な表現があれば）

プロンプト#9：問い合わせ対応のSLA優先度自動計算

以下の問い合わせ情報を基に、SLA（サービスレベルアグリーメント）の優先度と対応期限を計算してください。

【問い合わせ情報】
顧客ランク: {CUSTOMER_TIER}（例: ゴールド/シルバー/スタンダード）
チャネル: {CHANNEL}（例: メール/チャット/電話）
カテゴリ: {CATEGORY}
感情スコア: {EMOTION_SCORE}
受付日時: {RECEIVED_AT}

【SLAルール（例）】
- ゴールド顧客: 初回返信2時間以内、解決24時間以内
- シルバー顧客: 初回返信4時間以内、解決48時間以内
- スタンダード: 初回返信24時間以内、解決72時間以内
- 感情スコア4以上は1ランク上の対応
- クレームカテゴリは2時間以内に初回返信必須

【出力（JSON）】
{
  "sla_tier": "緊急/高/中/低",
  "first_response_deadline": "YYYY-MM-DD HH:MM",
  "resolution_deadline": "YYYY-MM-DD HH:MM",
  "assigned_team": "推奨担当チーム名",
  "sla_notes": "特記事項"
}

プロンプト#10：VoC（顧客の声）テーマ抽出

過去{期間}の問い合わせデータから、頻出テーマと改善示唆を抽出してください。

【問い合わせデータ（テキスト配列）】
{INQUIRY_DATA_ARRAY}

【分析項目】
1. 頻出テーマ TOP10（件数と割合）
2. 感情スコアが高い（4以上）テーマ
3. 前月比で増加しているテーマ
4. ビジネスへの影響度（推定）
5. 改善のための具体的な提案3つ

出力はCSマネージャーへの月次レポート形式にしてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト#11：問い合わせ対応スクリプト自動生成

以下の問い合わせタイプに対して、オペレーター向けの対応スクリプトを生成してください。

【問い合わせタイプ】
{INQUIRY_TYPE}

【会社情報・ポリシー】
{COMPANY_POLICY}

【スクリプト要件】
- 開始トーク（挨拶・本人確認）
- 問題確認フロー（聴き取り手順）
- 解決策提示テンプレ（3パターン）
- クロージングトーク
- 次回連絡が必要な場合の案内

オペレーターが読み上げるだけで対応できる形式にしてください。

プロンプト#12：問い合わせKPIダッシュボード用データ整形

以下の生の問い合わせログから、KPIダッシュボード用のサマリーデータを生成してください。

【ログデータ（JSON）】
{RAW_LOG_DATA}

【必要なKPI】
- 総件数
- カテゴリ別件数・割合
- 平均初回返信時間（分）
- 平均解決時間（時間）
- AI自動解決率
- エスカレーション率
- 感情スコア分布（1〜5別件数）
- 未解決チケット件数と最長未解決日数

出力はJSON形式で、グラフライブラリ（Chart.js等）に直接渡せる構造にしてください。

プロンプト#13：問い合わせ対応品質スコアリング（QA）

以下のCS対応ログを評価し、品質スコアを算出してください。

【対応ログ】
顧客メッセージ: {CUSTOMER_MESSAGE}
オペレーター（またはAI）の回答: {AGENT_RESPONSE}
解決ステータス: {RESOLUTION_STATUS}
対応時間: {RESPONSE_TIME}

【評価基準（各20点・合計100点）】
1. 正確性：回答内容は事実に基づいているか
2. 共感性：顧客の感情に適切に対応しているか
3. 解決性：問題が解決または適切にエスカレーションされたか
4. 効率性：適切な時間内に対応できたか
5. コンプライアンス：個人情報保護・社内ポリシーを遵守しているか

【出力（JSON）】
{
  "total_score": 数値,
  "breakdown": {"accuracy": 数値, "empathy": 数値, "resolution": 数値, "efficiency": 数値, "compliance": 数値},
  "strengths": ["良かった点"],
  "improvements": ["改善点"],
  "coaching_suggestion": "担当者向けフィードバック"
}

FAQ自動化プロンプト10選

FAQへの自動回答は、Claude Code CSエージェントの主戦場です。ここをしっかり作れば、Tier 1問い合わせの70〜80%を自動化できます。

プロンプト#14：ナレッジベース検索＋回答生成（RAGパターン）

以下のナレッジベース（FAQ・マニュアル・ポリシー文書）から関連情報を検索し、お客様の質問に回答してください。

【ナレッジベース】
{KNOWLEDGE_BASE_CHUNKS}

【お客様の質問】
{CUSTOMER_QUESTION}

【回答生成ルール】
1. ナレッジベースに記載のある情報のみを使用する
2. 根拠となる文書名・章番号を明記する
3. 情報が不十分な場合は「〜については担当者にご確認いただきます」と回答し、escalate_required: true を返す
4. 個人情報・機密情報を含む回答はしない
5. 回答は敬体（ですます調）で200字以内

【出力】
回答文: ...
根拠: [文書名、章番号または見出し]
confidence: 0.0〜1.0
escalate_required: true/false

プロンプト#15：FAQ候補の自動生成（問い合わせデータから）

過去の問い合わせデータを分析し、新しいFAQページに追加すべき質問と回答を生成してください。

【過去問い合わせデータ（上位50件）】
{INQUIRY_DATA}

【既存FAQリスト】
{EXISTING_FAQ}

【生成ルール】
- 既存FAQにない質問のみを対象
- 同じ趣旨の質問はグループ化して1つのFAQに
- 回答は200字以内・箇条書き推奨
- 専門用語にはカッコで説明を追加

【出力形式】
Q: 質問文
A: 回答文
推定問い合わせ件数/月: 数値
優先度: 高/中/低

プロンプト#16：FAQページのメタデータ・SEO最適化

以下のFAQコンテンツを、検索エンジンで上位表示されるようにSEO最適化してください。

【FAQコンテンツ】
{FAQ_CONTENT}

【最適化項目】
1. 検索クエリを意識した質問文のリライト（ユーザーが実際に検索しそうな言葉）
2. metaタイトル・metaディスクリプションの生成
3. FAQ Schema（JSON-LD）の生成
4. 関連FAQ同士のクロスリンク提案

【対象キーワード】
{TARGET_KEYWORDS}

出力はそのままHTMLやJSONに貼り付けられる形式にしてください。

プロンプト#17：AIが答えるべきか人間が答えるべきかの判定

以下の問い合わせについて、AI（自動応答）で対応すべきか、人間（オペレーター）が対応すべきかを判定してください。

【問い合わせ内容】
{INQUIRY_TEXT}

【判定基準】
AIで対応可能:
- 公開FAQで答えられる内容
- 標準的な手続き案内
- 情報の確認・照会

人間が対応すべき:
- 感情スコア4以上のクレーム
- 法的リスクを含む内容
- 個人情報の変更・削除に関する要求
- イレギュラーな例外対応が必要
- 過去に複数回問い合わせているリピートクレーム

【出力（JSON）】
{
  "handler": "AI/HUMAN",
  "reason": "判定理由（30字以内）",
  "ai_draft_answer": "AIで対応可の場合の下書き（対応不可の場合はnull）",
  "human_briefing": "人間担当の場合の引き継ぎメモ（対応可の場合はnull）"
}

プロンプト#18：多言語FAQ自動翻訳・ローカライズ

以下の日本語FAQを、指定言語に翻訳・ローカライズしてください。

【翻訳元FAQ（日本語）】
{FAQ_JAPANESE}

【翻訳先言語】
{TARGET_LANGUAGE}（例: 英語・中国語（簡体）・韓国語）

【ローカライズ要件】
1. 単純翻訳ではなく、当該言語圏の文化・慣習に合わせた表現に
2. 法律・規制の違いがある項目は注記を追加
3. 通貨・単位・日付形式を現地仕様に変換
4. 敬語表現を適切に調整

出力はQ&A形式で、そのまま多言語サポートページに掲載できる形式にしてください。

プロンプト#19：FAQ鮮度チェック・更新提案

既存FAQの内容を最新情報と照合し、更新が必要な項目を特定してください。

【既存FAQリスト（作成日付き）】
{FAQ_WITH_DATES}

【最新の会社情報・ポリシー変更】
{LATEST_UPDATES}

【チェック項目】
1. 古くなった数値・日付（料金・期間・バージョン等）
2. 廃止されたサービス・機能への言及
3. 変更された手続き・フロー
4. 追加すべき新情報

【出力】
更新必要度: 高/中/低
更新すべきFAQ番号と理由:
修正案（各FAQ）:

プロンプト#20：よくある質問への先読み回答（プロアクティブ対応）

顧客の購買・問い合わせ履歴から、次に問い合わせてくる可能性が高い内容を予測し、先読み案内文を生成してください。

【顧客の行動データ】
購入商品: {PRODUCT_INFO}
購入日: {PURCHASE_DATE}
過去問い合わせ履歴: {INQUIRY_HISTORY}

【先読みルール】
- 購入後3日以内：使用開始方法・初期設定FAQ
- 購入後7日以内：返品・交換ポリシー案内
- 購入後30日以内：定期メンテナンス・次回購入インセンティブ

先読みメール/プッシュ通知の文面を生成してください。
過度な営業トーンは避け、「お役立ち情報」として自然な形で届けること。

プロンプト#21：チケット解決後のアフターフォロー文生成

以下のサポートチケットが解決した後、お客様に送る満足度確認メッセージを生成してください。

【解決済みチケット情報】
問い合わせ内容: {INQUIRY_SUMMARY}
解決内容: {RESOLUTION}
対応担当者: {AGENT_NAME}
対応完了日時: {RESOLVED_AT}

【メッセージ要件】
- 解決のお礼と確認
- 追加質問がある場合の窓口案内
- CSATアンケートへの誘導（強制感なく）
- 文字数：150字以内
- トーン：親しみやすく、押しつけがましくない

出力はメール本文とSMSの2パターンで。

プロンプト#22：チャットボット向けウェルカムメッセージ最適化

以下のサービス・顧客層に最適なチャットボットのウェルカムメッセージを生成してください。

【サービス情報】
{SERVICE_INFO}

【主要顧客層】
{TARGET_CUSTOMERS}

【ウェルカムメッセージ要件】
- チャットボットであることを明示（ステルスAI禁止）
- 対応できることと対応できないことを明確に
- 人間担当者への切替方法を案内
- 3択以内のクイックリプライボタンを含む
- 文字数：80字以内

3パターン（フォーマル/カジュアル/親しみやすい）を生成してください。

プロンプト#23：FAQコンテンツの読みやすさ改善

以下のFAQコンテンツを、読みやすく・分かりやすく改善してください。

【改善前FAQコンテンツ】
{FAQ_ORIGINAL}

【改善観点】
1. 一文を短く（40字以内を目安）
2. 専門用語にはカッコ書きで説明を追加
3. 手順は番号付きリストに
4. 重要箇所は太字で強調
5. 読者が「次に何をすべきか」が分かる結びに

改善前と改善後を並べて出力し、改善ポイントを箇条書きで説明してください。

エスカレーション・クレーム対応プロンプト10選

クレーム対応は、AIが完全に自動化すべき領域ではありません。でも、AIが「初期受付・状況整理・引き継ぎメモ作成」を担当することで、オペレーターが本当に必要な対応に集中できます。

事例区分: 想定シナリオ
以下は100社以上の研修・顧問経験をもとに構成した典型的なシナリオです。

ある消費財メーカーの研修でクレーム対応AIのプロトタイプを作ったとき、最初はオペレーターから「AIに任せて大丈夫なの？」という声が多かったんです。でも実際に動かしてみると「怒っているお客様の情報整理をAIがやってくれて、自分は解決策の提案に集中できる」という評価に変わりました。AIとオペレーターの役割分担を明確にするのがポイントです。

プロンプト#24：クレーム受付・初期共感メッセージ生成

以下のクレーム内容に対して、お客様の感情に寄り添った初期対応メッセージを生成してください。

【クレーム内容】
{COMPLAINT_TEXT}

【初期メッセージ要件】
1. お客様の不満・怒りを受け止める共感表現から始める
2. 謝罪は「ご不便をおかけし」レベルに留める（事実認定・責任確定は後工程）
3. 担当者が確認の上、{対応時間}以内に折り返す旨を伝える
4. AIが対応していることを明示する
5. 文字数：100字以内

絶対に含めてはいけない表現:
- 「おっしゃる通りです」（事実未確認での同意）
- 「弊社のミスです」（責任確定表現）
- 「特別に対応します」（例外対応の確約）

仮定した点は必ず「仮定」と明記してください。

プロンプト#25：クレーム内容の事実整理と法的リスク評価

以下のクレーム内容を分析し、事実関係の整理と法的リスクを評価してください。

【クレーム全文】
{COMPLAINT_FULL_TEXT}

【分析項目】
1. 主張されている事実（お客様側の言い分）
2. 確認が必要な事実（社内で調査が必要な事項）
3. 関連する法的リスク（消費者保護法・製造物責任法・個人情報保護法等）
4. 推奨対応レベル:
   - STANDARD: 標準CS対応
   - ESCALATE_MANAGER: CSマネージャーへのエスカレーション
   - ESCALATE_LEGAL: 法務部門への相談が必要
5. 初回返信までにすべき内部確認事項

このプロンプトの出力は外部に送信せず、内部資料として扱ってください。
不足している情報があれば、最初に質問してから作業を開始してください。

プロンプト#26：エスカレーション引き継ぎメモ自動生成

以下の対応履歴から、上位担当者（CSマネージャー）への引き継ぎメモを自動生成してください。

【対応履歴（時系列）】
{INTERACTION_HISTORY}

【引き継ぎメモ構成】
1. 課題の一行サマリー
2. 顧客プロフィール（購買履歴・過去問い合わせ件数・顧客ランク）
3. これまでの対応内容と結果
4. 顧客の現在の感情状態（スコア付き）
5. 未解決事項と検討すべき解決策（3案）
6. 推奨するエスカレーション理由
7. 次の担当者が最初に言うべき一言

マネージャーが3分で状況把握できる形式にしてください。

プロンプト#27：クレーム解決策の選択肢生成

以下のクレームに対して、実現可能な解決策を複数生成し、コスト・顧客満足度・リスクを評価してください。

【クレーム概要】
{COMPLAINT_SUMMARY}

【自社ポリシーと制約】
{COMPANY_POLICY_CONSTRAINTS}

【解決策評価】
各解決策について以下を評価:
- 内容: 具体的な対応内容
- コスト: 金額または工数の概算
- 顧客満足度予測: 1〜5（高いほど満足）
- リスク: 設定できる前例・他顧客への影響
- 実施可能性: 即日/数日以内/要調整

最低3案、最大5案を提示し、推奨案を1つ指定してください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト#28：SNS炎上リスク評価と対応文生成

以下の問い合わせ・クレーム内容について、SNS炎上リスクを評価し、対応方針を提案してください。

【クレーム内容】
{COMPLAINT_TEXT}

【炎上リスク評価基準】
- HIGH: 拡散性が高い内容（差別・安全・製品欠陥・個人情報漏洩）
- MEDIUM: 顧客体験の不満（対応の遅さ・品質問題）
- LOW: 個人的な好みの問題・誤解に基づくクレーム

【対応方針出力】
炎上リスク: HIGH/MEDIUM/LOW
理由:
推奨初期対応（24時間以内）:
社外向けパブリックコメント案（必要な場合）:
社内に知らせるべきか: YES/NO（理由）

このプロンプトの出力は経営層・広報と共有してください。

プロンプト#29：クレーム対応品質の自動フィードバック

以下のクレーム対応を評価し、担当者へのコーチングフィードバックを生成してください。

【対応テキスト（担当者のメッセージ）】
{AGENT_RESPONSE}

【クレーム内容（顧客側）】
{CUSTOMER_COMPLAINT}

【評価観点】
1. 共感表現の適切さ（感情を受け止めたか）
2. 事実確認の徹底度（憶測で謝罪していないか）
3. 解決策の具体性（次のアクションが明確か）
4. 言葉遣い・トーン（敬語・感情的な言葉の有無）
5. リスク管理（不適切な確約・差別的表現がないか）

フィードバックは「褒める点→改善点→具体的な代替表現」の順で、担当者が受け入れやすい形にしてください。

プロンプト#30：クレームパターン分析と再発防止策立案

過去{期間}のクレームデータを分析し、根本原因と再発防止策を立案してください。

【クレームデータ（カテゴリ別件数・内容サマリー）】
{COMPLAINT_DATA}

【分析フレームワーク】
1. 5Why分析: 各上位クレームの根本原因を5段階で掘り下げ
2. 影響度×発生頻度マトリクスで優先度付け
3. 短期対策（1週間以内）・中期対策（1ヶ月以内）・長期対策（3ヶ月以内）に分類
4. 対策のKPI（測定指標と目標値）を設定

出力は経営会議の資料として使える形式にしてください。
数字と固有名詞は、根拠（出典/計算式）を添えてください。

プロンプト#31：電話クレームのリアルタイムサポート（コパイロット）

電話対応中のオペレーターをリアルタイムでサポートします。お客様の発言を入力すると、次に言うべき言葉の候補を即座に提示します。

【お客様の発言（文字起こし）】
{CUSTOMER_SPEECH_TRANSCRIPT}

【コンテキスト】
問い合わせカテゴリ: {CATEGORY}
顧客ランク: {CUSTOMER_TIER}
対応フェーズ: 初期受付/事実確認/解決策提示/クロージング

【リアルタイム提案】
次の一言（2〜3案）:
1. ...
2. ...
3. ...
避けるべき表現: ...
現在の感情状態: ...
推奨するフェーズ移行タイミング: ...

※出力は5秒以内に表示されることを前提とした短文形式にしてください。

プロンプト#32：謝罪文・お詫び状の自動生成

以下の状況に対する正式なお詫び文書を生成してください。

【事案概要】
{INCIDENT_SUMMARY}

【発生した問題】
{PROBLEM_DESCRIPTION}

【確認された事実】
{CONFIRMED_FACTS}

【対応済み事項】
{RESOLVED_ACTIONS}

【お詫び文書の要件】
- 事実に基づいた謝罪（確認できていない事項は謝罪しない）
- 再発防止策の明記
- 補償・対応策の記載（決定済みのもののみ）
- 今後の問い合わせ窓口の案内
- 文体：書面形式（拝啓・敬具）
- 分量：400〜600字

法的に問題のある表現（全面的な過失認定・無制限の補償約束）は含めないでください。

プロンプト#33：クレーム対応後の再発可能性スコアリング

クレームを解決した後、同一顧客からの再クレーム可能性を評価してください。

【解決済みクレーム情報】
クレーム内容: {COMPLAINT_SUMMARY}
解決策: {RESOLUTION}
顧客の最終感情: {FINAL_SENTIMENT}
対応品質スコア: {QA_SCORE}
過去クレーム件数: {PAST_COMPLAINT_COUNT}

【再発リスク評価】
リスクスコア: 1〜10（10が最高リスク）
リスク要因:
推奨フォローアップ:
- 短期（3日以内）: ...
- 中期（2週間以内）: ...
チャーンリスク: 低/中/高
推奨引き止め施策: ...

【要注意】CSエージェント構築の失敗パターン4選

失敗1：全ての問い合わせをAIに答えさせようとする

❌ 「AIがあるんだから、全部自動で答えてくれるでしょ」
⭕ Tier 1（FAQ）だけをAI対応に絞り、Tier 2・3は必ず人間に渡す設計にする

なぜ重要か：Claude CodeのAPIはテキスト生成の精度は高いですが、「本当に正しい情報か」の事実確認は自分ではできません。誤った回答をお客様に届けてしまうリスクが常にあります。研修先で全自動にしたところ、商品の誤った仕様情報を回答し続けてしまった事例がありました。Tier分けと人間によるサンプリングチェックは必須です。

失敗2：システムプロンプトにポリシーを詰め込みすぎる

❌ 5,000字を超えるシステムプロンプトに全ての業務ルールを書く
⭕ システムプロンプトは骨格のみ（500字程度）、詳細な業務ルールはナレッジベースとして別途検索させる（RAGパターン）

なぜ重要か：長すぎるシステムプロンプトは、モデルが中盤以降の指示を参照しにくくなる傾向があります。また、ポリシーが変わるたびにシステムプロンプトを書き直す運用になるので、メンテナンスコストが跳ね上がります。

失敗3：個人情報をプロンプトに直接含めてしまう

❌ 「お客様の名前は田中様、注文番号は〇〇、住所は〇〇です。以下に回答してください」
⭕ 個人情報はマスキングしたうえでAPIを呼び、回答生成後に必要な情報を差し込む処理を挟む

なぜ重要か：APIログやデバッグ情報に個人情報が残るリスクがあります。個人情報保護法の安全管理措置（第23条）の観点から、個人情報をLLMのプロンプトに直接含める設計は最小限にする必要があります。次のセクションで詳しく解説します。

失敗4：エスカレーション条件を曖昧にしたまま運用する

❌ 「困ったら人間に渡せばいい」という設計
⭕ エスカレーション条件を具体的なルールとして定義し、プロンプトに明記する

なぜ重要か：曖昧なエスカレーション条件では、AIが無限ループで回答を試み続けたり、逆に些細な質問でも人間に回してしまったりします。「感情スコア4以上」「信頼度0.6未満」「法的キーワード検出時」など、定量的な閾値を設定することが重要です。

ガバナンス：個人情報保護法・記録管理への対応

CSエージェントを本番運用するうえで、最も重要なのがガバナンス設計です。特に日本では2022年の個人情報保護法改正以降、AIを使った個人情報処理に対する要件が厳しくなっています。

個人情報保護法対応の4原則

1. 利用目的の明示：チャットボット起動時に「AIが対応していること」と「入力情報の利用目的」を必ず表示する。ステルスAIは景品表示法・個人情報保護法の両面でリスクがあります。
2. 個人情報のマスキング：氏名・住所・電話番号・注文番号等は、APIを呼び出す前にサーバーサイドでマスキング処理を施す。プロンプトには「{顧客ID}」等のトークンのみを渡す。
3. データ保存期間の設定：会話ログの保存期間をポリシーとして明記し、期間超過後は自動削除する仕組みを組み込む。
4. 第三者提供の記録：AnthropicのAPIを利用することは「第三者提供」に該当する可能性があります。プライバシーポリシーにAPIサービスの利用を明記し、オプトアウト手段を提供することが望ましいです。

記録管理の基本設計

【会話ログの推奨保存構造】
{
  "session_id": "UUID（個人情報を含まない識別子）",
  "timestamp": "ISO8601形式",
  "channel": "chat/email/phone",
  "tier": "1/2/3",
  "category": "FAQ/ORDER/COMPLAINT等",
  "emotion_score": 数値,
  "escalated": true/false,
  "resolution_status": "resolved/pending/escalated",
  "agent_type": "AI/human",
  "qa_score": 数値（QAサンプリング時）
}
※会話の全文テキストは別テーブルに暗号化して保存
※個人情報（氏名・連絡先）はさらに別テーブルで管理

既存ツール連携：Zendesk・Slack・Notion

Claude Code CSエージェントの価値は、既存ツールとの連携で最大化されます。MCPを使うと、外部サービスへの認証やAPIコールを標準化できます。

音声AIエージェントとの連携については、音声AIエージェント完全比較2026もあわせてご覧ください。

Zendesk連携のアーキテクチャ

【Zendesk + Claude Code 連携フロー】

1. Zendesk Webhook → Claude API（問い合わせ受信）
2. Claudeが分類・優先度付け・初期回答生成
3. Claude → Zendesk API（チケット更新・タグ付け・内部メモ追記）
4. 人間対応が必要な場合: Claudeがチケットに引き継ぎメモを添付してエスカレーション
5. 解決後: Claudeが対応ログを分析してVoCレポートを週次生成

【実装ポイント】
- Zendeskのトリガー機能で「新規チケット」をWebhookに設定
- Claude APIのtools機能でZendesk REST APIを呼び出す
- レート制限対策として非同期キューを挟む（Celery/BullMQ等）

Slack連携：社内CSチームへのリアルタイム通知

【Slack通知の条件設計（推奨）】
- 感情スコア4以上のクレーム受信 → #cs-urgent チャンネルに即時通知
- 3回以上エスカレーションした案件 → #cs-manager チャンネルに通知
- 日次サマリー（件数・解決率・未解決チケット数） → #cs-daily に毎朝8時
- VoCレポート（週次） → #cs-voc に毎週月曜

【Slack通知のプロンプトテンプレ】
Slackに送信するメッセージを生成してください。
- 上限300字
- 感情的な内容は事実のみを記載（顧客名は省略）
- 対応が必要な場合は「@on-call」をメンション
- ブロックキット形式で、対応ボタン（対応中/エスカレーション/解決済み）を含める

Notion連携：ナレッジベースの自動更新

【FAQ自動更新フロー（Notion + Claude Code）】
1. 月次で解決済みチケットを分析（プロンプト#15）
2. Claudeが新規FAQ候補を生成
3. 担当者がNotionのFAQデータベースをレビュー・承認
4. 承認済みFAQをClaudeのナレッジベースに自動追加
5. 翌日からAIが新しいFAQを参照して回答

【Notion APIとの連携コード骨格（Python）】
import anthropic
import requests

# 1. Notionから既存FAQを取得
notion_db = requests.get(
    f"https://api.notion.com/v1/databases/{DB_ID}/query",
    headers={"Authorization": f"Bearer {NOTION_TOKEN}",
             "Notion-Version": "2022-06-28"}
).json()

# 2. FAQをClaudeのナレッジベース形式に変換
faq_text = "\n".join([
    f"Q: {page['properties']['Question']['title'][0]['text']['content']}\n"
    f"A: {page['properties']['Answer']['rich_text'][0]['text']['content']}"
    for page in notion_db['results']
])

# 3. Claude APIを呼び出してFAQ回答を生成
client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    system=f"あなたはCSエージェントです。以下のFAQを参照して回答してください。\n\n{faq_text}",
    messages=[{"role": "user", "content": customer_question}]
)

Claude Codeの機能詳細についてはClaude Code機能完全ガイド2026もご参照ください。

ROI試算：自社構築のコストと効果

自社構築を検討する際に必ず聞かれるのが「いくらかかるの？」です。ここでは典型的なケースを想定シナリオとして試算します。

事例区分: 想定シナリオ
以下は月間問い合わせ500件規模の中堅ECサイト（従業員50名）を想定した試算です。実際のコストは業務複雑度・開発リソースによって大きく異なります。

月次削減額が2〜5万円のAPI費用を上回るケースが多く、初期費用回収は半年〜1年が目安です。ただし、運用・メンテナンス工数（プロンプト改善・ナレッジ更新）を別途計上することが重要です。

Claude Code CSエージェント構築ロードマップ

「何から始めればいいか分からない」という方向けに、4週間のロードマップを示します。

Week 1：Tier 1 FAQの自動応答プロトタイプ

• 既存FAQドキュメントをテキスト形式に整理
• プロンプト#14（RAGパターン）でFAQ回答を生成できるか検証
• 10〜20件の実際の問い合わせで精度を確認
• CS担当者と「これで答えてよい/ダメ」の判断基準を合わせる

Week 2：問い合わせ分類・優先度付けの実装

• プロンプト#4・#5・#6を組み合わせた一次仕分けシステムを構築
• 既存チケット管理ツール（Zendesk等）とのWebhook連携を実装
• エスカレーション条件を定量的なルールとして定義

Week 3：クレーム対応プロセスの組み込み

• プロンプト#24〜#26（初期受付・事実整理・引き継ぎメモ）の実装
• 感情スコア閾値・エスカレーション条件の調整
• Slack通知連携の構築

Week 4：ガバナンス・KPI計測の整備と本番リリース

• 個人情報マスキング処理の実装と確認
• 会話ログの保存・暗号化・削除ポリシーの設定
• KPIダッシュボード（プロンプト#12）の構築
• QAサンプリングチェックフローの確立
• 本番リリース・モニタリング開始

自動化プロンプトのさらなる活用については、Claude Code自動化プロンプト30選もあわせてご覧ください。

まとめ：CSエージェント構築で今日から始める3つのアクション

1. 今日やること：プロンプト#1（問い合わせ一次仕分け）をAnthropicのPlayground（console.anthropic.com）で試す。実際の問い合わせ5件を貼り付けて分類精度を確認してください。
2. 今週中：自社の問い合わせをTier 1〜3に分類し、Tier 1（AI対応OK）の件数・割合を把握する。そこが自動化できる最大の効果領域です。
3. 今月中：Week 1のロードマップに沿って、FAQプロトタイプを作成してCS担当者に試してもらう。現場のフィードバックが最高の改善ヒントになります。

正直に言うと、Claude Code×CSエージェントは「導入したら終わり」ではありません。プロンプトの継続的な改善、ナレッジベースの更新、QAサンプリングの運用が必要です。でも、その分だけ「自社の業務にフィットした」エージェントに育てていける。SaaSに業務を合わせるのではなく、業務に合わせてエージェントを作れる。それが自社構築の最大のメリットです。

あわせて読みたい：

• カスタマーサポートAIプラットフォーム完全比較2026 — Decagon・Intercom・Zendesk AIの詳細比較
• Claude Code自動化プロンプト30選 — CS以外の業務自動化にも応用できるプロンプト集

参考・出典

• 自動対話システム市場の現状と展望 2025年版 — コールセンタージャパン・ドットコム（参照日：2026-05-11）
• Customer support agent — Claude API Docs — Anthropic（参照日：2026-05-11）
• Decagon | The AI concierge for every customer — Decagon（参照日：2026-05-11）
• Intercomエージェント（Fin）2025年完全ガイド — eesel AI（参照日：2026-05-11）
• AI for customer service — Zendesk — Zendesk（参照日：2026-05-11）
• AI Customer Service Agents For Quality CX At Scale | Ada — Ada CX（参照日：2026-05-11）
• Decagon Pricing: How Much Does Decagon Cost in 2026? — Quiq（参照日：2026-05-11）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。