知能は無料になった、今後はどうするか？エージェントのためのデータシステム

*...人民の、人民による、人民のための政府...*

— アブラハム・リンカーン、ゲティスバーグ演説（1863 年）

AI のコストは急速に低下しています。2023 年初頭には GPT-4 クラスの能力が約 100 万トークンあたり 30 ドル程度でしたが、現在では同じものが 1 ドル未満で利用可能であり、一部のプロバイダーは 0.10 ドル未満への価格引き下げを推進しています。ベンチマーク全体を通じて、推論価格は年間 9 倍から 900 倍の幅で低下しており、その中央値は約 50 倍の低下です。さらに重要な点として、「ノーベル賞受賞者並みの天才レベル」の知能がまだ実現していないとしても、知識労働の大部分に十分な知能はすでに今日存在しており、毎月さらに安価になっています。このペースでいけば、私たちはまもなく実質的に無料の知能（**日常の知識労働には十分すぎるほどのもの）の時代へと突入します。

開示：本稿は、カリフォルニア大学バークレー校の EECS 准教授であり EPIC データラボの共同ディレクターである Aditya G. Parameswaran が主導する見解です。彼の協力者たちと共に執筆された本稿は、景観調査と見解の両方の側面を持ち、以下で議論されるいくつかの研究方向（エージェントによる推測、構造化メモリ、ゼロからカスタムデータシステムを構築することなど）には、著者自身の進行中の研究が反映されています。

では、このほぼ無料の知能という新時代は、データシステムに何を意味するのでしょうか？私たちは、推論コストがほぼゼロになることから生じる3つの新たな課題と機会があると信じています：

エージェントのためのデータシステム。エージェントはまもなくデータシステムの主要なワークロードとなり、各エンドユーザーのリクエストに応じて多数のエージェント群が起動されるようになるでしょう。人間（またはその代理人として行動するアプリケーション）との特性の違いを踏まえ、*このようなエージェンシーを持つユーザーのためにデータシステムをどのように再設計すべきでしょうか？*

エージェントによるデータシステム。エージェントが知識労働の大部分を引き受けるようになると、長期にわたるタスクで状態を管理し、調整して合意形成を図り、障害に対処するために、数千のエージェントを支える新たな基盤が必要となります。*信頼性が高く効率的にエージェント群を実行・管理するデータシステムとはどのようなものなのでしょうか？*

エージェントによって構築されるデータシステム。 エージェントは急速に、一度に完全なデータシステムを合成する能力を獲得しており、这意味着私たちは新しいワークロードごとにカスタムシステムを再構築できるようになります。こうしたシステムが意図した通りに動作することを検証することは課題です。*実際に信頼できるデータシステムをエージェントに合成させるには、何が必要なのでしょうか？*

次に、それぞれをより詳細に議論し、特に 3 つの課題が交差する点において、データシステムとエージェントの絡み合った未来について議論します。

エージェントのためのデータシステム

データベースを照会するエージェントは、人間や BI ツールとは異なる振る舞いを示します。私たちはこれを エージェンティック・スペキュレーション（代理的な推測）と呼びます。これは、スキーマの内部構造調査、列ごとの探索、部分的なそして最終的な完全なクエリ作成にわたる、高ボリュームで多様なワークロードのストリームです。複数のエージェントが仮説空間の各部分を探索する中で、1 つのユーザー要求が数千個の個別の SQL クエリに相当することさえあります。現在、ユーザーは「高レベル」のデータタスクを発行できます。例えば、根本原因分析（例：「なぜ今年のベルギーでのコーヒー販売は減少したのか？」）や、探索的コホート分析（例：「来期に離脱する可能性が最も高いユーザーセグメントはどれか？」）などです。これらには、結合、集計、フィルタの組み合わせにおける組み合わせ空間が関与します。

*

エージェントの推論をより効果的に支援するために再設計されたデータシステム

*

これらのエージェントからのリクエストには、最適化の様々な機会があります。例えば、複数のエージェントが各タスクに挑戦するテキストから SQL へのベンチマークでは、サブプランのわずか 10〜20% が固有のものであり、残りの 80〜90% のサブクエリは重複した作業を実行しています。同じ実験では、エージェントによる試行回数が増えるにつれてタスクの成功率が大幅に向上することが示されており、この冗長性は実際には有益です。しかし、データシステムの観点から見れば、これは無駄な作業となります。

エージェントファーストのデータシステムは、このような特性を活用して、エージェントがより迅速に進捗を達成できるよう支援できます。重複するサブプラン間で結果を再利用し、数十年にわたる マルチクエリ最適化 や 共有スキャン に関する古くからの文献の知見を援用できます。あるいは、データシステムは「満足できる解」を目指すアプローチ（*satisfice*）を試み、エージェントが進捗を達成するのに十分な近似回答を返すことで、AQP に関する 文献 の研究成果を活用できます。あるいは、最終または中間演算子の結果をストリーミングして、残りのデータを見る必要があるか有益であるかをエージェントが判断できるよう支援することも可能です。

ここで再考すべき別の機会として、クエリインターフェースそのものを根本から見直すことが挙げられます。エージェントが一度に単一の SQL クエリを発行するのではなく、それぞれに独自の近似要件を持つ一連のクエリをバッチ処理で発行できるようにするのです。前述の根本原因分析やコホート分析の例のように、指数関数的な探索空間を列挙することは、エージェントの推論能力を有効活用する方法とは言えません。むしろ、データシステムは各 SQL クエリを明示的にリストアップすることを要求するのではなく、より高レベルなプリミティブをサポートすべきでしょう。その一つのアイデアとして、DBT スタイルの Jinja マクロ を活用し、ループ処理に基づくプリミティブを提供して、エージェントがデータシステムと対話できるようにする案があります。

ここで最後の機会として、データシステムをクエリの受動的な実行体と考えるのをやめることです。データシステムは 能動的 になり得ます。なぜなら、エージェントが事前に持っていない可能性のあるデータやシステム特性に関するより深い基盤を持っているからです。彼らはエージェントを異なる方向へ誘導したり、関連するクエリの結果を提供したり、パフォーマンスレベルのフィードバック（例えば、高コストなクエリを実行する代わりに、まずエージェントにレイテンシの見積もりを提供するなど）を提供することもできます。過去とは異なり今これが可能なのは、エージェントがあらゆる形式のテキストフィードバックを受け入れられ、厳密な SQL クエリの結果を期待していないからです。実際、データシステムはエージェントのために事前に関数化されたビューと仮想ビューの両方を準備し、これらをコンテキストの一部としてエージェントに提供することもできます。これは、エージェントがそれらを作成したり使用したりするよりも安価で効果的である可能性があるためです。

エージェントのためのデータシステム

以前は、エージェントがデータシステムとどのように相互作用するかについて焦点を当てていました。今では、エージェントが動作し続けるために必要な他のすべての要素、つまり彼らが住む場所、記憶する方法、互いと協調する方法、そして互いの障害に対処する方法について考察します。この「アジェンティック・サブストレート（基盤）」は、生来の知能を駆動する推論スタックとは別物です。ただし、推論スタック自体も、API を通じて（例えば OpenAI や Anthropic から）、あるいはオープンウェイトモデルの場合は低レベルの詳細を隠す serving frameworks によって抽象化されつつあります。これまでのところ、アジェンティック・サブストレートは、Claude Code や Codex といったハーンネスを通じて管理されており、記憶を store し retrieve するためのさまざまなメカニズムと組み合わされています。

まず、メモリに関する現状の知見では、ファイル がすべて必要であると考えられています。エージェントは構造化されていないマークダウン（MD）ファイルに書き込み、その後、grep による検索や埋め込みベースの検索によってそれらを検索します。実際、多くの人が、継続的な学習に対する解決策として、エージェントが膨大な量（例えば、コードベース全体、Slack、企業のウィキなど）を消費し、その学びを MD ファイルに書き込むことで、必要に応じて選択的にそれらを取得するべきだと主張しています。確かに、ファイルシステム、Bash スクリプト、MD ファイルは、そしてこれからもエージェントにとって重要であり続けるでしょう。しかし、スケールした規模において、エージェントが知識作業の大部分を担当するようになると、このアプローチはもはや効果的ではなくなります。

コンテキストウィンドウに限りがあるため、関連する可能性のあるすべての MD ファグメントを取得してコンテキストに詰め込むことは、いずれ限界を迎えます。コンテキストウィンドウがさらに拡大し続けたとしても、すべての情報をコンテキストに入れることによる遅延のメリットを無視することはできません。また、多くの場合、例えば知識作業が大規模データベースやコードベースとの対話を伴う場合、関連するすべてのデータをシリアライズしてコンテキストに含めることは現実的ではありません。

知識グラフ表現を利用することも可能ですが、構造化された検索機能の欠如により、知識グラフも非構造化 MD ベースのメモリと同様の制約に直面します。必要なのは、関心のある複数の属性（または側面）にわたって、タスクに関連するメモリのみを抽出できることです。例えば、不安定なテストのデバッグを行うエージェントは、キーワードや埋め込み類似性に基づく検索ではなく、関連するモジュール、言語、フレームワーク、および失敗モードでタグ付けされたメモリのみを取得できるようにする必要があります。別の問題として、実際に何を取得すべきかという点があります。ミスを伴う生のエージェントトレースはあまり有用ではなく、これらはエージェントが同じミスを繰り返す原因となるためです。むしろ、取得されるメモリは修正的なものであるべきです。

私たちは最近、構造化メモリ という関連する概念を探求しました。ここでは、メモリをさまざまな属性にわたって整理し、各属性は * を設定して普遍的な適用性を示すか、一致させるべき値のリストとして設定します。データエージェントにとって、次元には列やテーブル、操作の種類、そして最終的に自由記述形式の自然言語による修正指示などが含まれます。つまり、特定の種類の操作（例：「日付・時刻操作を行う際は、暦年ではなく会計年度を使用する」）や特定のテーブル（例：「製品名で照会する際は、列 product_cleaned を列 product より優先する」）にのみ適用されるメモリを含めることができます。一つの未解決の課題は、「アプリケーション固有の構造化メモリ」、あるいは他者がメモリのための世界モデルと呼ぶものを定義することです。私たちはこれを、各アプリケーションのためのスキーマを定義することに akin（類似）していると考えます。おそらくエージェント自身も、時間とともにそれを定義・洗練させるのを助けてくれるでしょう。

構造化メモリは、探索空間を効果的に管理するための 進化的 フレームワーク においても有用です。実際、単一のおよび マルチエージェント・トレース の大量データを保存し、構造化し、掘り起こすことは、将来のエージェントをより効率的にするのに役立ちます—これにより、構造化メモリに基づくメカニズムを通じて効果的な再帰的自己改善が可能になる可能性があります。

もう一つの課題は、多数のエージェントが変換処理を行っている際に、共有メモリに対する並行編集や、一般的な並行編集をサポートすることです。マルチバージョン管理 や コピーオンライトセマンティクス のサポートに向けた有用な試みは幾つか存在しますが、数千ものエージェントが同時に共有状態の編集を試みるような状況において、これらの手法で十分かどうかは不明です。例えば、ユーザーリクエストに応答してエージェントがさまざまな潜在的なトランザクションを試行している場合、これらのトランザクションの绝大多数の効果はロールバックされ、唯一「正しい」とされるトランザクションの結果のみが永続化される必要があります。ここで関連するのは、まさに一度だけ実行するセマンティクス（exactly-once semantics）をサポートするための取り組みであり、CRDT やオペレーショナル変換に基づく基盤技術も同様に重要です。メモリのようなファジーなメカニズムへの更新においては、レイテンシを優先して一貫性をある程度犠牲にしつつ完全な正しさを確保できる可能性があります。エージェントはセマンティクスについて推論することで行動の補償やロールバックを行い、最終的にほとんどのタスクを完了させることができますが、主要な課題はプロセス中に相互に足を引っ張り合う度合いにあります。回避すべき重要な失敗モードの一つとして、「ライブロック」と呼ばれる状態があります。これは絶え間ない補償アクションによって、意味のある進捗が全く生じなくなる現象です。

共有状態の他にも、多数のエージェントを支援する際には、エージェントが失敗した場合の対応や、エージェント同士がどのように通信すべきか（直接行うのか、中間の共有状態を介するのか）、また遅延して到着するエージェント（straggler agents）にどう対処するかといった課題が生じます。永続的なマルチエージェント実行をサポートするための取り組みとして Temporal などの開発が進んでいますが、数千規模のエージェント全体でこれらのソリューションが適用可能かどうかは今後の動向次第です。

通信の話題においては、エージェント同士が相互に交渉できるメカニズムが必要です。例えば、共通のスキーマ（schema）について合意形成を図ろうとする 4 つの開発者エージェントを想像してください。これらはそれぞれ明確ではあるが重複する目的を持っています。人間の場合、これは反復的な議論と妥協を伴うプロセスになりますが、エージェント群においては、それぞれの主たる依頼者の根本的な目標を反映した設計に収束させるためのメカニズムを定義する必要があります。あるいは、すべてのエージェントが限られたリソースへのアクセスを要求する場合も同様で、その際には通信が不可欠となります。これが中央集権的な調整を通じて行われるべきか、それとも分散型のアプローチが必要なのかについては、まだ結論が出ていません。

エージェントによるデータシステム

最後に、知能が実質的に無料になったのであれば、この知能を活用してゼロから新しいデータシステムを合成することが可能になります。実際、多くの環境では汎用型データシステムは過剰なほどであり、あらゆるスキーマ、クエリ、ハードウェアターゲットをサポートしなければならないからです。与えられたワークロードに対して、Bespoke OLAP や GenDB などの最近の研究では、エージェントパイプラインを使用して、数分から数時間で、数ドルのコストで、ワークロードに特化した完全な分析エンジンを合成できることが示されています。これらのエンジンは一時的なものであり、ワークロードが変化すれば、単に再生成するだけで済みます。同様に、私たちの研究でも、ワークロードを対象としたカスタム キーバリューストア をゼロから合成できることが示されています。実際、Kiro などの最新の IDE は、システム開発のための仕様を第一級市民として扱えるレベルにまで高めています。

しかし、主な問題は仕様書が通常は不完全であり、すべての隅々まで網羅していない点にあります。現在のエージェントは、欠落した仕様を悪用して報酬ハッキングを行い、高いパフォーマンス指標を達成しようとします。私たちのカスタムキーバリューストアにおける研究では、この問題を緩和する一つの方法として、補助的な検証エージェントにテストケースを生成させ、隅々での悪用を検出させることで、実質的に仕様書を拡張するというアプローチがあります。もう一つの手法は、システムの正しさを証明する証明とシステム自体を同時に生成する方法で、これについてはすでに 初期の成功 を見つけていますが、このアプローチを確固たるものにするためにはさらなる取り組みが必要です。さらに、人間が記述した仕様書をどのようにしてシステムに対して最も効果的に引き出すかがまだ不明です。これは反復的な人間-in-the-loop（人間が関与するループ）方式で行うことができるのか、それとも一度きりで不完全な形式に留まるのか。実際、手動で記述されたソフトウェアであっても人間による仕様書は不完全であり、より整合性の取れた未来のエージェントは、設計判断を下す際に次第により優れた判断力を発揮すると予想されます。