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