はじめに — その「直して」、たぶん半分はハズしてます
エラーが出る。真っ赤なスタックトレースをコピーして、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）