32blogby Studio Mitsu

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

Claude Codeが指示を忘れる原因をメモリ層から解説。/compact・/clearの使い分け、Auto-Compactionの罠、長時間セッション安定化テクニックまで。

by omitsu20 min read
Claude Codecontext-managementproductivityCLAUDE.md
目次

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

Claude Codeが指示を忘れるのは、コンテキストウィンドウから古い情報が押し出されるか、Auto-Compactionで要約される際に文脈が失われるからだ。 対策はシンプルで、永続的なルールはCLAUDE.mdに書き、/compact と /clear を適切に使い分け、重要な決定を会話の中だけに残さないこと。

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

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

CLAUDE.md毎セッション自動読込常に存在Auto MemoryClaudeが自動記録セッション中蓄積コンテキスト窓モデルにより容量変動溢れると圧縮Auto-Compaction容量超過で自動圧縮

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

Claude Codeのコンテキストウィンドウは使用するモデルによって異なる。標準で約200,000トークン、一部モデルでは最大100万トークンに対応している。いずれにしても、実際の開発作業では驚くほど速く埋まる。

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

  • CLAUDE.mdファイル（1ファイルあたり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で要約される ——コンテキストウィンドウが容量の80〜85%程度に達すると自動圧縮が発動し、会話履歴が要約される。要約の過程で「なぜその決定をしたか」という文脈が失われ、Claudeが別の方針を取り始める

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

メモリ層を理解する

Claude Codeには複数のメモリ層があり、より具体的なスコープのものほど優先される。公式ドキュメントに詳しい解説がある。

優先度メモリ層誰が書くかいつ読み込まれるか
最高Managed Policy組織管理者（IT/DevOps）常時（除外不可）
Project CLAUDE.mdチーム（プロジェクトルート）毎セッション
User CLAUDE.mdあなた（~/.claude/CLAUDE.md）毎セッション
Subdirectory CLAUDE.mdチーム（サブディレクトリ）該当ディレクトリのファイル読み込み時
.claude/rules/*.mdチーム（ルールファイル）globパターンに一致時
最低Auto MemoryClaude自身MEMORY.md の先頭200行

ほとんどの個人開発者が使うのはProject CLAUDE.md、User CLAUDE.md、Auto Memoryの3つだ。

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

僕が32blogの初期にやったミスは、プロジェクト固有のルールを ~/.claude/CLAUDE.md（ユーザーレベル）に書いてしまったこと。Project CLAUDE.mdに優先されて事実上無視されていた。プロジェクト固有のルールはプロジェクトルートに書こう。

チームで開発しているなら、.claude/rules/*.md が便利だ。paths フロントマターでファイルごとに適用ルールを切り替えられる——たとえば frontend.md は src/components/**/*.tsx を触るときだけ読み込まれる。コンテキストの節約になる。

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として記録し、次のセッションでも守られる。フィードバックを蓄積していくと——「コミットにCo-Authored-Byを入れない」「提案する前に必ずコードを読んで裏取りする」など——同じ指摘を繰り返す手間がなくなる。

MEMORY.md は200行が上限。 先頭200行だけがセッション開始時に読み込まれる。200行を超えた部分は無視される。Claudeは MEMORY.md を簡潔なインデックスとして維持し、詳細なメモは debugging.md や api-conventions.md など別ファイルに移動する。これらは必要なときにオンデマンドで読み込まれる。

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

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

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

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

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

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

/compact — 会話を圧縮する

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

bash
> /compact

公式ドキュメントが明確にしている重要な点がある: CLAUDE.mdは圧縮の影響を受けない。 /compact 後、Claudeはディスクから CLAUDE.md を再読み込みしてセッションに注入する。圧縮後に指示が消えたように感じたら、それは会話の中だけで伝えた指示で、CLAUDE.mdには書いていなかったということだ。

使うべきタイミング:

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

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

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

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

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

bash
> /clear

使うべきタイミング:

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

判断フローチャート

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

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

Auto-Compactionの罠と対策

Auto-Compactionは、コンテキストウィンドウの容量が80〜85%程度に達すると自動で発動する圧縮機能だ。手動の /compact とは異なり、 予告なく発動する。

なぜ問題になるのか

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

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

対策

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

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

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

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

3. Hooksで自動退避する

PreCompact Hookを設定すると、圧縮直前にスクリプトを実行できる。trigger フィールドで手動（/compact）か自動かを判別できる。

json
{
  "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。 次のタスクに前のコンテキストを引きずらない
  • 重要な決定が出たらファイルに書き出す。 会話の中だけで決めない

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

markdown
# 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ではさらに複数エージェントが並列で動作し、それぞれがフルのコンテキスト予算を使える。

たとえば「フロントエンドのリファクタリング」と「APIのテスト追加」を別エージェントに任せれば、1つのセッションでコンテキストが競合する問題を回避できる。

よくある質問

CLAUDE.mdは/compactで消える？

消えない。/compact 後、Claudeはディスクから CLAUDE.md を再読み込みしてセッションに注入する。圧縮されるのは会話履歴だけで、CLAUDE.mdファイルとAuto Memoryは影響を受けない。

CLAUDE.mdとAuto Memoryの違いは？

CLAUDE.mdはあなたが定義するルール——コーディング規約、ワークフロー、アーキテクチャの決定など。Auto MemoryはClaudeがあなたの修正やフィードバックから学んだこと。ルールはCLAUDE.md、蓄積した知識はAuto Memoryという使い分けが基本だ。

コンテキスト使用量を確認するには？

/context コマンドを実行する。システムプロンプト、ツール、メモリファイル、会話履歴、空き容量のトークン内訳が表示される。

Auto-Compactionは無効にできる？

Auto-CompactionはClaude Codeの組み込み機能で、直接無効にはできない。最善の対策は、容量が限界に達する前に手動で /compact する、タスクごとにセッションを分割する、重要な決定を会話ではなくファイルに書き出す——この3つを習慣にすることだ。

MEMORY.mdが200行を超えるとどうなる？

先頭200行だけがセッション開始時に読み込まれる。超過分は無視される。Claudeは MEMORY.md を簡潔なインデックスとして管理し、詳細なメモは別ファイルに分離してオンデマンドで読み込む。

/clearでAuto Memoryは消える？

消えない。/clear が削除するのは会話履歴だけだ。~/.claude/projects/<project>/memory/ にあるAuto Memoryファイルはそのまま残り、次のセッション開始時に再読み込みされる。

CLAUDE.mdのルールを複数プロジェクトで共有できる？

できる。~/.claude/CLAUDE.md（ユーザーレベル）に書けば全プロジェクトに適用される。チームで共有したい場合は、.claude/rules/ にシンボリックリンクを貼って共有ディレクトリを参照する方法がある。

サブエージェントに独自のメモリを持たせられる？

持たせられる。サブエージェントは独自のAuto Memoryを維持できる。設定方法はサブエージェントメモリのドキュメントを参照してほしい。

まとめ

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

対策実践方法
ルールを忘れさせないCLAUDE.mdに書く。会話の中だけで決めない
学習を蓄積するAuto Memoryに任せる。フィードバックは明示的に伝える
コンテキストを管理する/context で30分ごとに確認。70%超えたら /compact
タスクを区切る1タスク完了 → /clear。次のタスクに引きずらない
Auto-Compactionに備える重要な決定はファイルに書き出す。PreCompact Hookで自動退避
セッションを引き継ぐsession-handoff.md を更新。Auto Memoryだけに頼らない

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

その他のClaude Codeガイドは記事一覧からどうぞ。

関連記事: