【脱・行き詰まり】不具合調査で途方に暮れないために、3年間で培った思考法と全フロー

トラブルシューティング

熊代風人

2026年06月17日

はじめに

この記事では、自分が携わってきた案件にて過去3年間に培った、「不具合調査・修正で気をつけていること」について、整理と備忘録を兼ねてまとめています。

新卒で何もわからなかった頃に先輩方から教わったこと、自身の失敗から学んだことが基になっています。

あくまで個人の考えですが、少しでも参考になれば幸いです。

この記事の対象者

不具合修正に行き詰まった方
初めての不具合調査 or 修正対応で、何をすれば良いか分からない方

必ずやるように気をつけていること

この項目では、不具合調査・修正の種別に関わらず実施していることについて、4つ記載しています。

不具合調査・修正対応の経験があまり無い方は、ぜひチェックしてみることをおすすめします！

まず不具合を再現させる

不具合調査を開始する際、まずは不具合が再現するかどうか手元で確認をします。

本番環境・検証環境で確認するほか、ローカルマシンでアプリケーションの立ち上げ・動作確認ができる場合は、そちらでも試すことを推奨します。

再現することを確認できたら、正しいスタートラインに立てています。この作業１つで、不具合調査はグッと楽になります。

自分はプロジェクトのアサイン直後、不具合調査の際にまずソースコードを読むことが多く、原因箇所の特定に時間がかかっていました。

ソースコードを読むことも大切ですが、様々な条件を設定しながら実際に動かす方が近道です。

もし、Issueに記載されている再現手順を試しても不具合が再現しなかった場合、下記のような原因が考えられます。

再現手順の考慮漏れのケース。見落としがあるため、条件を少しずつ変えて試したり、不具合の発生状況について詳しくヒアリングする必要がある。

特殊な環境に依存する不具合のケース。手元での不具合再現が困難なため、不具合の発生状況について詳しくヒアリングする必要がある。

手元で実際に動かせば状況把握も容易になりますので、その他の調査をする前にまず実施してください。

事象が不具合なのか、仕様なのか確認

不具合として報告された事象だとしても、その挙動が仕様なのか必ず確認するようにしています。

より正確に言いますと、どこまでが仕様でどこからが不具合なのか、区別して切り出します。

例えば、不具合の原因となっている条件式を「仕様変更の際の削除漏れ」と判断して削除したところ、実はその条件式の一部が別の箇所で使われており、他顧客に影響が出た、なんてこともあります。

仕様か不具合か区別して切り出すと、下記のパターンに分類されます。

報告された事象が不具合（通常パターン1）：
- 「意図しない挙動」なので修正対象。
報告された事象が仕様（通常パターン2）：
- 「仕様」なので、該当箇所の仕様書を添えて報告。

一部は不具合で、一部は仕様（切り分けが重要なパターン）
- 仕様書をもとに慎重に切り分ける。

中には、仕様か不具合か判別が難しいパターンもあります。

自分が遭遇した例として、下記のようなものが挙げられます。

削除されず残っていた古い仕様が起因（ソースコード上では仕様に見える）：
- 古い仕様の削除が意図的だったケース。「仕様変更の際の削除漏れ」なので、修正対象となる。
古い仕様が他コードの影響により消えていたが、昨今の修正により復活していた：
- 古い仕様の削除が意図的ではなかったケース。この場合は経営判断に委ねる。

大切なのは、特定のケースだけを考慮して修正を始めるのではなく、報告された事象の全容を把握することです。
ケース数があまりにも多い場合は、マトリクス表などを用いて整理すると非常に便利です。

不具合の再現手順の最適化・他手順の模索

不具合の原因が分かったら、再現手順から不必要なステップを削除して最適化を進めたり、再現手順が他にないかを確認します。

根本原因がはっきりすると、関係しない箇所が浮き彫りになったり、逆に同じような不具合が発生しそうな箇所・操作手順が見えてくると思います。
この過程を踏むことで、原因の根拠を裏付けることができたり、思わぬエラーに遭遇することができます。

また、この段階で不具合の再現方法を整理しておくと、検証段階のテストケースの網羅にも役立ちます。

修正案は複数提示

不具合の原因が特定できて修正案を提示する際は、1つではなく複数提示するように心がけています。

出来るだけ早く対応が完了する速度重視の案と、同様の不具合が発生しないよう根本解決するコード品質重視の案のように、最低でも2つ提示するように心がけると良いです。

同じ不具合であっても、案件状況や対象の不具合の深刻度合いなどによって、その場での最適な対応は異なってきます。
事前に温度感をヒアリングすることは大前提ですが、顧客の求める対応ができるよう対応案を複数用意しておくとスムーズです。

後々に役立つ、やって良かったこと

この項目では、チームとの連携やより高品質なコードの提供など、付加価値を出すために実施していることについて3つ記載しています。

不具合調査・修正に慣れてきた頃に試してみるのが効果的です。

調査記録を残す

不具合の原因調査や対応方針の検討の際は、調査記録を取りながら実施することを強く推奨いたします。

調査が長引くと目的を見失い、何について調査していたのか分からなくなることが度々ありました。

適度に記録を残すことで、現在の進捗を整理して効率よく調査を進めることができます。

具体的には、下記のような内容です。

現時点で分かっていること、分からないこと
調査するところ、調査しないところ（スコープ外）
調査の結果、分かったこと、分からなかったこと
調査結果をふまえた考察

また、調査結果がそのタスクで活かせなかったとしても、後々のタスクで役立つこともあります。他にも、調査の進捗状況をチームに共有しやすくなる、という利点もあります。

サイトURLを添付するだけの簡単なものから始めてみるのはいかがでしょうか？

不具合の原因・背景から横展開調査

不具合の原因が他箇所にも波及している可能性がある場合は、横展開調査を実施するのが効果的です。
ここでの「横展開調査」とは、「検出したエラーの原因に着目し、それと同じ特徴をもつエラーを洗い出すこと」を指しています。

対象の不具合がフレームワークやライブラリ、ブラウザ、OSなどのアップデートが起因の場合は特に重要です。

対象不具合と同様の処理が行われている箇所について検証・修正を実施したり、アップデート内容の中で影響しそうな項目を網羅的に調査すると良いかと思われます。

未発覚の不具合（潜在バグ）に顧客が遭遇する前に解消できるので、提供品質の向上に寄与します。

不具合発生パターンをテストケースに追加

不具合修正に合わせて、該当不具合を再現するテストケースを追加することをおすすめします。

これはテスト駆動開発の手法ですが、まず不具合によって失敗するテストケースを追加し、テストを実行して該当ケースが失敗することを確認します。（レッド）

この確認の後に不具合を修正してテストケースが成功すれば、施した差分によって不具合が解消されたと証明できます。（グリーン）

テストケースが十分にあるプロダクトであれば退行を検知することもできるので、コード品質を高めたいのであれば有効なテクニックです。

注意点として、対象の不具合が過度なエッジケースでテストケースが変更によって壊れやすくなる場合など、追加しない方が良いこともあります。要注意です。

不具合調査に役立つテクニック

ここからは、過去に自分が実施した不具合調査・修正対応の際に役立ったテクニックについて、いくつか紹介します。

状況次第ではありますが、行き詰まった時などにぜひ試してみてください！

ログを確認する

アプリケーションのログが確認できる場合は大いに活用しましょう！

エラーログやインフォログを通して、実際に行われた処理を把握できれば調査も進めやすくなります。

アプリケーションの状態が把握しにくい場合は、デバッグログを仕込んで状態を可視化する方法が有効です。

特定顧客でのみ発生するような特殊な不具合であっても、本番環境のログを調査することで解決に至るケースもあります。

監査体制が整っているプロダクトに限定される話ではありますが、ソースコードの調査だけでは限界があるので、デバッグができない環境では特に活用することを推奨します。

過去事例を調査

ネット上の調査で行き詰まった時は、プロダクトの中で似たような過去事例が無いか、また過去にどのような変更があったのか調査してみましょう！

これは長く運用されているプロダクトで、何度も変更が行われているコードでは特に有効です。

過去に同様の不具合が起こっていた場合、起因が別でも対応方針や調査ログが不具合解消のヒントになることもあります。

プロダクト特有の実装・構成が起因の不具合は珍しくないので、長く携わっている他開発者に相談してみると案外早く解決するかもしれません。

また、不具合の原因と思われるコード箇所を特定できても、該当箇所のコードが難解で実装意図が読めないケースもあります。

過去に遭遇した例として、特定の条件で意図しない動作となる原因がif文にあると分かっても、その条件式が複雑難解でどこまで仕様なのか分からない、といったケースがありました。

このようなコードは、度重なる機能追加や仕様変更、速度重視の不具合修正が原因であることが多いので、コミット履歴などから実装意図を読み解いていくと、適切な対応につながります。

システム言語を英語に変更

少し趣旨とずれますが、エラーメッセージが日本語で表示されるケースで、ネットで調べても情報が得られない際は、システム言語を日本語から英語に変更すると有効な場合があります。

状況としては稀ですが、OSやブラウザ起因のエラーの場合が該当します。

英語のエラーメッセージであればヒットすることがありますので、行き詰まった時は試してみてください。

大まかな不具合調査・修正のフロー

以上を踏まえ、自分が不具合調査・修正を実施する際の大まかなフローをまとめてみました。

不具合報告を基に、手元で不具合が再現するか確認する
- 再現しない場合、条件について追加でヒアリングしたり、他開発者を頼る
アプリケーションの仕様と該当不具合を比較し、仕様と不具合を切り分ける
- 仕様の誤認だった場合、報告した上で対応終了、または機能改善
- この段階で切り分けが難しい場合、原因特定後に改めて実施する
不具合の原因を調査する
- 始めは例外が発生していないか調査することが多い
- デバッグやログを用いて事実を一つずつ確認することを念頭に調査する
不具合原因から対応方針を検討する
- 工数・コード品質を考えながら複数案出す
- 実現可能か不安な場合は、最小限のコードで実装できることを確認しておく（PoC）
不具合解消の検証方法をまとめる
- ローカル環境で検証が難しい場合、検証段階をどうするか検討しておく
工数を割り出し、対応方針を比較検討し決定する
- 急ぎの対応でコード品質を高めたい時、Phaseを分けることも考える
不具合の修正対応を実施する
- 不具合発生のテストケース追加→コード修正→修正の確認という手順で進めることが多い
不具合が修正されていることを検証する
- 複数の環境で段階的に検証すると思うので、プロダクトごとのフローに沿って進めること
- 通常のフローで検証が難しい場合は5の検証方法検討の段階で相談しておくとスムーズ
修正対応をリリースする
- リリース時の検証も担当する場合、検証用のデータやアカウントを用意するなど、準備を進めておくと良い
今後に向けて
- 横展開調査で不具合箇所を見つけた場合は報告・起票する
- その他、反省点などあればチームに共有、振り返る