「再現できません」はほぼ必ず手順の問題です
良い再現手順 = 明確な開始点 + 1 ステップ 1 アクション + 実際のデータ + 各ステップでの観察結果。 誰かが声に出して読んで同じ画面にたどり着けるなら、その手順は十分です。以下では 5 つのルール、粒度の判定基準、5 つの完全な例（断続的なバグの書き方を含む）、送信前のチェックリストを紹介します。
開発者が「再現できません」と返すのは、たいてい意欲の問題ではありません。手順に何かが欠けていて、それは多くの場合この 3 つのどれかです。
+ が含まれるときだけ発生します。一言でいえば、手順はあなたのための記録ではなく、他人のためのルートです。
機能する手順の 5 つのルール
user+test@x.com と書き、「あるメールアドレス」とは書きません。手順はどこまで細かく書くべきか
| 粒度 | 例 | 問題 |
|---|---|---|
| 粗すぎる | 「チェックアウトを開いて商品を削除したら件数が違う」 | 3 つの操作を 1 文に圧縮。どこで壊れるか分かりません |
| ちょうどよい | 「1. /cart を開く 2. 商品の右の［削除］をクリック 3. ページ上部のバッジを見る」 |
1 ステップ 1 アクションで、それぞれ検証可能 |
| 細かすぎる | 「1. ポインタをボタンに移動 2. 左ボタンを押す 3. 離す」 | 物理操作まで分解すると、むしろ読みにくくなります |
判定基準：書き終えたら 2 つ自問します。① 他人が私のスクリーンショットを見なくても同じ画面に到達できるか。② 開発者が 2 分以内にフロントエンドか API かデータかを判断できるか。どちらも「はい」なら粒度は適切です。
5 つの完全な例
例 1：ログインと認証（5 ステップ）
前提条件：アカウント test@example.com が登録済みで正常な状態。
環境：Chrome 120 / macOS 14 / デスクトップ / 1920×1080 / シークレットウィンドウ。
https://app.example.com/login を開くtest@example.com と正しいパスワードを入力する期待：「認証コードが正しくありません。再試行してください」と表示され、アカウントはロックされない。 実際：認証コードが正しいにもかかわらず「アカウントをロックしました。24 時間後に再試行してください」と表示される。
例 2：決済とクーポン（6 ステップ）
前提条件：カートに商品が 2 点、合計 ¥1,299。アカウントは法人タイプ。 環境：Chrome 120 / Windows 11 / デスクトップ / 1440×900 / 法人アカウント。
/cart を開き、合計が ¥1,299 であることを確認するSAVE100 を入力する（3 日前に期限切れ）期待：「クーポンの有効期限が切れています」と表示され、カートは変化しない。 実際：「クーポンを適用しました」と表示して ¥100 を割引。［適用］を押した瞬間にカートの商品 2 点が消える。
例 3：モバイルのタッチ操作（5 ステップ）
前提条件：ログイン済み、カートに商品が 1 点。 環境：iPhone 14 / iOS 17.2 / Safari / ビューポート 390×844。
https://shop.example.com/cart を開く期待：ボタンがキーボードの上に移動し、タップできる状態が保たれる。 実際：キーボードがボタンの約 60% を覆い、その領域をタップしても反応しない。
例 4：API とデータ（4 ステップ）
前提条件：テスト環境のトークンを取得済み。DB に注文が 12,400 件あり、キーワードに一致するのは 12 件。
環境：https://api-test.example.com / curl 8.x。
Authorization: Bearer <token> を付けて GET /api/orders/export?month=2026-08 を実行するmonth=2026-08-01~2026-08-07 に変えて再試行する期待：200 とエクスポートジョブ ID、またはキュー投入を示す 202 が返る。 実際：504（ゲートウェイタイムアウト）。期間を狭めると 200 が返るため、しきい値はデータ量に依存する。
例 5：断続的なバグ（確率とタイミング付き）
前提条件：アカウントの残高はゼロ。テストカードをテストユーザーに登録済み。 環境：Chrome 120 / macOS 14 / ネットワークを 3G に制限。
/checkout を開き、支払い情報を入力する期待：注文は 1 件だけ作成される。連打はクライアント側で重複排除されるか、API の冪等性でブロックされる。
実際：10 回中 3 回、注文が 2 件作成された（再現条件：間隔 500ms 未満かつネットワーク遅延 1 秒超）。Network パネルの録画と、2 回の POST /api/orders のリクエスト ID を添付。
断続的なバグの書き方：
- 「たまに」ではなく確率を書きます。「10 回中 3 回」のほうが 100 倍役に立ちます。
- タイミングやしきい値を書きます。「間隔 500ms 未満」「遅延 1 秒超」——こうした条件は根本原因の手がかりになることが多いです。
- 証拠の種類を書きます。断続的なバグが持ち帰れる唯一の恒久的な証拠は、画面録画とコンソールログです。
手順を無効にする 7 つのミス
送信前チェックリスト
- 前提条件（ログイン状態 + データ状態）を書いたか？
- 最初のステップは「ブラウザを開く」ではなく業務操作か？
- 各番号に操作は 1 つだけか？
- プレースホルダーではなく実際の値か？
- 重要なステップの後に観察結果を書いたか？
- 期待結果と実際の結果を分けて書いたか？
- 断続的なバグは確率とタイミングを書いたか？
よくある質問（FAQ）
再現手順は何ステップくらいが適切ですか？
通常 3〜8 ステップです。3 未満は前提条件が不足していることが多く、8 を超える場合はたいてい短縮できます。ナビゲーション部分を前提条件に移し、問題を引き起こす操作だけを残してください。
環境情報は手順に書きますか、専用フィールドに書きますか？
専用フィールドです。手順に入れると読むリズムが崩れ、絞り込みもできません。環境フィールドがない形式（メールなど）の場合は、手順の先頭に 1 行で宣言します：「環境：Chrome 120 / macOS 14 / 1920×1080」。
「戻るをクリック」「ダイアログを閉じる」のような無関係な操作も書くべきですか？
再現条件の一部である場合だけ書きます。見分け方は、そのステップを削って問題が再現するかどうかです。再現するなら削除、しないなら必要です。
自分でも再現できないバグの手順はどう書きますか？
3 つを正直に書きます。① 試した条件（どの試行が成功し、どれが失敗したか）。② 手元にある最強の証拠（録画、コンソールログ、ネットワークリクエスト）。③ 気づいた相関（「回線が遅いときだけ」など）。必現であるかのように装わず、タイトルや備考に「再現条件は未確定」と明記してください。
再現手順とテストケースの違いは何ですか？
テストケースは事前に設計された検証リストで、正常系・境界・例外をカバーし、網羅性を狙います。再現手順は事後に記録された 1 本の経路で、問題を確実に再現することだけを目的とします。互いに参考になりますが目的は異なります — テストケースの書き方は テストケーステンプレートと例 をご覧ください。
手順は人が書く。証拠は自動化できる
手順はクリックした本人が書く必要があります — 何をしたか知っているのはあなただけです。ただし、一緒に提出する環境と証拠は自動で埋められます。
- 画面録画：現在のタブをワンクリックで録画してトリミング。断続的なバグでも再生可能な証拠が残ります。
- 診断データ：エラーレベルのコンソールログと失敗したネットワークリクエスト（HTTP 400 以上）を収集し、機密パラメータは自動でマスクします。
- 技術情報の自動取得：URL、ブラウザ、OS、解像度、ビューポートを自動で記入します。
- 注釈付きスクリーンショット：範囲を選んで矢印・枠・テキストを追加し、失敗箇所を画像に固定します。
- 共有・同期：登録なしで開ける共有リンクを発行、または Feishu の多次元テーブルや汎用 Webhook へ送信できます。
関連記事
- バグレポートのフォーマット：10 フィールドの仕様
- バグ報告テンプレート：記入例付きのコピー可能な骨組み
- バグタイトル例：良い例と悪い例 40 組の比較
- テストケーステンプレートと例
- 効果的なバグ報告の方法