MemCurrent：プロダクションエージェントのための永続メモリ設計

AIツールによって、エージェントのバイブコーディング（vibe code）は容易になりました。しかし、本番環境でエンタープライズ向けエージェントを構築・維持することは、依然として大きな課題です。特に開発者は、品質（特にロングテールタスクで適切な回答を得ること）と効率性（大規模環境でのコストとレイテンシの抑制）のトレードオフを迫られることがよくあります。多くの場合、ある次元での利点は別の次元での犠牲を伴います。

メモリは、両方を同時に改善するための有望なアプローチです。メモリを活用することで、エージェントはユーザーの好み、以前の修正内容、メトリクス定義、成功したワークフローなどの有用なコンテキストをタスク間で共有できます。原理的には、これにより精度が向上し、繰り返しのエラーが減少し、無駄な再発見を回避できます。しかし、履歴が多ければ優れたメモリになるというわけではありません。過去のあらゆるやり取りを提供することはコストがかかり、古くなった情報、矛盾する情報、無関係なコンテキストを持ち込む原因になります。中心となる課題は、何を保持し、どのように維持し、どのように有用性を測定するかを決定することです。

本記事では、本番用エージェント向けの永続的メモリアーキテクチャである MemCurrent を紹介します。これは現在、新しい Agent Bricks Memory や Genie の原動力となっています。エージェントは作業しながらメモリを読み書きし、オフラインの「ドリーミング（dreaming）」パイプラインがメモリを統合して、一貫性と最新性を維持します。現実的なエンタープライズタスクから作成された内部ベンチマークでは、MemCurrentはメモリなしの場合と比較して、トークン使用量を31%削減し、処理速度を26%向上させながら、エージェントのパス率（達成率）を3倍に高めました。本記事の残りでは、その設計および評価方法と、そのプロセスで得られた知見について解説します。

図1. 内部メモリベンチマークにおけるタスクあたりのパス率対トークン数。MemCurrentはパレートフロンティア上にあり、品質と効率の両方の次元でMem0、PropMem、OpenClawメモリを上回っています。

メモリの設計方法

エージェントにメモリを組み込む方法は3つあります。プラグインとして組み込む方法（MemAlign や Memory Scaling に関する当社の以前の研究と同様）では、セッション内の定められた時点でメモリが自動的に読み書きされます。ツールとして組み込む方法では、エージェントがいつ、何を読み書きするかを判断します。オフラインパイプラインとして組み込む方法では、スケジュールやトリガーに基づいてバックグラウンドでメモリが更新され、以降のセッションで使用されます。それぞれにトレードオフが存在します。

表1. メモリの3つのアクセスパターン：プラグイン、ツール、オフラインパイプライン

MemCurrentは、これら3つすべてをそれぞれの適材適所で組み合わせて使用しています。

図2. MemCurrentの概要

MemCurrentには2種類のメモリがあります。生のセッションのトレースを保持するエピソードメモリ（episodic memory）と、これらのトレースから抽出された学習内容を構造化ナレッジベース内のファイルとして保存する派生メモリ（derived memory）です。トップレベルには自動生成された memory.md インデックスが配置され、ファイル構造と各ファイルの内容を保持しています。

エピソードメモリと派生メモリはどちらも、低レイテンシで応答し、多数のユーザーにスケール可能な本番グレードのデータベース内に保持されます。エピソードメモリは追記専用であり、セッションの実行中にプラグインが各ステップをログ出力します。派生メモリは階層型ファイルシステムを擬似的に表現した変更可能なテーブルであり、書き込みは2つの方法で行われます。エージェントツール（add_memory, update_memory, delete_memory）は、「/tmp ディレクトリには絶対にスクリプトを書き込まないでください」といった明示的なリクエストを処理します。オフラインのドリーミングパイプラインはそれ以外を扱い、新しいセッションから暗黙的な学習内容を抽出して関連するファイルに集約します。また、ストア全体のクリーンアップ（過剰に大きなファイルの分割、重複の統合、矛盾の解消など）も行います。

読み込みはレイヤー構造で動作します。セッション開始時にプラグインがメモリインデックスを注入するため、エージェントは開始前に自身が何を知っているかを把握できます。セッション中、エージェントは両方のメモリタイプで機能する2つのツールを利用できます。search_memory はクエリに対して最も関連性の高い結果（過去のトレースのステップ、またはメモリファイル内の特定の行）を返し、fetch_memory は識別子（セッションIDまたはファイルパス）によってエントリ全体を返します。

メモリの評価方法

ベンチマーク

まず、広く使われている3つのオープンソースベンチマーク（LoCoMo、LongMemEval、ConvoMem）から検証を開始しました。これらはすべて、自由形式の合成会話において、エージェントが過去に言及された事実を想起できるかどうかをテストします。

さらに当社では、ユーザーがデータに関して多様な質問を行う実際の Genie の会話から「内部メモリベンチマーク」を構築しました。図3に示すように、12,000以上のセッションからスタートし、メモリとして残す価値のあるシグナルを含む3,000の候補を抽出し、評価基準（ルーブリック）を設けた追加の質問を作成しました。同じユーザーによるその他のセッションは、テストケースのダミー（フィラー）として機能します。その後、敵対的ジャッジ（adversarial judge）が「ナレッジが実際に存在するか」「ユーザー固有のものか」「回答に必須か」「自然か」「検証可能か」などの7つの基準に基づいて各テストケースをチェックしました。最終的な手動レビューを経て、このベンチマークは29人のユーザー、2,233の履歴セッション、合計114のテストケースで構成されています。

図3. 内部メモリベンチマークの構築プロセス

例を以下に示します。

図4. 内部メモリベンチマークのテストケース例。過去のセッションで、ユーザーはエージェントによるテーブルの選択を修正し、バックグラウンドでのリクエストを除外するように指示します。その後、エージェントは異なるものの関連する質問に直面し、100以上のセッションの中から該当するセッションを見つけて学習した内容を適用する必要があります。出力結果は、ルーブリックリスト（一部はメモリ依存、一部はタスク固有）に基づいてLLMジャッジによりスコアリングされます。

当社のベンチマークは、既存のものと比べて次の3つの点で異なります。

エンタープライズ領域。既存のベンチマークは、シミュレートされたペルソナの生活に関するオープンエンドなチャットです。私たちのベンチマークは、テーブルのセマンティクス、メトリクス定義、ワークフローなどの豊富なエンタープライズ知識を含む、データワークスペースでの実際の業務に基づいています。

メモリは回答ではなく、アクションに反映されます。 過去の会話から適切な文字列を見つけるだけでは不十分であり、エージェントは検索した知識を適用してマルチステップのタスクを完了する必要があります。

多様性。 テストケースは、5つのメモリタイプ（プロファイル、設定、ドメイン知識、プロジェクト、ワークフロー）と11のシナリオ（直接の指示、変更または古くなった事実、マルチセッションの集計、メモリに依存しない質問など）を組み合わせたものです。 

結果

MemCurrentを、同じ基盤LLMを使用する3つのオープンソースメモリバックエンド（Mem0、PropMem、OpenClaw memory）と比較します。 

オープンソースベンチマーク。 各メモリバックエンドを、2つのエージェントハーネス（LangGraphおよびOpenAI Agents SDK）で構築されたシンプルな質疑応答エージェントとペアリングします。また、メモリなしの下限と、すべての過去セッションがエージェントのコンテキストに入るフルコンテキストの上限という2つのベースラインも実行します。3つのベンチマークすべてにおいて、MemCurrentはすべてのメモリバックエンドの中で最高のスコアを記録し、コスト対精度のパレートフロンティアを維持しています。平均して、MemCurrent（88.1%）はフルコンテキスト（87.8%）と同等のパフォーマンスを、質問あたりの入力トークン数を約12分の一に抑えて（8.4K対103K）達成しています。履歴が最も長い2つのベンチマークでは、プロンプトにすべてを投入することでエージェントが混乱してしまうフルコンテキストを上回りさえしました。 

図5. (a) LoCoMo（19〜32セッション/サンプル）、(b) LongMemEval（s分割）（38〜62セッション/サンプル）、(c) ConvoMem（500サンプルの層化サブセット、100セッション/サンプル）におけるメモリバックエンドのコスト対精度¹のトレードオフ。エージェントモデルおよびメモリモデルとしてGPT 5.6 lunaを使用しています。すべてのメモリバックエンドはプラグインとして実行され、セッション開始時に質問に関連するメモリを自動的に検索してエージェントコンテキストに挿入します。² 精度はLangGraphおよびOpenAI Agents SDKハーネスと3回の繰り返し処理の平均値です。コストは質問あたりの平均入力トークン数（対数スケール）です。

社内メモリベンチマーク。当社のベンチマークでは、その差がさらに広がります。ここでは、各メモリバックエンドは、ベンチマークセッションの送信元と同じ社内Genie内で実行されます。履歴が長すぎてコンテキストに収まらないため、上限としてゴールドのメモリ（正解メモリ）のみをエージェントのコンテキストに挿入するゴールドインジェクションを設定しています。すべてのメモリバックエンドの中で、MemCurrentは最高の合格率（68.4%）、最小のレイテンシ（252秒）、最小のトークン使用量（418K）を達成し、メモリなし（22.3%）とゴールドインジェクション（78.6%）の間のギャップの80%以上を埋めました。特に、Mem0は以前のベンチマークではフロンティア上にありましたが、ここでは43.9%にとどまり、レイテンシとコストも高くなっています。メモリなしと比較して、MemCurrentはエージェントの合格率を3倍にし（22.3% → 68.4%）、同時に1.35倍高速化、1.44倍低コスト化を実現しています。

図6. 当社の社内メモリベンチマークにおける、3回の繰り返し全体でのタスクあたりの合格率、平均レイテンシ、および平均トークン使用量。エージェントモデルとしてClaude Opus 4.6、メモリモデルとしてGPT 5.6 solを使用しています。すべてのメモリバックエンドは、エージェントツールおよびセッション開始プラグインとして提供されています。

MemCurrentの実用例

ベンチマークの数値に加え、社内GenieセッションでのMemCurrentが実践でどのように役立つかを示す2つの例を見てみましょう。

例1：メモリが時折発生するハルシネーションの誤りを防止する。図7では、ユーザーが過去2ヶ月間のプロダクトXの上位20ユーザーをエージェントに要求しました。エージェントは正しいSQLクエリを作成しましたが、ファイルに保存された実際の実行結果を読み取りませんでした。それでも、ハルシネーションによるコンテンツを含むテーブルを堂々と生成しました。ユーザーからのフィードバックを受けて、エージェントはその教訓をメモリに保存しました。次回、クエリが実行されると、エージェントは最初に結果を読み取り、正しいテーブルを返しました。一度のメモリ補正により、一度限りのミスが習慣化するのを防ぎました。

図7. メモリがエージェントによる繰り返しのハルシネーションエラー回避にどのように役立つかを示す匿名化された例。

例2：メモリが関連タスクの計算量を削減する。図8では、ユーザーが「上位5社のSDPカスタマー」を要求しました。エージェントはゼロからすべてを解明する必要がありました。「SDP」が何を意味するのか、どのテーブルに使用状況データが格納されているか、そしてそれらをどのように結合してフィルター処理するかです。これには11回のツール呼び出し、8つのサブエージェント、および約6分がかかりました。エージェントはこれらの手順をワークフローファイルとしてメモリに保存し、関連するタスクで再利用できるようにしました。その後、ユーザーは別の質問をしました：先月5K回を超えるパイプライン実行を行ったSDPカスタマーの数です。ワークフローを使用して、エージェントは2回のツール呼び出しと1つのサブエージェントで、41秒で回答しました。質問は新しいものでしたが、回答への経路は新しくなく、メモリによりエージェントは不要な探索をスキップすることができました。

図8. メモリによって6分のタスクが41秒に短縮される様子を示す匿名化された例。

MemCurrentが効果的に機能する理由

MemCurrentの優れたパフォーマンスの要因を理解するために、メモリタイプと抽出戦略という2つの設計上の選択肢について、社内メモリベンチマークでアブレーション実験を行いました。

両方のメモリタイプが必要か？ エピソードメモリ単体でも適度な効果があります（メモリなしの22.3%から35.8%に向上）。生の履歴は有用ですが、エージェントがそれを検索するのはテストケースの約3分の1に過ぎません（検索した場合はその60%で合格します）。派生メモリはこの問題を回避します。セッション開始時に挿入されたメモリインデックスにより、エージェントにメモリ内で利用可能な情報と参照すべきタイミングに関する情報が提供され、合格率が66.1%に引き上げられます。さらにエピソードメモリを追加することで、最高の成果（68.4%）が得られます。向上幅はわずかですが、生のトレースによって蒸留で削ぎ落とされた詳細を復元できることを示唆しています。 

図9. メモリタイプ別の合格率。

優れたメモリ抽出戦略とは？ 図2に示すように、派生メモリはオンラインツールとオフラインドリーミングという2つのチャネルで抽出されます。単独で使用した場合、オフラインドリーミング（63.5%）はオンラインツール（53.9%）を10ポイント近く上回ります。これらを組み合わせることで、最高合格率の66.1%が達成されます。これは役割分担を裏付けています。ドリーミングがバックグラウンドでの抽出と統合を担当し、オンラインツールによって明示的なリクエストがすぐに有効になります。

図10. 抽出戦略別の合格率。

まとめ

メモリは、エージェントがゼロからのスタートを脱却するための手段です。本記事では、プロダクション環境のエージェント向けメモリアーキテクチャであるMemCurrentを紹介しました。これはエピソードメモリと派生メモリを組み合わせ、3つのアクセスパターンを備えています。コンテキストを自動的に記録・読み込みするプラグイン、エージェントがオンデマンドで呼び出すツール、そしてバックグラウンドでメモリを統合するオフラインドリーミングパイプラインです。

実施したすべてのベンチマークにおいて、MemCurrentは私たちが解消を目指したトレードオフである品質と効率の両方を同時に向上させました。オープンソースのベンチマークでは、約12分の1の入力トークン数でフルコンテキストのパフォーマンスと同等の結果を達成しました。実際のデータ業務から構築された当社の社内メモリベンチマークでは、メモリなしと比較してエージェントの合格率を3倍にし、同時に高速化と低コスト化を実現しました。

アブレーション分析により、価値がどこからもたらされているかが明確になりました。派生メモリが役割の大半を果たし、エピソードメモリは蒸留で失われた詳細を復元することで小さな向上をもたらします。オンラインツールとオフラインドリーミングの組み合わせが最良の抽出戦略となります。明示的なリクエストは即座に反映され、ドリーミングが暗黙の学習内容を蒸留してバックグラウンドでストレージを統合します。

数値的な結果にとどまらず、メモリは単一のエージェントやLLMに縛られないナレッジベースを提供します。ユーザーとともに新しいエージェントやLLMへと移行可能であり、組織全体で共有されるナレッジの基礎となる可能性を秘めています。これは、私たちが次に探索している方向性です。

はじめに

これらの知見を活用し、Databricks製品全体の向上を促進していきます：

エージェント開発者向け Agent Bricksは、カスタムエージェントを構築するためのDatabricksの開発者向けプラットフォームです。MemCurrentは、Lakebaseを利用したAgent BricksのMemory機能に組み込まれています。この機能には以下が含まれます：

• エピソード記憶用のセッションストア
• 派生記憶用のメモリストア
• 自動ドリーミングパイプライン 
• 記憶の影響を含む、エージェント品質のトレーシングと評価
• これらすべてを備えたエンドツーエンドのサンプルエージェントを10分未満で簡単に使い始められるCLI 

今すぐ始める：カスタムエージェントの構築をはじめましょう。

Databricks Genieユーザー向け Genieは、Databricksユーザーが自然言語でデータと対話できるインターフェースです。MemCurrentはすでにバックグラウンドで動作しており、応答のレイテンシとコストを削減しながら回答品質の向上に貢献しています。

今すぐ始める：Genieをご利用ください。

著者：Veronica Lyu、Wenhao Zhan、Sam Havens、Ziyi Yang、Jenny Sun、Qinxin Wang、Nihit Desai、Sirui Sun、Ankit Mathur、Jane Zhang、Yi Liu、Jialu Liu、Michael Bendersky、Matei Zaharia、Xing Chen

本プロジェクトを通じてフィードバックとサポートをいただいたJonathan Li、Rishabh Singh、Andy Zhang、Kenneth Choi、Will Tipton、Cassie Cao、Siddharth Murching、Sue Ann Hong、Pranav Sukumar、Neo Ni、Shanshan Zheng、Chung Wu、および社内ユーザー調査の参加者の皆様に感謝いたします。 

¹ ほとんどの質問は1回のホップで回答できるため、レイテンシはすべてのメモリバックエンドでほぼ同等です（質問あたり4〜7秒）。

² 既存のベンチマークにはプラグインベースのメモリで十分であることがわかりました。ツールを追加した際の結果はパフォーマンスが下回るため省略しています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事