Claude Code に仕事を投げるとき、いちばん効くのは難しい命令ではありません。
「何を直すのか」と「どこまで触ってよいのか」を、先に狭く決めることです。
このひと手間で、生成された差分を読みやすくできるし、意図しないファイルまで触られる事故も減ります。
エンジニアならリファクタリングや機能追加の前さばきに使えます。非エンジニアでも、文書整理、重複ファイルの洗い出し、フォルダ内の資料の整形にそのまま効きます。
曖昧な依頼が弱いのは、Claude Code がサボるからではなく、境界がないからです。
「このフォルダだけ」「このファイル群だけ」「本文だけ直して、見出し構成は変えない」のように、先に線を引くと結果が安定します。
たとえば、README の整備ならこう書けます。
次の作業をしてください。
対象:
- docs/README.md
やってほしいこと:
- 導入文を短くする
- 見出しの順番は変えない
- 手順の重複を減らす
- 文章は日本語のまま、意味は変えない
やらないこと:
- コード例は変更しない
- 他のファイルは触らない
- 新しい機能説明を勝手に足さない
完了条件:
- README だけが更新されていること
- 変更理由が差分で追えること
この書き方の肝は、命令を増やすことではなく、余計な解釈を減らすことです。
「改善して」「いい感じにして」は、便利そうに見えて一番広い依頼です。Claude Code は賢いので広い依頼でも動きますが、広いぶん戻りも広くなります。
非エンジニアの使い道でわかりやすいのは、散らかったフォルダの整理です。
たとえば、案件フォルダの中から古い書類の重複候補を見つけたい、ダウンロードフォルダから不要そうなキャッシュを洗いたい、議事録の表記をそろえたい、といった作業です。
ここで大事なのは、削除まで任せるのか、候補出しだけにするのかを分けることです。いきなり消させるより、まず一覧を作らせるほうが安全です。
Downloads フォルダの整理を手伝ってください。
対象:
- Downloads フォルダ配下のファイル名と更新日を見て、不要そうな候補を整理する
やってほしいこと:
- 似た名前の重複候補を挙げる
- 期限切れっぽいファイルを候補として挙げる
- 削除ではなく、候補リストを作る
やらないこと:
- 何も勝手に削除しない
- 写真や書類の中身を前提に断定しない
- システムファイルには触らない
出力:
- 残す候補
- 確認が必要な候補
- 迷う理由
こうしておくと、Claude Code は「削除してよいファイル」を決める役ではなく、「人が判断しやすい材料を整理する役」になります。
この役割分担が大切です。作業の責任線を曖昧にしないほうが、結局は速い。
「このプロジェクトを直して」と書くと、Claude Code はプロジェクト全体を見に行きます。
それ自体は悪くありませんが、意図した範囲より広がりやすい。そこで、単位を一段細かくします。
たとえば、アプリの文章修正なら「src/ 以下は触ってよいが、設定ファイルは触らない」と切る。
WordPress のような構成なら「記事本文の Markdown だけ」「画像ファイルは除外」と決める。
書面作成なら「第2章の見出しと本文のみ」「引用はそのまま」と限定する。
次の範囲だけ作業してください。
触ってよい範囲:
- article.md
- notes/ 以下のメモ
触ってはいけない範囲:
- 設定ファイル
- 画像
- ほかの記事
作業内容:
- 記事の重複表現を整理する
- 見出しの粒度をそろえる
- ただし、内容の追加はしない
この「範囲指定」は、Claude Code の出力を読む側にも効きます。
あとで差分を見たとき、「なぜここが変わったのか」を追いやすくなるからです。
曖昧な依頼のもう一つの問題は、作業と判断が混ざることです。
たとえば「古いファイルを消して」とだけ言うと、何をもって古いとするかを Claude Code が決めなければなりません。
そこで、判断基準を先に渡します。
次のルールで候補を整理してください。
古いとみなす条件:
- 更新日が 1 年以上前
- かつ、ファイル名が draft, old, backup のいずれかを含む
ただし次は残す:
- 署名済みの契約書
- 最終版とわかるファイル
- 手動で確認が必要な書類
最終判断は人がします。あなたは候補一覧を作ってください。
この書き方なら、Claude Code は迷いにくくなります。
「古い」の定義がない依頼は、思った以上にあちこちに飛びます。逆に、ルールが少しでもあると、結果の再現性が上がります。
何をするかだけでなく、何を返してほしいかも指定すると使いやすくなります。
特に文書整理や棚卸し系では、長い説明より、あとで見返せる一覧のほうが役に立ちます。
たとえばこんな具合です。
返答は次の形にしてください。
1. 変更したファイル名
2. 変更の要点を 1 行ずつ
3. 確認が必要な点
4. 手を付けなかったもの
長い説明は不要です。差分確認に使いたいです。
これは見落とされがちですが、かなり効きます。
依頼が曖昧だと、作業そのものだけでなく、返答まで散らかります。反対に、返答の形を固定すると、Claude Code を「作業者」ではなく「整理された下書きを返す相棒」として扱えます。
一度に全部やらせると、境界が広すぎて崩れます。
その場合は、ひとつの依頼で「調査」「修正」「最終確認」を全部やらせないことです。
順番はこうしたほうが安定します。
1. まず対象ファイルの候補を挙げる
2. 次に、変更案を出す
3. 最後に、了承した範囲だけ反映する
この分け方は、エンジニアのコード修正でも、非エンジニアの文書整理でも同じです。
たとえば大量の議事録を直すなら、先に「どのファイルを直すか」を出させ、次に「表記ルールをそろえる案」を見てから、最後に実行させる。
いきなり一括で触らせない。これだけで事故率がかなり下がります。
人は「やってほしいこと」ばかり書きがちです。
でも、Claude Code にとって効くのは、しばしば「やらないこと」です。
文章なら、勝手な言い換えをしない。
資料なら、構成を変えない。
ファイル整理なら、削除しない。
コードなら、対象外のモジュールを触らない。
この禁止事項があるだけで、作業の輪郭が締まります。
やってほしいこと:
- 文章の冗長表現を減らす
やらないこと:
- 意味の追加
- 構成変更
- 他ファイルの修正
- 自動削除
「何を・どこまで」を渡す、というのは、実は命令を増やす話ではありません。
広すぎる依頼を、あとから責めるのではなく、最初に狭くしておく。そのほうがずっと実用的です。
Claude Code を使うたびに、依頼文を少し整えるだけで結果が変わります。
毎回長文にする必要はありません。対象、禁止事項、完了条件。この三つが入っていれば、だいぶ違います。
仕様の細部や最新の挙動は、公式ドキュメント（docs.claude.com）で確認すると安心です。
ただ、依頼の組み立て方そのものは変わりません。曖昧に投げない。ここを押さえるだけで、Claude Code はかなり扱いやすくなります。