問題の本質：優秀なセッション内、ゼロの記憶継続性
Claude Codeは新しいセッションを開始するたびにまっさらな状態に戻ります。あなたがタブよりスペース派であること、APIがlocalhost:3000で動いていること、昨日Dockerのアーキテクチャ問題のデバッグに3時間費やしたこと——これらをすべて忘れます。 Medium
議論を重ねたアーキテクチャ上の決断は消え、ようやくたどり着いたバグ修正は蒸発し、3回伝えたクライアントの要件を4回目に聞いてくる。まるでグラウンドホッグ・デイの繰り返しで、自分だけが毎回同じことを説明し直さなければならない。 DEV Community
ツール使用が50回に達するとコンテキストが50万トークンを超え、Claudeが遅くなってリスタートすると、何も覚えていない状態から始まります。アーキテクチャの説明に10分かかり、それがまた繰り返される。 GitHub
この問題はClaude Code固有のものではなく、すべてのステートレスなLLMが抱える構造的な制約です。ただしClaude Codeはターミナル上で長時間の複雑なタスクを処理するユースケースが多いため、影響が特に顕在化します。
Anthropic公式の設計パターン：メモリツールとフック
Anthropicはこの問題を認識し、公式ドキュメントでメモリ永続化の設計パターンを示しています。
メモリツールは、Claude Code上でファイルとして情報をセッション間に永続化する仕組みです。すべての関連情報を事前にロードするのではなく、エージェントが学んだことをメモリに保存しておき、必要なときに取り出す「ジャストインタイムのコンテキスト取得」が核心的な設計思想です。これにより、現在のコンテキストを本当に今必要なものだけに集中させます——コンテキストウィンドウを一度に埋め尽くせばアウトになる長時間ワークフローにとって重要です。 Claude API Docs
複数セッションにわたる長期ソフトウェアプロジェクトでは、メモリファイルを作業が進むにつれてアドホックに書いていくのではなく、最初から意図的にブートストラップする必要があります。このパターンはメモリを構造的な「再開メカニズム」に変え、新しいセッションが前回の終了地点から正確に再開できるようにします。最初のセッションでは何も実質的な作業を始める前にメモリの土台——進捗ログ・機能チェックリスト・初期化スクリプトへの参照——をセットアップします。 Claude API Docs
コミュニティが構築したアーキテクチャの実例
2層構造：即時コンテキストとオンデマンド検索
すべての記憶が等価ではありません。あるコンテキストは毎セッション必要ですが、あるコンテキストはたまにしか必要になりません。すべてをCLAUDE.mdに詰め込むとコンテキストウィンドウを浪費し、すべてをデータベースに入れるとClaudeが基本的な情報さえ能動的に検索しなければなりません。 DEV Community
この認識から、開発者たちは2層設計を構築しています。
Tier 1はCLAUDE.md（約150行）。信頼度とアクセス頻度でランク付けされた最重要プロジェクト知識を含むコンパクトなブリーフィングドキュメントで、自動生成・自動更新されます。Claudeはプロンプトなしで起動時に自動で読みます。Tier 2は.memory/state.json（容量無制限）。これまでに記録されたすべての事実・決断・観察の完全なメモリストアで、MCPツールを通じてキーワード検索・タグ検索・自然言語質問でアクセスできます。セッションの80%はTier 1だけで足りますが、残り20%はTier 2をオンデマンドで参照します。 DEV Community
コンテキスト圧縮時の知識保護
MemCPはClaude Codeに組み込まれたMCPサーバーで、/compactコマンドを監視します。コンパクション（コンテキストの圧縮）が発生すると、「まず作業を保存してください」という形でClaudeをブロックし、インサイトとコンテキストを実際に保存するまで処理を続けさせません。通常モードではコンパクション後にほぼすべてが失われますが、このアプローチでは保存済み知識の100%が維持されます。 DEV Community
500件のインサイトをロードする場合、通常方法では9,380トークンを消費しますが、メタデータと特定チャンクだけを参照することで462トークンに抑えられます。約20倍の削減です。 DEV Community
矛盾検出と記憶の鮮度管理
長期利用時に浮上する問題として、純粋な時系列ベースの記憶検索は直感的に思えますが、数週間の日常使用後には「話題としては関連しているが時間的に古くなった」記憶が大量に蓄積されます。一度決定され、その後覆されたものが、キーワードに一致するため競合し続けます。重要度スコアに時間減衰を追加し、強化されない古い情報が自然に競合しなくなる仕組みが必要です。 DEV Community
矛盾する記憶をフラグ立てし、上書きされた決断をstale（古い）としてマークし、真実だけが浮かび上がる設計も実装されています。過去の決定と矛盾する内容が入力されたとき、その競合を検出して通知するアプローチです。 GitHub
デバッグへの応用：仮説の追跡とコンテキスト分離
根本原因分析に特化したアプローチとして、仮説追跡と信頼度レベルを組み合わせたシステマティックなデバッグアシスタントが構築されています。また、バグ調査のような重いタスクは、メインセッションのコンテキストウィンドウを汚染しないよう、分離した新しいコンテキストでサブエージェントに担当させ、最終結果だけを返す設計が有効とされています。 GitHub
実装にあたって押さえるべき現実的な制約
記憶永続化は有効ですが、万能ではありません。設計時に考慮すべき点があります。
まず、ファイルベース検索とMCPベース検索には異なるコストがあります。ファイルをコンテキストにロードすると、Claudeがその情報を使う使わないにかかわらず、セッション全体でそのトークンを消費し続けます。MCPによる検索は複数回クエリを発行できますが、実際に必要なものだけをコンテキストに保持します。 DEV Community
次に、コンパクションとメモリを組み合わせることが長時間ワークフローには有効です。コンパクションでアクティブなコンテキストをクライアント側の管理なしに維持可能にし、メモリがコンパクションの境界を越えて重要情報を保持することで、要約で失われるものを補います。 Claude API Docs
セッション記憶の喪失は「AIの限界」として諦めるべき問題ではなく、設計で解決できるインフラの問題です。Claude Codeのフックシステム・CLAUDE.md・MCPプロトコルを組み合わせることで、プロジェクトの文脈を組織的な記憶として蓄積し続けるエージェント環境を構築できます。
