Claude Code 速度最適化ガイド: 遅い原因を切り分けて実務を速くする

Claude Code が遅いと感じたとき、最初に疑うべきなのはモデル性能ではありません。多くの場合、遅さの正体は、会話履歴が膨らんだこと、読ませるファイルの範囲が広すぎること、そして検証ログをそのまま食べさせていることです。 このサイトでも、記事生成、翻訳、ビルド確認を同じセッションに詰め込みすぎた時期は、返答が重くなり、指示の意図もぶれました。そこで速度改善を、感覚ではなく、/usage と /context で確認しながら進める形に変えました。 この記事では、初心者でも今日から試せる順番で、Claude Code の速度を落としている原因の見つけ方、CLAUDE.md の整え方、実務で使えるプロンプト例、そしてやりがちな失敗をまとめます。

設定を変える前に診断する

速度改善は、いきなり設定をいじるより診断から始める方が早いです。/usage は現在のセッション利用状況を確認する入口で、API利用者にはセッションのトークンとローカル推定コスト、サブスク利用者にはプラン利用バーや利用内訳が表示されます。請求額そのものではなく、今の作業が重くなっているかを見るメーターとして使うのが現実的です。 /context は、MCP、ツール定義、メモリ、会話履歴など、何がコンテキストを占めているかを確認するために使います。ここで大きいものを見ずに、なんとなくモデルを変えるだけでは、根本原因が残ります。 /compact は会話履歴を要約して圧縮します。ただし、単に実行するより、何を残してほしいかを添える方が実務向きです。変更ファイル、テスト結果、決定事項、未解決論点を残すように指定すると、速さと継続性の両方を取りやすくなります。

# Run these inside Claude Code before changing the workflow
/usage
/context
/compact Preserve changed files, test failures, decisions, and open questions

速い標準ワークフローを作る

私が使っている基本の型は、最初に /usage と /context、長くなったら目的付きの /compact、別件に移るときは /clear です。特に /clear は怖がられがちですが、前のタスクの文脈が不要なら一番安いリセットです。 次に、Claude Code に読む場所を絞ります。初心者ほど「このプロジェクトを全部見て」と言いたくなりますが、これは人間に全フォルダを渡してバグを探させるのと同じです。対象ファイル、読んでよいテスト、読まなくてよいディレクトリを最初に指定します。 最後に、CLAUDE.md を短く保ちます。公式ドキュメントでも、毎回必要な事実は CLAUDE.md、特定領域だけの手順は rules や skills に分ける考え方が示されています。CLAUDE.md を肥大化させると、速くするためのメモリが逆に毎回の荷物になります。

claude -p "Fix only the null-check bug in src/api/auth.ts.
Read src/api/auth.ts and tests/auth.test.ts first.
Do not scan node_modules, dist, coverage, or unrelated feature folders.
Return the changed files, commands run, and remaining risks."

CLAUDE.md には常時必要な事実だけを書く

次の例は、あえて短くしています。Claude にリポジトリの安定した地図だけを渡し、メモリを永続的な資料置き場にしないためです。

# CLAUDE.md

## Project commands
- Build: npm run build
- Test: npm run test
- Type check: npm run typecheck

## Fast navigation
- API code: src/api/
- UI components: src/components/
- Tests: tests/

## Do not read unless explicitly requested
- node_modules/
- dist/
- coverage/
- .wrangler/

## Compact instructions
When compacting, preserve changed files, failing tests, decisions, credentials policy, and next actions.

小さなベンチマークで測る

体感だけで最適化しないでください。同じ種類のタスクを、広い指示と範囲を絞った指示で一度ずつ実行し、所要時間、読んだファイル数、最後に返った証拠の質を比べます。

$runs = @(
  @{ Name = "wide"; Prompt = "Find and fix the auth bug in this project" },
  @{ Name = "scoped"; Prompt = "Fix the null-check bug in src/api/auth.ts only" }
)

foreach ($run in $runs) {
  $elapsed = Measure-Command { claude -p $run.Prompt }
  [pscustomobject]@{
    Name = $run.Name
    Seconds = [math]::Round($elapsed.TotalSeconds, 1)
  }
}

実務で使える3つのユースケース

小さなバグ修正

ログイン処理の null チェック漏れのような作業では、対象ファイルとテストだけを指定します。これで探索は数十ファイルから二、三ファイルに減り、修正後の確認も短くなります。

大きなリファクタ

いきなり全体を書き換えず、調査、変更、テスト、差分レビューを別ステップにします。各ステップの終わりで /compact を挟むと、判断の履歴だけ残してノイズを落とせます。

記事生成や翻訳バッチ

本文作成、翻訳、ビルド、デプロイを一つの会話に詰め込むと重くなります。翻訳や一覧調査はサブエージェントへ渡し、メインには要約と変更ファイルだけ返す形が安定しました。

現場導入の判断基準

速度改善で一番大事なのは、「何秒短くなったか」だけを追わないことです。Claude Code の作業は、人間の待ち時間、探索回数、手戻り、検証のやり直しが合わさって体感速度になります。たとえば返答が二十秒速くなっても、必要なテストが抜けて後で三十分戻るなら、その最適化は失敗です。

私なら、まず一週間だけ小さな運用ログを残します。記録するのは、開始時刻、タスク種別、最初に読ませたファイル数、実行した検証、/compact のタイミング、最後に残ったリスクです。厳密な計測ツールを作らなくても、この五項目があるだけで「遅い」の正体がかなり見えます。特に、毎回同じディレクトリを探しているなら CLAUDE.md の不足、毎回巨大なログを読んでいるなら hook や grep の不足、毎回設計の前提を説明しているなら memory の不足です。

初心者が最初に入れるなら、設定よりもプロンプトの型をそろえるのが安全です。「対象」「読んでよい範囲」「読まない範囲」「完了条件」「検証コマンド」「最後に報告する形式」を毎回書きます。この型は地味ですが、Claude Code が迷いにくくなります。迷わないということは、読むファイルが減り、確認の往復が減り、結果的に速くなります。

チームで使う場合は、速さの責任を個人の勘に置かない方がよいです。レビューで「なぜこのファイルを読んだのか」「なぜこのテストを省いたのか」を確認できるように、最終回答に変更ファイル、実行コマンド、確認結果、未確認リスクを残すルールにします。速いだけの記事生成や実装は、あとで品質事故を起こすので、速度改善と検証レシートは必ずセットで考えます。

もう一つの判断基準は、Claude Code に「考えさせる時間」と「探させる時間」を分けて見ることです。設計判断や原因分析に時間がかかるのは悪いことではありません。むしろ、そこで急がせすぎると品質が落ちます。一方で、毎回 node_modules や生成物を見に行く、同じ設定ファイルを何度も探す、長いログの中から失敗行を探す、といった時間は削れます。速度改善の対象にすべきなのは後者です。

そのため、私は「速くする」より先に「迷わない状態を作る」と考えています。対象ファイルが分かっている、検証コマンドが分かっている、読まない場所が分かっている、圧縮時に残す情報が分かっている。この四つがそろうと、Claude Code は無駄な探索を減らしながら、必要なところではしっかり考えられます。

小さく始めるなら、まず一つのリポジトリで「速い依頼文」を三つ作ってください。バグ修正用、レビュー用、調査用の三つです。それぞれに対象ファイル、禁止範囲、検証コマンド、報告形式を入れておくと、毎回ゼロから指示を考えずに済みます。これはプロンプトテクニックというより、開発チームの作業標準化です。標準化された依頼文は、人間同士の引き継ぎにもそのまま使えるので、Claude Code を使わない場面でも効きます。

この型を一度作ると、速度改善は継続的に効きます。新しいメンバーが入っても同じ依頼文から始められ、失敗したときもどこで範囲が広がったかを確認できます。 速度は、才能ではなく運用で作れます。まずは今日の一タスクからで十分です。

避けたい失敗例

• 最初の失敗は、/compact を魔法の高速化ボタンとして使うことです。圧縮後に何を保持するかを指定しないと、重要なテスト失敗や設計判断が薄くなることがあります。
• 二つ目は、CLAUDE.md に何でも入れることです。毎回読む必要がない長い手順、古い障害対応、個人メモを入れると、速度も精度も下がります。
• 三つ目は、速さのために検証を消すことです。テストログを全部読む必要はありませんが、失敗箇所だけに絞って渡す仕組みは必要です。

確認した公式ドキュメント

• Claude Code costs and /usage: https://code.claude.com/docs/en/costs
• Claude Code monitoring and telemetry: https://code.claude.com/docs/en/monitoring-usage
• Claude Code memory and CLAUDE.md: https://code.claude.com/docs/en/memory

今回の書き直しで確認したこと

この記事の内容は、Claude Code の Costs、Monitoring、Memory の公式ドキュメントを確認し、古い /cost 前提ではなく /usage、/context、/compact、CLAUDE.md を中心に書き直しました。実務では、速くすることより、速く戻れる状態を残すことの方が効きます。

次にやること

チームで Claude Code を速くしたいなら、いきなり上位モデルや自動化を増やすのではなく、まずプロンプトの型、メモリファイル、検証レシートを標準化します。以下の内部リンクは、同じ運用思想で続けて読めます。

• トークン最適化
• Claude Code 権限ガイド
• ハーネスエンジニアリングガイド
• 相談・研修