Claude Codeのバグ修正：症状から再現条件へ絞り込む

観察と解釈を別に記録する

「保存ボタンが反応しない」は観察ですが、「ネットワークの不具合」は仮説です。入力内容、押した順序、表示、保存先の状態を記録すると、画面の問題か通信か保存処理かを切り分けやすくなります。

環境や版も残します。特定の端末やデータでだけ起きる問題を、一般的なコードの誤りと同じ方法で扱わないようにします。再現しない場合も、その事実と条件を記録します。

仮説ごとに観察する差を決める

ボタンの無効化が原因なら、押下時の状態を確認します。送信が二重なら、要求の識別子を追います。ログを大量に追加する前に、どの観察で仮説が否定されるかを決めます。秘密や顧客の本文を無条件にログへ出す必要はありません。

一度に複数の修正を行うと切り分けが難しくなります。原因に関わる最小の変更を適用し、同じ入力と操作で再確認します。

周辺の正常動作を確認する

問題の入力だけでなく、通常の入力、境界の値、失敗時の復帰を確認します。たとえば保存時の二重処理を防ぐ修正で、失敗後に再送できなくなることがあります。問題が消えたかと、元の正常系を壊していないかを別々に見ます。

再現が消えた理由を説明できるか確認する

修正後に問題が出なくなっても、入力、データ、環境が同時に変わっていれば、修正の効果とは限りません。可能なら同じ条件で修正前後を比較し、原因に関する仮説が観察と合うかを確認します。再現が不安定な場合は、成功例だけを選ばず、試行条件と発生の有無を記録します。「今は動いた」という報告と、原因を特定した修正を区別します。

調査中に追加したログや一時的な回避策も確認対象です。問題を隠すために検証を通さない、失敗を無視する、権限を広げるといった変更は、症状を消しても原因の解消ではありません。最終的な差分に調査用の処理が残っていないかを読み、必要な観測だけを適切なデータ範囲で維持します。修正の影響と診断の影響を分けてください。

具体例で考える

架空のフォームで、素早く二回押すと二件登録されます。

再現：同じ入力を用意し、送信を連続して実行。
観察：要求IDと登録IDを対応させる。
修正候補：処理状態とサーバー側の重複防止。
回帰：失敗後の一回の再送が可能か。

ボタンを見た目だけ無効化しても、別経路からの要求は残ります。再現条件を保ったまま、画面側と保存側のどちらで守るかを決めます。

確認課題と合格の目安

最近の不具合について、事実、仮説、否定に使う観察、再現手順を分けてください。

• 原因を推測だけで確定していない。
• 修正前後で同じ条件を比較できる。
• 周辺の正常動作も確認している。