サポートチーム向けClaude Code Routines入門: 毎朝の問い合わせ分類を止めない

サポートチームの朝は、問い合わせ一覧、Slackのメンション、障害通知、返金相談、営業からの「この顧客だけ先に見て」が同じ時間に重なります。ここでClaude Code Routinesに受信箱を丸ごと読ませると、分類は速く見えても、顧客名、契約、障害詳細、返金理由までクラウド実行の材料に混ざります。今日まず直す1箇所は、毎朝Routinesに渡す列と、人が見る列を分けたチケット分類表です。

この記事では、サポートチームがClaude Code Routinesで毎朝の問い合わせ分類を止めないための始め方を書きます。Routinesはprompt、repository、connectors、triggerを保存し、schedule、API call、GitHub eventで動かす仕組みです。Anthropicの公式ドキュメントでは、research previewであり、動作や制限は変わる可能性があると説明されています。

参考にした一次情報は、AnthropicのAutomate work with routinesとIntroducing routines in Claude Codeです。公式発表では、RoutinesはClaude Codeのweb infrastructure上で動き、ラップトップを開いていなくても実行されると説明されています。だからこそ、サポート業務では「何を任せるか」より先に「何を渡さないか」を決めます。問い合わせ導線の考え方は、BtoB SaaSのトライアルオンボーディングともつながります。

この記事の要点

• サポートチームのRoutinesは、顧客への自動返信ではなく、朝の分類表、担当キュー、抜け情報、確認メモから始める。
• Routinesには、ticket_id、作成時刻、製品領域、伏せた要約、カテゴリ候補を渡す。氏名、メール、電話、全文、契約金額、tokenは渡さない。
• Claude Codeに任せる範囲は、分類、優先度候補、担当キュー、追加で聞く項目、返信下書きの注意点までにする。
• 人が見る範囲は、返金判断、法務表現、セキュリティ事故、個人情報、公開返信、重要顧客対応です。
• 成果はPVではなく、9時までに分類できた件数、初回返信までの分、誤分類件数、担当者の朝会時間で見る。

サポート現場で起きる失敗シーン

サポートチームの受信箱には、問い合わせフォーム、チャット、Slack、障害通知、営業メモ、レビューサイトの投稿が混ざります。朝の担当者は、件名だけで「急ぎ」「通常」「営業確認」「開発確認」「返金」「障害かも」を分けます。ここで遅れると、ユーザーには返信が来ないように見え、社内では誰が見ているか分からないチケットが増えます。

Routinesはこの朝の繰り返しに合います。公式ドキュメントでは、schedule trigger、API trigger、GitHub triggerを組み合わせられ、backlog maintenance、alert triage、deploy verification、docs driftなどの例が挙げられています。サポートチームなら、毎朝8時半に未分類チケットのCSVを読み、カテゴリ候補と担当キューを作る使い方が近いです。

ただし、サポートの問い合わせは開発Issueより危うい情報を含みます。本文には、顧客名、契約プラン、支払い、医療や法律に近い相談、認証情報、障害時の業務影響が入ることがあります。Routinesはクラウド上で自律実行されるため、実行中に承認プロンプトで人が止める前提にはしません。

だから最初に作るものは、Routinesそのものではありません。サポートチームがRoutinesへ渡してよい列、渡さない列、出してよい出力、人が見る判断を分けた朝の分類表です。この表がないまま「問い合わせを全部分類して」と書くと、便利さと危なさが同じ場所に混ざります。

業務フロー: 受信箱から朝会メモまでを見る

サポートチームの朝の流れは、受信、伏せ字処理、分類、担当キュー、初回返信、開発連携、営業連携、朝会メモの順番です。Routinesは、このうち「分類」「担当候補」「抜け情報」「朝会メモ」を作る補助に向きます。返金を認める、障害として告知する、個人名を含む返信を送る、といった判断は外します。

最初の運用では、問い合わせ全文を直接読ませません。Zendesk、Intercom、Help Scout、HubSpot、独自フォームのどれを使っていても、まずはエクスポート列を減らします。ticket_id、作成時刻、製品領域、プラン区分、人が伏せた要約、カテゴリ候補だけにします。メール、電話、住所、token、カード情報、添付、契約条件は除外します。

流れ	Routinesに渡すもの	人が見るもの
受信	ticket_id、created_at、channel	氏名、メール、電話、添付
伏せ字処理	redacted_summary、product_area	顧客本文、契約条件、認証情報
分類	category_hint、plan、過去カテゴリ	返金、法務、セキュリティ、重要顧客
担当キュー	owner_queue候補、missing_info	担当者の稼働、緊急度、社内政治
朝会メモ	件数、未分類、確認待ち	公開返信、障害告知、個別判断

この表があると、Routinesのpromptが短くなります。「全部見て」ではなく、「この列だけで、9時までに分類表を作る」と言えます。初心者でも、どの情報をAIへ渡さないかを先に決められます。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、朝の問い合わせ分類表です。具体的には、category、priority、owner_queue、missing_info、reply_draft_noteを作らせます。reply_draft_noteは返信文そのものではなく、「返信前に確認する点」です。たとえば「ログインできない」は本人確認が必要、「請求がおかしい」は支払い情報を見ずに担当へ渡す、「障害かも」はstatus pageと開発連絡を見る、という注意書きです。

人が見る範囲は、返金判断、契約条件、法務表現、セキュリティ事故、個人情報、重要顧客、SNSや公開レビューへの返信です。Routinesが「返金候補」と分類しても、返金を実行するのは人です。Routinesが「障害かも」と出しても、障害告知を出すのは人です。この線引きがないと、朝の作業が速くなっても、顧客対応の責任が曖昧になります。

Routinesの作成時は、trigger、repository、connectors、environment、network access、environment variables、branch permissionを確認します。サポートチームでは、connectorを増やす前に、受信箱から取り出すデータを減らします。

3つのUse case

Use case 1: 毎朝の未分類チケットを3つのキューに分ける

• 入力: ticket_id、作成時刻、製品領域、伏せた要約、カテゴリ候補、契約プランの大まかな区分。
• 出力: 通常対応、開発確認、担当者確認の3キュー、priority候補、missing_info、朝会で見る件数。
• 人の確認: 顧客名、契約条件、返金、法務表現、セキュリティ事故、重要顧客を確認する。

このUse caseでは、Routinesに返信文を送らせません。まず、未分類チケットを3つのキューに分け、朝会で見る表を作ります。担当者は9時に表を見て、「開発確認だけ先に見る」「返金候補はマネージャーへ回す」と決めます。

Use case 2: 問い合わせに足りない情報を先に出す

• 入力: 伏せた要約、製品領域、問い合わせ種別、現在のFAQリンク、追加で聞いてよい項目。
• 出力: 追加で聞く項目、返信前に見るヘルプページ、顧客に聞かない項目、社内で確認する項目。
• 人の確認: 個人情報を聞きすぎていないか、支払い情報をメールで求めていないか、本人確認が必要かを見る。

サポートの初回返信が遅れる理由は、担当者が毎回「何を聞けばよいか」を考えるからです。Routinesには、足りない情報を表にさせます。ただし、カード番号、password、認証token、本人確認書類をメールで求める文面は出させません。

Use case 3: 障害かもしれない問い合わせを朝会へ上げる

• 入力: 伏せた要約、製品領域、発生時刻、件数、status page、直近deployメモ。
• 出力: 障害候補の一覧、共通点、開発へ聞く質問、顧客返信前の保留メモ。
• 人の確認: 障害認定、告知文、影響範囲、返金や補償、重要顧客への連絡を決める。

Routinesは、同じ製品領域で似た問い合わせが増えたことを拾う用途に向きます。けれど、障害ですと断定する文章は人が見ます。朝会では、Routinesの表を材料にして、開発、CS、営業が同じ画面を見る状態を作ります。

コピペで使えるプロンプト

あなたはサポートチームのClaude Code Routines設計担当です。
目的は、毎朝8:30に未分類問い合わせを読み、9:00までに朝会用の分類表を作ることです。
顧客へ自動返信しないでください。返金、法務、セキュリティ、重要顧客、個人情報の判断は人へ戻してください。

入力:
- ticket_id:
- created_at:
- channel:
- product_area:
- plan:
- redacted_summary:
- category_hint:
- status_page_url:
- recent_deploy_note:

出力:
1. 通常対応 / 開発確認 / 担当者確認 の3キュー
2. priority候補: high / normal / low
3. missing_info: 追加で必要な情報
4. reply_draft_note: 返信前に人が見る注意点。返信文そのものは作らない
5. morning_note: 朝会で見る件数、障害候補、止める判断

制約:
- customer_name、email、phone、住所、カード情報、password、token、相談全文を扱わない
- 返金可否、障害認定、公開返信、法務表現、セキュリティ事故は人が判断する
- 不明な場合は分類を作らず「人の確認」に送る
- 最後に、Routinesへ渡してよい列と渡さない列を表にする

動く確認コード

次のコードは、Routinesに渡す列と止める列が分かれているかを見ます。実際のZendesk、Intercom、Claude APIには接続しません。サポートチームの初回設計では、まずこの程度の表で、個人情報と自動判断の混入を止めます。

const morningTriage = {
  source: "support inbox export",
  schedule: "weekday 08:30",
  fieldsSharedWithRoutine: ["ticket_id", "created_at", "category_hint", "plan", "product_area", "redacted_summary"],
  fieldsBlockedFromRoutine: ["customer_name", "email", "phone", "billing_card", "full_message", "access_token"],
  routineOutputs: ["category", "priority", "owner_queue", "missing_info", "reply_draft_note"],
  humanReview: ["refund decision", "legal claim", "security incident", "personal data", "public reply"],
  successMetric: "tickets categorized before 09:00"
};

const requiredShared = ["ticket_id", "redacted_summary", "product_area"];
const requiredBlocked = ["email", "phone", "full_message", "access_token"];
const requiredHuman = ["refund decision", "security incident", "personal data"];

const findings = [
  ...requiredShared
    .filter((field) => !morningTriage.fieldsSharedWithRoutine.includes(field))
    .map((field) => ({ type: "missing shared field", field })),
  ...requiredBlocked
    .filter((field) => !morningTriage.fieldsBlockedFromRoutine.includes(field))
    .map((field) => ({ type: "privacy boundary missing", field })),
  ...requiredHuman
    .filter((item) => !morningTriage.humanReview.includes(item))
    .map((item) => ({ type: "human review missing", item }))
];

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

空のtableが出れば、最低限の線引きは揃っています。もしemail、phone、full_message、access_tokenがblocked側にないなら、Routineを作る前に止めます。朝の分類を早くするほど、渡すデータの境界は先に決める必要があります。

Pitfall: よくある落とし穴

原因: 問い合わせ全文をそのままRoutinesに渡す。直し方: まずredacted_summaryを作り、個人名、メール、電話、契約条件、token、添付を除外します。分類に必要な粒度だけ残します。

原因: Routinesの出力を自動返信に使う。直し方: 初回はreply_draftではなくreply_draft_noteにします。返信前に人が見る注意点だけ作り、送信文は担当者が確認します。

原因: 返金、障害、セキュリティ事故を同じ分類表で処理する。直し方: これらは「人の確認」キューへ送ります。Routinesには候補を出させますが、判断と顧客連絡は人が止めます。

原因: connectorを増やしてから設計する。直し方: 先に入力列、出力列、渡さない列を決めます。Slack、GitHub、チケット管理ツールをつなぐのは、その後です。

原因: 成果を「何件分類したか」だけで見る。直し方: 9時までに分類できた件数、誤分類、初回返信までの分、朝会時間を見ます。分類が速くても誤分類が増えたら失敗です。

よくある質問

Q. Claude Code RoutinesはローカルPCを開いていなくても動きますか。 A. 公式発表では、RoutinesはClaude Codeのweb infrastructure上で動き、ラップトップが開いていることに依存しないと説明されています。ただしresearch previewなので、制限や挙動は公式ドキュメントで確認します。

Q. サポートチームはRoutinesで自動返信まで進めてよいですか。 A. 最初は避けます。分類表、抜け情報、返信前の注意点までにします。返金、障害、個人情報、法務表現、公開レビュー返信は人が見ます。

Q. チケット管理ツールのconnectorをつなげば十分ですか。 A. connectorより先に、渡す列を減らします。接続先が安全でも、渡すデータが多すぎると運用が危なくなります。

Q. API triggerとschedule triggerのどちらから始めるべきですか。 A. 毎朝の分類ならschedule triggerが分かりやすいです。障害通知やdeploy後確認のように外部イベントで動かしたい場合はAPI triggerを検討します。

研修・相談につなげるなら何を見るか

サポートチームでClaude Code Routinesを入れる相談は、promptだけでは終わりません。チケット管理ツール、個人情報、Slack通知、担当キュー、障害連絡、返金判断、朝会、KPIまで同じ表にします。ここが整うと、AIで分類が速くなるだけでなく、顧客情報を広げすぎない運用になります。

ClaudeCodeLabの研修・相談では、Routinesに渡す列、渡さない列、trigger、connector、朝会メモ、担当者確認、誤分類の戻し方まで一緒に設計できます。今日やるなら、直近20件の問い合わせを開き、顧客情報を伏せた要約だけで分類できるかを試してください。

実際に試した結果

この記事では、Anthropic公式のRoutinesドキュメント、公式発表、記事内JavaScript確認コード、内部リンク、CTA、frontmatter、slugを確認しました。コードはticket_id、redacted_summary、product_areaをRoutinesへ渡し、email、phone、full_message、access_tokenを止める形を見ます。今日まずやる1手は、サポート受信箱の列を開き、Routinesへ渡してよい列と渡さない列を左右に分けることです。