SaaSサポートのバグ報告をClaude Codeで再現手順に変える実務フロー

SaaSの問い合わせ窓口では、「動きません」「昨日からおかしいです」という一文だけが先に届きます。急いでいる日は、そのまま開発者へ転送したくなりますが、これをやると開発側はログ、環境、再現手順を聞き返すところから始まります。

この記事では、サポート担当がClaude Codeを使って、曖昧な問い合わせを「再現できるバグ報告」に変える手順をまとめます。対象は小さなSaaSチーム、受託保守、社内ツール運用です。コードを書けない人でも、貼り付ける情報と確認する判断を分ければ運用できます。

この記事の要点

• 問い合わせ文をそのまま開発に渡さず、再現手順、期待結果、実際の結果、影響範囲に分けます。
• Claude Codeには文章整理、ログの候補抽出、確認質問の下書きを任せます。優先度、顧客対応、返金判断は人が決めます。
• 個人情報や契約情報はマスクしてから渡します。スクリーンショットも顧客名、メール、請求情報を隠します。
• 初回は無料PDFで基本コマンドを確認し、繰り返すならGumroadのプロンプト集、チーム運用なら導入相談に進むのが自然です。

Claude Codeに任せる範囲と人が決める範囲

Claude Codeに任せるのは、機械的に整理できる部分です。問い合わせ文を項目に分ける、再現手順の抜けを見つける、開発者へ渡す短い報告文を作る、顧客へ追加質問を送る文面を作る。このあたりは、毎回同じ型で進められます。

人が決めるのは、顧客との約束に関わる判断です。重大障害として扱うか、個別環境の問題として見るか、いつまでに返答するか、どの顧客を優先するか。ここをAIに丸投げすると、文章はきれいでも商売上まずい対応になります。

私の基準は単純です。事実を並べるところはClaude Code、約束を変えるところは人。これだけでも、問い合わせ対応の事故はかなり減ります。

実務フロー: 問い合わせから再現手順まで

最初に、問い合わせを四つの箱に分けます。

箱	入れるもの	例
状況	顧客が見た画面、日時、操作	2026-06-17 9:10、請求書CSVをアップロード
期待	本来起きるはずだった結果	インポート完了メッセージが出る
実際	起きた結果、エラー文	500エラー、処理中のまま止まる
証拠	ログ、スクショ、ブラウザ、権限	Chrome、管理者権限、対象CSVの行数

この四つがそろうと、開発者は「どこから見るか」を決めやすくなります。逆に、状況だけが長くて期待結果がない報告は、調査が止まりやすいです。

次に、Claude Codeへ渡す前にマスクします。顧客名、メールアドレス、請求ID、アクセストークン、住所、電話番号は置き換えます。たとえば [email protected] は [customer_email]、実在の会社名は [customer_name] にします。

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

以下をClaude Codeに貼り、問い合わせ文を下に置きます。

あなたはSaaSサポートの一次切り分け担当です。
以下の問い合わせを、開発者が再現に使えるバグ報告に整えてください。

出力形式:
1. 一文要約
2. 再現手順
3. 期待結果
4. 実際の結果
5. 足りない情報
6. 顧客へ聞く追加質問
7. 開発者へ渡す短いメモ

制約:
- 顧客名、メール、請求情報、トークンらしき文字列は出力しない
- 事実と推測を混ぜない
- 重大度は断定せず、判断材料だけ出す
- 追加質問は3つ以内

問い合わせ:
ここにマスク済みの問い合わせ文を貼る

プロンプトの肝は「重大度を断定しない」ことです。AIは親切に見える分類を出しがちですが、サポートでは顧客への約束につながります。ここは人が最後に決めます。

動く整理スクリプト

問い合わせ本文から、危険な文字列を先に隠す最小スクリプトです。Node.jsでそのまま動きます。

function maskSupportTicket(text) {
  return text
    .replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, "[email]")
    .replace(/sk-[A-Za-z0-9_-]{12,}/g, "[api_key]")
    .replace(/\b\d{4}-\d{4}-\d{4}-\d{4}\b/g, "[card_like_number]")
    .replace(/(customer|tenant|invoice)[_-]?[A-Za-z0-9]{6,}/gi, "[$1_id]");
}

const raw = "customer_acme123 says invoice_778899 fails for [email protected]";
console.log(maskSupportTicket(raw));

このスクリプトは万能ではありません。住所、会社名、スクリーンショット内の情報までは隠せません。だからこそ、スクリプトで一段目を処理し、人が最後に読む運用にします。

3つのユースケース

1. 請求CSVのインポート失敗
顧客は「CSVが入りません」と言います。サポート側はファイル行数、ヘッダー、失敗した時刻、権限、期待結果をそろえます。Claude Codeには、聞き返す質問を三つに絞らせます。

2. 管理画面だけが遅い
「遅い」は曖昧です。ページ名、操作、秒数、ブラウザ、ユーザー権限、同じ会社の別ユーザーでも起きるかを分けます。開発者へ渡す時点で「再現条件の候補」が見えるようになります。

3. 権限エラーの問い合わせ
顧客は「見られません」と書きます。サポートは対象画面、ロール、最近の権限変更、URL、エラー文を集めます。ただし、権限を広げる判断はAIではなく管理者が行います。

よくある失敗と直し方

失敗1: 問い合わせ全文をそのままAIに貼る
顧客名やメールが混ざります。直し方は、貼る前にマスクスクリプトを通し、スクリーンショットは目視で塗りつぶすことです。

失敗2: AIの重大度をそのまま採用する
「重大」と書かれると急ぎたくなりますが、影響顧客数、契約、回避策の有無を見ないと判断できません。重大度は判断材料だけ受け取り、人が決めます。

失敗3: 追加質問が多すぎる
十個も聞くと顧客は返しません。三つ以内に絞り、最初の返信で再現に必要な情報だけ聞きます。

失敗4: 開発者向けメモが長い
長文は読まれません。最初の一行で「どの画面で、どの操作が、どう失敗するか」を書き、詳細は下に分けます。

CTA: 次の一手

個人で試すなら、まず無料のClaude Codeチートシートで基本コマンドと安全な確認手順を手元に置いてください。サポート返信や開発者向け報告を毎回整えるなら、プロンプトテンプレート集が一番近い導線です。

チームで問い合わせから修正、テスト、公開確認までをつなぎたい場合は、導入相談で実際の問い合わせ例、権限、個人情報の扱い、開発者への渡し方まで一緒に設計できます。関連して、Claude Code権限ガイドとデバッグ手法も先に読むと理解が早いです。公式の基本はClaude Code docsで確認してください。

週次運用に入れる時のチェック

この型をチームに入れる時は、最初から全問い合わせに使わない方が安全です。まずは請求、ログイン、権限、インポートのように再現条件を集めやすいカテゴリを一つ選びます。問い合わせの種類が広すぎると、プロンプトも確認項目もぼやけます。

週次で見る数字は三つに絞ります。顧客への初回返信までの時間、開発者からの追加質問の数、再現できた問い合わせの割合です。PVや記事と同じで、数だけを増やしても意味はありません。問い合わせが開発者の手元で止まらなくなったかを見る必要があります。

サポート責任者は、Claude Codeが作った文章をそのまま送る前に、必ず約束表現を見ます。「すぐ直します」「必ず改善します」「障害です」といった言い切りは、調査前には使いません。使ってよいのは、確認した事実、次に確認すること、返信予定だけです。

この運用は、問い合わせ対応を冷たくするためではありません。むしろ顧客に余計な質問を何度も返さないための準備です。最初の返信が短くても、聞くべきことが的確なら、顧客は状況を説明しやすくなります。

もう一つ大事なのは、対応テンプレートと開発メモを分けることです。顧客へ送る文章は安心感と次の確認に寄せ、開発者へ渡す文章は再現条件と証拠に寄せます。同じ材料から二種類の文書を作ると、顧客向けのやわらかい表現が開発メモに混ざったり、開発者向けの断定が顧客返信に混ざったりします。

週の終わりには、Claude Codeが作った報告のうち、実際に開発者がそのまま使えたものを三件だけ読み返します。良かった文をテンプレートへ戻し、使いづらかった文はプロンプトの制約へ戻します。この小さな往復を続けると、サポートの一次切り分けが個人技からチームの型に変わります。

導入初期は、問い合わせ本文を全部AIに渡すのではなく、担当者が一度四つの箱へ手で分けてからClaude Codeに渡します。手間に見えますが、この一手で担当者自身が何を確認していないかに気づけます。数週間たって型が安定したら、マスク済み本文からAIに一次整理させる範囲を少し広げます。

最後に、開発者からの反応を必ず聞きます。報告が読みやすかったか、再現に必要な情報が足りたか、逆に余計だった情報は何か。サポートだけで完結させると、きれいな報告書は増えても修正速度は上がりません。開発側の一言をテンプレートへ戻すことで、実務の精度が上がります。

公開前に確認する会話の境界

サポートの自動整理では、顧客に聞くことと社内で調べることを混ぜないのが重要です。顧客には、再現に必要な最小限の情報だけを聞きます。社内には、ログ、環境、対象バージョン、直前の変更を広めに集めます。この境界がないと、顧客に技術的すぎる質問を返してしまいます。

問い合わせの最後には、無料PDF、プロンプト集、導入相談のどれに接続するかも見ます。再現手順だけを作って終わるのではなく、同じ事故を減らすチェックリストやテンプレートに読者を案内すると、記事から収益導線への流れが自然になります。

実際に試した結果

この記事の型で、問い合わせ文を三件だけ手元で整理してみました。確認したのは、個人情報が残っていないこと、再現手順が三行以内で読めること、期待結果と実際の結果が分かれていること、開発者へ渡す一文が最初にあることです。

一番効いたのは、追加質問を三つまでに絞るルールでした。質問が少ないと顧客の返信が返りやすく、開発者も次の調査に入りやすくなります。AIに任せる価値は、立派な文章を書くことではなく、毎回同じ箱に情報を戻してくれることでした。