Claude Codeが忘れる原因と対策 完全ガイド

「さっき言ったルール、もう忘れてるじゃん」——Claude Codeを使っていて、この不満を感じたことがないだろうか。

セッション序盤は完璧に指示に従っていたのに、1時間も経つと「そんなルール聞いてません」という顔でコードを書き始める。これはClaude Codeのバグではない。 コンテキストウィンドウの仕組みを理解していないと、必ず起きる問題だ。

この記事では、Claude Codeが「忘れる」メカニズムを根本から解説し、6つのメモリ層の使い分け、/compact と /clear の正しい判断基準、そしてAuto-Compactionの罠を回避する方法まで、実務で使える対策をまとめた。

なぜClaude Codeは指示を忘れるのか

Claude Codeのコンテキストウィンドウは約200,000トークン。巨大に聞こえるが、実際の開発作業では驚くほど速く埋まる。

コンテキストを消費するもの:

• CLAUDE.md（2,000〜5,000トークン）
• Auto Memory の MEMORY.md（200行上限）
• ソースコードの読み込み（500行のファイル1つで約5,000トークン）
• 会話履歴（やり取りが長くなるほど蓄積）
• ツール呼び出しの結果（ファイル読み込み、検索結果など）

10個のファイルを読み込んで30分会話するだけで、100,000トークン以上を消費することも珍しくない。

「忘れる」の正体は2つある:

1. コンテキスト窓から押し出される ——古い情報が窓の外に出ると、Claudeはそれを参照できなくなる。CLAUDE.mdに書いたルールが「忘れられた」ように見えるのは、ルールが会話履歴の奥に埋もれて注意が向かなくなるから
2. Auto-Compactionで要約される ——167,000トークン付近で自動圧縮が発動し、会話履歴が要約される。要約の過程で「なぜその決定をしたか」という文脈が失われ、Claudeが別の方針を取り始める

どちらの場合も、 情報の「存在」ではなく「配置」の問題 だ。正しい場所に正しい情報を置けば、忘れられない。

6つのメモリ層を理解する

Claude Codeには6つのメモリ層があり、優先順位がある。上にあるものほど優先される。

ほとんどの個人開発者が使うのは 2, 3, 6 の3つだ。

Project CLAUDE.md（層3） がコンテキスト管理の要。ここに書いたルールはセッション開始時に必ず読み込まれる。逆に言えば、 ここに書かないルールは忘れられるリスクがある。

チームで開発しているなら、層5の .claude/rules/*.md が便利だ。globパターンでファイルごとに適用ルールを切り替えられる。たとえば frontend.md はフロントエンドのファイルを触るときだけ読み込まれる。

CLAUDE.mdの書き方のパターンについては「Claude Codeコンテキスト管理：CLAUDE.md設計パターン」で詳しく解説している。

Auto Memoryの仕組みと活用法

Auto Memoryは、Claude自身がセッション中に学んだことを自動で記録する仕組みだ。~/.claude/projects/<project>/memory/ ディレクトリにファイルが保存され、MEMORY.md がインデックスとして機能する。

Auto Memoryが記録するもの:

• ビルドコマンドやテスト規約
• デバッグで得た知見
• アーキテクチャ上の決定
• コードスタイルの好み
• あなたの作業パターン

Auto Memoryが記録しないもの:

• コードの内容そのもの（コードベースを読めばわかる）
• 一時的な作業状態（「今このファイルを編集中」など）
• git履歴から読み取れる情報

使い方のコツ

明示的にフィードバックすると記録される。 「テストではモックを使わないで」と伝えると、Auto Memoryがfeedbackとして記録し、次のセッションでも守られる。

MEMORY.md は200行が上限。 先頭200行だけがセッション開始時に読み込まれる。超過すると警告が出る。定期的に古いエントリを整理しよう。

# Auto Memory を確認・管理する
> /memory

CLAUDE.md と Auto Memory の使い分け:

• CLAUDE.md → あなたが決めたルール。「TypeScript strictを使え」「テストはVitestで書け」
• Auto Memory → Claudeが学んだこと。「このユーザーはシニアエンジニアだ」「前回のセッションでDBスキーマを変更した」

両方に同じことを書くとトークンの無駄遣いになる。ルールはCLAUDE.md、学習はAuto Memoryと割り切ろう。

/compact と /clear の正しい使い分け

セッションが長くなったとき、コンテキストを管理するコマンドは2つある。判断を間違えると、必要な情報を失う。

/compact — 会話を圧縮する

会話履歴を要約し、トークンを大幅に削減する。重要な決定や方針は保持されるが、 詳細なやり取りの文脈は失われる。

> /compact

使うべきタイミング:

• 同じタスクを継続したいが、コンテキストが重くなってきた
• /context で確認して使用率が70%を超えている
• Claudeの応答速度が落ちてきた

使ってはいけないタイミング:

• タスクが完了して次の作業に移るとき（/clear の方が適切）

/clear — コンテキストをリセットする

会話履歴を完全に削除する。CLAUDE.mdとAuto Memoryは再読み込みされる。

> /clear

使うべきタイミング:

• タスクが完了して次の作業に切り替える
• Claudeが明らかに古い文脈に引きずられている
• 「何かおかしい」と感じたとき（リセットが最速の解決策）

判断フローチャート

「タスクは続くか？」→ Yes → /compact / No → /clear

この判断を迷ったら /clear を選ぶ方が安全だ。CLAUDE.mdとAuto Memoryがあれば、コンテキストのほとんどは復元される。

Auto-Compactionの罠と対策

Auto-Compactionは、コンテキストが約167,000トークンに達すると自動で発動する圧縮機能だ。手動の /compact とは異なり、 予告なく発動する。

なぜ問題になるのか

Auto-Compactionは会話を要約するが、要約の過程で 「なぜその決定をしたか」 という文脈が失われることがある。たとえば:

• 「Supabase Authを使う理由はRLSとの統合が必要だから」→ 圧縮後は「Supabase Authを使う」だけが残る
• 決定の理由が消えると、Claudeが別の方針を提案し始める

対策

1. 重要な決定はファイルに書き出す

会話の中だけで決まった状態を作らない。重要な決定は docs/decisions.md やCLAUDE.mdに書き出す。ファイルに書かれた情報はコンテキスト圧縮の影響を受けない。

2. セッションを分割する

1タスク = 1セッションを基本にする。認証フロー、DBスキーマ変更、大規模リファクタリングなど、精密な制約がある作業は特に分割が重要だ。

3. Hooksで自動退避する

PreCompact Hookを設定すると、圧縮直前にスクリプトを実行できる。重要な状態をファイルに自動保存する仕組みを作れる。

{
  "hooks": {
    "PreCompact": [
      {
        "matcher": "auto",
        "hooks": [
          {
            "type": "command",
            "command": "bash scripts/save-session-state.sh"
          }
        ]
      }
    ]
  }
}

長時間セッションを安定させる実践テクニック

ここまでの知識を踏まえて、実務で使えるテクニックをまとめる。

セッション開始時のルーティン

1. /context でコンテキスト使用量を確認（前セッションの残りがないか）
2. CLAUDE.mdが今日のタスクに合っているか確認
3. 前回のsession-handoff.mdがあれば参照させる

セッション中のモニタリング

• 30分ごとに /context を確認する。 使用率70%を超えたら /compact を検討
• タスクが完了したら即 /clear。 次のタスクに前のコンテキストを引きずらない
• 重要な決定が出たらファイルに書き出す。 会話の中だけで決めない

セッション終了時の引き継ぎ

# session-handoff.md

## 完了したこと
- src/auth/login.ts をJWTからSupabase Authに移行
- 既存テスト全パス

## 次のセッションでやること
- src/auth/register.ts を同じ方針で移行
- middleware.ts の認証チェックを更新

## 制約・注意
- Supabase RLSは有効のまま
- NEXT_PUBLIC_SUPABASE_URL は .env.local に設定済み

Auto Memoryがあっても、 「次にやること」はsession-handoff.mdに手書きする方が確実 だ。Auto Memoryは「Claudeが重要と判断したこと」を記録するが、あなたの作業計画まで正確に記録するとは限らない。

Agent Teams でコンテキストを分散する

大規模な作業では、Agent Teamsを使ってタスクを並列化できる。各エージェントが独立したコンテキストウィンドウを持つため、1つのセッションでコンテキストが溢れる問題を回避できる。

たとえば「フロントエンドのリファクタリング」と「APIのテスト追加」を別エージェントに任せれば、それぞれ200,000トークンをフルに使える。

まとめ

Claude Codeが「忘れる」のはバグではなく、コンテキストウィンドウの仕組みによる制約だ。正しく対策すれば、長いセッションでも安定した品質を維持できる。

「忘れられた」と感じたら、まずCLAUDE.mdを見直してみてほしい。情報の量ではなく配置を最適化するだけで、体験は大きく変わる。

関連記事:

• Claude Codeコンテキスト管理：CLAUDE.md設計パターン
• Claude Codeのトークン消費を50%削減した方法
• Claude Codeで「context window exceeded」が出たときの対処法