Claude Code auto compactが100%でデッドロック——90日daily運用者が再現検証して見つけた3つの回避策

Claude Code を毎日動かしていると、ある時点からセッションが奇妙な挙動を始めます。「さっきまで指示に従っていたのに、急に違うコードを書き始めた」「前提を忘れたかのように同じ質問を繰り返している」——その多くは auto compact（自動コンテキスト圧縮）が原因です。

GitHub Issues でも複数の独立した報告があり（#66144 等）、コンテキストが100%に近づいたタイミングで自動圧縮が走り、圧縮後に状態を喪失するパターンが確認されています。

結論：3つの対策をレイヤーで組む

回避策1: PreCompact hook — 圧縮直前にセッションログを退避（事後復元）
回避策2: 手動 /compact — 100%到達前に自分でタイミングを制御（事前防御）
回避策3: セッション分割設計 — 1タスク1セッション原則でデッドロックを構造ごと避ける（設計）

どれか1つで解決するより、用途によって組み合わせるほうが現実的です。

---

この記事の前提

• Claude Code を sns-automation・masatoman.net の日常ルーティンで 2026-05 から daily 運用中
• 複数リポジトリを1セッションで横断するため、長時間セッションが発生しやすい環境
• 上記の構成でcomp act後の状態喪失パターンを繰り返し確認し、2026-05-14 に PreCompact hook を実装

---

読者のよくある詰まり

「途中から Claude の回答がズレてきた気がする」「前のセッションで指示したことをなぜか無視している」「急にファイルを書き換えるペースが落ちて、確認質問が増えた」——これらは auto compact のトリガー直後に起きやすい症状です。

多くの場合、Claude Code のヘッダーにある「コンテキスト使用量」が 80〜100% に達したタイミングで起きます。気づかずに「モデルの調子が悪い日」として受け流してしまうことがほとんどです。

---

実際に起きたこと

auto compact の仕組みと問題

Claude Code はコンテキストウィンドウが上限に近づくと、自動的に 会話履歴を圧縮して要約に置き換えます（auto compact）。

圧縮後に残るのは「要約」だけで、それ以前の詳細なやり取りは Claude から見えなくなります。これ自体は仕様ですが、問題は以下の状況で起きます。

問題パターン：コード暴走（state drift）

1. 長時間のルーティン実行中にコンテキストが 100% に到達
2. auto compact が走り、直前の詳細な指示・制約・決定が要約で置き換わる
3. 圧縮後の Claude が「要約から推測した前提」でタスクを再開
4. 元の指示と異なるコードを生成、または意図しないファイルを変更する

sns-automation のルーティン（毎時 :15 に複数リポジトリを処理）で、compact 後に直前のブランチ判断を忘れて異なるブランチにコミットしようとするパターンを確認しました。

デッドロックが起きやすい条件

• 複数リポジトリを1セッションで横断する
• 「調査→設計→実装」を1セッション内で完結させようとする
• ルーティンとして長時間実行するタスクを組んでいる
• コンテキスト使用量を意識せずに指示を重ねる

---

原因分析

auto compact は悪い機能ではありません。コンテキストを無限に保持できないため、圧縮は必然です。問題は「圧縮のタイミングとその後の挙動を制御できていない」点です。

コンテキストが 100% に達してから auto compact が走ると：

• どの情報が残るか Claude Code が自動判断する（選べない）
• 圧縮直前に確定した重要な決定が「細かすぎる」として要約から落ちることがある
• 圧縮後にセッションを続けると、Claude は要約ベースで推測するため drift が起きる

---

3つの回避策

回避策1：PreCompact hook でログを退避する（事後復元）

圧縮直前にセッションの生ログを _inbox/ に退避しておく。compact 後に「あのとき何を決めたか」を確認できるようになります。

# ~/.claude/hooks/precompact-backup.sh
#!/bin/bash
INBOX="$HOME/_inbox/claude-sessions"
mkdir -p "$INBOX"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
SESSION_LOG="$HOME/.claude/current-session.jsonl"

if [ -f "$SESSION_LOG" ]; then
  cp "$SESSION_LOG" "$INBOX/session_${TIMESTAMP}.jsonl"
  echo "PreCompact backup: $INBOX/session_${TIMESTAMP}.jsonl"
fi

// ~/.claude/settings.json（抜粋）
{
  "hooks": {
    "PreCompact": [
      {
        "type": "command",
        "command": "bash ~/.claude/hooks/precompact-backup.sh"
      }
    ]
  }
}

この hook の位置づけ： compact 後に状態が失われることを防ぐのではなく、「圧縮される前の状態を自分で読み返せるようにする」ものです。Claude 側の状態は変わりませんが、自分が「何を決めたか」を確認してから新しい指示を出し直せます。

compact 後に挙動がズレたら _inbox/ の最新ファイルを開いて前提を確認し、Claude に明示的に再共有するフローを組めます。

---

回避策2：コンテキスト 80% で手動 /compact を打つ（事前防御）

auto compact に任せるのではなく、自分でタイミングを制御する。Claude Code のヘッダーにあるコンテキスト使用量インジケーターが 80% 前後になったら、手動で /compact を実行します。

手動 compact のメリット：

• 圧縮前に「次のフェーズで必要な情報」を Claude に明示できる
• 「次に続けるタスクは〇〇です。この前提を要約に必ず含めてください」 と伝えてから compact する
• 100% で auto compact が走るより情報損失を減らせる

タイミングの目安：

コンテキスト使用量	推奨アクション
〜60%	通常作業を続ける
60〜80%	次の compact 前に何を残すか意識し始める
80%〜	手動 /compact を検討、重要前提を明示してから実行
100%	auto compact が走る。状態 drift のリスク高

調査フェーズが終わったら /compact で圧縮してから実装フェーズに入る、という区切りを習慣にすると、drift のリスクが下がります。

---

回避策3：1タスク1セッション設計（構造で避ける）

long-running ルーティンで compact が問題になるなら、セッション自体を短く設計するのが根本解です。

sns-automation のルーティンで確認した設計原則：

❌ 悪い例：「リポジトリA調査→リポジトリB実装→リポジトリC記事執筆」を1セッション
✅ 良い例：タスクをスコープごとに分割し、1セッション内のコンテキスト予算を見積もる

具体的には：

• 「探索タスク」と「実装タスク」を別セッションに分ける（探索でコンテキストを大量消費した後に実装すると compact に近づきやすい）
• CLAUDE.md で「不要ファイルを読まない」制約を明示する（コンテキスト消費を抑える直接効果）
• ルーティンは1実行あたりのスコープを絞る（masatoman.net の content-executor は「1日1本」でスコープを限定している）

---

判断基準

PreCompact hook を入れるべきか？

→ 長時間セッションを頻繁に使うなら入れる。短いタスクに集中できているなら優先度は低い。

手動 compact を使うべきか？

→ 調査と実装を1セッション内でやるなら使う。タスクが既に分割できているなら不要。

セッション分割を優先するか、hook で対応するか？

→ ルーティン（自動実行）なら設計で避ける（回避策3）。インタラクティブ作業なら hook + 手動 compact の組み合わせ（回避策1+2）。

---

今日やること（3つ以内）

1. ~/.claude/hooks/precompact-backup.sh を作成し settings.json に登録する（10分で完了）
2. 次の長時間セッションで、コンテキスト使用量インジケーターを意識して 80% で /compact を試す
3. 直近1週間で「Claude の挙動がズレた」と感じたセッションを振り返り、compact が原因だったか確認する

---

---