AIエージェントのデータ層最前線：記憶、ツール、開発体験の進化

このパネルディスカッションは、AIエージェントのツーリング、特にその基盤となるデータ層に焦点を当てています。モデレーターはGradient VenturesのパートナーであるDenise Tang氏です。本日は、NetlifyのApplied AI担当VPであるSean Roberts氏、MongoDBのAI/ML担当シニアプロダクトマネージャーであるPrahul Agarwal氏、そしてDatabricks傘下のNeonでプロダクトスタッフを務めるBrian Holt氏をお迎えし、この重要なテーマについて議論します。

Denise氏は冒頭で、投資家としての立場から、エージェントが実世界のデータにアクセスできることが、ビジネスコンテキストやユーザーの具体的なユースケースに沿った意味のある価値を生み出す上で不可欠であると強調しました。そして、パネルの最初の問いとして、現在のデータ層、具体的にはベクトル検索、Retrieval API、コンテキストエンジニアリング、エージェントの記憶といった領域において、何が機能し、何が課題であり、そしてエージェントのために特別に設計される可能性のある新しい機能は何であるか、という核心的な質問を投げかけました。

AIエージェントにおける「記憶」の重要性

MongoDBのPrahul Agarwal氏は、AIエージェントにとって「記憶（Memory）」が最も重要な差別化要因として浮上していると指摘しました。彼は2024年を「記憶の年」と表現し、これまでのプロンプトエンジニアリング中心の議論が、より広範な「コンテキストエンジニアリング」へと移行している現状を説明しました。

記憶はエージェントの中核であり、それに伴い、従来のデータベース（OLTP/OLAP）、ベクトルストア、AIストアといった概念が個別に存在するという考え方から、ある種の「収束」が起こりつつあると述べています。徐々に洗練されたエージェントを構築する際には、以下の要素を考慮に入れる必要があります。

• リアルタイムデータの必要性: エージェントが常に最もリアルタイムなデータを把握している必要があります。
• 真のソースへの連結: データは常に真のソースに結びついており、データに変更があった際に最新の情報が取得できることが極めて重要です。
• IDとセキュリティへの統合: これらの要素が孤立して機能することは許されず、統合された環境で扱う必要があります。

開発者は、AIの記憶をどのように構築し、どのように管理していくかを日々模索しています。Prahul氏はまた、従来のETL（Extract, Transform, Load）プロセスや、異なるシステム間でデータを分離して考えるアプローチが崩壊しつつあると指摘しました。推論モデルや推論エージェントにおいては、単にデータを一度に提供するだけでは不十分です。推論の各ステップで必要なデータが提供され、それが共有される必要があります。これは、データの管理方法、すなわち「何を新しく取得すべきか」「後続の処理のために何を保存すべきか」「処理の進行に伴って何を削除すべきか」といった判断を、エージェント自身が行うか、またはそのための仕組みを構築する必要があるという大きな変化を意味します。

データツールの簡素化と専門化

Neon（Databricks）のBrian Holt氏は、Prahul氏の意見に深く同意しました。彼は、エージェントにメモリ内データ、データベース、分析プールなど、あらゆる種類の断片化されたデータソースを無作為に与え、「あとはエージェントに任せる」というアプローチがうまくいかないことを強調しました。このような状況では、エージェントは古いデータを返したり、誤ったデータソースから情報を取得したり、不適切にキャッシュされたデータを使用したりする傾向が見られます。

この課題に対する成功パターンとして、ツールの表面積を減らし、例えば「Retrieveツール」のような、一般的なデータプールから情報を取得するためのシンプルで汎用的なツールやスキルに集約することが非常に効果的であると述べています。

Brian氏は、Neonが以前に多数のAPIを公開した際、興味深い経験をしたと語りました。エージェントは、手作業で作成された洗練されたマイグレーションツールをほとんど使用せず、常に「生SQLツール」を好んで使用したとのことです。これは、エージェントが必ずしも「手作りで決定論的なコード」を好まないことを示唆しています。成功している傾向としては、ツールの数をわずか1つか2つ（例えば「これを持ってきて」のような非常にシンプルな命令）にまで削減することが挙げられます。さらに、以前のセッションでSentryの担当者が言及した「サブエージェント」や「専門家」にデータ取得タスクを委任し、メインのエージェントにそのコンテキストの負担をかけないというアイデアも有効であると付け加えました。

関連性と開発者体験の追求

NetlifyのSean Roberts氏は、自身のチームがこれら全ての要素を統合し、優れた開発者体験を提供する側にいると述べました。彼が注目しているのは、「最新で最も新鮮なデータ」という概念が、非常に相対的であり、特定の時点、ユースケース、環境などによって大きく異なるという点です。

システムは、このような複雑な状況をより適切に処理できるよう、進化していく必要があります。具体例として、LLMがSDKのバージョン1でトレーニングされており、最新バージョンが3であるにもかかわらず、顧客はバージョン2を使用しているというケースを挙げました。このような状況で、単に最新のドキュメントを提供するだけでは不十分であり、顧客の状況に特化した関連性の高いコンテキストを提供することが求められます。

最初はLLMだけで十分と考えられていましたが、その後、最新のドキュメントを無条件に提供することでオーバーシュートしてしまいました。業界としては、今後はより専門化された、状況に応じたコンテキスト提供へと進んでいくことを強く期待していると述べました。

最低限必要なデータスタックとは？

Denise Tang氏は、AIエージェントを初めて構築しようとするチームにとって、最も「最低限の実行可能なデータスタック（Minimal Viable Data Stack）」またはデータツールは何であるか、という実用的な問いを投げかけました。ベクトルデータベースやRetrieval APIは常に必要とされるのか、という点について、パネリストの意見を求めました。

まとめ

本パネルディスカッションでは、AIエージェントの進化を支えるデータ層の最前線について、多角的な視点から深く掘り下げられました。パネリストたちは、エージェントにとって「記憶」が最も重要な差別化要因であり、データ管理が従来のETLモデルから大きく変化していることを強調しました。

また、エージェントが効果的に機能するためには、多数の複雑なデータツールを与えるのではなく、「Retrieveツール」のようなシンプルで集約されたインターフェースを採用し、さらに専門化されたサブエージェントに特定のタスクを委任するアプローチが有効であるという洞察が共有されました。

「最新のデータ」の解釈は相対的であり、特定のユースケースや状況に合わせた適切なコンテキストを提供することの重要性も指摘されました。AIエージェントの開発はまだ初期段階にありますが、記憶の管理、ツールの簡素化、そして状況に応じたコンテキスト提供が、今後の成功の鍵となるでしょう。

参考動画

YouTube動画: Agent Tooling: Data Layer, Memory, Retrieval APIs & More