Claude Codeが遅いときに確認する設定・コンテキスト・ファイル量：原因切り分けの順序

結論：「コンテキスト圧迫 → 道具立て → 依頼粒度 → ネットワーク」の順で疑う

Claude Codeが遅いと感じたら、最初に疑うのはネットワークではなくコンテキストウィンドウの状態です。公式のBest Practicesも、性能劣化の最大要因として**「Claude’s context window fills up fast, and performance degrades as it fills.」**を挙げています。実際の遅さも、ローカルの観察でほぼ次の順序で原因が見つかります。

1. コンテキスト圧迫：会話・ツール定義・読んだファイルで詰まっている
2. 道具立て（MCPとサブエージェント）：MCPツール定義が初手から肥大化している
3. 依頼粒度：1依頼が大きすぎて1往復で終わらない
4. 検索インデックス：ripgrepが動かず@参照やSearchが空振り
5. ネットワーク／API：プロキシ・タイムアウト・5xx
6. メモリ・プロセス：Node側の常駐メモリで重くなっている

本記事では、上の6軸を順序付きの切り分け手順として整理します。エラーが出ているケースはClaude Codeのよくあるエラー一覧と原因別の直し方で扱うので、本記事は**「エラーは出ていないが遅い」**ケースに焦点を当てます。情報は2026年5月1日時点で公式のTroubleshootingとBest Practicesを確認したものです。

まずやる：/contextで詰まり方を見る

遅いと感じたときの最初のコマンドはこれです。Claude Code内で実行します。

/contextはシステムプロンプト・ツール定義・メモリファイル・メッセージのうち、いま何がコンテキストを食っているかを内訳で表示します。続けて全体診断にも回します。

/doctorはインストール、設定、MCP、コンテキスト使用量を一括で見て、CLAUDE.mdの肥大化やサブエージェント定義の過多などを警告します。/doctorが「CLAUDE.mdが大きい」と言っている時点で、後続で何をしても効果は限定的です。

切り分けの最短ルートをまとめると次のとおりです。

特に**/compactと/clearは「迷ったら早めに使う」のが鉄則です。Best Practicesも「If you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches.」**と明記しており、修正を2回繰り返したら/clearしてからやり直す方が結果的に速いことが推奨されています。

軸1：コンテキスト圧迫を解く

/contextの表示を見たときの典型パターンと対処は次の表のとおりです。

Autocompact is thrashing（自動圧縮が直後に押し戻される）状態に陥ったときは、ファイルやツール出力でコンテキストが即座に埋め直されています。この場合は次のいずれかが効きます。

• ファイル全体ではなく行範囲や関数名で部分読みを依頼する
• 大きな調査はサブエージェントに委譲してコンテキストを分離する
• 直近の会話が不要なら/clearで初期化する

軸2：MCPとサブエージェントの「道具立て」

公式エラーリファレンスは、Prompt is too longの対処として**「Disable MCP servers you are not using with /mcp disable <name> to remove their tool definitions from context」と注意書きを付けています。これは遅さにも直結します。MCPサーバーごとに定義されたツールの名前・説明・スキーマ**は、起動時点でそのままコンテキストへ載るためです。

さらに重要な落とし穴があります。サブエージェントは親セッションのMCPツール定義を全継承します。 Notion、Sentry、GitHub、Postgres、Playwright……と並べているままサブエージェントを生成すると、初手からツール定義だけで数千トークン消費した状態でスタートし、応答が体感で目に見えて遅くなります。

サブエージェントを使う日のチェック手順は次のとおりです。

/mcp画面で**当面使わないサーバーをdisable**してから、サブエージェントの仕事を回します。MCPの仕組み自体はClaude CodeとMCPサーバーの基本：できること・3つのスコープ・導入前のセキュリティ注意点で整理しているので、まだ全体像を掴んでいなければそちらを先に読んでください。

軸3：依頼粒度と「kitchen sinkセッション」

Best Practicesは**「The kitchen sink session」として、「You start with one task, then ask Claude something unrelated, then go back to the first task. Context is full of irrelevant information.」**を典型的な失敗パターンに挙げています。1セッションに無関係なタスクを混ぜると、その分だけ過去の文脈を引きずって遅くなります。

依頼粒度を直す原則は3つです。

• 無関係なタスク間では/clear：機能追加→バグ修正→ドキュメント整備のように切り替わったら/clear
• 大タスクは分解してから渡す：詳細は大きな開発タスクをClaude Codeに渡す前の分解方法
• 「探索」を無制限にしない：「投資して」ではなく「src/auth/配下の3ファイルだけ読んで仕組みを要約」のように範囲指定する

infinite exploration（探索の無限化）も公式が挙げる失敗パターンです。**「Scope investigations narrowly or use subagents so the exploration doesn’t consume your main context.」**と書かれているとおり、調査範囲を絞るか、消費するコンテキストを別エージェントに切り出す形が王道です。

軸4：検索が空振りしている

@file参照やSearchツールがファイルを見つけられないときも、Claudeが「再探索」を繰り返して結果的に遅くなります。公式Troubleshootingは原因として**「the bundled ripgrep binary may not run on your system」**を挙げています。このときはOS側にripgrepを入れて、Claude Code側に「外部のrgを使う」と教えるのが解決策です。

macOSなら次のとおりです。

Ubuntu／Debianなら次のとおりです。

その上で環境変数で次を設定します。

export USE_BUILTIN_RIPGREP=0

WSLでは公式が**「Disk read performance penalties when working across file systems on WSL may result in fewer-than-expected matches」**と警告しています。/mnt/c/に置いたプロジェクトは構造的に遅いので、可能なら/home/配下に移すか、Windowsネイティブ実行に切り替える判断が現実解です。

軸5：ネットワーク・APIまわり

ネットワーク要因はエラーになりやすく、本シリーズではClaude Codeのよくあるエラー一覧と原因別の直し方で扱っています。エラーが出ていなくても遅いときに見るのは次の3点です。

• モデル選択：/modelで現在のモデルを確認。Opus上限に達して自動的に小モデルへ落ちている可能性もある
• API_TIMEOUT_MS：遅い回線・プロキシでは引き上げ余地あり（既定600,000ms）
• CLAUDE_CODE_MAX_RETRIES：自動リトライが既定10回。スクリプト中の遅延の正体がリトライの可能性

/statusで「いまどの認証情報・どのモデルが効いているか」を確認しておくと、思わぬダウングレードに気付きやすくなります。詳しくはClaude Codeの基本コマンドと日常的に使う操作まとめを参照してください。

軸6：メモリ・プロセスの確認

長時間使っていてだんだん重くなるパターンでは、Node側のメモリ使用量を疑います。Troubleshootingは次のコマンドを案内しています。

これでメモリのスナップショットと内訳が~/Desktop（LinuxでホームにDesktopがない場合はホーム）に書き出されます。RSS／JSヒープ／ArrayBuffer／ネイティブメモリの内訳が表示されるので、JS側の肥大か、ネイティブ側の肥大かを見分けられます。多くのユーザーケースでは、/clearを挟んで再起動するだけで解決します。

ハングしてしまったときは次のとおりです。

• Ctrl+Cで現在の操作を中断
• 反応がなければターミナル側で再起動
• claude --resumeで同じディレクトリのセッションを引き継ぐ

会話履歴は破棄されないので、再起動でやり直しても数十秒のロスで済みます。

まとめ：チェックリスト

遅さを感じたときに、上から順に試せる最小セットを置いておきます。

• /contextでコンテキスト内訳を確認
• /doctorまたはclaude doctorで総合診断
• 直近で2回修正していたら/clearして仕切り直す
• 不要MCPを/mcp disableで外す（サブエージェント生成前は必須）
• 無関係タスクを混ぜず、/clearで区切る
• 大タスクは分解してから渡す
• WSLなら/home/配下にプロジェクトを置く、ripgrepを別途入れる
• /statusで意図したモデル・認証で動いているか確認
• 重い状態が続くなら/heapdumpを保存して再起動

公式Best Practicesが繰り返し書いているとおり、コンテキストはClaude Codeで最も重要なリソースです。遅さの大半は、ネットワークでも設定でもなく、**「いまセッションに何が載っているか」**で説明できます。次の記事として、コンテキストの中身を更に詰めるならClaude Codeに伝わるプロンプトの基本構造、エラーが出始めたらよくあるエラー一覧と原因別の直し方、MCPの整理はMCPサーバーの基本を続けて読むと運用の解像度が上がります。