Contents
まず結論
デバッグ作業を通じて、3つのことを身体で学びました。
- 真実は1箇所に置く（同じ名前のファイルが2つあると、意図しない方が動く）
- AIの原因仮説は、コードを見るまで”仮説”でしかない
- 仮に置いた値は、動いた瞬間に”風景”になって見えなくなる
順に書きます。
その前に ── チャットと「コードモード」は別の道具
教訓の前に、今週やっと腑に落ちたことがあります。私がいつも相談しているチャットと、実際にコードを書き換える「コードモード」は、上位・下位の関係ではなく、得意分野の違う別の道具だということです。
チャットは考える・調べる・相談する場所。コードモードは実際のプログラムを開いて、書き換えて、動かす作業場。そして重要なのは、コードモードも私のMacそのものの中にいるわけではないという点です。だから最後は必ず、私が実機で動かした結果を手で伝える場面が残ります。「AIが全部やってくれる」わけではなく、私が実機とAIをつなぐ橋になる——この役割分担が分かったのが、デバッグの土台になりました。
教訓①：真実は1箇所に ── 一番怖かった発見
バグを直していく途中で、今回いちばんゾッとする発見がありました。同じ名前のプログラムファイルが、置き場所を変えて2箇所に存在していて、本番のサーバーは”古いほう”を読んでいたのです。
これがなぜ怖いか。どれだけ正しく修正しても、本番に反映されない状態だったからです。直したつもりが、直っていない。バグそのものより深刻でした。
なぜこうなるかを初学者向けに言うと、プログラムは「どのフォルダから部品を探すか」の順番が決まっていて、置き場所によっては意図と違うほうが”勝って”しまうことがあるからです。教訓はひとつ、「真実は1箇所」（Single Source of Truth）。コピーして実験したくなったら、別の名前にするか、Gitのブランチ（作業用の分身）を使う。同じ名前のまま2つ置いてはいけない、と骨身にしみました。
教訓②：AIの仮説は、検証するまで仮説
ある異常な数値が表示される原因について、私は事前に「たぶんこういう処理のミスだろう」と見当をつけていました。ところがコードモードで実際にコードを追いかけて確かめたら、その原因は存在しませんでした。私の推測は外れていたのです。
ここが大事なところです。AIが出す原因の見立ては、どれだけもっともらしくても、コードを見るまでは全部”仮説”です。今回は「仮説 → 実際に追試 → 棄却」という流れがちゃんと回りました。この順番こそが正しい進め方で、AIの言うことを鵜呑みにせず、実測で確かめるという、このブログで何度も書いてきた姿勢が、そのまま活きた場面でした。
教訓③：仮に置いた値は”風景”になる
もうひとつのバグは、画面のある時刻表示がずっと更新されない、というものでした。原因は拍子抜けするほど単純で、開発の途中で仮に埋めた固定の値が、そのまま消し忘れられていただけでした。
これは個人開発の定番の罠だそうです。動く画面ができた瞬間、仮の値は”風景”になって目に入らなくなる。毎日見ているのに、見えていない。対策も教わりました。仮の値を書くときは、必ず「これは仮」と印になるメモを添えておく。そうすれば後でまとめて探し出せます。
おわりに ── AIと組んでも、判断は自分の側に残る
初めてAIエージェントで本格的にデバッグして、いちばん実感したのは、「AIが速くコードを直してくれるほど、人間側の”確認する目”が重要になる」ということでした。
同じ名前のファイルに気づく、AIの仮説を疑って追試する、風景になった仮の値を見つける。どれもコードを書く速さとは別の力です。そして幸い、これは非エンジニアの自分にも積み上げられる力でした。AIに任せる部分が増えるほど、最後の一線は自分が持つ。今週のデバッグは、その練習になりました。
次に同じ症状が出た日が、この修正の本当のテストです。そのときまた記録します。
デバッグ / Git / AIエージェント / 個人開発
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
