AIの修正が堂々巡りになったとき：同じ失敗を繰り返さない仕切り直しの手順

堂々巡りのサインを見分ける

次のうち2つ以上当てはまれば、仕切り直しの合図と考えてよいでしょう。

• 同じ(またはほぼ同じ)修正案が3回目に出てきた
• エラーメッセージは変わったのに、直す場所が元の関数に戻っている
• 修正のたびにコードが増え、どこが本質か分からなくなってきた
• 「おそらく〜が原因です」という推測が続き、確認の手順が出てこない

ここで「もう一度やり直して」と頼むのは避けます。会話には失敗した案も全部残っているため、同じ案が再提案されやすいからです。

手順1：まず現状を保存して、元に戻せるようにする

AIの案を何度も当てたコードは、どこまでが元で、どこからが変更か分からなくなりがちです。記録の前に、今の状態を保存します。

Gitを使っているなら、作業中の変更を一時退避する git stash が使えます。Gitの公式ドキュメントによると、git stash push は作業ツリーとインデックスの変更を新しいstashに保存してHEADの状態へ戻し、git stash list で一覧、git stash pop で適用して削除できます。新規ファイルも退避したい場合は -u(--include-untracked)を付けます。pop で競合が起きたときはstashが残る、とも書かれています。

git stash push -u -m "ai-loop: 案A〜C を試した状態"
git stash list

退避すると、変更前のきれいな状態でエラーを再現できます。「そもそも元の状態でも失敗するのか」を確かめられるのも利点です。退避した内容は捨てず、後で見返せるようにしておきます。

手順2：試した案の記録表をつくる

会話をさかのぼって、試した案を1行ずつ書き出します。AIに「この会話で試した修正案を下の表の形式で整理して」と頼んで下書きを作らせてもよいですが、結果の欄は必ず自分の実行結果で埋めてください。AIは実行していない結果を推測で書くことがあります。

• 1、試した案：非同期処理に await を追加、変えた場所：fetchUser()、実行した確認：npm test、結果(エラー全文の要点)：同じエラー(undefinedの読み取り)、分かったこと：await の有無は原因ではなさそう
• 2、試した案：入力の null チェックを追加、変えた場所：parseData()、実行した確認：npm test、結果(エラー全文の要点)：エラー位置が3行後ろに移動、分かったこと：値は渡っているが中身の形が違う可能性
• 3、試した案：案1と同じ await 追加(再提案)、変えた場所：fetchUser()、実行した確認：未実行、結果(エラー全文の要点)：—、分かったこと：重複。試さない
• 4、試した案：ライブラリを更新、変えた場所：package.json、実行した確認：npm install → npm test、結果(エラー全文の要点)：別のエラーに変化、分かったこと：更新で壊れた。元に戻した

(上は説明用の例です。)

ポイントは「分かったこと」の列です。成功か失敗かだけでなく、「この案が外れたことで何が言えるか」を一言で残すと、次の案が絞り込めます。重複した案には「試さない」と明記します。

手順3：前提を疑い直す

堂々巡りの多くは、会話の最初に置いた前提が間違っているときに起きます。AIも人も、一度「原因は〇〇」と置くと、その周辺ばかり直し続けるためです。記録表を見ながら、次の表で前提を点検します。

• エラーの場所=原因の場所、確かめ方(人が行う)：スタックトレースの上から順に、実際の値をログで出す、結果の読み方：値が壊れた地点がエラー行より前にあることは多い
• 元のコードは動いていた、確かめ方(人が行う)：手順1で退避した後、元の状態でテストを動かす、結果の読み方：元から失敗していたなら、AIの変更は原因ではない
• 環境は同じ、確かめ方(人が行う)：Nodeやライブラリのバージョン、環境変数、実行コマンドを書き出す、結果の読み方：会話中の想定と手元で差があれば、そこが候補
• テスト自体が正しい、確かめ方(人が行う)：テストの期待値を手計算で確認する、結果の読み方：テストが古い仕様のままなことがある
• 直す対象のファイルが正しい、確かめ方(人が行う)：実際に読み込まれているファイルのパスを確認する、結果の読み方：同名ファイルや古いビルド成果物を見ている場合がある

いつから壊れたかが分かるなら git bisect

過去のコミットに正常な時点があるなら、git bisect が使えます。公式ドキュメントでは、悪いコミットと良いコミットを指定すると、二分探索で問題を入れたコミットを絞り込むと説明されています。git bisect run にテストコマンドを渡せば自動化でき、終了コードは0が「良い」、125を除く1〜127が「悪い」、125が「判定不能(スキップ)」です。

git bisect start HEAD <正常だったコミット>
git bisect run npm test
git bisect reset

AIにコードを推測させるより、変更履歴で事実を絞るほうが確実な場面があります。

値を実際に見たいときはデバッガ

ログだけで分からなければ、Node.jsなら公式のデバッグガイドにある node --inspect-brk script.js で、ユーザーコードの実行前に止めて確認できます。同ガイドは、デバッガが実行環境へ広くアクセスできるため、デバッグポートを公開IPに出さないよう注意しています。

手順4：新しい会話に渡す状況まとめを書く

前提を点検して分かったことを、次のテンプレートにまとめます。会話の履歴ごと渡すのではなく、確定した事実だけを渡すのがコツです。

# 状況まとめ
## ゴール
(例)ユーザー情報の取得APIが、空の配列のときにも例外を出さず空表示になる

## 環境
- 言語/実行環境:(例)Node.js 〇〇、OS 〇〇
- 実行コマンド:npm test
- 元の状態(変更前)でのテスト結果:(例)3件失敗

## 現在の症状
- エラー全文:(貼り付け。秘密情報は伏せる)
- 再現手順:1. … 2. …

## 確認済みの事実
- (例)fetchUser() の戻り値は取得できている
- (例)parseData() に渡る時点で items が配列ではなくオブジェクト

## 試して外れた案(再提案しないでほしい)
- await の追加 → 変化なし
- null チェック追加 → エラー位置が移動しただけ
- ライブラリ更新 → 別のエラー

## まだ分かっていないこと
- (例)items の形が変わる箇所

## 変更してよい範囲/してはいけない範囲
- 変更可:parseData() とそのテスト
- 変更不可:package.json、公開API

(説明用の例です。)

エラー全文やコードを貼る前に、APIキー、パスワード、個人情報、社内の固有名は伏せるか、ダミーの値に置き換えます。

手順5：新しい会話の最初の依頼文

新しい会話では、いきなり「直して」と頼まず、まず原因の仮説と確認方法を出してもらいます。

下の状況まとめを読んでください。
まだコードは書き換えず、次の順で答えてください。
1. 確認済みの事実から考えられる原因の候補を3つまで。それぞれ、
   そう考える根拠と、それを確かめる具体的な操作(ログ出力・コマンドなど)
2. 「試して外れた案」と重複する提案を含めていないことの確認
3. 一番安く確かめられる候補から、1つだけ最小の修正案

不明な点は推測で埋めず、質問してください。

(ここに状況まとめを貼る)

返ってきた案は、人が次の点を確認します。

• 「試して外れた案」と同じものが混ざっていないか
• 確認方法が具体的で、実行して結果を見られるか
• 変更範囲が、指定した「変更してよい範囲」に収まっているか

1案を試したら、その結果を記録表に1行足し、まとめの「確認済みの事実」を更新します。それでも3回ほど外れたら、手順3の前提表に戻って疑う前提を変えます。