Lena です。Claude Code のセッションを始めて 45 分あたりで、ある種の苛立ちが訪れる瞬間があります。最初の数コマンドは快適だった。そこから徐々に遅くなり、tool call が失敗し、気づけばセッションの残り時間がもう半分以上消えている。
何度も経験して、ようやく「運が悪かった」で片づけるのをやめました。実際に何が起きているのか——そしてどう対処すべきか、整理してみます。
Claude Code が遅くなる・結果が不安定になる理由
修正に飛びつく前に、どういう種類の「遅さ」なのかを正確に見極める価値があります。Claude Code のパフォーマンス問題はすべて同じ原因ではなく、間違った対処をすればさらにセッション時間を浪費するだけです。
context window の過負荷
最もよくある原因であり、しかも静かに積み重なっていきます。
Claude Code は API に単一のプロンプトを送って応答を待つ仕組みではありません。各インタラクションはマルチターンの会話であり、system prompt、蓄積された会話履歴、コンテキストに引き込まれたファイル内容、さらにファイル読み込み・bash コマンド実行・コードベース検索といった操作が生成する tool call の token が含まれます。一見シンプルな「このファイルを編集して」というコマンドでも、完全な context window が組み立てられると、1 回の API 呼び出しで 50,000〜150,000 token を消費することがあります。
厄介なのは、同一セッション内のフォローアップメッセージがすべてこのコンテキストに追加されることです。最初は 40k token のセッションが、メッセージ 12 には 200k 以上に膨れ上がる。モデルは遅くなり、応答の精度は低下し、セッション予算は蒸発していきます。
Claude の context window サイズは、すべてのモデルと有料プランで 200K token です。ただし Enterprise プランでは、一部のモデルで 500K の context window が利用できます。この上限に達すると、応答が途中で切れるか、完全に停止するかのどちらかです。
tool call の失敗とリトライループ
Claude Code では、ユーザーに見える 1 つのコマンドが、tool call によって複数の API 呼び出しを発生させることがあります。「lint → 修正 → テスト → 修正」のサイクルでは、60 秒以内に 8〜12 回の API 呼び出しが生じることも珍しくありません。そのうち 1 つの tool call が失敗した場合——bash コマンドのタイムアウトやファイル読み込みのパーミッションエラーなど——Claude は必ずしもその失敗を明確に表面化させるわけではありません。リトライするのです。各リトライは token とリアルタイムのレイテンシを消費します。セッションが固まったように見えますが、実際にはリトライループが混乱に対して課金し続けているのです。
プロンプトのドリフト
これは、自分でもずっと過小評価していました。CLAUDE.md や同等の skill file には、時間とともに指示が蓄積されていきます。あるプロジェクトにだけ適用されていた古い制約がそのまま残る。矛盾するガイダンスが積み重なる。新しいリクエストのたびにファイル全体がコンテキストに読み込まれます——もはや当てはまらない部分も、互いに矛盾している部分も含めて。
肥大化した矛盾だらけの skill file は、単に token を消費するだけではありません。エージェントを混乱させるのです。両立できない指示を同時に満たそうとするため、応答は遅くなり、一貫性を失います。
モデルのレート制限
この点は具体的に書く価値があります。ダッシュボードの数字が本当に誤解を招くからです。
Claude Code を使うすべての開発者にとって見覚えのあるシナリオでしょう。Anthropic のダッシュボードには「本日の使用量 6%」と表示されている。どう見てもクォータは十分に残っている。なのにスロットリングされる。理由は、Claude Code のレート制限が3 つの独立した、重複する制約のシステムとして動作しているからです。ダッシュボードのパーセンテージは、そのうち 1 つしか反映していません。
5 時間のローリングウィンドウに加え、Anthropic は 7 日ごとにリセットされるウィークリーレート制限も適用しています。全体的な使用量上限に加え、Opus モデルには別途ウィークリー上限が設けられています。
さらに 2026 年 3 月には新たなレイヤーが追加されました。Anthropic はピーク時間帯（平日 5am〜11am PT）に限り、5 時間セッション制限の調整を導入したのです。この時間帯での負荷の高いエージェントワークフローは、夜間に同じ作業を行った場合より速く消費されます。
今すぐ適用できる修正策
コンテキスト管理
最も即効性のあるレバーです。応答品質の低下や速度の低下に気づいたら、新しいセッションを開始してください。肥大化したコンテキストからの継続は避けるべきです。
会話が context window の上限に近づくと、Claude は以前のメッセージを要約して会話をシームレスに継続します。完全なチャット履歴は保持されるため、要約後も Claude は参照できます。/compact コマンドを使えば、ウィンドウが完全に飽和する前にこの要約を前倒しで実行できます。劣化が目に見えてからではなく、60〜70% の段階で積極的に使いましょう。
CLAUDE.md やプロジェクト指示については、短くタスク固有に保つことが重要です。Anthropic のサポートドキュメントの公式ガイダンスでは、プロジェクト指示は一般的なコンテキストと役割に使い、タスク固有の指示は個別のセッションに留めるよう推奨されています。skill file をゴミ捨て場にしないことです。
tool call の最適化
ツールの公開範囲を絞りましょう。タスクが bash の実行を必要としないなら、Claude にオープンな bash ツールを与えないことです。明示的な権限のスコーピングにより、不要な tool call が減り、潜在的な失敗ポイントとリトライループも減ります。
プロンプトに明示的なエラーハンドリングの期待値を追加してください。「このコマンドが失敗したら、リトライせずに停止してエラーを報告して」——当たり前に聞こえますが、実際に振る舞いを変えます。Claude のデフォルトは粘り強い——通常は長所ですが、レート制限のあるセッションでは予算を消耗させます。
自動化ワークフローにはリトライ上限を明示的に設定しましょう。3 回リトライ＋指数バックオフのループは制御可能です。上限なしのリトライループは、複雑なエージェントセッションにとって致命的です。
プロンプトの衛生管理
数週間おきに、skill file と CLAUDE.md の内容を監査しましょう。テストはシンプルです。すべての指示を読み返し、それが現在のプロジェクトにまだ当てはまるかを自問する。古くなったものは削除する。矛盾があれば解消する。2 つの指示が矛盾していれば、モデルは両方を満たそうとします——ゆっくりと、不安定に。
複数のプロジェクトで CLAUDE.md を共有している場合は、プロジェクト固有の指示が「グローバル」ファイルに紛れ込んでいないか特に注意が必要です。無関係なリクエストにもノイズとして乗ってきます。
レート制限の回避策
集中的なセッションはピーク時間外にスケジュールしましょう。オフピークとは平日 5am〜11am PT の外を意味します。深夜や週末のセッションであれば、営業時間帯の使用に最も影響するスロットリングを回避できます。
大きなプロジェクトは、1 つの長時間マルチアワーの実行ではなく、小さく区切ったセッションに分割しましょう。これにより、課金サイクルごとのコンテキスト蓄積が抑えられ、各セッションの token 予算がより予測可能になります。
API ユーザーにとっては、Anthropic のレート制限ドキュメントが現時点での権威ある参考資料です。具体的な数値は予告なく変更されます——特定の閾値に基づいてワークフローを設計する前に、必ず確認してください。
セッション内のより単純なサブタスクには、/model を使ってより軽量なモデルに切り替えましょう。コーディングワークフローのすべてのステップに Opus が必要なわけではありません。Sonnet はコード読み取り、検索、ファイル操作を、より低い token コストで効率的に処理します。
場当たり的な修正の限界
ここが、何度も気づかされた点です。上記の修正を適用してクリーンなセッションを得る。しかし 2 週間後、別のプロジェクトでまったく同じ問題にぶつかる。同じ失敗パターンの繰り返しです。
理由は構造的なものです。これらの修正はあなたの頭の中にしか存在しない。 あるいは二度と見つからないチャットログの中。あるいは次のセッションまでに蒸発するメンタルノートの中。
Claude Code のパフォーマンス問題を修正した経験のある開発者は皆、翌週にまた同じことをしています。なぜなら、修正が何か永続的なものに紐づいていないからです。次のエージェント実行はゼロから始まります——同じコンテキスト肥大化パターン、同じリトライ挙動、同じ肥大化した skill file——前回うまくいったことを何も記録していないからです。
これは単なる個人の生産性の問題ではありません。現在のエージェントインフラが経験をどう扱うかという根本的な特性です。成功した修正はセッション終了時に蒸発してしまう。
修正を「継承可能」にする
ここから、エンジニアリングの議論がより興味深くなります。
修正がうまくいったとき——失敗ループを止めた特定のリトライ戦略、20 以上のコマンドにわたってセッションを安定させたコンテキスト圧縮パターン、不要な呼び出しを 40% 削減したツール権限スコープ——その修正には本当の価値があります。問いは、それが発見されたセッションを超えて有用であり続けるかどうかです。
EvoMap の GEP プロトコルが探求しているアプローチでは、修正がうまくいったとき、それを検証済みのアセット——遺伝子カプセル（Capsule）——としてカプセル化し、別のエージェントがゼロから再発見することなく継承できるようにします。プロトコルのループは、ローカルで進化 → 遺伝子（Gene）／Capsule バンドルとして公開 → hub で検証・ランク付け → モデルやセッションを跨いで他のエージェントが継承、という流れです。
そのエンジニアリング上の価値は「魔法の自動化」ではありません。単に、特定の条件下で機能した修正が、その条件とともに保存されるということです。品質と再利用シグナルでスコアリングされ、継承可能になる。次に同じタイムアウトパターンに遭遇したエージェントは、ゼロからやり直す必要がありません。
ある OpenHarness 実行での修復戦略が Capsule になり、POST /a2a/publish を通じて公開されます。検証を通過すれば昇格する。別のエージェント——どのハーネス上でも、どのモデル上でも動作している——が POST /a2a/fetch でフェッチして修正を継承できます。
これは上記の修正とは異なるレイヤーの話です。あれらの修正は戦術的なものです。Capsule の継承は、戦術的な修正をセッションとエージェントを跨いで持続させる試み——同じ問題を繰り返し修正するサイクルを断ち切る試みです。
Claude Code の代替ツールを検討すべきとき
Claude Code は本当に強力です。SWE-bench で 72.5% を達成しており、Codex の約 49% との間には 23 ポイントの差があります。SWE-bench は合成タスクではなく、実際の GitHub バグ修正をテストします。この差は有意です。複雑なマルチファイルの推論や大規模なコードベースリファクタリングにおいて、このパフォーマンス上の優位性は本物であり、トレードオフに見合うものです。
しかしトレードオフもまた現実であり、正直に向き合う価値があります。
token 効率が推論の深さより重要な場合： OpenAI Codex は隔離されたクラウドサンドボックスコンテナで動作し、同等のタスクに対して約 3 分の 1 の token で済みます。ChatGPT Plus（月額 20 ドル）に含まれています。トレードオフは、SWE-bench のスコアが低いことと、長文コンテキスト推論の精度が落ちることです。
モデルのロックインが問題の場合： Claude Code は Anthropic のモデル専用です。Aider（GitHub スター 40k 以上、BYOK 対応）や OpenCode（GitHub スター 112k 以上、75 以上のモデルプロバイダー）なら、タスクの種類やコストに応じて GPT-5.4、Gemini 3.1 Pro、DeepSeek を切り替えられます。Gemini CLI は 1 日 1,000 リクエスト無料で、100 万 token の context window を提供しています——軽量なワークフローには本当に魅力的な無料枠です。
レート制限が最大の制約の場合： 従量課金の API アクセス（Opus 4.6 は 100 万 token あたり入力 5 ドル／出力 25 ドル、Sonnet 4.6 は入力 3 ドル／出力 15 ドル）なら、サブスクリプション層のスロットリングなしで正確なコスト管理が可能です。レイテンシとスループットの特性はコンシューマープランとは異なりますが、本番環境のエージェントワークフローにはより予測可能です。
率直にまとめると、Claude Code はすべてのワークフローに適したツールではありません。 毎週セッション中にレート制限にぶつかる、コードを書くよりコンテキスト管理に時間を費やしている、マルチプラットフォームの非同期ワークフローを構築している——こうした場合には、上記の代替ツールがそれぞれのギャップに対処します。問いは、Claude Code のパフォーマンスの天井が、あなたのユースケースにとって運用上の制約に見合うかどうかです。
FAQ
Claude Code はなぜ長時間セッションで遅くなるのですか？
Claude Code セッションでは、各メッセージが蓄積されたコンテキスト——会話履歴、ファイル内容、tool call の出力——に追加されていきます。複雑なプロジェクトではメッセージ 10〜15 の時点で、1 リクエストあたり 150k〜200k token を送信している可能性があります。モデルは遅くなり、応答の精度は低下し、セッション予算は想定より速く消耗します。対策は先手のコンテキスト管理です。ウィンドウが飽和した後ではなく、飽和する前に /compact を使いましょう。
Claude Code の token 使用量を減らすにはどうすればよいですか？
3 つのレバーがあります。CLAUDE.md と skill file を短くする（古い指示や矛盾する指示を削除する）、ツールの公開範囲を絞る（タスクが実際に必要とする権限にスコープする）、大きなセッションを小さく区切った実行に分割する。Opus レベルの推論を必要としないタスクには /model で Sonnet に切り替えることでも、token コストを大幅に削減できます。
2026 年の Claude Code の最良の代替ツールは何ですか？
制約によります。token 効率とモデルの柔軟性を重視するなら Aider（BYOK、任意のプロバイダー）や OpenCode（75 以上のプロバイダー）。並列非同期タスクとサンドボックス隔離には OpenAI Codex（ChatGPT Plus に付属）。寛大な無料枠なら Gemini CLI（1 日 1,000 リクエスト）。ターミナルより IDE 統合を重視するなら Cursor。Claude Code は複雑な実世界のコーディングタスクでは SWE-bench で依然としてトップです——代替ツールが対処するのは、生の能力ではなく特定の運用上の制約です。
ワークフローの途中で Claude の使用制限にぶつからないようにするにはどうすればよいですか？
集中的な作業はオフピーク時間帯（平日 5am〜11am PT の外）にずらしましょう。プロジェクトは短い区切りのセッションに分割して、課金ウィンドウごとのコンテキスト蓄積を制限してください。API の利用については、Anthropic の最新のレート制限ドキュメントを直接確認してください。具体的な閾値は予告なく変更されますし、ダッシュボードの数字は 3 つの重複する制約レイヤーのうち 1 つしか反映していません。
Claude Code の修正を異なるプロジェクトやエージェント間で再利用できますか？
ネイティブにはできません。セッション内の修正はチャットログや個人のメモに残るだけで、次の実行には引き継がれません。より興味深いエンジニアリング上の問いは、成功した適応行動——特定のリトライ戦略、コンテキストパターン、ツールスコープの設定——を、他のエージェントが継承できる形で保存できるかどうかです。それこそが GEP プロトコルのドキュメントが取り組んでいるレイヤーです。成功したエージェントの行動を、セッション横断・エージェント横断の継承可能なアセットに変換する。新興のアプローチであり、解決済みの問題ではありませんが、対象としている構造的な問題——エージェントの修正がセッション単位で記憶喪失に陥ること——は、現在のエージェントインフラの本当の限界です。
2026 年を通じて、レート制限の状況がどう進展するか見守り続けます。Anthropic のインフラへの圧力は現実であり、制約の階層はドキュメントの更新が追いつかないほど速く変化しているようです。上記の修正は 2026 年 4 月時点で有効です。重要なものを構築する前に、詳細を必ず確認してください。
