2014年から個人開発を続けてきた私が、Claude Code を日常的に使うようになって最初に痛感したトラブルがあります。それは「突然セッションが止まり、これ以上続けられないと言われる」状況です。
Dolice Labs の4サイト分のコンテンツパイプライン構築でも、AdMob の収益データ集計スクリプトを組んでいるときでも、長時間の作業になると避けて通れない問題です。一度原因と対処を整理しておくと、長時間のコーディングセッションがずっとスムーズになります。
どんなエラーが出るか
Claude Code がコンテキスト上限に近づいたり超えたりすると、いくつかのパターンで警告や停止が起きます。
警告フェーズ（上限の 80% 付近）:
Claude's context window is getting full.
Use /compact to compress the conversation.
完全停止（上限超過）:
This conversation is too long to continue.
Please start a new conversation or use /compact.
API レベルで止まった場合は、ターミナルにエラーが落ちます:
{
"error": {
"type": "invalid_request_error",
"message": "prompt is too long: 210741 tokens > 200000 maximum"
}
}なぜ上限に達するのか
Claude Sonnet 4 系のコンテキストウィンドウは 200,000 トークンです。Claude Code のセッション中、以下のすべてがこの枠に積み上がります。
- 会話履歴: 自分の指示と Claude の応答の全文
- ツール実行結果: Read したファイルの内容、Bash コマンドの出力
- CLAUDE.md: プロジェクト指示ファイルの全文（セッション開始時に毎回読み込まれる）
- 過去の編集履歴: Edit / Write ツールで扱ったファイルの before/after
私が最初にこれを痛感したのは、複数のサイトに渡るコード修正を1セッションでやろうとしたときです。src/ 以下の 10 ファイルを連続で Read させて分析させただけで、1時間経たずに 150,000 トークンを超えていました。
解決策 1: /compact で会話を圧縮する
セッションを終了させずに続けたいときは、/compact コマンドが第一選択です。
/compact
このコマンドを実行すると、Claude が会話履歴を要約に置き換えてコンテキストを大幅に削減します。完了済みのファイル読み取り結果、試行錯誤のやり取りなどは要約に圧縮され、トークン数が一気に減ります。
確認が表示されることがある: 圧縮前に「この要約で続けてよいですか？」というプロンプトが出ることがあります。重要な決定事項や現在のファイルの状態が要約に含まれているか確認してから進んでください。
注意: /compact は不可逆です。一度圧縮すると元の詳細な会話には戻れません。
解決策 2: 新しいセッションで --continue する
作業が一段落ついた場面なら、クリーンな新セッションを立ち上げて続きを始める方法が確実です。
# 直前のセッションを続ける（最後のセッションIDを自動参照）
claude --continue
# 特定のセッションIDを指定して再開
claude --resume <session-id>
# セッション一覧を確認する
claude --list-sessions--continue は前回終了したセッションのサマリーを引き継いで新しい会話を開始します。ファイルの詳細内容は引き継がれないため、重要なコンテキスト（「どのファイルのどの関数を修正していたか」など）は最初のメッセージで明示して伝え直すことが必要です。
解決策 3: タスクを小さく分割する設計
根本的な対処は、大きな作業を独立した小さなセッションに分けることです。私が採用している方針をいくつか挙げます。
1セッション = 1コミット分の変更に絞る
「このリポジトリの全体的な品質を改善して」ではなく「src/lib/content.ts の getArticle 関数の戻り値に highlights フィールドを追加して」のように、セッション開始時のスコープを小さく定義します。
必要なファイルだけを指定する
# 悪い例（全ファイルをコンテキストに詰め込む）
# "src/ フォルダ全体を見て問題を探して"
# 良い例（対象を絞ってから指示）
# "src/lib/content.ts を見て、getArticle 関数の型定義を確認して"中間成果物はこまめにコミットする
セッションが強制終了してもコミット済みの内容は残ります。「ここまで完了」というチェックポイントを細かく作っておくと、次のセッションで git log --oneline -5 を見せるだけで状況を伝え直せます。
予防策: コンテキストを節約する習慣
長時間セッションをこなすうちに、これらを意識するようになりました。
CLAUDE.md はコンパクトに保つ
プロジェクトの指示ファイルが膨らむとセッション開始時から大量のトークンを消費します。実際に使わなくなったルールや古い設計メモは定期的に削除するか、別ファイルに分離するのが効果的です。
コマンド出力を絞り込む
# トークンを消費する例
git log --stat # 各コミットのファイル変更一覧まで出る
# 節約版
git log --oneline -10 # 直近10件のサマリーだけ大きなファイルは必要な行数だけ読む
Claude Code の Read ツールは offset と limit パラメータで読み込む行数を絞れます。「ファイル全体を見せて」ではなく「150〜250行目だけ見せて」のように指示するとトークン消費を抑えられます。
/clear との違いを把握しておく
/compact と似たコマンドに /clear があります。
/compact: 会話履歴を要約に置き換える（コンテキストを維持したまま削減）/clear: 会話履歴を完全にリセットする（まっさらな状態に戻る）
途中まで積み上げた判断経緯を消してはいけないとき（設計の議論中など）は /compact を、新しい独立したタスクに切り替えるときは /clear が向いています。
まとめ
コンテキスト上限に達したとき、対処の優先順位はこうなります。
作業の続行が必要 → /compact でその場で圧縮する。
一段落ついている → --continue または --resume で新セッションを開始する。
長期的な改善 → タスクの粒度を小さくし、こまめにコミットする習慣をつける。
「1セッション = 1コミット分の変更」という意識で作業すると、コンテキスト問題だけでなく、作業の見通しもよくなります。実際にこの方針に切り替えてから、途中停止によるロスが大幅に減りました。