Claude Codeの「context window exceeded」エラーは、セッションのトークン上限に達して処理が停止した状態だ。対処法は /compact で履歴を圧縮する、.claudeignore で不要ファイルの読み込みを防ぐ、長いタスクをセッション分割する——この3つを押さえれば、作業が止まる事態はほぼ回避できる。
大きなリファクタをClaude Codeに任せていたら、終盤で「context window exceeded」が出て作業が止まった——よくある話だ。どこまで進んだかもわからない。ファイルを確認しても中途半端な状態で、やり直すにも経緯が頭に入っていない。
Redditや開発者コミュニティでも頻出するこの問題、予防策と復元手順をここにまとめた。これを読めば、コンテキストウィンドウの問題で作業が止まる事態はほぼ回避できる。
Claude Codeの「context window exceeded」とは何か？
「context window exceeded」はClaude Codeが処理できるトークン数の上限に達したときに出るエラーだ。「もうこれ以上会話を続けられません」という意味で、それまでの会話履歴・読み込んだファイル・生成した出力、すべてを合算した数が限界を超えると発生する。
2026年3月時点で、Claude Codeのコンテキストウィンドウはほとんどのモデルで200Kトークン、Opus 4.6とSonnet 4.6では1Mトークン に対応している。巨大に見えるが、大きなコードベースと長い会話はあっという間にこの容量を食い尽くす。
重要なのは、これは突然来るのではなく、徐々に近づいてくる という点だ。Claude Codeはセッション中にコンテキスト使用率をトラッキングしており、事前に把握する手段がある。つまり適切に監視して行動すれば、エラーが出る前に対処できる。
対策は大きく4つある。
/compactで履歴を要約して圧縮する.claudeignoreで不要なファイルをそもそも読み込まない- セッションをドメイン別に分割して長期化させない
- Plan modeで先に設計を固め、実装時のトークン消費を最小化する
それぞれを後のセクションで詳しく解説する。まず、すでにエラーが出てしまった場合の復元手順から始めよう。
エラーが出た直後にどうやって作業を復元するか？
エラーが出た時点でセッションは終了している。パニックにならず、以下の順番で状況を把握する。
Step 1: git で差分を確認する
git diff HEAD
git status
Claude Codeはファイルを変更するたびに実際にディスクに書き込む。会話が止まっても、それまでの変更はファイルシステムに残っている。git diff で何が変わったか確認すれば、作業がどこまで進んでいたか把握できる。
Step 2: 変更内容をコミットまたはスタッシュする
中途半端な状態でも、まず保存する。
git add -A
git stash push -m "claude-code session interrupted - context exceeded"
あるいは作業が完結していそうな部分だけコミットしてもいい。大事なのは、何か別の操作をする前に確実に変更を退避させること。
Step 3: 新しいセッションで続きを依頼する
新しいセッションを開始し、コンテキストを最小限にまとめて続きを依頼する。
前回のセッションでcontext window exceededが発生しました。
変更済みファイル: src/components/Header.tsx, src/lib/api.ts
残りのタスク: フッターコンポーネントの型エラー修正
関連ファイルのみ読み込んで続きをお願いします。
長い説明は不要だ。「何をするか」「どのファイルか」の2点だけ伝えれば十分。最悪のパターンは前回の会話をコピペして新しいセッションに貼ることだ——それでは本末転倒になる。
コンテキスト使用率はどうやって確認するか？
予防の第一歩は可視化だ。残りがどのくらいかわからなければ、手の打ちようがない。
/cost でトークン消費量を確認する
/cost
/cost コマンドは現在のセッションの累積トークン消費量を表示する。多くのファイルを扱う機能追加なら、20〜30分おきにチェックする習慣をつけよう。
自動コンパクションのメッセージに注意する
Claude Codeはコンテキスト使用率が約80〜85%に達すると自動的にコンパクションを実行する。自動コンパクションのメッセージが出たら、それは「もうすぐ限界」の警告だ。今のタスクを早めにまとめることを考えよう。
目安となるセッションの「重さ」
| 状況 | トークン消費の目安 |
|---|---|
| 小さなバグ修正（1-2ファイル） | 10-30k |
| 機能追加（5-10ファイル） | 50-150k |
| 大規模リファクタ（20ファイル以上） | 200k超え → 危険 |
ファイル数が増えるほど消費は急増する。「ついでにこっちも直して」を繰り返すと、あっという間に上限に近づく。
コンテキスト節約の基本姿勢
- 1セッション = 1タスクを徹底する
- 「ついでに」はしない
- 新しいタスクは新しいセッションで始める
/compactコマンドはどう使えばいいか？
/compact コマンドはセッションの会話履歴を要約して圧縮するコマンドだ。詳細なやりとりを「ここまでの作業内容の要約」に置き換え、トークン数を大幅に削減する。
/compact
要約のフォーカスを指定することもできる。
/compact 認証リファクタの決定事項にフォーカスして
こうすると、Claudeが要約する際に何を優先すべきか明示できる。会話の一部だけがまだ関係している場合に便利だ。
正しい使いどき
- コンテキスト使用率が60-70%に達したとき
- 調査・設計フェーズが終わり、実装フェーズに移るとき
- エラーのデバッグが一段落したとき
使ってはいけない場面
- 複雑な設計の議論の途中（要約で重要な前提が失われる可能性がある）
- コードの細かいニュアンスを維持したい場合
/compact は万能ではない。要約によって失われる情報もある。重要な決定事項はファイルに書き出すか、CLAUDE.mdに記録しておくと安全だ。
## 現在の作業
- タスク: ユーザー認証モジュールのリファクタ
- 決定事項: JWT → セッションCookieに変更
- 変更済み: src/auth/index.ts, src/middleware/auth.ts
- 残り: テストの更新
決定事項は /compact を実行する前にCLAUDE.mdに書き出しておこう。会話にしか存在しない情報は要約で失われる可能性があるが、ファイルに書いてあればClaude Codeがいつでも読み直せる。
.claudeignoreでトークン消費を減らすには？
コンテキスト管理で最も効果が高いのは、不要なファイルをそもそも読み込まない 設計だ。.claudeignore ファイルを使うと、Claude Codeがファイルを探索する際に除外するパターンを指定できる。
# プロジェクトルートに .claudeignore を作成
touch .claudeignore
# .claudeignore
# 依存関係（絶対に読み込ませない）
node_modules/
vendor/
.venv/
__pycache__/
# ビルド成果物
dist/
build/
.next/
out/
# 大きなデータファイル
*.csv
*.json.bak
data/raw/
# ログ・キャッシュ
*.log
.cache/
coverage/
# 設計ドキュメント（作業に不要な場合）
docs/archive/
*.pdf
# テストのスナップショット（頻繁に変わるもの）
__snapshots__/
.gitignore と似た書式で書ける。.gitignore に書いてあるものと重複する場合も多いが、.claudeignore はClaude Code専用 なので、開発には必要だがAIに読ませる必要がないファイルを細かく制御できる。
効果の実例
Next.jsプロジェクトでnode_modules/・.next/・ビルド成果物を.claudeignoreに追加すると、セッション寿命が大幅に伸びる。node_modules/だけで大量のトークン節約になる。
セッションをどう分割すれば長期作業を安全にできるか？
「1つの大きなタスク」を「複数の小さなセッション」に分割することが、コンテキスト管理の根本的な解決策だ。
分割の基準
悪い例（1セッションでやること）:
- ユーザー認証の設計
- DBスキーマの設計
- API実装
- フロントエンド実装
- テスト作成
- デプロイ設定
良い例（セッションを分ける）:
Session 1: 設計のみ（CLAUDE.mdに記録）
Session 2: DB + API
Session 3: フロントエンド
Session 4: テスト
Session 5: デプロイ
各セッションの開始時に必要な文脈だけを伝える。前のセッションの会話履歴をそのまま引き継がせようとするのが、コンテキスト爆発の最大の原因だ。
セッション間の引継ぎファイルを作る
<!-- session-handover.md -->
## 前回セッションの成果
- 認証はJWT（RSA256）で実装完了
- src/auth/ 以下のファイルが対象
- テストは書いていない
## 今回のセッションでやること
- src/auth/__tests__/ にテストを追加
- カバレッジ80%以上を目標
これをClaude Codeに渡すだけで、前の経緯を説明する長い会話が不要になる。
CLAUDE.mdを永続メモリとして使う
会話履歴と違い、CLAUDE.mdはセッションをまたいで残る。アーキテクチャの決定、命名規則、プロジェクト固有のルール——一度CLAUDE.mdに書いておけば、毎回説明し直す必要がない。文脈を毎セッション伝え直すよりはるかにトークン効率が良い。具体的なパターンはCLAUDE.md設計パターン｜コンテキスト管理術を参照。
自動コンパクションはどう制御するのが正解か？
Claude Codeには自動コンパクション機能がある。コンテキスト使用率が約80〜85%に達すると自動で要約を実行する仕組みだ。
自動コンパクションのしきい値は環境変数で調整できる。
# しきい値を70%に下げて早めにコンパクションを実行させる
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=70
完全に無効にするにはCLIの設定を使う。
claude config set -g autoCompactEnabled false
精密な作業では自動コンパクションを無効にして /compact を手動実行するほうが安全だ。要約の内容を確認してから続きに進める。
日常的なタスク（シンプルなバグ修正、小さな機能追加）なら、自動コンパクションはオンのままで構わない。サイレントにコンテキストを管理してくれるので気にならない。リスクがあるのは、精密なコンテキストの連続性に依存する作業だけだ。
context window exceededを二度と出さないための設定チェックリスト
ここまでの内容をチェックリストにまとめた。プロジェクトを始めるときに一度設定しておけば、以降はほとんど意識しなくて済む。
プロジェクト初期設定
-
.claudeignoreを作成し、node_modules/・dist/・.next/を除外 -
CLAUDE.mdに現在の作業状況と決定事項を書く習慣をつける - 自動コンパクションのしきい値を調整、または精密なプロジェクトでは無効化
セッション開始時
- 1セッション = 1タスクを守る
- 前のセッションの引継ぎ情報をコンパクトにまとめて渡す
- 関係ないファイルは絶対に読み込ませない
セッション中
-
/costで定期的にトークン消費量を確認 - コンテキスト使用率が60-70%を超えたら
/compactを実行 - 「ついでにこっちも」をやめる
- 設計の決定事項は会話に留めず即座にファイルに書き出す
エラーが起きたとき
- まず
git diffで変更内容を確認 - 変更をスタッシュまたはコミット
- 新しいセッションで最小限の文脈を渡して続きを依頼
よくある質問
Claude Codeのコンテキストウィンドウはどのくらいの大きさ？
2026年3月時点で、Claude Codeはほとんどのモデルで200Kトークン、Opus 4.6とSonnet 4.6では1Mトークンに対応している。自動コンパクションがバッファ（200Kウィンドウで約33Kトークン）を確保するため、実際に使える容量はヘッドラインの数字より少ない。
/compactを実行すると会話履歴は消える？
正確には消えるのではなく「置き換わる」。/compact は詳細な会話を要約に圧縮する。元のメッセージはコンテキストからなくなるが、重要な情報は要約として残る。続きの作業は要約を元にシームレスに続行できる。
.claudeignoreと.gitignoreは同じもの？
構文は同じだが、役割が違う。.gitignore はGitが追跡するファイルを制御する。.claudeignore はClaude Codeが読めるファイルを制御する。node_modules/ のように重複するエントリも多いが、.claudeignore ではGitが追跡しているけどAIに読ませる必要がないファイル（大きなテストフィクスチャ、アーカイブドキュメント、データファイル等）を細かく制御できる。
コンテキストウィンドウのサイズを増やせる？
ハードリミットは変更できない。モデルごとに固定されている。ただし、Opus 4.6やSonnet 4.6を使えば200Kの代わりに1Mトークンが利用可能だ。Max、Team、Enterpriseプランなら1Mウィンドウが自動的に有効になる。
/compactと新しいセッションを始めるのはどう違う？
/compact は同じセッション内で作業文脈を要約して保持する。新しいセッションは完全にゼロからのスタートだ。同じタスクの続きを軽くしたいなら /compact、別のタスクに移るなら新しいセッション——これが使い分けの基準。
Plan modeはコンテキスト使用量に効く？
効く。Plan modeを使うと、コードを書く前に設計を固められる。設計の会話でトークンは使うが、明確な計画があることで実装フェーズが速く集中的になり、結果としてノープランのコーディングセッションより総トークン消費が少なくなることが多い。
Claude Codeが編集中にクラッシュした場合、ファイルは復元できる？
Claude Codeは作業中にファイルをディスクに書き込んでいる。git diff HEAD と git status を実行すれば、何が変更されたか正確にわかる。その変更をstashまたはcommitしてから新しいセッションを始めればいい。ファイルシステム上からは何も失われていない。
セッションが思ったより早くコンテキスト切れになるのはなぜ？
よくある原因は3つ。多くのファイル（特に大きいファイル）の読み込み、長いデバッグの往復会話、そして「ついでにこっちも」のスコープ拡大。ファイル読み込みは内容全体がコンテキストに入る。.claudeignore でファイルを絞り、セッションは1タスクに集中させよう。
まとめ
「context window exceeded」は不運ではなく、設計で防げるエラーだ。
.claudeignoreで読み込むファイルを絞る- 1セッション1タスクを徹底する
- 70%超えで
/compactを手動実行する - セッション間の引継ぎはファイルで管理する
- 決定事項はCLAUDE.mdに書いてコンパクション耐性を持たせる
この5つを実践するだけで、コンテキスト切れで作業が止まる経験はほぼなくなる。大規模リファクタも、セッションをうまく分割すれば安全にこなせるようになる。
まず今すぐ.claudeignoreを作ることから始めよう。
関連記事: