Claude Codeを長時間使っていると、
突然Claudeが「どのデータベースを使っていますか？」と質問してくることがあります。
2時間かけて設計した内容。
修正したバグ。
確立したパターン。
これらすべてを忘れてしまうのです。
Redditで興味深い議論を見つけました。
この「コンパクション健忘症」と呼ばれる問題についてです。
あるエンジニアが開発したナレッジグラフベースの解決策が紹介されていました。
本記事では、その議論から得られた知見を整理してお伝えします。
コンパクション問題とは何か
Claude Codeにはコンテキストウィンドウの制限があります。
そのため、長いセッションになると、AIは古い情報を要約して圧縮しなければなりません。
この処理が「コンパクション」です。
問題は、要約の過程で重要な文脈が失われてしまうこと。
アーキテクチャの決定事項。
特定のバグへの対処方法。
プロジェクト固有の規則。
こういった情報が消えると、Claudeは同じ質問を繰り返します。
すでに解決した問題を蒸し返すこともあります。
よくあるアドバイスは「CLAUDE.mdに書き留めておけばいい」というもの。
しかし、これは手動作業です。
すべてを書き留める時間はありません。
そして、重要だと気づかなかった情報は記録されないのです。
ナレッジグラフによるアプローチ
Reddit上で紹介されていたのは、MCPサーバーとして動作する記憶管理システムです。
単純なCRUD操作ではありません。
記憶同士を自動的に関連付けるナレッジグラフを構築するという発想でした。
このシステムの核となる機能を見ていきましょう。
セマンティックリンキング
記憶を保存する際、埋め込みベクトルの類似度に基づいて自動的にリンクを作成します。
認証システムに関する2つの記憶があったとしましょう。
タグが完全に異なっていても、意味的な類似性から接続されます。
従来のRAGでは、検索クエリに一致するものだけを返します。
しかし、このアプローチでは関連する文脈も一緒に取得できるわけです。
検索フィードバックループ
ここが面白いところです。
検索を行うたびに、返された記憶の重要度が強化されます。
さらに、同時に返された結果同士の間にリンクが生成されます。
つまり、あなたの検索パターンがナレッジグラフの形を決めていくのです。
よく一緒に参照される情報は、より強く結びつきます。
矛盾検出
1月に「PostgreSQLを使う」と言い、3月に「MongoDBを使う」と言った場合。
このシステムは両方の情報を黙って保持しません。
矛盾として検出し、フラグを立てます。
開発が進むにつれて方針が変わることはよくあります。
古い決定と新しい決定が混在していると、AIの回答も一貫性を失います。
矛盾を明示的に管理する仕組みは、長期プロジェクトで特に価値があるでしょう。
短期記憶から長期記憶への昇格
単なる重複排除ではありません。
関連する短期記憶をクラスタリングします。
そして、一貫性のある長期記憶へとマージします。
断片的な3つの記憶が、構造化された1つの記憶になるイメージです。
人間の記憶の働きに近いものがありますね。
PreCompactフックの仕組み
議論の中で「キラー機能」として挙げられていたのが、PreCompactフックでした。
これはClaude Codeのコンパクション処理にフックする仕組みです。
重要なコンテキストが要約される前に自動抽出します。
手動で「これを覚えておいて」と指示する必要はありません。
コンパクションが走る前に自動的に実行されます。
コンパクション後にはget_contextで復元できます。
コメント欄での議論
この投稿には様々な意見が寄せられていました。
いくつか興味深いものを紹介します。
代替アプローチ：コンパクションを避ける
あるコメントでは、そもそもコンパクションを避けるアプローチが提案されていました。
タスクを適切なサイズに分割する。
良いタイミングでセッションを引き継ぐ。
そういった方法です。
オリジナルのセッションファイル自体が、すべての詳細を含む「信頼できる唯一の情報源」だという考え方も示されていました。
新しいセッションを開始する際に元のセッションパスを注入する。
サブエージェントを使って任意の詳細を回復する。
そんなアイデアです。
複雑な記憶システムを構築するのではなく、シンプルに元データを参照する。
これも一つの有効な戦略でしょう。
技術的な批判
「それは本当のグラフではない。埋め込みをクラスタリングしているだけ。基本的に普通のRAGだ」という批判もありました。
開発者の回答によれば、確かに現在のグラフは埋め込み類似度と記憶リンクから構築されているとのこと。
正式なオントロジーではありません。
ただし、以下の機能があり、「単なるRAG」とは言えないと主張していました。
- 重要度スコアリング
- 時間減衰
- 短期から長期への昇格
- 矛盾検出
- 関係リンキング
標準的なRAGは何かを忘れたりしません。
何が保持する価値があるかを判断することもありません。
この点が違いだと。
将来的には、エンティティ抽出と明示的な主語-述語-目的語のトリプルを構築することも視野に入れているようです。
本格的なオントロジカルグラフへの拡張ですね。
実用上の問題点
「動かない」という声もありました。
具体的には以下のような批判です。
- ドキュメントが詳細なのに不正確で混乱を招く
- ダッシュボードが機能しない
- 自動でグラフを構築してくれると思ったら手動でrememberを呼ぶ必要がある
開発者はこれらのフィードバックを受けて対応しました。
セットアップ手順を見直し、ドキュメントを再構成したと報告しています。
npmでセットアップコマンドを実行すれば、フックが自動的にインストールされるとのこと。
手動でrememberを呼ぶ必要はなくなるそうです。
まだ開発が始まったばかりのプロジェクトです。
フィードバックを受けて改善を続けている段階のようでした。
ローカルで完結する設計
このシステムはSQLiteとローカル埋め込みを使用しています。
クラウド依存がありません。
データがローカルに留まる点は、セキュリティや機密性を重視する環境では重要な特性です。
外部サービスに依存しないため、オフライン環境でも動作します。
データ漏洩のリスクも低減されます。
記憶システムの設計から学べること
このプロジェクトと議論から、AIエージェントの記憶管理について考えるヒントが得られます。
まず、単純な保存と検索だけでは不十分だということ。
記憶同士の関連性。
時間による減衰。
矛盾の管理。
こういった要素が、「使える」記憶システムには必要です。
次に、ユーザーの行動パターンを学習する仕組みの価値。
検索フィードバックループのように、使うほど賢くなる設計は、長期的に大きな差を生みます。
そして、複雑なシステムと運用のシンプルさのバランス。
どれだけ優れた設計でも、セットアップが難しければ使われません。
PreCompactフックのような「自動で動く」仕組みが、実用性を左右します。
まとめ
Claude Codeのコンパクションによる記憶喪失は、長時間のコーディングセッションで深刻な問題となります。
CLAUDE.mdへの手動記録という従来のアプローチには限界があります。
そのため、ナレッジグラフベースの自動記憶管理は一つの解決策として注目に値します。
セマンティックリンキング。
検索フィードバック。
矛盾検出。
記憶の統合。
これらの機能は、単純なRAGを超えた設計思想を示しています。
一方で、「本当のオントロジカルグラフではない」という批判もあります。
セットアップの難しさといった課題も存在します。
代替として、コンパクションを避けてセッションを適切に分割する方法もあります。
元のセッションファイルをサブエージェントで参照する方法も議論されていました。
どのアプローチが最適かは、プロジェクトの性質や個人のワークフローによって異なるでしょう。
AIエージェントの記憶管理は、まだ発展途上の分野です。
こうした試みとコミュニティでの議論から、より良い解決策が生まれていくことを期待しています。
