2026年5月19日

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

1945年、ヴァネヴァー・ブッシュは、科学者の記憶を拡張する、机サイズの機械を想像しました。それは、あらゆる文書、注釈、思考の軌跡を保存し、オンデマンドで呼び出すことができるものでした。彼はそれをMemExと名付けました。ブッシュは、手元に置いておけない情報に圧倒されるという人間の問題を解決しようとしていました。80年後、LLMエージェントも驚くほど似た壁にぶつかっています。

現在のAgentic Tool Callingパラダイムでは、コンテキストウィンドウがモデルが操作できる唯一の永続的な基盤です。これは、システムプロンプト、ユーザーのクエリ、モデルの推論、ツール呼び出し、および生のツール出力を運ぶ共有スペースです。ツール出力は最悪の犯人です。単一のSQLクエリが数百万行を返すことがあり、今日のハーネスでは、たった1つのセルが重要であったとしても、それらの行は後続のすべてのターンで一緒に移動します。エージェントは、結果がウィンドウをあふれさせる前に、それをスライス、要約、または保存する方法がありません。

Databricksでは、この壁に常にぶつかっています。GenieからAgent Bricksに至るまで、当社の本番エージェントは、ある時点で同じコンテキストの制限に遭遇します。Genieは明確な例を提供します。単一のクエリで顧客のワークスペース全体を検索し、多くのツールを呼び出してテーブル、ベクトルインデックス、ダッシュボードからデータを取得します。これに対処するため、私たちは独自のMemExを構築し、複数の本番エージェントと内部エージェント内で検証しました。

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

MemExの仕組み

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

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

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

MemExを使用したLLMエージェントの例

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

データウェアハウスからサインアップおよびアクティベーションイベントを取得する
ユーザーごとに結合する
各段階でのセグメントごとのコンバージョン率を計算する
セグメント全体のドロップオフをランク付けする

ツール呼び出しエージェントは、python_execを備えており、一度に1ステップずつ動作します。各SQLクエリと各プログラムによる計算は個別のツール呼び出しであり、中間DataFrameはテキストにシリアル化され、後続のターンに再度貼り付けられます。このトレースはトークンが重く、そのため損失が多く、遅く、高価であり、ダウンストリームタスクで小さな連鎖的なエラーが発生しやすいです。

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

図3：ツール呼び出しエージェントと比較したMemExにおけるトークン節約の例。MemExは、ステップ間のテキストの繰り返し再具体化を回避し、ツール呼び出しエージェントと比較してトークンを節約します。

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

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

MemExは、Databricksのエージェントロールアウトフレームワークであるarollの上に開発されています。arollは、Genie、Agent Bricksのスーパーバイザーエージェント、KARLのような研究活動など、すでに本番システムを強化しています。MemExは、arollがツール呼び出しにすでに使用しているのと同じエージェントループとツールに接続します。

MemExはエンタープライズエージェントタスクでどのように機能しますか？

私たちは、9つのフロンティアモデルで直接評価を実施し、並列構造化ツール呼び出し（ツール呼び出し）とPythonコードブロック（MemEx）を比較しました。プロンプトチューニングも、タスクごとの適応も行っていません。大規模なテキストコーパスに基づくグラウンデッドリーディング（OfficeQA）と、多様なリレーショナルデータの大規模ワークスペースに基づく構造化検索（エンタープライズ構造化検索）という2種類のエンタープライズエージェント作業で比較しています。

両方のタスクで、MemEx AgentはTool Calling Agentよりも優れており、費用も安価です！

OfficeQA Proは、エージェントに1939年から現在までの約89,000ページにわたる米国財務省公報コーパスに関する根拠に基づいた推論質問に回答するよう求めます。一般的な質問では、複数のドキュメントから証拠を見つけ出し、ネストされた階層と結合されたセルを持つテーブルを操作し、取得したデータに対して計算を実行する必要があります。回答は厳密な一致によって採点されます。コスト対精度パレートフロンティア上の5つの点のうち4つはMemEx構成です。Gemini 3.1 Pro MemExは、ロールアウトあたり0.62ドル（精度52.9%）で最も安価なフロンティアポイントであり、Sonnet 4.6 MemExはGPT-5.5 Tool Callingの精度にコストの約70%で近づきます。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はロールアウトあたりのツール呼び出しが56回から28回に減少し、スコアは2倍になりました。Sonnetは28回から17回に、Opusは33回から21回に減少しました。¹これにより、ほとんどのモデルでコストが約半分になります。このパターンはOfficeQA Proと類似しています。タスクが困難であればあるほど、ネイティブオブジェクトと永続的な状態がその価値を発揮します。

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

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

エージェントの軌跡自体はかさばるオブジェクトです。Tool Callingパラダイムでは、軌跡の分析には通常、それらをテキストに平坦化する必要があり、これは情報が失われやすくコンテキストに依存し、複数の軌跡を一度に分析することはしばしば不可能です。軌跡は複数のコンテキストウィンドウにまたがり、その間に圧縮が行われることもあります。定義上、コンテキストに収まらないトレースをLLMがどのように分析できるでしょうか？しかし、軌跡は単なる別のPythonオブジェクトであるため、MemExはそれを直接スコープにロードして推論することができます。ここでは2つのアプリケーションを紹介します。1つ目は、MemExがTool Callingを上回る理由を説明するためにOfficeQA-Pro上のQwen 3.6-27Bの軌跡を分析する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軸分類法に沿ってすべての誤ったトレースを分類するよう求めます。

失敗軸	定義	MemExエラー	Tool Callingエラー
`Source Selection`	モデルが誤ったドキュメントまたはテーブルをターゲットにする	32	45
`Interpretation`	モデルが正しいデータを取得するが、誤った意味を抽出する	28	38
`Search Strategy`	モデルが早すぎる停止、または回答を通り過ぎてしまう	6	15
`Execution`	中間計算または最終出力フォーマットのバグ	3	6
`Total`	-	69	104

我々の分析は、6回の試行すべてが正解または不正解ではなかった66のOfficeQA Pro質問に焦点を当て、173の軌跡を生成しました。4つの軸は2つの大きなグループに分かれます。

- グラウンディングエラー（約83%）：モデルが改訂された数値の代わりに予備的な値を取得するケース、曖昧な用語（例：標本分散と母集団分散、または「百分の一」の丸め精度）を誤解するケース、または有効なテーブルから誤った列を抽出するケース。

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

検索戦略と実行のエラーに関して、MemExはTool Callingと比較してMemExエージェントのエラーが2倍減少したことを発見しました。これは、MemExの場合、取得が直接Python変数に格納されるため、モデルは1つのツールの出力から次のツール呼び出しに値をコピーするのを避け、複数のツール呼び出しを1回のターンでバッチ処理できるためです。Tool Callingにはそのようなショートカットがなく、常に呼び出し間で値を転記する必要があり、これが時々誤りを引き起こします。例えば、ある軌跡では、取得されたドキュメントからの3,501という値が、次の呼び出しで3531と再入力されました。

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

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

図7に示す結果では、8つの独立して生成されたQwen-3.6-27Bの軌跡を統合するアグリゲーターとしてClaude Sonnet 4.6を使用しています。アグリゲーターが単に問題を独自に再解決しないように、ファイル検索ツールを削除し、検証と選択に限定しました。完全な軌跡を入力として受け取るMemExベースのエージェントは、要約のみを受け取る同等のツール呼び出しエージェントよりも優れた性能を発揮します。あるケースでは、軌跡アグリゲーターは入力軌跡から生のツール出力を読み取ることで、以前の速報の重複エラーを捕捉しました。ツール呼び出しアグリゲーターは、入力が要約に限定されていたため、重複データの主張を検証できず、破損したソースの多数決に頼りました。

MemExアーキテクチャ

ツール呼び出しエージェントは、ReAct (Yao et al., 2022)によって導入されたアクション-観測ループにおいて、定義済みのツールスキーマに準拠した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()。
Recursive Language Models (Zhang et al., 2025)を一般化する、並列サブエージェントのためのノンブロッキングspawn_agent()。

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

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

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

ツール呼び出しのドロップイン

既存のツール呼び出しツールは、パラメータスキーマと戻り値の型メタデータを含め、Python関数として自動的に注入されます。既存のエージェントをツール呼び出しからMemExに切り替えるのは、単一の設定変更で済みます。

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

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

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

プロダクション展開の場合、カーネルはAnthropicのManaged Agentsのようなホスト型サンドボックスに交換できます。同じエージェントコードで、ファイルシステム分離、ネットワーク出力制御、リソース制限はホストによって処理されます。

次は何ですか？

MemExはあなたのエージェントの手に渡ろうとしています。DatabricksのファーストパーティエージェントとAgent Bricks全体で展開を進めています。現在Databricksエージェントを構築している場合、まもなくMemExを使用できるようになります。

MemExアクション空間向けにモデルの事後学習を行っています。MemEx自体が基盤であり、合成データを生成し、エージェント検証を実行し、トレーニングループにフィードします。

著者：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翻訳ツールを使用して翻訳されています) 原文記事