Claude Code に作業を頼むとき、いちばん効くのは「何を作るか」だけでなく「何をしないか」まで先に渡すことです。
ゴール、制約、成功条件、触ってよい範囲を最初に揃えると、やり直しが減ります。ファイル整理でも、文書作成でも、コード修正でも効きます。
たとえば、ただ「このフォルダを整理して」と頼むと、見た目は整っても、必要なものまで移動されたり、命名が勝手に変わったりします。
逆に、目的と境界を先に書くと、Claude Code は判断しやすくなります。人に仕事を頼むときと同じで、曖昧さを減らすほど返答の精度が上がります。
依頼文の骨格はシンプルです。次の4点を最初に置きます。
この順で書くと、相手は「何を達成すればよいか」と「どこまで手を出してよいか」を先に理解できます。
Claude Code はターミナル上でファイルを読んだり編集したりできるので、境界が曖昧だと、意図しない変更が入りやすくなります。
たとえば、文書整理ならこんな依頼です。
目的: 取引先向け提案書のたたき台を、読みやすく短くしたい。
制約: 内容の事実関係は変えない。固有名詞はそのまま。口調は丁寧語。
成功条件: 3ページ以内で要点が伝わること。
変更してよい範囲: 見出し構成、重複表現、文章の順番。
これだけでも、返ってくる提案の質はかなり変わります。
「短くしたい」だけでは、勝手に大幅削除されることがあります。どこを守るべきかを明示すると、安心して任せられます。
実際には、毎回きれいに書こうとしなくて大丈夫です。次の型をそのまま使えます。
次の作業をしてください。
目的:
-
制約:
-
成功条件:
-
変更してよい範囲:
-
変更しないでほしいもの:
-
必要なら最初に確認してほしいこと:
-
このテンプレのよいところは、非エンジニアでも埋めやすいことです。
たとえば、弁護士が案件ごとにフォルダを分けて書面を整えるなら、こう書けます。
目的:
- 依頼人ごとの資料フォルダを見やすく整理したい。
制約:
- 事件番号が付いたファイル名は変えない。
- PDFの中身は触らない。
- 削除はせず、まずは移動候補を示す。
成功条件:
- 案件ごとにまとまっていて、探しやすい状態になる。
変更してよい範囲:
- フォルダの並び替え。
- 重複しない補助資料の整理。
変更しないでほしいもの:
- 署名済み書面。
- 送付済みファイル。
この書き方だと、「全部やって」ではなく「ここまでは任せる、ここから先は触らない」が伝わります。
ファイル整理やディスク削減の作業でも同じです。不要なキャッシュ候補を洗ってほしいときは、まず削除ではなく一覧化から始めると安全です。
目的:
- ディスク使用量を減らしたい。
制約:
- 重要な書類、写真、メッセージ履歴は消さない。
- まず候補を出し、削除前に確認したい。
成功条件:
- 容量を食っているものが分かる。
- 安全に消せる候補だけが分離される。
変更してよい範囲:
- 一時ファイル、重複ファイル、古いダウンロード。
変更しないでほしいもの:
- 個人書類。
- 作業中のデータ。
手戻りが多い依頼は、たいてい禁止事項が足りません。
Claude Code は指示に沿って広く動けるぶん、余計な整形や勝手な改善も起こりえます。そこで、やらないことをはっきり書きます。
たとえば文書作成なら、こんな一文が効きます。
見出しの追加はしてよいですが、事実の追加、固有名詞の変更、表現の言い換えで意味が変わる修正はしないでください。
コード作業なら、次のように境界を切ります。
既存の動作を変えず、エラー修正に必要な最小限の変更だけをしてください。
リファクタリングやファイル移動は不要です。
この「不要です」を入れるだけで、返答がかなり落ち着きます。
見た目の改善よりも、目的に関係する変更だけを優先してほしいときに特に有効です。
依頼の精度を上げるには、最初から実行させるより、確認を挟んだほうが安全な場面があります。
Claude Code に「不明点があれば先に質問して」と添えると、推測で進むのを減らせます。
不明点があれば、作業を始める前に質問してください。
曖昧なまま進めず、確認してから着手してください。
この一言は、特に次のような場面で効きます。
確認を挟むのは遠回りに見えますが、やり直しを一回減らすだけで元が取れることが多いです。
制約だけ並べると、ただの禁止リストになってしまいます。
その制約がなぜあるのかも少し書くと、Claude Code が判断しやすくなります。
変更前に確認してほしい。提出期限が近く、構成を大きく変える余裕がないため。
ファイル名は変えないでほしい。外部システムがその名前で参照しているため。
理由があると、例外対応が必要なときにも判断しやすくなります。
「絶対にダメ」ではなく、「なぜそうしてほしいのか」が伝わるからです。
次のような頼み方は、あとで揉めやすいです。
いい感じに整えて
使いやすくして
とりあえず片づけて
人間同士なら雰囲気で伝わることもありますが、ターミナル上の作業では危険です。
「いい感じ」は人によって全然違います。Claude Code にとっても同じです。
置き換えるなら、こうします。
目的: 取引先に送る前提で、読みやすく整えたい。
制約: 内容は変えない。専門用語は残してよい。
成功条件: 初見でも流れが追える。
ふわっとした依頼を、目的と制約に分解するだけです。
この一手間で、返答の修正回数が目に見えて減ります。
慣れてきたら、単なる制約だけでなく、優先順位も渡すと便利です。
たとえば「正確さを最優先」「見た目より安全性を優先」「短さより読みやすさを優先」のように書きます。
優先順位:
1. 正確さ
2. 元の意味を保つこと
3. 読みやすさ
4. 短さ
この順番があると、Claude Code が迷ったときの振る舞いが安定します。
「短くしすぎて意味が落ちる」みたいな事故を減らしやすいです。
文書作成でも、ファイル整理でも、コード修正でも効く考え方です。
依頼文は命令文ではなく、判断材料のセットとして渡す。そう考えると、手戻りはかなり減ります。