AIエージェント2026-07-13

AI Agentの記憶設計を徹底比較：2025年の主要プロダクトに見る多層メモリアーキテクチャの最前線

エグゼクティブサマリー

過去1年間で、AI Agentの「記憶」設計は「コンテキストウィンドウにできるだけ多くの履歴を詰め込む」アプローチから、より工学的な多層体系へと明確に移行した。現在のコンテキストをワーキングメモリとして扱い、会話履歴やスクリーントレース・ログをエピソード記憶、安定した好み・ルール・知識要約を意味記憶、そしてルール・スキル・プロセステンプレートを並行的な「手続き記憶」に近い外化層として実装する動きが広がっている。

Anthropic、OpenAI、Cursor、Hermesなどのプロダクトはインターフェースこそ異なるものの、すべて同じ問題を解決しようとしている。それは、限られたコンテキスト、許容可能なレイテンシ、制御可能なコストの中で、Agentに持続的で一貫性があり監査可能な長期状態を提供することだ。

4つのアーキテクチャ分類

近年のプロダクト実装をアーキテクチャ別に整理すると、大きく4つの類型に分かれる。

1. ファイル型メモリ

Claude Code、Hermes、OpenClawなどが代表的。長期記憶をMarkdownファイルやディレクトリに落とし込む方式で、監査・編集・マイグレーションが容易だが、構造が弱く検索の精緻さに制限がある。

2. セッションストア＋検索型メモリ

HermesのSQLite+FTS5、OpenClawのLanceDB、Cursorのコードインデックスなどが該当。スケーラブルでオンデマンドのリコールが可能だが、インデックスの鮮度・並行性・一貫性・コストの管理が必要になる。

3. バックグラウンド凝縮型メモリ

Codex Memories、OpenClaw Dreaming、Hermesの外部プロバイダ同期などが代表例。「いつ書き込むか、何を書くか、いつマージするか」をメインの対話から分離する。

4. 事前リコール型サブエージェントメモリ

OpenClaw Active Memory、Hermesプロバイダプリフェッチなど。まず記憶を呼び出してから回答する」というステップを前置し、重要なコンテキストの見落としを防ぐ。

多層メモリアーキテクチャの全体像

現在最も堅実な実装は、「統一された万能メモリDB」ではなく、2〜3層の記憶構造である。

第1層：小さく安定した永続注入型インデックス（プロンプトキャッシュを保護）
第2層：大容量で安価なオンデマンド検索層（必要に応じてリコール）
第3層：バックグラウンドのリフレクション／コンパイル層（原始エピソードから再利用可能な事実・嗜好・関係を抽出）

graph TD
    A[ワーキングメモリ<br/>現在のコンテキストウィンドウ] --> B[エピソード記憶<br/>会話・操作履歴・ログ]
    B --> C[バックグラウンド凝縮<br/>Dreaming / コンソリデーション]
    C --> D[意味記憶<br/>ルール・嗜好・知識要約]
    A --> E[常駐インデックス<br/>MEMORY.md / CLAUDE.md]
    D --> E
    E --> F[オンデマンド検索<br/>セッションDB / ベクトル検索]
    F --> A

これは学術研究とも同期している。Generative Agentsの「関連性＋時間的新規性＋重要性」による記憶想起、MemoryBankの忘却曲線の導入、LongMem/MemGPTの階層化メモリ、そしてMem0の「抽出→マージ→検索」をデプロイ可能なプロダクションシステムとして実装する流れだ。

主要プロダクト比較

Claude Code：軽量で可視性の高いローカルメモリ

記憶の形態：CLAUDE.mdによる永続的な指示とauto memory。セッション内ではcompactionも実行
ストレージ：ローカルファイルシステム。リポジトリごとにmemoryディレクトリを配置
特徴：ユーザーがファイルを開いて編集・削除できる透明性。モデル自身が何を記憶すべきかを判断し、MEMORY.mdは先頭200行または25KBに制限
セキュリティ：auto memoryはマシンローカルで、API memory toolはclient-sideおよびZero Data Retentionをサポート

Codex Memories：スレッド間の后台抽出モデル

記憶の形態：ローカルの跨スレッド記憶。Chronicleによるスクリーンコンテキスト強化、AGENTS/skillsによる手続き記憶の外化
ストレージ：ローカルMarkdownファイルをsummaries / durable entries / recent inputs / supporting evidenceの4層に分離
更新戦略：アクティブまたは短命なスレッドをスキップし、rate limitが逼迫した場合は抽出を見送る。バックグラウンドでconsolidationを実行
注意点：Chronicleのローカルファイルは暗号化されておらず、プロンプトインジェクションのリスクが増加する

Cursor：コード理解とコンテキスト発見に特化

記憶の形態：Rules / AGENTS.md / Skillsによるテキスト指示と、コードインデックス（syntactic chunks + embeddings）
インデックス技術：Merkle treeによる増分変更検知、simhash + content proofsによるチーム内のセキュアなインデックス再利用。これにより類似コードベースの初回クエリ時間を時間単位から秒単位に短縮
コンテキスト取得：Agentがgrep・semantic search・Explore subagentで自らコンテキストを取得
制約：個人アシスタント的な跨セッション自動記憶については、Codex MemoriesやClaude Codeのauto memoryのような独立したレビュー可能な製品レベルの定義は公開されていない

OpenClaw：多層プラットフォーム型メモリ

記憶の形態：MEMORY.md長期記憶 + memory/YYYY-MM-DD.md日記層 + DREAMS.md。Active Memory・memory-wiki・QMD・LanceDB・Honchoをオプションで追加
Dreaming機能：light / deep / REMの3相で短期シグナルを去重・スコアリングし、長期記憶へ昇格。grounded snippetsのみ昇格を許可
検索：embeddings・キーワード・ハイブリッド検索をサポート。Active Memoryは主回答前にブロッキング型のサブエージェントでリコール
セキュリティ：プライバシーとオーソリゼーションを明確に区別。マルチユーザー共有時のセッション/メモリ分離≠ホスト権限分離であることを明記

Hermes：安定プレフィックスとプロバイダプラグイン

記憶の形態：内蔵MEMORY.md + USER.md + session_search + 8種の外部memory providers + Honcho / Skills / Context Files
ストレージ：~/.hermes/state.db（SQLite WAL + FTS5）。外部プロバイダはクラウド／セルフホスト可
プロンプトキャッシュ戦略：cached system promptとAPI呼び出し時のオーバーレイを分離。内蔵メモリはセッション開始時のfrozen snapshotとして動作し、実行中の書き込みはディスクに反映するが現在のプロンプトは変更しない
圧縮戦略：文字数上限を厳格に設定。50%でプレチェック、85%でゲートウェイ閾値をトリガーし、まずmemoryをflushしてから最新N件のメッセージを保護

記憶のライフサイクル管理

成熟したmemoryシステムは「どこに保存するか」だけでなく、ライフサイクル全体を見る必要がある。

書き込みの閾値管理

Claude CodeとCodexはどちらも「毎ラウンド書き込み」を避ける。Claudeはモデル自身が記憶すべき内容を判断し、Codexはアクティブまたは短命なスレッドをスキップする。記憶の書き込みにはコストがかかり、早すぎる書き込みはまだ不安定な中間結論を固定化してしまうからだ。

短期層から長期層への凝縮

OpenClawが最も代表的で、作業層（memory/YYYY-MM-DD.md）と長期層（MEMORY.md）を明確に区分し、Dreamingで昇格を行う。Hermesはより保守的で、長期記憶を約1,300トークン規模に制限し、超過時はconsolidateまたはreplaceを必須としている。

リコール戦略

現在のベストプラクティスは「すべての長期記憶を事前に注入する」のではない。Anthropicはcompaction・tool clearing・memoryの組み合わせを明確に提唱し、OpenClawはActive Memoryサブエージェントによるブロッキング型リコールを、Hermesはプロバイダのプリフェッチを採用している。

再利用可能な設計パターン

設計パターン	解決する問題	メリット	トレードオフ	適用場面
常駐インデックス＋オンデマンド詳細	跨セッションの重要事実記憶とトークン節約の両立	起動コンテキストを小さく安定させる	エントリインデックスの品質に依存	コーディング・リサーチ・Ops
エピソード層と意味層の分離	長い履歴に対して再利用可能な事実が少ない	マージ・圧縮・忘却・provenance管理が容易	抽出ルールの策定が必要	長期コラボレーション・個人エージェント
事前リコールエージェント	メインエージェントが「思い出すべきことを思い出せない」	リコールを強制的な前置ステップに	可視レイテンシの増加	個人アシスタント・カスタマーサポート
バックグラウンド凝縮	未安定の結論が長期記憶に混入するリスク	汚染を低減しコストを后台に移動	新規記憶の可視性に遅延	デスクトップアシスタント・コーディングワークフロー
ハイブリッド検索	コード・ログ・パス・コマンドはベクトル検索に不向き	キーワード・ディレクトリ・記号名・セマンティクスすべてに頑健	重み調整・重複排除・rerankが必要	コードベース・Wiki・Opsランブック
フリーズスナップショット	長いセッションでのシステムプレフィックス変更によるコスト増	プロンプトキャッシュのヒット率を向上	セッション内新規記憶が即座に反映されない	高頻度マルチターンセッション
ソース証明と監査コンパイル層	記憶の自動化に伴う誤記憶・インジェクション汚染	grounding・解釈性・削除能力の向上	実装の複雑化	企業エージェント・コンプライアンス
プラグイン型メモリプロバイダ	一つのmemoryがすべての要件を満たせない	底層のmemoryを交換可能に	プロバイダ間のセマンティクス不整合	プラットフォーム型Agent・B2B/SaaS

実践的なアドバイスがあれば、それはこれだ：まず双層メモリを作り、次にリフレクション層を作り、最後に複雑なグラフ層を構築する。 「常に読み込まれる小さなインデックス」と「オンデマンドで検索する大きなコーパス」を分けるだけで、ほとんどの実際の問題は解決できる。

評価・セキュリティ・エンジニアリング制約

評価指標

「セグメントを検索できるかどうか」だけでは不十分だ。合理的な指標には少なくとも以下の5カテゴリが必要となる。

リコール品質：hit@k、evidence precision、grounding consistency
行動利益：タスク完了率、跨セッション一貫性、重複質問の削減率
効率性：p50/p95レイテンシ、トークン消費、インデックス再構築時間
ライフサイクル品質：false remember rate、鮮度、競合解決成功率、削除伝播遅延
運用性：復旧能力、バックアップ復旧時間、可観測性カバレッジ

Mem0がLOCOMOで強調しているように、メモリアーキテクチャは回答の正答率だけでなく、p95レイテンシとトークンコストにも強く影響する。

セキュリティとプライバシー

現在のプロダクトは2つの方向に分かれる。ファイル型メモリはユーザーが理解・削除しやすいが、ローカルの平文問題が生じやすい。Codex Chronicleはメモリファイルが暗号化されていないことを明確に警告している。一方、OpenClawとHermesはスキャンと分離を重視し、メモリエントリとコンテキストファイルに対するインジェクション／リークスキャンを実施している。

企業プロダクトにとっての核心は「暗号化の有無」だけではない。スコープ（作用域）、証明、監査、最小権限、削除能力、外部コンテキストがmemoryに入る閾値を包括的に管理する必要がある。

スケーラビリティと運用

memoryシステムはデータベースおよび分散インデックスシステムとして運用されるものであり、プロンプトのテクニックだけでは到底足りない。HermesのSQLite WALによるマルチリード・シングルライト、CursorのMerkle treeによるチーム内インデックス再利用、Codexのmemory summaryのバージョニングなど、公開されている工学的詳細からその傾向は明らかだ。

可観測性とデバッグ

memoryはもはやブラックボックスであってはならない。チームが「この記憶はどこから来たのか、なぜリコールされたのか、削除後にどのくらいで反映されるのか、インデックスはどのくらいの頻度で更新されるのか」に答えられない場合、そのmemory層はおそらく本番成熟期に到達していない。

結論

AI Agentの記憶設計は、単なる「ベクトルDBに保存する」問題ではなくなっている。Claude CodeやCodexのような軽量で可視性の高いファイル型から、OpenClawやHermesのような多層プラットフォーム型まで、選択肢は多様化している。ただし、どのアプローチを選んでも、記憶の書き込み閾値・ライフサイクル管理・セキュリティの内蔵は避けて通れないエンジニアリング課題だ。まずシンプルな双層構造から始め、必要に応じて段階的に複雑化していくことが、最も現実的なアプローチとなるだろう。