Claude Codeのコンテキストウィンドウ: なぜ早く枯渇するのか、管理方法を解説

2026年3月下旬、Anthropicのエンジニアリングチームが珍しい声明を発表した: ユーザーが「予想よりはるかに早く」Claude Codeの使用制限に達しているというものだ。これはほぼ即座にr/ClaudeAIで最も議論されたスレッドのひとつになった。

フラストレーションは理解できる。セッションの途中で、モデルがようやくコードベースを理解し始めた頃に — コンテキストフル、品質低下、セッションの再起動が必要になる。

実際に何が起きていて、どう修正するかを解説する。

コンテキストウィンドウが予想より速く埋まる理由

Claude Codeのコンテキストウィンドウは、Max/Team/EnterpriseプランのOpus 4.6では技術的には最大100万トークンをサポートしている。しかし、持続的な高品質出力のための実用的な限界はそれより低い — 理論上のキャパシティと実用的なキャパシティのギャップが、多くの人が混乱するところだ。

あまり意識していないかもしれないが、いくつかのものがトークンを消費している:

ツール出力は冗長だ。 Claudeがbashコマンドを実行したり、ファイルを読んだり、ツールを呼び出すたびに、出力がコンテキストに入る。500行にマッチするgrepは500行のコンテキストだ。失敗した時に長いスタックトレースを出力するテストスイート? それが全部ウィンドウに入る。

CLAUDE.mdはセッションごとにロードされる。 CLAUDE.mdが2,000トークンなら、最初のメッセージの前に2,000トークンが消費される。複数のコンパクションがある長いセッションでは、その都度リロードされる。

明示的に読んだファイルはコンテキストに残る。 人間と違って情報を「脇に置いておく」ことはできない。Claudeはコンパクションかセッション再起動まで読んだものをすべて抱える。

会話履歴自体が成長する。 メッセージ、Claudeのレスポンス、やり取り — これが積み上がる。詳細なレスポンスが続く50メッセージのセッションは、会話履歴だけで数万トークンを消費する。

並列サブエージェントの結果。 複数のサブエージェントを実行して、それらが冗長なサマリーを返すと、それらのサマリーすべてが一度にメインコンテキストに入る。

実際の使用状況を測定する

最適化する前にベースラインを把握する。Claude Codeは各レスポンスの下にトークン使用量を表示する。--verboseフラグで詳細を確認できる:

claude --verbose

大きなスパイクがどこで起きるかを観察する。たいていは: 大きなファイルの読み込み、冗長な出力のコマンド、大量のテキストを返すサブエージェントのいずれかだ。

対策1: .claudeignore

ほとんどのコードベースで最も高いインパクトをもたらす単一の変更。.gitignoreと同じ構文でプロジェクトルートに.claudeignoreファイルを作成する:

# ビルド成果物
dist/
build/
.next/
out/

# 依存関係
node_modules/
vendor/
.venv/
__pycache__/

# 生成ファイル
*.lock
*.min.js
*.min.css
coverage/
.nyc_output/

# 大きなデータファイル
*.csv
*.sql
*.dump
data/

# エディタ・OSファイル
.DS_Store
.idea/
.vscode/
*.log

.claudeignoreがあれば、プロジェクトに存在していてもClaudeはこれらのファイルを読まない。典型的なNode.jsプロジェクトでは、node_modules/を除外するだけで、Claudeの検索可能範囲から数百万のポテンシャルトークンを取り除ける。

Claudeが実際に読んでいるものを確認:

claude --verbose 2>&1 | grep "Reading file"

自動生成されたクライアントコード、ロックファイル、カバレッジレポートなど、予想外のファイルを読んでいるかもしれない。

対策2: CLAUDE.mdを軽量化する

CLAUDE.mdは頻繁にリロードされる。その中のすべてのトークンがオーバーヘッドだ。包括的にしたい気持ちはわかる — すべての規約、すべての制約、すべてのコンテキスト。それに抵抗する。

CLAUDE.mdに適用するルール:

Claudeの動作を変えるものだけ含める。 命令がデフォルトとは違うことをClaudeにさせないなら、削除する。

CLAUDE.mdに例を入れない。 コード例は別ファイルに移してパスを参照する。Claudeはオンデマンドでファイルを読める — ベースコンテキストに例を抱える必要はない。

履歴やChangelogを入れない。 CLAUDE.mdはプロジェクトログではない。歴史的なコンテキストは別の場所へ。

ドメイン固有のコンテキストにはサブエージェントを使う。 複雑なバックエンドの規約と複雑なフロントエンドの規約がある場合、両方を1つのCLAUDE.mdに詰め込まない。ドメイン固有のシステムプロンプトを持つサブエージェントを作る。

ほとんどのプロジェクトで、軽量なCLAUDE.mdは500トークン未満であるべきだ。2,000超ならすべてのセクションを精査して問う: これはClaudeの動作を変えるか、それとも自分が安心したいだけか?

対策3: コンパクション戦略

コンパクション（/compact）は会話履歴を密なサマリーに圧縮して、大きなコンテキストスペースを解放する。Claude Codeは制限に近づくと自動的にこれをするが、自然な区切りポイントで手動でトリガーできる。

コンパクションのタイミング:

別々のフェーズの作業が完了した後（調査完了、実装フェーズへ）
消化済みの冗長な結果をサブエージェントが返した後
Claudeが初期のコンテキストを追えなくなり始めた時（コンテキストが満杯になっているサイン）
同じセッション内で新しいタスクを開始する前

コンパクションが失うもの: 会話の逐語的な履歴全文。保持するもの: 重要な決定事項、コードの現状、アクティブな指示。

メンタルモデル: タスクの境界でコンパクションする — タスクの途中ではない。タスクの途中でコンパクションすると、Claudeが辿っていた推論の連鎖を失うリスクがある。

コンパクション後は、Claudeに現在の状態を要約させるか、アクティブな制約を繰り返させることで、必要なコンテキストがまだあるか確認する。

対策4: 新しいセッションをもっと頻繁に始める

これは後退のように感じる — コンテキスト構築に30メッセージを費やした後でなぜ再起動するのか? しかし、集中した初期プロンプトを持つ新鮮なセッションは、何時間も動いてきた膨れたセッションよりも良いパフォーマンスを出すことが多い。

新しいセッションを始めるタイミング:

別の無関係な機能に移る時
完全な作業単位が完了した後（PRマージ、バグ修正）
レスポンスの品質が低下し始めたと気づいた時（コンテキスト圧迫の症状のことが多い）
タスクが履歴を必要としないほど自己完結している時

新しいセッションのための集中した開始プロンプトを書くのに30秒かかる。その30秒で、新鮮な100万トークンの予算と、6時間分の蓄積されたコンテキストを処理しようとしていないモデルを得られる。

対策5: ツール出力の冗長性をコントロールする

Bashコマンドは膨大な出力を返すことがある。よくある犯人:

# プロジェクト内のすべてのファイルパスを返す
find . -type f

# 何千行も返す可能性がある
npm test

# infoレベルのログで溢れる
docker logs my-container

冗長なコマンドはフィルター経由でパイプして、Claudeにも同じようにさせる:

テストスイートを実行するが、パスしたテストではなく失敗のみ見せて。
Dockerログを確認するが、ERRORとWARNレベルのみフィルターして。

Bashの出力をファイルにパイプして、Claudeに関連セクションだけ読ませることもできる:

npm test 2>&1 > /tmp/test-output.txt
# その後: /tmp/test-output.txtを読んで失敗のみサマリーして

対策6: 調査作業をサブエージェントに委任する

不慣れなライブラリ、サードパーティの依存関係のバグ、普段は作業しない大きなコードベースの部分を調査している場合 — それはサブエージェントの仕事だ。

調査タスクは最悪のコンテキスト消費者だ。ドキュメントを読んで、参照を辿って、例を確認する — これは答えを得たら多くが不要になる何千ものトークンを追加する。

AGENTS.mdにresearcherサブエージェントを作成する:

## researcher
description: 具体的な技術的質問に答えるためにドキュメント、GitHubのissue、ソースコード、外部リソースを調査する。答えと関連するファイルパスを含む簡潔なサマリーを返す。不慣れなライブラリを理解したり外部コードのバグを追跡する時に使う。
tools: read, bash, web_search
model: claude-sonnet-4-6

そして委任する:

researcherサブエージェントを使って、Prismaがサーバーレス環境でのコネクションプーリングをどう扱うか調べて。
関連する設定オプションを含む3段落のサマリーを返して。

調査は別のコンテキストで行われる。答えを得る。メインのコンテキストウィンドウは影響を受けない。

読み取り一回フック

r/ClaudeAIコミュニティのワークアラウンドスレッドに現れた上級パターン: SessionStartフックを使って一度コンテキストをロードし、Claudeが同じファイルを繰り返し読むのを防ぐ。

settings.jsonにフックを作成する:

{
  "hooks": {
    "SessionStart": [
      {
        "type": "command",
        "command": "cat /path/to/project-context.md"
      }
    ]
  }
}

フックの出力はセッション開始時に一度コンテキストに注入される。Claudeは会話の途中でファイルを再読みするのではなく、初期化時にこれを読む。会話中にClaudeが繰り返し取得するアーキテクチャドキュメントやAPIリファレンスに特に有効。

まとめ: コンテキスト効率的なセッションワークフロー

コンテキストを効率的に使うセッションの全体フロー:

Claude Codeを開く前: .claudeignoreが最新かどうか確認。最近やっていなければCLAUDE.mdを500トークン未満にトリム。
セッション開始時: タスクをスコープする集中したプロンプトを渡す。何でも詰め込まない — Claudeは今日のタスクに関係ない歴史的コンテキストを必要としない。
セッション中: 検索させるのではなく明示的なファイルパスを使う。冗長なコマンドはフィルター経由でパイプ。調査をサブエージェントに委任する。
自然な区切りポイント: コンパクション。Claudeの作業状態を確認する。無関係なタスクに切り替えるなら新しいセッションを始める。
品質が低下した時: 無理に続けない。コンパクションするか新しいセッションを始める。コンテキスト圧迫は発見しにくい微妙な推論の失敗を引き起こし、誤った出力をデバッグするまで気づけないことがある。

本質的な問題: 使用制限とコンテキスト制限

混同されることが多い2つの別問題を区別する価値がある:

コンテキストウィンドウ圧迫は、ウィンドウが埋まっていくにつれた品質低下に関するもの。これは徐々に低下し、管理は完全にあなたのコントロール下にある。

使用制限は、Anthropicのレート制限 — 1時間またはセッションあたりの最大消費トークン数 — に関するもの。これはサーバー側であり、直接コントロールはできないが、コンテキストをより効率的に使えば衝突頻度を減らせる。

上記のテクニックは主にコンテキストウィンドウ圧迫に対処する。使用制限については: MaxプランとTeamプランはProより実質的に高い制限を持っており、Anthropicは2026年3月のユーザーからの苦情を受けてキャパシティを増加させた。Proプランで本格的な開発作業をしているなら、制限は本当に制限的だ — これは設定の問題ではなく、プランのミスマッチだ。

コンテキストを効率的に管理しても使用制限をなくすことはできないが、衝突頻度を減らして、制限に達するまでセッションを生産的に長く保てる。