長い依頼を、いきなり全文で投げる人はだいたい損をする。Claude Code は長文でも読めるが、読めることと、うまく進むことは別物だ。
最初に「節目を先に決める」、つまり区切りを先に置く。ここをやるだけで、途中の迷走と手戻りがかなり減る。
長い依頼というのは、たとえば大量ファイルの整理、複数ディレクトリにまたがるリファクタ、長い仕様書の下書き、案件ごとの文書生成みたいなやつだ。こういう仕事は、全部を一気にやらせるより、いくつかの節目で止めるほうがいい。Claude Code にも確認させるし、自分も見直せる。
筆者は昔、要件を一気に投げて、出てきた変更を最後にまとめて眺めたことがある。結果、方向は合っているのに細部がズレていて、直し切るのに余計な往復が発生した。最初に止まる場所を作っておけば、防げた手戻りだ。
やり方は単純だ。依頼の最初に、仕事を段階に切る。たとえば「まず現状把握、次に方針案、最後に実作業」という三段にする。Claude Code に、いきなり全部をやらせず、各段で止める指示を入れる。
この作業は3段階で進める。
1. まず対象を確認し、気になる点を箇条書きで出す
2. 次に、進め方を短く提案する
3. 私が承認したら、実作業に進む
各段階の終わりで必ず止まって確認を求めてください。
これだけでも、途中で勝手に走り切る感じがかなり抑えられる。
重要なのは、「区切りを先に置く」ことだ。節目は後から考えるものではない。最初に決める。こうしておくと、Claude Code の出力も読みやすくなるし、こちらも確認ポイントを見失わない。
もう少し実務寄りにするなら、節目ごとの成果物をはっきり書く。たとえば文書作成なら、下書き、見出し案、本文、最終調整の順に分ける。ファイル整理なら、対象一覧、分類ルール、試し分け、実行、結果確認の順に分ける。
このとき、各段の終わりに「ここで止まる」と明記しておくのが効く。曖昧に「いい感じに進めて」ではだめだ。Claude Code は広く読んで進めるが、止め時まで勝手に忖度してくれるわけではない。
まず対象フォルダを見て、不要ファイル候補と残すべきファイル候補を分けてください。
この段階では削除しないでください。
一覧を出したら止まってください。
この頼み方だと、いきなり削除される事故を避けやすい。特にディスク削減や整理系は、最初の節目がないと痛い。見た目は手早く進んでいるのに、気づいたら元に戻しにくい変更が入っている、というのが一番だるい。
節目を決めるときにやりがちな失敗もある。
ひとつは、節目が多すぎることだ。細かく止めすぎると、逆に毎回の確認が面倒になる。大事なのは「迷いやすい場所」で止めることだ。全部で十回止める必要はない。最初の方向決め、危ない実行前、結果確認前後、このあたりで十分なことが多い。
もうひとつは、節目を書いたつもりで、実際には止める条件がないことだ。「適宜確認してください」では弱い。Claude Code に任せるなら、「この段階が終わったら止まる」を明文化したほうがいい。
筆者が一番まずいと思うのは、最初の依頼が長すぎて、しかも途中の優先順位が見えない形だ。そういう依頼は、Claude Code が正しく読んでも、こちらが後で「ここは先じゃない」と言い出しやすい。要するに、全文を投げる前に、節目の地図を先に描くべきだ。
これは非エンジニアの作業でも同じだ。たとえば契約書の下書きや議事録の整理でも、最初に「見出しだけ先」「要約だけ先」「本文はその後」と区切ると、修正がかなり楽になる。大量の資料整理でも、「分類案を先に出す」「移動は最後」と分けておくと事故が減る。
実際の頼み方は、こんな形にすると使いやすい。
長めの作業なので、節目を先に決めて進めたいです。
進め方は次の順にしてください。
- まず現状を確認する
- 次に方針を出す
- 私が確認したら作業する
- 作業後に結果を短く報告する
各節目で必ず止まってください。
次の段階に移る前に、私の承認を求めてください。
この型を覚えておくと、長い依頼でも崩れにくい。
さらに一歩進めるなら、節目ごとに「ここで何を判断するか」まで書くと強い。たとえば、一覧が正しいか、分類ルールが妥当か、削除候補が安全か、見出し構成が読みやすいか。止まる場所があるだけでなく、そこで何を見るかが決まっていると、確認が速い。
長い依頼は、長く書くこと自体が問題ではない。問題なのは、どこで止まるか決めずに流し込むことだ。最初に節目を決める。区切りを先に置く。これだけで、Claude Code とのやり取りはだいぶ扱いやすくなる。
雑に一発で片づけたい気持ちは分かるが、そこを少し我慢したほうが、結果的に速い。