CodeCraft Lab

パフォーマンスを最適化する

レスポンス速度とコスト効率を左右する要因を理解し、モデルの使い分けや計測を通じて大規模プロジェクトでも快適にClaude Codeを使い続ける方法を学びます

応用16分で読了
パフォーマンスコスト最適化モデル選択計測

このレッスンで学ぶこと

  • レスポンス速度に影響する要因を、コンテキストサイズ・モデル選択・実行環境の3つの軸で理解する
  • モデルの使い分けによってコストと品質のバランスを取る考え方を身につける
  • 大規模プロジェクトで起きがちなパフォーマンス劣化のパターンと対処法を知る
  • 自分の使用状況を計測し、継続的にチューニングする習慣をつける

前提条件

  • 実践コース Lesson 9（コンテキスト管理の最適化）を読んでいること。/compactやサブエージェント委譲の基本はそちらで扱っているため、このレッスンでは前提として進みます
  • 応用コース Lesson 11〜13で、IDE連携・Remote Control・デスクトップアプリの基本を理解していること

なぜ「遅い」「高い」が起きるのか

Claude Codeを毎日使っていると、ある日突然「反応が遅くなった」「今月の利用量がやけに多い」と感じる瞬間があります。多くの場合、原因は単一ではなく、いくつかの要因が積み重なって表面化します。このレッスンでは、その要因を構造的に整理し、対処の優先順位をつけられるようにします。

速度とコストは表裏一体

コンテキストが肥大化すれば応答は遅くなり、同時に処理するトークン数が増えるためコストも上がります。逆に、コンテキストを適切に保てば、速度とコストの両方が改善します。このレッスンで扱う対策の多くは、両方に効くものだと考えてください。

レスポンス速度に影響する要因

コンテキストサイズ

コンテキストウィンドウが埋まるほど処理対象のトークン数が増え、応答に時間がかかるようになります。コンテキストの管理方法そのものは実践コース Lesson 9で詳しく扱ったため、ここでは要点だけ振り返ります。

  • /compactを区切りのよいタイミングで使い、不要な情報を持ち越さない
  • 巨大なファイルは全体ではなく必要な範囲だけを読ませる
  • 独立した調査はサブエージェントに委譲し、メインの会話を膨らませない

これらを徹底するだけでも、体感速度はかなり変わります。コンテキスト管理を「コスト対策」ではなく「速度対策」として捉え直すと、また違った優先順位で取り組めるはずです。

モデル選択

Claude Codeでは、タスクの複雑さに応じてモデルを切り替えられます。高性能なモデルほど複雑な推論に強い一方、応答時間とコストは増える傾向にあります。タスクの難易度に対して常に最上位のモデルを使うのではなく、必要に応じて使い分けることが速度とコストの両面で効いてきます。

タスクの性質向いている考え方
単純な置換、フォーマット調整、定型的なコマンド実行軽量なモデルで十分なことが多い
複雑な設計判断、アーキテクチャの検討、難易度の高いバグ調査高性能なモデルの推論力が活きる
大量のファイルを横断する単純作業（リネーム、コメント追加など）軽量モデル + サブエージェントの並列実行が有効

VS Code拡張機能やデスクトップアプリではコマンドメニューやドロップダウンからモデルを切り替えられ、CLIでも起動時やセッション中にモデルを指定できます。「迷ったら最強のモデル」ではなく、「このタスクにこの精度は本当に必要か」を一呼吸置いて考える習慣が、積み重なると大きな差になります。

実行環境とネットワーク

ローカルマシンのスペック、VPN経由かどうか、WSL環境かどうかといった実行環境の違いも応答速度に影響します。特に以下は見落としがちなポイントです。

  • VPN経由での利用は、直接接続に比べて遅延が発生しやすい
  • WSL環境では、Windowsファイルシステム（/mnt/c/配下）よりLinuxネイティブファイルシステム（/home/配下）に置いたプロジェクトの方が、ファイル探索のパフォーマンスが安定する
  • node_modulesやdistのような大きなビルド成果物ディレクトリが.gitignoreに含まれていないと、無関係なファイル走査に時間を取られることがある
WSLでの検索結果が少なく見える場合

WSL環境ではディスク読み取りの仕組み上、検索ツールが期待より少ないマッチしか返さないことがあります。これは検索が壊れているのではなく、WindowsファイルシステムをまたぐI/Oのパフォーマンス特性によるものです。プロジェクトをLinux側のファイルシステムに置く、検索条件をディレクトリやファイル種別で絞り込むといった対策が有効です。

コスト効率の最適化

モデルの使い分けを「ルール化」する

毎回その場で「どのモデルを使うか」を判断するのは現実的ではありません。CLAUDE.mdやチームの運用ルールとして、タスクの種類ごとにモデルの目安を明文化しておくと、判断のコストそのものを減らせます。

## モデル選択の目安
- ドキュメント生成・コメント追加・フォーマット調整 → 軽量モデルで開始する
- 設計判断を伴う実装・本番障害の調査 → 高性能モデルに切り替える
- 迷ったら、まず軽量モデルで様子を見て、必要なら切り替える

トークン消費を減らす習慣

コンテキストサイズの管理と重なる部分も多いですが、コストの観点から特に効果が大きいのは次の習慣です。

  • 同じ内容を毎回説明し直すのではなく、CLAUDE.mdに恒久的なルールとして書いておく
  • 「とりあえず全部見て」ではなく、対象範囲を具体的に指定する
  • 大量の出力が予想される操作（巨大ログの全文出力など）は、要約や絞り込みを先に指示する

使用状況を可視化する

VS Code拡張機能では/usageコマンドで、アカウントの使用状況とプラン制限への到達状況を確認できます。バージョンによっては、直近の使用量のうちどんな操作が多くを占めているか（キャッシュミス、長いコンテキスト、サブエージェントの多用、高度な並列セッションなど）まで内訳が表示され、改善のヒントも提示されます。

/usage

「なんとなく使いすぎている気がする」で終わらせず、定期的にこの内訳を確認する習慣をつけると、どこにテコ入れすべきかが具体的に見えてきます。

大規模プロジェクトでのパフォーマンスチューニング

プロジェクトの規模が大きくなるほど、小規模プロジェクトでは気にならなかった問題が顕在化します。

モノレポ・大規模リポジトリでの工夫

  • 対象範囲をプロジェクト全体ではなく、作業しているパッケージ・ディレクトリに絞って指示する
  • .gitignoreを適切に整備し、ビルド成果物や依存関係ディレクトリが検索対象に含まれないようにする
  • 大規模な横断的変更（全体のリネーム、一括フォーマット変更など）は、一度に全体を任せるのではなく、ディレクトリ単位・モジュール単位で段階的に進める

並行作業との組み合わせ

応用コース Lesson 13で扱ったデスクトップアプリのマルチセッション機能や、git worktreeを使った並行実行は、パフォーマンスの観点からも有効です。1つの巨大なセッションですべてを処理しようとせず、独立したタスクは別セッション・別worktreeに分けることで、各セッションのコンテキストを小さく保てます。

flowchart LR
    A["大規模な変更要求"]
    B["モジュール単位に分解"]
    C1["セッション1: モジュールA"]
    C2["セッション2: モジュールB"]
    C3["セッション3: モジュールC"]
    D["各セッションは独立したコンテキスト<br/>worktreeでファイル競合も回避"]
 
    A --> B --> C1 & C2 & C3 --> D
 
    style D fill:#e8f5e9,stroke:#2e7d32

セーフモードで原因を切り分ける

応答が極端に遅い、CPUやメモリの使用量が異常に高いといった場合、原因がプラグインやMCPサーバーにあることも珍しくありません。--safe-modeで起動すると、セッション中のカスタマイズ（プラグイン・MCPサーバー・Hooksなど）が一時的に無効化されます。

claude --safe-mode

セーフモードで問題が解消すれば、原因はカスタマイズのどれかにあると判断できます。1つずつ有効化し直しながら、問題のある設定を特定していきましょう。

メモリ使用量の詳細を調べたいとき

セーフモードでも改善しない高いメモリ使用量が続く場合は、/heapdumpを実行するとヒープスナップショットとメモリ分析がデスクトップに出力されます。問題をGitHubで報告する際にこのファイルを添付すると、原因特定の助けになります。

計測・モニタリングの方法

最適化は「なんとなく速くなった気がする」で終わらせず、数値で確認することで初めて再現性のある改善になります。

ベースラインを記録する

最適化に取り組む前に、現在のコンテキスト使用量（/context）や利用量（/usage）の状態を一度記録しておきます。何かを変える前の基準値がないと、効果があったかどうかを判断できません。

1つずつ変更して効果を確認する

モデルの使い分けルールを導入する、CLAUDE.mdにコンテキスト方針を追記する、大規模タスクをセッション分割する——これらを同時に全部試すのではなく、1つ変えてから数日使ってみて、体感と数値の両方で変化を確認します。

チームで知見を共有する

個人で見つけた「このタスクはこのモデルで十分だった」「この粒度でセッションを分けるとコンテキストが安定する」といった知見は、CLAUDE.mdやチームのドキュメントに残し、属人化させないようにします。

実践コース Lesson 10で扱った生産性計測の考え方（タスク完了時間やレビュー往復数の記録）と、このレッスンで扱ったコンテキスト・コストの計測を組み合わせると、「速くなった」「安くなった」を主観ではなく根拠を持って語れるようになります。

まとめ

このレッスンでは、Claude Codeのレスポンス速度とコスト効率を左右する要因を構造的に整理しました。

  • 速度は主にコンテキストサイズ・モデル選択・実行環境の3つで決まり、コストとも密接に関係している
  • モデルの使い分けをその場の判断に頼らず、CLAUDE.mdやチームルールとして明文化しておくと判断コストそのものが下がる
  • /usageで使用状況の内訳を定期的に確認し、改善ポイントを具体的に把握する
  • 大規模プロジェクトでは対象範囲の絞り込みと、worktreeを活用したセッション分割が効果的
  • 原因不明の重さは--safe-modeでプラグイン・MCP・Hooksの影響を切り分けてから対処する

パフォーマンスの最適化は一度やって終わりではなく、プロジェクトの成長とともに見直し続ける性質のものです。次のレッスンでは、こうした最適化の文脈も含めて、問題が起きたときにどう体系的に向き合うかを扱います。

次のステップ

最終回となるLesson 15では、個別のエラー対処ではなく「問題解決そのものの考え方」を扱います。このレッスンで学んだ計測の習慣は、次のレッスンで扱う問題切り分けの土台にもなります。