同じ修正を3回させない

Claude Codeに同じ修正を何度も頼んでいないか。2回外したら止まる手順と、CLAUDE.mdに撤退・再開条件を書き残す型をまとめた。

エージェントに直させた修正が効かず、「もう一度お願い」と頼む。また効かない。気づくと同じ種類の修正を何度も打たせている。編集部の検証環境でも、これを何度も踏みました。この記事では、2回外した時点で止まる手順と、その経験を CLAUDE.md に書き残して再発を防ぐ型をまとめます。確認に使った Claude Code は 2.1.301 です（2026-10-16）。

同じエラーでループし始めたら

編集部のルールは単純です。同じ種類の修正が2回失敗したら、3回目は試さない。 2回外れたということは、前提のどこかが間違っています。前提が間違ったまま3回目を打っても、外れ方が変わるだけです。

公式のベストプラクティスにも、同じ考え方があります。1つのセッションで同じ問題を2回より多く訂正したなら、文脈は失敗したアプローチで散らかっている。/clear して、学んだことを入れた具体的なプロンプトでやり直す、という趣旨です（出典：https://code.claude.com/docs/en/best-practices 、2026-10-16確認）。

ただし、/clear だけでは足りないことがあります。前提の誤りを見つけないまま新しいセッションで頼むと、同じ前提で同じ修正が出てくるからです。止まったあとにやることを、次の節に書きます。

止まったあとの手順

目で確かめる。 まず、修正が本当に画面や出力に届いているかを見ます。エージェントの「直しました」ではなく、実物を見ます。

仮説を2つに分ける。 修正が効かないとき、原因はたいてい次のどちらかです。

• 適用されていない：直したファイルと、実際に動いているものが違う
• 上書きされている：直した内容が、あとから来た別の設定に負けている

この2つは、確かめ方が違います。手元のダミーのファイルで再現しました。

--- 修正後に実行（dist を実行）
label: OLD
--- 仮説A: 適用されていない？
src/app.js:1
dist/app.js:0
--- 仮説B: 上書きされている？
1:.btn { color: green; }
2:.page .btn { color: gray; }

上は、src を直したのに、ビルドし直していない dist を動かしている例です。grep -c で数えると、修正は src にしかありません。これが「適用されていない」です。下は、.btn を緑にしても、より具体的な .page .btn が灰色で上書きする例です。どちらの仮説なのかを先に決めれば、3回目の修正は要りません。

俯瞰の調査に切り替える。 2つの仮説でも説明できないなら、修正をやめて調べる側に回ります。その部品の基本の仕様、周りのコード、似た不具合の記録を読みます。どこから疑えばよいかの順番は、「AIが言う原因を疑う順番」にまとめました。

それでもだめなら、上位のモデルに上げる。 同じモデルに同じ文脈で頼み続けるより、別の目に渡すほうが早いことがあります。

/clear と /rewind を使い分ける

止まったあと、外した修正をどう片付けるかも決めておきます。公式の説明では、Esc を2回押すか /rewind を実行すると、会話とコードを以前の状態に戻せます。会話だけ、コードだけ、両方、のどれを戻すかも選べます。/clear は、関係のないタスクの間で文脈をリセットするものです（出典：https://code.claude.com/docs/en/best-practices 、2026-10-16確認）。

編集部では、次のように使い分けています。

大事なのは、/clear の前に「何が分かったか」を書き出すことです。書かずに消すと、次のセッションは同じ前提から始まり、同じ修正をまた出してきます。

実例：5回外したレイアウト

編集部の検証環境で作っていたアプリで、リストの余白がずれる不具合がありました。エージェントにレイアウトの修正を5回続けて頼み、5回とも外しました。原因は、その部品の余白の指定の仕方という、基礎的な仕様でした。

後から振り返ると、部品に仮の背景色を塗って実際の大きさを見れば、1回で分かりました。修正を重ねる前に「目で確かめる」をやっていれば、5回は要らなかったということです。2回ルールを決めたのは、この件がきっかけです。

CLAUDE.md に書き残す型

止まって原因が分かったら、同じことを繰り返さないように書き残します。編集部で使っている型は3つです。

手順として書く。 「気をつける」ではなく、何をするかを書きます。

- 同じ種類の修正が2回失敗したら、3回目は試さない。
  実物を目で確かめ、「適用されていない／上書きされている」を分けてから再開する。

撤退条件と再開条件を書く。 調査を途中でやめるときは、どこまで分かったかと、次はどこから始めるかを残します。以前、ある CLI の調査に長い時間をかけて撤退したときは「再挑戦は login が通るか確かめるところから」と1行残しました。次のセッションが同じ調査を最初から繰り返さずに済みます。

書く時期を決める。 理想は「1回目でメモに書き、2回目で既定の手順にする」です。3回目まで待つと、その間に同じ失敗の時間を払います。

書き足すほど CLAUDE.md は長くなります。公式は、ルールがあるのに守られないなら、ファイルが長すぎてルールが埋もれている可能性が高い、と書いています。何度も飛ばされる1行にだけ「IMPORTANT」のような強調を付け、多くの行を強調すると、どれも目立たなくなる、とも書いています（出典：https://code.claude.com/docs/en/best-practices 、2026-10-16確認）。書き足すときは削る作業とセットにします。削り方は「CLAUDE.mdは削るほど効く」に書きました。

書いても繰り返すなら、機構に渡す

書き残したルールは、読まれないことも、読まれて守られないこともあります。それでも同じ失敗が続くなら、文章のルールをやめて、機械で止める側に渡します。その作り方は「Claude Code hooks実践」に書きました。

まとめ

• 同じ種類の修正が2回外れたら、3回目は打たない。前提が間違っている。
• 止まったら、目で確かめ、「適用されていない／上書きされている」を分け、俯瞰の調査、上位モデルの順に進む。
• CLAUDE.md には手順・撤退条件・再開条件を書き、1回目でメモ、2回目で既定の手順にする。
• 書き足すなら削るのとセットで。書いても繰り返すなら hooks に渡す。