英語バグレポートの書き方｜エンジニアに伝わる構造化テンプレ
最終更新: 2026-05-24
目次
本記事はアフィリエイト広告を含みます。
「Bug あったので英語で報告したいけど、どこから書けばいい？」「Severity と Priority、どっちが優先度？」── 英語のバグレポートは、構造化されたテンプレに沿って書くと、エンジニアの対応速度が一気に上がります。本記事では、Jira・GitHub Issues・Linear など主要ツール共通で使える構造化テンプレと、英語ネイティブが実際に書く言い回しを解説します。
1. バグレポートの基本構成（6 セクション）
英語のバグレポートは、以下 6 セクションで書くのが業界標準です。順番が崩れるとエンジニアが情報を探しにくくなるので、テンプレを固定しておきます。
標準テンプレート
Title: [短く要約]
Description: [何が起きているか]
Steps to Reproduce: [再現手順 1, 2, 3...]
Expected: [本来こうなるはず]
Actual: [実際はこうなった]
Environment: [OS / Browser / Version]
各セクションの役割
- Title — 30 文字以内で問題を一言で表す。ユーザー視点で書く
- Description — 背景と影響範囲。誰が困っているか
- Steps to Reproduce — 別のエンジニアがコピペで再現できる粒度
- Expected vs Actual — 期待と現実のギャップ
- Environment — 環境依存の切り分けのため必須
- Screenshots / Logs — 視覚的証拠
このテンプレをそのまま使い回すのが鉄則です。毎回構成を考えると時間も消耗しますし、エンジニア側も「いつもと違う書き方」だと読み飛ばしがちになります。
2. Title の書き方（バグの顔）
Title はバグレポートの顔です。Issue 一覧で 30 件並んだ時、一目で内容が分かるかが勝負。
良い Title の型
[Component] What is broken (when)
- [Login] Password reset email not delivered on Gmail（パスワード再設定メールが Gmail に届かない）
- [Checkout] Total amount displays incorrect tax for EU customers（EU 顧客の合計金額の税額表示が誤り）
- [API] /users endpoint returns 500 when query param is empty（クエリ空で 500 を返す）
避けるべき Title
- Bug found — 何のバグか分からない
- Login not working — どこがどう動かないのか不明
- Help! Urgent! — 感情語で具体性なし
頻出フレーズ
- not working / broken / fails — 動かない
- incorrect / wrong / unexpected — 値が違う
- missing / not displayed — 表示されない
- crashes / freezes / hangs — クラッシュ・固まる
- throws error / returns 500 — エラーを出す
3. Steps to Reproduce の書き方
再現手順は、別の人がコピペで再現できる粒度で書きます。「ログインして〜」のような曖昧な書き方ではなく、具体的なクリック・入力を箇条書きにします。
良い再現手順の型
1. Go to https://example.com/login
2. Enter test@example.com and password "test123"
3. Click "Sign in"
4. Click "Account" in the top right
5. Observe the error
動詞のテンプレ
- Go to [URL] — 〜に行く
- Click on [button name] — 〜をクリック
- Enter [value] in [field name] — 〜に〜を入力
- Scroll down to [section] — 〜までスクロール
- Wait for [event] — 〜を待つ
- Observe / Notice [what happens] — 〜を観察する
動詞の現在形で書く
英語の再現手順は命令形・現在形で書きます。"I clicked"（私はクリックした）ではなく、"Click"（クリックする）。日記ではなく手順書のスタイルです。
条件分岐がある場合
- Note: This only happens when [condition].（条件: 〜の時のみ発生）
- Reproduces 100% of the time on Chrome, intermittent on Firefox.（Chrome では 100% 再現、Firefox では断続的）
4. Expected vs Actual の伝え方
このセクションは「何が問題か」を明確にするためにあります。手順だけ書いても「で？何が悪いの？」となるので、必ず Expected と Actual を分けて書きます。
標準フレーズ
- Expected: The user should be redirected to the dashboard.（期待: ダッシュボードにリダイレクトされるはず）
- Actual: The page shows a 404 error.（実際: 404 エラーが表示される）
もう少しフォーマルに
- Expected behavior: 〜（期待される動作）
- Observed behavior: 〜（観察された動作）
- What should happen: 〜（本来こうなるべき）
- What actually happens: 〜（実際こうなる）
頻出パターン
- The button should be enabled, but it remains disabled.（ボタンが有効になるべきだが、無効のまま）
- The API should return 200 with the user data, but it returns 401.（API は 200 とユーザーデータを返すべきだが、401 を返す）
- Form validation should reject empty input, but it accepts it.（フォームバリデーションは空入力を拒否すべきだが、受け入れている）
"should" を多用するのが鉄則。「あるべき姿」を明確にしないと、エンジニア側は「仕様？バグ？」の判断ができません。
5. Environment と Screenshots の書き方
環境情報を書かないと、エンジニアは再現できずに「Cannot reproduce」で Close する可能性があります。
Environment セクションの標準項目
- OS: macOS 14.4 / Windows 11 / iOS 17.5
- Browser: Chrome 124.0.6367.119
- App version: v2.3.1 (build 4567)
- User role: Admin / Free user / Trial
- Network: WiFi / 4G / VPN on
頻出フレーズ
- Tested on Chrome and Safari, both reproduce.（Chrome と Safari で再現確認済み）
- Only happens on iOS, Android works fine.（iOS のみ発生、Android は問題なし）
- Cannot reproduce in incognito mode.（プライベートブラウジングでは再現せず）
スクリーンショット・ログ添付の言い回し
- See attached screenshot.（添付スクリーンショット参照）
- Console error: 〜（コンソールエラー: 〜）
- Full stack trace attached as bug-trace.txt.（スタックトレース全体を bug-trace.txt として添付）
- Network tab shows 500 response from /api/users.（ネットワークタブで /api/users から 500 応答を確認）
6. Severity と Priority の使い分け
英語のバグレポートでは Severity（深刻度）と Priority（優先度）を分けて伝えることが多いです。混同するとエンジニアの判断が狂います。
Severity — バグそのものの深刻さ
- Critical / Blocker — システムが使えない、データ損失
- Major / High — 主要機能が動かない、回避策なし
- Minor / Medium — 一部機能が動かない、回避策あり
- Trivial / Low — 表示崩れ、誤字
Priority — 直す優先度（ビジネス判断）
- P0 / Urgent — 今すぐ修正
- P1 / High — 今スプリント内
- P2 / Medium — 次のリリースまで
- P3 / Low — 余裕がある時に
伝え方の例文
- Severity: Critical — production is currently down for all users.（深刻度クリティカル、本番が全ユーザーで停止中）
- Severity: Minor, but Priority: High — affects our biggest customer's demo tomorrow.（深刻度は低いが優先度は高、明日の主要顧客のデモに影響）
- Low priority, but worth fixing for polish.（優先度は低いが品質向上のために直したい）
7. エンジニアが対応しやすい書き方のコツ
同じバグでも、書き方ひとつで対応速度が変わります。エンジニア側に立った書き方を意識しましょう。
仮説を添える（推測・原因の候補）
- I suspect this might be related to the recent deploy on May 20.（5/20 のデプロイと関連していそうな気がします）
- This could be a caching issue — clearing cache resolves it temporarily.（キャッシュ問題かもしれません、クリアで一時的に解決します）
- Might be a race condition — happens more often under load.（レースコンディションの可能性、負荷時に多発します）
回避策を共有する
- Workaround: Refresh the page twice and the issue goes away.（回避策: 2 回リロードで解消）
- For now, users can use the mobile app to bypass this.（当面、モバイルアプリで回避可能）
影響範囲を明示
- Affects all paid users on the Pro plan.（Pro プランの全有料ユーザーに影響）
- Roughly 50 users have reported this in support tickets.（サポートチケットでおよそ 50 名から報告あり）
断定しすぎない
"This is broken!" と書くより、"It seems to be broken — could you take a look?" のように柔らかく書く方がエンジニアの心象が良く、対応も丁寧になります。
英語バグレポート力を鍛える練習法
ステップ1：GitHub Issues の英語良例を観察する
有名 OSS（React, Vue, Kubernetes など）の Issues を読むと、ネイティブのエンジニアがどう書いているかが学べます。"Steps to reproduce" "Expected vs Actual" の粒度を真似ると、自分の書き方が一気にレベルアップします。
ステップ2：Sentence Builder で短文の組み立てを反射的に
当サイトのSentence Builderで、SVO 構造を瞬時に組み立てる訓練をすると、"The button should be enabled" のような typical bug report 文が反射的に出るようになります。
ステップ3：Speaking Instant で技術系定型を瞬発的に
Speaking Instantの business カテゴリで "It doesn't work" "Could you take a look?" "I think this is a bug" のような口語的フレーズを反復すると、Slack でのバグ報告にも応用できます。
ステップ4：オンライン英会話で「障害報告ロールプレイ」
オンライン英会話で「私が今バグを発見したシナリオで、講師に英語で報告する」というロールプレイをすると、書き言葉と話し言葉の両方が鍛えられます。受け放題プランで毎日 5〜10 分繰り返せば、英語チャットでの瞬発力がつきます。
英語バグレポートの瞬発力を、毎日のレッスンで鍛える
英語のバグレポートは「短く・具体的に・構造化して」が原則です。この感覚は、毎日少しずつ英語ネイティブとやり取りすることで身につきます。受け放題プランで 5〜10 分の短いレッスンを積み重ね、技術トピックを英語で説明する練習を繰り返すと、Slack でも Jira でも瞬時に手が動くようになります。
まずは 7 日間の無料体験で、英語でのトラブル共有・状況説明を試してみるのがおすすめです。
本記事はアフィリエイト広告を含みます。