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
その他
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）から見られる。