長い依頼ほど、最初に雑に投げると詰まる。
「これも、あれも、ついでにこれも」と広げた時点で、Claude Code のコンテキストはじわじわ削られ、返ってくる結果もぼやける。作業範囲の宣言、つまりスコープを切る作業を先にやるだけで、手戻りはかなり減る。
Claude Code は、雑な長文を全部いい感じに解釈してくれる魔法の箱ではない。むしろ逆で、何をやるかと同じくらい、何をやらないかを明示したほうが強い。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初に一枚のメモで範囲を固定しておくと、あとから「そこは触らなくていい」「その形式では出さない」と毎回言い直さずに済む。
やることは単純だ。Claude Code に本題を投げる前に、まず自分の頭の中で依頼を分解して、次の4つを短く書く。
たとえば、フォルダ整理ならこうなる。
目的: 案件フォルダを見直して、重複や不要ファイルを減らしたい
対象: /Users/me/Documents/案件A
やること: ファイル名の重複候補を洗い出す。不要な一時ファイルを候補として挙げる。削除前に確認リストを作る
やらないこと: 勝手に削除しない。中身が不明なファイルは消さない。フォルダ構成は変えない
この程度で十分だ。立派な企画書にする必要はない。重要なのは、Claude Code が勝手に話を広げる余地を減らすことだ。人間相手でも、最初に「どこまでやるか」を決めない案件はだいたい揉める。CLI でも同じである。
筆者は以前、文書修正を頼むときに「読みやすく整えて」とだけ投げて、見出しの付け替え、表現の統一、段落再編まで全部走らせてしまった。結果、直したい一箇所より先に、触らなくていい場所まで広がって戻ってきた。あれは完全に依頼の切り方が悪かった。範囲を先に決めていれば、コンテキストも差分ももっと小さく済んだはずだ。
スコープは、自分用メモとして書くだけでも効くが、Claude Code にそのまま渡すとさらに安定する。ポイントは、最初から「一回で全部やれ」と言わないことだ。まず範囲を確認させる。
以下の作業を始める前に、作業範囲を整理して短く確認してください。
目的:
- 案件フォルダ内の不要ファイル候補を洗い出す
やること:
- 重複しそうなファイル名を拾う
- 明らかな一時ファイル候補を挙げる
- 削除候補は一覧にまとめる
やらないこと:
- 勝手に削除しない
- フォルダ構成を変えない
- 内容が判断できないファイルは触らない
まず、あなたが理解した作業範囲を3〜5行で要約してから、進め方を提案してください。
この頼み方のいいところは、Claude Code が「自分は何をする役か」を先に言語化する点にある。曖昧な依頼をそのまま実行させると、余計な補助作業まで含めた広い解釈になりやすい。範囲確認を先に挟むと、ズレを早めに潰せる。
文書作成でも同じだ。
以下の文章を整えてください。
目的:
- 社内向けの案内文を読みやすくする
やること:
- 表記ゆれを減らす
- 冗長な言い回しを削る
- 段落の順番を少し整える
やらないこと:
- 内容の追加
- トーンの変更
- 意味の強い言い換え
変更した箇所だけを示してください。全文の再掲は不要です。
この最後の一文が地味に効く。全文を毎回再掲させると、差分が見えにくくなる。修正点だけ出させたほうが、確認コストが下がる。
やることだけ書いて、やらないことを書かない依頼は危ない。Claude Code は善意で広げる。そこが困る。
たとえば「ファイルを整理して」とだけ言うと、重複候補の発見だけでなく、ファイル名の正規化やフォルダ再編成まで候補に上がることがある。便利そうに見えるが、実際には迷子の入口だ。人間のほうが「そこまでは要らない」と判断し直す羽目になる。だから、禁則をはっきり書く。
やらないこと:
- ファイル名の変更
- 移動
- 自動削除
- 内容の編集
この書き方は少し味気ないが、実務ではこれでいい。むしろ味気ないくらいのほうが事故が少ない。
非エンジニアの用途でも、ここはかなり効く。たとえば弁護士が案件フォルダを整理するなら、「案件Aの資料を読みやすく並べる」だけでは足りない。勝手にリネームされたり、証拠ファイルをまとめられたりすると困る。最初に「案件番号の付いた既存ファイル名は変えない」「原本フォルダは触らない」と書いておけば、余計な事故をかなり避けられる。
長文の依頼は、そのまま書くとひとまとまりに見えて、実は複数の仕事が混ざっていることが多い。ここを分けないと、Claude Code は一度に全部を解釈しにいく。結果、どれも中途半端になる。
そこで、最初に区切りを入れる。
次の順で進めてください。
1. 作業範囲を確認する
2. 対象ファイルを列挙する
3. 変更前の確認事項を出す
4. 実作業に入る
各 चरणごとに止まって確認してください。勝手に次へ進まないでください。
この「止まって確認」が重要だ。長い依頼では、途中で前提がズレても気づきにくい。確認点を節目ごとに作るだけで、失敗したときの修正範囲が小さくなる。
筆者は以前、複数の文書を一括で整えるときに、先頭で「必要なら整えて」と曖昧に書いたせいで、各ファイルの粒度が揃わず、結局あとで人間が見直すことになった。最初に「どこまで整えるか」を一枚に書いていれば、その手戻りは防げた。長い依頼でいちばん高くつくのは、実は処理時間ではなく確認のやり直しだ。
きれいに作る必要はないが、最低限の型はある。自分のメモでも、Claude Code に渡す指示でも同じだ。次の順番に並べると扱いやすい。
目的:
- 何を達成したいか
対象:
- どのフォルダ、どのファイル、どの文章か
やること:
- 実際にしてほしい処理
やらないこと:
- 触らない範囲、変えない条件
出力形式:
- 一覧だけ、差分だけ、要約だけ、など
確認タイミング:
- 事前確認が必要か
- 途中で止めるか
- 最後だけ見せるか
この型のいいところは、非エンジニアにもそのまま使えることだ。ディスクを空けたいなら、対象は「ダウンロードフォルダ」「重複動画」「巨大なキャッシュ」になる。やることは「候補を洗い出す」。やらないことは「勝手に消さない」。これだけで十分実用になる。
スコープを切るといっても、何でも厳密にすればいいわけではない。単純な文章整形なら、やらないことは2つか3つで足りる。危険な削除や移動が絡むなら、もっと厳しくする。要するに、事故ったときに戻しにくい作業ほど、先に縛る。
ファイル削除のような作業では、次のように書いておくとよい。
削除候補を出すだけにしてください。実行はしないでください。
削除前に、候補の理由と確認方法を並べてください。
曖昧なものは保留にしてください。
文書作成なら、ここまで縛らなくていい。
見出しの順番は変えてよいが、意味は変えないでください。
文章は短くしてよいが、断定を弱めないでください。
このくらいの緩急をつけると、Claude Code は無駄に暴れない。逆に、何でもかんでも禁止すると、今度は修正の自由度がなくなって使いにくい。締めるところだけ締めるのがちょうどいい。
長い依頼をその場で書き始める前に、まず一枚で範囲を切る。これだけで、作業の精度も、確認の速さも、かなり変わる。雑に広げるより、先に狭く決めたほうが最後まで楽だ。Claude Code を使うほど、この差は効いてくる。