Claude Codeがセッション途中で”前提を忘れる”のはオートコンパクティングが原因──仕組みと完全対策ガイド

「さっき決めた命名規則を守らなくなった」「絶対にやらないでと言ったのにやり始めた」「序盤の設計方針と矛盾するコードを書いてくる」――Claude Codeを長いセッションで使っていると、こうした「途中でアホになる」現象に遭遇することがあります。

これは使い方が悪いわけでも、Claude Codeの品質が低いわけでもありません。コンテキストウィンドウが一定量を超えると、古い会話を自動要約するオートコンパクティングが発動することが主な原因です。

この記事では、オートコンパクティングの仕組みを理解したうえで、「重要情報を守る」ための具体的な対策を網羅します。コスト管理の全体像はコスト管理完全ガイド、コンテキスト最適化の設計論はコンテキストエンジニアリングガイドも参照してください。

オートコンパクティングの仕組み

Claude Codeは会話のやり取りをコンテキストウィンドウに保持しながら動作します。このウィンドウには上限があり（claude-opus-4-6なら200K、Sonnetなら200K）、使用量が約83.5%に達すると、古い会話を自動的に要約・圧縮します。これがオートコンパクティングです。

80%付近でコンテキスト使用率の警告が表示され始め、83.5%で発動します。33Kのバッファは、コンパクション後のレスポンス生成に使われる領域です。

コンパクションが起きても会話が消えるわけではありません。「削除」ではなく「要約」です。ただし、要約は完璧ではないため、細かいニュアンスや否定形の指示が抜け落ちることがあります。

何が消えて何が残るか

オートコンパクティングで特に落ちやすい情報と残りやすい情報には、はっきりとした傾向があります。

つまり、Claudeは「何を作っているか」は残っても、「なぜそうしているか」を落としやすいのです。命名規則を破り始めたり、別方針のコードを書き始めたりするのは、この「なぜ」が消えた結果です。

対策①：CLAUDE.mdにCompact Instructionsを書く

CLAUDE.mdはコンパクション後に自動再読み込みされます。ここに重要な方針を書いておくことで、コンパクションが起きても「毎回注入される情報」として機能します。

さらに、# Compact instructionsセクションを設けると、オートコンパクティングの要約時に「保持を優先する観点」を指示できます。

# プロジェクト概要
TypeScript + Next.js 15（App Router）のECサイト

# 絶対に守る設計方針
- コンポーネントはServer Componentsをデフォルトにする
- ファイル名はkebab-case、コンポーネント名はPascalCase
- エラーハンドリングは必ずResult型を使う（throwしない）
- テストはVitestとReact Testing Libraryを使う

# 現在の作業状態
- 実装中: カートシステム（src/features/cart/）
- 次のタスク: 決済フローの実装

# Compact instructions
When compacting, preserve:
- The Result<T, E> error handling pattern (never throw)
- The kebab-case/PascalCase naming rules
- The Server Component priority rule
- Current task progress and file paths

Compact instructionsに書くべき内容は「要約から落ちると困るもの」です。命名規則・設計制約・否定系の指示を中心に記載するのが効果的です。

CLAUDE.mdの詳細な書き方はCLAUDE.md完全ガイドを参照してください。

対策②：手動/compactで観点を指定する

自動発動を待たずに、作業の区切りで手動で/compactを打つのが最も確実な方法です。引数に観点を渡すことで、要約品質が大きく上がります。

# 基本（引数なし）
/compact

# 観点を指定（推奨）
/compact Focus on the auth module and current test failures

# API設計の判断を保持
/compact Keep the API design decisions and error handling patterns

# 型定義を保持
/compact Preserve all TypeScript type definitions and Result<T,E> pattern

なぜ手動の方が良いか：自動発動は観点の指定ができません。また、83.5%ギリギリで発動するため、複雑な文脈が多く残った状態で圧縮されます。60〜70%の段階で手動コンパクトすれば、情報量が少ない状態での圧縮になり要約品質が上がりやすいです。

対策③：CLAUDE_AUTOCOMPACT_PCT_OVERRIDEで閾値を早める

環境変数CLAUDE_AUTOCOMPACT_PCT_OVERRIDEで、オートコンパクティングの発動閾値を変更できます。

# シェルで直接設定
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=75

# settings.json に恒久設定（推奨）
# ~/.claude/settings.json
{
  "env": {
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "75"
  }
}

閾値を早めるとコンパクションの頻度が上がりコストが増える点に注意してください。品質と頻度のトレードオフです。長い設計議論や重要な制約が多いプロジェクトでは75が、通常の開発では設定しない（デフォルト83.5%）でよいことが多いです。

対策④：/wrapup → /clear → /catchup ワークフロー

コンパクションに頼らず、明示的にセッションを区切る方法です。Claude Codeの公式ドキュメントも推奨するワークフローで、コンテキストを完全にリセットしながら重要な状態を引き継げます。

# ステップ1: 現在の作業状態をCLAUDE.mdに保存
/wrapup
# → Claudeが作業の要約をCLAUDE.mdに書き込む

# ステップ2: コンテキストを完全にリセット
/clear
# → 会話履歴をすべてクリア（コンテキスト使用量がゼロに）

# ステップ3: 新しいセッションで続きから再開
/catchup
# → CLAUDE.mdを読み込んで作業状態を復元

このワークフローの利点は、「コンパクションに任せる」のではなく「人間が意図的に区切りを設ける」点です。/wrapupで書き込む内容を確認・編集できるため、引き継ぐ情報を自分でコントロールできます。

対策⑤：大きな出力をコンテキストに流し込まない

コンテキストをすぐに埋める原因のひとつが、大量のコマンド出力をそのまま会話に流すことです。

# NG: ログをそのままClaude Codeに送る
# → 数千行のログがコンテキストを圧迫

# OK: ファイルに書き出してから参照させる
npm test 2>&1 | tee test-output.txt
# → "test-output.txtを読んでエラーを分析して" と依頼

# OK: エラー行だけに絞る
npm test 2>&1 | grep "FAIL\|Error\|×" > test-errors.txt

同様に、git log --oneline -100のような長い履歴や、大量のAPIレスポンスも直接流し込まず、ファイル経由で必要な部分だけを参照させるのが効果的です。

対策⑥：Auto MemoryとMemory MCPを活用する

Claude Code v2.1.59以降では、プロジェクトの重要情報を自動でメモリファイルに記録するAuto Memory機能が搭載されています。コンパクションが発生しても、メモリファイルは消えません。

# Auto Memoryのon/offを切り替え
/memory

# 保存場所
~/.claude/projects/<project-path>/memory/
  MEMORY.md        # インデックス（常時ロード）
  user_role.md     # ユーザー情報
  feedback_*.md    # フィードバック
  project_*.md     # プロジェクト情報

Auto Memoryの詳細、およびより強力な長期記憶システム（SQLite+ベクトル検索）の構築方法はClaude Codeメモリ戦略完全ガイドを参照してください。

オートコンパクティングを無効化する

特定のユースケースでオートコンパクティングを完全に無効化したい場合は、~/.claude.json（settings.jsonではなく.claude.json）に設定を追加します。

{
  "autoCompactEnabled": false
}

無効化した場合は、コンテキストが100%に達するとセッションが強制終了します。/wrapup→/clearワークフローを手動で管理するか、定期的に/compactを実行してください。

対策まとめ：優先度別チェックリスト

よくある質問