「ローカルでは動く」を4軸で切り分ける
「私の環境では動くんですが」——このひとことから始まる調査は長引きやすい。バグ報告と自分の手元の間には、環境変数・データ・ブラウザ・タイミングという4つの軸の差分が隠れていることが多く、闇雲に再現を試みると同じ質問の往復だけで時間が溶ける。この記事では、この4軸を機械的にチェックする切り分け手順をまとめる。
なぜ「自分の環境では動く」が起きるのか
再現しないバグの原因は、たいてい次の4つのどれかに収まる。
- 環境変数: フィーチャーフラグ、APIのURL、タイムゾーン設定の違い
- データ: 相手の手元にだけ存在する空データ・古いフォーマット・権限の違い
- ブラウザ/クライアント: 拡張機能、キャッシュ、画面サイズ、OSのフォント
- タイミング: ネットワーク遅延やレースコンディションによる非決定的な挙動
この4軸を順番に潰していけば、勘に頼らず原因の当たりがつけられる。
1. 環境変数の軸
まず自分の環境と相手の環境で設定差分がないかを確認する。
diff <(env | sort) remote_env.txtで環境変数を機械的に比較する- フィーチャーフラグの有効/無効を確認する（ONだけ／OFFだけで通るケースが多い）
TZとロケール設定を確認する。日付境界のバグはここが原因のことが多い
2. データの軸
「そのデータだから起きる」パターンを疑う。
- 対象レコードが空配列・null・0件のときの挙動を確認する
- 文字コードや全角/半角混在など、フォーマットが古いデータが混ざっていないか確認する
- 報告者と自分のアカウントで権限（ロール・プラン）が違わないか確認する
3. ブラウザ/クライアントの軸
- シークレットウィンドウ、拡張機能を全無効化した状態で再現するか試す
- Service Worker やキャッシュを削除してから再読み込みする
- 画面幅・DPR（デバイスピクセル比）を報告環境に合わせる
4. タイミングの軸
- ネットワークをChrome DevToolsの「Slow 3G」に落として再試行する
- 連打・二重クリックなど、素早い操作でだけ起きないか試す
- 非同期処理の完了順序に依存した箇所がないか、コードを疑う
実例: 「ボタンが押せない」の正体が回線速度だった話
ある報告では「送信ボタンを押しても何も起きない」という内容だった。開発者の手元では即座に成功する。上の4軸で切り分けたところ、環境変数・データ・ブラウザは一致。残る「タイミング」の軸でネットワークをSlow 3Gに落として再試行したところ、送信中に二重にボタンを押すとリクエストが競合し、後発のリクエストがエラーで握りつぶされていることが判明した。原因はボタンの二重送信防止処理が入っていなかったことで、修正は送信中のボタンをdisabledにするだけで済んだ。4軸を順番に潰していなければ、「ブラウザ依存の表示バグ」を疑って見当違いの調査をしていたかもしれない。
切り分けフローチャート
調査に入る前に、次の4つの質問を順番に投げるだけで、多くのケースは軸が絞れる。
- 環境変数・フィーチャーフラグは一致しているか？（一致 → 2へ）
- 同じデータ（同じレコード・同じアカウント）で試しているか？（一致 → 3へ）
- 同じブラウザ・同じ画面サイズで再現するか？（一致 → 4へ）
- 連続実行や遅い回線でだけ起きないか？
4つとも一致しているのに再現しない場合は、報告者側の一次情報（コンソールログ・ネットワークログ・操作手順）が不足している可能性が高い。
Bugoon での実践
Bugoon はウィジェットから送られたバグ報告に、スクリーンショットとアノテーション、操作ステップの記録を自動で添付する。操作ステップが残っていれば「タイミング」軸（何をどの順番でクリックしたか）の切り分けはその場で済む。GitHub Issue連携で開発者に渡す際も、この情報がそのままIssue本文に載るため、環境変数やデータの軸を確認する質問を1往復減らせる。
報告に環境名・ビルド番号・ブラウザ情報・画面サイズといったメタデータまで自動で載るようになれば、4軸のうち「環境変数」「ブラウザ/クライアント」の初期確認がほぼ省略できる。現状はスクリーンショットとURL情報が中心だが、この方向性は切り分けの効率化として意味がありそうだ。