今回やること
エラー調査で大事なのは、最初から答えを当てることではありません。
何が起きたかを、他人が再現できる形に整理することです。
この記事では、質問前に集める情報と、貼るテンプレートを整理します。
まず見る場所
Webのエラーでは、まず次を見ます。
| 場所 | 見るもの |
|---|---|
| 画面 | 何が起きているか |
| Console | JavaScriptエラー |
| Network | 通信、status、Response |
| Elements | HTML/CSSの状態 |
| Application | localStorage、Cookie |
全部を毎回見る必要はありませんが、画面だけで判断しないことが大切です。
質問テンプレート
## やりたいこと
例：問い合わせフォームを送信したい
## 起きていること
例：送信ボタンを押すと「送信に失敗しました」と出る
## 期待する動き
例：送信後に完了メッセージを表示したい
## 再現手順
1. /contact を開く
2. フォームに入力する
3. 送信ボタンを押す
## Consoleのエラー
```text
ここにエラー文を貼る
```text
## Networkの情報
- Request URL:
- Method:
- Status:
- Response:
## 該当コード
```js
ここに関係するコードを貼る
```text
## 試したこと
- パスを確認した
- console.logで値を見た
- Networkでstatusを見た
やりたいこと
最初に「何を作ろうとしているか」を書きます。
悪い例:
動きません
よい例:
Todoアプリで、削除ボタンを押したら該当行を消したいです。
目的が分かると、回答者は正しい方向で見られます。
起きていること
実際に起きていることを書きます。
例:
- ボタンを押しても何も起きない
- 404が出る
- ConsoleにTypeErrorが出る
- APIは200だが画面に表示されない
「おかしい」ではなく、観察できる事実を書きます。
ConsoleとNetwork
Consoleのエラーは全文を貼ります。
TypeError: Cannot read properties of null (reading 'addEventListener')
at main.js:12:8
Networkでは、最低限これを見ます。
- Request URL
- Method
- Status Code
- Response
API相談では、Responseに原因が書かれていることが多いです。
試したこと
試したことを書くと、同じ確認を繰り返さずに済みます。
例:
- セレクタ名を確認した
- ファイルパスを確認した
console.logで値を見た- Networkで404を確認した
- 別ブラウザでも試した
「何もしていません」でも、正直に書いた方が次の手順を出しやすくなります。
貼ってはいけないもの
秘密情報は貼りません。
- APIキー
- パスワード
- Cookie
- 認証トークン
.envの値- 個人情報
必要なら、値を伏せます。
Authorization: Bearer ***masked***
注意: エラー調査のためでも、秘密情報をそのまま貼らないでください。再発行が必要になることがあります。
まとめ
エラー調査では、やりたいこと、起きていること、期待する動き、再現手順、Console、Network、該当コード、試したことを整理します。
テンプレートに沿って質問すると、AIにも人間にも伝わりやすくなり、原因に早く近づけます。
次に読む記事
調査依頼の品質を決める情報
調査する開発者に必要なのは長い背景説明ではなく、同じ現象へ到達できる識別情報です。対象画面、buildやcommit、browser、利用者role、data ID、発生時刻とtimezoneを揃えます。秘密値そのものは不要です。
| 症状 | 添える証拠 | 書かない表現 |
|---|---|---|
| clickしても無反応 | Console先頭エラー、操作順 | 「何もしていない」 |
| API結果が空 | URL、method、status、response概要 | 「APIが壊れた」 |
| 特定accountだけ | role、対象ID、正常accountとの差 | 「たまに起きる」 |
| deploy後だけ | commit、環境、初回時刻 | 「前は平気だった」 |
期待動作は「成功するはず」ではなく、どの仕様に基づき何が表示・保存されるかを書きます。 実際の結果と推測した原因は別欄にします。
テンプレートの確認方法
提出前に、別の人が環境と入力を選び、手順番号だけで現象へ到達できるか読み返します。再現率が毎回でないなら、10回中何回、どのaccount、どの時刻帯かを記録します。試したことには変更内容だけでなく結果も添え、元へ戻したかを明記します。
スクリーンショット、HAR、logにはCookie、Authorization、メール、個人データが入り得ます。必要箇所をテキスト化し秘匿します。良い依頼の完成条件は原因を当てることではなく、次の担当者が観測を再開できることです。
参考リソース
ケース：特定の受講生だけ課題一覧が空
報告には受講生IDを秘匿した識別子、role、course、対象月、発生時刻、画面URL、buildを添えます。正常accountとの差は個人情報ではなくroleやdata有無で示します。
手順には初期dataを含めます。「課題が一件ある受講生としてloginし、対象月を選び、一覧を開く」と番号を振ります。期待は「一件のtitleと期限」、実際は「empty表示、GETは200、responseは空配列」のように書きます。
これで描画が落ちたのではなく受信配列が空だと分かりますが、API原因は未確定です。query、course紐付け、timezone境界を次候補にします。試したことは操作と結果を対にし、再現しない担当者はbrowser、role、data、buildの差を表へ追加します。
再現しない問題の記録方法
「時々」で終えず試行回数と失敗数を書きます。初回表示、放置後、別tab復帰後など操作間隔も含めます。通信速度、online遷移、省電力状態も条件になり得ます。時刻はserver logと照合できるtimezoneで残し、request IDがあれば添えます。
修正案は仮説欄へ置き、どのresponseが支持するかを書きます。反証結果も残し、同じ試行の繰り返しを防ぎます。該当しない欄は該当なし、不足は未確認と明記します。推測で欄を埋めるより、未取得の観測が分かる記録が役立ちます。
UI以外のエラーに合わせる
CLIの失敗なら実行command、working directory、exit code、標準出力と標準errorを分けます。長いlogは最後だけを貼らず、最初のerrorと直前のcommandを含めます。package managerではruntime、package manager、lockfile有無、install方法を記録します。秘密を含む環境変数は値でなく変数名と設定有無だけを共有します。
build失敗ならlocalとCIの差を表にします。OS、runtime version、依存install command、cache、対象commitを比較します。「CIだけ失敗」から権限や環境変数が原因と断定せず、logに現れた最初の失敗stepを起点にします。後続stepのskipは原因ではありません。
性能問題では「遅い」を秒数へ変えます。開始操作、完了条件、測定回数、中央値、data量、network条件を残します。memory問題では増加量と操作回数、解放後の状態を記録します。機能error用のConsole欄を無理に埋めず、その症状に近い計測へ置き換えます。
security問題を公開issueへ詳細掲載しません。再現手順が攻撃方法や個人dataを含む場合は、projectのsecurity policyに従って限定経路へ報告します。templateより情報開示境界を優先します。
引き継ぎ時の完了条件
調査途中で渡す時は、確定した事実、否定済み仮説、未確認項目、次に実行する一手を分けます。branchや一時logがあるなら場所と削除予定を記します。担当者名だけでなく、判断に必要な権限や環境も明記します。
修正後は元の手順で期待結果になった証拠をissueへ追記します。原因説明、変更箇所、確認環境、回帰確認を短くまとめます。単にPR linkを貼るだけでは、後から同じ症状を検索した人が判断できません。error messageやrequest IDなど検索可能な語を残しつつ秘密値は伏せます。
再現しなかったまま閉じる場合も理由を明確にします。観測期間、試行回数、追加したmonitor、再発時に採取する情報を記録します。「直ったようなので終了」ではなく、次回は何が増えるかを決めて調査可能性を上げます。
← 一覧に戻る
