タイトルが本文よりも重要な理由
良いバグタイトル ＝ どの画面で ＋ 何をして ＋ 何が起きたか ＋ どの条件で再現するか。 この4つを1行に収めれば、開発者は追加の質問なしで再現できます。良いタイトルと悪いタイトルの違いは、これだけです。以下では、ログイン・会員登録・決済・モバイル・API・パフォーマンス・UI の7シナリオに分けて40組の比較例をまとめました。自分のバグをそのまま書き換えるのに使えます。
開発者が最初に見るのは、いつでもタイトルです。曖昧なタイトルは、追加の質問を1往復増やすか、チケットが後回しにされるかのどちらかになります。さらに悪いことに、環境情報をどれだけ丁寧に埋めても、悪いタイトルは救えません。「ボタンが壊れている」というチケットを開く人はいないのです。
タイトルの良し悪しは次の4点で決まります。具体的か（コンポーネントや画面を名指ししているか）、観察可能か（「動かない」ではなく事実を書いているか）、条件を含むか（ブラウザ、端末、アカウント種別、時刻）、そして影響範囲を判断できるか（全停止かエッジケースか）。
バグタイトルの4要素フォーミュラ
[画面/コンポーネント] + [操作] + [発生した事象] + [再現条件]
各要素の埋め方：
- 画面・コンポーネント：チェックアウト画面／ログインモーダル／注文一覧／
POST /api/orders - 操作：クリック、送信、アップロード、タブ切り替え、スキャン
- 発生した事象：無反応、500 が返る、金額の桁が1つ多い、ステータスが同期しない、テキストが重なる
- 再現条件：Chrome 120、iOS 17.2、幅390px未満、法人アカウントのみ、通信タイムアウト後
Sentence Case、コンポーネントを先頭に、優先度タグは付けない。多くのチームがこの慣習に落ち着きます。どの慣習を選ぶかよりも、統一されていることのほうが重要です。
1. ログインとアカウント（7例）
| 悪いタイトル | 良いタイトル |
|---|---|
| ログインボタンが動かない | Chrome 120 で［ログイン］をクリックしても無反応。コンソールに TypeError: login is not a function |
| パスワード再設定メールが届かない | Gmail アドレスで［パスワードをお忘れの方］をクリック後、30分経っても再設定メールが届かない（迷惑メール確認済み） |
| ログイン後に遷移先が違う | 一般ユーザーがログイン後に /dashboard ではなく /admin に遷移する。v5.3 から必現 |
| 認証コードがずっとエラーになる | 正しい画像認証コードでも「コードが正しくありません」と表示。シークレットウィンドウのみで再現 |
| アカウントがロックされる | パスワードを3回間違えるとアカウントが永久ロックされるが、メッセージは「24時間後に再試行してください」 |
| セッションが無効にならない | 2台目の端末でログインしても1台目のセッションが切れず、そのまま操作できる |
| SSO ログインが失敗する | IdP の証明書更新後から、SSO コールバックが「Invalid signature」を返す |
要点：ログイン系のバグでは、条件（ブラウザ、アカウント種別、シークレットモード）が再現可否を決めます。省略しないでください。
2. 会員登録とフォーム（7例）
| 悪いタイトル | 良いタイトル |
|---|---|
| 会員登録できない | メールアドレスに「+」を含む場合（例 user+test@x.com）に「メール形式が正しくありません」で弾かれる |
| 電話番号のバリデーションがおかしい | 11桁を正しく入力しても「11桁の電話番号を入力してください」と表示される |
| パスワード強度の表示が誤っている | 数字を含む8文字のパスワードでも「数字を含めてください」と表示される |
| プルダウンが選択できない | 3文字入力して絞り込んだ後、「国・地域」プルダウンを矢印キーで選択できない |
| フォームが二重送信される | 登録フォームで Enter を押すと二重送信され、ユーザーが2件重複して作成される |
| 必須項目がチェックされない | 「利用規約に同意する」が未チェックでも登録が完了し、アカウントが作成される |
| タイムゾーンの初期値が誤っている | タイムゾーンの初期値が UTC+0。日本（UTC+9）のユーザーは毎回手動で変更が必要 |
要点：説明文ではなく、具体的な入力値に置き換えましょう。「入力がおかしい」と10行書くより、実際の文字列1つのほうが役に立ちます。
3. 決済とチェックアウト（7例）
| 悪いタイトル | 良いタイトル |
|---|---|
| 決済が失敗する | 合計 ¥1,299 がチェックアウトで ¥12,999（桁が1つ多い）と表示され、決済ページも誤った金額を引き継ぐ |
| クーポンが使えない | 期限切れクーポンが「有効」と表示され、適用すると 500 を返してカートが空になる |
| カートの件数が更新されない | 最後の商品を削除してもヘッダーのカートバッジが「1」のまま。再読み込みで解消する |
| 二重に課金される | 通信タイムアウト後の再決済で、同じ注文が2回課金される（注文番号 #10231） |
| 請求情報が保存されない | チェックアウトで入力した請求情報が、1つ前の画面に戻って再び進むと消える |
| 返金ステータスが同期されない | 返金処理済みなのに、ユーザー側の注文は「支払い済み」のまま（注文番号 #10388） |
| 支払い方法が表示されない | チェックアウトにカード払いの選択肢がない。旧請求プランのアカウントのみで発生 |
要点：金額や注文番号が絡むバグは、注文番号をタイトルに入れましょう。トリアージの時間が半分になります。
4. モバイルとレスポンシブ（6例）
| 悪いタイトル | 良いタイトル |
|---|---|
| スマホでレイアウトが崩れる | iPhone 14（iOS 17.2）の幅390px未満で、［カートに追加］ボタンが価格テキストと重なる |
| スクロールできない | モバイルでモーダルを開くとスクロールがロックされ、閉じた後も解除されない |
| キーボードが入力欄を隠す | Android Chrome でキーボードが［送信］ボタンを覆い、タップできない |
| 横向きのレイアウトが崩れる | iPad 横向き（1024×768）でナビゲーションバーが折り返し、ロゴとメニューが重なる |
| 画像が読み込まれない | Safari iOS 16 で商品メイン画像が表示されず、コンソールは 403（CDN 署名の期限切れ） |
| タップ領域が小さすぎる | モバイルのページャーボタンのタップ領域が 12×12px で、アクセシビリティ最小値の 44px を下回る |
要点：モバイルでは「スマホ」は条件になりません。機種、OS バージョン、ビューポート幅を具体的に書きましょう。
5. データ・API・権限（6例）
| 悪いタイトル | 良いタイトル |
|---|---|
| エクスポートが失敗する | 注文1万件以上のエクスポートが 504 を返す。分割エクスポートでは正常 |
| 日時がずれて表示される | レポートのタイムスタンプが8時間ずれる。タイムゾーン Asia/Shanghai のユーザーのみ |
| 検索しても結果が出ない | 「iPhone」で検索すると0件。DB には該当レコードが12件存在する |
| ページングで行が重複する | 注文一覧の2ページ目先頭に、1ページ目の最後の3行が重複して表示される |
| アップロードがエラーになる | 5MB 超の PNG アップロードが 413 を返すが、UI は「アップロード完了」と表示しファイルは空 |
| 権限の昇格が可能 | 参照のみのロールが DELETE /api/projects/12 を実行し、プロジェクトを削除できてしまう |
要点：API 系のバグは、HTTP ステータスコード、エンドポイントのパス、しきい値をタイトルに入れましょう。デバッグ作業の半分を先に済ませることになります。
6. パフォーマンスと読み込み（3例）
| 悪いタイトル | 良いタイトル |
|---|---|
| ページが遅い | 4G 回線でトップページの LCP が 8.2秒。要因は未圧縮の JavaScript 2.1MB |
| メモリリークしている | タブ切り替えを20回行うとメモリが 120MB から 900MB に増加し、最終的にタブがクラッシュする |
| API が遅い | 商品一覧 API の P95 が 4.8秒（基準 300ms）。セールのピーク時のみ発生 |
要点：パフォーマンス系は数値と基準値が必須です。なければ不具合かどうかを誰も判断できません。
7. 文言とUIの細部（4例）
| 悪いタイトル | 良いタイトル |
|---|---|
| 誤字がある | 注文確認画面の「確定」は「確認」が正しい |
| アイコンのスタイルが不統一 | 設定画面の4つのアイコンのうち2つが線画、2つが塗りつぶし |
| ダークモードで読めない | ダークモードで入力欄の文字色 #333 が暗い背景に重なり、ほぼ判読できない |
| エラーメッセージが不親切 | アップロード失敗時に「操作に失敗しました」のみで、原因も再試行方法も示されない |
要点：文言・UI 系のバグは「こう表示されている → こう表示すべき」と書くだけです。レビューコストが最も低いバグ種別です。
タイトルを悪くする7つの習慣
役割別の書き方
| 役割 | 書き方 |
|---|---|
| QA・テスター | 4要素のフルフォーミュラで、条件（ブラウザ、端末、アカウント、回線）をすべて記入 |
| サポート・運用からの起票 | ユーザーに見える事象＋再現手順＋スクリーンショット。原因が不明なら書かず「開発確認待ち」と付記 |
| UAT レビュー | 受け入れ基準に紐づける：「AC-3 不合格：注文ステータスが5秒以内に更新されない」 |
| プロダクトマネージャー | 優先度判断のためユーザー影響を書くが、技術的な事象の代わりにはしない |
タイトルを翻訳するとき
| 日本語タイトル | 英語タイトル |
|---|---|
| チェックアウトで最後の商品を削除してもカートのバッジが更新されない | Cart badge not updated after removing the last item on checkout |
| Android Chrome でキーボードが送信ボタンを覆い、タップできない | Android Chrome keyboard covers the Submit button, making it untappable |
| 参照のみのロールでプロジェクトを削除できる（権限昇格） | Read-only role can delete projects (privilege escalation) |
翻訳時の3原則：コンポーネント名が固有名詞なら原文のまま残す、観察できる結果は直訳する、そしてログメッセージとエラーコードは絶対に翻訳しない。翻訳されたスタックトレースは、再現できないバグになります。
よくある質問（FAQ）
バグタイトルはどのくらいの長さが適切ですか？ 60文字（英語なら10語）以内が目安です。一覧表示で切れずに済みます。収まらない場合は、主要な事象を絞り込めていないか、2つのバグが混ざっています。
優先度や深刻度はタイトルに入れるべきですか？ 入れません。優先度はスケジュールで変わる独立フィールドです。変わった瞬間にタイトルは誤りになり、検索も汚します。
原因がわからないとき、推測をタイトルに書いてよいですか？ 「〜の可能性」と添えるのは構いませんが、結論として断定しないでください。本文で根拠を示さないと、調査の方向を誤らせます。
同じバグが複数のブラウザで出る場合、チケットは分けるべきですか？ タイトルには主要な事象を書き、環境の差異は環境フィールドや備考に書きます。修正経路が実際に異なる場合（iOS と Android で別のコードパスなど）のみ分割します。
Title Case と Sentence Case のどちらを使うべきですか？ どちらでも構いませんが、既存のバックログと統一してください。過去の資産がなければ、Sentence Case のほうが読みやすく、一覧でも目で追いやすくなります。
タイトルは人が書く。それ以外は自動化できる
はっきり言っておきます。BugCapturer はタイトルを書いてくれません — 目撃した事象をどう表現するかは、あなたの判断が必要だからです。ただし、面倒で書き漏らしやすい項目は自動で埋められます。
- 技術情報の自動取得：URL、ブラウザ、OS、画面解像度、ビューポートサイズを自動で取得するため、タイトルに入れる条件を手で写す必要がありません。
- 診断データ：エラーレベルのコンソールログと、失敗したネットワークリクエスト（HTTP 400以上）を収集。機密パラメータ（トークン、パスワード、API キー）は自動でマスクされます。
- 注釈付きスクリーンショット：ドラッグで範囲を選び、矢印・枠・テキストを追加。「どこがおかしいか」が画像に固定されます。
- 画面録画：現在のタブを録画してトリミングし、検証できる12秒の動画として開発に渡せます。
- ワンクリック共有・同期：外部の協力者が登録なしで開ける共有リンクを発行するか、Feishu の多次元テーブル／汎用 Webhook に送信できます。
こうすれば、タイトルの1行だけに集中でき、残りの項目はツールが埋めてくれます。
ダウンロード用チェックリスト
モニターの横に貼って、送信前に確認してください。
- コンポーネントや画面を明示しているか？
- 「動かない」ではなく、観察できる事実を書いているか？
- 条件（ブラウザ／端末／アカウント／回線／画面幅）を含んでいるか？
- 検証できる数字（ステータスコード、注文番号、金額、所要時間、しきい値）があるか？
- 事象は1つだけか？
- 優先度と未検証の推測を外したか？
- 60文字（英語なら10語）以内に収まっているか？
7つすべて満たせば、あなたのタイトルはバックログの9割より先にトリアージされます。
関連記事：バグ報告テンプレート（全フィールドとコピー可能なテンプレート）· 効果的なバグ報告の方法 · テストケーステンプレートと例 · バグレポートのフォーマット · 再現手順の書き方