MemEx: LLMエージェントのためのプログラマブルなスクラッチパッド

1945年、ヴァネヴァー・ブッシュは、あらゆる文書、注釈、思考の軌跡を保存し、必要に応じて呼び出すことで科学者の記憶を拡張する、机の大きさの機械を構想しました。彼はそれをMemExと呼びました。ブッシュが解決しようとしていたのは、手元に置いておけないほどの情報に圧倒される人間の脳という課題でした。それから80年後、LLMエージェントも非常によく似た壁に直面しています。

現在のエージェント型ツール呼び出し（Agentic Tool Calling）のパラダイムでは、コンテキストウィンドウが、モデルが操作できる唯一の永続的な基盤となっています。これは、システムプロンプト、ユーザーのクエリ、モデルの推論、ツール呼び出し、そしてツールの生出力を保持する共有スペースです。中でもツールの出力は最も厄介です。1つのSQLクエリが何百万行ものデータを返すことがあり、現在の仕組みでは、たとえ1つのセルしか必要でなくても、その後のすべてのターンにそれらの行が引き継がれてしまいます。エージェントには、ウィンドウが溢れる前に結果をスライスしたり、要約したり、一時保存したりする方法がありません。

Databricksでは、常にこの壁にぶつかっていました。私たちの本番環境のエージェントは、GenieからAgent Bricksにいたるまで、どこかの時点で同じコンテキスト制限に直面します。Genieは分かりやすい例です。1つのクエリで顧客のワークスペース全体を検索し、多数のツールを呼び出して、テーブル、ベクトルインデックス、ダッシュボードからデータを取得します。これに対処するため、私たちは独自のMemExを構築し、複数の本番環境および社内エージェントで検証しました。

難易度の高いエンタープライズ向けの構造化データ検索タスクにおいて、図1が示すように、MemExはすべてのモデルでコスト対精度のフロンティアを押し上げています。Opus 4.6やSonnet 4.6のような最先端モデル（Frontier models）では、トークンコストを25〜30%削減しながら、精度が2〜5パーセンテージポイント向上しています。Qwen3.5-122B（18% → 36%）やQwen3.5-397B（20% → 38%）のようなオープンウェイトモデルでは、トークンコストを40〜50%削減しつつ、精度がほぼ倍増しています。MemExは任意に長い入力を処理できるため、さらに2つのアプリケーションが可能になります。1つは、通常は単一のコンテキストウィンドウに収まらないMemEx自体の軌跡を含むエージェントの軌跡（trajectory）の監査、もう1つは、複数の軌跡にわたる並列思考です。

MemExの仕組み

MemExは、LLMにプログラム可能なスクラッチパッドを提供します。これは、ツールの出力を保持し、コードでそれらを変換し、print文のみをコンテキスト内のトークンとして実体化（materialize）する、型定義されたPythonカーネルです。この環境内では、ロールアウト（展開）は自己拡張するPythonプログラムになります。各ターンの間、エージェントは新しいブロックを作成し、カーネルは状態を維持し、次のブロックは前のブロックをベースに構築されます。ツールは、型定義されたパラメータと型定義された戻り値を持つ、型定義されたPython関数として公開されます。ツールの出力はPythonオブジェクトとしてMemExのスコープに格納され、ターンをまたいで永続化されます。エージェントはそれらをコードで構成し、パターンが繰り返される場合はヘルパー関数を定義し、同じスコープ上で非同期関数呼び出しとしてサブエージェントを生成します。

MemExは、CodeAct（Wang et al., 2024）によって導入された「Code-as-Action（アクションとしてのコード）」ファミリーに属しており、AnthropicのProgrammatic Tool CallingやCloudflare Code Modeに本番環境のバリアントが存在します。MemExが際立っているのは、既存のReAct（Yao et al., 2022）スタイルのエージェントフレームワークに組み込むことができ、永続的なスコープ、サブエージェントのプリミティブ、および型定義された戻り値が組み込まれている点です。これらが組み合わさることで、JSON/XMLツール呼び出しのパラダイムにはない、以下のような機能が解放されます。

• 任意の大きさの入力の処理：文書、データセット、その他の大きなオブジェクトを、変数としてPythonのスコープ内に保持できます。
• 型定義されたオブジェクトの返却：ツールの出力はメモリに保持される型定義されたPythonオブジェクトであり、モデルが毎ターン実体化したり再パースしたりする必要がある文字列ではありません。
• ツール呼び出しの構成：1行のコード内で、ある呼び出しの出力が次の呼び出しの引数に直接流れます。中間出力をエージェントのコンテキストに実体化する必要はありません。
• ツール出力のスライス：モデルがデータを目にする前に、コード内で出力を前処理、フィルタリング、または要約できます。
• 非同期サブエージェントの生成：エージェントは、親エージェントと並行して実行されるサブエージェントをプログラムで生成し、メインモデルを往復することなくその結果を集計できます。

MemExを搭載したLLMエージェントの例

3つの顧客セグメントにおける「登録からアクティベーション」までのファネルを比較し、最大の離脱（ドロップオフ）を特定するという、具体的なエンタープライズタスクを考えてみましょう（図1）。このワークフローには4つのステップがあります。

1. データウェアハウスから登録イベントとアクティベーションイベントを取得する
2. ユーザーごとにそれらを結合（join）する
3. 各ステージにおけるセグメントごとのコンバージョン率を計算する
4. セグメント間で離脱率をランク付けする。

ツール呼び出し（Tool Calling）エージェントは、python_execを備え、一度に1つのステップを実行します。各SQLクエリや各プログラム計算は個別のツール呼び出しであり、中間のDataFrameはテキストにシリアル化され、その後のターンに再度貼り付けられます。このトレースはトークンを大量に消費するため、情報が失われやすく、遅く、コストがかかり、下流のタスクで小さなエラーが連鎖的に発生しやすくなります。

MemExエージェントは、同じワークフローを単一のコードブロックとして記述します。クエリはスコープ内のネイティブなDataFrameを返し、ヘルパー関数がそれらを構成し、最終的な回答はsubmit()を介して型定義・検証されたオブジェクトとして返されます。思考は同じですが、アクションスペースが異なります。

サブ問題に分解できるタスクの場合、エージェントはブロックの内部からサブエージェントを生成できます。サブエージェントを生成する際、親エージェントは任意のオブジェクトへの共有アクセスを渡すことができます。サブエージェントは親エージェントと並行して積極的に実行され、完了時にメインエージェントに結果を返すことができます。例えば：

再帰的な分解は、同じPythonプログラム内のもう1つの表現になります。

MemExは、Databricksのエージェント型ロールアウトフレームワークであるarollをベースに開発されています。Arollはすでに、GenieやAgent BricksのSupervisor Agentなどの本番システム、およびKARLなどの研究活動を支えています。MemExは、arollがすでにツール呼び出し（Tool Calling）に使用しているのと同じエージェントループやツールにプラグインできます。

エンタープライズ向けのエージェントタスクにおいて、MemExはどのようなパフォーマンスを発揮するのか？

私たちは、9つの最先端モデル（frontier models）を対象に直接対決の評価（evals）を実施し、並列構造化ツール呼び出し（Tool Calling）とPythonコードブロック（MemEx）を比較しました。プロンプト調整やタスクごとの適応は行っていません。比較は、大規模なテキストコーパスに対する根拠に基づく読解（grounded reading）（OfficeQA）と、多様なリレーショナルデータからなる大規模なワークスペースに対する構造化検索（Enterprise Structured Retrieval）という、2つの形態のエンタープライズ向けエージェントタスクにわたって行われました。

両方のタスクにおいて、MemExエージェントはTool Callingエージェントよりも優れており、コストも安価です。

OfficeQA Proは、1939年から現在に及ぶ約89,000ページにわたる米国財務省公報（U.S. Treasury Bulletins）のコーパスを対象に、根拠に基づいた推論の質問に回答することをエージェントに求めます。典型的な質問では、複数のドキュメントから証拠を特定し、ネストされた階層や結合されたセルを持つ表を探索し、取得したデータに対して計算を実行する必要があります。回答は完全一致（strict match）で採点されます。コスト対精度のパレートフロンティアにおける5つのポイントのうち4つは、MemExの構成です。Gemini 3.1 Pro MemExは、1回のロールアウトあたり0.62ドル（精度52.9%）と最も安価なフロンティアポイントであり、Sonnet 4.6 MemExは、約70%のコストでGPT-5.5のTool Callingの精度に迫ります。9つのモデル全体において、MemExはすべてのモデルで同等以上の結果を収めています。中位層のモデルが最も大きく向上しており、Qwen 3.6 27BとGemini 3.1 Proは約10パーセンテージポイント向上しています。

Enterprise Structured Retrievalは、企業のリレーショナルデータに対する自然言語の質問に回答することをエージェントに求めます。エージェントにはスキーマ検出やSQLクエリ実行に関連するツールが提供され、これらを使用してユーザーから要求されたデータ分析タスクを実行する必要があります。通常、多様なワークスペースのどこに関連情報があるかについての情報はほとんど提供されません。エージェントの回答は、決定論的なデータ検証とLLM-as-a-judgeの両方を使用して、グラウンドトゥルース（正解）の回答と比較して採点されます。図1および図6に示すように、同等のパフォーマンスを示したGPT 5.5を除き、すべてのモデルでMemExによる大幅な向上が見られます。コスト面でも、同様に強力な結果が得られています。Qwen 122Bは、スコアを2倍にしながら、1回のロールアウトあたりのツール呼び出し回数を56回から28回に削減しました。Sonnetは28回から17回に、Opusは33回から21回に削減されました。¹これにより、ほとんどのモデルでコストがほぼ半減します。このパターンはOfficeQA Proと同様です。タスクが難しくなるほど、ネイティブオブジェクトと永続的な状態がその真価を発揮します。

各比較は、プロンプトチューニング、タスクごとの適応、モデル固有の微調整を一切行わずに実行されました。エージェントのループ、システムプロンプト、およびツールは、両方のハーネスで同一です。唯一の違いはアクション空間であり、JSON/XMLで構造化されたツール呼び出しと、MemExのPythonコードブロックの比較です。

エージェントのトレース上で動作するMemEx

エージェントの軌跡（軌道）自体が、かさばるオブジェクトです。Tool Callingのパラダイムでは、軌跡の分析には通常、それらをテキストにフラット化（平坦化）する必要がありますが、これは情報損失が多く、コンテキストの負荷が高いため、一度に複数を分析することは困難な場合がよくあります。軌跡は、途中で圧縮を挟みながら、複数のコンテキストウィンドウにまたがることもあります。定義上、コンテキストに収まらないトレースを、LLMはどのように分析できるでしょうか。しかし、軌跡は単なる別のPythonオブジェクトであるため、MemExはそれをスコープに直接ロードして推論することができます。ここでは2つのアプリケーションを示します。1つ目は、OfficeQA-ProにおけるQwen 3.6-27Bの軌跡を分析し、なぜMemExがTool Callingを上回るのかを説明する、MemExベースの監査エージェントです。2つ目は、OfficeQA-Proでのテスト時スケーリングであり、同等のTool Callingエージェントを上回るMemExエージェントを使用します。

MemExがMemExを監査する：エージェントトレース分析

Qwen 3.6-27Bなどのオープンソースモデルにおいて、MemExへの切り替えがパフォーマンス向上につながった理由を分析するために、MemEx自身に説明を求めます。具体的には、OfficeQAの質問、そのグラウンドトゥルースの回答、および6つのソルバー軌跡（MemExエージェントから3つ、Tool Callingエージェントから3つ）をPythonのスコープに直接取り込む監査エージェントをインスタンス化し、MemExベースのSonnet 4.6エージェントに、すべての誤った軌跡を4つの軸からなる失敗モードの分類法に沿って分類させます。

私たちの分析は、6つの試行すべてが正解または不正解ではなかった66のOfficeQA Proの質問に焦点を当てており、173の軌跡が得られました。4つの軸は、大きく2つのグループに分類されます。

- グラウンディングエラー（約83%）：モデルが修正された数値ではなく暫定的な値を取得したり、曖昧な用語（例：標本分散と母分散、または「小数点以下第2位」の丸め精度など）を誤解したり、有効な表から誤った列を抽出したりするケース。

- 検索戦略および実行のエラー：検索シーケンスの計画におけるエラー、または取得したデータを最終的な計算に正しく統合できなかったエラー。

検索戦略および実行のエラーについて、MemExは、MemExエージェントのエラーがTool Callingと比較して2分の1に減少したことを示しています。これは、MemExでは検索結果をPython変数に直接格納できるため、モデルがあるツールの出力から次のツール呼び出しへ値をコピーする手間を省くことができ、1回のターンで複数のツール呼び出しをバッチ処理できるためです。Tool Callingにはそのようなショートカットがないため、呼び出し間で常に値を転記する必要があり、時折ミスが発生します。たとえば、ある軌跡では、取得したドキュメントの「3,501」という値が、次の呼び出しで「3531」と誤って入力されていました。

MemExによるエージェントの並列思考

テスト時の計算をスケーリングするための一般的なアプローチは並列思考（parallel thinking）であり、タスクの複数の独立したロールアウトを最終的な回答に集約します。KARLで使用されているアプローチなどのエージェント並列思考では、独立した試行の要約がアグリゲーターエージェントに渡されます。モデルのコンテキストウィンドウに複数の完全な軌跡を収めることは非現実的であるため、この要約ステップは情報損失を伴いますが、標準的なセットアップでは避けられません。MemExを使用すると、代わりにこれらの軌跡をスコープ変数としてロードできるため、情報損失を伴う表現を完全に回避できます。

図7に示す結果では、独立して生成された8つのQwen-3.6-27Bのトラジェクタリを統合するアグリゲーターとして、Claude Sonnet 4.6を使用しています。アグリゲーターが単に自力で問題を再解決しているだけではないことを確認するため、ファイル検索ツールを取り除き、検証と選択のみに制限しています。完全なトラジェクタリを入力として受け取るMemExベースのエージェントは、要約のみを受け取る同等のTool Callingエージェントを上回るパフォーマンスを示します。あるケースでは、トラジェクタリアグリゲーターが入力トラジェクタリから生のツール出力を読み取ることで、以前の報告における重複エラーを検出しました。一方、Tool Callingアグリゲーターは、入力が要約に限定されていたため重複データの指摘を検証できず、破損したソースに対する多数決に頼る結果となりました。

MemExのアーキテクチャ

Tool Callingエージェントは、ReAct (Yao et al., 2022)によって導入されたアクションと観測のループにおいて、事前に定義されたツールスキーマに従って、1ターンあたり1つ以上の構造化されたツール呼び出し（JSONまたはXML）を出力します。CodeAct (Wang et al., 2024)は、そのフォーマットを永続的なPythonカーネルに置き換えました。エージェントは任意のPythonコードを出力し、変数や関数定義はターンをまたいで保持されます。同一パラダイムのプロダクション向けバリアントには、AnthropicのProgrammatic Tool Calling (PTC)やCloudflare Code Modeがあります。PTCは同じコンテナを再利用することでリクエスト間で状態を保持しますが、Code Modeは保持しません。MemExは、このパラダイムをベースに、以下の4つの機能を追加して拡張しています。

• パラメータスキーマを維持した、ドロップインでのツール統合。
• ロールアウト開始時のライブPythonスコープ。
• 構造化された戻り値のための、型定義された submit()。
• 並列サブエージェントのためのノンブロッキングな spawn_agent()（Recursive Language Models (Zhang et al., 2025)を一般化したもの）。

この実装は、3つの設計上の選択肢に基づいています。

永続的なREPLにおけるアクションとしてのコード

エージェントのアクションは任意のPythonコードブロックであり、ターンをまたいで永続するネームスペース内で実行されます。ツール、スコープオブジェクト、および以前の結果はすべてそのネームスペース内に存在します。エージェントは観測結果（stdout、戻り値、エラー）を読み取り、さらにコードを記述します。Tool Callingを実行するのと同じ観測とアクションのループがMemExを実行します。変更されるのはアクションスペースのみです。

Tool Callingのドロップイン代替

既存のTool Callingツールは、パラメータスキーマや戻り値の型のメタデータを含め、Python関数として自動的に注入されます。既存のエージェントをTool CallingからMemExに切り替えるには、設定を1箇所変更するだけです。

バックエンドに依存しない実行

同じエージェントコードが、設定時に選択された3つのバックエンドのいずれかで実行されます。

• 研究中の迅速なイテレーションのためのインプロセス。
• 評価時の分離のためのサブプロセス。
• 高スループットのバッチ生成（トレーニングデータ、大規模なロールアウト）のためのプール。

本番環境へのデプロイでは、カーネルをAnthropicのManaged Agentsのようなホスト型サンドボックスに置き換えることができます。ファイルシステム分離、ネットワーク送信（エグレス）制御、リソース制限はホスト側で処理され、エージェントコードはそのまま使用できます。

今後の展望

MemExがエージェント開発者の皆様の手元に届きます。DatabricksのファーストパーティエージェントおよびAgent Bricks全体に展開を進めています。現在Databricksのエージェントを利用して構築している場合、まもなくMemExを使用できるようになります。

私たちは、MemExのアクションスペース向けにモデルの事後学習（post-training）を行っています。MemEx自体がその基盤であり、合成データの生成、エージェントによる検証器（agentic verifiers）の実行、そしてトレーニングループへのデータ供給を行います。

著者：Ashutosh Baheti、Shubham Toshniwal、Arnav Singhvi、Krista Opsahl-Ong、Sean Kulinski、Sam Havens、Jonathan Li、Marco Cusumano-Towner、Jonathan Chang、Wen Sun、Alexander Trott、Jonathan Frankle、Xing Chen、Matei Zaharia

---

¹ MemExにおいて、ツール呼び出しはPythonコードブロックであり、データ分析やその他のツールを非同期関数として呼び出すことができます。

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