雑に「これやって」で投げると、Claude Code はだいたい余計なものまで触る。そこが一番もったいない。
Claude Code に仕事を渡すときは、最初に「材料」と「判断基準」を分ける。別名で言えば、最初に使う材料と使わない材料を分けて渡す、である。これをやるだけで、コンテキストの浪費が減るし、手戻りも減る。ファイル整理でも、コード修正でも、文章作成でも効く。むしろ非エンジニアの作業ほど効く。何を見ればいいのか、何を見なくていいのかが曖昧だと、AI はだいたい親切すぎる方向に暴れるからだ。
たとえば、フォルダ内の散らかった書類を整理したいなら、Claude Code に必要なのは「対象フォルダの一覧」「残したい条件」「消したい条件」だ。逆に、関係ない過去案件や別部署の資料まで全部渡すと、判断のノイズになる。コード修正でも同じで、修正対象のファイル、参照してよい設定、守るべき制約が材料になる。一方で、「見てもらうと迷うだけの古い実装」「今回の作業に関係ないログ」「趣旨の違うメモ」は切り離す。ここをサボると、モデルの賢さより先に入力の雑さで負ける。
実際の頼み方は、こういう形にすると扱いやすい。
目的:
請求書フォルダのPDFを整理したい
材料:
- 2024/01〜2024/12 の請求書PDF
- ファイル名
- 既に手元でメモしてある重複候補の一覧
判断基準:
- 同じ請求先・同じ日付・同じ金額のものは重複として扱う
- 送付済みの最終版だけ残す
- 下書き、古い版、スキャン失敗の薄い画像は別フォルダへ移す
- 削除は最後に確認を取ってから行う
やってほしいこと:
1. まず重複候補を一覧にする
2. 迷うものは削除せず保留にする
3. 最後に、残すファイルと移すファイルを分けて提案する
これが「材料」と「判断基準」を分ける、という話の芯だ。材料は、Claude Code が実際に触る情報。判断基準は、どう選ぶかのルールである。両方をひとまとめにすると、指示文が長いわりに弱い。逆に分けると、指示が短くても通る。
コードの作業でも考え方は同じだ。筆者は昔、修正したいファイルだけを渡したつもりで、ログや試行錯誤のメモまで一緒に突っ込んだことがある。結果、Claude Code はそのメモに引っぱられて、古い方針に寄った提案をしてきた。人間から見ると「いや、そこじゃない」が、AI からすると全部同じ重みで見えてしまう。だから、見るべき材料と、見ないほうがいい材料は切っておくのが正解だ。
コードレビューや修正依頼なら、こう整理すると迷いが少ない。
材料:
- src/app.ts
- src/lib/validator.ts
- テスト失敗のログ
- 仕様メモの最新版
判断基準:
- 挙動は変えすぎない
- 既存の関数名はなるべく維持する
- 変更は最小限にする
- 新しいライブラリは追加しない
依頼:
仕様メモの最新版を基準に、失敗している入力検証を直して。
修正案は最初に要点だけ出して、そのあと差分の形で見せて。
ここで大事なのは、「材料」と「判断基準」を同じ粒度で並べないことだ。材料は具体物だ。ファイル名、フォルダ、文章、ログ、一覧、スクリーンショットの代わりになるテキスト情報。判断基準は選び方だ。残す、消す、優先する、変えない、最小限にする、確認を挟む。ここを混ぜると、依頼がぼやける。
ありがちな失敗は、「全部を材料として渡したのに、最後に口頭で“適当にいい感じで”と添える」パターンだ。これはかなり危ない。適当でいいなら、AI は広く見ようとする。広く見れば見るほど、余計な差分や不要な候補が増える。Claude Code は雑な仕事をしないが、雑な指示に対しては遠慮なく広く動く。ディスク削減のためのファイル整理で、消さなくていいものまで候補に上がったら嫌だろう。文章作成でも、下書きの癖まで拾われると困る。判断基準は、最初に固定してしまうのが楽だ。
実務では、材料と判断基準をこう分けると強い。
材料:
- いまあるファイル一覧
- 既存の文章
- 参照してほしい仕様
- 直近のエラー表示
判断基準:
- 既存の構成はなるべく崩さない
- 重複は統合する
- 古い版より最新の内容を優先する
- 迷ったら削除せず保留にする
この書き方の利点は、あとから見返したときにも分かりやすいことだ。何を渡したのか、何で選ばせたのかが一目で分かる。Claude Code は一度に全部を覚える道具ではない。見せる材料を絞り、判断基準を明示する道具だと思ったほうがいい。
なお、判断基準を細かくしすぎると、今度は人間が縛られる。そこはやりすぎないほうがいい。たとえば「命名規則は厳守」「差分は5行以内」「コメントは増やさない」まで全部盛ると、かえって窮屈になる。最初は大きな軸だけで十分だ。迷ったら、結果を見て次回の判断基準を足せばいい。Claude Code の使い方は、最初から完璧な一発勝負にしないほうがうまく回る。
この分け方は、非エンジニアの作業でもそのまま使える。たとえば、案件フォルダの整理なら「材料」は対象フォルダの中身、「判断基準」は残す条件と退避条件だ。文書作成なら「材料」は下書き・箇条書き・参考資料、「判断基準」は文体・用途・長さ・避けたい表現になる。どちらも、最初に分けておけば、後から修正が入っても崩れにくい。
Claude Code に仕事を渡すときは、まず材料を置く。次に判断基準を置く。順番を守るだけで、出てくる結果はかなり変わる。あいまいなお願いを減らすというより、AI が迷わない入口を作る感覚に近い。ここを押さえておくと、無駄な往復が目に見えて減る。