公式スキル · カスタマーサクセス

サポートチケットからバグ報告を書く

顧客の不満を、再現手順、期待する動作と実際の動作、環境、影響、証拠、顧客への質問がそろった、開発がすぐ着手できるバグ報告にする。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

AI に渡すもの

できあがるもの

Jira、Linear、GitHub にそのまま貼れるバグ報告と、顧客への質問。

手順

  1. 何が、どこで失敗するかがわかる件名を書く 型は「[どこで・いつ] [操作] が [どう失敗する]」。例:「レポートの CSV エクスポートで1,000行を超える行が落ちる」。「エクスポートが壊れている」や、顧客の言葉そのままの「至急!!バグ」にはしない。
  2. 再現手順を、番号つきの単一の操作で書く わかっている状態から始める(「Team プランの管理者としてログインした状態」)。1手順に1クリックか1入力。画面の表記はそのまま太字で書く。顧客の手順があいまいなら、書ける分だけ書き、不確かな手順に「[未確認]」と付ける。
  3. 期待する動作と実際の動作を書く 期待: ドキュメントやこれまでの動作から、製品がすべきこと。実際: 起きたことを、目に見える形で(メッセージの文面、表示されたもの、表示されなかったもの)。エラーメッセージは一字一句そのまま引用する。
  4. 環境と頻度を記録する ブラウザー、アプリのバージョン、OS、プラン、アカウント ID、発生日時とタイムゾーン。頻度: 毎回、ときどき(y回中x回)、1回だけ。
  5. 影響の大きさを見積もる 報告している顧客数やチケット数、回避策の有無、お金・データ・セキュリティに関わるか。重大度(S1〜S4)を提案し、理由を1行で書く。
  6. 証拠を添える スクリーンショット、録画、ログ、チケット ID を並べる。顧客の個人情報は報告に書かず、チケット ID で参照する。
  7. 顧客に聞くことを並べる 足りない事実を、サポート担当がそのまま貼れる質問にする(「お使いのブラウザーとバージョンを教えていただけますか」)。質問は4つまで、大事な順に。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: bug-report-from-ticket
description: 顧客の不満、サポートチケット、チャットを、開発チームがそのまま着手できるバグ報告に書き直す。再現手順、期待する動作と実際の動作、環境、影響、証拠、顧客にまだ聞くべきことの一覧をそろえる。チケットに不具合の報告があり開発に回すとき、「このバグを起票して」「チケットから Jira や Linear の課題を作って」と頼まれたとき、開発から詳細不足でチケットが何度も差し戻されるときに使う。
---

# チケットからバグ報告を書く

開発者がチケットのやりとりを読まず、報告だけでバグを再現できる状態にする。顧客が見たことと、原因についての推測は分ける。足りない情報は思い込みで埋めず、足りないと書く。

## 使う場面

- チケットに不具合が書かれていて、開発に回す必要があるとき。
- 開発から「再現できない」「情報が足りない」とチケットが差し戻されたとき。
- 複数のチケットが同じ不具合を報告していて、ひとつの報告にまとめたいとき。
- 機能の要望や使い方の質問には使わない。ticket-triage で振り分ける。

## 用意するもの

- チケットやチャットのやりとり。スクリーンショット、エラー文、リンクの記述も含めて。
- わかれば顧客の環境: プラン、ブラウザーまたはアプリのバージョン、端末、OS、アカウントやワークスペースの ID。
- 自分で再現を試したなら、その結果。試していなければ「未再現」と書く。
- わからない事実は推測しない。「顧客に聞くこと」に入れる。

## 手順

1. **何が、どこで失敗するかがわかる件名を書く。** 型は「[どこで・いつ] [操作] が [どう失敗する]」。例:「レポートの CSV エクスポートで1,000行を超える行が落ちる」。「エクスポートが壊れている」や、顧客の言葉そのままの「至急!!バグ」にはしない。
2. **再現手順を、番号つきの単一の操作で書く。** わかっている状態から始める(「Team プランの管理者としてログインした状態」)。1手順に1クリックか1入力。画面の表記はそのまま太字で書く。顧客の手順があいまいなら、書ける分だけ書き、不確かな手順に「[未確認]」と付ける。
3. **期待する動作と実際の動作を書く。** 期待: ドキュメントやこれまでの動作から、製品がすべきこと。実際: 起きたことを、目に見える形で(メッセージの文面、表示されたもの、表示されなかったもの)。エラーメッセージは一字一句そのまま引用する。
4. **環境と頻度を記録する。** ブラウザー、アプリのバージョン、OS、プラン、アカウント ID、発生日時とタイムゾーン。頻度: 毎回、ときどき(y回中x回)、1回だけ。
5. **影響の大きさを見積もる。** 報告している顧客数やチケット数、回避策の有無、お金・データ・セキュリティに関わるか。重大度(S1〜S4)を提案し、理由を1行で書く。
6. **証拠を添える。** スクリーンショット、録画、ログ、チケット ID を並べる。顧客の個人情報は報告に書かず、チケット ID で参照する。
7. **顧客に聞くことを並べる。** 足りない事実を、サポート担当がそのまま貼れる質問にする(「お使いのブラウザーとバージョンを教えていただけますか」)。質問は4つまで、大事な順に。

## 出力の形式

```markdown
# [件名: 操作、失敗、場所]

**重大度(提案):** [S1〜S4] — [理由]
**報告元:** [チケット ID] · **影響を受けた顧客:** [わかっている数]
**社内での再現:** [できた / できなかった / 未実施]

## 再現手順
1. [開始時の状態]
2. [単一の操作、**画面の表記**]
3. [...]

## 期待する動作
[本来起きるべきこと]

## 実際の動作
[起きたこと。エラー文は「」でそのまま]

## 環境
- ブラウザー/アプリ: [...] · OS/端末: [...] · プラン: [...] · アカウント: [ID]
- 日時: [日付、時刻、タイムゾーン] · 頻度: [毎回 / y回中x回 / 1回だけ]

## 影響
[誰が作業を止められているか、回避策の有無、お金・データ・セキュリティに関わるか]

## 証拠
- [スクリーンショット / ログ / チケットへのリンク]

## 顧客に聞くこと
1. [質問]

## メモ(未確認)
- [原因についての仮説。推測だとはっきり書く]
```

## 例

**入力:**

> デザイン事務所「森のアトリエ」の小西さんからのチケット #2291:「ブランド設定でロゴをアップロードすると、ずっとくるくる回ったままです。2回試しました。Chrome です。PNG で、6MB くらい。明日のクライアントへの提案で必要なんです」。サポートのメモ: 社内のテストアカウントで1MB の PNG を試したところ、問題なくアップロードできた。

**出力:**

```markdown
# ブランド設定で6MB の PNG のロゴをアップロードすると終わらない

**重大度(提案):** S2 — 顧客1社が期限を前に作業を止められている。回避策(小さいファイル)はありそう
**報告元:** #2291 · **影響を受けた顧客:** 1
**社内での再現:** できなかった — 1MB の PNG は問題なくアップロードできた。6MB は未実施

## 再現手順
1. ワークスペースに管理者としてログインする。
2. メニューから **設定 > ブランド** を開く。
3. 画面の **ロゴをアップロード** を押し、6MB 程度の PNG を選ぶ。
4. 待つ。

## 期待する動作
ロゴがアップロードされてプレビューが表示される。または、ファイルが大きすぎるとエラーが出る。

## 実際の動作
アップロード中の表示が回り続け、終わらない。エラーは出ない。2回中2回発生。

## 環境
- ブラウザー/アプリ: Chrome、バージョン[不明] · OS/端末: [不明] · プラン: [不明] · アカウント: #2291 を参照
- 日時: [日付と時刻は不明] · 頻度: 2回中2回

## 影響
顧客1社が、明日のクライアントへの提案を前に作業を止められている。回避策の候補: ロゴを1MB 未満に圧縮する。お金・データ・セキュリティには関わらない。

## 証拠
- チケット #2291

## 顧客に聞くこと
1. くるくる回っているときの画面のスクリーンショットを送っていただけますか。
2. お使いの Chrome のバージョンを教えていただけますか。(メニュー > ヘルプ > Google Chrome について)
3. ロゴを1MB 未満に小さくしたものは、アップロードできますか。

## メモ(未確認)
- 大きなファイルのアップロードに、ファイルサイズの上限やエラーメッセージがないのかもしれない。
```

## 送る前のチェック

- [ ] チケットを見たことのない人が、質問せずに手順をたどれる。
- [ ] 期待する動作と実際の動作が分かれていて、実際の動作は推測ではなく観察したこと。
- [ ] エラーメッセージがそのまま引用され、わからない環境の項目は「[不明]」になっている。
- [ ] 原因の推測は「メモ(未確認)」の下にだけある。
- [ ] 顧客のメールアドレス、電話番号、支払い情報が報告に入っていない。
- [ ] 「顧客に聞くこと」は4つ以内で、そのまま貼れる。

## よくある失敗

- 実際の動作に「動かない」と書く。画面に何が表示されたかを書く。
- ありそうだからと、ブラウザーやバージョンを埋める。間違った情報より「不明」のほうが役に立つ。
- 2つの不具合を1つの報告に混ぜる。手順が違うなら2件に分けて起票する。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

出典

出典は英語のページです。

  1. Bug Writing Guidelines (2026-11-04に確認)
  2. Bug Report Guidelines | WebKit (2026-11-04に確認)
  3. Configuring issue templates for your repository (2026-11-04に確認)