それ、なんでも丸投げできる道具だと思っているなら最初に一度つまずく。Claude Code は万能ロボットではなく、手元のファイルを読ませて、編集させて、確認させるのが得意な CLI エージェントだ。だからこそ強い。逆に、曖昧な気分相談や、外部の事実確認を雑に任せると、平気で手戻りする。
ここで大事なのは、「何を頼めるか」を機能名で覚えることではない。何を渡すと速いか、何を渡すと危ないかを線引きすることだ。これがわかると、コード修正だけでなく、書類整理、不要ファイルの洗い出し、文章のたたき台作りまで、かなり現実的に使えるようになる。
Claude Code が強いのは、すでにあるファイルやディレクトリを読んで、そこから作業を進める場面である。たとえば、こんな依頼は相性がいい。
このディレクトリ配下を見て、README を実態に合わせて直して。
古い手順、存在しないファイル名、曖昧な説明を消してほしい。
変更前に、どこをどう直すつもりか要約してから進めて。
これはコードでも文書でも同じだ。実在するファイルを読ませて、そこから整える。Claude Code は、ファイル間の食い違いを見つけたり、記述の抜けを埋めたり、重複した説明をまとめたりするのが得意である。
非エンジニアなら、こういう使い方がわかりやすい。案件ごとにフォルダを掘って、メモ、Word、PDF、メールの下書きが散らばっているときに、内容を見比べさせて「最新版っぽい書面だけ残す」「重複している下書きを一覧にする」「不要なキャッシュや大きな一時ファイルを洗い出す」といった整理ができる。手で全部開いて確認するよりずっと速い。
ただし、ここでもコツがある。最初から完成品を期待しないことだ。まずは「何があるかを把握する」「差分の候補を出す」「危ない削除は止める」という段取りに分けたほうがいい。いきなり削除まで走らせると、確認漏れで泣く。
筆者も最初、README も設定ファイルも全部まとめて直させようとして、意図しない文言まで置き換えられて手戻りした。原因は単純で、依頼が雑だったからだ。Claude Code は気が利くが、空気までは読まない。
ここを分けるだけで、だいぶ事故が減る。Claude Code への指示は、次の順で出すと安定する。
1. このディレクトリの構成を把握して
2. 関係ありそうなファイルだけを挙げて
3. 変更案を短く説明して
4. そのうえで編集して
5. 最後に diff の要点をまとめて
要は、最初から「直して終わり」にしないことだ。CLI で動く道具は、目の前のテキストを処理するのは速いが、目的が曖昧だと遠回りする。人間のほうが先に地図を描いてやると、無駄な探索が減る。
文章作成でも同じだ。たとえば社内向けの手順書を整えるなら、こう書けばいい。
この手順書を、初見の人向けに書き直して。
ただし、事実関係は元の文書とファイル内の記述だけを使って。
勝手に手順を増やさず、あいまいな箇所は「要確認」と明記して。
この「勝手に足さない」という縛りが重要だ。Claude Code は、穴埋めをしようとすることがある。空白を見つけると、つい自然な文章で埋めたくなるのだ。だが実務では、その自然さが危ない。特に手順書や対外文書では、わからないところをわからないままにしておくほうが正しい。
ここで線を引いておく。Claude Code は、手元のファイルをもとに作業するのが本業である。だから、次のような頼み方は弱い。
こういう依頼は、材料が薄い。CLI の中だけで完結する道具に、外部調査の責任まで乗せると、話が崩れる。もちろん、ブラウジングや外部情報の扱いが絡むケースはあるが、仕様や可否は使っている版や設定で変わりうる。そこは公式ドキュメントで確認したほうがいい。docs.claude.com を見れば、今の動きに寄せて判断できる。
筆者が一度やらかしたのは、議事録もソースもないまま「この件の要点を整理して」と投げたことだ。出てきた文章は、それっぽいが中身が薄かった。材料がないのだから当然である。人間でも苦しい仕事を、道具だけに押しつけても仕方がない。
Claude Code は、条件が明確な仕事で強い。たとえば以下だ。
src 配下の TypeScript を見て、型エラーの原因候補を挙げて。
修正は最小限にして、振る舞いを変えないこと。
変更後は、どのファイルをどう直したかを短く説明して。
あるいは、非エンジニアの整理作業ならこうだ。
このフォルダの中で、更新日が古い下書きと重複しそうなファイルを挙げて。
削除はまだしないでいい。候補を理由つきで並べて。
ポイントは、何をもって成功とするかを先に書くことだ。最小限の変更、既存表現を維持、削除は保留、理由を添える。こうした条件があると、Claude Code は無駄に広がらない。逆にここを省くと、親切心で余計な整形をしてきて、差分がでかくなる。
差分が肥大化するのは地味に面倒だ。レビューしづらいし、どこが本質の変更かわからなくなる。筆者はこれで一度、本文の修正を頼んだつもりが、空白や改行まで広く整えられて、確認だけで疲れた。内容より見た目の差分が増えると、作業の意味が薄れる。だから「余計な整形をしない」と明記しておくのが効く。
Claude Code に任せやすいが、慎重に扱うべきなのは削除系の仕事である。重複ファイルの掃除、不要キャッシュの整理、古い下書きの削除候補出し。ここは便利だが、勢いで消させてはいけない。
安全な流れはこうだ。
このディレクトリから、サイズが大きくて不要そうなファイル候補を挙げて。
削除はしないで、候補と理由だけ出して。
確信度が低いものは残す前提で扱って。
削除してよい候補を出したら、必ず最終確認を待ってから実行して。
実行前に、削除対象をもう一度一覧で表示して。
この二段階が大事だ。最初から消させない。候補を見て、人間が止める余地を残す。ファイル整理は、スピードよりも取り返しがつくことのほうが大事である。
特にディスク削減では、見た目の重複と実害のある重複が混ざる。似た名前のファイルがあっても、片方が最終版とは限らない。フォルダ構成を見た目だけで判断させると危ない。だから「このプロジェクトで実際に参照されているファイルを優先して残して」と添えるとよい。依存関係のあるものを消されにくくなる。
Claude Code は文章も書けるが、ここで勘違いすると失敗する。完成文を一発で出させるより、素材作りに使うほうが強い。議事録の要約、手順の整形、古い説明の更新、表現の統一。そういう仕事に向く。
たとえば、社内説明文を整えるならこうだ。
この文章を、初見の人に伝わる順番へ並べ替えて。
ただし、専門用語は減らしてもいいが、意味は変えないで。
曖昧な表現は削って、必要なら短い注釈を付けて。
逆に、最終版の文章をそのまま任せきりにするのは危ない。特に対外文書では、事実関係、肩書き、日付、数値を人間が確認しないといけない。Claude Code は、文章の見栄えを整えるのはうまいが、責任までは取らない。
実務で効くのは、たたき台を出させたあと、自分で直す前提で使うやり方だ。これだとゼロから書くより早いし、内容の抜けにも気づきやすい。筆者は、この用途で一番時間を節約できた。反対に、完成を期待して頼むと、微妙にずれた文章を直す時間が発生する。そこが地味にだるい。
最後に、使い分けを一文で切る。
手元のファイルを読んで、編集して、差分を出す仕事は任せていい。
外の情報を集める仕事、曖昧なまま答えを作る仕事、確認なしの削除や上書きは任せない。
この線さえ守れば、Claude Code はかなり頼れる。開発者ならコード修正や設定整理に効くし、非エンジニアなら文書整理やファイル棚卸しにも使える。要するに、道具の得意領域を外さないことだ。
迷ったら、こう考えるといい。
「今やりたいのは、読ませる作業か、決めさせる作業か」。
前者なら向いている。後者なら、人間が先に決めてから渡すべきである。