Claude Code 活用 TIPS 記事インデックス

Claude Code を使っていて厄介なのは、作業そのものより「なぜそうしたか」が消えることだ。あとで差分だけ見ても、削除した理由、残した理由、別案を捨てた理由が見えない。これが積み重なると、作業は進んでいるのに自分だけが置いていかれる。 そこで使うのが、判断理由の記録、つまり意思決定ログだ。Claude Code に「何をしたか」だけでなく「なぜその選択にしたか」を残させる。これだけで、あとから見返したときの迷い方がかなり変わる。特に、ファイル整理、重複削除、文書の下書き整理、リポジトリの改修みたいに、正解が1つではない作業で効く。 筆者は最初、Claude Code に「整理して」とだけ投げて、きれいになった結果だけを受け取っていた。すると数日後に「なぜこのファイルは残したんだっけ」「この見出しは何を基準に削ったんだっけ」がわからなくなる。やり直しが出るたびに、また同じ判断を最初からさせる羽目になる。あれは地味にだるい。判断の中身を残しておけば、同じ迷いを二度踏まなくて済む。 やり方は難しくない。Claude Code への依頼に、最初から「判断の記録も一緒に出す」と書くだけでい

Claude Code に長文を丸ごと投げて、全部を一度に飲み込ませようとする人は多い。だがそれ、だいたい途中で雑になる。 分割投入、つまり章分けして渡すやり方に変えるだけで、指示の通りやすさがかなり変わる。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初から全部を読ませるより、章ごとに材料を渡したほうが、何を直せばいいかがはっきりする。 筆者も最初は、一枚の長いメモをそのまま貼って「いい感じにして」と投げていた。結果はだいたい同じで、要点は拾うが細部がぼやける。しかも手戻りが増える。後から「ここは別章だった」「その章の前提はこっち」と補足する羽目になる。あれはだるい。最初から章単位で渡しておけば、無駄な往復はかなり減る。 やり方は単純だ。材料を、目的ごとに小さく切る。 たとえば文書作成なら、序文、背景、各章の要点、結論を分ける。ファイル整理なら、まず対象フォルダのルール、次に削除候補の基準、最後に例外処理を渡す。Claude Code には、いきなり全体像を完成させる役ではなく、1 章ずつ整える役を持たせる。 たとえばこんな頼み方になる。 ```text 以下の材料を、章

長い依頼を一気に投げて、そのまま最後まで突っ走らせると、だいたいどこかで前提がにじむ。Claude Code は優秀だが、会話が長くなるほど「いま何を守るべきか」がぼやける。そこで効くのが、途中要約、つまり会話の節目で要約するやり方だ。 やることは単純で、作業の区切りごとに「ここまでの前提」「決めた方針」「未決事項」を短くまとめ直させる。これだけで、途中から入った指示に引きずられにくくなる。ファイル整理でも文書作成でも、最後に「最初に何をしたかったんだっけ」とならない。長い会話の事故をかなり減らせる。 筆者は昔、要件を詰めながらファイル移動の手順書を作らせていて、途中で「説明を短くして」と頼んだせいで、重要な注意点まで一緒に削られたことがある。あれは地味に痛い。会話が長いと、モデルはその場その場では筋の通った返答をするが、全体の設計図を勝手に保持してくれるわけではない。人間側が節目で釘を刺す必要がある。 一番やりやすいのは、最初に会話の運び方を決めてしまうことだ。たとえば、最初の依頼にこう入れる。 ```text この作業では、適当な区切りごとに途中要約を入れてください。 要約には次の

Claude Code に雑に頼むと、まず返答の形がブレる。文章でほしいのに箇条書きが増えたり、表でほしいのに説明が長くなったりする。中身以前に、器が決まっていないのが原因だ。ここを先に固定すると、出力形式の指定が効いて、成果物の形を固定するだけで手戻りがかなり減る。 筆者はこれで何度も痛い目を見た。たとえばファイル整理の依頼で、最初は「不要なものを洗い出して」とだけ投げていた。すると、ある回は長文の方針説明、別の回は箇条書き、さらに別の回は見出しだけ妙に立派なメモになった。欲しいのは「そのまま使える一覧」なのに、毎回整形し直す羽目になる。これが地味にだるい。 だから最初にやることは単純だ。Markdown で返すのか、表で返すのか、先に決める。迷うなら、まずは Markdown に寄せる。理由は簡単で、Claude Code は説明文、手順、注意点、短い例をひとまとめにしやすいからだ。逆に、項目同士を並べて比較したいなら表が向く。どちらでもいい、ではなく、最初の一手で固定するのが大事になる。 実際の頼み方はこうだ。 ```text この内容を Markdown で出力してください。

「短くして」とだけ頼むと、だいたい長い。これ、Claude Code でも同じだ。 返答を短くさせたいなら、最初に分量の上限を決める。出力の分量制御とか回答の長さ指定は、後から気分で足すより、先に枠を切ったほうが効く。 たとえば「要点だけで」「手短に」で済ませると、モデルはまだ説明できる余地があると判断して、つい補足を盛る。逆に「3行以内」「箇条書きで3点まで」「100文字以内」と上限を先に置くと、余計な前置きや保険がかなり減る。Claude Code は、こちらが与えた制約の中で組み立てる道具だ。曖昧な「短く」は制約ではない。 実務では、この差が地味にでかい。たとえばディレクトリ整理の方針を聞きたいとき、長文の説明が返ると、そのあと自分で判断する手間が増える。文書の下書きを整えたいときも同じで、まず短い回答をもらってから必要なら掘るほうが速い。最初から長く語らせると、読んでいるうちに本題を見失う。 実際の頼み方は、こんなふうに先に枠を入れる。 ```text この作業の方針を、3点までで短く答えてください。 各点は1文にしてください。 余談や前置きは不要です。 ``` もう少し厳密に

コンフリクトが多い人のやりがちな勘違いは、「Claude Code が賢ければ、同じ場所を複数の作業で触っても勝手にうまくやるはず」だ。そこ、かなり危ない。 実際は、同じファイルを同時に触らせないだけで、競合を避ける、同時編集を避ける、という基本がかなり効く。しかもこれは開発だけの話ではない。文書整理でも、請求書まわりでも、写真の整理でも、ひとつのファイルを別タスクが横取りしないだけで手戻りが目に見えて減る。 筆者も最初は、要約、修正、整形を雑に並列で投げて、最後に diff がぐちゃぐちゃになったことがある。内容は合っているのに、改行だけで戦っているような差分が増える。地味にだるい。Claude Code は便利だが、同じ物を同時に触らせると、賢さより衝突回避の設計がものを言う。 やることは単純だ。タスクをファイル単位、できればディレクトリ単位で分ける。Claude Code に渡す指示も、「この範囲だけ触れ」と明示する。そうすると、出力の見通しがよくなり、あとで人間が確認するときの負担も下がる。 たとえば、リポジトリ内の複数ファイルをいじるときは、こんなふうに分ける。 ```tex

雑に丸ごとテンプレ化すると、次回も同じところで詰まる。そこ、かなりもったいない。 Claude Code を使った作業は、全部をテンプレにするより、迷った地点だけを回収して次回の依頼に戻すほうが強い。振り返りからテンプレ改善、ログを次回依頼に活かす、という流れだ。ログを全部コピーしても、たいていノイズが増えるだけである。 筆者も最初は、やり取りをそのまま長文で残していた。すると次の依頼で、どうでもいい前提説明まで復活してしまい、指示が重くなる。しかも本当に必要だった「ここは先に確認してほしい」「このファイルは触るな」だけが埋もれる。あれはだるい。 残すべきなのは、会話の全部ではない。迷いが起きた地点だ。 作業ログを見返すときは、成果物よりも、次の3種類を探すと早い。 一つ目は、Claude Code が何度か聞き返してきた箇所だ。要件の境目がぼやけていた証拠である。 二つ目は、こちらが途中で指示を足した箇所だ。最初の依頼に抜けがあった。 三つ目は、思ったより手数が増えた箇所だ。ファイルの場所、命名、対象範囲、出力形式のどれかが曖昧だった可能性が高い。 逆に、順調だったと

Claude Code でありがちな失敗は、こちらが「ちょっと整えて」と言っただけなのに、気づいたら深いところまで掘り進んでいて、最後にまとめて見せられることだ。これ、気持ちはわかるが、後から戻すのがだるい。ファイル整理でも文書作成でも同じで、途中で一回止めてくれないと、方向がずれていても気づけない。 そこで効くのが、途中報告を指定する、つまり進捗報告の粒度を決めるやり方だ。Claude Code に「何分ごとに報告してくれ」と機械的に命令するより、「どの単位で止まり、何を見せるか」を先に決めておくほうがずっと実用的である。黙って進みすぎるのを防ぐだけで、手戻りはかなり減る。 たとえば、最初の依頼にこう添える。 ```text まず、作業を小さく区切って進めてください。 各ステップの終わりで、やったこと・見つけた問題・次にやることを短く報告してください。 勝手に大きく先へ進まず、一区切りごとに私の確認を待ってください。 ``` この「一区切り」が肝だ。時間ではなく、作業単位で切る。 ファイル整理なら「重複候補の洗い出しまで」「不要そうな一時ファイルの候補抽出まで」「削除前の一覧提示まで

Claude Code に雑に丸投げして、「なんか遠回りしたな」で終わらせるのはもったいない。そこで止めると、次回も同じ場所で迷う。作業ログを見返す、迷った地点を次回に生かす。ここまでやって初めて、CLI のエージェントはただの便利ツールから、だんだん手癖の合う相棒になる。 狙いは単純だ。Claude Code がどこで止まり、何を確かめ、どこで手戻りしたかを拾って、次の指示を最初から少しだけ鋭くする。これだけで、無駄な探索、でかい diff、あいまいな修正の往復が減る。特に、ファイル整理や文書作成みたいに「正解はあるが、そこへ行く道筋がいくつもある」作業で効く。 筆者は最初、ログをほとんど見返していなかった。すると何が起きるか。前回と同じように「とりあえず全体を見てから判断します」と動き、不要な範囲まで触り、最後に「やっぱりここは触らないで」で戻る。差分は膨らむし、どこで判断が鈍ったのかも残らない。地味だが、これがいちばん痛い。 まず、作業ログは「終わったあとに読む資料」ではなく、「次回の依頼文を作る材料」だと考えると扱いやすい。Claude Code には、実行中の会話やコマンドの

長い指示を書けば、Claude Code が賢くなると思っているなら、そこがまず勘違いだ。たいていは逆で、メモが長いほどノイズが増えて、あとで自分が困る。持たせるメモは短くする。この雑なほど効くやり方が、作業中の手戻りをかなり減らす。 ここでいう「メモ」は、Claude Code に仕事を続けさせるための短い引き継ぎ文だ。たとえば一度の編集で終わらず、次の作業に移るときに「何が決まり、何が終わり、次に何をするか」を渡すためのものだと思えばいい。要するに、議事録ではなく、作業再開のための付箋である。 長文メモがだめな理由は単純だ。Claude Code は会話の文脈を読むが、文脈は無限ではない。余計な背景説明、気持ちの整理、検討途中の迷いまで全部積むと、肝心の決定事項が埋もれる。しかも人間側も、あとでそのメモを見返したときに「結局何を決めたんだっけ」となる。作業の速度を上げるつもりが、逆に確認作業を増やすわけだ。 筆者も最初はやらかした。ファイル整理の作業で、「このフォルダは請求書、こっちは契約書、さらに古いものは別の基準で…」と、経緯まで含めて延々と説明したことがある。結果、C

Claude Code を使うと、気持ちよく進みすぎることがある。そこが落とし穴だ。黙々と走らせたあとで、最後に「違う、そうじゃない」となる。あれはだいぶだるい。 だから最初にやるべきなのは、途中報告の頻度を決めることだ。別名でいうと「途中報告の頻度を決める」だし、要は、どのくらいの間隔で状態を返せば止めどきが見えるかを先に縛る作業である。これを入れておくと、Claude Code が勝手に深追いして、後から大きく戻す事故をかなり減らせる。 特に効くのは、リポジトリ整理、不要ファイルの洗い出し、文章の下書き、複数ファイルの一括修正みたいな作業だ。どれも「一見うまく進んでいるように見えて、実は方向がズレていた」が起きやすい。進捗が見えないまま長く走らせると、コンテキストも時間も無駄になる。 最初にこう言ってしまえばいい。 ```text 20〜30分ごとに途中報告して。今やっていること、終わったこと、次にやること、気になる点を短く返して。止めて確認が必要そうなら、その時点で止まって聞いて。 ``` もう少し作業寄りにするなら、こう書く。 ```text 途中報告の頻度を先に決める。各ファ

長い会話ほど、相手はちゃんと理解しているふりをする。Claude Code でもここが地味に危ない。 途中で要約を一回挟まないと、最初の前提が少しずつずれて、最後には「思ってたのと違う」が出来上がる。これ、コード修正でもファイル整理でも文書作成でも同じだ。 別名で言えば「会話が長くなったら節目で要約させる」だ。要するに、こちらが勝手に次へ進まず、途中で Claude Code に今の理解を言い直させる。すると、解釈違い、対象範囲の取り違え、やるべきことの抜けが早めに見つかる。手戻りが減る。差分も無駄に育ちにくい。 筆者は最初、これをサボって何度か痛い目を見た。大きめのリファクタリングを流しっぱなしにしていたら、途中から「古いほうのディレクトリも触るのか」「要らないキャッシュは消していいのか」が曖昧なまま進み、最後に修正のやり直しが出た。会話の後半でズレが見つかると、修正対象が増えたぶんだけコンテキストも消耗する。先に止めたほうがずっと安い。 やり方は単純だ。長い依頼を一気に投げるのではなく、節目ごとに「ここまでの理解を要約して」と挟む。Claude Code は会話の流れを読めるが、読

長い依頼をいきなり章立てで整えようとすると、だいたい途中で崩れる。章の名前を先に決めること自体は悪くないが、Claude Code に投げる相手が長い会話になるなら、先に決めるべきは「どこで止めて、何を要約させるか」だ。別名で言うと、会話が長くなったら節目で要約させる、である。 ここを外すと、依頼の前半で出した条件が後半で薄まる。Claude Code は会話の流れを追えるが、雑にだらだら続けると、重要な前提や制約が会話の奥に埋もれる。すると、終盤で「その条件は前に出した」とこちらが思っていても、モデル側では拾い直しが必要になる。筆者はこれで何度か手戻りした。特に、ファイル整理や文書作成のように、途中で方針が変わりやすい依頼ほど厄介だ。 だから、長い依頼ではまず章立てを作るより先に、節目を置く。節目とは、会話の途中で Claude Code に立ち止まらせて、ここまでの理解を短く要約させる地点だ。これを先に決めておくと、会話の骨が折れにくい。 たとえば、こんなふうに始める。 ```text この作業は長くなります。次の節目で必ず要約してください。 1. 現状把握が終わったら要約 2.

雑に「これやって」で投げると、Claude Code はだいたい余計なものまで触る。そこが一番もったいない。 Claude Code に仕事を渡すときは、最初に「材料」と「判断基準」を分ける。別名で言えば、最初に使う材料と使わない材料を分けて渡す、である。これをやるだけで、コンテキストの浪費が減るし、手戻りも減る。ファイル整理でも、コード修正でも、文章作成でも効く。むしろ非エンジニアの作業ほど効く。何を見ればいいのか、何を見なくていいのかが曖昧だと、AI はだいたい親切すぎる方向に暴れるからだ。 たとえば、フォルダ内の散らかった書類を整理したいなら、Claude Code に必要なのは「対象フォルダの一覧」「残したい条件」「消したい条件」だ。逆に、関係ない過去案件や別部署の資料まで全部渡すと、判断のノイズになる。コード修正でも同じで、修正対象のファイル、参照してよい設定、守るべき制約が材料になる。一方で、「見てもらうと迷うだけの古い実装」「今回の作業に関係ないログ」「趣旨の違うメモ」は切り離す。ここをサボると、モデルの賢さより先に入力の雑さで負ける。 実際の頼み方は、こういう形にすると

案件を1つの場所に雑に押し込むと、あとで自分が探す側になる。これ、かなりだるい。Claude Code を使うときも同じで、案件ごとにディレクトリを分ける、いわゆる案件単位のフォルダ分離をしておかないと、指示・出力・メモ・成果物が混ざってすぐ迷子になる。 とくに Claude Code は、その場の文脈を見ながら作業を進める道具だ。だからこそ、作業単位をフォルダで切っておくと効く。コード案件だけの話ではない。文書作成、調査メモの整理、重複ファイルの洗い出し、契約書まわりの下書き管理みたいな使い方でも、フォルダの切り方で後の楽さが全然違う。 筆者は昔、1つの作業ディレクトリに別件のメモを足していって、どのファイルがどの案件の最終版か分からなくなったことがある。Claude Code に頼むたびに古いメモまで拾われ、修正のたびに diff が太る。あれは地味に痛い。最初に分けておけば、こんな事故はかなり減る。 まず、考え方は単純だ。Claude Code を起動する前に、案件ごとに親フォルダを切る。中に必要な資料、作業用メモ、出力物をまとめる。Claude Code には、その案件フォルダ

雑に閉じると、次の Claude Code がいきなり鈍る。これは思った以上に効く。 「次回の Claude Code が速くなる終わり方」とか「作業フォルダの後始末」と呼んでもいいが、要するに、いまの作業を“次の一手が打ちやすい形”に整えてから離席する、という話だ。 Claude Code は、こちらが置いたファイル、残したメモ、差分のまとまり方にかなり引っ張られる。作業途中の断片が散らかっていると、次に開いたときにまた状況整理から始まりやすい。人間でも嫌なやつだが、CLI エージェントでも同じだ。 筆者は最初、成果物だけ急いで出して、`.tmp` や試作ファイルを放置したまま終わらせていた。すると次の実行で、古い案と新しい案が混ざり、確認に無駄な往復が増えた。地味だが、こういう手戻りがいちばんだるい。 大事なのは、全部をきれいにすることではない。次回が迷わないだけの“片づけ”をすることだ。やることは意外と少ない。 まず、終わる前に Claude Code に「いま何が残っていて、何を消してよくて、何を残すべきか」をはっきり言う。曖昧に「あとよろしく」では弱い。作業フォルダ内の中間生

ひとつの場所に何でも放り込むと、あとで必ず探し物ゲームになる。Claude Code を使うなら、案件ごとにディレクトリを掘る、つまり最初から案件単位でフォルダを切っておく運用にしたほうがいい。後から探しやすくするだけでなく、指示の混線も減るし、差分も見やすい。地味だが、ここを雑にすると手戻りがいちばん痛い。 筆者は昔、同じ親フォルダに似た名前の依頼を並べて、あとで「この修正、どっちの案件だったっけ」と迷ったことがある。Claude Code 側も、置き場が曖昧だと、こちらが出した指示の文脈を人間ほど都合よく分けてはくれない。ファイルが散らかっていると、探す時間だけでなく、確認のための会話や差分の追跡までだるくなる。案件ごとにディレクトリを分けるのは、整理術というより事故防止だ。 実際の運用は難しくない。たとえば、クライアント名や案件名で親フォルダを作り、その下に作業中の資料、出力物、メモをまとめる。 ```bash mkdir -p ~/work/client-a/2026-04-proposal/{input,output,notes} ``` こうしておけば、Claude Cod

雑に「失敗した」で片づけると、Claude Code はだいたい同じところをまた踏む。そこがまずい。再現しなかった失敗と、たまたま起きた失敗を混ぜて書くと、原因がぼやける。失敗の切り分け、偶発エラーの整理、再現性の判定を先にやるだけで、次の指示がかなり鋭くなる。 Claude Code は、曖昧な記録をそのまま信じて突っ走ると、不要な修正を広げやすい。逆に、何が毎回起きるのか、何が一度だけ起きたのかを分けて残すと、無駄なコンテキスト消費が減る。筆者は最初、エラー文をそのまま貼って「直して」と投げていたが、実際には一回しか出ていない偶発エラーまで重要扱いしてしまい、関係ない周辺ファイルまでいじられて手戻りした。あれは地味にだるい。 まずやることは単純だ。失敗ログを「再現した」「再現しなかった」「条件つきで再現した」の3つに分ける。Claude Code に頼むときも、ここを混ぜない。 たとえば、調査メモを作るならこんな書き方で十分だ。 ```text 次の失敗を整理してください。 いつ起きたか 何をしたときに起きたか 同じ操作で再現するか 1回だけの偶発エラーか その失敗が何に影響したか

作業ログを全部テンプレに戻すのは、だいたい雑だ。しかも重い。次回に残すべきなのは「うまくいった手順」より、むしろ「そこで迷った」「判断に時間がかかった」「指示があいまいで手戻りした」地点だけである。ここを戻すと、ログの再利用、失敗の抽出、テンプレ改善が一気に実用になる。 Claude Code は、毎回の依頼をきれいに書き直す道具というより、作業の癖を次に持ち越す道具として使うほうが強い。特に、ファイル整理や文書作成みたいな用途では、毎回の作業で同じ迷いが出る。どのフォルダを触ったか、どの表現で止まったか、どこで差し戻されたか。そこだけ拾って次回の依頼テンプレに戻せば、無駄な説明が減るし、Claude Code のコンテキストも食いにくくなる。 最初に大事な線引きをしておく。戻すのは「成果物の全文」ではない。戻すのは「次回も迷う可能性が高い一文」だけだ。ここを間違えると、テンプレが日記になる。日記は読めるが、指示としては弱い。 たとえば、前回の作業ログがこんな形で残っていたとする。 ```text 依頼: 請求書フォルダの重複を整理 迷った点: 「2023_final」「2023_最新

長く書き散らしたあとに、そのまま投げるのは雑すぎる。しかも、本人には読めるのに他人には使えない、いちばん厄介な形になりやすい。そこで効くのが、仕上げの再編集、全体の整形、引き継ぎ用まとめだ。Claude Code を使うなら、最後にこれを一回かけるだけで、下書きが「自分のメモ」から「他人が次に動ける文」に変わる。 ここでやることは、文章をきれいにするだけではない。重複を削り、順序をそろえ、前提が抜けた箇所を補い、あとで別の人が見ても迷わない形に整える。会議メモ、作業ログ、調査メモ、ディレクトリごとの作業記録、ファイル整理の手順書。どれでも効く。筆者は最初、ただ長文を短くしてもらえば十分だと思っていたが、実際はそれだと筋が切れて、あとで読み返すと「で、何を決めたんだっけ？」となった。長さを削るだけでは足りない。最後の組み直しが本体だ。 まずは、Claude Code に渡す役目をはっきりさせる。ここをあいまいにすると、要約なのか整形なのかがぶれて、出力が中途半端になる。たとえば、作業メモを引き継ぎ用に変えたいなら、こんなふうに指示する。 ```text この下書きを、あとで別の人が読んで

長いメモを残して「あとで Claude Code が全部わかるはず」と思うと、だいたい逆に詰まる。 ここで効くのは、短い作業メモを残し、決定事項のみを書き、余計な経緯は落としていくやり方だ。要するに、コンテキスト圧縮である。Claude Code に渡す情報は、議事録ではない。次の一手を迷わないための手がかりだけでいい。 筆者は最初、ここを盛大に外した。要件をそのままベタ書きして、しかも途中の試行錯誤まで全部残したら、Claude Code が「どれが現在の方針か」を拾いきれず、無駄に広く触り始めた。修正差分が増え、見なくていい古い方針まで引きずる。あれは気持ちいい失敗だった。メモは増やすほど賢くなるわけではなく、むしろ鈍ることがある。 やることは単純だ。残すのは「何をやるか」「何をやらないか」「もう決めた制約」だけにする。たとえば、文書作成でもファイル整理でも、次のような短いメモで足りる。 ```text 目的: 契約書の下書きを整える 決定事項: 口調はやや硬め 見出しは3つ 参考資料Aは使う 参考資料Bは使わない 未決定: 署名欄の表記 ``` これだけで十分だ。

長い依頼ほど、いきなり章立てを作る人が多い。だが、そこがだるい罠だ。Claude Code に会話が長引く作業を任せるなら、先に決めるべきなのは章ではなく節目である。区切り設計、マイルストーン、進行の節目。呼び方は何でもいいが、要は「どこで止めるか」を先に固定する発想だ。 これをやると、会話の空回りがかなり減る。特に、ファイル整理、不要キャッシュの洗い出し、長い文書作成、複数ディレクトリにまたがる作業では効く。逆に、節目がないまま走らせると、Claude Code は親切に広げすぎる。確認のたびに前提を思い出し、説明が増え、差分も膨らむ。筆者はこの手の作業で、途中までうまくいっていたのに「続きも同じ調子で」と丸投げして、説明の再生成にコンテキストを食われたことがある。やることは単純なのに、会話だけ長くなる。かなりもったいない。 まずは、仕事を章ではなく節目で切る。たとえば文書作成なら、こんなふうだ。 目的の確認 素材の棚卸し 下書き 体裁の調整 最終確認 これだけを見ると、ただの手順書に見える。だが実際は違う。Claude Code に渡すべきなのは「第1章、第2章」のような見出しでは

調べっぱなしで終わると、Claude Code は平気で長文を抱えたまま次の仕事に入る。そこが雑だと、あとで「あれ、さっき何を見つけたんだっけ」となる。 そこで使うのが、その場で短くまとめさせてから次の指示に渡すやり方だ。調査サマリ、中間要約、引き継ぎメモ、と呼び方は何でもいいが、やることは同じである。見つけた事実だけを短く圧縮して、次の判断材料に変える。 これが効くのは、Claude Code が「長い調査結果」をそのまま抱え込むと、肝心の次の作業に使うコンテキストがじわじわ削られるからだ。特に、複数ファイルを見たり、候補を比較したり、不要ファイルの洗い出しをしたあとに、そのまま編集へ入る流れは危ない。筆者は最初、調べた内容を全部貼って「これで直して」と投げて、要点がぼやけたまま手戻りした。長文を読ませるより、要点を切って渡したほうが速い。これはかなりはっきりしている。 やり方は単純だ。まず調べさせる。次に、調査結果を短く要約させる。最後に、その要約だけを使って次の指示を出す。 たとえば、重複ファイルや大きすぎるファイルを見て、削除候補を絞りたいなら、こう頼む。 ```text この

Claude Code に作業だけさせて、あとから「なんでそこを触ったんだ」と首をかしげる。これ、かなりありがちな落とし穴だ。差分はきれいでも、判断の筋道が残っていないと、少し時間がたっただけで修正の意図が追えなくなる。結果、同じ迷いをもう一度やる羽目になる。 ここで欲しいのは、判断ログ、理由メモ、思考の記録だ。大げさな監査記録ではない。どのファイルをなぜ変えたか、何を捨てて何を残したか、迷った末にどう決めたかを、短く残しておくだけでいい。これがあると、後から差分を見返すときの速度が段違いになる。レビューも楽になるし、非エンジニアが書類整理やファイル整理に使う場面でも効く。削除した理由が残っていれば、戻すべきかの判断が一気にしやすくなるからだ。 一番手堅いのは、Claude Code に「作業そのもの」と「判断の記録」を分けて頼むやり方である。たとえば、ファイル整理ならこう書く。 ```text このフォルダを整理してください。 作業の前に、どの基準で分類するかを短く整理してください。 作業後に、変更した内容と、迷った点・判断理由を箇条書きで残してください。 判断理由は、あとで見返して

長い依頼でいちばん雑に扱われがちなのは、実は“今の状態”だ。 ここを省くと、Claude Code は毎回まっさらな気分で読み始める。こちらは「前提くらい分かるだろ」と思っているのに、向こうから見ると肝心の足場が見えていない。結果、手戻りが増える。地味だが、かなりだるい。 この手の依頼では、冒頭に短い現状メモを置くのが効く。途中再共有とか、前提の再掲と呼んでもいい。要するに「いま何がどうなっていて、どこで詰まっていて、何を優先したいのか」を先に一段落で書くやり方だ。Claude Code は会話の流れを読めるが、長い作業ほど途中で前提がぼやける。だから最初に短く固定する。 たとえば、ファイル整理ならこういう入り方になる。 ```text 今の状態を先に書きます。 このフォルダには請求書PDF、スキャン画像、古い下書きが混ざっている まず重複っぽいものと不要そうな一時ファイルを分けたい いきなり削除はせず、削除候補を一覧にしてから進めたい この前提で、整理の手順を提案して。必要ならコマンドも出して。 ``` これだけで、依頼の解像度がかなり上がる。Claude Code にとっての「何を

会話が長くなるほど、前提を抱えたまま走るのが一番だるい。Claude Code にも人間にも通じないまま話が進むと、あとで「それは最初に言ってほしかった」が必ず出る。そこで効くのが、要点の一文化、文脈サマリ、ミニ要約だ。節目ごとに前提を 1 行へ圧縮して差し込むだけで、指示のズレと手戻りがかなり減る。 Claude Code は、会話の流れで積み上がった文脈をもとに動く。だから、ファイル整理でも文書作成でも、途中で前提が変わったのに古い認識のまま作業させると、平気でズレる。たとえば「重複ファイルを消したい」の話をしていたのに、途中から「バックアップは残したい」に変わった。ここを明示せずに進めると、消してはいけないものまで整理対象に入る。そういう事故を防ぐのが、前提を 1 行で打ち直すやり方だ。 やり方は単純で、節目ごとに「今の状況」「守る条件」「この先の目的」を 1 行に畳む。長い説明は要らない。むしろ長いと、Claude Code が拾うべき核がぼやける。たとえば、こんな感じでいい。 ```text ここまでの前提: 対象は /Projects/report/ 配下、削除は不可、今回

途中までちゃんと合っていたのに、最後の最後でズレる。Claude Code ではこれがいちばん面倒だ。たいてい原因は、最初の前提が少しずつ摩耗していることにある。定期要約、会話の棚卸し、前提の再確認を途中で挟むだけで、この手の手戻りはかなり減る。 長い作業を丸投げするときほど、モデルは「今どこまで合意済みか」を取り違えやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初は「不要ファイルだけ消して」と頼んだのに、途中から「似た名前のフォルダも整理しておきました」と広がっていく。ありがたいようで、実は危ない。あなたが欲しかったのは、勝手な拡張ではなく、最初の意図を保ったままの実行だ。 このズレを止める方法は単純で、途中で一回、短く要約させることだ。やっていることは、会話の棚卸しだと思えばいい。今の理解、終わったこと、未確定のことを切り分けさせる。前提の再確認まで入れればなおよい。 たとえば、Claude Code に長めの作業を頼む前に、最初からこう指示しておく。 ```text この作業は長くなるので、途中でいったん要約を挟んでください。 その時点で、 1. ここまでに確定

長く返ってくるのは、Claude Code が空気を読めないからではない。こちらが「どこまで書いていいか」を渡していないからだ。 出力の長さを抑える、短く要約して返させる、分量指定。このへんを最初に言っておくだけで、返答の暴走はかなり減る。 Claude Code は、曖昧な依頼だと丁寧に埋めようとする。そこが便利でもあり、だるいところでもある。たとえば「このフォルダの内容を整理して」とだけ言うと、背景説明、手順の候補、補足、注意点まで一気に盛り込みがちだ。欲しいのが要点だけなら、最初から上限を置くのが早い。 やり方は単純で、最初の一文に分量を入れる。 ```text この内容を200字以内で要約して返して。 要点だけでいい。前置きは不要。 ``` ```text 次の手順を3点に絞って短く説明して。 各項目は1文まで。 ``` ```text この文章を短く整えて。300字以内。 重要な情報は落とさず、冗長な説明は削って。 ``` Claude Code に対しては、ただ「短くして」より「200字以内」「箇条書き3点まで」「各項目1文まで」のように、境界をはっきり切るほうが効く。人間

「あとで見返せばわかる」と思って、肝心な迷い方を残していない。これがいちばんもったいない。Claude Code は作業を進める道具としては強いが、勝手に次回のための教材まで整えてくれるわけではない。だからこそ、作業ログの確認、つまり振り返りを一手間足して、迷った地点を拾い上げておくと効く。 この TIPS の狙いは、作業が終わったあとに「何をしたか」を眺めることではない。どこで詰まり、どの指示が曖昧で、どの切り分けで前に進んだかを回収して、次の依頼文にそのまま埋め込める形にすることだ。これをやると、同じ迷子を何度もやらなくて済む。特に、ファイル整理、文書作成、不要ファイルの洗い出しみたいな用途では、作業の“正解”より“迷い方”のほうが再利用しやすい。 まずやることは単純だ。Claude Code に任せた作業を終えたら、その場でログを見返し、迷った瞬間だけ抜き出す。全部読む必要はない。雑に全部読むと、ただの記録で終わる。見るべきなのは、こちらが何を曖昧に頼んだか、Claude Code がどこで確認を返したか、こちらがどの追加条件を後出ししたか、の三つだ。 たとえば、書類整理の案件で

作業が終わったあとに「もう十分だろ」と放り出すと、あとで一番だるい。受け取る側が読む気を失うからだ。Claude Code を使うなら、最後にやるべき仕事は修正の上積みではない。最終要約、つまり成果物の圧縮だ。引き継げる形に整えて初めて、作業は終わる。 ここでいう「まとめ直し」は、長い説明を短くするだけではない。何をやったか、何が変わったか、残っている懸念、次に誰が触るべきかを、読み飛ばされにくい順番で並べ直す作業だ。ファイル整理でも、文書作成でも、コード修正でも効く。雑に散ったメモを、そのまま渡せる状態にする。これができると、やり直しが減る。 Claude Code に頼むときは、最初から「要約して」とだけ投げないほうがいい。あれは短くなるだけで、引き継ぎやすくはならないことがある。要点の選び方まで指示したほうが、あとで使える形になる。 たとえば、作業ディレクトリの内容を最後に整理したいなら、こう頼む。 ```bash Claude Code にこう依頼する： このフォルダ内の作業内容を、引き継ぎ用の最終要約にまとめてください。 次の順で出してください。 1. 何をやったかを3〜5行

「短くして」とだけ投げると、返ってくる文量が妙にぶれる。そこを曖昧にしたままだと、Claude Code は空気を読んでいるようで読んでいない。なら最初から上限を切る。短文指定、出力量の制御は、だいたいここで効く。 Claude Code で要点だけ欲しい場面は多い。たとえば、変更内容を一言で説明してほしいとき、長いログから異常だけ拾いたいとき、整理メモを作りたいときだ。こういうときに「短めで」と頼むだけでは弱い。短めの感覚は人によって違うし、モデル側にも余地が残る。だから、返答の長さを「感覚」ではなく「上限」で縛る。 いちばん手堅いのは、文字数か行数で切るやり方だ。たとえばこう書く。 ```text この内容を要約してください。3行以内で、箇条書きは2点まで。 ``` ```text 変更点を説明してください。120字以内で。 ``` ```text 不要ファイルの整理方針を、見出しなしで5行以内にまとめてください。 ``` この頼み方のいいところは、Claude Code が余計な前置きや保険文を足しにくくなる点だ。「短く」とだけ言うと、結局は小見出し付きのミニ解説が返ってきたりす

「とりあえず答えて」で始めると、あとで整形し直す羽目になる。Claude Code でもここは同じで、返答の形を先に固定するだけで手戻りがかなり減る。出力形式の指定、返答フォーマットを先に渡しておく、というやつだ。 たとえば、作業メモを整えたいのに段落だらけの文章が返ってくると、結局こちらで見出しを切り直すことになる。逆に、最初から Markdown で返させれば、見出し、箇条書き、コードブロックがそのまま使える。表が欲しいなら表に寄せる。ここを曖昧にしたまま進めるのは、箱を開けてから「やっぱりこの棚は縦じゃなく横だった」と言っているようなものだ。 Claude Code に頼むときは、まず使い道を一言で言い切る。そのうえで、返答形式を最初の条件として置く。たとえばこうだ。 ```text この作業はMarkdownで返してください。見出しは h2 相当、要点は箇条書き、最後に次の作業だけ短く書いてください。 ``` 表で欲しいなら、最初からそう言う。 ```text この内容は表で返してください。列は「項目」「内容」「補足」の3つで固定し、余計な前置きは不要です。 ``` フ

Claude Code でいちばん無駄なのは、もう変わった前提を延々と引きずることだ。昨日まで有効だった指示を、そのまま今日も抱え続けると、会話は静かに濁る。出力がズレる、修正が増える、diff が太る。地味だが、かなり痛い。 ここで効くのが、指示の更新と前提の再提示だ。要するに、「前に言ったこと」を神聖視しないで、状況が変わったら言い直す。Claude Code は長い文脈を読めるが、だからこそ古い前提をそのまま残すと、昔の依頼に引っ張られる。ファイル整理でも、文書作成でも、コード修正でも同じである。 たとえば最初は「このフォルダの重複画像を探して」と頼んだのに、途中で「いや、削除はしないで一覧だけ出して」と方針が変わったとする。このときに「さっきの続きで」などと曖昧に流すと、Claude Code は削除前提のまま手を動かし続けることがある。ちゃんと、いったん前提を上書きするのが正解だ。 実際の頼み方は、短くていい。むしろ短いほうが強い。前提を明示して、古い指示は捨てると書く。 ```text 前提を更新します。ここからは「削除しない」が正しい前提です。 重複候補は一覧だけ出してく

黙って最後まで走らせて、あとで「あれ、思っていたのと違う」が出る。Claude Code でもこれをやると、地味に痛い。 進捗報告、報告間隔を先に決めておくだけで、その手戻りはかなり減る。 Claude Code は、こちらが待っている間も延々と考えたり、ファイルを見たり、差分を積んだりできる。だからこそ、途中報告の頻度を先に決めておくのが効く。短い作業なら最後まで黙っていてもいいが、少しでも長引くなら、どのくらいの間隔で止まって報告するかを最初に渡しておくべきだ。これを怠ると、手元では静かでも、裏では見当違いの方向に寄っていき、最後にまとめて修正する羽目になる。 たとえば、最初の依頼文にこう書く。 ```text この作業は途中報告を入れながら進めてください。 ひと区切りごとに、今やったこと・次にやること・迷っている点を短く報告してください。 報告間隔は、作業の節目ごと、または10分ごとを目安にしてください。 大きく方針が割れそうなら、その場で止まって確認してください。 ``` ここで大事なのは、「途中で報告して」で終わらせないことだ。 それだと、Claude Code 側はどこで止

長い指示を一気に投げて、そのまま走らせる。これ、Claude Code でいちばん手戻りが増えるやり方だ。 途中で前提がズレていても、最後までそれっぽく進んでしまうのが厄介で、気づいた時には diff が太っている。そこで効くのが途中要約、つまり節目要約だ。節目ごとに「ここまでの理解」を短く言わせるだけで、ズレを早めに止められる。 Claude Code は、長い作業ほど文脈を食う。しかも人間側は「この辺で分かっているはず」と思いがちだ。だが、分かっていないまま進むことは普通にある。 要約を挟む目的は、きれいな文章を作ることではない。こちらの意図、前提、制約、残っている論点を、途中で一回棚卸しさせることだ。 たとえば、フォルダ整理でも文書作成でも同じだ。最初に雑に「整理して」「読みやすくして」と言うと、Claude Code は広く解釈する。悪気はない。むしろ素直すぎる。だから節目で止める。止めて、今どこをどう理解しているかを返させる。そこで違和感があれば、その場で直す。 実際の頼み方はこうだ。作業の最初に、途中要約のタイミングを指示しておく。 ```text この作業は段階ごとに進め

長い依頼文を一発で投げると、たいていろくなことにならない。Claude Code は賢いが、材料の山をそのまま渡せば、要点がぼやけるし、余計なところまで気を取られる。だから使うのは分割投入、つまり長文の小分けだ。 やることは単純で、長い案件文書や仕様書、整理したいフォルダの事情を、章ごとに分けて渡す。いきなり全部貼らずに、「背景」「やりたいこと」「制約」「確認したい点」を別々に処理させる。これだけで、返ってくる文章の精度がかなり変わる。ファイル整理でも同じで、巨大な一覧を丸ごと食わせるより、まず重複候補だけ、次に古いものだけ、最後に残す条件だけを渡したほうが事故りにくい。 筆者は最初、議事録の原稿を長文のまま貼って「要約して」と頼み、見出しの粒度が崩れて手戻りしたことがある。全文に対して一気に指示すると、どこが重要なのかの優先順位が曖昧になる。人間でも、20ページの資料を一度に読んで的確に直すのはだるい。同じことだ。 実際のやり方は、こんな形で十分だ。 ```text まず、次の材料はまだ要約しないで受け取ってください。 第1章: 背景 第2章: 現状の問題 第3章: 直したいこと 受

長い依頼をそのまま投げて、Claude Code が途中でズレる。これ、かなりありがちな失敗だ。 依頼の分割、作業の切り分けを先に入れておくと、指示の抜けや解釈違いが目に見えて減る。しかも、やり直しが起きたときの損失も小さい。長文を一発で飲み込ませる前提そのものを捨てたほうがいい。 Claude Code は、長い文章を雑に「読んでくれる」道具ではない。作業を進める相手だ。だから、最初に区切りを入れて、何を先に理解してほしいのか、何を後回しにしていいのかをはっきりさせる。これだけで、コンテキストの浪費がかなり減る。 筆者も昔、変更したいファイルの背景説明から制約から希望する書き味まで、全部を一度に貼って失敗したことがある。返ってきた内容は間違っていないのに、欲しい順番ではなかった。結果、後半の条件を見落としたまま作業が進み、差分を戻してやり直す羽目になった。あれは完全に、依頼文を一気読み前提にしたこちらの負けだ。 やることは単純だ。最初に依頼を三つくらいに切る。 たとえば、まず「何をしたいか」を渡す。次に「触っていい範囲」を渡す。最後に「出力の形」を渡す。これだけで十分な場面は多い。

長い会話で詰まる人は、だいたい「最初の前提がどこかで抜ける」ことを軽く見ている。Claude Code でもこれは同じだ。作業が進むほど、会話の文脈はじわじわ重くなる。途中で条件が増え、方針が変わり、古い依頼文と今の依頼文が混ざる。そこで効くのが途中要約、つまり節目のサマリーだ。節目ごとに短く整理させておくと、後半で前提が崩れにくい。結果として、手戻りと再説明が減る。 筆者は最初、これをサボって痛い目を見た。大きめの整理作業を Claude Code に任せ、途中で「この方針のまま続けて」とだけ投げたら、会話の後半で古い判断を引きずったまま進められた。修正はできるが、戻り道を探すのがだるい。長い会話は、放っておくと「今の前提」と「昔の前提」が同居する。要約を挟むのは、その混線をほどくための地味だが強い手だ。 やり方は単純だ。大きな区切りごとに、Claude Code に「ここまでを短く整理して」と頼むだけでいい。たとえば、計画を立てたあと、数ファイルを触ったあと、方針変更を入れたあと、最後の仕上げに入る前。このあたりで途中要約を挟む。 実際の頼み方はこうだ。 ```text ここまでの

長い会話は、だいたい前提がこぼれて終わる。 Claude Code でも同じで、途中までうまく進んでいたのに、少し話が伸びただけで「最初に何を守る話だったか」が薄れる。そこで効くのが、長い会話の要約、あるいは節目要約だ。要するに、途中で一度立ち止まって「ここまでの前提・決定・未解決」を短く固め直す。これを入れるだけで、手戻りが目に見えて減る。 筆者は最初、これを面倒がっていた。すると何が起きるか。数十ターン後に、Claude Code が別の前提で続きを書き始める。ファイル名の方針、削除対象の範囲、文章のトーン、どれか一つでもズレると、修正が雪だるま式に膨らむ。特に文書作成やファイル整理では、会話が長いほど「前に決めたこと」が効いてくる。節目で要約させるのは、機能というより事故防止の作法だ。 やり方は単純だ。会話がある程度進んだところで、Claude Code にその場の状態を要約させる。ポイントは、ただの要約ではなく、次に続けるための要約にすることだ。要約の中に、目的、前提、決定事項、未解決事項、次にやることを入れる。 たとえば、こう頼めばいい。 ```text ここまでの会話を、次

終わったディレクトリをそのまま放置していると、次の Claude Code が地味に鈍る。これ、かなりありがちな落とし穴だ。 使い終わった作業場所の整理、要するに後片付けをしておくと、次回は「何を見ればいいか」が明確になり、探し回る時間も、余計な差分に引っ張られる手間も減る。 Claude Code は賢いが、魔法のように自動で「これはもう不要」と見抜いてくれるわけではない。作業用のフォルダに古い試行錯誤、半端な生成物、使い終わったメモが残っていると、次の依頼でまたそれらを読みに行く。人間でも気が散るが、こういう散らかり方はエージェントにも効く。筆者は以前、同じ案件フォルダに古い出力と新しい出力を混在させたまま進めて、Claude Code に「どっちを正にするのか」を毎回説明し直す羽目になった。あれは本当にだるい。 なので、作業が終わったら「片付け」を一回入れる。大げさな話ではない。次の仕事が始まる前に、古い依頼の残骸を減らしておく。それだけで十分効く。 まずやることは単純だ。作業が終わったら、その案件のフォルダを見直して、次回に要らないものを外に出す。たとえば、実験中のファイル、途

「差分が悪い」のではない。たいていは、同じ場所を同時に触らせた運用が雑だ。 Claude Code でコンフリクトを減らしたいなら、まずやることは派手な自動化ではない。同じファイルを同時に触らせない。これだけでかなり効く。別名でいうなら、コンフリクトの芽を摘む、あるいは編集箇所の分離だ。 筆者も最初は、1 つの大きい指示にまとめて投げていた。すると Claude Code はちゃんと仕事をするのに、最後に差分を合わせる段階で疲れる。README、設定ファイル、サンプル、文書本文を一気にいじると、修正の意図は合っていても、競合の処理だけで手戻りが出る。そこで分けた。すると、見た目は地味だが、衝突は目に見えて減った。 要は、Claude Code に「何を直すか」だけでなく、「何を同時に直さないか」まで渡すのがコツだ。 この話は開発だけでなく、ファイル整理や文書作成にもそのまま使える。たとえば案件ごとのフォルダを分けて書面を作る、原稿本文と参考資料を切り分ける、不要ファイルを掃除するときに対象を一塊にしない。そういう地味な分離が、あとで効いてくる。 --- まず、C

同じ作業場に案を2つ3つ重ねると、だいたいどこかでぶつかる。ファイルが上書きされる、差分が汚れる、どの変更がどの案のものか分からなくなる。ここを雑にやると、Claude Code はむしろ便利さより手戻りを増やす。 だから先に作業場所を分ける。複数案を別作業場所で進める、要するに並走作業の整理だ。これだけで衝突の大半は消える。 Claude Code で複数案を同じリポジトリに並べたいとき、まずやるべきなのは「同じ場所で頑張ること」ではない。案ごとに作業ディレクトリを分けることだ。Git の worktree を使うのが一番きれいで、次点で単純に別ディレクトリへ複製するやり方でも足りる。 筆者は最初、ひとつの作業ディレクトリで「案Aを少し直して、戻して、案Bを試す」をやって、diff がぐちゃぐちゃになった。Claude Code 自体が悪いのではなく、作業場の切り分けが甘いだけだった。後から見ても、どの変更がどの案だったか判別しづらい。あれは本当にだるい。 Git を使っているなら、`git worktree` が本命だ。同じリポジトリを、別のディレクトリとして複数開ける。しかも履歴

それ、いきなり本番の場所で試すから詰まるのだ。Claude Code は手早く頼めるぶん、雑に使うと変更が広がる。下書きと確定版を分離する、試作品を別場所に逃がす。たったこれだけで、あとから直すときの面倒さがかなり減る。 ここで言っている「分ける」は大げさな話ではない。たとえば、文章なら本番の原稿とは別に `draft/` を作る。ファイル整理なら、いきなり元フォルダを触らず、まず `sandbox/` や `tmp/` に複製を置く。コードなら、既存ブランチや本番ディレクトリを汚す前に、作業用の場所を切る。Claude Code はその場で手を動かす道具なので、まず逃がし先を作るのが正解だ。 一番わかりやすい使い方は、Claude Code に「試作品はここで作って、確定したら本体に反映して」と最初に言い切ることだ。依頼文は、あいまいにするとすぐ散る。たとえば文書整理ならこうだ。 ```text このフォルダは本番用です。直接は触らず、別の作業用フォルダに試作品を作ってください。 まずは下書きを `draft/` にまとめ、その内容を見てから確定版へ反映します。 本番のファイル名や配

Claude Code に雑に「これ直して」と投げて、そのまま広い場所を触らせる。これがいちばん危ない。 事故の多くは、モデルの頭の良し悪しではなく、触らせる範囲が広すぎることから起きる。だから先にやるべきは、作業場所を固定することだ。別名で言えば、触らせる範囲を狭める、だ。 筆者はこれを甘く見て、ホームディレクトリや巨大なプロジェクトの根っこで作業を始めて、余計なファイルまで読ませてしまったことがある。結果、コンテキストが無駄に膨らみ、返ってくる修正案もぼやけた。小さな修正のはずが、確認のための往復だけで疲れる。Claude Code は優秀だが、何でも見せれば賢くなるわけではない。むしろ逆だ。 作業フォルダを先に決める、とは要するに「今回の仕事はここだけ」と最初に囲うことだ。これだけで、誤爆、読みすぎ、書きすぎが一気に減る。ファイル整理でも文書作成でも同じで、対象を絞ったほうが、指示も結果もシャープになる。 たとえば、案件ごとの書面を作るなら、案件フォルダを先に切って、その中だけを相手にする。重複ファイルや不要キャッシュを掃除するなら、対象のディレクトリを決めてから走らせる

作業の終わりに雑に閉じると、次回の Claude Code は平気で迷う。人間でも嫌になるあの状態だ。直前まで何をやっていたか、どのファイルを触ったか、何が残っているかが散らばったままだと、次の一手が毎回「状況確認」になる。もったいない。 ここで効くのが、後片付けと引き継ぎ、作業終了時の整備、次回に残すメモだ。大げさな儀式はいらない。終わる前に、次の Claude Code がそのまま続けられる形に整えるだけでいい。これをやると、指示のやり直しが減るし、diff が無駄に育たない。ファイル整理や文書作成で使っている人ほど効く。片づけずに寝ると、翌日の自分がいちばん損をするのと同じだ。 実際、筆者は最初、Claude Code に「このあたり直しておいて」とだけ投げて終わらせ、翌日に同じ説明をもう一回やったことがある。しかも、途中で出した一時ファイルやメモが残っていて、Claude Code がそっちに引っ張られた。仕事としては小さいが、地味にだるい。だから今は、終わり方を作業の一部として扱っている。 やることは単純だ。終わり際に、次回のための短いメモを残し、不要なものを捨て、今の状態を

複数の案件を同じ作業場で走らせると、だいたいどこかで噛み合わなくなる。これはClaude Codeでも同じで、雑に並べると、同時編集の回避が甘くなって、ファイルの衝突防止に失敗する。結果として、同じファイルを別案件が触っていたり、片方の作業がもう片方の差分を上書きしたりする。地味だが、いちばん手戻りが高い事故だ。 ここでやるべきことは単純で、案件ごとに作業の境界を先に決めることだ。Claude Codeに丸投げしてから考えるのでは遅い。最初に「どの案件が、どのファイル群を触るか」「共通で触る場所はどこか」「触ってはいけない場所はどこか」を切っておく。これだけで競合を減らす、という話になる。 筆者は以前、資料整形の案件と原稿修正の案件を、同じフォルダ配下でうっかり並べたことがある。どちらも似た名前のMarkdownを触るので、Claude Codeに「この資料を整えて」と頼んでいるうちに、別案件の下書きまで読みに行かれた。結果、差分の見通しが悪くなり、直すつもりのない文書まで手が入った。あれは完全に置き場の設計ミスだ。 まず効くのは、案件ごとに作業ディレクトリを分けるやり方だ。Claud

いきなりブランチを切って、あとから全部を Claude Code に投げ込む。これ、かなり雑だ。変更前整理を先にやらないと、ブランチ運用がすぐ重くなるし、小さく始める準備もできない。結果として、diff は肥大化する、指示はぼやける、どこまで直したのか自分でも追えなくなる。 Claude Code を使うなら、最初にやるべきなのは「何を変えるか」を作業前にほどくことだ。コード修正だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも同じで、先に材料を整理したほうが、後のやり取りが短くなる。筆者は以前、関連ファイルをまとめずに「このフォルダを整えて」とだけ頼んで、似た名前のファイルを何往復も確認する羽目になった。あれは完全に準備不足だった。 まずやることは、作業の境界を決めることだ。Claude Code に丸投げする前に、対象を狭く切る。たとえばリポジトリなら、機能全体ではなく、1 画面、1 コマンド、1 文書、1 ディレクトリに絞る。ファイル整理なら、まずは「Downloads の画像だけ」「契約書フォルダの重複 PDF だけ」のように切る。ここを曖昧にすると、AI は広

Claude Code に作業させるとき、成果物だけ欲しいのに、作業用メモや途中生成物まで山ほど残してしまう。これがあとで地味にだるい。 一時ファイルの扱いを最初に決めておくと、成果物と作業用メモの分離がはっきりする。ゴミを残さない頼み方にしておけば、あとで見返したときに「結局どれが本体だっけ」が起きにくい。 筆者は昔、下書き整理を Claude Code に任せたとき、途中の案や検討メモまで同じ階層に吐かせてしまい、数日後に見返して盛大に混乱したことがある。内容は悪くないのに、どれが採用版で、どれが捨てていいメモなのかが一目で分からない。あれは単純に依頼の切り方が悪かった。 やることは難しくない。最初に「残すもの」と「残さないもの」を言い切るだけだ。 たとえば、文書作成でもコード整理でも、依頼文をこう寄せる。 ```text この作業では、一時ファイルや作業メモを残さないでください。 最終成果物だけを出してください。 途中経過は必要ならメモせず、作業後に削除してください。 成果物と作業用メモは分けてください。 ``` Claude Code がファイルを触る作業なら、さらに具体的に書

Claude Code に大きなフォルダを丸ごと渡して、「あとはよろしく」はかなり危ない。 余計なファイルまで見に行かせると、コンテキストを食うし、意図しない場所まで修正しやすい。対象フォルダを限定する、作業範囲の制御を先にやる、巻き込み事故を防ぐ。これだけで、手戻りは目に見えて減る。 特に、ファイル整理、ディスク削減、文書作成みたいな用途では効き目が大きい。開発者でも非エンジニアでも同じだ。触らせる場所を狭めると、Claude Code は雑になりにくい。 たとえば、案件ごとにフォルダを分けているなら、その案件の中だけを見せればいい。 古い書類の整理をしたいなら、家全体ではなく「この年の請求書フォルダだけ」に絞る。 これをやらずに全体を渡すと、関係ないドラフトや一時ファイルまで拾ってしまい、出力がぼやける。実務ではそれがいちばんだるい。 Claude Code を使う前に、作業対象を言葉で固定するのが先だ。 「このフォルダの中だけ」「この案件の書面だけ」「この掃除対象の範囲だけ」とはっきり切る。曖昧にすると、AI はいい感じに広く見に行く。人間が見れば不要な範囲まで、平気で拾う。 た

終わった成果物をいつまでも作業場所に置きっぱなしにするのは、地味に効くムダだ。不要なブランチ整理や、使い終わった成果物の整理を後回しにすると、Claude Code は次の仕事で関係ないファイルをまた見に行くし、あなたも「これ、まだ触るんだっけ」と迷う。あの手の迷いは、思った以上にコンテキストを食う。 Claude Code を使うなら、仕事が終わった瞬間に周辺を片付けて、次の依頼に入りやすい状態へ戻すのが強い。これは開発だけの話ではない。書類作成、文章の下書き、案件ごとの資料整理でも同じだ。作業が終わった場所に古い下書き、仮ファイル、重複した出力が残っていると、次の指示がぼやける。やることは単純で、終わったものを「終わった」と見なして退避、削除、整理するだけである。 まず効くのは、Claude Code に「残すもの」と「捨てるもの」をはっきりさせることだ。曖昧に「全部見て整えて」みたいな頼み方をすると、結局どれが本命かわからず、diff が肥大化しやすい。片付けは、作業の最後にまとめてやるより、ひと区切りごとにやるほうが速い。 たとえば、開発ならこんな依頼にする。 ```text

試し書きのファイルに、いつのまにか本番用の文章や成果物まで混ざる。これ、かなり雑に見えて、あとでいちばん高くつくやつだ。下書きと確定版を分ける、成果物の置き場を分ける。Claude Code を使うなら、この線引きは最初にやっておいたほうがいい。 理由は単純で、Claude Code は「今見えているファイル群」を材料に作業するからだ。下書き、メモ、採用済み原稿、配布用の完成版が同じ場所にあると、参照も修正も曖昧になる。書類整理でもコードでも同じで、混ぜるほど事故る。筆者は一度、作業用フォルダに旧版のメモを残したまま頼みごとをして、戻し先がぐちゃぐちゃになったことがある。人間なら見分けられるが、雑な置き方をすると機械は平気で巻き込む。 まずやることは、置き場を物理的に分けることだ。名前でごまかさない。フォルダを分けるほうが早い。 ```text project/ draft/ final/ references/ archive/ ``` たとえば文章作成なら、`draft/` に試し書き、`final/` に確定版、`references/` に参考資料、`archive/` に古い

並走作業でいちばん雑にやってしまうのが、「とりあえず同じ場所で別案を回す」ことだ。これ、すぐ詰まる。Claude Code は賢いが、同じリポジトリの同じファイル群を複数案でいじらせると、変更の混線と差分の肥大化が一気に起きる。複数案の比較をしたいなら、同時進行の整理は最初にやる。場所の衝突を先につぶしておくのが、あとで一番効く。 筆者は最初、同じ作業ツリーで A 案と B 案を行ったり来たりさせて、かなり手戻りした。片方で直した設定ファイルを、もう片方が前の前提のまま触ってしまう。Claude Code は目の前の指示に忠実だから、こちらが整理していないと、平気で「どっちの案の前提で動いているのか」が曖昧になる。結果、diff を見ても何を比較しているのか分からない。これはかなりだるい。 やることは単純だ。案ごとに作業場所を分ける。Git で別ブランチにするだけでは足りない場面がある。同じファイル名、同じ生成物、同じ一時ファイルがぶつかるからだ。Claude Code に複数案を投げるなら、物理的に場所を分けたほうが早い。 たとえば、同じリポジトリを保ったまま、案ごとに別ディレクトリ

その場しのぎで同じ場所に全部押し込むと、あとで確実に詰まる。Claude Code でも同じだ。案件単位で分ける、要するにフォルダ設計を先に決めて、整理用の作業場所を案件ごとに切るだけで、あとから「この差分どれだっけ」「この原稿どこに置いた」と迷わなくなる。 地味に見えるが、効き目は大きい。Claude Code に頼む作業は、コード修正だけではない。議事録の下書き、請求書まわりの整理、既存フォルダの棚卸し、重複ファイルの洗い出しまで入ってくる。ここで作業場所が混ざると、出力も入力も散らかる。人間が戻ってきたときに、どれが正本でどれが一時ファイルか分からない。これがいちばんだるい。 発想は単純でいい。ひとつの大きな「作業箱」を使うのをやめて、案件ごとに独立したフォルダを切る。Claude Code に見せる作業ディレクトリも、基本はその案件の中に閉じる。 たとえば、こんな感じだ。 ```text work/ client-a/ 01_inbox/ 02_draft/ 03_output/ 99_archive/ client-b/ 01_inbox/ 02_draft/ 03_outp

本流のフォルダにそのまま試作を混ぜると、だいたいろくなことにならない。差分は膨らむし、どこまでが本番でどこからが試行錯誤かも見えなくなる。Claude Code を使うなら、最初に「別作業場所を切る」「作業ディレクトリを分ける」「サンドボックスで試す」を先にやるだけで、後の会話がかなり静かになる。 この静かになる、というのは大げさな言い方ではない。Claude Code は、いま置かれているディレクトリの中身を前提に動く。だから、本番の文書やファイルの山の中でいきなり試させると、読ませたくないものまで文脈に入る。逆に、試作用の小さい作業場所を切ってしまえば、指示も差分も小さくなる。手戻りが減る。何より、あとで消していい場所として割り切れるのが強い。 たとえば、弁護士が案件ごとに書面を作る、経理担当が月次のファイル整理をする、非エンジニアが散らかった文書をClaude Codeに整えさせる。こういう場面では、元のフォルダで直接いじらせるより、まずコピーを置いた別ディレクトリで試したほうが安全だ。本番の資料が壊れる心配がないし、出力の確認もしやすい。 やり方は単純だ。試作専用の場所を作って

Claude Code に雑に頼んで、返ってきた答えが毎回バラつく。これはかなりありがちな失敗だ。長文で返ってきたり、逆に一言で終わったり、箇条書きが崩れたりする。先に返答の形を決めておかないと、後で整える手間が地味に重い。 ここで効くのが、Markdown か表かを決める、つまり出力形式の固定だ。要するに「返答を整える」ための下ごしらえを先にやる。Claude Code は指示が曖昧だと、内容は合っていても見た目や粒度が暴れやすい。逆に、最初に形を縛ると、比較・一覧・手順書・要約がかなり扱いやすくなる。 たとえば、ファイル整理や文書作成で Claude Code を使うとき、返答の形を先に決めないと困る場面は多い。重複ファイルの候補を洗い出したいのに、説明文ばかり返ってくる。案件メモを整えたいのに、段落が長すぎてコピペしづらい。そんなときは、最初から「この形式で返して」と言い切るのがいちばん手っ取り早い。 実際の頼み方はこうだ。 ```text 以下の内容は Markdown の見出しと箇条書きで返してください。 余計な前置きは不要です。 各項目は 1 行で短くまとめ、最後に次にやる

最後の最後に雑に投げるだけだと、Claude Code はかなり簡単に“作業した気分の断片”を吐く。そこから人に渡せる形へ直す一手間を入れるかどうかで、引き継ぎ用の要約、最終サマリー、成果物の整形の質が露骨に変わる。ここをサボると、あとで「結局どこが変わったのか」「何を前提に進めればいいのか」が読み取れず、会話をもう一往復、いや二往復する羽目になる。 筆者は最初、作業が終わった直後に「変更点をまとめて」とだけ頼んでいた。すると、モデルはだいたい“それっぽい説明”を返すが、実際にはファイル名の列挙だけだったり、重要な判断理由が抜けていたりする。コード修正なら diff を見ればまだ追えるが、書類整理や設定整理だとそれができない。終わり際にもう一回、引き継ぐ前提でまとめ直す。これが効く。 やり方は単純だ。作業が一通り終わったら、Claude Code に対して「ここまでの成果を、後任がそのまま続きから入れる形に整えて」と明示する。ポイントは、単なる要約ではなく、次の人が迷わない順序に並べ替えさせることだ。たとえば次のように頼む。 ```text ここまでの作業を、引き継ぎ用の要約として整理

Claude Code に雑に「適当に進めて」と投げると、静かに深掘りしすぎて、あとから人間が困る。これが一番ありがちな事故だ。節目だけ報告、進捗の粒度、黙らせるか返させるかを先に決めておくと、作業の暴走をかなり防げる。 特に Claude Code は、頼み方が広いほど、丁寧にやりすぎる。ファイルを読み込み、関係ありそうな箇所まで追い、修正案を積み上げる。その間に「今どこまで進んだか」が見えないと、こちらは待つしかない。長いコード修正でも、書類整理でも、途中報告の設計がないと後でまとめて確認する羽目になる。差し戻しが重い。 筆者も最初はこれで何度か手戻りした。たとえば「このフォルダの重複ファイルを整理して」とだけ頼むと、探索を丁寧にやりすぎて、不要な比較や候補出しに時間を使う。あとで「そこまで細かく見なくてよかった」となる。逆に、途中で一度だけ報告させるようにすると、方向修正が早い。Claude Code を黙らせるか、こまめに返させるかを先に決めるだけで、かなり扱いやすくなる。 やり方は単純でいい。最初の指示に、報告の節目を入れる。ポイントは「何文字ごと」みたいな機械的な指定より、

Claude Code に雑に長文を投げて、そのまま最後まで走らせる。これをやると、途中で前提がズレたまま突き進み、あとで手戻りする。かなりあるあるだ。 そこで効くのが、途中で要約を挟ませるやり方である。節目で要約、中間サマリー、会話の棚卸し、と呼び方はいろいろあるが、要するに「ここまでの理解を一回言わせる」だけだ。これを入れると、Claude Code が勝手に補完した前提、抜けた制約、あいまいな目的を早めに炙り出せる。 特に、ファイル整理、古い資料の整理、複数フォルダにまたがる改修、長い文章の整形みたいな作業で効く。人間側も、途中で判断軸を見直しやすくなる。 筆者は一度、長い修正依頼を最初から最後まで一気に投げて、Claude Code が「見た目を整える」方向に寄りすぎたせいで、肝心の命名ルールを外されたことがある。あのとき、途中要約を入れていれば、ズレは半分くらいで止められたはずだ。 やり方は単純で、最初に「一定量進んだら、作業を止めて要約して」と明示する。ポイントは、単に「要約して」では弱いことだ。何を確認したいのかまで書く。たとえば、目的、前提、未確定点、次にやることを分け

長い資料を丸ごと投げて「読んで」とやると、だいたい途中で雑になる。Claude Code は雑にしても止まらないが、こちらの意図は平気で薄まる。そこで効くのが、章ごとに渡すやり方だ。分割投入、資料を小分けにする、一気読みさせない、というやつである。 これは単なる小技ではない。長文の仕様書、契約書の下書き、議事録、マニュアル、フォルダ整理のルール説明まで、長いものを扱うときの基本動作だ。資料を一気に食わせるより、章単位で渡したほうが、Claude Code は論点をつかみやすい。こちらも「今どこを見ているか」を見失いにくい。 たとえば、20ページの社内手順書を要約したいとする。全文を貼る前に、目次だけを見せる。次に第1章だけ、次に第2章だけ、という具合に進める。これだけで、抜けやすい注意点や、章ごとの言い回しの揺れを拾いやすくなる。非エンジニアの人でも同じで、案件フォルダの整理ルールや、請求書の命名規則を見直すときに相性がいい。先に全体像、あとで各章。順番を守るだけで迷子になりにくい。 実際の頼み方は、かなり素直でいい。まずは全体の目的を一言で固定する。 ```text この資料を章ごと

「たくさん渡せば賢くなる」は、Claude Code ではわりと危ない思い込みだ。長文をそのまま投げる、関係ないフォルダまで一緒に渡す、メモを全部貼る。やりがちだが、これで答えが良くなるとは限らない。むしろノイズが増えて、出力がぶれる。要点だけ渡す、長文を圧縮する、文脈を削る。こっちのほうが、狙いが通りやすい。 Claude Code は会話の空気を読む道具ではあるが、空気を吸わせすぎると息が詰まる。特に、ファイル整理や文書作成みたいな用途では、材料を盛るほど安心しがちだ。だが実際には、余計な背景が多いほど「何を優先するべきか」がぼやける。筆者も最初は、関連資料を全部貼って「これで完璧だろ」と思い、逆に修正の手戻りを増やした。要らない文脈が混ざると、エージェントはそれを無視しきれず、無駄に広い解釈を始める。 なので、まずやるべきは「情報を増やす」ことではなく、「仕事に関係する芯だけ残す」ことだ。Claude Code に渡す前に、次の3つに分けると扱いやすい。 何をしたいのか どのファイル、どの範囲が対象か 何をしないのか この3つだけで、かなり通る。 たとえば、リポジトリ内の古い M

Claude Code は、放っておくと気持ちよく走り続ける。で、そのまま最後にまとめて見せてきて、こちらが「そこじゃない」と言う。これがいちばんもったいない。途中報告、つまり進捗頻度を先に決めておくと、この事故がかなり減る。 大事なのは、毎回こまかく監視することではない。どの区切りで一度止めるかを決めることだ。たとえば「3ファイルごと」「1つの機能の骨組みができたら」「削除候補を出したらその場で止まる」のように、報告のタイミングを先に置く。そうしておくと、Claude Code が黙って走り切ってしまう前に、方向だけ直せる。diff がふくらみすぎる前に止められるのも強い。 筆者は昔、これを甘く見て手戻りした。文書整理の下ごしらえを Claude Code に任せたとき、「古い版を探して、重複っぽいものをまとめて」とだけ投げたら、かなり進んだあとでまとめて報告してきた。整理のやり方は悪くなかったが、こちらは途中で「この分類、案件ごとに切るべきだった」と気づいていた。途中報告の合図がなかったせいで、修正が大きくなった。あれは普通にもったいない。 やることは単純だ。最初の依頼に、作業の進

長いやり取りで一番こわいのは、Claude Code が急に変な方向へ走ることではない。前提を忘れたまま、もっともらしい修正を積み増していくことだ。これで差し戻しが増える。diff は肥大化する。こっちは「何の話だったっけ」と画面を見返す羽目になる。 そこで効くのが、節目要約、途中要約だ。会話が一定の長さになったら、いったん要点を短くまとめさせて、前提を言葉に戻す。地味だが、これを入れるだけで迷走がかなり減る。 Claude Code は、ファイルを読ませて直したり、複数ステップの作業を続けたりすると、会話の流れに引っ張られる。だから「今どこをやっていて、何を変えない方針なのか」を途中で固定し直すのが大事になる。特に、リネーム、ファイル整理、文書の推敲みたいに、見た目以上に前提が崩れやすい作業で効く。 やり方は単純だ。作業がひと区切りついたら、次のように節目要約を頼む。 ```text ここまでの前提と、今確定している方針を5行で要約してください。 あわせて、まだ未確定の点を箇条書きで分けてください。 そのあと、次に触るべきファイルだけ挙げてください。 ``` この頼み方のいいところは

レビューで毎回ゼロから目をこらしていると、だいたいどこかで雑になる。しかも厄介なのは、雑になる場所が毎回少しずつ違うことだ。今回たまたま見たつもりでも、次回は別の抜けが出る。これ、かなりもったいない。 Claude Code は、こういう「見る観点が毎回似ている仕事」に強い。レビュー観点テンプレ、あるいは確認テンプレとして定型を持たせておくと、何を見ればいいかを毎回考え直さなくて済む。結果として、確認が速くなるだけでなく、抜け漏れも減る。 ただし、テンプレを作れば勝手に賢くなるわけではない。雑な観点をそのまま固定すると、雑さまで恒久化する。ここを外すと、むしろ手戻りが増える。筆者は最初、「とりあえず変更点を見て」とだけ投げて、結局あとから「ここも確認して」「いや、権限まわりも見て」と差し戻しを食らった。あれはだいぶだるかった。最初から観点を固定しておけば、こんな往復は減る。 まずやることは単純だ。よく見るポイントを、短い文章で並べる。Claude Code に渡すなら、こういう形でいい。 ```text この作業のレビューでは、次の観点を毎回確認してください。 変更の目的と、実際の差分

長時間いじったあとに「全部見直してください」と投げるのは、だいたい破綻する。差分がでかすぎて、Claude Code も人間も本当に大事なところを見失うからだ。ここでやるべきなのは、差分圧縮と要点整理だ。作業の途中で散らかった変更を、あとから読める単位に畳み直す。変更点の量を減らす話ではない。意味の粒度をそろえる話である。 Claude Code では、ひたすら作業を続けたあとに「変更を要点だけ残す形にして」と頼むと、雑多な修正をまとめ直す助けになる。ファイル整理でも、文書作成でも、コード修正でも効く。要は、あとで自分か相手が追える状態に戻す作業だ。 最初にやることは単純だ。いったん変更を見せて、何を残し、何を捨てるかを明確にさせる。 ```text ここまでの変更を差分圧縮したい。 次の3つに分けて整理してほしい。 1. 本当に残すべき変更 2. まとめられる変更 3. 捨ててもよい一時的な変更や試行錯誤 出力は、変更点の要点を箇条書きで短くまとめて。 そのあと、必要ならコミットメッセージ案も出して。 ``` この頼み方のいいところは、Claude Code に「全部説明しろ」と言わ

「たまに起きる」「さっきは動いた」──その手の話は、だいたい不具合そのものより先に、話の組み立てが崩れている。Claude Code で詰まるのもそこだ。再現しないまま雑に修正へ飛ぶと、原因と対処がズレる。不具合切り分けと再現性確認を先に固めるだけで、勘違いはかなり減る。 Claude Code は、曖昧な状況説明をそのまま飲み込むと、もっともらしい修正案を出してくる。そこに人間側の思い込みが乗ると、別の場所を直して終わりだ。だから最初にやるべきは「直すこと」ではなく、「再現する条件を削ること」になる。 たとえば、こんな頼み方が効く。 ```text この不具合を再現したいです。まず修正はしないでください。 次の情報を整理してください。 どの操作で起きるか 毎回起きるのか、たまに起きるのか 何が起きたように見えるか 直前に変えたファイルや設定は何か 再現手順を1つずつ最小化するならどこまで絞れるか 必要なら、再現確認用のチェックリストを作ってください。 ``` この頼み方のいいところは、Claude Code を「修理係」ではなく「切り分け係」として使える点だ。いきなりコードを書かせる

変更を見ただけで納得した気になると、だいたい後で崩れる。差分は「何を変えたか」しか教えてくれないが、ログは「そのとき何を考えていたか」を残す。Claude Code では、この二つを並べて追う癖をつけると、作業のズレがかなり減る。作業ログ、履歴確認、どちらの感覚でも使えるやり方だ。 特に効くのは、ファイル整理や文書作成みたいに、完成物そのものより「なぜそうしたか」が重要な場面だ。最初はうまくいったように見えても、後から「この並び替えは何のためだったのか」「この削除は本当に安全だったのか」で止まる。筆者も一度、メモの整理を Claude Code に任せたあと、変更履歴だけ見て満足していたら、不要な重複を消したつもりで別の版を残していた。ログを並べていなかったせいで、判断の筋道が消えていたわけだ。 やることは単純だ。Claude Code に作業を頼むとき、最初に「作業ログを残しながら進めてほしい」と明示する。次に、区切りごとに変更内容と判断理由を短く書かせる。最後に、必要なら Git の差分やファイルの更新履歴と見比べる。これだけで、単なる「結果の確認」から「判断の確認」に変わる。 た

PR にそのまま貼る説明文を、いきなり Claude Code に書かせると、だいたい散らかる。要点が混ざる。変更の理由が薄まる。読んだ相手が「で、何を見ればいいの」となる。 ここで効くのが、先に論点整理をさせて、PR説明の芯を作ってから本文に落とすやり方だ。非エンジニアの作業でも同じで、ファイル整理でも文書作成でも、先に「何を伝えるか」を固めるだけで手戻りがかなり減る。 Claude Code は、雑に頼むと雑に広げる。これは欠点というより、指示のあいまいさをそのまま反映するだけだ。だから最初にやることは、文章を書かせることではない。論点を切ることだ。 PR説明、論点整理、この二つを先にやると、説明の芯ができる。芯ができると、後から差分を見た人が追いやすい。レビューの質も上がるし、あとで自分が読み返したときの恥ずかしさも減る。 やり方は単純だ。まず変更内容を丸ごと説明させるのではなく、論点だけを短く抜き出させる。たとえばこんな頼み方でいい。 ```text この変更について、PR説明を書く前の論点整理をしてください。 以下の観点で、重複しないように箇条書きにしてください。 変更の目的

コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。 Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。そこが強い。 まず、作業ツリーを見せて、変更点を要約させる。これだけでも十分役に立つ。 ```bash claude ``` Claude Code が起動したら、こんなふうに頼む。 ```text 今の作業ツリーの変更を確認して、コミット前に見落としがないか洗ってください。 次を順に見てください。 変更ファイルの一覧 追加・削除・名前変更の有無 差分の要点 置き忘れた設定値、コメントアウト、デバッグコードの残り 仕様上まずい変更や、関連ファイルの更新漏れ 最後に、コミット前に人間が目で確認すべき点を短く箇条書きで出してください。 ``` この頼み方のいい

修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。 Claude Code は、長い説明を短く圧縮するのが得意だ。ただし、雑に投げると要点まで薄まる。修正後の内容を、誰に渡しても同じ理解になる粒度に削るには、最初に「何のための要約か」を言い切るのがコツになる。単なる短縮ではなく、引き継ぎ用のメモにする。ここを外すと、ふわっとした文章が返ってきて終わる。 たとえば、修正した文章がこれだとする。 ```text この機能は、重複したファイル名をまとめて整理できる。対象フォルダを選ぶと、同名ファイルを一覧化し、最後にまとめて確認してから処理を実行する。誤削除を避けるため、最初はプレビューだけ表示する。 ``` これを Claude Code にそのまま丸投げするより、次のように頼むほうが使える出力になる。 ```text 次の説明を、引き継ぎメモとして使えるように短く要約してください。 条件

「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。 Claude Code でも同じで、修正依頼を出して、返ってきた変更をそのまま信じるのは雑すぎる。AI はちゃんと直すこともあるが、関係ない箇所を触ったり、テストの失敗原因を外したまま別方向をいじったりもする。だから最後は、人間が「テストが指している場所」と「差分で実際に変わった場所」を重ねて見る。ここをサボると、手戻りが増える。かなり露骨に増える。 たとえば、こんな流れだ。 ```bash git diff ``` で変更点を見てから、 ```bash npm test pytest go test ./... ``` でテストを走らせる。失敗したら、そのエラーメッセージと diff を同時に見る。Claude Code に頼むときも、ただ「直して」では弱い。こう投げるといい。 ```tex

自分で書いた差分ほど、雑に見てしまう。そこが一番まずい。 「差分レビュー」や「レビュー依頼」を自分宛てに投げる感覚で Claude Code を使うと、勢いで書いた変更を一度外に出せる。すると、読みにくい命名、説明不足のコメント、余計なファイル変更が、かなり早い段階で見つかる。 人間の目は、実装した瞬間の文脈に引っ張られる。だから「動くしまあいいか」で流しやすい。Claude Code に赤入れさせる価値は、そこを機械的に叩ける点にある。コードの正しさだけでなく、差分の見た目、変更範囲の広さ、説明の足りなさまで見させると、後で恥をかく率が下がる。 やり方は単純だ。作業が一段落したら、未コミットの差分をまとめて見せて、レビュー観点を先に渡す。Claude Code はターミナルから使うエージェントなので、ローカルのファイルを見ながら指摘を返せる。ここで大事なのは、「直して」と丸投げする前に、まず「レビューして」と頼むことだ。いきなり修正させると、確認したい論点まで勝手に書き換えられることがある。 たとえば、こんな依頼文で十分だ。 ```text 以下の差分をレビューしてほしい。 目的はコ

雑にいじってから確認させると、だいたい手戻りする。Claude Code でもそこは変わらない。先にセルフレビュー、つまり事前レビューの観点を出させてから変更に入るだけで、あとから「そこじゃない」を潰しやすくなる。 この手は、コード修正だけの話ではない。ファイル整理、不要キャッシュの削除、文書の推敲みたいな作業でも効く。いきなり本体を触らせると、見た目は進んでも肝心の判断基準があいまいなまま走る。結果、差分は増えるのに、欲しかった品質には届かない。かなりもったいない。 やることは単純だ。変更を頼む前に、「何を見て自分で確認するか」を Claude Code に先に書かせる。観点を先に固定しておくと、作業中のブレが減る。人間の側も、あとからレビューしやすい。 たとえば、いきなり「この関数を直して」と投げる代わりに、こう始める。 ```text この変更を始める前に、自己レビューの観点を先に列挙してほしい。 対象は次の通り。 変更対象ファイル: src/app.ts 目的: エラーハンドリングの改善 制約: 既存の挙動を変えすぎない 出力: 先にレビュー観点、その後に変更案 観点は、機能、

Claude Code に雑に「さっきの続きで」「さっきの方針で」とだけ投げると、だいたいズレる。前提が変わったのに、古い指示を抱えたまま走らせるからだ。これが前提の更新、方針変更、そして古い前提を消すという話である。 たとえば、最初は「このフォルダを整理して」と頼んでいたのに、途中で「やっぱり削除はせず、重複候補だけ報告して」と変わったとする。ここで大事なのは、変更点だけを足すことではない。古い前提を明示して捨て、今の方針を言い直すことだ。そうしないと、Claude Code は昔の条件を混ぜたまま、半端な削除や中途半端な修正を返してくる。 筆者はこれで何度か手戻りした。最初の依頼では「不要ファイルを見つけて消したい」だったのに、途中で「実際には消さず、候補一覧だけ欲しい」に変えた。ところが、前の指示を消さずに追加だけしたせいで、削除前提の説明と一覧作成が同居した返答が返ってきた。人間なら文脈を読んで空気を直すところだが、CLI の相手にはそれを期待しないほうがいい。指示は更新ではなく置き換えとして書くのが安全だ。 やり方は単純である。まず、今の目的を一文で言い直す。次に、もう不要に

長い会話をそのまま流しっぱなしにすると、Claude Code は平気な顔で文脈を抱えたまま進む。これが曲者だ。人間は「ここまでの話、何だったっけ」となり、モデル側も要点の輪郭がぼやけてくる。そこで入れるのが途中要約、節目の要約、要点整理である。会話の途中で一度立ち止まらせ、ここまでの決定事項・未決事項・次にやることを短く並べ直させる。これだけで、手戻りがかなり減る。 筆者は以前、ファイル整理の作業を Claude Code に任せて、削除候補の洗い出しをだらだら続けたことがある。最初はよかったのに、途中から「さっきの条件」と「今回の条件」が混線して、同じフォルダを二度見させる羽目になった。最後に要約を挟んでおけば、こんな無駄はだいぶ防げたはずだ。長話は、賢さの証明ではない。たいていはコンテキストの浪費だ。 やり方は単純で、会話の節目でこう頼めばいい。 ```text ここまでの内容を、次の3点に分けて短く要約して。 1. 決まったこと 2. まだ曖昧なこと 3. 次にやること 要約は箇条書きで、各項目は1行ずつ。余計な説明は増やさないで。 ``` この依頼文の肝は、「何を要約するか」

長い経緯メモを Claude Code に持たせると、だいたいろくなことにならない。読み返すだけでコンテキストを食い、肝心の判断材料が埋もれる。残すべきなのは、途中の雑談ではなく決定事項だ。短い作業メモ、あるいは決定事項の圧縮という発想に切り替えると、作業が急に軽くなる。 Claude Code は会話の流れを踏まえて動く。だからこそ、途中で「ここまで何を決めたか」を短く固定しておくと強い。逆に、経緯をだらだら積み上げると、あとから見返したときに自分でも迷うし、Claude Code も無駄に揺れる。筆者は最初、会議の議事録みたいなメモをそのまま貼っていたが、修正のたびに話が分散して、同じ説明を何度もやり直した。あれははっきり無駄だった。 たとえば、あるフォルダ整理を頼む場面を考える。 悪いメモはこうなる。 ```text 昨日の続きで、あの資料も入っていて、こっちのファイル名も少し変えていて、最初はPDF中心だったけど途中で画像も混ざって、クライアントの都合で表紙の扱いが変わって、たしか社内共有用と提出用で分ける話もあって…… ``` これだと、何が決定で何がただの経緯か分からない。

長文を投げておいて「要点だけ返せ」は、だいたい伝わりきらない。Claude Code でも同じで、先に分量の上限を決めておかないと、返答は平気で膨らむ。短くまとめさせる、要点だけ返させる、という使い方をしたいなら、最初に「何行まで」「何文字まで」「箇条書き何点まで」を入れておくのがいちばん効く。 これはコードの相談だけの話ではない。ファイル整理の相談でも、文書の下書きでも、ディスク削減の手順でも、先に制限を言うだけで返答の密度が上がる。逆に、あとから「もっと短く」と言い足すと、すでに出した長文を削る作業が発生して、無駄が増える。 たとえば、こう頼む。 ```text 次の内容を、3行以内で短くまとめてください。 要点だけ返してください。前置きは不要です。 ``` Claude Code にコーディングの相談をするなら、もう少し型を決めるといい。 ```text この変更案を、箇条書き3点以内で短くまとめてください。 各項目は1文まで。背景説明は不要です。 ``` 文書作成なら、分量の上限を先に置く。 ```text この文章を、200字以内で要点だけ返してください。 読者が次に取るべき

Claude Code に雑に「一覧で」「見やすく」で投げると、返答の形が毎回ぶれる。ここを甘く見ると、あとでコピペしづらい、差分が読みにくい、保存したときに壊れやすい、の三重苦になる。先に Markdown で出すのか、表で出すのかを決めておく。要するに出力形式の固定だ。成果物の形を先に決めるだけで、返答はかなり安定する。 この手の話は、エンジニアのコードレビューだけの話ではない。ファイル整理でも、議事録作成でも、請求書の確認でも同じだ。たとえば「重複ファイルの候補を拾ってほしい」と頼むときに、表で返してほしいのか、Markdown の見出し付きで返してほしいのかが曖昧だと、途中で形式が変わる。そうなると人間の目でも扱いにくいし、次の工程に渡しづらい。 筆者も最初はここで何度も手戻りした。Markdown のつもりで頼んだのに、途中から表が混ざる。逆に、表で見たかったのに箇条書きが増える。Claude Code は内容をちゃんと理解していても、出力の器が決まっていないと、返し方が揺れることがある。コンテキストを食うわけではないが、余計な往復が増える。地味にだるい。 まず、最初に器を決

長い資料をそのまま全部投げるのは、だいたい雑だ。Claude Code は長文でも扱えるが、だからといって「最初から最後まで一気に読んで、全部を一発で直してくれ」で済ませると、要点がぼける。途中で重要な条件を落としたり、修正の軸がぶれたりして、あとで手戻りになる。 ここで効くのが、章分けして渡す、あるいは分割投入だ。資料を見出し単位、章単位、用途単位で切り、順番に渡していく。これだけで、Claude Code が今どこを見ているのかがはっきりする。長い議事録、仕様書、契約書の下書き、マニュアル、散らかった手順書。全部に効く。非エンジニアでも同じだ。ファイル整理のルール文書や、社内向けの手順書を整えるときにもかなり使える。 筆者は最初、長文を丸ごと貼って「要約して、ついでに直して」と頼んでいた。結果は悪くないのに、肝心の制約が抜ける。後から「いや、そこは残すべきだった」と気づいて、もう一回やり直しになる。あれはだるい。章ごとに渡し始めてから、話が戻りにくくなった。 やり方は単純だ。まず資料を人間が読んで、章や役割で切る。次に、各章を別々に扱わせる。たとえば、先に全体方針を固め、その後で各

Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。 たとえば、最初は「このフォルダの重複画像を整理して」と頼んでいたのに、途中で「やっぱり削除は怖いから一覧だけにして」と方針が変わったとする。ここで前の指示を引きずったまま会話を続けると、Claude Code は「削除前提の整理」と「一覧化だけ」を両方気にして、中途半端な出力を返しやすい。これは開発でも文書作成でも同じで、前提が変わったのに古い条件を残すと、やり直しが増える。 やることは単純だ。方針が変わったら、差分だけを足すのではなく、いったん前提を切り替えて言い直す。Claude Code は会話の流れを見て動くので、「さっきの続き」より「今の前提」を明確に渡したほうが強い。 たとえば、こう書き直す。 ```text ここからは前の指示をいったん忘れてください。 前提を変更します。 目的: 重複ファイルの削除ではなく、一覧化だけを行う 禁止事項:

長いやり取りほど、Claude Code は勝手に賢くなった気になって崩れる。実際には、途中で前提が抜ける、対象ファイルを取り違える、同じ修正を別名で繰り返す、こういう地味な事故が起きやすい。そこで効くのが途中要約だ。会話を区切って要約させる。節目で一度整理を挟むだけで、どこまで進んだか、何を決めたか、何を残したかが見えやすくなる。 Claude Code は、長い会話を続けるほど文脈をたくさん抱える。便利ではあるが、文脈が増えれば増えるほど「今なにを前提に話しているか」がぼやける。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初は「不要ファイルの洗い出し」だったのに、いつの間にか「命名規則の話」へ飛び、最後には「手順書の整形」に話が化ける。人間が手綱を握っていないと、会話は平気で迷子になる。 だから、節目を作る。たとえば、ひとつの大きな作業を終えたら、次の指示を出す前に要約を挟む。途中要約でもいいし、会話を区切って要約させる、でもいい。要は「今までの議論を、後で読んでも使える形で短く固めておけ」ということだ。 実際の頼み方は、こんな形で十分だ。 ```text ここまでの

Claude Code に任せると、気づいたら最後まで走り切っていて、途中の判断材料が消えることがある。これが地味に痛い。途中報告を入れさせる、中間報告を入れさせる、進捗の粒度を決める。この3つをちゃんと使うだけで、勝手に突き進んで戻れなくなる事故をかなり減らせる。 特に、ファイル整理や文書作成みたいな「正解はあるが、途中で見たい」作業では効く。全部終わってから見せられても、そこまでの流れが雑だと手戻りがだるい。最初に報告の頻度を決めておけば、Claude Code は勝手に走る道具ではなく、区切って確認しながら進む相棒になる。 まず押さえるべきなのは、指示は「こまめに見せて」だけでは弱いという点だ。Claude Code は、曖昧な指示だと節目の定義を自分で決めがちだし、その節目があなたの感覚とズレる。だから、何回ごとに、どの単位で、何を報告するのかまで決める。 たとえば、文書のたたき台を作らせるなら、こう書く。 ```text まず作業計画を短く出してから、3段階ごとに途中報告してください。 各途中報告では、今やったこと、次にやること、迷っている点を3行で示してください。 勝手に最

Claude Code に雑に「これを整理して」と投げると、返ってくるものが妙に長い説明文になって、あとで自分が切り貼りする羽目になる。ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown でほしいのか、表でほしいのか、成果物の形を固定してから頼む。これだけで手戻りがかなり減る。 たとえば、ファイル整理でも文書作成でも、欲しいのは「考え方」より「そのまま使える形」だろう。Markdown なら見出しや箇条書きをそのまま草案にできるし、表なら項目ごとの比較や一覧にそのまま流し込める。Claude Code は指示が曖昧だと、親切に見えて実は中途半端な出力を返しがちだ。そこを最初に縛るのが、このTIPSの肝である。 実務では、依頼文の冒頭に形式を明記するだけでいい。たとえばこうだ。 ```text 次の内容を、Markdown の見出し付きで整理してください。本文はそのまま貼れる形にしてください。 ``` Markdown にしたいなら、どこまで機械的に整えてよいかも添えると強い。 ```text 次のメモを Markdown で整形してください。 見出しは h2 相当

新しい指示をいきなり今の作業フォルダで試すと、だいたいろくなことにならない。差分が混ざる、途中のメモが散る、戻したいのに戻しにくい。Claude Code でやるなら、まず別作業場所を切って本流を汚さず試す。安全に試すための作業場を分ける、本番と検証を分離する、という考え方だ。 これをやると何がいいか。ひとつは、失敗しても本体を壊しにくいこと。もうひとつは、Claude Code に「この場ではこの作業だけ」と集中させやすいことだ。会話の流れも、ファイルの変更範囲も、ぐっと整理される。筆者は最初、いつものディレクトリでそのまま頼んで、関係ないファイルまで触られて手戻りした。あれは地味に痛い。作業場が分かれていないと、どこまでが試行でどこからが成果物か、すぐに曖昧になる。 やり方は単純で、元のリポジトリやフォルダをそのまま触らず、複製か別ブランチ、別ディレクトリで試す。Claude Code には、その作業場の中だけを見せればいい。 たとえばコードの修正なら、まず git の作業ツリーを複製して、そこで試すやり方が扱いやすい。 ```bash git clone /path/to/rep

終わった仕事をそのまま残す人は多い。しかも「あとで見るから」と言いながら、数日後には同じブランチ、同じ作業フォルダ、同じ不要ファイルの山にまた足を取られる。Claude Code はそこを雑に流さず、使い終わった作業場所を整理する、ブランチやフォルダの後片付けまで含めて片づけ役にできる。 ここでやりたいのは大げさな自動化ではない。作業が終わったら、残すものと捨てるものを切り分けて、コンテキストもディスクも空けることだ。これをやらないと、次の依頼で Claude Code が余計なファイルを拾ったり、古い差分に引っ張られたりして、地味に手戻りが増える。 「片付ける」と言っても、全部消せばいいわけではない。残すのは、あとで参照する必要があるものだけだ。たとえば、作業メモ、最終成果物、再利用したいテンプレート、あるいは案件の証跡になる書面だ。消すのは、途中で作った一時ファイル、古い出力、使い捨ての検証フォルダ、役目を終えたブランチだ。 Claude Code には、最初からこの判断を言葉で渡しておくといい。たとえばこんな依頼で十分だ。 ```text この作業が終わったら、後片付けまでやって

本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。 やることは単純だ。下書き専用の場所を作る。確定版に直書きしない。これだけで、Claude Code に考えさせる内容と、最終的に残す内容を分けられる。結果として、コンテキストの無駄遣いが減り、差分も読みやすくなる。ファイル整理でも文書作成でも効く、地味だが効き目の大きい癖だ。 たとえば、案件ごとにこんな構成にしておくと扱いやすい。 ```text project/ draft/ 2026-08-21-notes.md final/ report.md ``` Claude Code には、まず下書き側だけ触らせる。 ```bash claude ``` 依頼文はこんな具合でいい。 ```text draft/2026-08-21-notes.md に、報告書の材料を箇条書きで整理して。 このファイルは下書き専用。本文の確定版には触らないで。 まだ文章は整えなくていい。

ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。 変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。 Claude Code は、雑な状態でもそれなりに進めてしまう。そこが便利でもあり、危ないところでもある。 だからブランチを切る前に、作業対象を絞り、不要物を片づけ、今から何をやるかを一度だけ言葉にしておく。これだけで、生成される提案の精度がかなり変わる。非エンジニアのファイル整理でも同じだ。案件フォルダ、請求書、原稿、重複画像がごちゃついたまま頼むと、まず整理にコンテキストを食われる。先に片づけるほうが早い。 ブランチ名を考える前に、Claude Code に見せる範囲を狭める。これが一番効く。 巨大なリポジトリ全体を相手にすると、文脈が薄まる。人間でも、机の上に関係ない紙が山ほどあると集中できない。それと同じだ。 作業前にやるのは、この三つで足りる。 1. 今回の目的を一文で書く 2. 触るファ

同じファイルを同時に触らせると、だいたい面倒になる。Claude Code でもそこは変わらない。 「同時に走らせれば速いはず」と思って並列に投げると、diff がぶつかる、指示が食い違う、片方の修正をもう片方が上書きする、で手戻りが増える。やるべきことは単純で、同じファイルを同時に触らせない、衝突しにくい分担にすることだ。 筆者も最初は、複数の作業をまとめて投げてしまっていた。たとえば README と設定ファイルとメモ類を一気に直させる。見た目は速いが、あとで差分を見たら、同じ導入文を別の依頼で微妙に書き換えていたり、設定の文言だけ先祖返りしていたりする。人間が手で整える時間が増えるだけだった。Claude Code は魔法の共有フォルダではない。分担設計が雑だと、普通に詰まる。 一番効くのは、最初に「どの作業がどのファイル群を触るか」を切ることだ。Claude Code に渡す依頼も、ここを先に固定する。たとえば文書整理なら、章の並べ替え担当と誤字修正担当を分けない。どちらも同じ本文を触るからだ。先に構成を固め、そのあとで表記や体裁を直す順番にする。 ```text この作業では

Claude Code を使っているのに、あとで「このファイル、誰の仕事の途中だっけ」となるなら、だいたい混ぜすぎだ。 一時ファイルと成果物を分離する。作業途中のゴミを残さない。ここを雑にすると、ディスクはじわじわ減るし、差分は読みにくくなるし、別件の作業まで巻き込む。筆者も最初はよくやった。資料を整えてほしいだけなのに、途中生成したメモ、抽出結果、古い版が同じ場所に積もって、どれが納品物か分からなくなった。Claude Code は賢いが、置き場が曖昧だと平気で曖昧なまま積む。そこを人間が締める必要がある。 この話は開発だけの話ではない。文書作成、議事録整理、案件ごとのファイル整頓、画像やCSVの一時処理でも同じだ。成果物は成果物、一時物は一時物。まずこの線を引く。 一番やりやすいのは、作業ディレクトリを最初から分けることだ。案件単位、目的単位でフォルダを切り、途中の派生物はその中の一時置き場に閉じ込める。たとえば、原稿を磨くなら入力、作業中、完成版を分ける。不要なら一時置き場ごと消せる。これだけで後始末がかなり楽になる。 ```text project/ input/

同じ場所に全部ぶち込んで、あとから「どれがどの案件の資料だっけ」と探し回る。これ、かなり雑に見えて、実は一番コストが高い整理不足だ。Claude Code を使うなら、案件フォルダを切る、整理用の置き場を分ける、という発想に早めに寄せたほうがいい。そうしておくと、後から資料を拾いやすいし、生成した文書の差し替えや見直しも楽になる。 特に、文章作成や書類整理で Claude Code を使う人は、「ひとつの作業にひとつの場所」を作るだけで手戻りが減る。フォルダ名を見れば中身の当たりがつく状態にしておく、ただそれだけで探す時間が消える。雑に見えるけれど、効く。 Claude Code でやることは単純だ。案件ごとのディレクトリを先に作り、その中で入力資料、下書き、出力を分ける。散らかった作業場を毎回片づけるより、最初から箱を分けたほうが早い。 たとえば、こんな形にしておく。 ```bash projects/ 2026-01_契約書見直し/ 00_inbox/ 01_materials/ 02_drafts/ 03_output/ notes.md 2026-01_請求書整理/ 00_in

「1つの作業場所で少しずつ直せばいい」と思っていると、だいたい途中でぐちゃる。 Claude Code でも同じで、案を分けて試すなら、同じリポジトリの中で作業場所を分けて走らせるほうが圧倒的に扱いやすい。別作業場所で比較する、案を分けて試す、というやり方だ。 ここでの狙いは単純で、A案とB案を同時に触って、あとから見比べることだ。たとえば文書の章立てを2通り試す、ファイル整理のルールを2案作る、コード修正の方針を2つ並べて判断する。ひとつの案をいじっては戻し、またいじっては戻し、をやるよりずっと速い。しかも「どっちがよかったか」を diff で見やすい。 Claude Code は会話の文脈を使って作業するので、ひとつのセッションに何案も詰め込むと、途中から話が濁る。最初は筋がよくても、後半で別の方針が混じって、結局どれも中途半端になる。筆者は以前、1つの作業場所で「案Aの文面」「案Bの文面」「やっぱり章の順番も変更」を全部口頭でやって、最後にどれが本命か自分でもわからなくなった。あれは時間の無駄だった。分けておけば済んだ話だ。 やり方は難しくない。肝は、同じリポジトリを複製して別デ

本流を汚しながら試す人は、だいたい後で自分に殴られる。Claude Code は便利だが、便利なぶん、確定版のファイルにそのまま触らせると面倒が一気に増える。試し書きと確定版を分離する、つまり本番用の作業と試作品を分けるだけで、手戻りも差分の読みづらさもかなり減る。 ここで言う「本流を汚さない作業場所」は、要するに本番の原稿やデータとは別に、試すための場所を最初から切り出しておくことだ。Claude Code に新しい案を書かせるなら、いきなり本番ファイルをいじらせず、試作品用のディレクトリや複製ファイルで先に遊ばせる。これだけで、気軽に試して、納得したものだけを本番へ戻せるようになる。 たとえば文書作成なら、こんな分け方がわかりやすい。 ```bash project/ draft/ final/ ``` `draft/` は試作置き場、`final/` は確定版だ。Claude Code に対しては、最初からこう頼めばいい。 ```text draft/ にある原稿だけを使って、見出しの整理案を3つ出してください。 final/ のファイルは触らないでください。 必要なら draf

Claude Code を使い始めた人が最初にやりがちな失敗は、いきなり「このへん全部見て、いい感じにやって」と雑に投げることだ。これ、かなり危ない。作業フォルダを先に固定する、触らせる範囲を狭める。たったこれだけで、コンテキストの浪費と事故の確率が目に見えて下がる。 Claude Code は賢いが、置き場所が曖昧だと平気で話が広がる。広がるだけならまだいい。関係ないファイルを読んで、関係ない変更案を出して、最後に差分がやけに大きくなる。筆者は最初、ルートディレクトリでうっかり作業を始めて、ログや生成物まで拾わせてしまい、肝心の修正に入る前にコンテキストを食い潰した。あれはだるかった。先に「ここだけ触る」を決めるだけで、かなりマシになる。 やることは単純だ。Claude Code を起動する前に、作業対象のフォルダに移動してから始める。例えば、1 つの案件だけ、1 つの文書だけ、1 つの整理対象だけを置く場所を先に決める。 ```bash cd ~/work/project-a claude ``` これだけでも効く。要は、Claude Code に見せる世界を狭めるわけだ。コードな

終わったのに、作業場所だけが残り続ける。これがいちばん地味で、いちばん効く事故だ。Claude Code を使うと、調査用の分岐や作業ディレクトリをさっと作れるぶん、片付け、後始末、不要な作業場所の整理を後回しにしやすい。すると、次に開いたときに「どれが本線で、どれが捨てていいやつだっけ」と毎回確認する羽目になる。これ、かなりだるい。 この手の整理は、気合いでやるものではない。終わった瞬間に、消すものと残すものをはっきり分けておく。Claude Code はそこを手伝える。ブランチ名や作業フォルダの一覧を見せて、要るものだけ残し、不要なものを消す。文書作成やファイル整理でも同じだ。案件ごとのフォルダ、下書き、差し替え前の版。放っておくとノイズになるものを、作業が終わった段階でまとめて片付けておくと楽になる。 まずは、Claude Code に「何を片付けたいか」をそのまま渡すのが基本だ。曖昧に「整理して」で投げると、残すべきものまで巻き込んで痛い目を見る。たとえば Git のブランチ整理なら、こう頼めばいい。 ```bash claude ``` ```text 使い終わった作業ブラン

その場でいきなり本番ファイルを触るから、あとで余計な手戻りが出る。Claude Code を使うときは、下書き、確定版、ドラフトをちゃんと分けたほうがいい。ここを雑にすると、内容も差分も散らかるし、何を直したのか追いにくくなる。 たとえば文書作成でも、ファイル整理でも同じだ。最初の試し書きは別の場所で済ませて、固まってから本番に反映する。Claude Code は会話の流れを保ったまま編集できるので、思いつきの修正までそのまま本番へ流し込みやすい。便利だが、便利すぎるせいで事故る。 筆者も最初は、既存の原稿を開いたまま「ちょっとだけ整えて」と頼んで、気づいたら段落の順番までいじられていた。人間なら「ここはまだ仮」とわかるところでも、曖昧な指示だとそのまま確定扱いになる。下書きと確定版を分けるだけで、この事故はかなり減る。 やり方は難しくない。まず、作業用の場所を決める。たとえば案件ごとのフォルダを切って、そこに試し書き用のファイルを置く。完成したら、確定版だけを本番の場所にコピーする。Claude Code に頼むときも、最初から「このファイルはドラフト」「最後に確定版へ反映」と言い切

ごちゃつく人は、だいたい最初から全部を同じ箱に入れる。Claude Code でもそれをやると、あとで自分が掘り返す段階で詰まる。案件フォルダ、整理用フォルダ、分類ルールを先に決めておくと、ファイルが散らからないだけでなく、AI に任せるときの指示もかなり通りやすくなる。 Claude Code は会話の流れで作業を進める道具だが、見えている作業場所が曖昧だと、出力の置き場も曖昧になる。すると、レポート、下書き、画像、メモ、不要な一時ファイルが同じ階層に混ざる。これは後で探すのが面倒なだけではない。差分も見づらいし、どれを残すか判断しにくい。筆者は最初、案件名だけを雑に付けて全部ひとつのフォルダに押し込んでいたが、1か月後に「どれが最終版だっけ」で普通に迷子になった。あれは地味にだるい。 やることは単純で、案件ごとにルートフォルダを切る。中は用途で分ける。これだけでいい。たとえば文章作成なら、案件ごとに `input`、`draft`、`final`、`reference` を分ける。ファイル整理なら、`to_sort`、`keep`、`remove_candidate`、`archi

同じファイルを何人にも同時編集させて、あとでコンフリクト地獄に落ちる。これ、かなりありがちな失敗だ。Claude Code を使うときも同じで、便利だからこそ雑に並列化すると、差分が膨らみ、直す側がだるくなる。 競合回避、同時編集、衝突防止。この手の話は、結局「同じファイルに手を入れる人数を絞る」に尽きる。Claude Code に仕事を振るなら、最初からファイルの担当範囲を切っておくほうが早い。あとで diff を追いかけるより、最初の分け方に少し気を遣ったほうが、全体の時間は確実に減る。 筆者も最初は、複数のタスクを雑に並べて投げていた。結果、同じ README と設定ファイルを別々の指示でいじらせて、手戻りした。Claude Code 自体が悪いわけではない。指示の切り方が雑だと、当然こうなる。 Claude Code に頼むときは、タスクの粒度を「機能」ではなく「触るファイル」で考えると事故が減る。たとえば、ドキュメント整理なら「このフォルダ配下の Markdown だけ」「不要ファイルの洗い出しだけ」と切る。コード修正なら「このモジュールだけ」「この設定ファイルは触らない」と

雑に作業を始めると、あとでいちばん困るのは「何が途中で、何が完成か分からなくなる」ことだ。Claude Code でも同じで、一時ファイルと成果物を同じ置き場に放り込むと、差分は汚れるし、次の作業で前回のゴミまで拾う。地味だが、かなりだるい事故になる。 ここで分けたいのは単純だ。作業中だけ使う一時ファイル、最終的に残す成果物、そしてそれらを置く置き場。この3つを曖昧にしないだけで、Claude Code に頼む内容がはっきりするし、ディスク掃除も楽になる。非エンジニアでも効く。たとえば書類整理や文章作成でも、下書きと納品物を同じフォルダに混ぜると、あとで自分が混乱するだけだ。 まず、置き場を先に分ける。Claude Code に最初から「作業用」と「提出用」を別に扱わせるのがコツだ。 ```text この作業では、次の2つを分けて扱ってください。 一時ファイル: 作業中だけ使う下書き、途中生成物、変換途中のファイル 成果物: 最後に残すファイル、提出するファイル、保存しておく完成版 ルール: 一時ファイルは work/ に置く 成果物は out/ に置く work/ の中身は完成品とし

ブランチを切ってから整理しようとすると、だいたい面倒になる。差分が増え、指示があいまいになり、Claude Code に投げる文面まで雑になるからだ。先に片づける。これを事前整理、着手準備、分割開始の土台づくりとしてやっておくと、変更は小さく始めやすい。 Claude Code は、いきなり「全部直して」と投げるより、対象を絞ったほうが働きやすい。非エンジニアの作業でも同じで、フォルダの山、重複ファイル、長文の資料、散らかったメモを先に整えるだけで、次の一手がかなり軽くなる。ブランチを切る前の整理は、気合いの話ではない。後戻りを減らすための実務だ。 まずやることは単純だ。作業対象を一つに絞る。アプリのコードなら、機能追加なのか、文書修正なのか、不要ファイル削除なのかを分ける。文書作成なら、原稿を整えるのか、章立てを直すのか、語尾をそろえるのかを分ける。ここが混ざると、Claude Code への依頼が一気に濁る。 たとえば、次の順で始めるといい。 1. 触る場所を1つに決める 2. その場所にある不要物を先に外す 3. 変更したい目的を短く書く 4. そこで初めてブランチを切る、または

Claude Code に何でも見せると、だいたい雑になる。人間でもそうだが、道具も広すぎる作業範囲を渡すと、余計なファイルまで見に行って、指示の解像度が落ちる。 だから先に作業フォルダを決める。対象フォルダ、作業領域、作業範囲を絞る。これだけで、読み違いも、関係ない差分も、やたら長い往復も減る。 筆者は最初、リポジトリのルートをそのまま渡して「この周辺を整えて」と投げたことがある。結果は見た目以上にだるかった。README、設定ファイル、試作メモ、昔の検証コードまで混ざった場所を見せたせいで、Claude Code が「どれを本当に触るべきか」を拾うのに余計な時間を食い、修正も散った。 逆に、最初から一つのフォルダを決めておくと話が早い。触っていい場所がはっきりするので、提案も差分も小さくなる。これはエンジニア作業でも、書類整理でも、原稿整備でも同じだ。 やることは単純だ。Claude Code を起動する前に、先に作業フォルダへ移動してから始める。 ```bash cd ~/Documents/案件A claude ``` あるいは、最初の依頼文で対象をきっちり言う。 ```tex

それ、ひとつの作業場所で全部いじるから、あとでどれが良かったのか分からなくなるのだ。 Claude Code を使うときも同じで、雑に一案ずつ上書きしていると、比較検討どころか「前の案、どこへ行った」となる。並走作業をちゃんとやるなら、同じリポジトリでも作業場所を分ける。これだけで、複数案を並べて見比べやすくなり、手戻りも減る。 この手は、開発だけの話ではない。文書の言い回しを3案出したいとき、ファイル整理の方針を2通り試したいとき、不要ファイルの削減手順を安全側と攻め側で比べたいときにも効く。要は、Claude Code に「同じ土台で別の案を別々に育てさせる」やり方だ。 やり方は単純だ。リポジトリを複数の作業場所に分ける。Git を使っているなら、同じ履歴を保ったまま別ディレクトリを並べる `git worktree` がいちばん扱いやすい。別のフォルダにコピーしても動くが、重くなるし、うっかり片方だけ更新して混乱しやすい。比較したいなら、土台は同じで、作業場所だけ分けるほうがいい。 たとえば、メインの作業場所があるリポジトリで、2案を並走させるならこうする。 ```bash gi