【2026年最新】コールセンター応対メモ自動化×Claude Code

はじめに:深夜2時、SV席で「あと47件の応対メモ」を眺めていた話

「正直、コールセンターの一番のボトルネックって、通話そのものじゃなくて通話のあとなんですよ」

この記事の対談相手、田所さん(仮名・元コンタクトセンターSV、現在は某SaaS企業のCXマネージャ)とランチで話したときに、開口一番こう言われました。私はそのとき、自社のCS部門でEC事業者向けの問い合わせ自動化案件を進めていて、コールセンター領域は未経験。「通話を文字起こしして要約すれば終わりじゃないんですか?」と聞いた私に、田所さんはコーヒーを置いて、こうつぶやいたんです。

「終わらないんですよ。要約を書く時間より、その要約をCRMのどのフィールドに入れるかで悩む時間のほうが長い。FAQに既に答えがあるのに、新人が見つけられなくて先輩に聞く時間も長い。SVがその全部を眺めて『今日は何が問題だったのか』を見つける時間も長い。全部、通話のあとです」

私は元々、Anthropic公式のClaude Codeを業務システム連携に使ってきましたが、コールセンター領域への適用は手探りでした。そこで、田所さんに「対談形式で、実際にやってる/やりたいことを全部聞かせてください」とお願いして、3時間半の音声を回したのがこの記事の出発点です。

※本記事に登場する応対率・削減率・FAQヒット率の数字は、田所さんが過去に運用していたセンターの公開可能な水準と、私が別案件でホテルのレビュー返信業務や自治体の問い合わせ振り分けでClaude Code導入した際の想定例を組み合わせたものです。実際の効果は環境・チーム規模・既存CRM構成に大きく依存します。

Q1.そもそも、コールセンターの「あと処理」って何にそんなに時間がかかってるんですか?

佐藤(筆者):田所さん、まず素朴な疑問なんですけど、通話自体が5分で終わったとして、そのあと処理に何分くらいかかるものなんですか?

田所さん:これね、業種で全然違うんですけど、私が見てきた金融系インバウンドだと、通話5分に対してあと処理7〜10分っていうのがザラでした。生命保険のクレーム系だと15分超えることもあった。

佐藤:あと処理7〜10分の内訳って、具体的にはどういう作業ですか?

田所さん:分解するとこんな感じです。

• 応対メモを書く(2〜3分):お客様の用件・解決状況・次回フォロー要否を文章で要約してCRMに入力
• 対応履歴のカテゴリタグ付け(1分):大分類/中分類/小分類の3階層タグを選ぶ。これが意外に悩む
• 関連書類・契約情報の確認漏れチェック(1〜2分):通話中に確認した内容と一致しているか
• FAQに該当があったか・なければ起票するかの判断(1〜2分):同じ問い合わせが3回続いたらFAQ起票するルールが多い
• SVへのエスカレ要否判定とSlack/Teams通知(1〜2分):クレーム性が高い案件のみ

佐藤:これ、ほぼ全部「通話の音声/文字起こしを起点に、構造化された情報を作る」作業ですよね。Claude Codeの得意領域そのもの。

田所さん:そうなんですよ。だから私、Claude Codeの話を最初に聞いたとき「これコールセンターのためにあるんじゃないか」って一瞬思った。でも実際に導入の話を進めると、もっと泥臭い問題が山ほど出てきて……。

Q2.最初のハードル:録音データを「外部APIに送る/送らない」問題

佐藤:「泥臭い問題」、これ聞きたかったやつです。Claude Codeで実装、と言っても録音音声を直接Anthropic APIに投げるわけにはいかないケースが多いですよね。

田所さん:金融・医療・自治体系はほぼNGです。お客様の声紋・氏名・契約番号・口座番号・通話中の生年月日が全部入った音声を、コンプラ部門が「クラウドAPIに直送します」と聞いたら一瞬で止まる。

佐藤:うちでも、自治体の問い合わせ振り分け案件では「録音データそのものはVPC内のオンプレ文字起こしエンジンで処理し、テキスト化されたあとの匿名化済みデータだけをClaude API経由でClaude Codeに渡す」っていう設計にしました。

田所さん:そのパターンが現実解だと思います。具体的にはこういうアーキテクチャでしたよね?

1. CTI(電話交換機)が通話録音を社内ストレージに保存
2. オンプレ文字起こしエンジン(Whisperローカル版や国産STT)が音声→テキスト変換
3. マスキング処理:氏名・電話番号・口座番号・生年月日を「[MASK_NAME]」「[MASK_ACCOUNT]」等に正規表現+辞書で置換
4. マスキング済みテキストをClaude API経由でClaude Codeに渡し、要約・分類・FAQマッチング
5. 結果をCRMに書き戻し

佐藤:ここで重要なのは、個人情報保護法・改正電気通信事業法・業界別ガイドライン(金融FISC・医療3省2ガイドラインなど)で「クラウド送信前に何をマスキングすべきか」を確認することです。Claude Codeに「マスキングのコードを書いて」と頼むのは簡単ですが、何をマスキングすべきかの判断は法務・コンプラ部門に必ず確認してください。

田所さん:あと、忘れちゃいけないのが「お客様への録音・AI活用の事前告知」です。アナウンスフレーズも、コンプラ部門のレビューが要ります。

Q3.「録音→要約→CRM登録」の最小実装、どうやって作りましたか?

佐藤:では本題。マスキング済みテキストが手元にある前提で、Claude Codeで「要約してCRMに登録するまで」をどう作ったか聞かせてください。

田所さん:私が最初に作ったのは、Markdownファイル1個から始まる最小実装でした。社内のオンプレSTTが吐いた文字起こしを、決まったフォルダにポンと置く。それをClaude Codeが見て、要約とタグ付けをして、CRMのAPIに投げる。これだけ。

佐藤:「Markdown 1個から始める」ってClaude Code文化そのものですね。具体的にはどんなディレクトリ構成?

callcenter-summarizer/
├── CLAUDE.md          # Claude Codeへの指示書
├── transcripts/       # STT出力のマスキング済みテキスト(.txt)
│   ├── 20260527_0930_call0142.txt
│   └── 20260527_0935_call0143.txt
├── output/            # 要約結果のJSON
├── faq/               # FAQマスター(.md)
├── prompts/           # 用途別プロンプト(.md)
└── scripts/
    ├── ingest.py      # CRMへPOSTするスクリプト
    └── dashboard.py   # SV向け日次集計

田所さん:このCLAUDE.mdに「マスキング済みテキストを読んで、以下のスキーマで構造化JSONを出して」って書いておく。Claude Codeに `claude` って打って起動した後、「transcripts/にある未処理ファイルを全部要約してoutput/に出して」って自然言語で指示するだけで、ループが回ります。

佐藤:大事なのは、「いきなりCRM本番に書き込まない」こと。最初はoutput/にJSONを吐くだけ。SVが目視で30件くらい確認して「これなら使える」となってから、ingest.py経由でCRM API書き込みを有効化する。

田所さん:あと、Claude Codeに直接 `–dangerously-skip-permissions` を渡すのは、CRM書き込みフェーズに進むまでは絶対やめたほうがいいです。最初は1ファイルずつ承認しながら回す。慣れてから自動承認。

Q4.要約プロンプト、具体的にはどう書きました?(コピペ可能プロンプト1)

佐藤:では実物を出しましょう。これ、田所さんと一緒に何十回も書き直したやつです。

あなたはコールセンターのベテランオペレータ兼SVです。
以下のマスキング済み通話文字起こしを読み、JSON形式で構造化サマリを返してください。

【スキーマ】
{
  "call_id": "ファイル名から抽出",
  "duration_min": "推定通話時間(整数・分)",
  "category_l1": "大分類(下記から1つ)",
  "category_l2": "中分類(自由記述・15字以内)",
  "summary_one_line": "1行サマリ(全角40字以内)",
  "summary_detail": "詳細サマリ(全角150〜200字、客観的事実のみ)",
  "customer_emotion": "calm/concerned/upset/angry のいずれか",
  "next_action": "follow_up_needed/resolved/escalate_to_sv のいずれか",
  "faq_match_candidate": "該当しそうなFAQ ID(複数可、なければnull)",
  "compliance_flags": ["契約解除言及","返金要求","SNS言及","録音同意問題"のうち該当するもの]
}

【大分類リスト】
- 商品問い合わせ
- 契約変更
- 解約相談
- 不具合・クレーム
- 請求関連
- 操作サポート
- その他

【ルール】
- 「お客様」「ご担当者」など人物の固有名詞が[MASK_xxx]で潰れている場合は推測しない
- 推測で書いたフィールドには値の末尾に「(推定)」を付けてはならない。スキーマ通りの値のみ返す
- compliance_flagsはマッチがなければ空配列[]
- customer_emotionは音声トーンではなく「文字起こし上の発話内容」のみから判定すること

【入力】
<transcript>
{ここにマスキング済みテキストを貼る}
</transcript>

田所さん:このプロンプトのキモは、「推測で書くな」と明示することと、customer_emotionを音声トーンじゃなくテキストから判定させているところ。音声トーンを判定させると、文字起こし精度の影響で誤判定が増えるんですよね。

佐藤:もうひとつ、compliance_flagsを入れたのが地味に効きました。「契約解除言及」「返金要求」「SNS言及」のフラグが立った案件は、SV側のダッシュボードで自動的に赤色表示にして、優先レビュー対象にしている。

Q5.FAQヒット率を上げる、ってどういうことですか?

佐藤:次のテーマです。FAQヒット率の向上って、田所さんが特に力を入れたところだと聞いてます。

田所さん:これね、コールセンターで「同じ質問が3回続いたらFAQ起票」ってルールがある現場、多いんですよ。でも実態は「3回続いた」ことを誰も気づかない。なぜなら、3人の別のオペレータが3日にわたって受けてるから、お互いの履歴を見ない。

佐藤:つまりFAQヒット率を上げるには、まず「同じ問い合わせが何回来てるか」を可視化する必要がある。

田所さん:そうです。私たちのアプローチはこうでした。

1. 過去30日分の構造化サマリJSONを全部Claude Codeに読ませる
2. 「summary_one_line と category_l2 から、意味的に類似した問い合わせをクラスタリングして」と指示
3. クラスタごとに「件数」「既存FAQでカバーできているか」「カバーできていなければFAQ起票案」を出力

佐藤:これ、本来はClaude Codeのサブエージェント機能や、社内のベクトル検索DBと組み合わせるとさらに精度が上がります。でも最初の1ヶ月は「全件を1ファイルにまとめてClaudeに食わせる」だけで十分機能した、と。

田所さん:はい、想定例ですが、これで「実は1ヶ月で47件来てた特定機能の操作質問」がFAQ化されて、その後の新規問い合わせのFAQヒット率が体感で大きく上がりました。具体的な数字は環境依存ですが、「同じ質問が47回来てたことに気づけた」こと自体が一番の価値でした。

Q6.FAQ起票プロンプト、見せてもらえますか?(コピペ可能プロンプト2)

あなたはFAQライターです。
以下は過去30日分のコールセンター応対サマリ(JSON配列)です。

【タスク】
1. summary_one_line と category_l2 を見て、意味的に類似した問い合わせをクラスタリングしてください
2. 件数が10件以上のクラスタを「FAQ起票候補」として抽出
3. 各候補に対して、以下のフォーマットでFAQ案を生成

【出力フォーマット(Markdown)】
## FAQ起票候補

### #1 [タイトル(40字以内)]
- 件数: XX件
- 既存FAQでのカバー: ID-XXX(あれば)/なし
- 想定読者: 例「初めて契約した個人ユーザー」
- 質問(Q):
  > お客様が実際に使う言葉で1〜2文
- 回答(A):
  > 250〜350字。手順がある場合は箇条書き
- 関連リンク先候補:
  - 既存FAQへの内部リンク
  - 取扱説明書の該当ページ番号
- 注意: FAQ起票後はFAQマスター(faq/master.md)にも追加すること

【ルール】
- Q/Aの中に[MASK_XXX]が残っていたら除外
- compliance_flagsに「契約解除言及」「返金要求」が含まれる案件のクラスタは、FAQ化せずSVレビュー対象として別途出力
- 件数10件未満のクラスタは「経過観察リスト」として件数だけ出す

【入力】
<summaries>
{output/配下のJSONを全部結合してここに}
</summaries>

田所さん:このプロンプト、最後の「件数10件未満は経過観察リスト」が地味に重要です。これがないと「5件しか来てない問い合わせ」までFAQ化してしまって、ホテルのレビュー返信運用で問題になった「FAQが肥大化して逆に検索できない」現象が起きる。

佐藤:ちなみに、ここで生成されたFAQ案は必ずSVが目視レビューしてから本番公開してください。Claude Codeが書いた文面そのままを公開して、顧客対応の表に出すのはNG。最終的な顧客対応判断はオペレータとSVが担う、というのは何度でも繰り返したいポイントです。

Q7.対応品質モニタリング、これは難しそうですが…

佐藤:応対品質スコアリング、いわゆる「QAチェック」をAIで自動化したい、っていう要望は田所さんのところでもありました?

田所さん:めちゃくちゃありました。でも、これは慎重派です。「人事評価に直結する数字をAIに出させる」のは、私は反対の立場。

佐藤:その理由は?

田所さん:3つあります。1つめ、文字起こし精度の問題。STTが「申し訳ございません」を「申し上げません」と誤認識した場合、AIは「謝罪不足」と判定する。2つめ、文脈解釈の問題。お客様がジョークで「殺すぞ」と言った場合と、本気で言った場合をAIは見分けられない。3つめ、これが一番大事ですが、評価される側のオペレータが納得しない。

佐藤:でも品質モニタリング自体は必要ですよね。落とし所はどこに?

田所さん:「AIは『SVが目を通すべき案件を抽出する』までしかやらせない」という運用にしました。具体的には、以下の3つのフラグが立った案件だけSV席のレビュー対象にする。

• customer_emotionが「upset/angry」
• compliance_flagsに「契約解除言及」「返金要求」「SNS言及」のいずれかが立つ
• 通話時間が平均の2倍以上

佐藤:これ、「AIが評価する」じゃなくて「AIが優先順位を付ける」っていう発想の転換ですね。SVは1日100件の通話を全部聴く時間はないけど、AIがフラグ立てた20件なら聴ける。

Q8.SV向けダッシュボード、何を表示しましたか?(コピペ可能プロンプト3)

佐藤:SVが朝イチで見るダッシュボード、Claude Codeで作りましたよね。あれの仕様を教えてください。

田所さん:はい、これも泥臭くて、最初はMarkdownで日次レポートを吐くだけでした。HTML/Reactのダッシュボードを最初から作ろうとして時間溶かす、っていうのを散々経験したので、もう「Markdownで十分」と割り切った。

あなたはコンタクトセンターのSV補佐です。
以下は本日0:00〜23:59のコールセンター応対サマリ(JSON配列)です。
SVが朝礼で5分で読める日次レポートをMarkdownで生成してください。

【出力フォーマット】
# 日次サマリ(YYYY-MM-DD)

## 1. 件数サマリ
- 総応対件数: XX件
- 大分類別件数:
  - 商品問い合わせ: XX件
  - クレーム: XX件
  - ...

## 2. 今日のハイライト
- 急増カテゴリ(前7日平均比+30%以上のカテゴリを最大3つ)
- 通話時間が平均の2倍以上だった案件(call_id一覧、最大5件)

## 3. 要レビュー案件(SVが必ず目を通すべき)
- compliance_flagsが立った案件
- customer_emotion=upset/angryの案件
※case_idと1行サマリのみ。詳細はCRMで確認

## 4. FAQヒット候補
- 本日3件以上同類の問い合わせがあったクラスタ(タイトルのみ)

## 5. オペレータ別件数(個人評価ではなく、業務量配分の参考)
- 件数の多い順上位5名と少ない順下位5名
※個別の品質評価コメントは絶対に書かない

【ルール】
- 個人の品質を点数化しない
- 「○○さんの応対が悪い」等の主観的評価は書かない
- 件数の偏りは「業務量の偏り」として表現する

【入力】
<daily_summaries>
{当日output/配下のJSONをすべて結合}
</daily_summaries>

田所さん:このプロンプトのキモは最後の「ルール」です。AIに人事評価コメントを書かせないように、明示的に禁止している。これがないと、ある日突然「○○さんの応対品質が低下傾向」とか書いてくることがあって、超危ない。

佐藤:このMarkdown日次レポート、本当に5分で読めるので、SVが朝礼前に印刷して全員に配ってる現場もあると聞きました。

Q9.新人オペレータ向けロールプレイ、これはどうやって?(コピペ可能プロンプト4)

佐藤:もう1つの目玉、新人向けロールプレイ自動生成。これ田所さんの一番のお気に入りでしたよね?

田所さん:はい、これは本当に効きました。新人研修の最大のボトルネックって「ベテランオペレータをロールプレイ相手として拘束する」ことなんですよ。1人の新人を育てるのに、ベテランが3〜5時間取られる。これがClaude Codeで「Claudeがお客様役」になってくれる。

あなたはロールプレイ訓練の「お客様役」を演じるシミュレータです。
新人オペレータの応対練習相手になってください。

【設定】
- あなたが演じる顧客タイプ: {input: 例「契約3年目・解約を検討している・少し不満気味」}
- 用件: {input: 例「月額料金が高くなったので解約したい」}
- 性格設定: {input: 例「丁寧だが頑固。納得しないと引かない」}
- 隠し情報: あなたは実は「料金プラン変更で解約せず継続」を一番望んでいる。ただし新人がそれを引き出せるかをテストする
- 終了条件: 新人が(1)解約理由を3つ以上ヒアリングできた、(2)代替プランの提示まで到達した、(3)10分以上経過した、のいずれかで終了

【あなたの応対ルール】
- 最初の発話は「もしもし、契約してる[製品名]のことで…」のように曖昧に始める
- 新人が共感を示したら少しずつ情報を出す
- 新人がいきなり解約手続きを進めようとしたら「ちょっと待ってください、まだ決めたわけじゃ…」と引き止める
- 新人が無言で15秒経ったら「もしもし、聞こえてますか?」と促す
- ロールプレイ中に絶対やってはいけないこと:
  - 実在しそうな個人情報(氏名・住所・電話番号)を口にする
  - 暴言・誹謗中傷
  - 性的・差別的な発話

【終了後の出力】
ロールプレイが終了したら、以下のフィードバックを新人に返してください。
1. 良かった点(3つ・具体的に)
2. 改善ポイント(3つ・具体的に・「次回はこうしてみよう」の提案つき)
3. 模範的な切り返し例(2つ・実際にお客様役が言った発話に対する応答例)
4. このロールプレイで使えたであろう既存FAQ ID

【入力】
新人の発話を1ターンずつ受け取って、お客様役として応答してください。

田所さん:これ、私の現場想定では「新人がロールプレイを1日10回回せる」状態になって、研修期間そのものが短縮できた感触がありました。具体的な短縮日数は環境次第ですが、何より新人が「失敗を怖がらずに練習できる」のが大きかった。人間相手だと、新人は緊張して本来の力が出ない。

佐藤:これ、ベテラン側にもメリットあって、「ロールプレイ相手で消耗していた時間が空いた」ことで、ベテランが本当に難しい案件に時間を使えるようになる。

Q10.最後にもう1本、トレンド分析プロンプトを(コピペ可能プロンプト5)

佐藤:5本目のプロンプト、これは「週次のトレンド分析」ですね。

あなたはCXアナリストです。
以下は過去4週間分のコールセンター応対サマリ(JSON配列)です。
SV向けに週次トレンドレポートを生成してください。

【出力フォーマット(Markdown)】
# 週次CXトレンド(YYYY-MM-DD〜YYYY-MM-DD)

## 1. 件数推移
- 週次総件数の推移(直近4週)
- 急増カテゴリTOP3(前週比+20%以上)
- 急減カテゴリTOP3(前週比-20%以上)

## 2. 新規発生問い合わせ
- 過去4週で初めて出現したと思われる問い合わせクラスタ
- 特に「製品アップデート直後」と推測される問い合わせはハイライト

## 3. 解決時間の傾向
- 大分類別の平均通話時間(分)
- 平均より大幅に長い案件カテゴリ

## 4. compliance_flag集計
- 「契約解除言及」「返金要求」「SNS言及」のフラグ件数推移
- SNS言及があった案件は、X(旧Twitter)等での炎上リスクが高いカテゴリかを推察

## 5. SVへの提案アクション(最大5つ)
- データから読み取れる具体的アクション
- 「○○のFAQを起票すべき」「○○カテゴリに人員追加すべき」「○○の応対トークスクリプトを見直すべき」など

【ルール】
- 「○○さんが」など個人特定の分析はしない
- 因果関係の断定は避ける。「〜の傾向がある」「〜の可能性」で表現
- 数値は実データに基づくもののみ。推測で数字を出さない

【入力】
<four_weeks_summaries>
{過去4週output/配下のJSONをすべて結合}
</four_weeks_summaries>

田所さん:このトレンド分析、月1のセンター長会議の資料作りに使ってます。今までExcelで何時間もかけて作ってたグラフと考察を、Claude Codeが下書きしてくれる。最終調整は人間がやりますが、ゼロから書くのとレビューするのでは負担が違う。

Q10b.プロンプト運用のコツ:バージョン管理を最初からやる

佐藤:プロンプトを5本紹介してきましたが、もう1つだけ、運用に関するtipsを補足させてください。それは「プロンプトもコードと同じくバージョン管理する」ということ。

田所さん:これ、私もハマりました。最初は1つのプロンプトファイルを直接書き換えながら運用していたら、3週間後に「あれ、先週まで動いていた要約品質が落ちた気がする…」となったときに、誰がいつどう変えたかわからなくなった。

佐藤:Git管理が当然のように見えますが、コールセンター現場のSVがGitを使えるとは限りません。私のおすすめは、prompts/フォルダの中にYYYYMMDD_用途.md形式で日次スナップショットを保存するシンプルな運用です。Claude Codeに「今日使うプロンプトはどれ?」と聞けば、最新のスナップショットを自動で参照してくれる設計にする。

田所さん:あと、プロンプトを変更したら必ず同じ入力で新旧両方を実行して差分確認すること。「ちょっとした言い回しの調整」が、想定外の出力フォーマット崩壊を引き起こすことがあります。私の現場では、prompts/test_cases/に「期待される出力」を3〜5件入れておいて、変更のたびにそれで回帰テストする運用にしました。

佐藤:Claude Code自身に「このプロンプトでこの入力を処理した結果が、test_cases/の期待出力と一致するか確認して」と頼めるので、テストフレームワークを別途構築する必要はない。これがClaude Codeの良いところ。

【要注意】よくある失敗パターン4選

Q11.実装あるある:CRM連携で必ず引っかかるポイント

佐藤:ここからは少し技術寄りの話を。CRM連携でハマりがちなポイント、田所さんの現場ではどうでした?

田所さん:これね、SalesforceでもZendeskでもkintoneでも、共通の落とし穴があります。3つ挙げますね。

1つめ、カテゴリタグの値マッピング問題。Claude Codeが返したcategory_l1の値が、CRM側のマスタに存在しないと書き込みエラー。「商品問い合わせ」というラベルがCRMでは「product_inquiry」というキーで持たれているケース、多いです。

佐藤:これ、対策としてCLAUDE.mdに「カテゴリ値はCRMマスタ(faq/category_master.json)の値しか使わない」と明記して、マスタJSONをClaude Codeに事前に読ませておく。これで誤マッピングがほぼ消えます。

田所さん:2つめ、顧客ID紐付け問題。音声からは顧客IDが取れないケースが多い。電話番号からCRMの顧客IDを引く処理が必要なんですが、これをClaude Codeにやらせると遅い。Pythonスクリプト側で電話番号→顧客IDの引き当てをやって、その結果をClaude Codeに渡す設計が正解でした。

佐藤:役割分担として「決定論的に書ける処理はPython、文脈解釈が必要な処理はClaude Code」という分け方ですね。電話番号→顧客IDの引き当ては正規化されたSQLでやれるので、Claudeに任せる必要ない。

田所さん:3つめ、重複登録問題。同じ通話の文字起こしが2回処理されると、CRMに同じ応対履歴が2件登録される事故。これは私たちのチームで実際に起きました。

佐藤:対策は、処理済みファイル名を「processed_log.json」のような台帳に記録して、Claude Codeに「このファイル名が台帳にあったら処理スキップ」と明示する。Pythonのingest.pyスクリプト側でも二重チェック。これでうちは事故ゼロです。

Q12.オペレータが「AIに監視されている感」を持たないようにするには

佐藤:これも大きなテーマです。導入アナウンスで現場のオペレータがどう感じるか。

田所さん:本当に大事なポイントです。私が現場SVだった頃のことを思い出すと、新しい品質モニタリングツールが入るたびに、オペレータの間で「監視されている」「これで人員削減されるんじゃないか」という空気が広がる。これを最初に潰さないと、運用が回らない。

佐藤:どう潰しました?

田所さん:3つやりました。1つめは「AIは応対メモを書く補助で、評価はしない」と明確に宣言すること。文書化してオペレータ全員に配る。2つめは「AIが書いた要約は必ずオペレータ本人が確認・修正してからCRMに保存」するワークフロー設計。あくまでメモの下書きを書いてくれる相棒、という位置づけ。3つめは「AIに任せて空いた時間は、より複雑な案件のスキルアップ研修や、休憩時間の延長に充てる」と明示。

佐藤:3つめが特に効きそうですね。「AIで業務効率化したぶん、人員削減します」ではなく「より高度な対応や個人のスキルアップに時間を使えます」というメッセージ。

田所さん:はい、これは経営判断と紐付くので、技術側だけでは決められない。プロジェクト立ち上げ時に、経営層から「AI導入による人員削減はしない、再配置と高度化に使う」という明確なメッセージを出してもらうのが重要でした。

Q13.繁忙期・閑散期の波対応はどうしました?

佐藤:コールセンターって繁忙期と閑散期の差が激しいですよね。Claude Code側の処理キャパシティはどう設計しました?

田所さん:これ盲点なんですが、応対メモ生成ってリアルタイム性が要らないんですよ。通話が終わってから1時間後にCRMに登録されてもいい(オペレータ本人が下書きを確認してからCRM保存する場合)。なので、繁忙期は処理をキューに積んで順次回す設計にしました。

佐藤:具体的にはどう実装?

田所さん:シンプルにファイルベースのキューです。transcripts/フォルダに新規ファイルが来たら、scripts/process_queue.pyが順次処理。並列数は3〜5本に絞って、API側のレート制限を超えないようにする。繁忙期で200件溜まっていても、1〜2時間で処理し切れるので、オペレータの帰宅前には全件確認可能になります。

佐藤:本格的なメッセージキュー(SQS、RabbitMQ等)を使う必要は?

田所さん:規模次第ですが、私が見ていた1日500〜2,000件規模のセンターならファイルキューで十分でした。1日1万件超えるような大規模センターなら、SQSやRabbitMQの導入を検討する段階。でもまずはファイルキューから始めて、限界を体感してから次に進むのが安全。

Q14.導入の進め方:いきなり全社展開しないでください

佐藤:最後に、これからコールセンター×Claude Codeを始めようとしている方への進め方アドバイスをお願いします。

田所さん:3段階で進めてほしいです。

1. 1ヶ月目:1チーム5名で要約だけ。マスキング済みテキスト→要約JSON→output/に吐くだけ。CRM連携はまだしない。SVが30件目視確認して精度を測る
2. 2〜3ヶ月目:CRM書き込み+FAQ起票候補生成。1チームでの運用が安定したら、CRM API書き込みを有効化。FAQ起票候補プロンプトを動かして、SVのレビューフローに組み込む
3. 4ヶ月目以降:ロールプレイ・SVダッシュボード追加+他チーム展開。1チームで完全に回るようになってから、新人ロールプレイ・週次トレンドを追加。並行して隣のチームへ展開

佐藤:絶対に避けてほしいのは「全社一斉導入」。100席のセンターでいきなり全席にClaude Code連携を入れたら、現場の運用が破綻します。私が見てきた成功事例はほぼ全部、小さく始めて段階的に広げています。EC問い合わせ自動化のケースでも同じパターンでした。

Q15.既存のCTI・PBXとの連携、どこまでやれます?

佐藤:もう1つ、現場が必ず聞かれる質問。「うちのCTIは10年前のオンプレ機です。連携できますか」というやつ。

田所さん:これね、結論を先に言うと「CTIと直接連携しない」のが正解でした。間に音声ファイルの共有ストレージを1段挟む。CTIは録音ファイルを所定のNFS/SMBフォルダに吐いてくれれば、それ以降はClaude Code側のパイプラインに渡せます。

佐藤:CTIベンダーに依存しないアーキテクチャ、ということですね。

田所さん:はい。CTIに直接APIを叩きにいくと、ベンダー依存が増えて、CTI更改のたびに連携部分を書き直す羽目になる。「録音ファイルを共有ストレージにコピーしてくれさえすれば、こちらの処理は変わらない」という疎結合設計が、5〜10年スパンで運用する上では一番強い。

佐藤:ファイル名規約とメタデータの扱いはどうしました?

田所さん:ファイル名に通話日時・内線番号・通話IDを埋め込むのが定番です。「20260527_0930_ext1042_call0142.wav」みたいな形式。Pythonスクリプトでファイル名をパースして、必要な情報を抽出。CTIごとに命名規則が違う場合は、ingest層に変換アダプタを噛ませる設計にしてください。

Q16.オペレータの応対トークスクリプトもAIで作れます?

佐藤:もう1つ実務的な質問。応対トークスクリプト、いわゆるアドリブの定型フレーズ集をAIで生成する案件もありそうです。

田所さん:これはやりました。具体的には、新製品リリース直後の問い合わせトークスクリプトを、過去類似製品の応対履歴からAIに下書きさせる、という運用。

佐藤:プロンプトの骨格だけ簡単に紹介しますね。

• 過去の類似製品応対サマリ(直近6ヶ月)を入力
• 「以下の問い合わせパターン上位5つに対する、3〜5分で回答できるトークスクリプトの下書きを作成」
• 「企業の公式トーン(丁寧・親しみ・距離感)を守る」
• 「想定問答形式で、お客様の追加質問への返しも2つずつ用意」

田所さん:これも当然、SV+ベテラン+商品企画担当の3者レビューを経てから現場展開。AIの下書きをそのまま読み上げる形にすると、現場のオペレータの言葉になじまずに浮きます。レビュー時に「うちの現場ならこう言う」という言い回し調整を必ず入れてください。

Q17.導入後のKPI、どこを見たらいいですか?

佐藤:導入してから「うまくいってる/いってない」を判定するためのKPI、どこを見るべきでしょう?

田所さん:3層に分けて見ると整理しやすいです。

1層目:オペレータの作業時間。あと処理時間(AHT – After Call Work)が短縮されたか。これは導入前後で測定可能。ただし新しいツールに慣れるまでの2〜4週間は逆に伸びることもあるので、月次トレンドで判断する。

2層目:対応品質。SVがレビューした応対メモの「修正率」を見る。Claude Codeが書いた要約を、オペレータ本人が大幅修正する率が高いなら、プロンプトのチューニングが足りない。私が見た現場では、最初2ヶ月は修正率40〜50%、3ヶ月目で20%前後、半年で10%前後に落ち着くのが標準でした(あくまで想定例です)。

3層目:顧客体験。応対後のお客様アンケート(NPS、CSAT)に変化があるか。これは導入の真の成果。ただしアンケート回収数が少ないと有意な差が出にくいので、半年〜1年スパンで見る。

佐藤:3層目に到達するまで時間がかかる、ということですね。経営層には「最初の3ヶ月は1層目の数字で進捗報告、2層目と3層目は半年〜1年で出てきます」と最初に共有しておくべき。

田所さん:はい、これを最初に握っておかないと、3ヶ月時点で「NPSが上がってないじゃないか」と言われて、プロジェクト自体が止まる事例を何件か見てきました。KPI設計はキックオフ時に経営層と握るのが最大の成功要因です。

Q17b.オペレータの育成にどう活用するか:Claudeとの「振り返り会話」

佐藤:もう1つ、現場での副次効果として面白かった話。新人オペレータが、自分の応対の振り返りにClaude Codeを使い始めた、と聞きました。

田所さん:これね、自然発生的に起きたんです。Q9のロールプレイ機能を使い慣れた新人が、ある日「自分の今日の通話3本をClaudeに見せて、改善ポイントを聞いてみていいですか」と言ってきた。SVとして「ぜひやってみて」と。

佐藤:結果は?

田所さん:本人いわく「先輩SVに聞くと『時間がない』と言われたり、評価される空気で本音が話せなかったりするけど、Claudeは何度でも聞ける」と。これ、新人にとっての心理的ハードルが下がったんですよね。SVが減らせる、という意味ではなく、SVに行く前のセルフ振り返り段階が成立した、ということ。

佐藤:これ、ある意味では「AIが先輩オペレータの代わりに育成サポートをしている」状態ですね。ただ気をつけたいのは、Claudeに食わせる通話文字起こしも、必ずマスキング済みのものを使うこと。新人が「自分の練習だから」と未マスキングの本物の通話データを直接Claude APIに投げたら、それはコンプラ違反です。

田所さん:これも運用ルールとして明文化が必要。「個人の振り返りで使う場合も、必ず社内のマスキング済みデータベースから取得する」と。技術的な制約以前に、組織のルールとして決めておく。

Q18.費用感はどれくらい?

佐藤:気になる費用ですが、Claude APIの利用料はどうでした?

田所さん:あくまで想定例として、月1万件の応対サマリ生成だと、入力1件あたり3,000〜5,000トークン、出力1,000トークン前後。Claude Sonnet系で計算すると、月数万円〜十数万円のレンジに収まりました。これ、SVが1日1時間レポート作成から解放されることを考えれば、確実にROI黒字です。

佐藤:注意点として、これは「マスキング済みテキストを処理する」コストだけです。オンプレSTTの構築・運用コスト、CRM連携API開発コスト、コンプラ部門との調整工数は別途見込んでおいてください。

Q19.将来展望:音声直接処理がコンプラクリアになったら何が変わる?

佐藤:最後に少し未来の話を。今は「録音音声をクラウドAPIに直送しない」設計で進めていますが、将来的にコンプラ・ガイドラインが整備されて、音声直接処理が許容されるようになったら何が変わるでしょう?

田所さん:大きく3つ変わると思います。1つめはリアルタイム性。通話中にAIがSVに「この案件はフラグ立ちました、聴いてください」と通知できるようになる。今はあと処理時に判定するしかないものが、進行中に判定できる。

佐藤:2つめは?

田所さん:音声トーン情報の活用。今は文字起こしに落としてしまうので「お客様の声の震え」「沈黙の長さ」が消える。これらは熟練SVなら気づける重要な情報ですが、テキストには現れない。音声を直接扱えるようになると、ここを補える可能性がある。ただし判定精度の検証は厳しくやる必要があります。3つめは多言語対応。多言語コールセンターで、その場で言語判定して適切な要約を出す、というユースケースが楽になる。

佐藤:とはいえ、ここでも繰り返したいのは「AIが判定した内容を、お客様対応の最終判断にそのまま使わない」というラインは絶対に守ってほしい、という点です。リアルタイム性が上がっても、人間SVの判断を介する設計は崩さない方がいい。

田所さん:同意です。技術の進歩と、人間の役割の境界線をどう引くか、というのは別の議論。コールセンターという、お客様の感情・人生に深く触れる仕事は特に、その境界線の引き方が大事だと思います。

3アクション:この記事を読んだあなたが今日できること

関連する業界別事例

• ECカスタマーサポート自動化 × Claude Code — Eメール・チャット中心のCS自動化アプローチ。本記事の音声起点と対比でどうぞ
• ホテルレビュー返信業務 × Claude Code — 公開系コンテンツの応対自動化の難しさ。「FAQ肥大化」問題の参考に
• 自治体問い合わせ振り分け × Claude Code — マスキング+VPC内処理のアーキテクチャ実装例

著者プロフィール

参考出典

• Anthropic「Claude Code overview」(https://docs.claude.com/en/docs/claude-code/overview)— Claude Codeの基本仕様・運用パターン
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」(https://www.ppc.go.jp/)— 通話録音・AI活用時の同意取得・第三者提供に関する基本原則
• 総務省「電気通信事業における個人情報保護に関するガイドライン」(https://www.soumu.go.jp/)— 改正電気通信事業法を踏まえた通信の秘密と外部送信規律
• 厚生労働省「コンタクトセンター・コールセンターにおける労働環境ガイドライン」(参考)— オペレータの労働時間管理・ストレス対策
• Anthropic「Prompt Engineering for Claude」(https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview)— 本記事の各プロンプト設計の参照元

※本記事の応対率・削減率・FAQヒット率に関する数字は、複数のセンター運用経験を再構成した想定例です。実際の効果は環境・規模・既存システムに大きく依存します。Claude Codeは要約・分類・FAQ起票候補生成の補助ツールであり、最終的な顧客対応判断・品質評価・FAQ公開判断はオペレータとSVが担います。録音データ・個人情報の取り扱いは、必ず社内の法務・コンプライアンス部門および所管法令(個人情報保護法・電気通信事業法・業界別ガイドライン)に基づいて設計してください。

関連記事（自動）

• ▸ 【2026年最新】司法書士・法律事務所のClaude Code活用｜登記・契約書を効率化
• ▸ 【2026年最新】税理士・会計事務所のClaude Code活用｜申告書・顧問先レポート自動化
• ▸ 法律事務所×Claude Code 完全実装ガイド｜契約書ドラフト・判例リサーチ・依頼者対応の月100時間効率化【2026年最新】
• ▸ 動画字幕・サムネ案・概要欄をClaude Codeで半自動化
• ▸ NPOの助成金申請業務をClaude Codeで効率化｜想定モデル