「いい感じにやって」で済むと思っていると、だいたい遠回りになる。Claude Code も例外ではない。
雑に投げると、広く見に行きすぎる。触ってほしい範囲がぼやけるから、無駄にファイルを読み、無駄に大きな差分を作り、あとで「そこじゃない」を直す羽目になる。筆者も最初はこれで何度か手戻りした。頼み方が曖昧だと、エージェントは親切に広く動く。親切さが、そのままコンテキストの浪費になるわけだ。
Claude Code に渡すべきなのは、ふわっとした願望ではない。「何を」「どこまで」「何は触らないか」だ。これを先に切るだけで、作業の速さが変わる。コード修正だけの話ではない。ファイル整理、重複削除の候補出し、文章の整形、案件フォルダの整理でも同じだ。
たとえば、こういう投げ方は弱い。
このプロジェクトを見て、使いやすくして。
これでは広すぎる。何を直すのか分からない。UIなのか、READMEなのか、不要ファイルの削除なのか、テスト追加なのか、全部あり得る。Claude Code は勝手に範囲を解釈するが、その解釈があなたの頭の中と一致する保証はない。
代わりに、最初の一文で範囲を切る。
src/app/ 配下だけを見て、起動時のエラー原因を探して。
他のディレクトリは触らないで。
まず原因候補を3つ挙げて、必要なら最小修正だけ入れて。
この書き方のいいところは、曖昧な「改善」ではなく、対象と上限をはっきりさせている点だ。
「src/app/ 配下だけ」「他は触らない」「まず候補を3つ」まで入っているので、Claude Code は調査の深さを抑えやすい。結果として、読むファイルが減る。差分も小さくなる。確認もしやすい。
非エンジニアの使い方でも同じだ。たとえば、散らかった書類フォルダを整理したいなら、こう言えばいい。
このフォルダ内のPDFだけを対象にして、
請求書と契約書を分けたい。
重複していそうなファイル名を候補として挙げて、
削除は自分の確認待ちにして。
フォルダ構成は勝手に大きく変えないで。
ここで大事なのは、「やってほしいこと」と「勝手にやらないこと」を同時に書くことだ。
“整理して” だけだと、分類、リネーム、移動、削除の全部を勝手にやりかねない。自動化は便利だが、境界線がない自動化はただの事故だ。
実務で効くのは、依頼を三段に分けるやり方だ。
最初に、対象を固定する。
対象は docs/specs/ 以下のMarkdownだけ。
次に、ゴールを一つだけ置く。
見出しの重複を直して、読みやすくしたい。
最後に、制限を書く。
本文の意味は変えない。
大きな書き直しはしない。
差分が大きくなりそうなら止まって確認を取る。
この三つがそろうと、Claude Code はかなり扱いやすくなる。逆に、ゴールが複数あると途端にぶれる。たとえば「読みやすくしたい」と「文章量を減らしたい」と「表現を堅くしたい」を一度に入れると、どれを優先するかで揺れる。人間でも迷う。エージェントならなおさらだ。
筆者が一度やらかしたのは、修正範囲を指定せずに「テストを直して」と投げたことだ。結果、関連しそうなファイルを広く見に行って、思った以上に差分が膨らんだ。しかも本当に直したかったのは一箇所だけだった。こういうときは、先にファイル名やディレクトリを出しておいたほうが圧倒的に早い。
tests/auth/login.test.ts だけを直して。
本体コードは今回は触らないで。
失敗しているケースは 2 つあるので、そのうち 1 つだけ先に直して。
「どこまで」を渡すときは、量の上限も言うと強い。
たとえば、次のように書く。
修正は1ファイルに収めて。
増やすコードは最小限にして。
新しい依存は追加しないで。
この手の制約は地味だが効く。Claude Code は丁寧に仕事をしようとするので、説明が足りないと“ついでの整備”までやりがちだ。だが、今ほしいのは整備ではなくピンポイント修正であることが多い。特に、時間がないときは余計な整え直しがいちばんだるい。
もう一つ、地味に効くのが「確認してから進めて」と書くことだ。いきなり改修に入ってほしくないときは、まず方針だけ出させる。
まず変更方針だけ示して。
実際の編集はまだしないで。
不明点があれば先に質問して。
これを挟むだけで、思いつきの改修を防げる。
特に、削除や移動を伴う作業ではこの一段階が重要だ。ファイル整理でよくあるのは、「片付けて」と言ったら必要なものまで別の場所に動かされる事故である。先に方針を確認すれば、そういう雑な事故をかなり減らせる。
逆に、やってはいけないのは「全部任せる」ことだ。全部任せると、全部が対象になる。
全部が対象になると、結果の検証も全部必要になる。そこで人間側の確認コストが跳ね上がる。Claude Code を使う意味は、作業を肩代わりさせることではなく、確認しやすい単位に切ることにある。
依頼文の型としては、次の順番が使いやすい。
1. 対象: どのファイル・どのフォルダか
2. 目的: 何を達成したいか
3. 制限: 何を触らないか、どこまでで止めるか
4. 進め方: 先に確認か、すぐ編集か
この順で書くと、曖昧さがかなり減る。
たとえば、文書作成ならこうだ。
対象は proposal.md だけ。
目的は、読み手が最初の3分で要点をつかめるようにすること。
本文の事実関係は変えない。
見出しの順番整理と、冗長な段落の圧縮だけやって。
編集前に、変える箇所の一覧を先に出して。
たとえば、ディスク整理ならこうなる。
対象は Downloads/ の中だけ。
目的は、不要な重複ファイルの候補を洗い出すこと。
削除はしない。
サイズの大きい順に候補を出して、最終判断は自分でやる。
この「削除はしない」はかなり効く。
Claude Code は判断材料を集めるのは得意だが、破壊的な操作を雑に任せるのは危ない。特に、ファイル整理は一度消すと戻しづらい。だから、まずは候補出しに止める。ここを守るだけで事故率が下がる。
少し進めた使い方をするなら、依頼を一回で終わらせないことだ。最初は範囲を絞り、次に詳細を足す。
まずは対象ファイルを列挙して。
次に、変更候補を優先度順に並べて。
最後に、実際の編集に進んでいいか確認して。
一発で完成形を求めるより、このほうが安定する。
Claude Code は指示が具体的になるほど強い。裏返すと、曖昧な一発投げには弱い。ここを勘違いすると、毎回「なんか違う」が出る。
最後に、迷ったらこの一文を足せばいい。
迷ったら手を広げず、まず最小の変更で進めて。
この一文は雑に見えて強い。無駄な修正を増やさない。コンテキストを食い荒らさない。差分が太りにくい。Claude Code を使うときは、賢くさせるより、暴れないように囲うほうが成果が出る。
「何を」「どこまで」を先に渡す。これだけで、頼み方の半分は終わりだ。残り半分は、触らせない範囲をちゃんと決めることになる。そこまでやれば、だいぶ外さなくなる。