はじめに — その「直して」、たぶん半分はハズしてます

エラーが出る。真っ赤なスタックトレースをコピーして、AIにペタッと貼る。「これ直して」。

……このムーブ、僕もめっちゃやります。速いし、当たると気持ちいい。

でも、正直に言いましょう。当たり外れが、けっこう激しくないですか。

数字でも出ています。Lightrunの「2026 State of AI-Powered Engineering Report」（US/UK/EUの大企業のSRE・DevOpsリーダー200名調査、VentureBeat報道）では、AIが生成したコード変更の43%が、QAもステージングも通ったあとに、本番でもう一度手動デバッグが必要になったそうです。しかも、AIが出した修正を「1回の再デプロイ」で確定できた人はゼロ。88%が2〜3回、11%は4〜6回も直し直したと。

もうひとつ、生々しい研究があります。『How Coding Agents Fail Their Users』（arXiv:2605.29442, 2026-05）という論文で、実際の開発セッション20,574件を分析したところ、コーディングエージェントには共通のクセがあると分かりました。「調べる前に推測する（guessing rather than investigating）」、そして「根本原因に触れず、表層の対症療法を当てる（surface-level symptom fixes）」。

ここで大事なのは、これって「AIが賢くないから」じゃない、という点なんです。むしろ賢いからこそ、"それっぽい答え"を一瞬で出せてしまう。問題は頼み方のほう。「直して」という一言が、AIに推測を強要しているんですよね。

この記事は、その頼み方を根っこから変える話です。キーワードはひとつ。

推測させるな、観測させろ。

これ、実は新しい話じゃありません。デバッグの正しいやり方は、20年前にほぼ答えが出ています。今日はそれをAIと一緒に回す形に翻訳していきます。

なお、この記事が扱うのは「一件のバグを、自分の机で直す」開発デバッグの話です。本番障害の火消し（ログ集約・トリアージ・緩和・ポストモーテム）や、パフォーマンス改善（速さの計測）は、それぞれ別の型があるので、ここでは正しさ（correctness）のバグにしぼって話します。

まず、言葉をそろえましょう

無知の無知、つまり「知らないことすら知らない」状態で置いていかれるのが一番しんどい。なので、最初に用語を全部ざっくり定義します。分かる人は読み飛ばしてOKです。

バグ: プログラムが「こうあってほしい挙動」と違う動きをすること。エラーで落ちるだけじゃなく、"静かに間違った結果を返す"のもバグ。
再現（repro）: そのバグを、狙って何度でも起こせる状態にすること。「たまに起きる」を「必ず起きる」に変える作業。
スタックトレース: エラーが起きた瞬間の「関数の呼ばれ方の履歴」。事故現場に残ったブレーキ痕みたいなもの。
ログ / instrumentation（計器）: コードの要所に「今ここ通ったよ、変数はこの値だよ」と喋らせること。車のスピードメーターを後付けするイメージ。
根本原因（root cause）と対症療法（symptomatic fix）: 雨漏りで例えると、天井のシミを塗り替えるのが対症療法、屋根の穴をふさぐのが根本原因。塗り替えても、また滲みます。
回帰（regression）: 直したはずのバグが、あとでまた復活すること。あるいは、直した拍子に別の場所が壊れること。
回帰テスト（regression test）: 「このバグが二度と戻ってこないか」を自動でチェックし続けるテスト。踏んだ地雷に刺す「立入禁止」の札。
二分探索（bisect）: 「どのタイミングで壊れたか」を、範囲を半分ずつに割って絞り込む探し方。犯人を「前半にいる？後半にいる？」で追い詰める。

このへんの言葉が体に入ってると、AIへの指示もグッと具体的になります。

なぜ「直して」丸投げは半分ハズすのか

理由を、根性論じゃなく構造で見てみましょう。3つあります。

① 文脈が足りないと、AIは"それっぽさ"で埋める

AIはあなたのコードベース全体も、本番のデータも、その関数がどういう約束（契約）で呼ばれてるかも、基本的には見えていません。見えない部分は、学習データの「よくあるパターン」で補完します。だからエラー文だけ渡すと、"世間一般のよくある原因"を、自信たっぷりに埋めてくる。当たることもあるけど、あなたの現場の事情はガン無視です。

② AIは「動く」を最適化する。「原因」は頼まないと出てこない

「直して」と言われたAIのゴールは、「エラーが消えるコードを返すこと」になりがちです。エラーさえ消えれば、原因を理解していなくても、タスクは"達成"に見える。だから try/except でエラーを握りつぶす、if x is None: return を足す、みたいな「症状を消すだけ」の修正が平気で出てきます。動く。でも、直ってない。

③ 対症療法は一瞬速いけど、負債になる

②の修正は、その場では動くから気持ちいい。でも根本原因が生きてるので、少し違う条件でまた顔を出す。しかも、握りつぶした場所には「なぜここでNoneが来るのか」という問いが埋められたまま。半年後の自分（かAI）が、その黒魔術を前に固まることになります。

冒頭の研究（arXiv:2605.29442）が20,574セッションで見つけた「推測」と「対症療法」は、まさにこの①②③が現場で噴き出した姿なんですよね。モデルを賢いのに替えても、頼み方が"推測を促す形"のままだと、この構造は変わりません。

リフレーム：デバッグは「コード生成」じゃなくて「仮説の探索」

ここで発想を一段ずらします。

多くの人はデバッグを「壊れたコードを、正しいコードに書き換える作業」だと思ってる。だからAIに「書き換え」を頼む。でも、それは仕上げの一部でしかありません。

デバッグの本体は、「なぜ壊れているのか、その理由を突き止める作業」です。これは書く仕事じゃなくて、調べる仕事。もっと言うと、仮説を立てて、観測で確かめて、絞り込んでいく科学なんです。

実はこれ、ソフトウェア工学ではとっくに整理されています。Andreas Zellerの名著『Why Programs Fail: A Guide to Systematic Debugging』（2005）は、デバッグに科学的方法を持ち込みました。流れはシンプルで、

失敗を再現する
原因の仮説を立てる
仮説が正しいなら「こう観測できるはず」を予測する
実験して、予測が合うか確かめる
説明が固まるまで、仮説を修正して繰り返す

同じZellerの「Delta Debugging」（IEEE TSE 2002）という論文のタイトルが、デバッグの気分を完璧に表しています。曰く、「Yesterday, my program worked. Today, it does not. Why?（昨日は動いた。今日は動かない。なぜ？）」。

この"科学"のフレームに乗ると、人間とAIの役割がスッと決まります。

人間＝科学者。何がおかしいと感じるかを定義し、仮説を立て、「何を観測すれば決着がつくか」を決め、最後に修正を承認する。ここはWhat / Whyの領域。
AI＝めちゃくちゃ優秀な実験助手。ログやトレースを高速で読む、観測用のコードを書く、仮説を並べる、最小の修正差分を書く、回帰テストを書く。ここはHowの領域。

だから合言葉はこうなります。

推測させるな、観測させろ。

AIに「原因を当てて」と言うと推測ゲームになる。「この仮説を確かめる観測コードを書いて」と言うと、科学になる。同じAIでも、引き出すものが全然変わるんです。

デバッグの型：5つのステップ

科学的方法を、明日から手を動かせる5ステップに落とします。全体像はこれ。

① 再現(Reproduce)   失敗を必ず起こせる状態にする（失敗するテストを先に書く）
② 観測(Observe)     推測せず、事実を集める（ログ・トレース・二分探索）
③ 仮説(Hypothesize) 原因の候補を複数出し、確率順に並べる
④ 最小修正(Fix)     根本原因に、最小の差分で手を入れる
⑤ 再発防止(Prevent) バグを再現するテストを恒久化する（立入禁止の札）

そして、各ステップの人間とAIの分担をざっくり先に置いておきます。

ステップ     人間(What/Why)                     AI(How)
① 再現       何が「正しい」かを定義              MRE化・repro手順の整理
② 観測       どこを観測すれば決着するか決める    ログ差し込み・トレース読解
③ 仮説       仮説の妥当性を判断                  仮説を複数生成・確率付け
④ 最小修正   対症療法か根本かを見極め承認        最小diffの提案
⑤ 再発防止   何を守るべきかを決める              回帰テストのコード生成

ここから、1ステップずつ具体的にいきます。

Step1｜再現（Reproduce）：直す前に、まず「必ず落ちるテスト」を書く

デバッグで一番やりがちなミスが、再現できていないのに直し始めることです。再現できていないと、直ったのかどうかも確認できない。まぐれで消えたのか、本当に直したのか、区別がつかないんですよね。

なので最初にやるのは、修正じゃなくて「そのバグを踏む、失敗するテストを1本書くこと」。これがあると、直ったかどうかが「テストが赤→緑になったか」で機械的に分かります。

たとえば「割引計算が、特定の条件でマイナスになる」というバグなら、こう書きます。

# test_discount.py
# バグを踏むための「失敗するテスト」を先に書く（red）
from pricing import apply_discount


def test_discount_never_goes_negative():
    # 100円の商品に、150%割引という不正な入力が来たケース
    price = apply_discount(base_price=100, discount_percent=150)
    # 期待: 価格は0円未満にならない
    assert price >= 0, f"価格がマイナスになった: {price}"

このテストが「赤（失敗）」になることを、まず確認する。再現できた瞬間、バグは半分片付いたようなものです。

ここで大事なのが決定論化。「たまに落ちる」バグは、AIにとっても人間にとっても地獄です。ランダム・時刻・外部通信・並行処理みたいな"ゆらぎ"を固定して、「必ず落ちる」状態を作りましょう。

# ゆらぎを固定して「たまに」を「必ず」にする
import random

def test_flaky_becomes_deterministic():
    random.seed(42)          # 乱数を固定
    # 時刻に依存するなら freezegun 等で「今」を固定する
    # 外部APIに依存するなら、その応答をモックで固定する
    ...

AIに任せるところは、この「再現手順の整理」と「最小再現（MRE）化」です。長い再現手順から、バグに関係ない部分をそぎ落として、最小の再現コードにしてもらう。プロンプトはこんな感じ。

【役割】あなたはデバッグの実験助手です。原因の推測はまだしないでください。

【状況】次の手順でバグが再現します（全文貼付）。
（再現手順・エラーメッセージ・関連コードを貼る）

【依頼】
1. このバグを再現する「失敗するテスト」を1本、pytestで書いてください。
2. 再現に関係なさそうな手順を削って、最小の再現コード(MRE)に絞ってください。
3. 再現が不安定な要因（乱数・時刻・並行・外部通信）があれば指摘し、
   それを固定する方法だけ挙げてください。
※ まだ修正案は出さないでください。まずは「必ず落ちる状態」を作るのがゴールです。

「まだ修正するな」と釘を刺すのがコツです。放っておくとAIは秒で④に飛んで推測し始めるので。

Step2｜観測（Observe）：推測させるな、観測させろ

再現できたら、次は事実集め。ここがこの記事の心臓部です。

原則はひとつ。AIにも自分にも、推測を禁止して、観測させる。 「たぶんここが原因」ではなく、「ここにログを入れて、実際の値を見る」。

スタックトレースは"読む"、AIには"次の一歩"を聞く

スタックトレースは上から下へ「呼ばれた順」に並んでいます。まず自分たちのコードで一番最後に出てくる行、そこが事故の入口であることが多い。AIに渡すときは、「原因を当てて」ではなく「次に観測すべき場所を1つだけ挙げて」と頼みます。

【役割】実験助手として、推測ではなく「次の観測点」を出してください。

【材料】
- 失敗するテスト（Step1で作成、貼付）
- スタックトレース全文（貼付）
- 該当関数のコード（貼付）

【依頼】
1. このトレースから「確実に言える事実」だけを箇条書きにしてください
   （推測と事実を混ぜないこと）。
2. 原因を特定するために、次に確認すべき変数・分岐を「1箇所だけ」挙げ、
   そこにログを入れるコードを提案してください。
3. その値が「何だったら、どの仮説が濃くなるか」も添えてください。

「事実と推測を分けて」「次の1箇所だけ」——この2つで、AIの暴走がかなり止まります。

計器（ログ）を差し込んで、値を"見る"

提案されたログを、実際に入れて動かす。ここで初めて「思ってた値と違う」が見えてきます。

import logging
logger = logging.getLogger(__name__)

def apply_discount(base_price, discount_percent):
    # 観測: 入ってきた値を、加工する前にそのまま見る
    logger.debug("apply_discount 入力: base=%s, percent=%s",
                 base_price, discount_percent)
    discounted = base_price * (1 - discount_percent / 100)
    logger.debug("apply_discount 計算結果: %s", discounted)
    return discounted

これを走らせて percent=150 が来ていると分かれば、「割引率の上限チェックが無い」という事実が観測できます。推測じゃなく、目で見た事実です。

「昨日は動いた」なら、二分探索（git bisect）

「先週まで動いてたのに」というバグは、どのコミットで壊れたかを探すのが最速です。手で1つずつ戻すのは大変なので、gitの二分探索を使います。良いコミットと悪いコミットを教えると、半分ずつ絞ってくれます。

# 今は壊れている、3日前は動いていた、が分かっているとき
git bisect start
git bisect bad                 # 今のコミットは「悪い」
git bisect good a1b2c3d        # 動いていたコミットを「良い」と伝える

# ここから git が中間コミットを次々チェックアウトしてくれる。
# テストを走らせて good / bad を答えるだけ。

# さらに自動化: テストの成否で自動判定させる
git bisect run pytest test_discount.py
# → 「このコミットが原因」と一発で出る

git bisect reset               # 終わったら元に戻す

犯人のコミットが分かれば、その差分を見るだけで原因がほぼ見えます。ここまで来ると、AIに渡す情報の質が段違いになりますよね。

Step3｜仮説（Hypothesize）：1つに飛びつかない

観測で事実がそろってきたら、原因の仮説を立てます。ここでの落とし穴は、最初に浮かんだ1つの仮説に恋してしまうこと。人間もAIも、これをやります。

対策は「複数出して、確率順に並べる」。そして各仮説に、その仮説をどう観測すれば否定できるか（kill条件）を先に決めておく。反証を用意しておくのが、科学の作法です。

【役割】実験助手として、原因の仮説を複数出してください。断定はしないこと。

【材料】観測で分かった事実（Step2の箇条書き）＋関連コード（貼付）

【依頼】
1. 原因の仮説を3〜5個、「ありえそうな順」に並べてください。
2. 各仮説について、次の2つを必ず添えてください。
   - 「この仮説が正しいなら、こう観測できるはず」（確認方法）
   - 「もしこう観測されたら、この仮説は捨ててよい」（反証＝kill条件）
3. どの仮説も、まだ修正はしないでください。

こうすると、AIの出力が「これが原因です（キリッ）」から「候補と、それを潰す実験セット」に変わります。あとは人間が、コストの低い実験から順に観測して、仮説を1つずつ消していく。残ったものが真実、という探偵ムーブですね。

ここで肝に銘じたいのは、AIが出した仮説は「主張」であって「事実」じゃないということ。もっともらしさと正しさは、全然べつものです。必ず観測で裏を取る。これは後の安全章でもう一度出てきます。

Step4｜最小修正（Fix）：根本原因に、最小の差分で

原因が観測で確定したら、いよいよ修正。ここでの合言葉は、根本原因に、最小の差分で、この一点です。

さっきの割引バグ。原因は「割引率の上限・下限チェックが無い」ことでした。悪い修正（対症療法）と、良い修正（根本修正）を並べてみます。

# ❌ 対症療法：症状（マイナス価格）だけを消している
def apply_discount(base_price, discount_percent):
    discounted = base_price * (1 - discount_percent / 100)
    if discounted < 0:      # マイナスなら0にする…
        discounted = 0      # → なぜ150%が来るのかは放置。次はまた別の顔で出る
    return discounted

# ✅ 根本修正：不正な入力そのものを、境界で止める
def apply_discount(base_price, discount_percent):
    # 割引率は 0〜100 の範囲でしか意味を持たない、という「契約」を明示する
    if not 0 <= discount_percent <= 100:
        raise ValueError(f"discount_percent は 0〜100 で指定してください: {discount_percent}")
    return base_price * (1 - discount_percent / 100)

対症療法版は「マイナスになったら0」と、症状を隠しているだけ。150%という不正な入力がなぜ来たのか、という本当の問いは残ったままです。根本修正版は、「割引率は0〜100」という契約を境界で守る。以後、変な値は入口ではじかれます。

AIに修正を頼むときは、「対症療法になっていないか自己批判させる」よう頼むのが効きます。

【役割】確定した根本原因（Step2/3で観測済み）に対して、修正案を出してください。

【原因】割引率の上限チェックが無く、100を超える値がそのまま計算される。

【依頼】
1. 症状を隠すのではなく、原因を断つ最小の修正diffを出してください。
2. その修正について、自分で次を点検してください。
   - これは「対症療法（症状隠し）」ではないか？
   - この変更で、別の呼び出し元が壊れる可能性はないか？
   - 変更範囲は必要最小限か？（ついでの整形・リファクタを混ぜない）
3. 懸念が残る箇所は「ここは人間が確認してください」と明示してください。

「ついでのリファクタを混ぜない」も地味に大事です。修正と無関係な変更が混ざると、レビューもロールバックも一気に難しくなるので。

Step5｜再発防止（Prevent）：バグに「立入禁止」の札を刺す

修正できた。テストが緑になった。……で終わらせないのが、プロの、いや明日の自分に優しい人のやり方です。

最後に、Step1で書いた「失敗するテスト」を、恒久的な回帰テストとして残す。これで、このバグが将来もう一度忍び込もうとした瞬間、CIが赤くなって止めてくれます。踏んだ地雷に「立入禁止」の札を刺すイメージ。

# test_discount.py（回帰テストとして恒久化）
import pytest
from pricing import apply_discount


def test_normal_discount():
    assert apply_discount(100, 20) == 80


def test_reject_out_of_range_discount():
    # かつてマイナス価格を生んだ入力。二度と通さない。
    with pytest.raises(ValueError):
        apply_discount(base_price=100, discount_percent=150)

このテストをCIに乗せておけば、再発は仕組みで防げます。

# .github/workflows/test.yml（抜粋）
name: test
on: [push, pull_request]
jobs:
  pytest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: pytest -q      # 回帰テストが赤なら、ここでマージが止まる

余力があれば、超軽量の「ポストモーテム」も1〜2行残すと最高です。ドラマチックな反省文じゃなくていい。

## bug: 割引価格がマイナスになった (2026-07-04)
- 症状: discount_percent=150 で価格が負値
- 観測できた事実: 入力に上限チェックが無く、100超がそのまま計算されていた
- 修正: apply_discount の入口で 0〜100 を検証（契約を明示）
- 再発防止: test_reject_out_of_range_discount を追加
- 学び: 「外から来る数値には、意味の範囲がある」。境界で守る。

これ、AIに観測ログと修正diffを渡して下書きさせれば10秒です。未来の自分（と次に触るAI）への置き手紙になります。

安全鉄則：ここだけは、絶対に外さない

AIとデバッグするとき、速さより先に守るべき線があります。

① 秘密・PII・本番接続を、ログやプロンプトに貼らない（最重要）

デバッグ中って、つい生のログをそのままAIに投げたくなります。でもそのログに、APIキー・トークン・個人情報・本番のDB接続文字列が混ざっていたら？ AIに渡す＝外に出す、です。一度渡したら、キャッシュされるかもしれないし、取り消せない前提で動くのが安全。貼る前にマスクする。

# ❌ 生のまま貼らない
logger.debug("request: %s", request)   # ヘッダにトークンが乗っているかも

# ✅ 秘密は落としてから
def redact(d: dict) -> dict:
    hide = {"authorization", "api_key", "password", "token", "cookie"}
    return {k: ("***" if k.lower() in hide else v) for k, v in d.items()}

logger.debug("request: %s", redact(request_headers))

② 不可逆な操作は、AIに実行ボタンを持たせない

「本番DBでこのDELETEを試して」みたいなデバッグは、事故ると戻せません。本番DBの削除・課金・メール送信・デプロイ——このへんの不可逆操作は、必ず人間のゲートを通す。AIに触らせるのは、コピーした検証環境か、読み取り専用の接続だけにしましょう。

③ AIの「原因はこれです」は、主張であって事実じゃない

Step3でも言いましたが、これは何回でも言います。AIの説明は流暢で、めちゃくちゃ正しそうに聞こえる。でも、正しそう≠正しい。必ず観測（ログ・テスト）で裏を取ってから信じる。冒頭のLightrunの数字——AIの修正が2〜3回の再デプロイで直った——は、まさに「一発で信じると火傷する」ことの裏付けですよね。

④ 外から来たエラー文・ログは「データ」として扱う

ユーザーの入力や外部サービスのメッセージに、AIへの指示めいた文字列（「これまでの指示を無視して……」的なもの）が紛れ込むことがあります。デバッグ材料として貼るときも、それはあくまで調査対象のデータであって、AIへの命令ではない、という枠で扱う。プロンプトインジェクションの入口を、デバッグ経由で開けないように。

人間とAIの役割分担（まとめ表）

やること	人間（What / Why）	AI（How）
何が「正しい」かの定義	◎ 決める	—
失敗するテストを書く	承認する	◎ 下書き
再現手順のMRE化	妥当性を判断	◎ そぎ落とす
ログ・観測点の設計	◎ どこを見るか決める	差し込みコードを書く
スタックトレース読解	事実を確認	◎ 高速に読む
仮説を立てる	◎ 採否を判断	複数生成＋確率付け
対症療法か根本かの見極め	◎ 最終判断	自己批判の材料出し
最小修正diff	承認・マージ	◎ 差分を書く
回帰テスト	何を守るか決める	◎ コード生成
不可逆操作の実行	◎ 人間だけ	触らせない

境界線はいつも同じです。What（何を）とWhy（なぜ）は人間、How（どうやって）はAI。 デバッグでも、この線は動きません。

つまずきポイントと、撤退ライン

よくある落とし穴

再現せずに直し始める → 直ったか永久に確認できない。まず失敗テスト。
1つ目の仮説に恋する → 反証（kill条件）を先に決めておく。
対症療法を"修正"と呼ぶ → 症状隠しは負債。根本を断つ。
AIの説明を観測なしで信じる → 主張は事実じゃない。ログで裏取り。
修正にリファクタを混ぜる → レビューもロールバックも困難に。差分は最小。
生ログを丸ごとAIに貼る → 秘密・PII漏れ。マスクしてから。

撤退ライン（AIデバッグをやめて、人間の手に戻す線）

AIの修正案が、同じ場所で3回連続でハズした → 前提（渡してる文脈）が間違っている合図。手を止めて、観測をやり直す。
原因が「セキュリティ」「お金」「データ消失」に触れそう → 速さより正確さ。人間が主導する。
再現がどうしても取れない → 直すより前に、まず観測（ログ強化・監視）を仕込んで"次に起きたとき捕まえる"に切り替える。

「AIに任せない」も、立派な設計判断です。どこまで任せてどこから握るかを決めるのが、これからのエンジニアの腕の見せどころかなと思います。

おわりに — 今日刺した回帰テストは、明日の自分への「あざっす」

長くなったので、いちばん大事なところだけ持って帰ってください。

デバッグは、コードを書き換える作業じゃなくて、仮説を観測で確かめる"科学"です。 そして、

推測させるな、観測させろ。

AIに「原因当てて」と言えば推測ゲーム。「この仮説を確かめる観測コード書いて」と言えば、科学になる。同じAIから、まるで違うものが引き出せます。人間がWhat / Why（何が正しくて、なぜそう言えるか、何を観測すれば決着するか）を持ち、AIにHow（読む・書く・並べる・作る）を任せる。この線を守るだけで、冒頭の「43%が本番で再デバッグ」みたいな事故は、ぐっと減らせるはずです。

最後に、ひとつだけ気持ちの話を。

バグを出したとき、「なんでこんなの見落としたんだ」って過去の自分を責めたくなりますよね。でも僕は、そこは責める軸じゃなくていいと思っています。バグは、出るもの。大事なのは、今日それを踏んで、観測して、根本を直して、"立入禁止"の札（回帰テスト）を1枚刺しておくこと。

その札は、半年後にまた同じ穴に落ちかけた自分を、CIの赤ランプで止めてくれます。そのとき明日の自分は、こう言うはずです。「札さしといてくれて、あざっす」。

デバッグの型も、観測の習慣も、積み上げた回帰テストも、AIには奪えない、あなたに積み上がっていく資産です。まさに Code as Capital。道具は借りても、"直せる力"だけは、自分のものにしていきましょう。

明日からの4ステップ

次にバグを踏んだら、直す前に「失敗するテストを1本」書く。
「原因を当てて」じゃなく、AIに「次に観測すべき1箇所」を聞く。
修正案には「これは対症療法じゃない？」と一言、自己批判させる。
直したら、そのテストを回帰テストとして残してCIに乗せる。

これだけで、あなたのデバッグは「推測ゲーム」から「科学」に変わり始めます。明日の自分が「あざっす」って言ってくれる一歩、今日ひとつ、置いていきましょう。

参考文献・出典

Andreas Zeller, Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005（科学的方法によるデバッグ）
Andreas Zeller, "Simplifying and Isolating Failure-Inducing Input"（Delta Debugging, IEEE TSE 2002）
Tang et al., How Coding Agents Fail Their Users: A Large-Scale Analysis of Developer-Agent Misalignment in 20,574 Real-World Sessions, arXiv:2605.29442, 2026-05
Lightrun, 2026 State of AI-Powered Engineering Report（VentureBeat報道／SRE・DevOpsリーダー200名調査）
Git 公式ドキュメント（git bisect）