利用者からの不具合報告を手元に、自分の画面では正常に動くシステムを前にして落ち着いて条件の違いを考えている一人運用の保守担当者
保守・改修約12分

「再現しない」バグの調べ方｜環境とタイミングを疑う順番

「たしかにエラーが出ました」という報告。でも自分の画面で同じ操作をすると、何度やっても普通に動く——。 保守運用をしていると、この「再現しないバグ」に何度もぶつかりますよね。相手は困っている。でもこちらは症状すら見られない。そのうち「自分の確認が甘いのかも」「本当は自分のミスなのに気づけていないのかも」と、だんだん自分を疑い始めてしまう。あの宙ぶらりんな時間、地味に消耗します。

でも、再現しないバグの正体は、あなたの調べ方が下手だからではありません。「動く自分の環境」と「エラーが出る相手の環境」で、何かの条件が違っているだけです。その条件を1つずつ合わせにいけば、たいていの「再現しない」は「再現する」に変わります。

この記事では、再現しないバグに出会ったとき、やみくもにコードを読む前に、どの条件から疑って合わせにいくかの順番を一緒に整理します。全部を一度に調べるのではなく、当たりやすいところから手をつける話です。

結論：まず「いつ・どの画面で・どんな結果になったか」を具体的にそろえることから始めます（推測で再現しようとしない）。そのうえで、①データ（対象レコード・入力値）→②利用者の条件（権限・ブラウザ・端末）→③タイミング（時間帯・同時操作・順番）→④環境差（本番だけ・特定サーバーだけ）の順に、自分の環境を相手に近づけていきます。再現できた瞬間に、原因はほぼ半分見えています。焦って直そうとせず、「まず自分の手元で1回起こす」ことをゴールにします。

再現のしやすさは、システムの作り（1台構成か複数台か、キャッシュやキューを使うか）で大きく変わります。順番と考え方を出発点に、自分の現場の道具に置き換えて使ってください。

何が起きているか：再現しないのは「条件が隠れている」から

再現しないバグがやっかいなのは、症状が嘘だからではなく、再現に必要な条件が報告に含まれていないからです。報告する人は悪気なく「エラーが出た」としか言えないことが多く、その裏にある「そのとき何が違ったか」は本人も気づいていません。

つまり必要なのは「気合いで何度も操作する」ことではなく、隠れている条件を1つずつ表に出して、自分の環境に持ち込む目です。次から、その順番を見ていきます。

再現の条件を合わせにいく4つの層

データ・利用者・タイミング・環境の4つの条件を順に自分の環境へ合わせて再現を狙う流れ図
「データ→利用者→タイミング→環境」の順に条件を合わせる。当たりやすい手前から一つずつ

大事なのは、当たりやすくて調べやすい条件から先に合わせることです。多くの「再現しない」は、実は①データか②利用者の条件で片づきます。いきなり③タイミングや④環境差といった難しい層から疑うと、時間だけが溶けていきます。

① まず「データ」を疑う（対象レコード・入力値）

最初にやるのは、コードを読むことではなく、エラーが出たときの「実物のデータ」を見にいくことです。ここで原因が割れるケースが、驚くほど多いです。

ここで特定のデータでだけ再現するなら、犯人はデータ（またはその値を想定していない処理）です。奥の層は触らなくて大丈夫。逆に、どのデータでも再現しないなら、条件はもっと別のところにあります。次の②へ進みます。

ここで一呼吸。「自分では再現できない」時間は、腕を疑う時間ではなく、条件をそろえる時間です。まだ症状を見られていないのは、あなたの落ち度ではありません。

② 利用者の条件を疑う（権限・ブラウザ・端末）

データで再現しないなら、次は「誰が・何で」見ているかです。同じ画面でも、その人の状態によって通る道が違うことがあります。

ここでも、相手の条件に一つ近づけるごとに、同じ操作をなぞって確かめるのがコツです。一度に全部変えると、何が効いたのか分からなくなります。

③ タイミングを疑う（時間帯・同時操作・順番）

データも条件もそろえたのに、それでも再現しない——ここから少し難しい層です。「そのときだけ」重なった何かを疑います。

この層は、ログのタイムスタンプを突き合わせるのが有効です。エラーが出た時刻の前後で、ほかにどんな処理が動いていたかを並べて見ると、「重なり」が見えてきます。

④ 環境差を疑う（本番だけ・特定サーバーだけ）

最後は、環境そのものの違いです。手前を全部そろえても検証環境で再現しないなら、ここを疑います。

この層に来たら、本番を直接いじる前に、まず観測を増やすのが安全です。再現できないものを勘で直すと、直ったかどうかも確かめられません。まずは「次に起きたときに原因が分かる」状態を作ることを優先します。

具体例：「特定のお客様だけ、注文完了でエラーになる」

よくある報告で、順番に条件を合わせてみます。

犯人は「データ」でも「タイミング」でも単体ではなく、②の利用者条件（特別割引ランク）を入り口に、③の重なり（クーポン併用）で顔を出す組み合わせでした。もし最初からコードを読み込んでいたら、どの分岐を追えばいいか分からず迷子になっていたはずです。手前から条件を合わせて「まず1回再現させた」からこそ、読むべき場所が一気に絞れました。

影響：再現の順番を持つと、何が変わるか

再現の切り分け順を1枚持っておくと、直す力そのものより先に、焦りと自己否定が減ります。

逆に、順番を持たずに毎回「とりあえず操作を繰り返す」だけだと、たまたま出た日と、丸一日出せずに終わる日の差が大きくなります。順番は、宙ぶらりんな時間を短くする道具です。

明日やること：再現できないバグの「条件メモ」を1枚作る

立派な調査書は要りません。明日できる、いちばん小さな一歩はこれです。

  1. いま抱えている（または次に来た）再現しないバグについて、報告から分かる事実だけを書き出す（誰が・いつ・どの画面で・どんな結果）。
  2. 上の①データ→②利用者→③タイミング→④環境の順に、「まだ確かめていない条件」に印を付ける。
  3. いちばん手前の未確認から、一つだけ条件を合わせて同じ操作をなぞる。
  4. 変えた条件と結果（再現した／しない）を1行ずつ記録する。何を試したか残すと、同じ確認を二度しない。
  5. 再現できたら、そのときの条件をそのまま「再現手順」としてメモに残す。原因調査も引き継ぎも、ここから一気に楽になります。

きれいにまとめなくて大丈夫です。「どの条件を試して、どうだったか」の1枚があるだけで、次の自分（や相談する相手）が、同じ場所を手探りせずに済みます。

「再現しないバグ」チェックリスト

調査に着手するとき、これだけ確認できているかを見る項目です。コピーして、自分のメモに当ててみてください。全部を毎回そろえる必要はありません。

まず外せない最低ラインはこの3つです。焦っていても、ここだけは押さえます。

次の項目は、手前で再現しないとき・原因が条件の重なりにあるときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「実物のデータを1件見にいく」さえ押さえられれば、自分を疑って消耗するより、ずっと確かな一歩になります。

よければ、こちらも

再現しないバグは、「まず1回起こす」ところまで来れば、あとは原因調査の技が効いてきます。再現後の原因特定と、本番でしか出ない不具合を捕まえる備えをセットにしておくと、次の「再現しない」がだいぶ軽くなります。

合わせるべき条件を突き止めて手元でバグを再現でき、原因の見当がついて肩の力が抜けた保守運用の担当者

再現しないバグがこわいのは、症状が見えないまま、自分の力を疑い始めてしまうからです。でも、①データ→②利用者→③タイミング→④環境の順に条件を合わせると決めるだけで、霧はかなり晴れます。多くの場合、あなたの調べ方は正しくて、ただ隠れた条件がまだそろっていなかっただけです。 今日は、抱えている再現しないバグの「条件メモ」を1枚書いてみるところからで十分です。その1枚が、次の「再現しない」を、宙ぶらりんな時間ではなく手順に変えてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語