基礎で「二度修正しても直らない時は /clear で仕切り直す」と書いた。本章はその判断を一段深め、抜ける合図の見極めと、再出発のプロンプトをどう設計するかを扱う。

なぜ修正ループから抜けにくいのか

「ここが違う、こう直して」を何度も繰り返していると、コンテキストが失敗したアプローチで埋まっていく。これが厄介なのは、Claude が過去の自分の出力に引きずられるためである。

「アプローチ X で試したけど違う」と言っても、次のターンで Claude が出してくるのは「X を少しいじったもの」になりがちで、根本から考え直してくれない。修正を重ねるたびに正解への距離は縮むどころか、Claude の発想は失敗の周りで堂々巡りを始める。

公式ベストプラクティスはこれを失敗パターンの一つとして挙げ、「2 回失敗した修正の後、/clear を実行し、学んだことを組み込んだより良い初期プロンプトを書きます」と推奨している。

抜ける合図

「2 回失敗したら /clear」が目安だが、それ以外にも合図はある。

  • 同じ提案が形を変えて戻ってくる ─ こちらが拒否したものを微調整して再提案している
  • モグラ叩き状態 ─ 一つ直すと別の場所が壊れる、を繰り返している
  • 会話がエラーメッセージと修正試行で埋まっている ─ 本筋の議論が見えなくなっている
  • 自分が苛立ち始めている ─ 自分の状態も信号として有効

これらが見えたら、一往復追加で粘るより、いったん抜ける方が速い。蓄積した修正履歴より、整ったプロンプトの方が強い。

抜ける前に学びを書き出す

/clear で仕切り直す前に、ここまでで分かったことを外に書き出しておく。これをやらないと、せっかく試行錯誤で得た知見が文脈と一緒に消える。

書き出す内容の例:

  • 試してダメだったアプローチと、その理由
  • 関係するファイル・関数・行
  • 部分的にうまくいった部分
  • まだ試していないアプローチの候補

書き出し先はどこでもよい ─ メモ帳でも、SCRATCH.md のような一時ファイルでも。実装に関わる学びならリポジトリに残すほうが、後の自分や Claude が再利用できる。

再出発のプロンプトを設計する

/clear で新しい会話を始める時、最初のプロンプトは学びを反映した一段尖ったものにする。普通のプロンプトでは、また同じ罠にはまりかねない。

組み込むべきもの:

  • 元のゴール (これがブレてはいけない)
  • 試してダメだったアプローチ (「これはやらないで」と明示)
  • 新しい方向性 / 重視してほしい点
  • 関連ファイルへのポインタ

例:

src/auth/login.ts のセッション期限切れ後のログイン失敗を直したい。

前のセッションでは「リフレッシュトークンの再発行ロジック」を疑って
試したが、原因はそこではなかった。実際は redis のキー TTL が
session 開始時に正しく更新されていないことが分かっている。

今回は session 更新のタイミングを中心に修正してほしい。
変更前にまず @src/auth/session.ts と @src/redis/session-store.ts を
読んで、TTL 更新の流れを確認してから着手して。

「やらないで」を明示し、「読んでから着手して」を入れることで、Claude は前のセッションでこちらが踏んだ轍を避けられる。

巻き戻すという選択肢

/clear は会話を全部捨てるが、「会話は残したいが、Claude のコード変更だけ取り消したい」場合がある。コードに触る前まではうまく進んでいたが、実装で迷走した、というようなケース。

この時は /rewind で過去のチェックポイントに戻り、コードだけを巻き戻して会話の続きから別アプローチで再出発する手がある。詳しくは次章で扱う。

ここまで「修正ループから抜ける」判断と再出発を扱った。次章では、抜けた後の選択肢のもう一つ ── 戻すための仕組みとして /rewind とチェックポイント、git の関係を整理する。

参考情報