Claude Media
Claude Codeの生産性を上げる小技12選 — 場面別の使い方

Claude Codeの生産性を上げる小技12選 — 場面別の使い方

Claude Codeで応答が鈍る、調査が散らかる、手作業が繰り返される場面に効く12の小技を、/clear・サブエージェント・Hook・worktree.baseRefの仕様に沿って示します。

このTipsでできること

Claude Codeを使っていて「応答が鈍ってきた」「調査の出力で会話が埋まった」「同じ手作業を毎回している」と感じたとき、手元ですぐ試せる12の小技を並べます。どれも数秒から数分で入れられる小さな変更です。Claude Codeの使い方全体を先に知りたいときは、そちらから読めます。小技ごとに、どの場面で効くかと、公式仕様のどこに根拠があるかを添えました。

選び方の目安は次のとおりです。

今の困りごと試す小技
会話が長くなって精度が落ちた試す小技1・2・3・4
調査や並列作業で会話が埋まる試す小技5・6・7
同じ手作業・確認作業が繰り返される試す小技8・9・10
ブランチ・マージの運用で事故を減らしたい試す小技11・12

会話が長くなって精度が落ちたとき

1. /clear を計画的に挟む

無関係な作業を同じ会話で続けると、不要な情報がコンテキストに残ります。公式のベストプラクティスも、関連のない作業のあいだに /clear で文脈をリセットするよう勧めています。長いセッションに無関係な内容が残ると性能が落ちうる、という説明です。

/clear は空のコンテキストで新しい会話を始めるコマンドで、/reset と /new が別名です。名前を渡して /clear 認証修正 のように実行すると、直前の会話がその名前で /resume の一覧に残ります。消した会話は /resume で戻せます。同じプロセス内なら、rewindメニューの前セッションの項目からも復元できます。

同じ会話を続けたまま軽くしたいときは、/compact で会話を要約します。使い分けは、作業が切り替わるなら /clear、同じ作業の途中なら /compact です。今どれだけ埋まっているかは /context で見られます。状態を引き継ぐ手がかりはgit logやTODOに残しておくと安心です。詳細はClaude Codeが期待通りに動かない10シナリオのシナリオ1を参照してください。

2. 大きなファイルは検索してから範囲を指定して読む

ファイル全体の読み取りがトークン上限を超えると、Read は先頭の1ページだけを返し、PARTIAL view という通知で「どこまで読めたか」と「続きを offset と limit で読む方法」を伝えます。全文を一度に取り込む設計ではないので、読む前に場所を絞るほうが無駄がありません。

macOS・Linux・WSLでは、Grep と Glob は既定のツールセットに入っておらず、ClaudeはBash経由の grep や find で検索します。そのため「Grep を先に使う」と覚えるより、依頼文で手順を指定するほうが確実です。たとえば次のように書きます。

src/billing.ts のうち請求額を丸める処理だけを知りたいです。
まず該当する関数を検索で見つけ、その周辺の行だけを読んで説明してください。

3. CLAUDE.mdは200行を目安に保つ

CLAUDE.mdは毎セッション開始時に読み込まれるので、長くなるほど毎回のコンテキストを消費します。公式は1ファイル200行以内を目標にしており、それより長いファイルは多くのコンテキストを使い、指示への従い方が落ちることがあると説明しています。

行数を減らす手段は、置き場所を変えることです。複数手順の作業や、コードベースの一部でしか意味を持たない指示は、スキルかパス指定のルールに移します。ルールは該当するファイルを扱うときだけ読み込まれ、スキルは呼び出したとき、または関連すると判断されたときに読み込まれます。@path でファイルを取り込む方法は、整理には役立ちますが、取り込んだファイルも起動時に読まれるため、コンテキストは減りません。3つの置き場所の使い分けはClaude Code memoryの三層構造にまとめています。

4. 1セッション1目的に絞る

公式ベストプラクティスは、よくある失敗の一つに「何でも入りのセッション」を挙げています。1つの作業を始め、無関係な質問を挟み、また元の作業に戻ると、コンテキストが無関係な情報で埋まります。対処は、無関係な作業のあいだで /clear することです。

別々の作業を並べたいときは、/clear の代わりに別のセッションを立てる手もあります。claude -w(--worktree)は作業ツリーごと分けたセッションを作り、claude --bg はバックグラウンドで動くセッションを作ります。v2.1.287の claude --help には次のように出ます。

-w, --worktree [name]   Create a new git worktree for this session (optionally specify a name)
--bg, --background      Start the session in the background and return immediately.
                        Prints the id that `claude attach`, `logs`, `stop` and `rm` take;
                        `claude agents` lists them.

「リファクタ」「新機能」「テスト整備」のように目的が違う作業は、セッションを分けるだけで互いの文脈が混ざらなくなります。

調査や並列作業で会話が埋まるとき

5. 重い調査はサブエージェントに隔離する

「リポジトリ全体をスキャンして」「過去のPRをまとめて読んで」のような作業は、メインの会話で直接やると検索結果やログでコンテキストが埋まります。サブエージェントは自分専用のコンテキストで作業し、要約だけを返します。

起動に使うツールの名前は Agent です。古いバージョンのchangelogには Task という名前で出てきますが、現在のツール一覧では Agent になっています。コードベースの検索や理解には、読み取り専用の組み込みサブエージェント Explore が使われます。Explore はCLAUDE.mdとgit statusのスナップショットを読まずに動くため、軽く速く調べられる設計です。

手順

調査を切り離す流れ

  1. 1

    依頼文でサブエージェントを指定する

    「サブエージェントでテストを実行し、失敗したテストとエラーだけ報告して」のように、何を返してほしいかまで書きます。

  2. 2

    サブエージェントが自分のコンテキストで作業する

    検索結果やログは、サブエージェントのコンテキストに溜まります。メインの会話には載りません。

  3. 3

    要約だけがメインに戻る

    結果が戻るのはここです。返ってくる内容が長いと、その分はメインのコンテキストを使います。

詳しい使い分けはサブエージェント完全活用で扱っています。

6. 独立した作業は並列に起動する

互いに依存しない調査は、同時に走らせられます。公式の例は「認証・データベース・APIの各モジュールを、別々のサブエージェントで並列に調べて」という依頼です。経路が互いに依存しない場合に向いた方法です。

注意点が2つあります。1つ目は、並列にするとトークンも並列で使う点です。サブエージェントは自分のリクエストを送り、メインの会話と同じ使用量の上限に数えられます。2つ目は、サブエージェントが会話履歴も、すでに読んだファイルも引き継がない点です。担当するファイルやディレクトリは、依頼文に明記します。

同時に動かせる数は、既定で20です。20に達した状態でさらに起動すると Concurrent subagent limit reached のエラーで失敗し、Claudeには再試行しないよう伝わります。上限は環境変数 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS で変えられ、この仕組みはv2.1.217以降のものです。ultracode(/effort ultracode で有効にする、Claudeが実質的な作業ごとにワークフローを計画するモード)を有効にしたセッションには、この上限は適用されません。

7. 長時間のコマンドはバックグラウンドで走らせる

開発サーバーや監視ビルドのように終わらないコマンドを、そのまま実行させると会話が止まります。Bashコマンドにはタイムアウトがあり、Claudeが指定しなければ既定は2分、上限は既定で10分です。上限を超えて固まり続けるわけではなく、期限で打ち切られます。

終わらないプロセスには run_in_background: true が使われます。コマンドがバックグラウンドタスクとして起動し、Claudeは作業を続けられます。進行中のタスクの一覧と停止は /tasks で行います。ターミナルやデスクトップアプリで手元から使うローカルのセッションでは、v2.1.288以降、バックグラウンドコマンドに時間制限がありません。無人のセッション(-p、CI、クラウド)では、30分または指定した timeout(最大2時間)で止められます。この制限はv2.1.285で入り、v2.1.287までは全セッションに適用されます。止まったときは Background command "<説明>" was stopped after reaching its background time limit と表示され、必要なら長い timeout で起動し直せます。

同じ手作業や確認が繰り返されるとき

8. 毎回の整形はPostToolUse Hookに任せる

「保存したらフォーマット」を毎回頼むのはやめて、Hookにします。PostToolUse イベントに Edit|Write のmatcherを付けると、ファイル編集ツールの実行後だけ動きます。公式ガイドの例は、編集したファイルのパスを jq で取り出してPrettierに渡す形です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

成功したHookは会話に何も表示しません。動いたかどうかは、編集されたファイルが整形されているかで確かめます。Bashコマンドがファイルを書き換える場合まで対象にしたいときは、FileChanged Hookを使います。ほかの用途の書き方はHooks実例カタログのレシピ2にあります。

9. PR本文はHEREDOCかファイル経由で渡す

gh pr create --body に長い本文を渡すとき、引用符のエスケープで崩れがちです。HEREDOCなら改行も記号もそのまま渡せます。

gh pr create --title "..." --body "$(cat <<'EOF'
## Summary
...
EOF
)"

gh は -F(--body-file)でファイルから本文を読む方法も持ち、- を渡すと標準入力から読みます。本文をファイルに書き出してから渡す形にしておくと、Claudeが本文を書いて、あなたが読んでから送る流れにもしやすくなります。ドラフトで作りたいときは --draft(-d)を付けます。

10. 機微ファイルは書き込みの前に止める

.env や認証情報の編集を扱うHookは、どのイベントに置くかで効き方が変わります。

くらべる

どのタイミングで判定するか

編集のあと

PostToolUse

編集が成功した後に走るため、ファイルはすでに書き換わっています。気づきを促す注意喚起には向きますが、書き込み自体は止められません。

編集のまえ

PreToolUse

終了コード2で編集を止めると、Claudeは止めた理由を受け取って別のやり方を探します。保護したいファイルには、こちらが確実です。

公式ガイドにも、.env や package-lock.json、.git/ 配下の編集を止める例があります。判定をスクリプトに置き、保護するパターンに一致したら終了コード2で止める構成です。注意喚起型のレシピはHooks実例カタログのレシピ9にあり、検出の範囲と限界もそちらで確かめられます。

ブランチとマージの運用で事故を減らしたいとき

11. worktree.baseRef で新しいworktreeの起点を決める

新しいworktreeが何を起点にブランチを切るかは、設定 worktree.baseRef で決まります。値は2つだけで、ブランチ名は指定できません。

値起点向く場面
"fresh"(既定)起点リモートの既定ブランチ(通常は main)向く場面リモートと同じきれいな状態から始めたい
"head"起点手元の現在の HEAD向く場面未pushのコミットや作業中のブランチ状態を持ち込みたい

"fresh" のときは、最後の取得から24時間以上経っていれば既定ブランチを取得します(5秒で打ち切り、失敗したらキャッシュを使います)。リモートが無い、または origin/HEAD を取得できない場合は、現在の HEAD から作られます。この設定はサブエージェント用のworktreeにも同じ起点として効きます。作業中の変更を前提にサブエージェントを動かすなら "head" です。

{
  "worktree": {
    "baseRef": "head"
  }
}

特定の既存ブランチから始めたいときは、gitで直接worktreeを作ります。使い方はWorktree完全活用にあります。

12. 自動マージはラベルで止められるようにする

PRの自動マージを回しているなら、人が止めるための手段を最初に用意します。代表的なのは、特定のラベルが付いているあいだは自動マージのジョブを走らせない構成です。GitHub Actionsでは、ジョブの条件に次のように書けます。

if: ${{ !contains(github.event.pull_request.labels.*.name, 'do-not-merge') }}

緊急停止用のラベルを1つ決めておけば、マージ間際の異変に気づいた人が、コードを触らずに止められます。Claude Codeにはドラフトで作らせる(9の --draft)ことも組み合わせられ、人が確認するまで公開されない段階を挟めます。自動マージ自体は、レビューとCIの結果を条件にするのが前提です。

迷ったときの入れ方

12個を一度に入れる必要はありません。会話の質に悩んでいるなら1と4、調査の出力で会話が埋まるなら5、同じ整形作業が気になるなら8から始めると、効果が見えやすくなります。入れたあとは /context で埋まり具合を見比べると、小技が効いているかを確かめられます。

まとめ

小技は「どの場面で困っているか」から選ぶと外しにくくなります。会話の長さ、調査の置き場所、手作業の繰り返しのどれが負担かを決めたら、該当する1つだけを入れて、数セッション使ってから次へ進んでください。

参照した一次ソース

この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。

  1. code.claude.com/docs/en/commands
  2. code.claude.com/docs/en/tools-reference
  3. code.claude.com/docs/en/memory
  4. code.claude.com/docs/en/sub-agents
  5. code.claude.com/docs/en/hooks-guide
  6. code.claude.com/docs/en/worktrees
  7. code.claude.com/docs/en/best-practices
この記事を共有:XはてブLinkedIn