Claude Code に何でも押しつけると、だいたい最後にしわ寄せが来る。雑に投げると、長い説明を読ませたわりに成果物が中途半端、しかも人間が後で直す羽目になる。そこを先に切り分けておくと、Claude Code はかなり使える道具になる。
Claude Code は、Anthropic の CLI コーディングエージェントだが、ここでの本質は「端末から指示して、作業をまとめて任せる相手」だという点にある。コードを書かせるだけの道具ではない。ファイルを探す、差分をまとめる、文書を整える、不要なものを洗い出す、そんな地味だが面倒な仕事に向いている。
逆に、曖昧な判断、最後の責任が重い決定、見通しの甘い大工事は苦手だ。ここを間違えると、コンテキストを無駄食いし、diff が膨らみ、手戻りが増える。筆者も最初は「全部まとめてやって」と投げて、あとで細部を直すほうが面倒になる失敗を何度かやった。便利だが、万能ではない。
Claude Code が強いのは、手元のファイルや既存の文脈を読みながら、具体的な作業に落とす場面だ。人間が「どこにあるのか」「何を直せばいいのか」を探す時間を削れる。
たとえば開発者なら、壊れたテストの原因探し、README の更新、設定ファイルの整理、既存コードの小さなリファクタリングが頼みやすい。非エンジニアでも、フォルダの中身を見て重複や不要物を洗い出す、案件ごとに文書を整理する、文章の体裁をそろえる、といった用途がある。
実際には、こういう頼み方がいちばん安定する。
このディレクトリ内の Markdown を見て、章立てをそろえてください。
内容は変えず、見出しのレベルと表記だけ統一してください。
変更前に、どのファイルをどう直すか短くまとめてください。
このフォルダの中で、同じ名前や似た名前のファイルを見つけて、重複していそうなものを一覧にしてください。
削除はまだしないで、候補だけ出してください。
このプロジェクトの README を読んで、初めて触る人がつまずきそうな説明不足を埋めてください。
既存の内容を消しすぎないで、足りないところを補う方向でお願いします。
この手の依頼は、Claude Code に向いている。やることが具体的で、対象の範囲も見えるからだ。逆に「いい感じにして」は危ない。いい感じの基準が人によって違うし、Claude Code も遠慮なく広い範囲を触り始める。
頼みごとがうまくいくかどうかは、技術の難しさより、指示の切り方で決まる。ここを雑にすると、かなりの確率で手戻りになる。
対象は「どのファイルか」「どのフォルダか」「どの種類の文書か」まで絞る。目的は「整える」「短くする」「不要物を見つける」「壊れている箇所を直す」みたいに一つにする。触っていい範囲は「内容は変えない」「削除はしない」「コード以外は触らない」など、事故防止の線を先に引く。
たとえば、書類整理ならこうなる。
この案件フォルダの中から、提出用に残すべきファイルと、アーカイブに回せるファイルを分けて考えてください。
勝手に移動や削除はしないで、候補を理由つきで出してください。
ディスク削減なら、こうだ。
このディレクトリを見て、容量を食っていそうな不要ファイルの候補を探してください。
削除ではなく、まず候補一覧と確認ポイントを出してください。
この「まず候補だけ出す」が大事だ。いきなり実行まで任せると、想定外のファイルまで巻き込む。筆者は昔、片づけのつもりで広い範囲を見せすぎて、関連ファイルの候補が多すぎて判断に迷った。人間が迷うときは、AI もだいたい迷う。範囲を切れ。
Claude Code は、局所的な作業は得意だが、最終判断の重い仕事は別だ。たとえば法務、会計、公開直前の文言調整、事故ると痛い削除や移動だ。そこは機械に丸投げしないほうがいい。
理由は単純で、Claude Code は「見えている範囲」をもとに作業するからだ。見えていない事情、組織の慣習、あとで必要になる例外処理までは勝手に分からない。だから、正しそうな答えを返しても、そのまま実行していいとは限らない。
特に危ないのは、次のような頼み方だ。
この大量のファイルを整理して、不要なものは消しておいて。
この文章を完成版にして。
このコードベースをいい感じに直して。
これだと、範囲も基準も曖昧すぎる。不要の定義がないし、完成版の条件もない。いい感じ、は人間の口癖としては便利だが、CLI エージェントへの命令としては雑すぎる。
削除や移動を頼むなら、必ず段階を踏む。候補を出させる。理由を確認する。必要なら一回レビューする。そのうえで実行させる。人間の確認を一枚挟むだけで、事故率はかなり下がる。
もう一つ、地味にやりがちなのが、最初の指示に情報を詰め込みすぎることだ。気持ちは分かるが、長文の要件を一発で全部覚えさせると、重要度がぼやける。Claude Code は読めるが、読めることと、うまく優先順位をつけられることは別だ。
筆者は以前、作業の背景、過去の経緯、例外条件、参考メモを全部一度に渡してしまい、結局「で、何を先にやればいいのか」がぼけたことがある。結果として、出力はそれなりに整っていたのに、直したいポイントに外れていた。こういうときは、最初に一つだけ頼むほうが速い。
たとえば、先にこう言う。
まずは現状の問題点だけ洗い出してください。
修正はまだしないでください。
次に、問題点を見てからこう続ける。
では、見つかった問題点のうち、影響が小さいものから順に直してください。
この二段構えのほうが、だいたい安定する。いきなり完成形を求めないことだ。
ざっくり切ると、Claude Code に向くのは「既存の材料をもとに、見つける・そろえる・書き換える」作業だ。向かないのは「事情を読み切って、責任を持って決める」作業である。
向くものの例を挙げると、こんな感じだ。
向かないものの例は、こうなる。
この線引きを頭に入れておくと、Claude Code はかなり扱いやすくなる。道具として優秀なのは、できることが派手だからではない。地味な作業を、短い指示で、手元の文脈を使って進められるからだ。
慣れてきたら、毎回ゼロから説明しないほうがいい。頼み方を型にすると、手戻りが減る。
たとえば、こんな順番だ。
1. このフォルダの中身をざっと把握する
2. 変更候補を出す
3. 変更前に確認点を短く挙げる
4. 承認したものだけ反映する
文章作成でも同じだ。
1. 元の文章を読む
2. 冗長な箇所を指摘する
3. 変更案を出す
4. 内容を変えずに整える
この形にしておけば、毎回の指示が短くなる。しかも、どこで人間が確認するかが固定されるので安心だ。Claude Code を「自動で全部やる係」にしないほうが、実際は速い。
最後に一つだけはっきり言うと、Claude Code は万能の秘書ではない。だが、作業の粒度をきっちり切れば、かなり頼れる実務ツールになる。何を頼めるかは、機能の一覧よりも、頼み方の線引きで決まる。そこを外さなければ、文書整理でもファイル整理でも、コード修正でも、かなり気持ちよく進む。