メモリシステム設計
メモリは、エージェントがセッションをまたいで継続性を維持し、蓄積された知識に基づいて推論するための永続化層を提供します。単純なエージェントはコンテキストのみに依存してメモリを保持するため、セッション終了時にすべての状態が失われます。洗練されたエージェントは、即時のコンテキストニーズと長期的な知識保持のバランスをとる階層型メモリアーキテクチャを実装します。ベクトルストアから知識グラフ、時間的知識グラフへの進化は、検索と推論の向上を目的とした構造化メモリへの投資の増大を表しています。
アクティベーション条件
以下の場合にこのスキルをアクティベートします。
- セッションをまたいで知識を永続化するエージェントを構築する場合
- メモリフレームワーク（Mem0、Zep/Graphiti、Letta、LangMem、Cognee）を選択する場合
- 複数の会話にわたってエンティティの一貫性を維持する必要がある場合
- 蓄積された知識に基づく推論を実装する場合
- 本番環境でスケールするメモリアーキテクチャを設計する場合
- ベンチマーク（LoCoMo、LongMemEval、DMR）に対してメモリシステムを評価する場合
- 自動エンティティ/関係抽出と自己改善メモリ（Cognee）を備えた動的メモリを構築する場合
他のスキルが担当する隣接作業にはこのスキルをアクティベートしないでください。
- ファイルベースのスクラッチパッド、実行ログ、ツール出力のオフロード：
filesystem-context - 会話の圧縮や人間が読める引き継ぎサマリー：
context-compression - マスキング、プレフィックスキャッシュ、トークンバジェット、単一軌道内の検索スコーピング：
context-optimization - RDF状態に基づく形式的な信念/欲求/意図モデル：
bdi-mental-states
コアコンセプト
メモリを、揮発性のコンテキストウィンドウから永続ストレージに至るスペクトラムとして考えてください。検索ニーズを満たす最も単純な層をデフォルトとします。なぜなら、ベンチマークの証拠（claim-memory-locomo-filesystem-baseline）によれば、一部のメモリワークロードではツールの複雑さよりも信頼性の高い検索の方が重要であるためです。構造（グラフ、時間的妥当性）は、検索品質が低下した場合、またはエージェントがマルチホップ推論、関係トラバーサル、タイムトラベルクエリを必要とする場合にのみ追加します。
詳細トピック
プロダクションフレームワークの状況
エージェントが必要とする主要な検索パターンに基づいてフレームワークを選択します。以下の表を使用して候補を絞り込み、その後、以下のベンチマークデータで検証します。
| フレームワーク | アーキテクチャ | 最適な用途 | トレードオフ |
|---|---|---|---|
| Mem0 | ベクトルストア＋グラフメモリ、プラグ可能なバックエンド | マルチテナントシステム、幅広い統合 | マルチエージェントには特化していない |
| Zep/Graphiti | 時間的知識グラフ、二時間モデル | 関係モデリング＋時間的推論を必要とするエンタープライズ | 高度な機能はクラウドロック |
| Letta | 自己編集型メモリと階層型ストレージ（インコンテキスト/コア/アーカイブ） | 完全なエージェント内省、ステートフルサービス | 単純なユースケースには複雑 |
| Cognee | カスタマイズ可能なECLパイプラインとカスタマイズ可能なタスクによる多層セマンティックグラフ | 適応して学習する進化するエージェントメモリ、マルチホップ推論 | インジェスト時の処理負荷が高い |
| LangMem | LangGraphワークフロー用のメモリツール | すでにLangGraphを使用しているチーム | LangGraphに密結合 |
| ファイルシステム | 命名規則を持つプレーンファイル | 単純なエージェント、プロトタイピング | セマンティック検索なし、関係なし |
エージェントが二時間モデリング（イベントが発生した時刻とインジェストされた時刻の両方を追跡）を必要とする場合はZep/Graphitiを選択します。その3層知識グラフ（エピソード、セマンティックエンティティ、コミュニティサブグラフ）が時間的クエリに優れているためです。マネージドインフラストラクチャで迅速なプロダクション化が優先される場合はMem0を選択します。エージェントがエージェント開発環境を通じて深い自己内省を必要とする場合はLettaを選択します。エージェントが高密度の多層セマンティックグラフを構築する必要がある場合はCogneeを選択します。Cogneeはテキストチャンクとエンティティタイプを詳細な関係エッジを持つノードとして階層化し、すべてのコア要素（インジェスト、エンティティ抽出、後処理、検索）がカスタマイズ可能です。
ベンチマークパフォーマンス比較
以下のベンチマークを参照して期待値を設定しますが、絶対的なランキングではなく、検索次元に関するソース固有のシグナルとして扱ってください。単一のベンチマークが決定的とは限りません。
| システム | DMR精度 | LoCoMo | HotPotQA（マルチホップ） | レイテンシ |
|---|---|---|---|---|
| Cognee | — | — | 公開高スコア | 変動あり |
| Zep（時間的KG） | 公開高スコア | — | メトリクス全体で中程度 | 低レイテンシ報告 |
| Letta（ファイルシステム） | — | 公開ファイルシステムベースライン | — | — |
| Mem0 | — | 公開特化ツールベースライン | ある比較では低い | — |
| MemGPT | 公開高スコア | — | — | 変動あり |
| GraphRAG | 公開中/高範囲 | — | — | 変動あり |
| ベクトルRAGベースライン | 公開低範囲 | — | — | 高速 |
重要なポイント：メモリシステムはブランドではなく検索の形状で比較します。ベンチマーク数値は、製品の主張を行う前に再確認が必要な過去の証拠として扱います。安定した設計ルールは、浅く始め、検索品質を測定し、より単純な層が失敗した場合にのみセマンティックまたはグラフ構造を追加することです。
メモリ層（決定ポイント）
永続化要件を満たす最も浅いメモリ層を選択します。深い層ほどインフラコストと運用の複雑さが増すため、浅い層が検索または耐久性のニーズを満たせない場合にのみレベルを上げてください。
| 層 | 永続性 | 実装 | 使用タイミング |
|---|---|---|---|
| ワーキング | コンテキストウィンドウのみ | システムプロンプト内のスクラッチパッド | 常に — 注意が向きやすい位置で最適化 |
| 短期 | セッションスコープ | ファイルシステム、インメモリキャッシュ | 中間ツール結果、会話状態 |
| 長期 | セッション間 | キーバリューストア → グラフDB | ユーザー設定、ドメイン知識、エンティティレジストリ |
| エンティティ | セッション間 | エンティティレジストリ＋プロパティ | 同一性の維持（「山田太郎」が複数の会話で同じ人物であること） |
| 時間的KG | セッション間＋履歴 | 有効性インターバルを持つグラフ | 時間とともに変化する事実、タイムトラベルクエリ、コンテキスト競合の防止 |
検索戦略
クエリの形状に合わせて検索戦略を選択します。セマンティック検索は直接的な事実検索に適していますが、マルチホップ推論では精度が低下します。エンティティベースのトラバーサルは「Xに関するすべて」のクエリを処理しますが、グラフ構造が必要です。時間的フィルタリングは変化する事実を処理しますが、有効性メタデータが必要です。精度が最重要でインフラ予算が許せば、戦略を組み合わせてハイブリッド検索にします。
| 戦略 | 使用タイミング | 制限 |
|---|---|---|
| セマンティック（埋め込み類似度） | 直接的な事実クエリ | マルチホップ推論で精度低下 |
| エンティティベース（グラフトラバーサル） | 「Xについてすべて教えて」 | グラフ構造が必要 |
| 時間的（有効性フィルタ） | 時間とともに変化する事実 | 有効性メタデータが必要 |
| ハイブリッド（セマンティック＋キーワード＋グラフ） | 全体的に最高の精度 | 最もインフラが必要 |
ハイブリッドアプローチは、関連するサブグラフまたはメモリのみを検索することでアクティブコンテキストを削減します。Cogneeは、グラフ、ベクトル、リレーショナルストアにわたる複数の検索モードを通じてハイブリッド検索を実装し、エージェントが汎用的なアプローチではなくクエリタイプに合った検索戦略を選択できるようにします。
メモリ統合
無制限のメモリ蓄積は時間の経過とともに検索品質を低下させるため、定期的に統合を実行して無制限の成長を防ぎます。無効化しても破棄しないでください — 過去の状態を再構築する必要がある時間的クエリには履歴の保存が重要です。メモリ数のしきい値、検索品質の低下、またはスケジュールされた間隔で統合をトリガーします。動作する統合コードについては、実装リファレンスを参照してください。
実践的なガイダンス
メモリアーキテクチャの選択
最も単純な実行可能な層から始め、検索品質が低下した場合にのみ複雑さを追加します。 ほとんどのエージェントは初日から時間的知識グラフを必要としません。以下のエスカレーションパスに従ってください。
- プロトタイプ：ファイルシステムメモリを使用します。事実をタイムスタンプ付きの構造化JSONとして保存します。これにより、インフラストラクチャにコミットする前にエージェントの動作を検証できます。
- スケール：エージェントがセマンティック検索とマルチテナント分離を必要とする場合、ファイルベースのルックアップでは類似度クエリを処理できないため、Mem0またはメタデータ付きベクトルストアに移行します。
- 複雑な推論：エージェントが関係トラバーサル、時間的妥当性、またはセッション間の合成を必要とする場合、Zep/Graphitiを追加します。Graphitiは汎用的な関係を持つ構造化された関連を使用し、グラフをシンプルで推論しやすく維持します。Cogneeはより高密度な多層セマンティックグラフを詳細な関係エッジとともに構築します。エージェントが時間的二重モデリング（Graphiti）を必要とするか、よりリッチな相互接続知識構造（Cognee）を必要とするかに基づいて選択します。
- 完全な制御：エージェントが深い内省を通じて自身のメモリを自己管理する必要がある場合、LettaまたはCogneeを使用します。これらのフレームワークはメモリ操作を第一級のエージェントアクションとして公開するためです。
コンテキストとの統合
すべてを事前にロードするのではなく、ジャストインタイムでメモリをロードします。大きなコンテキストペイロードはコストがかかり、アテンション品質を低下させるためです。検索したメモリは、コンテキスト内の注意が向きやすい位置（先頭または末尾）に配置して、生成への影響を最大化します。
エラーリカバリ
メモリシステムは本質的にノイズが多いため、検索の失敗を優雅に処理します。以下のリカバリ戦略を順に適用します。
- 空の検索結果：より広い検索にフォールバック（エンティティフィルタを削除、時間範囲を拡大）。それでも空の場合は、ユーザーに明確化を促します。
- 古い結果：
valid_untilタイムスタンプをチェックします。ほとんどの結果が期限切れの場合は、再試行する前に統合をトリガーします。 - 矛盾する事実：最も新しい
valid_fromを持つ事実を優先します。確信度が低い場合は、矛盾をユーザーに提示します。 - ストレージ障害：書き込みをキューに入れて再試行します。メモリ書き込みでエージェントの応答をブロックしないでください。
例
例1：Mem0統合
from mem0 import Memory
m = Memory()
m.add("ユーザーはダークモードとPython 3.12を好みます", user_id="alice")
m.add("ユーザーがライトモードに切り替えました", user_id="alice")
# 古いものではなく、現在の設定（ライトモード）を取得
results = m.search("ユーザーはどのテーマを好みますか？", user_id="alice")
例2：時間的クエリ
# 有効期間を持つエンティティを追跡
graph.create_temporal_relationship(
source_id=user_node,
rel_type="LIVES_AT",
target_id=address_node,
valid_from=datetime(2024, 1, 15),
valid_until=datetime(2024, 9, 1), # 転居
)
# クエリ：ユーザーは2024年3月1日にどこに住んでいましたか？
results = graph.query_at_time(
{"type": "LIVES_AT", "source_label": "User"},
query_time=datetime(2024, 3, 1)
)
例3：Cogneeメモリインジェストと検索
import cognee
from cognee.modules.search.types import SearchType
# インジェストしてナレッジグラフを構築
await cognee.add("./docs/")
await cognee.add("任意のデータ")
await cognee.cognify()
# メモリを豊かにする
await cognee.memify()
# エージェントが関係を認識したコンテキストを取得
results = await cognee.search(
query_text="メモリに関する任意のクエリ",
query_type=SearchType.GRAPH_COMPLETION,
)
ガイドライン
- ファイルシステムメモリから開始し、検索品質が要求する場合にのみ複雑さを追加する
- 時間とともに変化する可能性のある事実には時間的妥当性を追跡する
- 最高の精度を得るにはハイブリッド検索（セマンティック＋キーワード＋グラフ）を使用する
- メモリを定期的に統合する — 無効化しても破棄しない
- 検索失敗に備えて設計する：メモリルックアップで何も返されなかった場合のフォールバックを常に用意する
- 永続メモリのプライバシーへの影響を考慮する（保持ポリシー、削除権利）
- 変更の前後で、メモリシステムをLoCoMoまたはLongMemEvalに対してベンチマークする
- 本番環境でメモリの増加と検索レイテンシを監視する
落とし穴
- すべてをコンテキストに詰め込む：利用可能なすべてのメモリをプロンプトにロードするとコストがかかり、アテンション品質が低下します。代わりに関連性フィルタリングを使用したジャストインタイム検索を使用します。
- 時間的妥当性を無視する：事実は古くなります。有効性追跡がないと、古い情報がコンテキストを汚染し、エージェントが誤った前提で行動します。
- 早すぎる過剰エンジニアリング：単純なファイルシステムベースのメモリは、一部のベンチマーク（claim-memory-locomo-filesystem-baseline）でより特殊なツールよりも優れたパフォーマンスを発揮する可能性があります。単純なアプローチが明らかに失敗した場合にのみ、高度化を追加します。
- 統合戦略がない：無制限のメモリ増加は時間の経過とともに検索品質を低下させます。メモリ数のしきい値またはスケジュールされた間隔を設定して統合をトリガーします。
- 埋め込みモデルの不一致：ある埋め込みモデルでメモリを書き込み、別のモデルで読み取ると、ベクトル空間が交換可能でないため検索が低下します。各メモリストアに単一の埋め込みモデルを固定し、モデルが変更された場合はすべてのエントリを再埋め込みします。
- グラフスキーマの硬直性：過度に構造化されたグラフスキーマ（固定ノードタイプ、固定関係ラベル）は、ドメインが進化すると機能しなくなります。新しいエンティティ種類がスキーマ移行を必要としないように、汎用的な関係タイプと柔軟なプロパティバッグを優先します。
- 古いメモリの汚染：現在の状態と矛盾する古いメモリは、エージェントの動作を静かに破壊します。期限切れポリシーまたは信頼度減衰を実装してエージェントが古い事実を優先しないようにし、矛盾が検出された場合は明示的に表面化します。
- メモリとコンテキストの不一致：トピック的には関連しているが、コンテキスト的に間違っているメモリを取得する（例：エージェントがPythonプログラミング言語について議論しているときに「Python」というヘビに関するメモリを取得する）。メモリエントリにセッションまたはドメインメタデータを含め、検索時にフィルタリングすることで軽減します。
統合
このスキルは永続的なセマンティックメモリを担当します。隣接するスキルはスクラッチストレージ、圧縮、コンテキスト戦術を担当します。
filesystem-context：ファイルベースのスクラッチパッド、ログ、および単純な実行
…
[翻訳のために切り詰め]