雑に投げた指示がそのまま通ると思っているなら、そこが一番あぶない。Claude Code は空気を読んで勝手に名案をひねり出す道具ではないので、失敗した依頼はその場で拾って、次の指示に直すほうがずっと強い。ここで使うのが、手戻り分析とやり直しポイントの洗い出しだ。会話のどこでズレたかを見つけて、同じ事故をもう一回起こさない形に変える。
このやり方のうまみは単純だ。失敗を「なかったこと」にせず、次の依頼文に変換できる。Claude Code にやり直しをさせるたびに、曖昧な言い方が減り、余計な探索や無駄な diff も減る。ファイル整理でも文書作成でも、ここをサボると、あとで「なんでここを触った？」みたいな修正が増える。地味だが、効く。
まずやることは、失敗した依頼をそのまま見返すことだ。Claude Code との会話ログの中で、結果がズレた返答、余計な修正、期待外れの要約、触ってほしくないファイルへの変更を拾う。重要なのは、結果だけを見るのでなく、その前の自分の依頼文も一緒に見ることだ。たいてい問題は、モデルの気まぐれではなく、依頼のどこかが曖昧だったり、前提が抜けていたりする。
たとえば、こういう依頼は失敗しやすい。
このフォルダをきれいにして。
これでは広すぎる。削除なのか移動なのか、重複検出なのか、命名統一なのかが分からない。Claude Code は文脈からそれらしく進めるが、そこが危ない。なので、会話の流れから「何が目的だったか」「何を触ってよかったか」「何を触るなと言うべきだったか」を抜き出して、次の依頼をこう直す。
このフォルダ内の .tmp と .log を一覧化して、削除候補だけを提案してください。
実際の削除はしないでください。
重複しそうなファイルがあれば、候補名と理由を出してください。
この修正で大事なのは、依頼を細かくしたことより、失敗の原因を塞いだことだ。削除してほしかったのか、整理だけしてほしかったのか、まずそこを明文化する。Claude Code は手を動かす前に、範囲をはっきりさせたほうが安定する。
会話の流れから洗い出すときは、次の3点を見ると速い。ひとつ目は目的のズレだ。たとえば「要約して」と頼んだのに、実際には「箇条書き化」や「短文化」や「専門用語の言い換え」が欲しかった、というズレがある。二つ目は対象のズレだ。どのファイル、どの章、どのディレクトリを対象にするのかが曖昧だと、余計なところまで巻き込む。三つ目は出力形式のズレだ。差分だけ欲しいのに全文を書き換えられた、一覧だけ欲しいのに勝手に編集が始まった、というやつだ。
筆者も最初はここで何度も手戻りした。特に文書作成で、「この資料を読みやすくして」と投げると、Claude Code はけっこう親切に見える形へ整える。だが、こちらが欲しかったのは見出しの整理だけで、本文の言い回しはほぼ触らないことだった。結果、微妙に言い回しまで変わって、確認の手間が増えた。そこからは、会話がズレたら「何がやりたかったか」を一文で再定義してから、次の依頼を出すようにした。これだけで戻り作業が減る。
実際の直し方は、失敗した依頼を次の形に分解するとやりやすい。会話ログを見ながら、まず「やりたかったこと」を一文にする。次に「やってほしくなかったこと」を並べる。最後に「出力の形」を固定する。これをそのまま次の依頼文にする。
目的:
請求書フォルダ内の重複ファイル候補を洗い出したい。
やらないこと:
ファイルの削除、移動、リネームはしない。
出力:
重複候補の一覧を、ファイル名・サイズ・理由つきで出す。
Claude Code への依頼は、長文である必要はない。だが、余計な解釈の余地は潰したほうがいい。特に「確認して」「整えて」「いい感じにして」は危険語だ。便利そうに見えて、失敗の芽でもある。確認なのか提案なのか実行なのかを分けるだけで、だいぶ違う。
会話の流れから拾うべきなのは、ユーザー側のあいまいさだけではない。Claude Code が途中で見せた前提の置き方も見ておくといい。たとえば、「このファイルは設定ファイルだろう」と決め打ちしているのに、実は手順書だった、みたいなケースだ。こういうときは、次の依頼で前提を明示する。
このリポジトリでは、config/ 配下の JSON は設定用で、README と docs/ は編集対象です。
今の修正では、README と docs/ だけを直してください。
こうやって境界を先に言うと、Claude Code は変なところに手を出しにくくなる。特に複数フォルダが混ざる案件では効く。非エンジニアでも、案件ごとに資料フォルダが分かれているなら同じだ。作業対象の箱を先に指定しておけば、余計なファイルをいじる事故が減る。
ここで一つ注意がある。失敗した依頼を洗い出すとき、会話全体を広く見すぎると、ただの反省会になる。見るべきは「次の指示をどう直すか」に直結する部分だけだ。たとえば、途中の雑談や確認メッセージまで全部抱え込む必要はない。修正に効くのは、失敗した結果、その直前の依頼、そしてClaude Code が勘違いした前提だ。ここだけ切り出せばいい。
もう一つ、やりがちなのは「失敗したから全部やり直し」と気合で押し切ることだ。これはだいたい悪手だ。大きな依頼を丸ごと投げ直すと、また別の場所でズレる。そうではなく、会話の流れから失敗点を一つずつ拾って、その都度依頼文を締めるほうがいい。たとえば、ファイル整理なら先に一覧だけ出させる。文書作成なら先に見出しだけ整えさせる。差分の見通しを作ってから本処理に入ると、手戻りが減る。
少し進んだ使い方としては、失敗した依頼の後に「次回用の依頼テンプレ」を作っておく方法がある。毎回ゼロから考えず、会話の中で効いた言い回しを残すのだ。
今後この種類の作業では、先に対象範囲を確認し、実行前に候補だけ一覧化してください。
削除、移動、上書きは確認なしでは行わないでください。
これは地味だが強い。Claude Code に限らず、同じタイプの作業を繰り返すなら、失敗の修正そのものをテンプレにしたほうが速い。特にディスク削減や文書の大量整理では、毎回同じズレが起きる。そこを一度つぶしておくと、次からの依頼が軽くなる。
最後に、会話の流れから失敗を洗い出すときの判断基準をひとつだけ置いておく。失敗の原因が「Claude Code が悪い」で終わるなら、だいたい改善できていない。次の指示に直すとは、モデルを責めることではなく、依頼文のどこが曖昧だったかを見つけて、再発しない形に変えることだ。そこまでできると、同じ作業でも返り道が短くなる。手戻り分析は反省のためではなく、次の一手を安くするためにやる。