Claudeのカスタマーサポートプラグインでチケット対応を回す手順
Anthropicのcustomer-supportプラグインは、チケットの分類、調査、返信案、エスカレーション、KB記事化を5つのスキルで分担します。導入手順、P1〜P4の基準、連携先、自社ルールに寄せる方法をまとめます。
customer-supportプラグインは、サポート担当者の作業を5つのスキルに分けて任せるAnthropic製のプラグインです。着信チケットの分類、顧客の質問の調査、返信案の下書き、エンジニアへのエスカレーション、解決済み案件のKB記事化までを、1つの導入でひとまとめにできます。
主な利用先はCowork(Anthropicのデスクトップ向けエージェントアプリ)で、Claude Codeでも動きます。プラグインのバージョンは1.3.0です。ここでは導入手順、5スキルの役割、判断基準の中身、自社の運用に寄せる方法を順に見ます。
customer-supportプラグインの5スキルは何をするか
プラグインはAnthropicの knowledge-work-plugins リポジトリの customer-support ディレクトリにあります。説明文は「チケットの分類、返信案の作成、問題のエスカレーション、ナレッジベースの構築」です。
5つのスキルの役割
ticket-triage
カテゴリ、優先度(P1〜P4)、担当チームを決め、重複チケットや既知の問題かどうかを確かめます。
customer-research
顧客の質問に対し、複数の情報源を横断して調べ、出典と確度を付けて答えをまとめます。
draft-response
状況・相手との関係・チャネルに合わせた顧客向けの返信案を作ります。
customer-escalation
影響範囲、再現手順、必要な判断を揃えた、エンジニアリング・プロダクト・経営層向けの報告書を作ります。
kb-article
解決済みの案件から、検索されやすいナレッジベース記事の下書きを作ります。
流れとしては、まずticket-triageで分類と優先度付けを行い、必要ならcustomer-researchで調べてからdraft-responseで返信案を作ります。直らない案件はcustomer-escalationで担当チームへ上げ、解決した案件はkb-articleでナレッジベース記事に残します。
各スキルは実行後に次の一手を提案する作りで、たとえばトリアージ後に「返信案を作りましょうか」「エスカレーションしますか」と尋ねます。
導入手順 — マーケットプレイス追加からインストールまで
READMEのインストール手順は2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install customer-support@knowledge-work-plugins1行目でマーケットプレイスを登録し、2行目でプラグインを入れます。セッション内では /plugin marketplace add と /plugin install でも同じことができ、/plugin install はすぐに入れず、詳細パネルを開いて導入範囲(スコープ)を選ばせます。入れたあとに反映されない場合は /reload-plugins を実行します。
Coworkで使う場合、上のコマンドは使いません。READMEにCowork側の導入画面の説明はなく、Claude Codeの導入ページはclaude.aiとCoworkのプラグインを別の案内ページに分けています。Coworkでの追加と管理の流れはCoworkの部門別プラグインの使い方を参照してください。
プラグインのスキルは、プラグイン名を前に付けた形で呼び出されます。公式のプラグイン解説には、my-plugin に入れた review スキルが /my-plugin:review として動く例があります。これに従えば、ticket-triageは /customer-support:ticket-triage です。実際に打てる名前は、スラッシュ入力時の候補一覧で確かめるのが確実です。
READMEとスキル名が食い違う点に注意
導入前に知っておきたいのが、READMEの記述と、リポジトリの実体とのずれです。
| README上の呼び名 | 実際のスキルフォルダ |
|---|---|
/triage(スキル名ticket-triage) | 実際のスキルフォルダticket-triage |
/research(スキル名customer-research) | 実際のスキルフォルダcustomer-research |
/draft-response(スキル名response-drafting) | 実際のスキルフォルダdraft-response |
/escalate(スキル名escalation) | 実際のスキルフォルダcustomer-escalation |
/kb-article(スキル名knowledge-management) | 実際のスキルフォルダkb-article |
READMEのコマンド表には /triage /research /escalate が並び、スキル表には response-drafting escalation knowledge-management が載っています。ところがスキルのフォルダ名と、各 SKILL.md の先頭にある name は、右列のとおりです。各スキルの本文の見出しも /ticket-triage や /customer-escalation になっています。
READMEの記述どおりに /escalate と打って反応がない場合は、名前の違いを疑ってください。この記事ではリポジトリの実体に合わせ、右列のスキル名で説明します。
ticket-triage — 分類と優先度の基準
ticket-triageは、入力から「本当の問題」「症状」「顧客の文脈」「緊急度の手がかり」「感情の状態」を読み取り、次の形で出力します。
- 見出しの1行要約と、カテゴリ・優先度・製品領域
- 問題の要約、影響範囲、回避策の有無、関連チケット、既知の問題かどうか
- 担当チームの推奨とその理由
- 顧客への初回返信案
- 担当者向けの内部メモ(再現のヒント、エスカレーションの引き金)
カテゴリは9種類
カテゴリは、バグ、使い方の質問、機能要望、請求、アカウント、連携、セキュリティ、データ、パフォーマンスの9種類です。「以前は動いていたのに動かない」はバグ、「動き方を変えてほしい」は機能要望、と見分ける目安がスキル内に書かれています。
バグと機能要望が同居するときはバグを主カテゴリにします。ログインできない原因がバグなら、アカウントではなくバグに分類します。根本原因でカテゴリを決める考え方です。
優先度はP1からP4
| 優先度 | 基準 | 初動の目安 |
|---|---|---|
| P1 | 基準本番停止、データ損失・破損、セキュリティ侵害、大半のユーザーに影響 | 初動の目安1時間以内に応答、1〜2時間ごとに更新 |
| P2 | 基準主要機能の障害、重要な作業の停止、回避策なし | 初動の目安4時間以内に応答、4時間ごとに更新 |
| P3 | 基準機能の一部不全、回避策あり、単一ユーザーか小規模チーム | 初動の目安1営業日以内に応答、3営業日以内に解決か更新 |
| P4 | 基準軽微な不便、見た目の問題、一般的な質問、機能要望 | 初動の目安2営業日以内に応答 |
さらに、待ち時間がSLAを超えた、複数の顧客が同じ問題を報告した、顧客が経営層の関与に触れた、回避策が効かなくなった、影響範囲が広がった、のいずれかなら優先度を自動的に一段引き上げます。
重複の確認と担当の振り分け
担当の振り分けは、使い方の質問・請求・パスワード再設定がTier 1、調査が要るバグや連携の問題がTier 2、修正が要る確定バグがエンジニアリング、需要の大きい機能要望がプロダクトです。データへの不正アクセスや脆弱性の報告はセキュリティ、返金や契約の争いは請求・経理に回します。
重複の確認は、症状、顧客、製品領域、既知の問題の4方向から検索する手順です。重複が見つかれば既存チケットに紐づけ、新しい情報を追記し、新規報告で緊急度が増すなら優先度を上げます。
customer-researchとdraft-response — 調べて、返す
customer-researchは、顧客の質問に答える前の調査を担当します。情報源を5段階に分け、確度を付けるのが特徴です。
| 段階 | 情報源 | 確度 |
|---|---|---|
| 1 | 情報源社内の公式資料、ナレッジベース、ポリシー | 確度高 |
| 2 | 情報源CRM、サポートチケット、会議メモ | 確度中〜高 |
| 3 | 情報源チャット、メール、カレンダーのメモ | 確度中 |
| 4 | 情報源Web、フォーラム、外部のドキュメント | 確度低〜中 |
| 5 | 情報源推論、類推、一般的なベストプラクティス | 確度低 |
情報源同士が食い違うときは、矛盾を明示し、より新しく権威のある側を示し、顧客に出す場合は最も保守的な答えを使います。ロードマップ、価格、法務、セキュリティにかかわる質問は、直接答えずに確認や上申を促します。
draft-responseは、相手が誰か、状況の種類、緊急度、チャネル(メール、チケット、チャット)、関係の段階、相手の役職を整理してから下書きを作ります。出力には宛先・件名・チャネル・トーンの見出しと、「送らない内部メモ」が付きます。内部メモには、方針の理由、送信前に確認すべき事実、リスク、送信後の対応が入ります。
下書きを出す前の品質チェックは7項目です。トーン、許可されていない約束の有無、社外に出せないロードマップの有無、過去のやり取りの正確さ、次のステップと担当、相手の役職への適合、チャネルに合った長さを見ます。長さの目安は、チャットが1〜4文、チケット返信が短い段落1〜3つ、メールが3〜5段落です。
返信の書き方そのものはClaudeで問い合わせ返信を作るにまとめています。
customer-escalationとkb-article — 上げて、残す
customer-escalationは、エスカレーションすべきかを先に判定します。回避策が文書化されている、設定の問題で自分で直せる、案内や教育で足りる、といった場合はサポート側で対応します。確定バグ、複数顧客への影響、SLA超過、同じ問題を3社以上が報告、直したはずの問題の再発などは上げる対象です。
上げ先はL1からL2、L2からエンジニアリング、L2からプロダクト、セキュリティ、経営層の5経路です。セキュリティは階層を飛ばして直ちに上げます。
出力される報告書は、深刻度(Critical / High / Medium)、対象チーム、影響(顧客数・業務への影響・危うい売上・滞留時間)、問題の説明、試したこと、再現手順、顧客とのやり取り、求める判断、補足資料の順です。再現手順は、期待した結果と実際の結果、環境を添えて書く形式で、スキル内では「バグのエスカレーションで最も価値が高いもの」とされています。
エスカレーション後の追跡間隔も決まっています。
| 深刻度 | 社内フォロー | 顧客への更新 |
|---|---|---|
| Critical | 社内フォロー2時間ごと | 顧客への更新2〜4時間ごと(またはSLA) |
| High | 社内フォロー4時間ごと | 顧客への更新4〜8時間ごと |
| Medium | 社内フォロー毎日 | 顧客への更新1〜2営業日ごと |
kb-articleは、解決済みの案件から記事を起こします。記事の型はハウツー、トラブルシューティング、FAQ、既知の問題、リファレンスの5種類です。顧客の言葉でタイトルを付け、エラーメッセージを原文のまま入れ、同義語を含める、といった検索されやすさの指針が付いています。
出力には、タイトル、種類、カテゴリ、タグ、対象読者に加え、「公開メモ」として出典のチケット、更新すべき既存記事、レビューが要る担当者、次回の見直し日が付きます。記事を新規作成するか既存記事を更新するかの基準も用意されています。
連携先 — .mcp.jsonに入っているサーバー
プラグインの .mcp.json に事前設定されているMCPサーバーは次のとおりです。
- Slack(社内の議論と顧客チャンネル)
- Intercom(チケット履歴と顧客との会話)
- HubSpot(アカウントと連絡先)
- Guru、Notion(ナレッジベース)
- Atlassian(バグ報告と機能要望)
- Google Calendar、Gmail(URLが空のまま)
READMEにはメールとクラウドストレージとしてMicrosoft 365も載っていますが、.mcp.json にはありません。Google CalendarとGmailは、サーバー名だけがあってURLは空欄です。そのため、この2つは自分で接続先を設定するまで使えません。
別のツールを使う場合は、CONNECTORS.md にカテゴリ別の代替が示されています。サポート基盤ならZendeskやFreshdesk、CRMならSalesforceやPipedrive、ナレッジベースならConfluenceやHelp Scout、課題管理ならLinearやAsanaです。スキルの本文は、特定製品ではなく「サポート基盤」「CRM」といったカテゴリの記号で書かれているので、同じカテゴリのMCPサーバーを接続すれば動く設計です。
接続がないとき、プラグインは文脈の入力を求め、自分で埋められる枠組みとテンプレートを出します。同じ公式プラグインの読み方はfeature-devプラグインの手順でも扱っています。
自社のルールに寄せる — 使い始めの調整
スキルに書かれた優先度の基準やSLAは、一般的な雛形です。自社のSLAと食い違うなら、Claude Codeで使う場合に限り、プロジェクトの CLAUDE.md に上書きの方針を書いておく方法があります。Coworkでの調整方法は、READMEには載っていません。次は CLAUDE.md に書く一例で、数値と名称は自社の値に置き換えます。
## サポート運用ルール(customer-supportプラグインの既定を上書き)
- 優先度はP1〜P4。初回応答の目標: P1は30分、P2は2時間、P3は1営業日、P4は2営業日
- Enterpriseプランの顧客は、障害を1段階上のPで扱う
- 返信案には、返金・割引・納期の約束を書かない(担当者が決める)
- 製品領域の名称は「ダッシュボード」「API」「請求」「SSO」の4つに限る調整の効き方は、実際のチケットで確かめます。例えば次のように、過去に解決した案件を1件渡して、出力が自社の基準に沿うかを見ます。入力はREADMEの例と同じ文です。
/customer-support:ticket-triage Customer says their dashboard has been showing a blank page since this morning — they're on the Enterprise planREADMEには、この入力に対してカテゴリがBug、優先度がP2、製品領域がDashboard / Frontend、振り分け先がTier 2 Supportのトリアージが返る例が載っています。例であって、実行結果の保証ではありません。自社の基準に変えた場合に、優先度や担当がどう変わるかを数件の過去チケットで見比べてから運用に載せると、思わぬずれを早く拾えます。
向く場面と向かない場面
向くのは、トリアージの観点がチーム内でばらつく、返信の下書きに時間がかかる、解決した案件がKBに残らない、といった状況です。分類基準、返信の構成、報告書の書式が型として揃います。
向かないのは、チケットを無人で処理し続ける用途です。プラグインは担当者がスキルを呼び出して下書きを受け取る形で、draft-responseの出力には「送る前に確認する事項」が含まれます。顧客への回答は、人が内容を確かめてから送る前提の作りです。
自動応答のチャットボットを組み込みたい場合は、Claudeでカスタマーサポートチャットボットを作るのように、APIで実装する別の道があります。企業がどう設計を分けているかはClaudeカスタマーサポート導入事例が比較しています。
まとめ
customer-supportは、分類、調査、返信、エスカレーション、KB化を型で揃えるプラグインです。導入は2コマンドで済みますが、READMEとスキル名にずれがあるため、呼び出す名前は候補一覧で確かめてください。使い始めは、優先度とSLAを自社の値に合わせ、過去のチケット数件で出力を見比べるところから始めると、運用に載せやすくなります。