Anthropic の CLI コーディングエージェント Claude Code の実用 TIPS をまとめた索引だ。
各 TIPS の本文は PaPoo の記事に置き、このページからリンクしている（随時追加・更新）。
この記事は各 TIPS の要点だけを並べた索引だ。手順・依頼文の例・注意点まで入った完全版は PaPoo の記事にある（原文＝カノニカル）。
Claude Code の導入・基本操作・最初の一歩
Claude Code を最初に動かすまで：インストールから初回の依頼まで
「入れたのに何を頼めばいいか分からない」で止まる人が多い。そこが一番もったいない。Claude Code は、起動した瞬間から小さく使い始めるのが正解だ。最初の一回で大仕事をさせる必要はない。むしろ、ファイルの中身を読ませて、整理や要約、簡単な修正を一つ通すところから始めると、使い方の勘所が一気につかめる。
https://papoo.work/doc/df659aeb3c7ebaef
Claude Code に何を頼めるか：得意なこと・苦手なことの線引き
Claude Code に何でも押しつけると、だいたい最後にしわ寄せが来る。雑に投げると、長い説明を読ませたわりに成果物が中途半端、しかも人間が後で直す羽目になる。そこを先に切り分けておくと、Claude Code はかなり使える道具になる。
https://papoo.work/doc/a262925c8e59c921
プロジェクトを開いて最初にやるべき3つの設定
最初に何も決めずに Claude Code を走らせると、だいたい雑に広がる。コンテキストは無駄に食うし、差分はでかくなるし、あとで「それじゃない」を言い直す羽目になる。あれは地味にだるい。
https://papoo.work/doc/55eb3e43b83794b2
Claude Code のセッションを上手に区切る：いつ /clear すべきか
長く雑に話し続けるほど賢くなる、なんて思っていると痛い目を見る。Claude Code は会話の文脈をちゃんと使うが、使い続ければ使い続けるほど、今やっている作業に不要な前提まで抱え込む。これがコンテキスト管理の話だ。 /clear は「会話を捨てるためのボタン」ではない。作業の単位を切り替えるための道具である。ここを外すと、指示はだんだん鈍るし、差分はでかくなるし、直したい場所と違う場所を触り始める。
https://papoo.work/doc/80eb7adbfa5f0247
ファイルを丸ごと貼らずに済ませる：Claude Code に探させる頼み方
「このファイル全部読んで」。その頼み方、だいたい雑だ。Claude Code に丸ごと貼る前に、まず探させればいい。これだけでコンテキストの無駄食いが減るし、長い設定ファイルや複数の文書を相手にするときの手戻りもかなり減る。
https://papoo.work/doc/b898c38e4c2017d0
Claude Code の権限モードを理解する：自動承認はどこまで許すか
「自動承認にしておけば全部ラク」みたいな雑な使い方をすると、だいたいどこかで痛い目を見る。Claude Code は便利だが、便利さの芯にあるのは“どこまで勝手にやってよいか”の線引きだ。ここを曖昧にしたまま走らせると、ファイルを思った以上に触られたり、確認待ちで手が止まったりする。
https://papoo.work/doc/540918ab2fea474c
プランモードで「やる前に方針を確認」する使い方
勢いで走らせると、だいたいあとで直す羽目になる。Claude Code でもそこは同じで、いきなり実行させるより、先に方針だけ確認させたほうがずっと事故が少ない。
https://papoo.work/doc/616c7bf6cd99ac3f
差分を小さく保つ：大きな変更を安全に進めるための区切り方
一気に全部やろうとすると、だいたい雑になる。Claude Code でも同じで、でかい変更をひと塊で投げると、途中で文脈があふれて、直したい箇所まで巻き込んで壊しやすい。差分を小さく保つコツは、気合いではなく区切り方だ。
https://papoo.work/doc/117853b495ea1b05
Claude Code が間違えたときの戻し方：作業を捨ててやり直す
やりがちなのは、Claude Code が変な方向に進んだのに、そのまま修正させ続けることだ。これ、たいてい泥沼になる。少し直したつもりが別のファイルまで触られ、diff が膨らみ、どこから壊れたのか分からなくなる。そんなときは、粘るより一度捨てたほうが早い。
https://papoo.work/doc/9fee72fce1b24dfd
ターミナルが苦手でも使える：Claude Code の最小限の操作だけ覚える
Claude Code は、ターミナルの玄人向けツールに見えて、実際は「最小限だけ覚えて雑に使う」ほうが向いている。ここを勘違いして、最初から bash を全部理解しようとして止まる人が多い。そんな気合はいらない。必要なのは、起動する、依頼を書く、承認する、終わる。この4つだけだ。
https://papoo.work/doc/85ecba97142be165
依頼の出し方・伝え方で品質が変わる TIPS
曖昧な依頼をやめる：Claude Code に「何を・どこまで」を渡すコツ
「いい感じにやって」で済むと思っていると、だいたい遠回りになる。Claude Code も例外ではない。 雑に投げると、広く見に行きすぎる。触ってほしい範囲がぼやけるから、無駄にファイルを読み、無駄に大きな差分を作り、あとで「そこじゃない」を直す羽目になる。筆者も最初はこれで何度か手戻りした。頼み方が曖昧だと、エージェントは親切に広く動く。親切さが、そのままコンテキストの浪費になるわけだ。
https://papoo.work/doc/7ee8826295233a8f
ゴールと制約を先に伝える：手戻りを減らす依頼テンプレ
「とりあえず直して」でうまくいくと思っていると、だいたい手戻りする。Claude Code は空気を読んで全部やってくれる便利屋ではない。何を終点にしたいのか、何を触ってよくて何を触るな、ここを先に渡したほうが速い。
https://papoo.work/doc/edb2a4e40b75bdaf
「まず調べて、次に直して」と段階で頼むと精度が上がる理由
雑に「これ直して」で投げると、Claude Code はだいたい手広く動きすぎる。調べるべきことと、直すべきことが頭の中で混ざるからだ。 先に調べさせ、あとで直させる。この順番に分けるだけで、無駄な修正、見当違いの変更、差分の膨張がかなり減る。ファイル整理でも文書作成でも同じで、いきなり“完成形”を頼むより、まず現状を見せたほうが話が早い。
https://papoo.work/doc/e86b2c7fb62d6767
既存コードの作法に合わせさせる：スタイルを真似させる頼み方
新しいコードをいじらせる前に、まず既存コードの空気を読ませろ。ここを雑にやると、動くけど場違いな差分が増える。名前の付け方も、関数の切り方も、コメントの濃さも、ぜんぶちぐはぐになる。Claude Code でも同じで、「このリポジトリの作法に合わせて」と丸投げするより、見本を渡して真似させたほうがずっと安定する。
https://papoo.work/doc/ff29391d27bb3904
やってほしくないことを明示する：禁止事項の伝え方
「やってほしいこと」だけ書いて、やってほしくないことを放置する。これ、Claude Code への依頼でかなり危ない。余計な編集、勝手な要約、触ってほしくないファイルの改変まで一気に起きる。禁止事項は、気を使ってぼかすより、先に切っておいたほうが早い。
https://papoo.work/doc/a1afddafe9340de7
長い作業を ToDo に分解させてから進めてもらう
長い仕事をそのまま投げると、Claude Code はだいたい雑に走る。で、あとから「それ先に必要だったのはこっちだった」と気づいて手戻りする。ここを避けるなら、最初にやることは単純だ。いきなり本作業に入らせず、先にToDoへ割らせるのである。 この一手で、作業の抜け、順番違い、コンテキストの無駄遣いがかなり減る。ファイル整理でも、ディスク掃除でも、文書作成でも効く。長い依頼ほど効き目が大きい。
https://papoo.work/doc/0b1c8b9734c47f81
例を 1 つ見せる：少ない指示で意図を伝える few-shot 的な頼み方
「ちゃんと考えて」とだけ投げて、思った通りになるはずがない。Claude Code も同じで、雑な依頼は雑な結果を呼ぶ。ここで効くのが、長々と説明するより、たった 1 つの例を見せるやり方だ。
https://papoo.work/doc/84601d75d1948ce1
「説明して」と「直して」を混ぜない：依頼の粒度を揃える
「これ、何をしてほしいのか曖昧なまま投げているな」と思ったら、だいたい当たっている。Claude Code への依頼で一番もったいないのは、説明と修正を一度に混ぜることだ。読み解きと編集は別作業で、同じ呼びかけに押し込むと、返ってくる結果が中途半端になる。
https://papoo.work/doc/b7bc95c2e762f329
git・コードレビュー・リファクタリングの運用
Claude Code にコミットメッセージを書かせる：粒度と作法を揃える
コミットメッセージを「それっぽく一行で」済ませると、あとで自分が困る。Claude Code に任せるなら、そこを雑にしないほうがいい。粒度がバラついたメッセージは、履歴を読めなくするだけでなく、変更の単位まで崩す。逆に、作法を先に揃えておくと、コミットはただの作業ログではなく、あとから効くメモになる。
https://papoo.work/doc/4491bd91f48d88d9
変更内容をレビューしてもらう：自分の差分にツッコミを入れさせる
差分をそのまま見せて「レビューして」と投げるだけでは甘い。だいたい見落とされる。Claude Code にやらせたいのは、単なる読み上げではなく、変更の穴を突かせることだ。
https://papoo.work/doc/255830b7fec4153c
安全にリファクタする：テストを足してから直す段取り
テストもないのに手を入れて、あとで「何が壊れたか分からない」と泣く。これ、かなりありがちな事故だ。Claude Code を使うときも同じで、いきなり大工事を頼むより、先に“壊してはいけない形”をテストで囲ってから直したほうが圧倒的に安全になる。
https://papoo.work/doc/eb5c3b25351bd041
プルリクエストの説明文を Claude Code に下書きさせる
プルリクの説明文を、毎回ゼロからひねり出しているなら、その時間はかなりもったいない。差分は読めるのに、説明だけが薄っぺらい。あれはだいたい、頭の中にある変更点をそのまま文章化していないのが原因だ。
https://papoo.work/doc/dffb9e3224022a20
コンフリクトの解消を手伝ってもらうときの渡し方
コンフリクトを見つけた瞬間に、雑に「直しといて」と投げるとだいたい余計にこじれる。Claude Code もそこは人間と同じで、何を残すべきか、どこまで触っていいかが曖昧だと、無難そうな修正を広げてしまう。結果、差分が太る。あとで自分が読むと、何を直したのか分からない。これが一番だるい。
https://papoo.work/doc/51f7abb6c9cbaa76
「なぜこのコードがあるのか」を git 履歴から説明させる
そのコード、ただ動くだけで満足していないか。いちばん厄介なのは「何のために残っているか誰も覚えていない行」だ。消すと壊れそうで怖い、残すと読みづらい。こういうときに Claude Code に git 履歴を当たらせると、ただの謎コードが「いつ、誰が、どの意図で入れたか」に変わる。意味が見えるだけで、保守のストレスはかなり減る。
https://papoo.work/doc/51e0c451964e5d4a
大規模な置換を一気にやらない：段階コミットで巻き戻せるようにする
置換を1回で全部終わらせようとして、あとで何が起きたか分からなくなる。これ、かなりありがちな失敗だ。Claude Code に大量の修正を投げると、ファイルのあちこちを同時に触れて、差分がでかくなり、どこで壊れたのか追いにくくなる。巻き戻したいのに、戻す単位すら見えない。そこで効くのが段階コミットだ。小さく直して、小さく確かめて、小さくコミットする。これだけで手戻りの痛さがかなり減る。
https://papoo.work/doc/4aebdab9222d32cb
CLAUDE.md・設定・権限・hooks・サブエージェントのカスタマイズ
CLAUDE.md にプロジェクトの作法を書いて毎回の説明を省く
毎回同じことを口で説明しているなら、その時点でもう負けである。Claude Code に仕事を頼むたびに「このフォルダは何のためのものか」「どのファイルを触っていいか」「何を勝手に変えないでほしいか」を打ち直していると、コンテキストも時間もじわじわ溶ける。そこで使うのが CLAUDE.md だ。別名でプロジェクトメモリとも呼べる。要するに、プロジェクト固有の作法を置いておくメモである。
https://papoo.work/doc/2a7780462f0c05a0
CLAUDE.md に書くと効くこと・書いても効きにくいこと
CLAUDE.md を「雑に長文で埋める箱」だと思っていると、だいたい損をする。効くのは、毎回ブレると困る前提だけだ。逆に、巨大な社内規約や操作マニュアルを丸ごと押し込んでも、Claude Code はそこを丁寧に読み上げる執事にはならない。
https://papoo.work/doc/22544c3267ecd611
よく使う頼みごとをスラッシュコマンド（カスタムコマンド）にする
毎回同じお願いをベタ打ちしているなら、そこがいちばんムダだ。Claude Code は「よく使う頼みごと」をスラッシュコマンドに落としておくと、指示の抜け漏れが減るし、毎回の入力もかなり軽くなる。
https://papoo.work/doc/750373545a29d87c
権限の許可リストを整えて確認ダイアログを減らす
毎回「これ許可していい？」を踏ませてくるなら、だいたい整理の仕方が悪い。Claude Code は便利だが、むやみに広い権限を渡すより、よく使う場所だけを先に許可リストへ入れておいたほうが、手が止まらない。
https://papoo.work/doc/937927cd5c3ec76a
hooks で「保存したら自動でフォーマット」を仕込む
保存のたびにフォーマットを走らせたいのに、毎回「あとで Claude Code に整えて」と頼んでいるなら、かなり遠回りだ。フック、つまり hooks を使えば、その面倒な一手を先回りできる。
https://papoo.work/doc/7c90877e0657648c
サブエージェントに調べ物を任せて本流の文脈を汚さない
調べ物を全部ひとつの会話に押し込むと、すぐに文脈が死ぬ。これ、かなりありがちな失敗だ。Claude Code にはサブエージェント、英語で subagent と呼ばれる仕組みがあり、重い調査や周辺確認を分離して、本題の流れをきれいに保てる。うまく使うと、メインの作業は設計や編集に集中できるし、調べ物の途中で話が散らからない。ファイル整理でも、文書作成でも、コード修正でも効く。
https://papoo.work/doc/c4e921de29e4d445
個人設定とプロジェクト設定を使い分ける：settings.json の置き場所
設定ファイルを1か所にまとめれば楽だと思っていると、だいたいあとで詰まる。Claude Code の settings.json も同じで、全部を個人設定に押し込むと、別プロジェクトで余計な癖が出る。逆にプロジェクト側に何でも書くと、今度は毎回同じ説明を繰り返す羽目になる。
https://papoo.work/doc/cad2004d4f05af32
MCP・外部ツール連携
MCP とは何か：Claude Code に外部ツールをつなぐ仕組みを噛み砕く
「Claude Code に何でもやらせたい」と言いながら、結局は会話欄に手作業でコピペしている。そこ、かなりもったいない。 MCP はその手間を減らすための仕組みだ。正式には Model Context Protocol。Claude Code に外部ツールや外部データをつなぎ、必要なときに呼び出せるようにする共通の口だと思えばいい。
https://papoo.work/doc/a6e0a0e0c6cae9c0
MCP サーバを 1 つ追加してみる：最初の連携の始め方
最初の失敗はだいたい決まっている。いきなり何個も MCP サーバを足して、どれが何をしているのか分からなくなるやつだ。これをやると、Claude Code の便利さより先に、設定の面倒くささだけが残る。まずは 1 つだけ足す。これがいちばん速い。
https://papoo.work/doc/bd5f7425e8981efa
どの MCP を入れるべきか：入れすぎない選び方
MCP は、入れれば入れるほど便利になるものではない。むしろ逆で、雑に増やすと Claude Code の中身が散らかって、何を頼むにも余計な確認が増える。ここを外すと、最初は賑やかでも、そのうち「結局どれを使えばいいんだ」となる。
https://papoo.work/doc/6204881096bc81eb
Claude Code から外部 API やデータベースを安全に触らせる勘所
雑に「API叩いておいて」「DB見ておいて」と投げると、Claude Code はだいたい困る。困るだけならまだいいが、権限が広すぎると余計な変更まで手を出す。ここでやるべきことは単純で、触れる範囲を狭く切り、危ない操作は人間の確認を挟み、あとで検証できる形にしておくことだ。
https://papoo.work/doc/4176585d6a6bc770
デバッグ・テスト・自動化のワークフロー
エラーログを貼って原因を切り分けてもらう頼み方
ログを貼らずに「動きません」だけ投げるのは、ほぼ自爆だ。Claude Code に原因切り分けを頼むなら、症状の説明より先に、エラーログをそのまま渡したほうが速い。これは開発作業でも、ファイル整理でも、書類の自動生成でも同じである。曖昧な依頼は、余計なやり取りを増やしてコンテキストを食い、最後に「それ、最初に出してくれれば済んだのに」になる。
https://papoo.work/doc/bf515c6b22fad9bb
失敗するテストを先に書いてもらい、それを通す形で直す
「直してから確認する」は、だいたい遠回りだ。Claude Code にも同じで、まず壊れるテストを作らせてから、その赤を消す形でコードを直すほうが、手戻りが少ない。
https://papoo.work/doc/87d3821bd7cfa5ed
「再現手順」を渡してバグを再現させてから直してもらう
「壊れてるから直して」で投げると、だいたい遠回りになる。Claude Code みたいなCLIエージェントは、雰囲気で当てるより、再現できる条件を渡したほうがずっと強い。
https://papoo.work/doc/3b80972097b3b992
定型作業をスクリプト化させて手作業を消す
毎回同じ名前でフォルダを掘って、同じ文言で文書を整えて、同じゴミを消しているなら、もう人間がやる仕事ではない。そこを Claude Code に渡すと、作業そのものよりも「抜け漏れを気にしている時間」がごっそり減る。
https://papoo.work/doc/8fe0b31710132eae
Claude Code に自分の作業を検証させる：思い込みを潰す確認の頼み方
人は、自分で直したコードや片づけたファイルをいちばん雑に見てしまう。見たつもりで見落とすし、「たぶん合ってる」で突っ走る。Claude Code を使う場面でも、ここが一番まずい。
https://papoo.work/doc/d2cf52a6093369e6
長時間かかる処理を Claude Code に任せて結果だけ受け取る
それ、途中で画面を見張っているからだるくなるのである。長時間かかる処理は、手を止めて待つより、Claude Code に投げて終わった結果だけ拾う形にしたほうがいい。ファイルの棚卸し、重複の洗い出し、ログの整理、文章の下書き、リポジトリ内の一括確認みたいな作業は、特に相性がいい。
https://papoo.work/doc/890e2ef0ec3a984e
プログラマ以外でも使える活用法（ファイル整理・文書作成・資料整理）
重複ファイルと不要キャッシュを洗い出してディスクを大幅に空けた話
ディスクが足りないとき、多くの人はまず「大きいフォルダ」を探す。だが、実際に効くのはそこじゃない。見落としやすい重複ファイルと、放置された不要キャッシュだ。ここを片付けると、ディスク整理とストレージ削減の効き方が一段違う。
https://papoo.work/doc/2e5c60bf5c973b0c
弁護士が案件ごとにフォルダを掘り、関連書類から書面の下書きを作る
案件フォルダが散らかっていると、書面づくりはただの手作業地獄になる。士業でも書類整理でも同じで、探す時間が長いほど、肝心の中身を考える時間が削れる。 Claude Code はコードを書く道具だと思われがちだが、実は「フォルダを掘って、関連ファイルを拾い、下書きを作る」作業にかなり向いている。弁護士の案件管理みたいな使い方でも効く。
https://papoo.work/doc/89081313468ccb38
大量のファイルを内容で分類してフォルダに振り分けてもらう
ファイル名だけ見て振り分けようとするのは、だいたい雑に終わる。final_2 とか 新規 とか scan0007 みたいな地獄を、名前だけで救えるわけがない。こういうときは、Claude Code に「中身を読ませて分類させる」ほうが早い。
https://papoo.work/doc/53ea925fac7489bb
PDF や議事録の山から必要な情報だけ抜き出して表にまとめる
PDF を全部読んでから表を作る、あれは一番だるい。しかも大抵、読み落としが出る。Claude Code の出番はそこだ。ファイルの山を丸ごと相手にして、必要な項目だけ拾い、CSV か Markdown の表に整える。人力で目を通す仕事を、最初のふるい分けだけでもかなり減らせる。
https://papoo.work/doc/28c88b7995a9a3ee
フォルダの中身を棚卸しして「何が入っているか」を一覧化する
フォルダを見て「何が入っているか」を口で説明できないなら、だいたい整理は崩れている。ファイル名を眺めるだけでは足りないし、サブフォルダが深いと、人間の頭ではすぐ抜け落ちる。Claude Code は、その見落としを雑に埋める道具としてかなり使える。 やることは単純だ。指定したフォルダの中身を洗い出し、階層ごとに一覧にする。必要なら、種類ごとに分ける。重複っぽいものや、でかいファイルが混じっていないかまで見える。
https://papoo.work/doc/9ca3ab02a6f98e8e
非エンジニアのための最小ターミナル入門：Claude Code に任せる前提で
「ターミナルはエンジニアの武器」みたいな顔をしているが、Claude Code を使うなら、非エンジニアこそ最低限だけ覚えておいたほうが速い。全部を理解する必要はない。だが、入口と出口を知らないまま突っ込むと、ファイルの置き場所が分からず詰む。そこで止まるのはもったいない。
https://papoo.work/doc/fe4f0a58d868221d
写真や書類のファイル名を内容に沿って一括リネームする
「IMG_4839.jpg」を100枚並べて、あとで中身を見てから直そうとする。あれ、だいたい破綻する。写真でも書類でも、名前が意味を持っていないと、探すだけで時間を食う。Claude Code は、その手の雑な山を一気に片づけるのに向いている。
https://papoo.work/doc/6bfb9549df7010f7
Claude Code に大きめの依頼を投げるとき、最初の切り分けで手戻りを減らし、実行の粒度を揃え、途中で迷子にさせないための TIPS をまとめるクラスタ。曖昧な一発依頼ではなく、調査・計画・実行・確認をどう区切るかに焦点を当てる。既存の「曖昧な依頼」「段階で頼む」「ToDo に分解」「説明と修正を混ぜない」とはずらし、ここでは“作業の進め方そのもの”に寄せる。
一発で終わる依頼を捨てる：最初に作業の切り方を決める
Claude Code に雑に「これやっといて」と投げると、だいたい一回で終わらない。むしろ、そこで作業の切り方を決めていないせいで、途中からコンテキストを食い、diff がふくらみ、最後に人間が手で戻す羽目になる。ここを外すと、便利なはずの道具が一番だるい道具になる。
https://papoo.work/doc/215a4f8571858420
まず成果物の形を固定する：Markdown なのか表なのかを先に言う
それ、たぶん最初にぼかしているせいで詰まる。 Claude Code に「いい感じにまとめて」と投げると、出力形式の指定、つまり成果物の型やフォーマット指定が曖昧なまま進みやすい。すると、文章がほしいのに箇条書きが返ってきたり、表がほしいのに長文の説明が混ざったりする。結果として、こちらが後で整形し直す羽目になる。
https://papoo.work/doc/e1b92a4755a87863
調査・編集・確認を分けて頼むと、途中の迷いが消える
ありがちなのは、「これまとめてやって」と一気に投げて、そのまま手戻りの山を作るやり方だ。Claude Code は雑に使うとかなり賢いが、指示の粒度が荒いと、途中で迷う。調査と実行の分離、段階依頼、確認フェーズを分けるだけで、その迷いはかなり減る。
https://papoo.work/doc/d2dca9eea62ec265
大きい変更は「この順でやる」と先に並べる
大きい依頼を雑に投げて、「いい感じにやって」で済むと思っていると、だいたい途中で崩れる。Claude Code も人間と同じで、やる順番が曖昧だと、先に触るべきでない場所まで手を出して、あとで戻す羽目になる。
https://papoo.work/doc/61acfbac50137d28
途中報告の粒度を決める：黙らせるか、節目だけ返させるか
途中報告がうるさい。だから全部止める。これ、かなり雑なやり方だ。 Claude Code の進行中出力は、進捗報告、節目の報告、途中経過の出し方をきちんと決めないと、静かすぎて不安になるか、逆に細切れすぎて読めないかのどちらかになる。
https://papoo.work/doc/9e0286859fd8d9ae
止めてほしい条件を先に書く：安全なブレーキのかけ方
Claude Code に雑に「やっといて」と投げると、速いぶんだけ派手に外す。特に危ないのは、何を止めればいいかを書かずに走らせるやり方だ。中断条件、失敗時の停止、ブレーキ条件を先に置く。これだけで、暴走した修正を途中で止めやすくなり、あとから手で戻す量がかなり減る。
https://papoo.work/doc/4f04b6360016314d
前提が崩れたら止めるよう指示して、暴走を防ぐ
Claude Code に雑に「進めて」と投げると、案外まっすぐ突っ走る。で、いちばん痛いのは、前提が途中で壊れているのに走り続けることだ。前提崩れ時の停止、前提確認、暴走防止を最初から入れておくと、手戻りが目に見えて減る。
https://papoo.work/doc/84c0a3950c27315e
確認してから次へ進める：Claude Code にゲートを置く
勢いで全部やらせると、たいてい後で面倒になる。Claude Code でも同じだ。 修正、整理、削除、要約。どれも便利だが、いきなり最後まで走らせると、思っていたものと違う場所まで触られることがある。だからこそ、承認ゲート、段階的確認、次工程への進行条件を置く。要するに「ここまでは進めていい、ここから先は止まれ」を先に決めるやり方だ。
https://papoo.work/doc/c5e00a7f54193131
作業の入口と出口を明示して、終わり方を迷わせない
Claude Code で詰まる人の多くは、指示が雑だからではない。終わり方が曖昧だから詰まるのだ。 どこから始めるか、何が終わりか、終わったとみなす条件は何か。ここを先に固定しておかないと、Claude Code はそれなりに動くのに、最後に「で、これで完了なのか？」という微妙な空気が残る。人間のほうも迷うし、再依頼でコンテキストを無駄にする。地味だが、これが一番だるい。
https://papoo.work/doc/7ed3010b0e2d322c
最後にまとめ直させる：途中の断片を成果物に整える
途中で出たメモや断片を、そのまま成果物だと思って放置するとだいたい崩れる。Claude Code はそこを最後にまとめ直させるのがうまい。仕上げの再構成、最終整形、まとめ直し、呼び方はいろいろあるが、やることは単純だ。バラけた素材を、提出できる形に整える。
https://papoo.work/doc/2e0437c51826777a
Claude Code に長い作業をやらせるとき、コンテキストの浪費を抑えながら、調査・編集・確認・要約を小さく回すための実践 TIPS をまとめるクラスタである。大規模変更や長文作成、フォルダ整理でも効く。
最初に「使う材料」と「使わない材料」を分けて渡す
Claude Code に雑に「このフォルダ見ていい感じにやって」と投げると、だいたい遠回りになる。 参照範囲を絞る、つまり材料の選別を先にやるだけで、出力の精度もスピードもかなり変わる。無関係なファイルまで読ませてコンテキストを浪費するより、使う材料と使わない材料を分けて渡したほうが、Claude Code は迷いにくい。
https://papoo.work/doc/26f7235f4a9a281f
作業中に持たせるメモは短く、決定事項だけにする
長いメモを投げると、Claude Code は「読む側」ではなく「解釈する側」に回る。ここで雑に経緯や愚痴まで積むと、作業ノートはすぐ肥大化して、肝心の指示が埋もれる。進行メモは短く、作業ノートは決定事項だけ。これだけで手戻りがかなり減る。
https://papoo.work/doc/d011254f4e3692f7
長い依頼は途中で区切って、返答を挟ませる
長い依頼を一息で投げて、そのまま全部を抱えさせる。これ、いちばん雑に見えて、いちばん手戻りが増えるやり方だ。Claude Code は長文も受けるが、だからといって一発で正解を取りにいく道具ではない。むしろ、段階実行や途中確認を挟んだほうが、速いし、壊れにくい。
https://papoo.work/doc/f2b2d657d88efc77
一度にやることを減らして、見失いを防ぐ
雑にまとめて一気に投げると、Claude Code はわりと簡単に見失う。人間のほうもだが、出力のほうもだ。 ここで効くのが、単一タスク化、あるいは集中実行という考え方である。やることを一度に1個に絞る。すると、指示が短くなり、差分が小さくなり、途中で何を直しているのか分からなくなる事故が減る。
https://papoo.work/doc/5bfee5302e69da9f
調べた内容をその場で要約させて、次の指示に渡す
調べものをしたあとに、そのまま長文を抱えて次の指示を投げると、Claude Code のコンテキストはあっさり太る。ここで雑に進めると、必要な事実よりも、読み込んだメモやログのほうが邪魔になる。だから一度、中間要約で調査の圧縮を挟む。これだけで、次の一手がかなり安定する。
https://papoo.work/doc/0a4c60df74a7fb2b
長文の下書きは章ごとに作らせる
長文を一気に書かせて、あとで整えればいい——このやり方、たいてい途中で崩れる。Claude Code は便利だが、雑に丸投げすると、前半で決めた言い回しが後半で勝手にズレたり、同じ話を二度書いたりする。長い文章ほど、分割執筆、章立て執筆に切り替えたほうがいい。
https://papoo.work/doc/3510c6c1fb90642e
大量のファイル整理は、まず分類ルールだけ決める
ファイル整理で一番まずいのは、いきなり中身を見始めることだ。そこからやると、分類がその場の気分でぶれて、あとで自分でも意味が分からなくなる。Claude Code を使うなら、先に決めるのは「何をどう分けるか」だけでいい。分類基準を先に決める、仕分けルールを固定する、ここを飛ばすと、整理はほぼ確実にぐだる。
https://papoo.work/doc/3232846d1a664513
途中で方針が変わったら、古い前提を捨てて言い直す
途中で話が変わったのに、前の指示を引きずったまま走る。これが一番だるい。Claude Code でも同じで、最初の前提のまま作業を続けさせると、見当違いの差分や、やたら長い説明を生む。ここで効くのが前提更新、つまり指示のリセットだ。
https://papoo.work/doc/2b6d7418a1eb92b2
返答が長すぎるときは、出力の形を先に固定する
Claude Code に「要点だけ頼む」と言っても、返ってくる文章が妙に長い。あれはツールが悪いというより、こちらが出力の型を渡していないことが多い。出力制約とか成果物の型を先に決めておくと、返答の長さはかなり扱いやすくなる。
https://papoo.work/doc/4b0fb07ce0ba49f8
最後に全体を短くまとめ直して、引き継げる形にする
長く作業したあとに、ただ「終わりました」で投げるのは雑だ。Claude Code でも同じで、最後に全体を短くまとめ直しておかないと、あとで自分が困る。引き継ぎメモ、あるいは仕上げ要約を残しておくと、何を変えたのか、何が未完了なのか、次にどこから触ればいいのかが一発で見える。
https://papoo.work/doc/37b0a6c9aea8adb4
Claude Code の作業ログや履歴を起点に、何が起きたかを後追いで確認し、失敗の再発を防ぐための読み解き方をまとめるクラスタ。会話の流れだけでなく、記録される情報をどう見ればよいか、どこまで信頼してよいか、どう次の指示に活かすかに焦点を当てる。調査・修正・検証の各局面で「あとから追える状態」を作るのが主題で、非エンジニアのファイル整理用途にもつながる。
作業ログを見返して、Claude Code がどこで迷ったかを特定する
Claude Code に雑に任せて「なんか遅い」「なんか遠回りした」で終わらせるのは、かなりもったいない。迷いはだいたい作業ログに出る。会話ログ、作業履歴を見返せば、どこで前提を取り違えたか、どの指示が弱かったか、どこで無駄な探索を始めたかが見えてくる。
https://papoo.work/doc/78f327c7175639d2
失敗した依頼を会話の流れから洗い出して、次の指示に直す
雑に投げた指示がそのまま通ると思っているなら、そこが一番あぶない。Claude Code は空気を読んで勝手に名案をひねり出す道具ではないので、失敗した依頼はその場で拾って、次の指示に直すほうがずっと強い。ここで使うのが、手戻り分析とやり直しポイントの洗い出しだ。会話のどこでズレたかを見つけて、同じ事故をもう一回起こさない形に変える。
https://papoo.work/doc/619899a6de9c83d6
途中で何を判断したかを記録させて、あとから説明できる形にする
Claude Code に仕事を投げておいて、あとから「なんでそうしたんだっけ」と困る人は多い。 出力がそれっぽく終わると満足しがちだが、実務で痛いのはそこではない。途中で何を見て、何を捨てて、何を採ったかが残っていないことだ。これがないと、数日後に見返した瞬間に意味が死ぬ。
https://papoo.work/doc/e387bd15df1c76b1
長い作業の節目ごとに要点を残して、後追いの確認を楽にする
長い作業を丸ごと一気にClaude Codeへ投げて、そのまま最後まで追いかけようとする。これ、かなり詰まる。途中で何を決めたかが消えるから、後から「なぜこの構成にしたんだっけ」「どのファイルを触ったんだっけ」が毎回発生する。
https://papoo.work/doc/2d97fb6088da5738
貼ったログと実際の変更を照合して、見落としを潰す
貼ったログをそのまま信じて進むと、あとで「そこ、直ってないじゃん」で止まる。いちばんだるいのは、直したつもりの差分と、実際に変わったファイルがズレていることだ。
https://papoo.work/doc/cd58b3ad9fd82cd5
Claude Code の出力と自分の期待がずれた場所を読む
Claude Code でいちばん無駄が出るのは、ちゃんと動いているのに「なんか違う」とだけ感じて、そこを言語化できないときだ。 期待との差分、つまり出力のズレを読めないと、同じ依頼を少しずつ言い換えては手戻りする。これが地味にだるい。しかも、ズレている場所は毎回同じではない。要件の理解が浅いのか、対象ファイルの見方が違うのか、やり方は合っているのに粒度だけ外したのか。
https://papoo.work/doc/76630239787a58a2
再現できる失敗と、たまたま起きた失敗を分けて見る
同じ失敗に見えても、直すべき場所はぜんぜん違う。そこを混ぜると、Claude Code に何を頼むべきかが毎回ぼやけて、手戻りだけが増える。 ここで分けたいのは、再現できる失敗と、たまたま起きた失敗だ。言い換えると、再現性の確認と偶発エラーの切り分けである。
https://papoo.work/doc/012a8554ebe8284d
調査だけのやり取りを残して、修正作業に混ぜない
これを混ぜる人は、だいたいあとで自分の首を絞める。 調べた結果のメモと、実際の修正を同じ流れで雑にやると、何を根拠に直したのか分からなくなるし、Claude Code のコンテキストも無駄に食う。調査記録を残して、修正分離する。たったそれだけで、後から見返したときの説明力がまるで違う。
https://papoo.work/doc/676cf08fbebf89c9
作業記録をもとに、次回の依頼テンプレを作り直す
依頼テンプレを「一回作って終わり」にしていると、だいたい次の依頼でまた同じ手戻りを食う。そこを放置して、毎回ゼロから雑に投げ直すのはかなりもったいない。Claude Code は一発で完璧な代物を出す道具ではないが、作業記録を見ながら依頼テンプレ改善を回すと、次回の指示精度が目に見えて上がる。再発防止メモとしても効く。
https://papoo.work/doc/decd9f31a8919009
非エンジニアの整理作業で、処理の前後を比較して確認する
整理作業でいちばん危ないのは、きれいになった気がして終わることだ。削ったはずのファイルが残っていたり、直したつもりの文書が別の場所で壊れていたりする。こういうときに効くのが、整理前後比較、棚卸し確認だ。Claude Code に処理の前と後を見比べさせると、何を減らしたのか、どこが変わったのか、逆に何が残っているのかを落ち着いて追える。
https://papoo.work/doc/ce43e952bef8f768
Claude Code に作業を頼むとき、何を作らせるかだけでなく、どう返させるかを先に固定すると、長いやり取りでもブレにくくなる。調査結果の要約、表や箇条書きへの整形、途中報告の粒度、最後の引き継ぎ用まとめまでを一つの流れとして扱うクラスタである。非エンジニアの整理作業にもそのまま効く。
最初に出力の形を固定する：Markdown か表かを先に決める
ここを曖昧にしたまま投げると、Claude Code はだいたい素直に広がる。つまり、読みやすい文章ではなく、あとで直しにくい長文や、表にしたかったのに段落で返ってくるあの感じだ。先に成果物の形を決める、要するに出力形式を指定する。これだけで手戻りがかなり減る。
https://papoo.work/doc/0eb62bbd7581d994
Claude Code に長い作業や大量の資料を扱わせるとき、コンテキストを食い潰さずに回すための実践 TIPS をまとめるクラスタである。プロジェクト知識の持たせ方、記憶に残す情報の絞り方、途中での要約と継ぎ足し、古い前提の捨て方までを扱う。コード修正だけでなく、議事録・書類・フォルダ整理のような非エンジニア用途でも効く。
Claude Code に持たせる情報を削る：要点だけ残して長文を捨てる
長い前提をそのまま投げ込むと、だいたい詰まる。Claude Code は賢いが、無限に文脈を飲み込んでも気持ちよくなるわけではない。むしろ要点が埋もれて、肝心の判断がぼやける。コンテキストを節約する、長い前提を短くする。ここを雑にすると、あとで手戻りが増える。
https://papoo.work/doc/c7318229a5f22d14
会話が長くなったら節目で要約させる：前提を崩さず進める
会話が長引くたびに、最初の前提を人間が頭の中で持ち運ぶ前提で進めるのは雑だ。Claude Code に任せるなら、途中要約でその荷物を一回降ろしたほうがいい。要点を引き継ぐ、という考え方だ。長い依頼、複数ファイルの整理、何段階もある文書作成では、節目で「いま何を前提に、どこまで決まったか」を短く残さないと、後半で平気で話がねじれる。
https://papoo.work/doc/32f26045c6793c8a
古い前提を残さない：方針変更したら言い直す
そこを曖昧にしたまま進めると、Claude Code はわりと平気で昔の指示を守り続ける。人間側が方針を変えたつもりでも、前提を更新する、古い指示を捨てる、をやらないと、作業の芯がずれていく。
https://papoo.work/doc/5c875061dd6b70fe
節目ごとに判断理由を残す：あとから迷いどころを追えるようにする
「あれ、なんでこうしたんだっけ」で止まるなら、まだ手戻りは小さいほうだ。厄介なのは、Claude Code に作業を続けさせたあとで、前の判断が消えていることだ。判断ログ、あるいは「なぜそうしたかを記録する」癖がないと、数十分後に自分で自分の指示を疑う羽目になる。
https://papoo.work/doc/a7dba04fbd4052cd
長い資料は章ごとに渡す：一気読みを前提にしない
長い資料を全部貼って「さあ読め」でうまくいくと思っているなら、そこがまずズレている。Claude Code は長文を処理できるが、だからといって一気読みさせるのが正解ではない。むしろ章ごとに渡したほうが、分割投入もしやすいし、章単位で扱うほうが手戻りも減る。
https://papoo.work/doc/6a9ca7e07f24cac1
作業中に持たせるメモは短くする：決定事項だけ残す
長いメモを抱えたまま Claude Code に作業させると、だいたい途中で鈍る。読ませた本人が満足してしまうのがいちばん厄介だ。実際には、後で効くのは「何を決めたか」だけで、経緯や雑談はほぼ邪魔になる。
https://papoo.work/doc/a9be2d3c91269854
最後に全体をまとめ直して、引き継げる形に整える
途中の作業をそのまま投げると、あとで読む人が高確率で詰まる。Claude Code でも同じで、最後に「最終要約」までやっておかないと、出力は立派でも引き継ぎには弱い。ここでやるのは、単なる要約ではない。引き継ぎ用に整形する、つまり「次の人が迷わず動ける形」に潰し込む作業だ。
https://papoo.work/doc/362ff159cfc61c36
Claude Code に作業を頼むとき、出力の形・途中報告・終了条件を先に決めて、会話の暴走と読み返し地獄を防ぐためのクラスタ。依頼内容そのものではなく、返し方と進め方を整える話をまとめる。
Claude Code の返答を短くさせるなら、最初に出力の形を決める
長文でだらだら返すように見えて、実は最初の一言が悪いだけ、というケースは多い。Claude Code は、こちらが曖昧に投げると、普通に曖昧なまま広げてくる。そこで効くのが、出力形式を先に固定する、要するに「Markdown か表かを先に言う」やり方だ。返答の長さそのものを細かく縛る前に、まず箱を決める。これだけで、返ってくる文章の輪郭がかなり締まる。
https://papoo.work/doc/d6238ea2e6e14801
途中報告の頻度を決めて、黙って進ませすぎない
Claude Code に雑に「いい感じに進めて」と投げると、あとで見たときに気持ちよく進んでいるようでいて、実はだいぶ怖い。勝手に進む時間が長いほど、手戻りは重くなる。進捗報告の粒度を決める、節目だけ返させる。この二つを先に決めておくだけで、黙って深掘りしすぎる事故はかなり減る。
https://papoo.work/doc/7d409da85baf84e8
作業の終わり方を先に指定して、止まりどころを迷わせない
Claude Code に雑に「これ直して」と投げると、だいたい途中で迷う。迷っている間にコンテキストを食い、変更が広がり、最後は「で、どこで終わればいいんだ」という顔になる。そこで先にやるべきなのが、終了条件を明示すること、つまり出口を決めることだ。
https://papoo.work/doc/25edfbfe0faa0ff9
前提が変わったら、古い指示を残さず言い直す
Claude Code に何かを頼むとき、いちばん雑にやって痛い目を見るのがここだ。前の前提を残したまま「これも直して」と足すやり方である。方針変更時に前提を捨てる、古い前提を引きずらない。呼び方はいろいろあるが、やることは同じだ。前提が変わったなら、古い指示は上書きではなく、いったん消して言い直す。
https://papoo.work/doc/2ab0090d632c9510
会話が長くなったら、節目で要約を挟んで前提を保つ
長いやり取りを「気合いで覚えておいてくれるはず」と思うと、だいたいズレる。Claude Code は会話の文脈を持っているが、無限に細部を保持してくれるわけではない。途中で要約させる、セッションを区切る。この2つを入れるだけで、指示の食い違いと手戻りがかなり減る。
https://papoo.work/doc/b9257d3c093b41cd
長い作業は章立てして、途中の迷子を減らす
長文を一気に投げて、あとで「どこまでやったんだっけ」となるのは、かなりありがちな失敗だ。Claude Code は賢いが、長い作業を雑に渡せば、平気で話が横に広がる。だから最初から章立てして、途中の迷子を減らす。別名で言えば、章ごとに分けて頼む、長文を分割して進める、だ。
https://papoo.work/doc/48ed52c2098241cc
持たせるメモは短く、決定事項だけ残す
Claude Code に長い作業メモを食わせて安心していると、だいたい途中で鈍る。読ませたいのは議事録ではなく、次に動くための要点だ。 作業メモを削る、短いメモだけ渡す。どちらも同じ話で、要するに「判断に必要な情報だけ残し、経緯は捨てる」ということになる。
https://papoo.work/doc/377859571c269240
判断理由を残させて、あとから迷いどころを追えるようにする
Claude Code に作業を投げるとき、いちばんもったいないのは「何をしたか」は残るのに「なぜそうしたか」が消えることだ。あとで diff を見返しても、そこで迷った理由が抜け落ちていると、同じ場所でまた立ち止まる。決定の根拠を記録する、途中の判断を書かせる、要するにその場の思考を残す使い方だ。
https://papoo.work/doc/26bc8832ec58ec3f
調査ログと変更結果を照合して、ずれた場所を見つける
「やったつもり」で終わる調査ほど、あとで面倒なものはない。ログは残した、変更もした。なのに、どこが期待と違ったのか分からない。そういうときに効くのが、調査ログと変更結果を突き合わせるやり方だ。要するに、ログと差分を突き合わせる、期待とのズレを読む、という作業である。
https://papoo.work/doc/c813ec1134fccb96
Claude Code で大きめの作業を安全に進めるには、会話の切り方より先に「作業場所」を分けるのが効く。ここでは、作業ブランチ、別ディレクトリ、実験用の退避先をどう使い分けるかに絞って、変更の衝突やうっかり上書きを避ける TIPS をまとめる。非エンジニアのファイル整理でも、案件ごと・用途ごとに場所を分ける発想はそのまま役立つ。
Claude Code で別の作業場所を切る：本流を汚さず試す基本
本流のリポジトリでそのままClaude Codeを走らせて、あとで「あれ、どこまで触ったっけ」となるのは、かなりよくある失敗だ。雑に試すほど差分は太り、戻すのも面倒になる。だから最初から別の作業場所を切る。作業ブランチでもいいし、別ディレクトリでもいい。Gitのworktreeを使えば、同じリポジトリを複数の作業場所に分けて置ける。
https://papoo.work/doc/b04ff502ab3f79f0
本番用の作業と試作品を分ける：失敗しても戻しやすい置き方
本番の作業と試作品をごちゃ混ぜにする人は、だいたいあとで泣く。ファイルが増えたとき、どれが完成版でどれが実験用コピーなのか分からなくなり、戻したいのに戻せない。Claude Code を使うなら、ここを先に分けておくべきだ。退避先、検証用コピー、実験用コピーを最初から用意しておけば、雑に試しても本線を壊しにくい。
https://papoo.work/doc/49eaa8be5089eb22
同じリポジトリで複数の案を並走させる：作業場所を分けて比較する
それ、ひとつの作業場所で全部いじるから、あとでどれが良かったのか分からなくなるのだ。 Claude Code を使うときも同じで、雑に一案ずつ上書きしていると、比較検討どころか「前の案、どこへ行った」となる。並走作業をちゃんとやるなら、同じリポジトリでも作業場所を分ける。これだけで、複数案を並べて見比べやすくなり、手戻りも減る。
https://papoo.work/doc/f590680616fd6acb
Claude Code に触らせる範囲を狭める：作業フォルダを先に決める
Claude Code に何でも見せると、だいたい雑になる。人間でもそうだが、道具も広すぎる作業範囲を渡すと、余計なファイルまで見に行って、指示の解像度が落ちる。 だから先に作業フォルダを決める。対象フォルダ、作業領域、作業範囲を絞る。これだけで、読み違いも、関係ない差分も、やたら長い往復も減る。
https://papoo.work/doc/0aed00bb585c73ea
ブランチを切る前に整理する：変更を小さく始める準備
ブランチを切ってから整理しようとすると、だいたい面倒になる。差分が増え、指示があいまいになり、Claude Code に投げる文面まで雑になるからだ。先に片づける。これを事前整理、着手準備、分割開始の土台づくりとしてやっておくと、変更は小さく始めやすい。
https://papoo.work/doc/6bd9d97797405033
別作業の成果を混ぜない：一時ファイルと成果物の置き場を分ける
雑に作業を始めると、あとでいちばん困るのは「何が途中で、何が完成か分からなくなる」ことだ。Claude Code でも同じで、一時ファイルと成果物を同じ置き場に放り込むと、差分は汚れるし、次の作業で前回のゴミまで拾う。地味だが、かなりだるい事故になる。
https://papoo.work/doc/9ca715a7a3c9d294
コンフリクトを増やさない進め方：同じファイルを同時に触らせない
同じファイルを何人にも同時編集させて、あとでコンフリクト地獄に落ちる。これ、かなりありがちな失敗だ。Claude Code を使うときも同じで、便利だからこそ雑に並列化すると、差分が膨らみ、直す側がだるくなる。
https://papoo.work/doc/daf48ef5c804d40d
案件ごとにディレクトリを分けて、後から探しやすくする
ごちゃつく人は、だいたい最初から全部を同じ箱に入れる。Claude Code でもそれをやると、あとで自分が掘り返す段階で詰まる。案件フォルダ、整理用フォルダ、分類ルールを先に決めておくと、ファイルが散らからないだけでなく、AI に任せるときの指示もかなり通りやすくなる。
https://papoo.work/doc/becfd9803306bf22
試し書きは別場所で済ませる：下書きと確定版を分離する
その場でいきなり本番ファイルを触るから、あとで余計な手戻りが出る。Claude Code を使うときは、下書き、確定版、ドラフトをちゃんと分けたほうがいい。ここを雑にすると、内容も差分も散らかるし、何を直したのか追いにくくなる。
https://papoo.work/doc/dadabf6596afae6f
終わった作業を片付ける：使い終わったブランチや作業場所の整理
終わったのに、作業場所だけが残り続ける。これがいちばん地味で、いちばん効く事故だ。Claude Code を使うと、調査用の分岐や作業ディレクトリをさっと作れるぶん、片付け、後始末、不要な作業場所の整理を後回しにしやすい。すると、次に開いたときに「どれが本線で、どれが捨てていいやつだっけ」と毎回確認する羽目になる。これ、かなりだるい。
https://papoo.work/doc/29d0e3456e751331
Claude Code に作業させるときの「どこで、何を、どこまで触らせるか」を先に決めるためのクラスタである。会話の節目やセッション管理ではなく、作業場所・分離・並走・片付けに寄せてまとめる。開発用途だけでなく、下書き作成やファイル整理でも効く、実務寄りの境界設定 TIPS を束ねる。
Claude Code に触らせる場所を先に決める
Claude Code を使い始めた人が最初にやりがちな失敗は、いきなり「このへん全部見て、いい感じにやって」と雑に投げることだ。これ、かなり危ない。作業フォルダを先に固定する、触らせる範囲を狭める。たったこれだけで、コンテキストの浪費と事故の確率が目に見えて下がる。
https://papoo.work/doc/0c8e6ddf0ac10f4e
本番用の作業と試作品を分ける
本流を汚しながら試す人は、だいたい後で自分に殴られる。Claude Code は便利だが、便利なぶん、確定版のファイルにそのまま触らせると面倒が一気に増える。試し書きと確定版を分離する、つまり本番用の作業と試作品を分けるだけで、手戻りも差分の読みづらさもかなり減る。
https://papoo.work/doc/7632f2e05125ff19
同じリポジトリで複数案を並走させる
「1つの作業場所で少しずつ直せばいい」と思っていると、だいたい途中でぐちゃる。 Claude Code でも同じで、案を分けて試すなら、同じリポジトリの中で作業場所を分けて走らせるほうが圧倒的に扱いやすい。別作業場所で比較する、案を分けて試す、というやり方だ。
https://papoo.work/doc/71c0fc65492c4da9
案件ごとにディレクトリを分けて後から探しやすくする
同じ場所に全部ぶち込んで、あとから「どれがどの案件の資料だっけ」と探し回る。これ、かなり雑に見えて、実は一番コストが高い整理不足だ。Claude Code を使うなら、案件フォルダを切る、整理用の置き場を分ける、という発想に早めに寄せたほうがいい。そうしておくと、後から資料を拾いやすいし、生成した文書の差し替えや見直しも楽になる。
https://papoo.work/doc/019d2c75e97d4e08
別作業の成果を混ぜない
Claude Code を使っているのに、あとで「このファイル、誰の仕事の途中だっけ」となるなら、だいたい混ぜすぎだ。 一時ファイルと成果物を分離する。作業途中のゴミを残さない。ここを雑にすると、ディスクはじわじわ減るし、差分は読みにくくなるし、別件の作業まで巻き込む。筆者も最初はよくやった。資料を整えてほしいだけなのに、途中生成したメモ、抽出結果、古い版が同じ場所に積もって、どれが納品物か分からなくなった。
https://papoo.work/doc/f6dbd438e96c8973
コンフリクトを増やさない進め方
同じファイルを同時に触らせると、だいたい面倒になる。Claude Code でもそこは変わらない。 「同時に走らせれば速いはず」と思って並列に投げると、diff がぶつかる、指示が食い違う、片方の修正をもう片方が上書きする、で手戻りが増える。やるべきことは単純で、同じファイルを同時に触らせない、衝突しにくい分担にすることだ。
https://papoo.work/doc/14177dc70713e452
ブランチを切る前に整理する
ブランチを切ってから考える人は、だいたいあとで自分の差分に殴られる。 変更を小さく始める準備、作業開始前の下ごしらえを飛ばすと、Claude Code に渡す文脈が散らかる。すると指示は長くなるし、余計なファイルまで触るし、diff もでかくなる。手戻りの回数が増えるのは、たいていここだ。
https://papoo.work/doc/161030bc1ca866b5
試し書きは別場所で済ませる
本番のファイルにいきなり書き始める人は、だいたいあとで自分の差分に泣く。Claude Code でも同じで、思いついた指示を確定版に直書きすると、途中の試し書きまで履歴に残って、あとから何が本筋だったのか分からなくなる。
https://papoo.work/doc/ffa43ba9ca76eaae
終わった作業を片付ける
終わった仕事をそのまま残す人は多い。しかも「あとで見るから」と言いながら、数日後には同じブランチ、同じ作業フォルダ、同じ不要ファイルの山にまた足を取られる。Claude Code はそこを雑に流さず、使い終わった作業場所を整理する、ブランチやフォルダの後片付けまで含めて片づけ役にできる。
https://papoo.work/doc/e79c5403d99ee9d7
別作業場所を切って本流を汚さず試す
新しい指示をいきなり今の作業フォルダで試すと、だいたいろくなことにならない。差分が混ざる、途中のメモが散る、戻したいのに戻しにくい。Claude Code でやるなら、まず別作業場所を切って本流を汚さず試す。安全に試すための作業場を分ける、本番と検証を分離する、という考え方だ。
https://papoo.work/doc/cafea688817654a9
Claude Code に長めの作業を任せるとき、返答の形・途中報告・確認の止めどころを先に決めて、迷走と手戻りを減らすためのクラスタ。調査、編集、要約、検証を一度に混ぜず、会話の節目で前提を保ちながら進める TIPS をまとめる。非エンジニアの整理作業にもそのまま使える。
返答の形を先に固定する：Markdown か表かを決めてから頼む
Claude Code に雑に「これを整理して」と投げると、返ってくるものが妙に長い説明文になって、あとで自分が切り貼りする羽目になる。ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown でほしいのか、表でほしいのか、成果物の形を固定してから頼む。これだけで手戻りがかなり減る。
https://papoo.work/doc/35715d361e98f0b4
途中報告の頻度を指定して、黙って進みすぎるのを防ぐ
Claude Code に任せると、気づいたら最後まで走り切っていて、途中の判断材料が消えることがある。これが地味に痛い。途中報告を入れさせる、中間報告を入れさせる、進捗の粒度を決める。この3つをちゃんと使うだけで、勝手に突き進んで戻れなくなる事故をかなり減らせる。
https://papoo.work/doc/9e0cfb499b1ee099
節目で要約を挟ませると、長い会話でも前提が崩れにくい
長いやり取りほど、Claude Code は勝手に賢くなった気になって崩れる。実際には、途中で前提が抜ける、対象ファイルを取り違える、同じ修正を別名で繰り返す、こういう地味な事故が起きやすい。そこで効くのが途中要約だ。会話を区切って要約させる。節目で一度整理を挟むだけで、どこまで進んだか、何を決めたか、何を残したかが見えやすくなる。
https://papoo.work/doc/76a8ed0a42475460
前提が変わったら古い指示を捨てて、言い直す
Claude Code に同じ話を延々と持ち込んでいると、だいたい一回はズレる。古い前提を残したまま「ちょっとだけ追加で」と積み上げるからだ。方針変更の再指示、古い前提を残さない、というのは派手なテクニックではないが、実務ではこれが効く。
https://papoo.work/doc/0359d77a58a8c694
長い資料は章ごとに渡して、一気読み前提をやめる
長い資料をそのまま全部投げるのは、だいたい雑だ。Claude Code は長文でも扱えるが、だからといって「最初から最後まで一気に読んで、全部を一発で直してくれ」で済ませると、要点がぼける。途中で重要な条件を落としたり、修正の軸がぶれたりして、あとで手戻りになる。
https://papoo.work/doc/9a5db4d755a8aa15
Claude Code の返答そのものを整えるための TIPS クラスタだ。依頼の粒度や作業手順ではなく、出力形式・分量・途中報告・要約・終わり方を先に決めることで、長い会話でも見失いにくくし、あとから引き継げる成果物に寄せる。調査、編集、整理、下書き生成を Claude Code に任せるとき、最後の見え方で損をしないための実用技をまとめる。
Markdown か表かを最初に決めると、返答が暴れない
Claude Code に雑に「一覧で」「見やすく」で投げると、返答の形が毎回ぶれる。ここを甘く見ると、あとでコピペしづらい、差分が読みにくい、保存したときに壊れやすい、の三重苦になる。先に Markdown で出すのか、表で出すのかを決めておく。要するに出力形式の固定だ。成果物の形を先に決めるだけで、返答はかなり安定する。
https://papoo.work/doc/a17be6aff3992cf1
返答を短くさせたいなら、先に分量の上限を伝える
長文を投げておいて「要点だけ返せ」は、だいたい伝わりきらない。Claude Code でも同じで、先に分量の上限を決めておかないと、返答は平気で膨らむ。短くまとめさせる、要点だけ返させる、という使い方をしたいなら、最初に「何行まで」「何文字まで」「箇条書き何点まで」を入れておくのがいちばん効く。
https://papoo.work/doc/e389b679aa1722ce
作業中に持たせるメモは短く、決定事項だけ残す
長い経緯メモを Claude Code に持たせると、だいたいろくなことにならない。読み返すだけでコンテキストを食い、肝心の判断材料が埋もれる。残すべきなのは、途中の雑談ではなく決定事項だ。短い作業メモ、あるいは決定事項の圧縮という発想に切り替えると、作業が急に軽くなる。
https://papoo.work/doc/d2a661f38685101a
Claude Code の会話セッションを、長さ・再開・整理の観点でうまく扱うための TIPS 群。長文のやり取りで前提が崩れるのを防ぎ、作業の節目で要約や切り替えを入れながら、会話を肥大化させずに進めることに集中する。作業の途中で迷子になりやすい人や、ひとつのセッションに情報を溜め込みがちな人向けのまとめである。
会話が長くなったら節目で要約させる
長い会話をそのまま流しっぱなしにすると、Claude Code は平気な顔で文脈を抱えたまま進む。これが曲者だ。人間は「ここまでの話、何だったっけ」となり、モデル側も要点の輪郭がぼやけてくる。そこで入れるのが途中要約、節目の要約、要点整理である。会話の途中で一度立ち止まらせ、ここまでの決定事項・未決事項・次にやることを短く並べ直させる。これだけで、手戻りがかなり減る。
https://papoo.work/doc/fad240d912e52d26
前提が変わったら、古い指示を捨てて言い直す
Claude Code に雑に「さっきの続きで」「さっきの方針で」とだけ投げると、だいたいズレる。前提が変わったのに、古い指示を抱えたまま走らせるからだ。これが前提の更新、方針変更、そして古い前提を消すという話である。
https://papoo.work/doc/f60e6df2c7c4ec38
Claude Code に修正だけでなく、仕上げの前後で自分の仕事を点検させる流れをまとめるクラスタだ。レビュー、検証、差分の読み直し、説明文の整え直しまでを一続きの作業として扱い、手戻りを減らす。
変更前に自己レビューの観点を先に書かせる
雑にいじってから確認させると、だいたい手戻りする。Claude Code でもそこは変わらない。先にセルフレビュー、つまり事前レビューの観点を出させてから変更に入るだけで、あとから「そこじゃない」を潰しやすくなる。
https://papoo.work/doc/16b4408017fbf42d
自分の差分を Claude Code に赤入れさせる
自分で書いた差分ほど、雑に見てしまう。そこが一番まずい。 「差分レビュー」や「レビュー依頼」を自分宛てに投げる感覚で Claude Code を使うと、勢いで書いた変更を一度外に出せる。すると、読みにくい命名、説明不足のコメント、余計なファイル変更が、かなり早い段階で見つかる。
https://papoo.work/doc/a17a25c33edf2d3c
テスト結果と差分を突き合わせて、直したつもりを潰す
「直しました」で終わらせると、たいていどこかがまだ死んでいる。見た目は直っていても、テストは別の場所で赤いまま、あるいは差分だけ眺めると肝心の修正が抜けている。そこで効くのが、検証と照合だ。テスト結果と git diff を突き合わせる。これだけで「直したつもり」のまま次に進む事故がかなり減る。
https://papoo.work/doc/761477ecd8ee524c
修正後の説明を短く要約させて引き継ぎやすくする
修正した説明を、そのまま長文で押しつけるのはだいたい失敗する。読む側は「で、何が変わったのか」だけ知りたいのに、前提や経緯まで全部読む羽目になるからだ。ここで効くのが、要約だ。さらに引き継ぎメモとしてそのまま使える形に落としておくと、次の人が拾いやすい。
https://papoo.work/doc/ac2ce76f652ce948
コミット前に変更の見落としを洗い出させる
コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。 Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。
https://papoo.work/doc/a4be38744afbb059
PR に載せる前に論点を整理させて、説明の芯を作る
PR にそのまま貼る説明文を、いきなり Claude Code に書かせると、だいたい散らかる。要点が混ざる。変更の理由が薄まる。読んだ相手が「で、何を見ればいいの」となる。 ここで効くのが、先に論点整理をさせて、PR説明の芯を作ってから本文に落とすやり方だ。非エンジニアの作業でも同じで、ファイル整理でも文書作成でも、先に「何を伝えるか」を固めるだけで手戻りがかなり減る。
https://papoo.work/doc/2fd3dc6e80a9435a
ログと変更履歴を並べて、判断のズレを追う
変更を見ただけで納得した気になると、だいたい後で崩れる。差分は「何を変えたか」しか教えてくれないが、ログは「そのとき何を考えていたか」を残す。Claude Code では、この二つを並べて追う癖をつけると、作業のズレがかなり減る。作業ログ、履歴確認、どちらの感覚でも使えるやり方だ。
https://papoo.work/doc/b6e67b7d4727c323
再現しない不具合を切り分けて、勘違いを減らす
「たまに起きる」「さっきは動いた」──その手の話は、だいたい不具合そのものより先に、話の組み立てが崩れている。Claude Code で詰まるのもそこだ。再現しないまま雑に修正へ飛ぶと、原因と対処がズレる。不具合切り分けと再現性確認を先に固めるだけで、勘違いはかなり減る。
https://papoo.work/doc/a3ba132682adaf4a
長い作業のあとに差分を圧縮して、要点だけ残す
長時間いじったあとに「全部見直してください」と投げるのは、だいたい破綻する。差分がでかすぎて、Claude Code も人間も本当に大事なところを見失うからだ。ここでやるべきなのは、差分圧縮と要点整理だ。作業の途中で散らかった変更を、あとから読める単位に畳み直す。変更点の量を減らす話ではない。意味の粒度をそろえる話である。
https://papoo.work/doc/65b2170f158c8bb2
レビュー観点をテンプレ化して、毎回の確認を速くする
レビューで毎回ゼロから目をこらしていると、だいたいどこかで雑になる。しかも厄介なのは、雑になる場所が毎回少しずつ違うことだ。今回たまたま見たつもりでも、次回は別の抜けが出る。これ、かなりもったいない。
https://papoo.work/doc/c281086c81b72864
Claude Code との長いやり取りで、前提・途中結果・指示の粒度を崩さずに進めるための実践 TIPS をまとめるクラスタ。会話が伸びたときに何を残し、何を捨て、どこで要約し、どう次の指示へつなぐかを扱う。調査、編集、確認をまたぐ作業や、前提変更の多い案件で特に効く。
会話が長くなったら、節目で要約させて前提を保つ
長いやり取りで一番こわいのは、Claude Code が急に変な方向へ走ることではない。前提を忘れたまま、もっともらしい修正を積み増していくことだ。これで差し戻しが増える。diff は肥大化する。こっちは「何の話だったっけ」と画面を見返す羽目になる。
https://papoo.work/doc/1c5e0f596aab3143
途中報告の頻度を決めて、黙って進みすぎない
Claude Code は、放っておくと気持ちよく走り続ける。で、そのまま最後にまとめて見せてきて、こちらが「そこじゃない」と言う。これがいちばんもったいない。途中報告、つまり進捗頻度を先に決めておくと、この事故がかなり減る。
https://papoo.work/doc/98f81c741309964b
Claude Code に渡す文脈を整理し、長いやり取りや作業の迷子を減らすための TIPS クラスタ。依頼の粒度、要約、途中報告、前提の更新、持たせる情報の削り方をまとめて扱うと、手戻りをかなり潰せる。
Claude Code に渡す材料を削ると、むしろ精度が上がる
「たくさん渡せば賢くなる」は、Claude Code ではわりと危ない思い込みだ。長文をそのまま投げる、関係ないフォルダまで一緒に渡す、メモを全部貼る。やりがちだが、これで答えが良くなるとは限らない。むしろノイズが増えて、出力がぶれる。要点だけ渡す、長文を圧縮する、文脈を削る。こっちのほうが、狙いが通りやすい。
https://papoo.work/doc/3e2619a55cd181dd
章ごとに渡すと、長い資料でも迷子になりにくい
長い資料を丸ごと投げて「読んで」とやると、だいたい途中で雑になる。Claude Code は雑にしても止まらないが、こちらの意図は平気で薄まる。そこで効くのが、章ごとに渡すやり方だ。分割投入、資料を小分けにする、一気読みさせない、というやつである。
https://papoo.work/doc/db871e0959ad0def
途中で要約を挟ませて、前提のズレを止める
Claude Code に雑に長文を投げて、そのまま最後まで走らせる。これをやると、途中で前提がズレたまま突き進み、あとで手戻りする。かなりあるあるだ。 そこで効くのが、途中で要約を挟ませるやり方である。節目で要約、中間サマリー、会話の棚卸し、と呼び方はいろいろあるが、要するに「ここまでの理解を一回言わせる」だけだ。これを入れると、Claude Code が勝手に補完した前提、抜けた制約、あいまいな目的を早めに炙り出せる。
https://papoo.work/doc/636e1a568400fff6
途中報告の頻度を決めて、黙って進みすぎるのを防ぐ
Claude Code に雑に「適当に進めて」と投げると、静かに深掘りしすぎて、あとから人間が困る。これが一番ありがちな事故だ。節目だけ報告、進捗の粒度、黙らせるか返させるかを先に決めておくと、作業の暴走をかなり防げる。
https://papoo.work/doc/d5adbf93f694cf65
最後に全体をまとめ直して、引き継げる形にする
最後の最後に雑に投げるだけだと、Claude Code はかなり簡単に“作業した気分の断片”を吐く。そこから人に渡せる形へ直す一手間を入れるかどうかで、引き継ぎ用の要約、最終サマリー、成果物の整形の質が露骨に変わる。ここをサボると、あとで「結局どこが変わったのか」「何を前提に進めればいいのか」が読み取れず、会話をもう一往復、いや二往復する羽目になる。
https://papoo.work/doc/e0958624996b2f7e
返答の形を先に固定して、出力の暴れを抑える
Claude Code に雑に頼んで、返ってきた答えが毎回バラつく。これはかなりありがちな失敗だ。長文で返ってきたり、逆に一言で終わったり、箇条書きが崩れたりする。先に返答の形を決めておかないと、後で整える手間が地味に重い。
https://papoo.work/doc/ec76ab2fd71fef4d
Claude Code を使った作業場所の切り分け、試作、片付け、引き継ぎまでを扱うクラスタだ。1 回の依頼をどう始めるかではなく、別作業を混ぜずに進め、終わったあとに散らからない運用に焦点を当てる。開発だけでなく、書類整理や大量ファイルの仕分けでも効く。
試作は別ディレクトリに逃がすと、本流が一気に静かになる
本流のフォルダにそのまま試作を混ぜると、だいたいろくなことにならない。差分は膨らむし、どこまでが本番でどこからが試行錯誤かも見えなくなる。Claude Code を使うなら、最初に「別作業場所を切る」「作業ディレクトリを分ける」「サンドボックスで試す」を先にやるだけで、後の会話がかなり静かになる。
https://papoo.work/doc/39dd2420ae175c3f
案件ごとに作業フォルダを分けて、後から迷子にならない
その場しのぎで同じ場所に全部押し込むと、あとで確実に詰まる。Claude Code でも同じだ。案件単位で分ける、要するにフォルダ設計を先に決めて、整理用の作業場所を案件ごとに切るだけで、あとから「この差分どれだっけ」「この原稿どこに置いた」と迷わなくなる。
https://papoo.work/doc/41877dd629627f8a
同じリポジトリで複数案を並走させるなら、場所の衝突を先につぶす
並走作業でいちばん雑にやってしまうのが、「とりあえず同じ場所で別案を回す」ことだ。これ、すぐ詰まる。Claude Code は賢いが、同じリポジトリの同じファイル群を複数案でいじらせると、変更の混線と差分の肥大化が一気に起きる。複数案の比較をしたいなら、同時進行の整理は最初にやる。場所の衝突を先につぶしておくのが、あとで一番効く。
https://papoo.work/doc/b33ae44ea4c31cc1
本番用と試作品を混ぜない：下書きと確定版を分離する
試し書きのファイルに、いつのまにか本番用の文章や成果物まで混ざる。これ、かなり雑に見えて、あとでいちばん高くつくやつだ。下書きと確定版を分ける、成果物の置き場を分ける。Claude Code を使うなら、この線引きは最初にやっておいたほうがいい。
https://papoo.work/doc/5da2e1ac5ec3853b
終わった作業を片付けると、Claude Code の次の仕事が速くなる
終わった成果物をいつまでも作業場所に置きっぱなしにするのは、地味に効くムダだ。不要なブランチ整理や、使い終わった成果物の整理を後回しにすると、Claude Code は次の仕事で関係ないファイルをまた見に行くし、あなたも「これ、まだ触るんだっけ」と迷う。あの手の迷いは、思った以上にコンテキストを食う。
https://papoo.work/doc/7fce30f357c087c5
触らせる範囲を狭めるだけで、余計な事故はかなり減る
Claude Code に大きなフォルダを丸ごと渡して、「あとはよろしく」はかなり危ない。 余計なファイルまで見に行かせると、コンテキストを食うし、意図しない場所まで修正しやすい。対象フォルダを限定する、作業範囲の制御を先にやる、巻き込み事故を防ぐ。これだけで、手戻りは目に見えて減る。
https://papoo.work/doc/d4ed4b3134483627
一時ファイルを残さない依頼にすると、あとで見返しやすい
Claude Code に作業させるとき、成果物だけ欲しいのに、作業用メモや途中生成物まで山ほど残してしまう。これがあとで地味にだるい。 一時ファイルの扱いを最初に決めておくと、成果物と作業用メモの分離がはっきりする。ゴミを残さない頼み方にしておけば、あとで見返したときに「結局どれが本体だっけ」が起きにくい。
https://papoo.work/doc/045773dfe8e9fbee
ブランチを切る前に整理して、変更を小さく始める
いきなりブランチを切って、あとから全部を Claude Code に投げ込む。これ、かなり雑だ。変更前整理を先にやらないと、ブランチ運用がすぐ重くなるし、小さく始める準備もできない。結果として、diff は肥大化する、指示はぼやける、どこまで直したのか自分でも追えなくなる。
https://papoo.work/doc/57a5c12af1b75905
複数の案件を並べるときは、コンフリクトの芽を先に摘む
複数の案件を同じ作業場で走らせると、だいたいどこかで噛み合わなくなる。これはClaude Codeでも同じで、雑に並べると、同時編集の回避が甘くなって、ファイルの衝突防止に失敗する。結果として、同じファイルを別案件が触っていたり、片方の作業がもう片方の差分を上書きしたりする。地味だが、いちばん手戻りが高い事故だ。
https://papoo.work/doc/833de96ef88fa0cb
引き継ぎやすい状態で終えると、次回の Claude Code が迷わない
作業の終わりに雑に閉じると、次回の Claude Code は平気で迷う。人間でも嫌になるあの状態だ。直前まで何をやっていたか、どのファイルを触ったか、何が残っているかが散らばったままだと、次の一手が毎回「状況確認」になる。もったいない。
https://papoo.work/doc/5fc87886d63341f0
Claude Code を使うときに、作業場所・一時ファイル・試作品・成果物の置き方を整えて、あとから迷子にならないようにするための TIPS クラスタである。コード作業だけでなく、書類整理や下書き作成にも効く。前提は「どこで何を触らせるか」を先に決めることだ。
作業フォルダを先に決めると、Claude Code の事故がかなり減る
Claude Code に雑に「これ直して」と投げて、そのまま広い場所を触らせる。これがいちばん危ない。 事故の多くは、モデルの頭の良し悪しではなく、触らせる範囲が広すぎることから起きる。だから先にやるべきは、作業場所を固定することだ。別名で言えば、触らせる範囲を狭める、だ。
https://papoo.work/doc/1b58e1fd1d805031
本番用の作業と試作品を分けると、手戻りが一気に楽になる
それ、いきなり本番の場所で試すから詰まるのだ。Claude Code は手早く頼めるぶん、雑に使うと変更が広がる。下書きと確定版を分離する、試作品を別場所に逃がす。たったこれだけで、あとから直すときの面倒さがかなり減る。
https://papoo.work/doc/2e3b4ffcbca047e2
同じリポジトリで複数案を並走させるときの衝突回避
同じ作業場に案を2つ3つ重ねると、だいたいどこかでぶつかる。ファイルが上書きされる、差分が汚れる、どの変更がどの案のものか分からなくなる。ここを雑にやると、Claude Code はむしろ便利さより手戻りを増やす。 だから先に作業場所を分ける。複数案を別作業場所で進める、要するに並走作業の整理だ。これだけで衝突の大半は消える。
https://papoo.work/doc/17e336875e78841e
同じファイルを同時に触らせないだけで、コンフリクトは減る
「差分が悪い」のではない。たいていは、同じ場所を同時に触らせた運用が雑だ。 Claude Code でコンフリクトを減らしたいなら、まずやることは派手な自動化ではない。同じファイルを同時に触らせない。これだけでかなり効く。別名でいうなら、コンフリクトの芽を摘む、あるいは編集箇所の分離だ。
https://papoo.work/doc/954204b5daa68dec
終わった作業を片付けると、次の Claude Code が速くなる
終わったディレクトリをそのまま放置していると、次の Claude Code が地味に鈍る。これ、かなりありがちな落とし穴だ。 使い終わった作業場所の整理、要するに後片付けをしておくと、次回は「何を見ればいいか」が明確になり、探し回る時間も、余計な差分に引っ張られる手間も減る。
https://papoo.work/doc/31aeeb386248b57d
Claude Code に渡す文脈の量と境界を整え、長いやり取りでも前提を崩さず、出力を暴れさせず、手戻りを減らすためのクラスタである。調査・編集・要約・引き継ぎを分けて、必要な情報だけを短く持たせる実践に寄せる。
会話が長くなったら節目で要約させる：前提を保って進める
長い会話は、だいたい前提がこぼれて終わる。 Claude Code でも同じで、途中までうまく進んでいたのに、少し話が伸びただけで「最初に何を守る話だったか」が薄れる。そこで効くのが、長い会話の要約、あるいは節目要約だ。要するに、途中で一度立ち止まって「ここまでの前提・決定・未解決」を短く固め直す。これを入れるだけで、手戻りが目に見えて減る。
https://papoo.work/doc/c01135d47d088290
Claude Code に長い作業や複数の指示を渡すとき、コンテキストの持たせ方・切り替え方・記録の残し方を整えて、迷子や手戻りを減らすためのクラスタである。依頼の粒度、要約、前提の更新、判断理由の保持を軸に、長丁場でも崩れにくい進め方をまとめる。
節目ごとに要約を挟ませて、長い会話でも前提を保つ
長い会話で詰まる人は、だいたい「最初の前提がどこかで抜ける」ことを軽く見ている。Claude Code でもこれは同じだ。作業が進むほど、会話の文脈はじわじわ重くなる。途中で条件が増え、方針が変わり、古い依頼文と今の依頼文が混ざる。そこで効くのが途中要約、つまり節目のサマリーだ。節目ごとに短く整理させておくと、後半で前提が崩れにくい。結果として、手戻りと再説明が減る。
https://papoo.work/doc/0fe218ff958f775d
Claude Code に渡す文脈を削り、区切り、要約し、前提のズレを防ぐための実践クラスタだ。長い資料や長い会話で迷子にならない進め方をまとめる。
長い依頼は最初に区切る：一気読み前提をやめる
長い依頼をそのまま投げて、Claude Code が途中でズレる。これ、かなりありがちな失敗だ。 依頼の分割、作業の切り分けを先に入れておくと、指示の抜けや解釈違いが目に見えて減る。しかも、やり直しが起きたときの損失も小さい。長文を一発で飲み込ませる前提そのものを捨てたほうがいい。
https://papoo.work/doc/8fa5cf4b970bfd83
材料は章ごとに渡す：長文を丸ごと貼らない
長い依頼文を一発で投げると、たいていろくなことにならない。Claude Code は賢いが、材料の山をそのまま渡せば、要点がぼやけるし、余計なところまで気を取られる。だから使うのは分割投入、つまり長文の小分けだ。
https://papoo.work/doc/120a9cd68a3478c2
節目で要約を挟ませる：前提のズレを止める
長い指示を一気に投げて、そのまま走らせる。これ、Claude Code でいちばん手戻りが増えるやり方だ。 途中で前提がズレていても、最後までそれっぽく進んでしまうのが厄介で、気づいた時には diff が太っている。そこで効くのが途中要約、つまり節目要約だ。節目ごとに「ここまでの理解」を短く言わせるだけで、ズレを早めに止められる。
https://papoo.work/doc/bd4aebce11e71b81
途中報告の頻度を先に決める：黙って進みすぎない
黙って最後まで走らせて、あとで「あれ、思っていたのと違う」が出る。Claude Code でもこれをやると、地味に痛い。 進捗報告、報告間隔を先に決めておくだけで、その手戻りはかなり減る。
https://papoo.work/doc/a2ba2aead0014cc3
前提が変わったら古い指示を捨てる：言い直しで迷いを消す
Claude Code でいちばん無駄なのは、もう変わった前提を延々と引きずることだ。昨日まで有効だった指示を、そのまま今日も抱え続けると、会話は静かに濁る。出力がズレる、修正が増える、diff が太る。地味だが、かなり痛い。
https://papoo.work/doc/35833f92f6ed9978
返答の形を先に固定する：Markdown か表かを決める
「とりあえず答えて」で始めると、あとで整形し直す羽目になる。Claude Code でもここは同じで、返答の形を先に固定するだけで手戻りがかなり減る。出力形式の指定、返答フォーマットを先に渡しておく、というやつだ。
https://papoo.work/doc/be82ed4e1a95fc15
返答を短くさせるなら、分量の上限を伝える
「短くして」とだけ投げると、返ってくる文量が妙にぶれる。そこを曖昧にしたままだと、Claude Code は空気を読んでいるようで読んでいない。なら最初から上限を切る。短文指定、出力量の制御は、だいたいここで効く。
https://papoo.work/doc/c53cfd6a54ad4d68
最後に全体をまとめ直す：引き継げる形に整える
作業が終わったあとに「もう十分だろ」と放り出すと、あとで一番だるい。受け取る側が読む気を失うからだ。Claude Code を使うなら、最後にやるべき仕事は修正の上積みではない。最終要約、つまり成果物の圧縮だ。引き継げる形に整えて初めて、作業は終わる。
https://papoo.work/doc/08d822f01bd91851
作業ログを見返して、迷った地点を次回に生かす
「あとで見返せばわかる」と思って、肝心な迷い方を残していない。これがいちばんもったいない。Claude Code は作業を進める道具としては強いが、勝手に次回のための教材まで整えてくれるわけではない。だからこそ、作業ログの確認、つまり振り返りを一手間足して、迷った地点を拾い上げておくと効く。
https://papoo.work/doc/eaa56809cc1e5bfe
Claude Code の返答量、途中報告、要約の入れ方を整えて、長いやり取りでも前提を崩さずに進めるためのクラスタである。調査・編集・確認が混ざって会話がだらだら伸びる失敗を防ぎ、出力の形と進行のリズムを先に決める実務寄りの TIPS をまとめる。非エンジニアの文書作成や整理作業でも効く。
返答を短くさせたいなら、分量の上限を伝える
長く返ってくるのは、Claude Code が空気を読めないからではない。こちらが「どこまで書いていいか」を渡していないからだ。 出力の長さを抑える、短く要約して返させる、分量指定。このへんを最初に言っておくだけで、返答の暴走はかなり減る。
https://papoo.work/doc/989e117d05b56fff
途中で要約を挟ませる：前提のズレを止める
途中までちゃんと合っていたのに、最後の最後でズレる。Claude Code ではこれがいちばん面倒だ。たいてい原因は、最初の前提が少しずつ摩耗していることにある。定期要約、会話の棚卸し、前提の再確認を途中で挟むだけで、この手の手戻りはかなり減る。
https://papoo.work/doc/f0dfbbd86cb1fab5
長く続く Claude Code のやり取りで、会話の文脈を食い潰さずに進めるためのクラスタだ。要約、前提の言い直し、材料の圧縮、判断理由の記録をまとめて扱い、長文依頼や段階的作業の精度を上げる。既存の「節目で要約」「長い資料を章ごとに渡す」「返答の形を先に固定する」系と被らないよう、今回は“会話の記憶を保ちながら運ぶ”ことに寄せている。
会話の節目で前提を 1 行に圧縮する
会話が長くなるほど、前提を抱えたまま走るのが一番だるい。Claude Code にも人間にも通じないまま話が進むと、あとで「それは最初に言ってほしかった」が必ず出る。そこで効くのが、要点の一文化、文脈サマリ、ミニ要約だ。節目ごとに前提を 1 行へ圧縮して差し込むだけで、指示のズレと手戻りがかなり減る。
https://papoo.work/doc/2bb33a10315ac589
長い依頼の冒頭に、今の状態を短く書き出す
長い依頼でいちばん雑に扱われがちなのは、実は“今の状態”だ。 ここを省くと、Claude Code は毎回まっさらな気分で読み始める。こちらは「前提くらい分かるだろ」と思っているのに、向こうから見ると肝心の足場が見えていない。結果、手戻りが増える。地味だが、かなりだるい。
https://papoo.work/doc/a8e1cfe2c7df1159
Claude Code に判断理由を残させて、後から迷いどころを追えるようにする
Claude Code に作業だけさせて、あとから「なんでそこを触ったんだ」と首をかしげる。これ、かなりありがちな落とし穴だ。差分はきれいでも、判断の筋道が残っていないと、少し時間がたっただけで修正の意図が追えなくなる。結果、同じ迷いをもう一度やる羽目になる。
https://papoo.work/doc/622bb775053f75a2
調べた結果をその場で短く要約させて、次の指示に渡す
調べっぱなしで終わると、Claude Code は平気で長文を抱えたまま次の仕事に入る。そこが雑だと、あとで「あれ、さっき何を見つけたんだっけ」となる。 そこで使うのが、その場で短くまとめさせてから次の指示に渡すやり方だ。調査サマリ、中間要約、引き継ぎメモ、と呼び方は何でもいいが、やることは同じである。見つけた事実だけを短く圧縮して、次の判断材料に変える。
https://papoo.work/doc/963a50a0dc4859af
会話が長引く作業は、章立てより先に節目を決める
長い依頼ほど、いきなり章立てを作る人が多い。だが、そこがだるい罠だ。Claude Code に会話が長引く作業を任せるなら、先に決めるべきなのは章ではなく節目である。区切り設計、マイルストーン、進行の節目。呼び方は何でもいいが、要は「どこで止めるか」を先に固定する発想だ。
https://papoo.work/doc/ae5b01796ebaa46f
Claude Code に持たせるメモは短く、決定事項だけに絞る
長いメモを残して「あとで Claude Code が全部わかるはず」と思うと、だいたい逆に詰まる。 ここで効くのは、短い作業メモを残し、決定事項のみを書き、余計な経緯は落としていくやり方だ。要するに、コンテキスト圧縮である。Claude Code に渡す情報は、議事録ではない。次の一手を迷わないための手がかりだけでいい。
https://papoo.work/doc/599c089ca1b2ab78
長文の下書きを最後にまとめ直して、引き継げる形に整える
長く書き散らしたあとに、そのまま投げるのは雑すぎる。しかも、本人には読めるのに他人には使えない、いちばん厄介な形になりやすい。そこで効くのが、仕上げの再編集、全体の整形、引き継ぎ用まとめだ。Claude Code を使うなら、最後にこれを一回かけるだけで、下書きが「自分のメモ」から「他人が次に動ける文」に変わる。
https://papoo.work/doc/e5a01bde4c62b999
作業ログから、迷った地点だけを次回の依頼テンプレに戻す
作業ログを全部テンプレに戻すのは、だいたい雑だ。しかも重い。次回に残すべきなのは「うまくいった手順」より、むしろ「そこで迷った」「判断に時間がかかった」「指示があいまいで手戻りした」地点だけである。ここを戻すと、ログの再利用、失敗の抽出、テンプレ改善が一気に実用になる。
https://papoo.work/doc/38aa358d773a30d4
再現しなかった失敗と、たまたま起きた失敗を分けて記録する
雑に「失敗した」で片づけると、Claude Code はだいたい同じところをまた踏む。そこがまずい。再現しなかった失敗と、たまたま起きた失敗を混ぜて書くと、原因がぼやける。失敗の切り分け、偶発エラーの整理、再現性の判定を先にやるだけで、次の指示がかなり鋭くなる。
https://papoo.work/doc/aae1b3fac9c6b73b
Claude Code に触らせる作業場所を先に設計し、本流を汚さずに試作・比較・片付けまで回すためのクラスタ。リポジトリ内の置き場、別ディレクトリ、試作品と確定版の分離、並走案件の衝突回避、終了後の整理をまとめて扱う。開発だけでなく、文書作成やファイル整理でも効く、かなり実務寄りの土台づくりだ。
案件ごとにディレクトリを分けて後から迷子にならない
ひとつの場所に何でも放り込むと、あとで必ず探し物ゲームになる。Claude Code を使うなら、案件ごとにディレクトリを掘る、つまり最初から案件単位でフォルダを切っておく運用にしたほうがいい。後から探しやすくするだけでなく、指示の混線も減るし、差分も見やすい。地味だが、ここを雑にすると手戻りがいちばん痛い。
https://papoo.work/doc/9212238eacdb46e2
引き継ぎやすい状態で終える
雑に閉じると、次の Claude Code がいきなり鈍る。これは思った以上に効く。 「次回の Claude Code が速くなる終わり方」とか「作業フォルダの後始末」と呼んでもいいが、要するに、いまの作業を“次の一手が打ちやすい形”に整えてから離席する、という話だ。
https://papoo.work/doc/d524b6e8dea72c08
Claude Code の作業場所と会話の切り方を整えて、並走・試作・引き継ぎを安定させるための TIPS クラスタである。リポジトリをまたぐ事故、コンテキストの浪費、途中で前提が崩れる手戻りを減らす観点でまとめる。
案件ごとにディレクトリを分けて、後から迷子にならない
案件を1つの場所に雑に押し込むと、あとで自分が探す側になる。これ、かなりだるい。Claude Code を使うときも同じで、案件ごとにディレクトリを分ける、いわゆる案件単位のフォルダ分離をしておかないと、指示・出力・メモ・成果物が混ざってすぐ迷子になる。
https://papoo.work/doc/1efb13b0f629d0eb
Claude Code に長い作業を任せるとき、文脈の持たせ方・作業場所の切り方・途中経過の返させ方を整えて、迷子と手戻りを減らすためのクラスタである。単発の頼み方ではなく、長時間の作業を安定して走らせる運用に寄せる。
Claude Code に渡す情報は、最初に「材料」と「判断基準」に分ける
雑に「これやって」で投げると、Claude Code はだいたい余計なものまで触る。そこが一番もったいない。 Claude Code に仕事を渡すときは、最初に「材料」と「判断基準」を分ける。別名で言えば、最初に使う材料と使わない材料を分けて渡す、である。これをやるだけで、コンテキストの浪費が減るし、手戻りも減る。ファイル整理でも、コード修正でも、文章作成でも効く。むしろ非エンジニアの作業ほど効く。
https://papoo.work/doc/0f40ff60d48d1dc4
長い依頼は章立てより先に節目を決める
長い依頼をいきなり章立てで整えようとすると、だいたい途中で崩れる。章の名前を先に決めること自体は悪くないが、Claude Code に投げる相手が長い会話になるなら、先に決めるべきは「どこで止めて、何を要約させるか」だ。別名で言うと、会話が長くなったら節目で要約させる、である。
https://papoo.work/doc/96dfc5e571d0c34c
途中要約を挟ませて、前提のズレを止める
長い会話ほど、相手はちゃんと理解しているふりをする。Claude Code でもここが地味に危ない。 途中で要約を一回挟まないと、最初の前提が少しずつずれて、最後には「思ってたのと違う」が出来上がる。これ、コード修正でもファイル整理でも文書作成でも同じだ。
https://papoo.work/doc/abd80f9494678f59
途中報告の頻度を先に決めて、黙って進みすぎないようにする
Claude Code を使うと、気持ちよく進みすぎることがある。そこが落とし穴だ。黙々と走らせたあとで、最後に「違う、そうじゃない」となる。あれはだいぶだるい。
https://papoo.work/doc/4588069ef8c23018
作業中に持たせるメモは短く、決定事項だけに絞る
長い指示を書けば、Claude Code が賢くなると思っているなら、そこがまず勘違いだ。たいていは逆で、メモが長いほどノイズが増えて、あとで自分が困る。持たせるメモは短くする。この雑なほど効くやり方が、作業中の手戻りをかなり減らす。
https://papoo.work/doc/d8713a8802cbf842
作業ログを見返して、Claude Code が迷った地点を次回に生かす
Claude Code に雑に丸投げして、「なんか遠回りしたな」で終わらせるのはもったいない。そこで止めると、次回も同じ場所で迷う。作業ログを見返す、迷った地点を次回に生かす。ここまでやって初めて、CLI のエージェントはただの便利ツールから、だんだん手癖の合う相棒になる。
https://papoo.work/doc/7f313670961670b7
Claude Code の出力と作業の進め方を先に整えて、長い会話でも前提を保ち、返答の暴れや迷子を減らすための TIPS クラスタ。作業ログ、要約、出力形式の固定、途中報告の設計をまとめて扱う。
途中報告の頻度を決めて、黙って進みすぎないようにする
Claude Code でありがちな失敗は、こちらが「ちょっと整えて」と言っただけなのに、気づいたら深いところまで掘り進んでいて、最後にまとめて見せられることだ。これ、気持ちはわかるが、後から戻すのがだるい。ファイル整理でも文書作成でも同じで、途中で一回止めてくれないと、方向がずれていても気づけない。
https://papoo.work/doc/bfbf601c96b71a62
Claude Code に渡す情報量、出力の形、途中報告の粒度、作業の終わらせ方を先に整えて、長い会話や大きい依頼でも迷子になりにくくするためのクラスタである。曖昧さを減らしつつ、返答の暴れを抑え、要約・節目・引き継ぎまで含めて作業を安定させる TIPS をまとめる。
作業ログを見返して、迷った地点だけを次回の依頼テンプレに戻す
雑に丸ごとテンプレ化すると、次回も同じところで詰まる。そこ、かなりもったいない。 Claude Code を使った作業は、全部をテンプレにするより、迷った地点だけを回収して次回の依頼に戻すほうが強い。振り返りからテンプレ改善、ログを次回依頼に活かす、という流れだ。ログを全部コピーしても、たいていノイズが増えるだけである。
https://papoo.work/doc/7d5275e2d82b950d
Claude Code に触らせる作業範囲を、ディレクトリ・ブランチ・試作置き場の切り分けで管理する TIPS 群。差分の衝突や本流の汚れを防ぎ、並走実験や引き継ぎをやりやすくする観点に寄せる。
同じファイルを同時に触らせないだけで、コンフリクトはかなり減る
コンフリクトが多い人のやりがちな勘違いは、「Claude Code が賢ければ、同じ場所を複数の作業で触っても勝手にうまくやるはず」だ。そこ、かなり危ない。 実際は、同じファイルを同時に触らせないだけで、競合を避ける、同時編集を避ける、という基本がかなり効く。しかもこれは開発だけの話ではない。文書整理でも、請求書まわりでも、写真の整理でも、ひとつのファイルを別タスクが横取りしないだけで手戻りが目に見えて減る。
https://papoo.work/doc/0a0651980f320a36
Claude Code に長くなりがちな作業を任せるとき、返答の形・分量・途中報告・要約の入れ方を先に決めて、出力の暴れと前提の崩れを抑えるためのクラスタである。長文の調査、章ごとの下書き、複数の判断が混ざる作業、非エンジニアの整理作業にもそのまま効く。
返答を短くさせるなら、分量の上限を先に決める
「短くして」とだけ頼むと、だいたい長い。これ、Claude Code でも同じだ。 返答を短くさせたいなら、最初に分量の上限を決める。出力の分量制御とか回答の長さ指定は、後から気分で足すより、先に枠を切ったほうが効く。
https://papoo.work/doc/553ef073f00594f1
Markdown か表かを先に決めると、返答が暴れない
Claude Code に雑に頼むと、まず返答の形がブレる。文章でほしいのに箇条書きが増えたり、表でほしいのに説明が長くなったりする。中身以前に、器が決まっていないのが原因だ。ここを先に固定すると、出力形式の指定が効いて、成果物の形を固定するだけで手戻りがかなり減る。
https://papoo.work/doc/bee28c3eaa4ce8ca
節目で要約を挟ませて、長い会話でも前提を保つ
長い依頼を一気に投げて、そのまま最後まで突っ走らせると、だいたいどこかで前提がにじむ。Claude Code は優秀だが、会話が長くなるほど「いま何を守るべきか」がぼやける。そこで効くのが、途中要約、つまり会話の節目で要約するやり方だ。
https://papoo.work/doc/0f91a6df65476870
材料は章ごとに渡して、一気読み前提をやめる
Claude Code に長文を丸ごと投げて、全部を一度に飲み込ませようとする人は多い。だがそれ、だいたい途中で雑になる。 分割投入、つまり章分けして渡すやり方に変えるだけで、指示の通りやすさがかなり変わる。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。最初から全部を読ませるより、章ごとに材料を渡したほうが、何を直せばいいかがはっきりする。
https://papoo.work/doc/40687e5c17ca3925
Claude Code との長いやり取りで前提を崩さず、会話・作業・出力の境目を設計するためのクラスタ。セッションを切る、要約を挟む、途中報告の粒度を決める、出力の形を固定する、といった「長引くほど効く」運用をまとめる。開発だけでなく、長文作成や資料整理、複数案件の下書きにも効く。
Claude Code に判断理由を残させて、あとから迷いどころを追えるようにする
Claude Code を使っていて厄介なのは、作業そのものより「なぜそうしたか」が消えることだ。あとで差分だけ見ても、削除した理由、残した理由、別案を捨てた理由が見えない。これが積み重なると、作業は進んでいるのに自分だけが置いていかれる。
https://papoo.work/doc/b0ef442d9af70798
Claude Code に渡す情報量と会話の流れを整えて、長い作業でも前提のズレやコンテキスト浪費を起こしにくくするための TIPS クラスタ。調べ物、要約、節目の確認、材料の削り方までをひとまとまりで扱う。
長い依頼は最初に節目を決める
長い依頼を、いきなり全文で投げる人はだいたい損をする。Claude Code は長文でも読めるが、読めることと、うまく進むことは別物だ。 最初に「節目を先に決める」、つまり区切りを先に置く。ここをやるだけで、途中の迷走と手戻りがかなり減る。
https://papoo.work/doc/2d8ded53d2199a8b
Claude Code に渡す材料は最初に「材料」と「判断基準」に分ける
Claude Code に雑に全部投げると、だいたい雑に返ってくる。これは性格の問題ではなく、入力の置き方が悪いだけだ。 「材料と判断基準を分ける」「入力を分離する」と先に決めておくと、Claude Code はかなり扱いやすくなる。ファイル整理でも、ディスク削減でも、文書作成でも同じだ。何を見せるかと、何を基準に選ばせるかを混ぜない。ここを分けるだけで、手戻りが露骨に減る。
https://papoo.work/doc/73e2178513c084f2
Claude Code の出力を思いどおりの形にそろえるための TIPS クラスタ。返答の長さ、粒度、途中報告、要約、成果物形式、判断理由の残し方をまとめて扱い、長い会話や複数工程でも迷子にならない頼み方を学べる。開発用途だけでなく、文書作成やファイル整理のような非エンジニア作業にもそのまま効く。
Claude Code に最初に出力形式を決めさせる
いきなり作業を始めさせると、あとで「やっぱり表で」「いや箇条書きで」と差し戻しが入る。あれは地味にだるい。Claude Code は、最初に返答の形を固定してから動かすだけで、手戻りがかなり減る。Markdown か表かを先に決める、返答の形を固定する、というやり方だ。
https://papoo.work/doc/acd512725cd934c2
長い資料は章ごとに渡す：一気読み前提をやめる
長い資料をそのまま丸投げして、Claude Code が全部を一気に飲み込む前提で話を進める。これ、かなり雑だ。章ごとに渡したほうが早いし、手戻りも減る。資料を分割して渡す、章ごとに入力する。呼び方は何でもいいが、やることは同じである。
https://papoo.work/doc/6bd4e5bf4c83f64f
Claude Code に判断理由を残させる
Claude Code に作業だけさせて、なぜその手を選んだのかを残さない。これ、あとで地味に困る。ファイルがどう変わったかは diff で見えるが、迷いどころや採用理由は消えるからだ。判断根拠を残す、迷いどころを記録させる、という使い方を入れておくと、あとで見返したときに「なんでこの構成にしたのか」「なぜこの重複を消したのか」が追える。
https://papoo.work/doc/8fc0cd6e75f271cd
Claude Code に長い作業や複数案件を扱わせるとき、作業場所の切り方、下書きと確定版の分離、終わったあとの片付け、引き継ぎやすい状態の作り方をまとめるクラスタである。変更の衝突を避けつつ、本流の文脈を汚さず、あとから見返しても迷子になりにくい運用に焦点を当てる。
Claude Code に触らせる作業フォルダを先に決める
Claude Code に「とりあえず全部見ておいて」は危ない。雑に広い場所で動かすと、余計なファイルまで巻き込み、指示も散る。まずやるべきは、作業フォルダの固定、つまり触らせる範囲を狭めることだ。
https://papoo.work/doc/098e30adefd93f99
Claude Code の返答や途中経過、要約の出し方を先に決めて、長いやり取りでも前提と成果物の形を崩さず進めるための TIPS 群。指示の出し方より一段下の「出力制御」に寄せるので、既存の依頼テンプレや作業分割の記事と重ならず、実務での手戻り削減に直結する。
返答の形式を先に固定する
Claude Code で地味に効くのに、みんな後回しにするのがこれだ。 最初に「Markdown で返すのか、表で返すのか」を決めないまま投げると、あとで整形し直す羽目になる。内容は合っているのに、出力がバラけていてそのまま使えない。あれはかなりだるい。
https://papoo.work/doc/cc13f04c9c000e8b
返答の長さに上限をかける
Claude Code に雑に投げて、返ってきた返答が長すぎて読む気を失う。これ、かなりありがちな失敗だ。分量を絞る、短く要約させる、そういう指定を先に入れておかないと、こちらの意図よりも「丁寧さ」が勝ってしまい、出力がだらっと伸びる。
https://papoo.work/doc/41bbe16de65c626b
長い会話は節目ごとに要約を挟む
長文の依頼を一気に投げて、そのまま最後まで走らせる。これ、かなりの確率で手戻りになる。Claude Code は賢いが、会話が長くなるほど前提が散り、途中で「どの話を軸にしていたか」がぼやけるからだ。そこで効くのが途中要約、つまり前提の圧縮である。
https://papoo.work/doc/06ee216403a50cb6
作業の終わり方を先に決める
作業がだれる人は、始め方より終わり方が雑だ。これを決めずにClaude Codeを走らせると、修正がだらだら伸びる。diffは太り、指示はあいまいになり、最後の数回でいちばんコンテキストを食う。そこで先に「止まりどころを指定する」「出口条件を明示する」。要するに、どこで手を止めるかを先に決めておく話だ。
https://papoo.work/doc/ea2d1d73192d5f2f
調べた結果をその場で短く要約させて次に渡す
検索しただけで満足して、長い出力をそのまま次の作業に持ち込むと、だいたい後で詰まる。ログも、記事の下書きも、調査メモも、全部そのままだと長すぎるのだ。 Claude Code は、調べた内容をその場で短く圧縮して、次の指示に渡すのがうまい。ここでいう圧縮は、雑な要約ではない。必要な論点だけを抜き出して、次の作業で扱える密度に落とすことだ。調査メモ、検索結果の圧縮、と呼んだほうが通りがいい場面もある。
https://papoo.work/doc/4ef3a13356f13aa2
会話が長引く前に前提を 1 行で書き出す
会話がぐだるのは、相手が悪いからではない。前提を言葉にしていないからだ。 Claude Code に頼みごとをするときも同じで、いきなり「これ直して」「整理して」「要約して」と投げると、返ってくるものが妙に広がる。修正対象が曖昧なまま進むので、途中で「いや、そうじゃない」と戻す羽目になる。これは開発でも文書作成でもファイル整理でも同じだ。先に前提を 1 行で置くだけで、会話の往復がかなり減る。
https://papoo.work/doc/1fd8153f69fc8373
作業ログから迷った地点だけを次回の依頼に戻す
作業ログを丸ごと次の依頼に貼るのは、だいたい無駄だ。しかも、長いログほど Claude Code の思考を散らす。必要なのは全部ではなく、迷った地点だけである。ここを切り出すやり方は、振り返りテンプレにもなるし、迷いポイントの抽出としても使える。
https://papoo.work/doc/a83807daa9aa804c
Claude Code に長い材料を渡すとき、コンテキストを食い潰さずに進めるための実践クラスタだ。章ごとに渡す、途中で要約させる、判断理由を残す、最後に引き継ぎ形へ圧縮する、という流れをまとめて扱う。作業が長引くほど前提がずれ、返答がだらけ、あとから何を判断したか追えなくなる。そこを防ぐための、会話の設計と情報の削り方に絞った TIPS 群である。
材料は章ごとに渡す：一気読み前提をやめる
Claude Code に長文をそのまま放り込んで「読んでおいて」は、だいたい雑に詰む。こちらは一気に片づく気がするが、実際は途中で論点がぼやけたり、条件を落としたり、出力が妙に広がったりする。分割投入、つまり長文を分けて渡すやり方に切り替えると、この手のムダがかなり減る。
https://papoo.work/doc/2ddd5a37dfd7b7a8
Claude Code の出力の形、途中報告、要約、判断理由の残し方を整えて、長い依頼でも前提が崩れないようにするためのクラスタである。作業を進めながら迷子になりやすい人、返答が長すぎたり暴れたりして困っている人、あとから引き継げる記録を残したい人に向く。依頼文そのものの設計に寄った TIPS をまとめる。
返答の形式を先に固定する：Markdown か表かを決めてから頼む
雑に頼むと、Claude Code はちゃんと働くのに、返ってきたものが使いにくい、という事故が起きる。中身は合っているのに、Markdown で欲しかったのに段落の羅列だったり、表で一発整理したかったのに長文で返ってきたりするやつだ。 ここで先にやるべきなのは、出力形式を先に決めることだ。Markdown か表かを指定しておく。たったそれだけで、返答の形が安定するし、あとからコピペして文書に流し込みやすい。
https://papoo.work/doc/bf3c3ab4fa0d1ebe
Claude Code の出力を途中で迷わせず、最後まで使える形に整えるためのクラスタ。長文依頼や調査、修正、引き継ぎまで、返答の長さ・形式・節目を先に決めることで手戻りを減らす TIPS をまとめる。既存の「依頼の粒度」や「作業場所の分離」系とはずらし、出力そのものの整え方に寄せる。
作業ログを見返して、迷った地点だけを次回の依頼に戻す
Claude Code を使っているのに、次の依頼文が毎回まっさらなのはもったいない。 全部を覚えておく必要はない。むしろ、迷った地点だけを拾って次回に戻したほうが速い。これが「迷いどころを次回に戻す」「作業ログから改善点を拾う」という考え方だ。
https://papoo.work/doc/a50d0cb0de421761
その他
Sonnetがついに「Opusでいいじゃん」って言われ始めた件、実際どうなのか集めてみた
2026年6月末にSonnet 5が出て以来、あちこちで「もうOpusいらないんじゃないか」という声を見るようになった。正直、この手の「新型は前世代を食う」論は毎回出てくるので話半分に聞いてたんだけど、今回は言ってる人の顔ぶれが違う。エンタープライズの導入事例から個人ブロガーの生々しい愚痴まで、実際にClaude Codeで両方回した人たちの声を拾ってみたら、思ったより解像度の高い話が出てきたので整理する。
https://papoo.work/doc/e16269f0eca66047
で、CLAUDE.mdで英語で書かせるのと日本語で書かせるの、どっちが良いの？
結論から言うと、どっちでもいい。日本語で書いて全然問題ない。 ネットで「CLAUDE.mdは英語が正義」みたいなの見るけど、あれ半分は雰囲気で言ってるだけだと思う。Claude は普通に日本語の指示を読むし、ちゃんと従う。「英語じゃないと精度ガタ落ち」みたいなことは起きない。
https://papoo.work/doc/60ecfd7f495a7794
TIPS は随時追加していく。全記事の一覧は PaPoo のプロフィール（https://papoo.work/u/claudecodejp）から見られる。