Claude CodeとMCPによるカスタマーサポートの一次対応自動化

過去10週間、私のMacでは毎朝6時にClaude Codeが単一の命令ファイルに従ってスケジュール実行されています。MCPサーバーを通じてトラフィック、新しい本番エラー、アップタイムを取得し、着席する前に1通のレポートをメールで送信します。これまで67回の実行——地味で信頼性が高い、まさにそれが目的です。

今週、これを朝一番の手作業の最大の塊に拡張しました：サポート受信箱。初回実行では5件のスレッドを処理し、メールクライアントに3件の返信下書きを作成、2件を正しくスキップしました。この記事では、まったく同じものを構築できるように、命令ファイルを含む完全なセットアップを紹介します。SiteSpeak固有のものは何もありません。MCPサーバーを備えたあらゆるサポートツールで動作します。

なぜ受信箱が手動だったのか

私たちのAIチャットボットはsitespeak.aiで一次対応を処理しており、その部分は何年も前から自動化されています。手作業として残っていたのは、ボットがエスカレーションするすべて——バグ報告、請求に関する質問、人間と話したいと希望する見込み客——です。これらは受信箱に届き、毎朝私は各会話を読み、どの「壊れている」報告が本当に壊れているのかを判断し、返信を書いていました。

量が問題だったわけではありません。1日数件のスレッドでは、節約される時間だけでは自動化を正当化できません。問題は一貫性でした。適切な返信には、エラーログの確認、関連コードの読み込み、ドキュメントの検証が必要であり、毎朝それをすべてのスレッドに対して、他の業務の合間に徹底的に行うことは、まさに適切なツールを持ったエージェントが代わりに行うべき仕事です。

セットアップ概要

4つの要素：

• Claude Code：スケジュールに基づいてヘッドレスで実行（launchdジョブからclaude -p "/morning-report"）。Linuxではcronも同様に動作。
• 4つのMCPサーバー：サポートツールの受信箱、Sentry、Nightwatch、そしてメールクライアント。
• 1つのMarkdownスキルファイル：ワークフロー、分類ルール、ハードリミットを記述。
• 1つのJSON状態ファイル：処理済みのすべてのスレッドを記録し、実行を冪等に保つ。

グルーコードは不要です。API統合プロジェクトも不要。エージェントは命令ファイルに従って4つのサーバーを1つの小さなエージェントワークフローに自ら構成します。これがMCPの実用的な利点です：ツールごとに通常必要だった統合作業が消え、「統合」は人間が読み編集できるドキュメントになります。

実際の実行内容

スキルファイルからのステップバイステップ：

1. サポートツールのMCPサーバーを介してオープンな受信箱スレッドをリストアップし、前回の実行以降にアクティビティがあるものだけを保持。状態ファイルで既に処理済みのものを除外。
2. ボットの回答だけでなく、訪問者自身のメッセージを読む。各スレッドを分類：緊急（既存顧客、何か壊れている、請求、人間を求める）、見込み客（評価中、価格、「Xはできるか」）、またはノイズ（スパム、空のセッション、テスト）。
3. 下書き前に調査。バグ報告はSentryとNightwatchで一致する本番エラーをチェックし、リポジトリ内の関連コードも確認。ハウツー質問はライブドキュメントで検証。このステップがどれほどうまく機能するかに最も驚きました。
4. まずメールを確認。下書き前に、エージェントは過去30日間にそのアドレスからの既存のメールスレッドを検索。人々はチャットボットが人間がフォローアップすると伝えた直後にメールでサポートに連絡することがよくあります。会話が既にメールで行われていた場合、そのスレッドはスキップ。
5. メールクライアントに下書きを作成。送信は禁止。すべての下書きは私の確認を待ちます。
6. スレッドをアーカイブし、訪問者ID、実施したアクション、理由を状態ファイルに記録。スキップしたものも記録しないと、次回の実行で同じスパムを再読してしまいます。
7. 報告。サポートセクションはエラー、トラフィック、アップタイムと同じ午前6時のメールに、スレッドごとに1行と下書きへのリンクを含めて届きます。

実行全体は20分のタイムアウトでラップされており、ハングしても明日の実行を妨げません。

最も効果を発揮する2つのルール

上記はすべて配管です。アウトプットを信頼できるものにしているのは、スキルファイル内の2行です。

「決して推測しない。下書き内のすべての主張は、このセッション内で検証されているか、下書きに存在しないかのいずれかでなければならない。」このルールがないと、LLMは自信たっぷりに友好的な口調で、あなたが持っていない機能を喜んで捏造し、支払い顧客に伝えます。ルールがあれば、主張は実行中にコード、ドキュメント、またはエラーログに対してチェックされたか、出現しません。これに従った下書きは、実際に問題を調べた人が書いたかのように読めます——なぜなら実際にそうだからです。

「絶対に送信しない。下書きのみ。」スキルのハードリミットセクションは送信ツールを完全に禁止しています。返信が顧客に届く唯一の方法は、私がメールクライアントで送信ボタンを押すことです。これは最もシンプルな人間参加型の仕組みです。これは信頼性を疑っているからではありません。ほとんどの下書きは編集なしで送信されます。しかし、人間による編集が必要な稀な下書きは、常に怒っている顧客へのメッセージであり、まさに送信後に取り消せないものです。

初回実行で明らかになったこと

最初の48時間で、このプロセスが価値を生むと確信させた3つの出来事：

• クロスチャネルの重複排除は初日に機能しました。5つのスレッドのうち1つは、訪問者が既に直接メールで連絡し、回答を受け取っていたためスキップされました。「最初にメールをチェック」ステップがなければ、同じ会社から2番目のわずかに異なる返信を受け取っていたでしょう。それはサポートがボットファームのように感じられる原因です。
• 自社のチャットボットの誤りをフラグしました。トリアージで、ボットが顧客に設定が存在しないと伝えた会話をキャッチしました。実際には別の設定ページに存在していました。レポートは「おそらく誤り、同日中に人間が返信が必要」とマークしました。私はそのスレッドを読み飛ばし、ボットの回答を信じ、たった1つの誤った文で顧客の信頼を失っていたでしょう。
• 見込み客が待たされなくなりました。製品を評価している人が実際の質問をすると、創業者からその日の朝に短い個人的なメールが届き、正しい回答が既に検証された状態で送られます。以前は、そのスレッドは私が手をつけるまで、時には数日間も放置されていました。

正直な限界

これは創業者レベルのセットアップであり、エンタープライズ向けサポートパイプラインではありません。1日数件のスレッド、1人の人間がすべてをレビューします。もし何百ものチケットに埋もれているなら、下書きのみのモデルはボトルネックを取り除けません。別の視点で見る必要があります。

また、エージェントは本番環境のアカウントデータに触れることができません。これは意図的です。請求に関する質問には、問題を認識したことを伝え、人間が必要とする詳細を尋ねる下書きが作成され、見ることのできないアカウント状態についての約束はしません。

そして、「検証するか省略するか」のルールを文書で強制する必要があります。スキルファイルは、新しいサポート担当者向けのオンボーディングノートのように扱ってください：明示的なルール、明示的なガードレール、そして書き留めなかったことはいつか問題を起こすと想定すること。

自分で構築する

サニタイズされたスキルファイル、README、およびlaunchd/cron設定例は公開リポジトリにあります：github.com/sitespeakai/support-inbox-agent。MCPサーバー名をご自身のスタックに合わせて置き換え、お客様とのコミュニケーション方法に合わせてルールを編集してください。

必要なもの：

• エージェントCLI。私はClaude Codeを使用しています。MCPサーバーをロードし、命令ファイルに従えるものであれば何でも構いません。
• MCPサーバーを持つサポートツール。SiteSpeakは独自のサーバーを提供しています：受信箱スレッドのリスト表示、会話の全文読み取り、リード情報の取得、スレッドのアーカイブが可能です。SiteSpeakをご利用の場合、最速の方法はClaude Codeプラグインを使用することです：/plugin marketplace add sitespeakai/sitespeak-claude-plugin、次に/plugin install sitespeak-chatbot-manager@sitespeak-plugins、そしてAPIトークンで認証します。
• 調査ステップを希望する場合は、MCPサーバーを持つエラートラッカー。Sentryは公式のMCPサーバーを持っています。
• 下書き用のMCPサーバーを持つメールクライアントまたはメールAPI。
• スケジューラー。macOSではlaunchd、その他ではcronにタイムアウトラッパーを付けて使用します。

まずはトリアージのみのバージョン（分類とレポート、下書きなし）から始めてください。1週間実行し、生成されるものを読んでください。分類を信頼できるようになったら下書き機能を追加し、送信は永遠に手動のままにします。この順序は私が構築した方法でもあります：レポートは顧客返信に触れさせる前に10週間実行されました。

FAQ

これにはSiteSpeakが必要ですか？ いいえ。このスキルは、スレッドのリスト表示、会話の読み取り、訪問者のメールアドレスの取得、スレッドのアーカイブができるMCPサーバーを持つあらゆるサポートツールで動作します。SiteSpeakのMCPサーバーはスキルの例示ツール名と完全に一致するため、適応作業が不要なパスですが、ワークフロー自体はツールに依存しません。

エージェントは自分でメールを送信できますか？ いいえ。スキルのハードリミットセクションは送信ツールを完全に禁止しているため、エージェントは下書きのみ作成できます。すべての返信は人間がレビューし送信します。ほとんどの下書きは編集なしで送信されますが、たまに修正が必要な下書きは常にハイステークスなものです。

どのMCPサーバーが必要ですか？ 2つは必須です：サポートツールの受信箱と、下書きをサポートするメールクライアント。Sentryのようなエラートラッカーはオプションですが、エージェントが一文を書く前にバグ報告を実際の本番エラーと照合する調査ステップを支えます。

まだ一次対応を行うチャットボットをお持ちでない場合、その部分がエージェントよりも重要です。この記事で扱っている受信箱が小規模に保たれているのは、ボットが人間に届く前にほとんどの質問に答えるからです。SiteSpeakを無料でお試しいただき、今日あなたのサイトで一次対応を稼働させることができます。MCPサーバーも含まれています。