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

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

本番の作業と試作品をごちゃ混ぜにする人は、だいたいあとで泣く。ファイルが増えたとき、どれが完成版でどれが実験用コピーなのか分からなくなり、戻したいのに戻せない。Claude Code を使うなら、ここを先に分けておくべきだ。退避先、検証用コピー、実験用コピーを最初から用意しておけば、雑に試しても本線を壊しにくい。 Claude Code は、雑にいじると便利だが、雑にいじる場所まで雑だとすぐに面倒になる。プロジェクトの本体で直接手を入れる代わりに、作業用の複製を切り出して、そこで試す。これだけで、差分の確認もしやすいし、失敗したときの引き際もはっきりする。 たとえば、文書整理ならこうだ。元のフォルダはそのまま残し、Claude Code には複製側だけを触らせる。 ```bash cp -R project project_trial cd project_trial claude ``` この形にしておくと、Claude Code に「このフォルダを整理して」「重複をまとめて」「古い下書きを退避して」と頼んでも、本体は残る。整理が気に入らなければ、試作品フォルダを捨てればいい。終わっ

本流のリポジトリでそのままClaude Codeを走らせて、あとで「あれ、どこまで触ったっけ」となるのは、かなりよくある失敗だ。雑に試すほど差分は太り、戻すのも面倒になる。だから最初から別の作業場所を切る。作業ブランチでもいいし、別ディレクトリでもいい。Gitのworktreeを使えば、同じリポジトリを複数の作業場所に分けて置ける。 これをやると、Claude Codeに試作を任せても本流を汚しにくい。文章修正でも、ファイル整理でも、コードの小改修でも同じだ。ひとつの場所で検討しながら、別の場所では元の状態をきれいに保てる。地味だが、後戻りの手間がかなり減る。 まず押さえるべきなのは、Claude Codeを「本番の作業場」から切り離すことだ。やり方は大きく三つある。作業ブランチを切ってそこで動かす、別ディレクトリに丸ごとコピーして触る、そしてGitのworktreeを使う。この中でいちばん扱いやすいのはworktreeだ。同じGitリポジトリを複数の作業ディレクトリとして並べられるので、片方を本流、もう片方を試作場にしやすい。 たとえば、今いるリポジトリの中身をそのまま壊したくないな

「やったつもり」で終わる調査ほど、あとで面倒なものはない。ログは残した、変更もした。なのに、どこが期待と違ったのか分からない。そういうときに効くのが、調査ログと変更結果を突き合わせるやり方だ。要するに、ログと差分を突き合わせる、期待とのズレを読む、という作業である。 Claude Code を使うと、この照合をかなり人力より楽にできる。しかも、コード修正だけの話ではない。ファイル整理でも、不要ファイル削除でも、文書の置き換えでも同じだ。先に「何を確認したか」を残し、あとで「実際に何が変わったか」を見比べる。これだけで、変な手戻りがかなり減る。 筆者は昔、似たようなことを雑にやって失敗した。ログは長いのに、肝心の変更結果を見ていなかったのだ。結果、Claude Code がちゃんと動いていても、別の場所のファイルを触っていたことに気づくのが遅れた。調査が浅いと、出力の量だけで安心してしまう。そこが罠だ。 この手の作業で大事なのは、まず「期待」を先に書くことだ。調査のメモと、実際の変更結果を比べるとき、期待が曖昧だとズレも見えない。逆に、期待がはっきりしていれば、Claude Code に

Claude Code に作業を投げるとき、いちばんもったいないのは「何をしたか」は残るのに「なぜそうしたか」が消えることだ。あとで diff を見返しても、そこで迷った理由が抜け落ちていると、同じ場所でまた立ち止まる。決定の根拠を記録する、途中の判断を書かせる、要するにその場の思考を残す使い方だ。 これ、コード修正だけの話ではない。ファイル整理でも、不要キャッシュの削除でも、文書作成でも同じだ。最終成果物だけ整っていても、途中で「これは消す」「これは残す」「これは後で別フォルダへ回す」と判断した理由が残っていないと、次回の自分がまたゼロから悩む。Claude Code はこの途中経過をきちんと書かせると、ただの自動化ツールから、あとで見返せる作業メモに変わる。 やり方は単純だ。最初から成果物だけを求めず、「判断のログも一緒に作れ」と明示する。たとえば、作業前の方針と、各判断の根拠、迷った点を別ファイルに残させる。 ```text この作業では、結果だけでなく判断理由も残してください。 次の3つを作ってください。 1. 変更した内容の要約 2. 重要な判断とその理由 3. 迷った点、今

Claude Code に長い作業メモを食わせて安心していると、だいたい途中で鈍る。読ませたいのは議事録ではなく、次に動くための要点だ。 作業メモを削る、短いメモだけ渡す。どちらも同じ話で、要するに「判断に必要な情報だけ残し、経緯は捨てる」ということになる。 これは開発でもファイル整理でも文書作成でも効く。メモが長いほど親切に見えるが、実際にはノイズが増えるだけだ。Claude Code は長文を読めるが、読めることと、うまく動けることは別物である。余計な経緯、迷い、雑談を持たせると、出力も散るし、手戻りも増える。 筆者は最初、メモを丁寧に残そうとして失敗した。たとえば「こういう方針で、あのときはこう考えて、例外はこれで……」と延々書いた結果、Claude Code が“全部大事”として扱ってしまい、結局どれも浅く触るだけになった。人間の議事録としては親切でも、作業指示としては重すぎる。そこから、残すべきなのは決定事項だけだと割り切った。 実際の書き方は単純でいい。長い経緯を要約しようとせず、最終的に決まったことだけを短く渡す。 ```text このフォルダの整理を進めてください。 残

長文を一気に投げて、あとで「どこまでやったんだっけ」となるのは、かなりありがちな失敗だ。Claude Code は賢いが、長い作業を雑に渡せば、平気で話が横に広がる。だから最初から章立てして、途中の迷子を減らす。別名で言えば、章ごとに分けて頼む、長文を分割して進める、だ。 このやり方は、コード修正だけの話ではない。散らかったフォルダの整理、重複ファイルの洗い出し、長い文書の清書、案件ごとの資料整理にもそのまま効く。要するに、ひと続きに見える作業を、Claude Code が追いやすい単位に切るという話である。 筆者は最初、ひと塊の依頼文で全部やらせて失敗した。途中で方針がブレるし、出力も冗長になる。修正のたびに前半の指示が薄まり、後半だけやけに詳しい、みたいなアンバランスも起きる。長い作業ほど、章ごとに切ったほうが早い。これは気分論ではなく、コンテキストの使い方の問題だ。 やり方は単純だ。まず作業全体を、人間の目で見て4〜6章くらいに割る。たとえば文書作成なら、「材料の整理」「目次づくり」「本文の下書き」「用語の統一」「最終確認」に分ける。ファイル整理なら、「現状の棚卸し」「重複候補の

長いやり取りを「気合いで覚えておいてくれるはず」と思うと、だいたいズレる。Claude Code は会話の文脈を持っているが、無限に細部を保持してくれるわけではない。途中で要約させる、セッションを区切る。この2つを入れるだけで、指示の食い違いと手戻りがかなり減る。 特に、ファイル整理、文書の推敲、複数ファイルの修正みたいに、途中で話題が広がりやすい作業ほど効く。最初は「全部つながっている」と感じるが、実際は、古い前提と新しい前提が少しずつ混ざって、最後に変な成果物が出る。あれは地味にだるい。筆者は一度、長いやり取りの末に「前回の方針」を Claude Code が別の意味で受け取り、修正済みのはずの箇所をもう一度広げられて、差分が無駄に肥大化したことがある。要約を挟んでいれば防げたやつだ。 やり方は単純だ。大きな作業を始める前に、区切りを決める。たとえば「第1段階では現状把握だけ」「ここまでで一度要約」「次の段階はこの要約を前提に続行」と言っておく。Claude Code に対しては、最初からこう頼めばいい。 ```text この作業は長くなりそうなので、途中で一度、ここまでの前提と決

Claude Code に何かを頼むとき、いちばん雑にやって痛い目を見るのがここだ。前の前提を残したまま「これも直して」と足すやり方である。方針変更時に前提を捨てる、古い前提を引きずらない。呼び方はいろいろあるが、やることは同じだ。前提が変わったなら、古い指示は上書きではなく、いったん消して言い直す。 この癖がないと、Claude Code は前の条件と今の条件を両方まじめに拾って、妙に遠回りな修正を返してくる。ファイル整理でも文書作成でも同じで、途中で方向を変えたのに「さっきの話」と「いまの話」を同居させると、成果物が中途半端になる。人間でもやるミスだが、CLI の相手だともっと露骨に出る。 たとえば最初に「このフォルダは不要だから削除候補を洗って」と頼み、そのあと気が変わって「削除ではなく、アーカイブ用に分類して」と言い足す場面がある。ここで前の指示を消さずに続けると、Claude Code は削除前提の整理と、保存前提の整理を両方気にして、判断が鈍る。結果として、見た目は丁寧でも実務では使いづらい出力になる。 こういうときは、追加説明ではなく、前提を切り替える指示を先に置く。実際

Claude Code に雑に「これ直して」と投げると、だいたい途中で迷う。迷っている間にコンテキストを食い、変更が広がり、最後は「で、どこで終わればいいんだ」という顔になる。そこで先にやるべきなのが、終了条件を明示すること、つまり出口を決めることだ。 これは大げさな話ではない。Claude Code は手を動かすのが速いぶん、終わり方が曖昧だと仕事がどんどん膨らむ。ファイル整理でも同じで、「不要ファイルを消して」とだけ言うと、似た名前のログやキャッシュまで気にし始めて、確認事項ばかり増える。文書作成でも、「整えて」と丸投げすると、構成をいじるのか、表現だけ直すのか、段落を増減するのかがぶれる。 先に止まりどころを言っておくと、作業はかなり安定する。Claude Code に期待するのは、万能な判断ではなく、決めた出口までの到達だ。そこを外すと、出力は増えるのに満足度は下がる。 たとえば、こんな頼み方にする。 ```text この作業は、次の終了条件を満たしたら止めてください。 対象は docs/ 配下だけ 変更は文章の修正のみ 見出し構成は変えない 事実関係の不明点は推測で埋めず、該

Claude Code に雑に「いい感じに進めて」と投げると、あとで見たときに気持ちよく進んでいるようでいて、実はだいぶ怖い。勝手に進む時間が長いほど、手戻りは重くなる。進捗報告の粒度を決める、節目だけ返させる。この二つを先に決めておくだけで、黙って深掘りしすぎる事故はかなり減る。 特に Claude Code は、仕事が進むほど差分が大きくなりやすい。ファイル整理でも、文書作成でも、コード修正でも同じだ。最初に方向を外すと、そのまま大量の変更を積み上げてから「これでいい？」と出してくる。そこで止めると、確認も修正も重い。逆に途中報告を細かくしすぎると、今度は毎回止まりすぎて、こちらの集中が切れる。だから大事なのは、止める回数ではなく、止める場所を決めることだ。 たとえば、最初にこう指示する。 ```text まず作業方針を3行で出してから進めてください。 以後は、各主要ステップの完了ごとに短く途中報告してください。 実装や整理を勝手に最後まで進めず、節目で止まって確認を求めてください。 ``` これだけでもだいぶ違う。ポイントは「何分ごとに報告」ではなく「どの節目で報告」かを指定する

長文でだらだら返すように見えて、実は最初の一言が悪いだけ、というケースは多い。Claude Code は、こちらが曖昧に投げると、普通に曖昧なまま広げてくる。そこで効くのが、出力形式を先に固定する、要するに「Markdown か表かを先に言う」やり方だ。返答の長さそのものを細かく縛る前に、まず箱を決める。これだけで、返ってくる文章の輪郭がかなり締まる。 筆者は最初、内容だけ先に頼んでいた。たとえば「このフォルダの中身を整理して、不要そうなものを教えて」とだけ投げる。すると Claude Code は、親切に説明を足しすぎる。結果、肝心の候補が埋もれる。人間が欲しいのは整理の方であって、長い前置きではない。ここで「表で」「箇条書きで」「見出しは3つまで」と先に言うと、返答のノイズが目に見えて減る。 いちばん使いやすいのは、最初の指示で出力の器を指定することだ。たとえば文書作成なら、最初から Markdown の見出し付きで短くまとめさせる。ファイル整理なら、表で候補を並べさせる。コードレビューなら、箇条書きで問題点だけ出させる。Claude Code は、形が決まると余計な説明を削りやす

途中の作業をそのまま投げると、あとで読む人が高確率で詰まる。Claude Code でも同じで、最後に「最終要約」までやっておかないと、出力は立派でも引き継ぎには弱い。ここでやるのは、単なる要約ではない。引き継ぎ用に整形する、つまり「次の人が迷わず動ける形」に潰し込む作業だ。 この一手が効く場面は多い。コード変更のあとに別の人へ渡すとき。ファイル整理の結果を残すとき。長い会話の内容を文書に落とすとき。要点だけを抜き出せば済む話ではなく、何をやったか、何が残っているか、次に何を見ればいいかを、順番つきで残す必要がある。 筆者は最初、Claude Code に「最後にまとめて」とだけ投げて、見事に中身の薄い箇条書きだけを受け取ったことがある。たしかに短い。だが、次に何をすればいいのかが抜け落ちていて、結局もう一回会話を掘り返した。あれは時間の無駄だった。まとめは短くすることではない。使える形に圧縮することだ。 まずは、まとめの役割をはっきり分ける。Claude Code に渡す依頼は、ただの要約ではなく、次のどれを作るのかを明示するのがコツだ。 ```text この会話内容を、引き継ぎ用に

長いメモを抱えたまま Claude Code に作業させると、だいたい途中で鈍る。読ませた本人が満足してしまうのがいちばん厄介だ。実際には、後で効くのは「何を決めたか」だけで、経緯や雑談はほぼ邪魔になる。 ここでいうのは、作業メモを絞る、短い指示で回す、という考え方だ。Claude Code に持たせるメモは、思いついたことを全部盛りしたメモ帳ではない。作業の途中で迷わないように、決定事項だけを残す道具だ。 筆者は最初、仕様の経緯も未決定の論点も、全部そのまま投げていた。すると Claude Code は筋のいい補助をする前に、どこが確定でどこが未確定かを読み解くところで余計なコンテキストを使う。結果、出てくる差分が散らかる。ひどいときは、古い前提を拾って戻り作業が増えた。あれは単純に、メモが長すぎたせいだ。 Claude Code に渡すメモは、次のような形に寄せると強い。 ```text 目的: README を短くする 決定事項: 対象は使い方の説明だけ インストール手順は別ファイルに分けない 例は macOS と Linux のみ 文章は日本語で書く 既存の見出し構成は維持する

長い資料を全部貼って「さあ読め」でうまくいくと思っているなら、そこがまずズレている。Claude Code は長文を処理できるが、だからといって一気読みさせるのが正解ではない。むしろ章ごとに渡したほうが、分割投入もしやすいし、章単位で扱うほうが手戻りも減る。 筆者は最初、仕様書や長い手順書を丸ごと投げて、あとから「この章の前提は無視して」とか「さっきの表だけ見て」と言い直して、かなり無駄を出した。大きい資料ほど、最初のひと押しを雑にすると全体がだるくなる。Claude Code にも、人間にもだ。 やることは単純だ。資料をいきなり全文で渡さず、章や節ごとに区切る。最初に全体像だけ渡して、そのあと必要な章を順番に扱う。これで指示の焦点がぶれにくくなる。 たとえば、次のような資料があるとする。 企画書 契約書のたたき台 手順書 フォルダ内の大量のメモ 監査用のチェックリスト この手のものは、最初から全文を相手に食わせるより、目次や章立てを先に見せたほうがいい。Claude Code は、その場で全体構造をつかんでから作業したほうが強い。 依頼文は、こんなふうに切る。 ```text この資

「あれ、なんでこうしたんだっけ」で止まるなら、まだ手戻りは小さいほうだ。厄介なのは、Claude Code に作業を続けさせたあとで、前の判断が消えていることだ。判断ログ、あるいは「なぜそうしたかを記録する」癖がないと、数十分後に自分で自分の指示を疑う羽目になる。 Claude Code は、雑に言えば“今ある材料をもとに次の一手を組み立てる”道具だ。だからこそ、途中の節目で「何を選んで、何を捨てたか」を残しておくと強い。あとから迷ったとき、同じ調査をもう一回やらなくて済む。コンテキストの浪費も減る。diff が無駄に膨らむのも防げる。地味だが、効く。 たとえば、ファイル整理でも文書作成でも同じだ。最初は「このフォルダをこう切る」「この重複ファイルは残す」「この表現はやめる」と決める。ところが作業が進むと、Claude Code も人間も、最初の前提を薄く忘れる。そこで、節目ごとに短い判断ログを残す。これだけで、あとから「なぜその方針にしたか」を追える。 やり方は難しくない。Claude Code に作業を頼むとき、最初に「判断理由も一緒に残して」と明示する。しかも、長文でだらだら書か

そこを曖昧にしたまま進めると、Claude Code はわりと平気で昔の指示を守り続ける。人間側が方針を変えたつもりでも、前提を更新する、古い指示を捨てる、をやらないと、作業の芯がずれていく。 これは開発だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初に「古い書類は残す」と言っていたのに、途中で「不要なものは捨てる」に変えたなら、その場で言い直す。ここをサボると、Claude Code は古いルールに忠実なまま、こっちの意図と違う方向へきれいに進む。丁寧なのが逆にまずい。 筆者はこれで何度か手戻りした。最初は「このフォルダ内の資料を整理して」と頼み、途中で「やっぱり重複ファイルは削除して」と方針を変えたのに、前の「削除しないで整える」前提が残っていたせいで、無難な並べ替えだけで終わったことがある。やるべきだったのは、追加でお願いすることではなく、古い前提を明示して捨てることだった。 たとえば、途中でルールを変えるなら、こう言い直す。 ```text ここまでの前提はいったん捨ててください。 方針を更新します。 以前の「削除しない」は無効です これからは重複

会話が長引くたびに、最初の前提を人間が頭の中で持ち運ぶ前提で進めるのは雑だ。Claude Code に任せるなら、途中要約でその荷物を一回降ろしたほうがいい。要点を引き継ぐ、という考え方だ。長い依頼、複数ファイルの整理、何段階もある文書作成では、節目で「いま何を前提に、どこまで決まったか」を短く残さないと、後半で平気で話がねじれる。 筆者は最初、長い作業をそのまま流して痛い目を見た。たとえば「このフォルダの重複ファイルを整理して、不要なものを消し、最後に削除候補だけ一覧にして」と一気に頼むと、途中で基準が曖昧になって、候補の抽出と削除の判断が混線する。会話の後半になるほど、最初に決めた条件を雑に扱いやすい。だから節目ごとに要約させる。これだけで、後戻りがかなり減る。 やり方は単純だ。長い作業を最初から最後まで一息でやらせない。区切りを作って、そのたびに「ここまでの前提」「決まったこと」「未決事項」を短くまとめさせる。Claude Code への頼み方は、こんな形でいい。 ```text この作業は長くなりそうなので、節目ごとに途中要約を入れてください。 要約では次の3点だけを書いてくだ

長い前提をそのまま投げ込むと、だいたい詰まる。Claude Code は賢いが、無限に文脈を飲み込んでも気持ちよくなるわけではない。むしろ要点が埋もれて、肝心の判断がぼやける。コンテキストを節約する、長い前提を短くする。ここを雑にすると、あとで手戻りが増える。 筆者は最初、仕様メモや経緯説明をそのまま貼り付けていた。すると返ってくるのは、やたら丁寧だが焦点のずれた整理だったり、最初に読ませた長文の細部に引っ張られた提案だったりする。あれは地味にだるい。要るのは長文の再掲ではなく、判断に必要な芯だけだ。 Claude Code に食わせる情報は、たいてい三層に分けると扱いやすい。まず「何をしたいか」。次に「絶対に守る条件」。最後に「判断に必要な最小限の背景」だ。長い経緯、途中の愚痴、似たような失敗談は、基本的に落としていい。残すのは、後で答えの質に効くものだけである。 たとえば、ファイル整理の依頼なら、こう削る。 ```text 依頼: 仕事用フォルダの中で、重複しているPDFと古い下書きを見つけたい 削除前に候補を一覧にしてほしい 誤って正式版を消したくない 背景: 案件ごとにフォルダ

ここを曖昧にしたまま投げると、Claude Code はだいたい素直に広がる。つまり、読みやすい文章ではなく、あとで直しにくい長文や、表にしたかったのに段落で返ってくるあの感じだ。先に成果物の形を決める、要するに出力形式を指定する。これだけで手戻りがかなり減る。 Claude Code に何かを頼むとき、内容だけでなく「最終的にどう並べるか」を先に固定すると強い。Markdown で見出し付きの説明文にするのか、比較しやすい表にするのか。ここを最初に決めておくと、内容の整理もその形に引っ張られる。逆に、形を後回しにすると、途中まで書かせたあとに「やっぱり表で」と言って崩す羽目になる。筆者はこれで何度も手戻りした。特に、ファイル整理の説明や手順書を作らせるときに、段落で長く返ってきたものを後から表に直すのはだるい。最初に固定しておけばいい。 たとえば、読み物や手順書なら Markdown に寄せる。箇条書き、見出し、小見出し、コードブロックを使いやすいからだ。比較、一覧、チェック用の整理なら表が向く。たとえば「どのフォルダに何を入れるか」「この書類は残すか捨てるか」「このキャッシュは削除

整理作業でいちばん危ないのは、きれいになった気がして終わることだ。削ったはずのファイルが残っていたり、直したつもりの文書が別の場所で壊れていたりする。こういうときに効くのが、整理前後比較、棚卸し確認だ。Claude Code に処理の前と後を見比べさせると、何を減らしたのか、どこが変わったのか、逆に何が残っているのかを落ち着いて追える。 非エンジニアの整理でこれが役に立つ場面は多い。たとえば、案件フォルダの重複書類を減らす、古い下書きをまとめる、写真やPDFの置き場を整える、不要なキャッシュや一時ファイルを洗う。人間が目で追うと、どうしても「たぶん大丈夫」で済ませがちだ。そこを比較で締める。雑に見える作業ほど、前後差分を残したほうが後で助かる。 やり方は単純だ。Claude Code に「処理前の一覧を保存して、処理後と比べて報告して」と頼む。ファイル整理なら、対象フォルダの状態を作業前に記録しておき、処理後にもう一度見比べる。たとえば、こんな依頼で十分だ。 ```text このフォルダの整理をしたいです。まず処理前の状態を記録してください。 対象はこのディレクトリ配下のファイル一覧、

依頼テンプレを「一回作って終わり」にしていると、だいたい次の依頼でまた同じ手戻りを食う。そこを放置して、毎回ゼロから雑に投げ直すのはかなりもったいない。Claude Code は一発で完璧な代物を出す道具ではないが、作業記録を見ながら依頼テンプレ改善を回すと、次回の指示精度が目に見えて上がる。再発防止メモとしても効く。 ここで言う作業記録は、長大なログのことではない。Claude Code に何を頼んだか、どこで迷走したか、どの出力がそのまま使えたか、そこだけ拾えばいい。雑に見えるが、ここを残さないとテンプレは劣化する。人間の記憶はだいたい都合よく丸くなるので、実際に詰まった箇所を次回へ渡せない。 たとえば、ファイル整理なら「重複候補を見つけて」と頼んだのに、判定基準が曖昧で候補が多すぎた。文書作成なら、章立てはよかったのにトーンが硬すぎて直しが増えた。コード修正なら、対象ファイルの範囲を絞らずに話を始めたせいで、差分が肥大化した。こういうズレは、記録を元にテンプレへ戻せばかなり減る。 やり方は単純だ。まず、その作業の終わりに短い記録を残す。次に、その記録から「次回も固定したい条件」と

これを混ぜる人は、だいたいあとで自分の首を絞める。 調べた結果のメモと、実際の修正を同じ流れで雑にやると、何を根拠に直したのか分からなくなるし、Claude Code のコンテキストも無駄に食う。調査記録を残して、修正分離する。たったそれだけで、後から見返したときの説明力がまるで違う。 Claude Code では、まず「調べるだけ」の往復を終わらせ、その内容を独立した記録として残してから、別のやり取りで修正に入るのが強い。 このやり方にすると、判断の履歴が消えにくい。ファイル整理でも文書作成でも同じだ。調査の途中でいじり始めると、いつの間にか「何を直していたのか」が溶ける。筆者は昔、原因調査のつもりで会話を続けながらそのまま修正まで頼み、どの変更が診断で、どの変更が本命か分からない差分を抱えたことがある。あとから戻すのが面倒で、かなりだるかった。 やり方は単純だ。まず Claude Code に調査だけを頼み、最後に「修正はまだしない」と釘を刺す。たとえば、こんな流れにする。 ```text このリポジトリについて、次の点だけ調べて。 1. どのファイルが関係しているか 2. どこで

同じ失敗に見えても、直すべき場所はぜんぜん違う。そこを混ぜると、Claude Code に何を頼むべきかが毎回ぼやけて、手戻りだけが増える。 ここで分けたいのは、再現できる失敗と、たまたま起きた失敗だ。言い換えると、再現性の確認と偶発エラーの切り分けである。 たとえば、ある文書を並べ替えたら毎回同じファイル名で衝突するなら、それは再現できる失敗だ。入力と手順が同じなら、同じところでつまずく。逆に、たまたま一度だけ同期が遅れてファイルが見えなかった、ネットワークの瞬断でコマンドが落ちた、ディスクが一杯の瞬間だけ保存に失敗した、という類は偶発エラーだ。ここを同じノリで扱うと、Claude Code に「とりあえずもう一回試す」を延々やらせる羽目になる。 筆者は最初、この区別を雑にしていた。ログを見ずに「なんか失敗した」で片づけ、Claude Code に同じ修正を何度も投げたことがある。結果、差分だけが太り、原因は残ったまま。あれはかなりだるい。以後は、まず「再現するのか、しないのか」を先に決めるようにしている。 Claude Code を使うなら、最初の依頼でこの切り分けを明示したほうが

Claude Code でいちばん無駄が出るのは、ちゃんと動いているのに「なんか違う」とだけ感じて、そこを言語化できないときだ。 期待との差分、つまり出力のズレを読めないと、同じ依頼を少しずつ言い換えては手戻りする。これが地味にだるい。しかも、ズレている場所は毎回同じではない。要件の理解が浅いのか、対象ファイルの見方が違うのか、やり方は合っているのに粒度だけ外したのか。そこを切り分けるだけで、Claude Code はかなり扱いやすくなる。 まず押さえるべきなのは、Claude Code の出力は「答え」ではなく「解釈の結果」だという点だ。だから、期待と違ったときに見るべきなのは、出力の文章そのものだけではない。どのファイルを見たのか、どこを変更対象だと思ったのか、何を省いたのか。その読み取りが要る。 たとえば、フォルダ整理を頼んで、古い画像だけ消してほしかったのに、関連しそうなファイルまで候補に上げてきたとする。ここで「違う」で終わると、次もまた似たズレを踏む。見るべきは、Claude Code が「古い画像」という言葉をどう解釈したかだ。更新日時で見たのか、ファイル名で見たのか、拡

貼ったログをそのまま信じて進むと、あとで「そこ、直ってないじゃん」で止まる。いちばんだるいのは、直したつもりの差分と、実際に変わったファイルがズレていることだ。 ここで使うのがログ照合、つまり貼ったログと実際の変更を突き合わせるやり方である。Claude Code に作業を振ったあと、返ってきた説明と、リポジトリ上の実ファイルや `git diff` を並べて見る。これをやるだけで、見落とし、やり残し、説明だけ立派な変更をかなり潰せる。 筆者はこれをサボって、README の説明は更新されたのに設定ファイルの例が古いまま、という半端な状態を何度も踏んだ。見た目はそれっぽいのに、実行すると壊れる。ああいう事故は、照合を省いたときに起きる。 まず、Claude Code には「作業後に変更内容を要約して」と頼む。大事なのは、要約だけで終わらせず、実際の差分と照合する前提を最初から入れることだ。たとえばこんな頼み方でいい。 ```text この作業で変更したファイルを一覧にして、各ファイルで何を変えたかを短く要約してください。 そのうえで、実際の差分と照合して、説明と食い違う点や見落としがあ

長い作業を丸ごと一気にClaude Codeへ投げて、そのまま最後まで追いかけようとする。これ、かなり詰まる。途中で何を決めたかが消えるから、後から「なぜこの構成にしたんだっけ」「どのファイルを触ったんだっけ」が毎回発生する。 そこで効くのが、途中要約、つまり節目メモだ。作業の区切りごとに、今の判断・変更点・未完了を短く残しておく。これだけで、後追い確認、再開、レビュー、差し戻しが一気に楽になる。Claude Codeにとっても、人間にとってもだ。長丁場の文書作成、ファイル整理、不要データの洗い出し、ディスク削減、コード修正まで、全部に効く。 やることは単純だ。大きな依頼を小分けにして、各段階の終わりで「ここまでの要点」を必ず出させる。さらに、その要点を次の依頼の前提として使う。これで会話の流れが細くならない。 たとえば、案件フォルダを整理して報告書の下書きを作るなら、最初から全部を一気にやらせない。まずは現状把握、次に整理方針、最後に実作業だ。そのたびに要点を残す。 ```text この作業は3段階で進めてください。 1. 現状把握 フォルダ内の主要なファイル種類 重複しそうなもの

Claude Code に仕事を投げておいて、あとから「なんでそうしたんだっけ」と困る人は多い。 出力がそれっぽく終わると満足しがちだが、実務で痛いのはそこではない。途中で何を見て、何を捨てて、何を採ったかが残っていないことだ。これがないと、数日後に見返した瞬間に意味が死ぬ。 ここで効くのが、判断メモ、つまり意思決定ログだ。 Claude Code に「結果だけでなく、途中の判断も短く残せ」と最初から頼む。そうすると、あとから説明しやすい形で残る。ファイル整理でも文書作成でも同じで、最後の成果物だけ作らせると、なぜその構成になったのかが消える。消えた説明は、だいたい再現できない。ここがだるい。 たとえば、文書を整えるなら、Claude Code にこう頼む。 ```text この作業では、最終結果だけでなく判断メモも残してください。 各ファイルについて、以下を短く記録してください。 何を基準にその判断をしたか 迷った案があれば何だったか 最終的に採用した理由 後で見返したときに説明に使える一文 本文の中に長く混ぜ込まず、最後に「判断メモ」としてまとめてください。 ``` ファイル整理な

雑に投げた指示がそのまま通ると思っているなら、そこが一番あぶない。Claude Code は空気を読んで勝手に名案をひねり出す道具ではないので、失敗した依頼はその場で拾って、次の指示に直すほうがずっと強い。ここで使うのが、手戻り分析とやり直しポイントの洗い出しだ。会話のどこでズレたかを見つけて、同じ事故をもう一回起こさない形に変える。 このやり方のうまみは単純だ。失敗を「なかったこと」にせず、次の依頼文に変換できる。Claude Code にやり直しをさせるたびに、曖昧な言い方が減り、余計な探索や無駄な diff も減る。ファイル整理でも文書作成でも、ここをサボると、あとで「なんでここを触った？」みたいな修正が増える。地味だが、効く。 まずやることは、失敗した依頼をそのまま見返すことだ。Claude Code との会話ログの中で、結果がズレた返答、余計な修正、期待外れの要約、触ってほしくないファイルへの変更を拾う。重要なのは、結果だけを見るのでなく、その前の自分の依頼文も一緒に見ることだ。たいてい問題は、モデルの気まぐれではなく、依頼のどこかが曖昧だったり、前提が抜けていたりする。 た

Claude Code に雑に任せて「なんか遅い」「なんか遠回りした」で終わらせるのは、かなりもったいない。迷いはだいたい作業ログに出る。会話ログ、作業履歴を見返せば、どこで前提を取り違えたか、どの指示が弱かったか、どこで無駄な探索を始めたかが見えてくる。 ここを拾えるようになると、同じ依頼を次回からずっと軽くできる。コード修正でも、ファイル整理でも、文書作成でも同じだ。Claude Code が迷う瞬間を特定できれば、指示の出し方が一段よくなる。人間側の手戻りも減る。 まず見る場所は、単純でいい。Claude Code の作業中に残る会話ログや出力を、ひとまとまりの履歴として読む。やることは「何をしたか」を追うことではなく、「どこで方針が揺れたか」を探すことだ。 たとえば、こんな依頼を出したとする。 ```text このリポジトリ内の古い設定ファイルを整理して、重複しているものをまとめてください。 削除してよい候補も出してください。 ``` この手の依頼で迷いが出るとき、ログにはこういうサインが出やすい。 似た名前のファイルを何度も行き来している 先に削除候補を出すはずが、比較だけを

長く作業したあとに、ただ「終わりました」で投げるのは雑だ。Claude Code でも同じで、最後に全体を短くまとめ直しておかないと、あとで自分が困る。引き継ぎメモ、あるいは仕上げ要約を残しておくと、何を変えたのか、何が未完了なのか、次にどこから触ればいいのかが一発で見える。 このひと手間は、開発者だけの話ではない。ファイル整理でも、原稿作成でも、ディスク削減でも効く。途中で Claude Code に細かい作業を任せるほど、最後の要約がないと成果物が散らばる。差分はあるのに意図が残っていない。これがいちばんだるい。 実際、筆者は一度、長い整理作業のあとに要約を作らせず、そのまま別日に続きを見て手戻りした。変更点は散らかっているのに、どのファイルをなぜ触ったのかが分からない。結局、ログを掘り返して再確認する羽目になった。最後に短くまとめるだけで避けられた無駄だ。 Claude Code に頼むとき、最後のまとめは「長文の報告書」を作らせる場面ではない。必要なのは、引き継げる最小単位の整理だ。目的は三つある。何をやったか、何が残っているか、次に何を見ればいいか。この三点が入っていれば十分

Claude Code に「要点だけ頼む」と言っても、返ってくる文章が妙に長い。あれはツールが悪いというより、こちらが出力の型を渡していないことが多い。出力制約とか成果物の型を先に決めておくと、返答の長さはかなり扱いやすくなる。 雑に頼むと、Claude Code は親切に広げる。しかも、説明が増えるほどタスクは見失いやすい。ファイル整理でも文書作成でも同じで、「何をどの形で返すか」を先に縛ったほうが、あとで読む側が圧倒的に楽だ。筆者は以前、3 ファイルだけ確認したいのに、背景説明つきで長文を返され、結局自分で見直した。あれは地味にだるい。最初から形式を指定していれば済んだ話だった。 まず効くのは、指示文の頭で「長さ」と「形式」を固定することだ。たとえば、こんな頼み方にする。 ```text 次の条件で返答してください。 3項目だけ 各項目は1文 余計な前置きは不要 箇条書き以外は書かない 対象: ... ``` この手の制約は、単に短くさせるためだけのものではない。何を出力してほしいかの輪郭をはっきりさせるために入れる。Claude Code は、曖昧な依頼に対しては補足や説明を足し

途中で話が変わったのに、前の指示を引きずったまま走る。これが一番だるい。Claude Code でも同じで、最初の前提のまま作業を続けさせると、見当違いの差分や、やたら長い説明を生む。ここで効くのが前提更新、つまり指示のリセットだ。 たとえば「このフォルダの画像だけ整理して」と頼んだあとに、「やっぱり古いPDFも対象にして」「いや、削除じゃなく一覧化だけで」と方針が変わる場面がある。こういうときは、前の依頼を上書きする感覚で言い直す。曖昧に「それも含めて続けて」ではだめだ。古い前提を捨てて、今の目的をはっきり言い直すほうが速い。 実際の頼み方は、こういう形でいい。 ```text ここまでの前提は一度忘れてください。 目的は「重複ファイルの削除」ではなく、「重複候補の一覧作成」に変わりました。 削除はしないでください。 出力は、重複の可能性があるファイル名、サイズ、保存場所を表でまとめてください。 ``` この言い方の肝は、単に「変更です」と伝えるだけで終わらせないことだ。何を捨てて、何を残すかを明示する。Claude Code は会話の流れを参照するので、前の指示が残ったままだと、意

ファイル整理で一番まずいのは、いきなり中身を見始めることだ。そこからやると、分類がその場の気分でぶれて、あとで自分でも意味が分からなくなる。Claude Code を使うなら、先に決めるのは「何をどう分けるか」だけでいい。分類基準を先に決める、仕分けルールを固定する、ここを飛ばすと、整理はほぼ確実にぐだる。 Claude Code は、散らかったフォルダを人間みたいに眺めて「これ重要そうですね」と曖昧に気を利かせる道具ではない。こちらがルールを渡すと、かなり素直に動く。逆に言えば、ルールが曖昧だと、曖昧なまま大量のファイルを処理して、後で確認地獄になる。筆者は最初、フォルダを見せて「いい感じに分類して」と頼み、戻ってきた結果を見て手が止まった。基準がない分類は、作業が速いぶんだけ修正がだるい。 まずやるべきことは、ファイルそのものではなく、分類の軸を決めることだ。たとえば案件書類なら「案件名」「種別」「日付」、写真なら「イベント名」「日付」「仮置きか確定か」、ダウンロード済みの雑多なファイルなら「残す」「アーカイブ」「削除候補」の三択にする。ここで大事なのは、軸を増やしすぎないことだ。

長文を一気に書かせて、あとで整えればいい——このやり方、たいてい途中で崩れる。Claude Code は便利だが、雑に丸投げすると、前半で決めた言い回しが後半で勝手にズレたり、同じ話を二度書いたりする。長い文章ほど、分割執筆、章立て執筆に切り替えたほうがいい。 これは開発の話だけではない。仕様書、手順書、社内向けの案内文、案件ごとのメモ整理、重複した文章の圧縮まで、長文を扱う場面は多い。章ごとに作らせると、各パートの狙いがぶれにくくなるし、直しやすい。全文を一発で出させるより、最後まで読める下書きになりやすい。 やり方は単純だ。最初に全体構成を作らせ、そのあとで章単位に書かせる。ここで大事なのは、「最初から完成文を求めない」ことだ。完成品を一気に欲しがると、Claude Code は広い文脈を抱えたまま無難な文章を量産しがちになる。結果、どこかで力尽きる。筆者はこれで、序盤は切れ味があるのに後半だけ急に総論っぽくなる下書きを何度も踏んだ。あれは直すのがだるい。 たとえば、こんな流れにする。 ```text この文章を章ごとに分けて下書きしたい。先に全体の章立てを提案して。 条件: 読者

調べものをしたあとに、そのまま長文を抱えて次の指示を投げると、Claude Code のコンテキストはあっさり太る。ここで雑に進めると、必要な事実よりも、読み込んだメモやログのほうが邪魔になる。だから一度、中間要約で調査の圧縮を挟む。これだけで、次の一手がかなり安定する。 たとえば、ファイル整理でも文書作成でも同じだ。散らかったフォルダ一覧、重複候補、PDF の抜き書き、議事メモ。これらを全部そのまま次の依頼に放り込むと、指示がぼやける。Claude Code は「何を見たか」より「何を判断材料にするか」を短く渡したほうが強い。 要は、調べた直後にこう使う。 ```text ここまでに調べた内容を、次の指示に渡しやすい形で短く要約して。 目的、重要な事実、迷いどころ、次に決めるべきことを分けて書いて。 余計な説明は削って、後続の作業に必要な情報だけ残して。 ``` この一文だけでもかなり効くが、もう少し実務向けに詰めると使いやすい。筆者は最初、調べた内容をそのまま貼って次の指示を出していた。すると、要約すべき箇所まで毎回読み直すことになり、コンテキストが無駄に消える。し

雑にまとめて一気に投げると、Claude Code はわりと簡単に見失う。人間のほうもだが、出力のほうもだ。 ここで効くのが、単一タスク化、あるいは集中実行という考え方である。やることを一度に1個に絞る。すると、指示が短くなり、差分が小さくなり、途中で何を直しているのか分からなくなる事故が減る。 これはコード修正だけの話ではない。ファイル整理でも、不要ファイルの削除でも、文書作成でも同じだ。 「このフォルダを片付ける」「この文章の冗長さだけ削る」「この1本のスクリプトの失敗原因だけ追う」と分けるだけで、かなり安定する。 筆者は最初、欲張って「このディレクトリの整理、重複削除、README更新、ついでに不要な設定も見て」と一気に頼んで手戻りした。返ってきた結果は悪くないのに、どこに何を置いたか、何を触ったか、こちらが追えない。差分がでかくなると、レビューもつらい。Claude Code は優秀でも、曖昧で広い依頼を丸ごと飲み込ませると、だいたい散る。 要は、作業を「目的」で切るのではなく、「一回の実行単位」で切ることだ。 たとえば次のようにする。 ```text この作業は3段階に分けた

長い依頼を一息で投げて、そのまま全部を抱えさせる。これ、いちばん雑に見えて、いちばん手戻りが増えるやり方だ。Claude Code は長文も受けるが、だからといって一発で正解を取りにいく道具ではない。むしろ、段階実行や途中確認を挟んだほうが、速いし、壊れにくい。 特に Claude Code では、ファイルをまたぐ変更、削除候補の洗い出し、文書の下書き、リネーム方針の整理みたいな作業で効く。最初に方針だけ固めて、次に実作業、最後に差分確認。これだけで、変な前提のまま大量変更される事故がかなり減る。 筆者は昔、ひとつの依頼文に「古い資料を整理して、重複を消して、命名規則も直して、READMEも整えて」と全部詰め込んで痛い目を見た。途中で返答を挟まなかったせいで、こちらの意図と違う削除候補まで広げられ、最後に確認してから戻す羽目になった。最初から二段三段に切っていれば済んだ話だ。 長い依頼の最初から作業を始めさせない。先に、見立てと手順を返させる。ここでの目的は、Claude Code に仕事をさせることではなく、こちらの意図を固定することだ。 たとえば、こんなふうに頼む。 ```text

長いメモを投げると、Claude Code は「読む側」ではなく「解釈する側」に回る。ここで雑に経緯や愚痴まで積むと、作業ノートはすぐ肥大化して、肝心の指示が埋もれる。進行メモは短く、作業ノートは決定事項だけ。これだけで手戻りがかなり減る。 Claude Code を使っていると、つい「背景も含めて全部書けば親切だろう」とやりたくなる。だが実際には、背景が長いほど判断がぶれる。特に、ファイル整理や文書作成のように“何を残し、何を捨てるか”が大事な作業では、余計な文脈がノイズになる。 作業中に持たせるメモは、あとで見返して意味が残るものだけに絞るのが正解だ。 たとえば、こんなふうに書く。 ```text このフォルダ内の重複候補を洗い出して、削除してよいものだけ一覧にしてください。 判断基準は次のとおりです。 同一内容の重複ファイル 明らかな一時ファイル 既に別名で保存済みの下書き 迷うものは削除しないで、保留として分けてください。 最後に、削除候補と保留を分けた一覧を出してください。 ``` これで十分だ。背景説明を足すなら、必要最小限でいい。 「3年前の移行で残った」「メール添付用に

Claude Code に雑に「このフォルダ見ていい感じにやって」と投げると、だいたい遠回りになる。 参照範囲を絞る、つまり材料の選別を先にやるだけで、出力の精度もスピードもかなり変わる。無関係なファイルまで読ませてコンテキストを浪費するより、使う材料と使わない材料を分けて渡したほうが、Claude Code は迷いにくい。 これは開発コードだけの話ではない。案件フォルダの整理、重複ファイルの洗い出し、議事録から要点だけ抜く作業でも同じだ。最初に「見るべきもの」と「見なくていいもの」を分ける。これが一番効く。 たとえば、リポジトリの中に `src/`、`docs/`、`node_modules/`、`dist/` があるとする。ここで全部まとめて渡すと、必要のない生成物や依存関係まで拾ってしまう。逆に、作業対象を `src/` と `docs/` に絞り、`node_modules/` と `dist/` は明示的に除外すれば、Claude Code は本筋に集中しやすい。ファイル整理でも同じで、`請求書` と `契約書` だけ見てほしいのに、昔の画像やキャッシュまで混ぜると、出力がぼ

途中で出たメモや断片を、そのまま成果物だと思って放置するとだいたい崩れる。Claude Code はそこを最後にまとめ直させるのがうまい。仕上げの再構成、最終整形、まとめ直し、呼び方はいろいろあるが、やることは単純だ。バラけた素材を、提出できる形に整える。 この使い方のいいところは、最初から完璧な指示を出さなくていい点にある。先に雑に集めさせて、最後に「この断片を一つの成果物に仕上げて」と頼む。人間の下書きでもよくやる流れだが、Claude Code はこの手の再構成がかなり得意だ。逆に、最初から完成形を一発で作らせようとすると、抜けや重複が出やすい。筆者も昔、仕様メモ、箇条書き、途中のコード断片を別々に投げて、最後の整形を省いたせいで、同じ説明が二重に入った文書をそのまま使いかけた。あれは地味にだるい。 たとえば、ファイル整理なら、散らかったメモやログを「削除候補」「残すもの」「後で確認するもの」にまとめ直させる。文書作成なら、章ごとに作った断片を、読み物として通る順番に並べ替えさせる。開発なら、試行錯誤のメモから、最終的な手順書や README に変換させる。ここで大事なのは、ただ

Claude Code で詰まる人の多くは、指示が雑だからではない。終わり方が曖昧だから詰まるのだ。 どこから始めるか、何が終わりか、終わったとみなす条件は何か。ここを先に固定しておかないと、Claude Code はそれなりに動くのに、最後に「で、これで完了なのか？」という微妙な空気が残る。人間のほうも迷うし、再依頼でコンテキストを無駄にする。地味だが、これが一番だるい。 この話をするときは、開始条件、完了条件、着地条件の3つを分けて考えるといい。入口は「何を見て作業を始めるか」、出口は「何をもって終わりにするか」、着地条件は「終わったあとにどの形で返すか」だ。名前は違っても、やることは同じである。 たとえば「README を直して」とだけ投げると、Claude Code は古い説明を直すのか、足りない章を足すのか、文体を整えるのか、判断に幅が出る。結果として、修正の方向がブレる。逆に、入口と出口を明示すると、作業が急に締まる。差分が小さくなるし、戻りも減る。筆者は最初、ここを甘く見て、文章修正を何度も往復した。悪いのは Claude Code ではなく、こっちの終点設計だった。 た

勢いで全部やらせると、たいてい後で面倒になる。Claude Code でも同じだ。 修正、整理、削除、要約。どれも便利だが、いきなり最後まで走らせると、思っていたものと違う場所まで触られることがある。だからこそ、承認ゲート、段階的確認、次工程への進行条件を置く。要するに「ここまでは進めていい、ここから先は止まれ」を先に決めるやり方だ。 この手の制御は、開発作業だけの話ではない。ファイル整理でも、ディスク削減でも、文書作成でも効く。Claude Code に「まず候補を出せ」「差分を見せろ」「削除前に止まれ」と言わせるだけで、手戻りがかなり減る。筆者は最初、全部まとめて任せて、あとから「そこは残したかった」と何度かやり直した。あの手戻りは地味にだるい。ゲートを置くと、その無駄が消える。 まず押さえるべきなのは、Claude Code に「最終実行」ではなく「確認用の下ごしらえ」をやらせることだ。たとえば不要ファイルの整理なら、いきなり削除させず、候補一覧を出させる。文書作成なら、いきなり全文を書かせず、章立てと論点を先に確認する。コード変更なら、いきなり大改修ではなく、影響範囲と変更方針

Claude Code に雑に「進めて」と投げると、案外まっすぐ突っ走る。で、いちばん痛いのは、前提が途中で壊れているのに走り続けることだ。前提崩れ時の停止、前提確認、暴走防止を最初から入れておくと、手戻りが目に見えて減る。 たとえばファイル整理でも文書作成でも同じで、最初に置いた条件が崩れた瞬間に止まらせるほうがいい。勝手に「たぶんこうだろう」で埋められると、あとで大量に直す羽目になる。筆者は、削除候補を洗い出すはずが、曖昧な指示のせいで想定外の範囲まで候補を広げられ、確認に余計な時間を食ったことがある。こういう事故は、最初の一文でかなり防げる。 効くのは、作業そのものより「止まり方」を先に決めることだ。Claude Code に渡す指示に、前提が崩れたら勝手に補完せず、必ず止まって確認する、と書く。これだけで、暴走しやすい場面の多くは抑えられる。 まずは、依頼文にこう入れる。 ```text 前提が崩れたら作業を止めてください。 不明点を推測で埋めず、前提確認をしてから続けてください。 変更前に、何が前提で、どこが崩れたのかを短く示してください。 ``` もう少し実務向けにするなら

Claude Code に雑に「やっといて」と投げると、速いぶんだけ派手に外す。特に危ないのは、何を止めればいいかを書かずに走らせるやり方だ。中断条件、失敗時の停止、ブレーキ条件を先に置く。これだけで、暴走した修正を途中で止めやすくなり、あとから手で戻す量がかなり減る。 この話は開発だけの話ではない。ファイル整理でも、文書作成でも、ディスク掃除でも同じだ。たとえば「重複ファイルっぽいものを探して」と頼んだとき、何を重複扱いにするか、どこまで削除していいか、どの条件で止めるかが曖昧だと、あとで痛い目を見る。Claude Code はこちらの意図を汲んでくれる場面もあるが、止めどころまで自動で空気を読む道具ではない。 だから最初に書くべきなのは、作業内容より先にブレーキだ。 たとえばこうだ。 ```text この作業では、次の条件に当てはまったら必ず止まって確認してほしい。 変更対象に .git 配下、node_modules、vendor、バックアップ、キャッシュが含まれるとき 既存ファイルの削除や上書きが発生するとき 影響範囲が 10 ファイルを超えるとき 依存関係やビルド設定を直す必

途中報告がうるさい。だから全部止める。これ、かなり雑なやり方だ。 Claude Code の進行中出力は、進捗報告、節目の報告、途中経過の出し方をきちんと決めないと、静かすぎて不安になるか、逆に細切れすぎて読めないかのどちらかになる。 大事なのは「黙らせる」か「節目だけ返させる」かを、作業の種類ごとに切り分けることだ。ファイル整理でも、文書作成でも、コード修正でも同じで、途中経過を全部見たい場面は少ない。見たいのは、止まったのか、方向がずれたのか、もうすぐ終わるのか、その三つだけである。 筆者も最初は、途中の考えごとまで全部見せてもらうほうが安心だと思っていた。だが実際は、出力が増えるほどコンテキストが汚れる。人間が「いま何してるんだっけ」と往復し始める。しかも、細かい進捗を逐一返させる頼み方は、成果物より実況にトークンを食う。地味にだるい。 Claude Code で粒度を決めるときは、まず仕事を二種類に分けるといい。ひとつは、黙って最後まで走らせる仕事。もうひとつは、節目だけ返させる仕事だ。 黙って走らせるのは、たとえば単純な移動、重複ファイルの洗い出し、既存文書の整形、指定フォル

大きい依頼を雑に投げて、「いい感じにやって」で済むと思っていると、だいたい途中で崩れる。Claude Code も人間と同じで、やる順番が曖昧だと、先に触るべきでない場所まで手を出して、あとで戻す羽目になる。 ここで言うのは、実行順の指定、手順の固定、処理順の話だ。要するに、「何を先にやり、何を後に回すか」を最初に並べるだけである。これを入れると、大きい変更でも迷いが減る。コンテキストの浪費も少ない。差分も妙に膨らみにくい。 筆者は最初、この順番を省いて何度も手戻りした。たとえば、古い文章ファイルを整理してから命名規則をそろえたいのに、いきなりリネームに入られて、あとで参照先がずれる。あるいは、不要ファイルを消す前に集計を始めてしまい、残すべきものまで候補に混ざる。順番を決めないと、作業そのものより、修正のほうが面倒になる。 Claude Code に頼むときは、最初に「全体の段取り」を明文化するのが効く。いきなり本作業を命じるより、先に分解させるほうが安定する。 たとえば、フォルダ整理ならこう書く。 ```text 次の順で進めてください。 1. まず対象フォルダを確認し、残すものと

ありがちなのは、「これまとめてやって」と一気に投げて、そのまま手戻りの山を作るやり方だ。Claude Code は雑に使うとかなり賢いが、指示の粒度が荒いと、途中で迷う。調査と実行の分離、段階依頼、確認フェーズを分けるだけで、その迷いはかなり減る。 特に、ファイル整理、ディスク削減、文書作成みたいな作業は、この分け方が効く。先に情報を集め、次に編集し、最後に確認する。順番を切るだけで、Claude Code の出力が安定するし、こちらも「今どの段階の話をしているのか」を見失いにくい。 筆者は最初、ひとつの依頼文に全部詰め込んでいた。たとえば「このフォルダを見て、重複を探して、不要なものを消して、最後にレポートして」と一息で頼む。すると、探索も削除も説明も同時に走るせいで、どこまで事実確認済みなのかが見えにくい。しかも diff が肥大化しやすい。あとから「その削除は本当に要るのか」と見返すのがだるい。そこで段階を分けたら、かなり扱いやすくなった。 やり方は単純だ。最初は調査だけ頼む。次に、調査結果をもとに編集や削除を頼む。最後に、変更後の確認を頼む。 たとえば、不要ファイルの整理ならこ

それ、たぶん最初にぼかしているせいで詰まる。 Claude Code に「いい感じにまとめて」と投げると、出力形式の指定、つまり成果物の型やフォーマット指定が曖昧なまま進みやすい。すると、文章がほしいのに箇条書きが返ってきたり、表がほしいのに長文の説明が混ざったりする。結果として、こちらが後で整形し直す羽目になる。 先に「Markdown で出す」「表で並べる」「見出し付きの箇条書きにする」と固定しておくと、手戻りが減る。これは開発の話だけではない。ファイル整理でも、議事録でも、契約書のたたき台でも同じだ。最初に成果物の形を決めるだけで、Claude Code が何を優先すべきかがかなりはっきりする。 たとえば、フォルダ内の書類を整理したいなら、こう言えばいい。 ```text このフォルダ内のファイルを整理して、結果を Markdown の表で返してください。 列は「ファイル名」「種類」「処理方針」「理由」にしてください。 本文の説明は最小限でいいです。 ``` これだけで、少なくとも「長い感想文」にはなりにくい。 逆に、あとでそのままメモに貼りたいなら、こう寄せる。 ```text

Claude Code に雑に「これやっといて」と投げると、だいたい一回で終わらない。むしろ、そこで作業の切り方を決めていないせいで、途中からコンテキストを食い、diff がふくらみ、最後に人間が手で戻す羽目になる。ここを外すと、便利なはずの道具が一番だるい道具になる。 この話で大事なのは、細かい命令文のテクニックではない。最初に「どこまでを Claude Code にやらせるか」「どの粒度で区切るか」を決めることだ。別名でいうなら、作業の切り方、進め方の設計、段取りである。ここが決まると、ファイル整理でも、ディスク削減でも、文書作成でも、頼み方が急に安定する。 筆者も最初はやった。ひと息で終わる気がして、長い依頼をそのまま投げた。結果は見事に散った。調査、修正、確認、微調整が全部ひとつの依頼に入って、Claude Code は便利に働くが、こちらは何を確認すればいいのか見失う。あとで見る diff はでかいし、どこから崩れたのか追いにくい。あれは気持ちが悪い。最初に切らないと、最後に手戻りで払うことになる。 やることは単純だ。最初に「一発で終わる依頼」を捨てる。代わりに、次の3つを分

「ターミナルは怖いから触らない」は、Claude Code を使うときだけはかなり損だ。 ただし、だからといって黒い画面の達人になる必要はない。覚えるのは本当に少しでいい。`cd` で場所を変える、`claude` を起動する、終わるときは `exit`。まずはこれだけで回る。 Claude Code は Anthropic の CLI コーディングエージェントだが、名前に反してエンジニア専用ではない。フォルダの中身を整理したい、散らかった文書をまとめたい、不要ファイルを減らしたい。そういう用途でもかなり使える。大事なのは、ターミナルを「操作する」ことではなく、Claude Code に「そのフォルダで何をしてほしいか」を短く伝えることだ。 最初にやることは単純だ。作業したいフォルダに移動して、Claude Code を起動する。 ```bash cd ~/Documents/案件A claude ``` ここで `cd` は「そのフォルダに入る」コマンド、`claude` は Claude Code を立ち上げるコマンドだ。フォルダ名のところは自分の環境に合わせればいい。たとえば書類

Claude Code が変な方向に進んだとき、いちばん危ないのは「少し直せば戻るだろう」と粘ることだ。そこから先は、直すための指示がさらに増えて、コンテキストも汚れて、結局もっと面倒になる。 この手の CLI コーディングエージェントは、雑に言えば「今ある作業状態」を読んで次を決める。だから、間違えたときは作業を抱えたまま修正会議を続けるより、いったん捨てて、まっさらな状態でやり直したほうが早い場面が多い。 筆者も最初はこれで何度かやらかした。小さな修正のつもりで指示を重ねたら、diff が妙に広がって、元の意図から外れた変更まで混ざる。あとから人間が見て「これはどこから来た？」となるやつだ。 なのでこの話では、Claude Code が迷走したときに何を捨て、何を残し、どうやって再出発するかを、実務寄りに整理する。 まず押さえるべきなのは、戻し方は1つではないという点だ。 すでにファイルを書き換えたあとなら Git で戻す。まだファイルを触っていないなら、セッションを切って、依頼文を作り直す。途中までの成果に価値がないなら、未練なく捨てる。ここを曖昧にすると、いつまでも半端な状態が

大きな作業を一気に投げると、だいたいロクなことにならない。Claude Code でも同じで、広い範囲をまとめて触らせるほど、意図しない変更が混ざるし、あとから差分を読むのも地獄になる。 ここでやるべきなのは、仕事を小さく切ることだ。Claude Code に「全部やって」で渡すのではなく、変更の境界を先に決める。そうすると、差分が読みやすくなるだけではない。途中で止めて確認しやすいし、手戻りしても被害が小さい。ファイル整理でも、文章修正でも、コード修正でも、この考え方が効く。 筆者は最初、ひとまとまりの依頼をそのまま投げて、関係ないファイルまで巻き込まれたことがある。修正点そのものは合っているのに、差分が太りすぎてレビューで疲れるやつだ。あれはかなりだるい。以後は「どこまでやるか」を先に決めてから頼むようにしている。 差分を小さくするコツは、作業を結果で分けるのではなく、工程で分けることだ。 たとえば、ひとつの大きな改修があったとする。いきなり完成版を作らせるより、こう分ける。 1. 既存の構成を確認する 2. 変更対象を絞る 3. 最小の修正を入れる 4. 差分を見て、余計な変更を

いきなり実行させてから「違う、そうじゃない」と止めるのは、だいたい一番高くつく。Claude Code のプランモードは、その手戻りを先に潰すための道具だ。作業を走らせる前に、方針・手順・危ない点を一回紙に出させる。これを挟むだけで、コンテキストの無駄食いも、雑な一括変更も、かなり減る。 プランモードは「何をするか」を先に固めるために使う。実行そのものを急がない。ここを逆にすると、便利な機能がただの遠回りになる。筆者も最初は、いきなり修正を走らせて、あとから「その前に依存関係を整理してほしかった」と気づいてやり直した。差分が肥大化すると、どこから崩れたのか追うのがだるい。だから先に方針確認だ。 使い方は単純で、最初に「変更はまだしないで、計画だけ出して」と頼む。たとえばコード修正なら、こんなふうに始める。 ```text この作業はまだ実行しないでください。 まず方針を確認したいです。 目的: 既存のログ出力を整理したい ただし振る舞いは変えすぎたくない やってほしいこと: 1. 関係するファイルを洗い出す 2. 変更方針を3案くらい出す 3. それぞれのメリット・リスクを書く 4.

「全部おまかせ」で回すと、だいたいどこかで余計なものまで触る。Claude Code の権限モードは、その事故をどこで止めるかを決める仕組みだ。ここを雑に扱うと、ファイル整理のつもりが思わぬ上書きになったり、コード修正のつもりが確認なしで広範囲の変更に進んだりする。 権限モードで見るべき本質は単純だ。Claude Code に何を自動で許し、何を必ず止めるかを先に決めることだ。自動承認は便利だが、便利さの裏には「止めどころを失う」危険がある。特に、削除・移動・上書き・外部コマンド実行のあたりは、最初から雑に広く許可しないほうがいい。 Claude Code には、作業を進める前に都度確認を挟むか、ある程度まとめて承認するか、といった権限の扱いがある。呼び方や細かな表示は環境で違うことがあるが、考え方は同じだ。普段の編集は流し、壊れやすい操作だけ人間が止める。これが基本線になる。 たとえば、文章作成やファイル整理で使うなら、こう考えるといい。下書き作成やリネーム案の提示はかなり自由に任せる。だが、実際の移動・削除・上書きは一段慎重にする。開発でも同じで、コードの提案や差分