長い依頼を一息で投げて、そのまま全部を抱えさせる。これ、いちばん雑に見えて、いちばん手戻りが増えるやり方だ。Claude Code は長文も受けるが、だからといって一発で正解を取りにいく道具ではない。むしろ、段階実行や途中確認を挟んだほうが、速いし、壊れにくい。
特に Claude Code では、ファイルをまたぐ変更、削除候補の洗い出し、文書の下書き、リネーム方針の整理みたいな作業で効く。最初に方針だけ固めて、次に実作業、最後に差分確認。これだけで、変な前提のまま大量変更される事故がかなり減る。
筆者は昔、ひとつの依頼文に「古い資料を整理して、重複を消して、命名規則も直して、READMEも整えて」と全部詰め込んで痛い目を見た。途中で返答を挟まなかったせいで、こちらの意図と違う削除候補まで広げられ、最後に確認してから戻す羽目になった。最初から二段三段に切っていれば済んだ話だ。
長い依頼の最初から作業を始めさせない。先に、見立てと手順を返させる。ここでの目的は、Claude Code に仕事をさせることではなく、こちらの意図を固定することだ。
たとえば、こんなふうに頼む。
このフォルダ内の古い資料を整理したいです。
まずは作業方針だけ出してください。
1. どの種類のファイルをどう分類するか
2. 削除候補をどう見分けるか
3. 進める順番
4. 危険な操作があれば先に指摘すること
実作業はまだしないで、確認待ちで止まってください。
この言い方が効くのは、依頼のゴールが広いときだ。ファイル整理でも、文章作成でも、コード修正でも同じである。いきなり本丸に踏み込ませると、前提のズレが後ろで大きく響く。逆に、最初の返答で「こう進める予定です」と返させれば、そこでズレを潰せる。
文章作成なら、こういう区切り方も使える。
この資料を整えたいです。まず構成案だけ出してください。
見出しの順番と、各見出しで書く内容の要点だけでいいです。
本文はまだ書かないでください。
この段階で「何を含めるか」「何を落とすか」が見える。後から全文を書き直すより、はるかに楽だ。
段階実行で大事なのは、最初の返答をそのまま通さないことだ。見立てを読んで、足りない条件を足す。ここを飛ばすと、ただの長文投げっぱなしになる。
たとえば、Claude Code が整理方針を返したら、次にこう返す。
いいです。次の条件を追加します。
- 削除は勝手に確定しない
- 変更前に対象ファイル名を一覧で出す
- 互換性が壊れる命名変更は避ける
- 最後に変更点の差分をまとめる
この条件で、まずは対象の候補一覧を出してください。
このやり方だと、途中で軌道修正しやすい。長い依頼を一気に終わらせようとすると、どこかで意図が混ざる。たとえば「削除」と「非表示化」を同じ扱いにされたり、「読みやすくする」と「構造を変える」が勝手に結びついたりする。そんなズレを、返答のたびに切り分けるわけだ。
Claude Code でありがちな失敗は、変更範囲がじわじわ広がることだ。最初は文書の整形だけのつもりだったのに、文中の表現を直し、見出しを変え、ファイル名まで触る。コードならなおさらで、関連箇所の修正が増えて diff が肥大化する。
途中確認を入れると、この広がりを止めやすい。実際、筆者は段階を切らずに頼んだせいで、ひとつの修正に関連するファイルが増えすぎて、どこまでが必要変更か見えなくなったことがある。あとで差分を追うほうが面倒だった。最初に「ここまで」と線を引いていれば、説明も検証もかなり楽だったはずだ。
コード修正なら、こう区切るといい。
まずは原因の説明だけしてください。
修正案はまだ出さなくていいです。
説明を見たあとで、次の依頼をします。
- 修正方針
- 変更対象ファイル
- 想定される影響範囲
説明を先に出させると、無関係な修正まで広がるのを防げる。これは地味だが効く。非エンジニア向けの作業、たとえば大量の文書整理でも同じだ。いきなり「全部直して」ではなく、「どれを直す予定か」を先に確認するだけで、後戻りが減る。
ここが勘違いされやすい。長文をまとめて書かせたほうが速そうに見えるが、実際は逆になりやすい。なぜなら、途中でズレたときの修正コストが大きいからだ。
段階実行は、仕事を小分けにして遅くするためのやり方ではない。むしろ、無駄なやり直しを消すためのやり方である。本文を書く、見直す、直す、という工程を分けると、各段階で見るべきものが減る。見ればいい範囲が狭いほど、人間の確認も速い。
文書作成の例なら、こんな順番が扱いやすい。
1. まず要点を箇条書きで出す
2. その要点をもとに本文を書く
3. 私が読むので、修正点だけ反映する
4. 最後に表現を整える
この順番なら、途中で「この項目は不要」「この表現は硬すぎる」と止めやすい。全部完成してから直すより、ずっと少ない手数で済む。
Claude Code は親切に見えて、依頼が曖昧だと勝手に整え始めることがある。これが便利な場面もあるが、不要な場面も多い。特に「整理」「最適化」「見やすく」といった言葉は広すぎる。ここに途中確認が効く。
たとえばこう言う。
ここまでの認識を一度まとめてください。
私の目的は次の3つです。
- 既存の内容はなるべく残す
- ファイル構成だけ整える
- 不要なものは候補として挙げるだけにする
この理解で合っているか確認したいです。
これで、相手が「ついでに」やりたがる変更を抑えられる。確認を挟むのは面倒に見えるが、実際はその逆だ。曖昧なまま突っ走って、最後に大量の修正を戻すほうがよほどだるい。
段階実行をうまく回すコツは、依頼文の中で役割を分けることだ。ひとつのメッセージに、方針確認、実作業、最終校正を全部混ぜない。混ぜるなら、どこで止まるかをはっきり書く。
実務では、次の順番が安定している。
- まず現状を把握する
- 次に方針案を出す
- 私が確認する
- 承認後にだけ変更する
- 最後に差分を要約する
この流れなら、ファイル整理でも、資料作成でも、コード修正でも使い回しやすい。特に非エンジニアの用途では、「まず候補を出す」「次に確認する」がかなり大事だ。いきなり削除や上書きを走らせると、後で探し直しになる。
最後にひとつだけ強く言うと、長い依頼を途中で区切るのは、慎重すぎるからではない。雑に一括で渡すより、結果が安定するからやるのだ。Claude Code はここをちゃんと使い分けると、ただの自動化ではなく、作業の相談相手としてかなり頼れる。まずは「方針だけ」「確認待ちで止める」を、次の依頼から入れてみるといい。