2026-06-28

ゴールと制約を先に伝える：手戻りを減らす依頼テンプレ

「とりあえず直して」でうまくいくと思っていると、だいたい手戻りする。Claude Code は空気を読んで全部やってくれる便利屋ではない。何を終点にしたいのか、何を触ってよくて何を触るな、ここを先に渡したほうが速い。

特に Claude Code は、こちらの依頼文そのものを仕事の設計図として読む。だから、ゴールがぼんやりしていると、出力もぼんやりする。逆に、先に制約を渡すだけで、不要な調査や修正、でかい diff をかなり減らせる。ファイル整理でも文書作成でも同じだ。何を残し、何を捨て、どこまでやれば終わりかを先に言っておくのが効く。

筆者も最初は「このフォルダを見て適当に整えて」で頼んで、見事に遠回りした。見た目は整ったが、欲しかったのは重複ファイルの退避であって、構成変更ではなかった。指示が曖昧だと、エージェントは丁寧に暴れる。そこを抑えるのがこの TIPS だ。

まずは、依頼文の骨格を固定してしまうのが早い。Claude Code には、最初にこう投げる。

目的:
- 何を完成形とするかを先に決める
- 変更は最小限にする
- 既存の命名や構成は極力維持する

制約:
- 触ってよいのはこの範囲だけ: <対象フォルダやファイル>
- 変更してはいけないもの: <例: 本番設定、履歴、PDF原本>
- 出力は <例: 1 本の Markdown 文書 / 変更差分のみ / 整理後の一覧> に限定する
- 途中で不明点があれば勝手に進めず、確認質問を先に出す

やってほしいこと:
- <具体的な作業>
- <完了条件>
- <確認したい観点>

最後に、作業前に「理解したゴール」と「制約」を短く要約してから進めてください。

この形のいいところは、Claude Code に「何を優先するか」を先に渡せる点だ。例えば文書作成なら、単に「文章を直して」では足りない。むしろ、以下くらいまで言ったほうがいい。

目的:
- 顧客向け提案書を読みやすくする
- 中身の主張は変えない
- 文章の冗長さだけ削る

制約:
- 数字、日付、固有名詞は勝手に変えない
- セクション順は変えない
- 新しい論点は追加しない
- 2000字以内に収める必要はない

作業:
- 冗長な表現を削る
- 同じ意味の繰り返しをまとめる
- 見出しごとに要点が一目で分かるようにする

出力:
- 修正版本文
- どこをどう削ったかの短いメモ

この「ゴール」と「制約」を分けるやり方が肝だ。ゴールだけだと雑に広がる。制約だけだと何をすればいいかが曖昧になる。両方を置くと、Claude Code の迷いが減る。

ファイル整理でも効く。たとえば、重複しそうな資料をまとめたいなら、こんな頼み方になる。

目的:
- 仕事で使う資料を案件ごとに整理したい
- 古い版と最終版が混ざっている状態をほどきたい

制約:
- 原本は削除しない
- 移動先は /Archive にまとめる
- ファイル名の変更は最小限にする
- 画像やPDFの中身までは編集しない

作業:
- 日付付きのファイル名を優先して並べる
- 同じ内容の候補を見つけたら一覧にする
- どれを残すか迷うものは保留にして質問する

出力:
- 整理案
- 移動候補
- 保留項目

ここで大事なのは、「何をしないか」を書くことだ。Claude Code は賢いので、放っておくともっと良いやり方を探しにいく。だが、あなたが欲しいのは最良案ではなく、今の制約内で安全に終わる案だったりする。そこを外すと、やたら大きい変更や、望んでいない再構成が起きる。手戻りの多くは、能力不足ではなく、制約不足で起こる。

実務では、次の一文を足すだけでもかなり変わる。

勝手に範囲を広げないでください。
不明点は推測で埋めず、先に確認してください。
完了条件を満たす最小の変更だけを提案してください。

この手の文言は少し強めだが、効く。曖昧な依頼に対して、Claude Code が善意で広げた作業を止められる。筆者は以前、「この README を直して」とだけ投げて、関連しない設定ファイルまで整える案が出てきたことがある。内容自体は悪くないのに、作業範囲が広がるとレビューが重くなる。そういう余計な熱心さを、先に抑えるわけだ。

逆にやってはいけないのは、制約を山ほど並べて目的を消すことだ。
「触るな」「変えるな」「確認しろ」だけでは、ただの禁止文になる。Claude Code は何を完成形にすればいいのか分からない。制約はブレーキであって、ハンドルではない。必ず、最後に「何をどう終わらせたいか」を短く入れる。

うまくいく依頼は、だいたいこの順で揃っている。

1. 何を達成したいか
2. 何が許可され、何が禁止か
3. どの範囲を触るか
4. 迷ったときの扱い
5. どういう形で返してほしいか

この順に並べると、Claude Code が勝手に前提を補完しにくい。人間相手の依頼でも同じだが、エージェント相手だと効果がさらに大きい。

もう一段うまくやるなら、完了条件を見える化する。たとえば、コード修正なら「テストが通る」「既存の挙動を変えない」「差分がこのファイル群に収まる」。文書なら「見出し構成は維持」「重複表現の削減」「意味の変更なし」。整理なら「案件ごとに集約」「原本保持」「保留リスト作成」。ここが曖昧だと、終わったのか終わっていないのか分からなくなる。

Claude Code を長く使うほど、このテンプレは効いてくる。毎回ゼロから説明するより、まず骨格を置いて、案件ごとに中身だけ差し替えるほうが速い。依頼のたびに迷いを削るのが、結局いちばんの時短だ。次に使うときは、まずゴールと制約を書き分けてから投げればいい。そこから先の手戻りが、目に見えて減る。