本文へ移動
Claude Tips

Tips 集

Claude Code をうまく使うコツを、確かめ方・頼み方・セッションの扱い・並列化・コストの抑え方・よくある失敗に分けて短くまとめました。

公式ドキュメントのベストプラクティスとコスト管理の案内から、すぐ試せるコツを集めました。各項目の詳しい説明はリンク先のページにあります。

確かめる手段を渡す#

Claude が自分で走らせられるチェックを用意する#

テスト・ビルド・リンター・スクリーンショットとの比較など、成否が分かるものを渡すと、Claude は「作る → 走らせる → 結果を読む → 直す」を自分で回せます。チェックが無いと、間違いに気づく役が自分に回ってきます。

text
validateEmail 関数を書いて。user@example.com は true、invalid は false、user@.com は false になること。書いたらテストを走らせて。

止めどころの固さを選ぶ#

  • 1回の指示の中で「チェックを走らせて、通るまで直して」と頼む
  • セッションを通して守らせるなら /goal の条件にする（別の評価役が毎ターン確かめる）
  • 機械的に止めたいなら Stop フック でチェックを走らせ、通るまでターンを終わらせない
  • 別の目で見るなら、検証用の サブエージェント や ワークフロー に結果を崩させる

ヒント

「できました」と言わせるより、テストの出力・実行したコマンドと結果・スクリーンショットなどの証拠を出させるほうが、確かめ直すより早く見られます。

頼み方#

調べる → 計画する → 実装する → コミットする#

いきなり書かせると、違う問題を解いたコードができることがあります。Shift+Tab でプランモードにして調べさせ、計画を出させてから実装に移ります。計画は Ctrl+G でエディタに開いて直せます。

補足

1文で言える小さな修正（誤字・ログの追加・名前の変更）なら、計画は飛ばしてそのまま頼むほうが早いです。計画が効くのは、やり方に迷うとき・複数のファイルにまたがるとき・知らないコードを触るときです。詳しくは 権限モード。

具体的に頼む#

ファイル・場面・テストの方針を指定する、答えのある場所（git の履歴など）を示す、真似てほしい既存のコードを名指しする、症状と「直った」の状態を書く。この4つで、直しのやり取りが減ります。

文脈は直接渡す#

  • 場所を説明する代わりに @ でファイルを指す
  • 画像は貼り付けかドラッグで渡す
  • ドキュメントの URL を渡す（よく使うドメインは /permissions で許可しておく）
  • cat error.log | claude のようにパイプで渡す

大きな機能は先に聞き取りをさせる#

最小限の説明だけ渡し、AskUserQuestion ツールで詳しく聞き取ってから仕様を SPEC.md に書くよう頼みます。仕様ができたら、新しいセッションで実装させると文脈がきれいなまま進められます。

環境を整える#

CLAUDE.md は /init で作って短く保つ#

/init がプロジェクトの構成からひな形を作ります。長すぎる CLAUDE.md は大事な規則が埋もれて守られにくくなるので、指示が無くてもできていることは消すか、フック にします。詳しくは CLAUDE.md とメモリ。

特定の作業の手順はスキルへ移す#

CLAUDE.md は毎回読み込まれるので、PR のレビューや DB の移行のような特定の作業の手順は、使うときだけ読まれる スキル にすると文脈を食いません。

セッションの扱い#

ずれたらすぐ止める#

Esc で止めても文脈は残るので、そのまま言い直せます。Esc を2回か /rewind で、会話やコードを前の時点へ戻せます（チェックポイントと巻き戻し）。

注意

チェックポイントが追うのは Claude のファイル編集ツールによる変更だけです。Bash のコマンドやほかのプロセスが変えたものは戻せないので、git の代わりにはなりません。

同じことを2回直して駄目なら /clear#

失敗したやり方が文脈にたまっています。学んだことを入れた、より具体的なプロンプトで新しく始めるほうがうまくいきます。関係の無い作業に移るときも /clear で切り替えます。

要約に残すものを指定する#

/compact Focus on the API changes のように、何を残すかを添えて要約できます。CLAUDE.md に「要約するときは変更したファイルの一覧とテストのコマンドを必ず残す」のように書いておくこともできます。詳しくは コンテキストとプロンプトキャッシュ。

脇の質問は /btw#

答えが会話の履歴に入らないので、ちょっとした確認で文脈を増やしません。

調べものはサブエージェントに任せる#

「サブエージェントを使って X を調べて」と頼むと、別の文脈で大量のファイルを読み、要約だけを返します。本筋の文脈を実装のために空けておけます（サブエージェント）。

セッションに名前を付けてブランチのように使う#

/rename で名前を付けておくと、claude --resume の一覧で探しやすくなります。前回の続きなら claude --continue（セッションの再開と管理）。

並列と自動化#

書く役と見る役を分ける#

あるセッションで実装させ、別の新しいセッションにレビューさせると、書いたばかりのコードへの思い込みが入りません。テストを書く役とそれを通すコードを書く役に分けるのも同じ考え方です。並べ方は 並列作業の選び方、ファイルがぶつからないようにするには worktree で並行作業。

大きな一括変更は /batch か claude -p のループ#

/batch <指示> は変更を5〜30のサブエージェントに分け、それぞれを専用の worktree で進めます。自分のスクリプトで回すなら、対象のリストを作らせてから claude -p をループで呼び、--allowedTools で使えるツールを絞ります。最初の2〜3件で指示を直してから全件に流します。

bash
for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

詳しくは ヘッドレス実行（-p）。

長い作業は auto mode#

claude --permission-mode auto は、実行の前に判定用のモデルがコマンドを確かめ、危ないものだけを止めます。確認の手間を減らして長い作業を任せられます（権限モード）。

終わりにする前に別の目でレビューさせる#

/code-review は新しいサブエージェントで今の差分のバグを探します。計画と照らしたいなら「サブエージェントで差分を PLAN.md と照らし、抜けを報告して」と自分で頼みます。

ヒント

抜けを探すよう頼まれたレビュー役は、問題が無くても何かを挙げがちです。正しさや要件に関わるものだけを挙げさせ、それ以外は任意の扱いにすると作り込みすぎを防げます。

コストを抑える#

やること 効き方
/usage を見る・ステータスライン に出す どれだけ使っているかが分かる
関係の無い作業の前に /clear（先に /rename） 古い文脈を毎回送らずに済む
普段は Sonnet、難しい設計や多段の推論だけ Opus Sonnet のほうが安い（モデル・effort・fast mode）
gh・aws・gcloud などの CLI を MCP より優先する。使わない MCP サーバーは /mcp で切る CLI はツールの一覧を文脈に足さない（MCP サーバーをつなぐ）
型のある言語は コードインテリジェンスのプラグイン を入れる 定義へのジャンプで、grep と何ファイルもの読み込みを減らせる
長いログはフックで絞ってから渡す 何万トークンを数百トークンにできる（フックの使い方）
単純な作業では /effort を下げる 思考のトークンは出力として課金される
テストの実行やログの処理はサブエージェントへ 長い出力が本筋の文脈に入らない
曖昧な「良くして」より、場所と中身を指定する 広い走査をさせずに済む

補足

エージェントチームは、チームメイトがプランモードで動くと通常のセッションのおよそ7倍のトークンを使うと公式は案内しています。チームの作業は小さく分けます（エージェントチーム）。詳しくは コストを抑える。

よくある失敗#

失敗 直し方
1つのセッションで関係の無い作業を行き来する 作業の間に /clear
何度も直させて、文脈が失敗したやり方で埋まる 2回直して駄目なら /clear し、学んだことを入れて頼み直す
CLAUDE.md が長すぎて半分が無視される 削る。指示が無くてもできていることは消すかフックにする
もっともらしいが端の場合を扱っていない実装をそのまま使う テスト・スクリプト・スクリーンショットで必ず確かめる
範囲を決めずに「調べて」と頼み、何百ものファイルを読ませる 範囲を絞るか、サブエージェントに調べさせる

ここに無いコツは 上手に使うコツ と よくある作業の進め方 にもあります。

ページの一覧