AIエージェント向けデータベース：5つの評価基準

AIエージェント向けのデータベースを評価する5つの基準は、ブランチの分離、サーバーレスのスケリング、ハイブリッド検索、ACID保証、そして統合プラットフォームへのアクセスです。これらの基準を総合することで、開発者やデータチームは、エージェントをプロトタイプから本番環境へと移行させ、並行タスク、リアルタイムの運用データ、永続的な状態の処理を開始する際に、データベースがそのエージェントをサポートできるかどうかを判断できます。

AIエージェント向けデータベースとは、エージェントが複数のステップやセッションにわたってタスクを完了するために必要な状態、メモリ、ツールの実行結果、および運用データを保存するように設計されたシステムです。従来のアプリケーションに対応するデータベースとは異なり、繰り返しの読み書き、エージェントの並行アクティビティ、さまざまな種類のメモリにわたる検索、そして最新の運用データへのアクセスをサポートする必要があります。

AIエージェントの台頭により、これらの要件はさらに重要性を増しています。開発者がコーディングエージェント、カスタマーサポートエージェント、またはマルチテナントプラットフォームを実行する場合、エージェントは単に情報を検索する以上のことを行います。状態を書き込み、タスクを再開し、ツール呼び出しを調整し、変化する運用データに基づいて動作します。データチームがエージェントを本番環境に移行する際、データベースの制限によって、メモリの陳腐化、書き込みの競合、レイテンシ、不要なコンピュートコストが発生する可能性があります。

AIエージェント向けデータベースが異なる課題である理由

本番環境に対応したエージェントは、すでに行ったことを記憶し、中断したところからタスクを再開し、行動する前に適切なコンテキストを取り込む必要があります。不適切なデータベースと組み合わせると、そのメモリは古くなったり、不完全になったり、不整合が生じたりする可能性があります。

本番環境のエージェントは、これを実現するために4つのメモリレイヤーに依存しています。

• 短期メモリ：最近のメッセージ、検索された情報、ツールの結果など、現在のインタラクション中に利用可能なコンテキスト内のワーキングメモリ。
• エピソードメモリ：エージェントが以前の会話、ユーザーの好み、完了したタスクを思い出すことを可能にする、過去のインタラクション。
• 手続きメモリ：外部に保存されているかモデルに組み込まれているかを問わず、タスクの実行方法をガイドするワークフロー、ツールの定義、および指示。
• 運用状態：完了したステップと保留中のステップ、ツールの出力、後で作業を再開するためのチェックポイントなど、タスクのリアルタイムのステータス。

これは、データベースにクエリを送信して次の処理に移る一般的なアプリケーションよりも、はるかに複雑なワークロードです。ほとんどの本番データベースは、運用データベース（オンライン取引処理（OLTP）システムとも呼ばれます）であり、この「一度に1つのリクエスト」という同じパターンを中心に構築されています。エージェントはそのようには動作しません。単一のタスク内で、人間による一時停止を挟むことなく、読み取りと書き込みを何度も繰り返し実行します。しかも、他の何百ものエージェントが同時に同じことを行っています。

AIエージェントのワークロード向けデータベースを評価するための5つの基準

AIエージェント用のデータベースを選択する際、いくつかの基準が重要になりますが、マネージドかセルフホストかを問わず、どのベンダーを検討する場合でも、評価する価値があるのは以下の5つです。

エージェントごとのブランチ：実際のデータに対する安全なテスト

合成データのみに対してエージェントをテストすることは、完璧にフォーマットされた一握りの顧客アカウントでサポートシステムをテストするようなものです。期待通りに動作するかもしれませんが、実際のアカウントは常に煩雑です。データチームは最終的に、テストフィクスチャには含まれていなかった欠損フィールド、不整合なレコード、古いデータ、エッジケースに直面することになります。

そのため、実際のデータに対する隔離されたテストをデータベースの評価基準として扱うことをお勧めします。その目的は、エージェントに本番環境を変更する手段を与えることなく、本番環境に近い状態で動作させることです。その隔離を実現する1つの方法がゼロコピーブランチです。これにより、開発者はデータベースの完全なコピーをもう1つ維持することなく、別の環境を作成できます。

Lakebase Projectsは、開発者が基盤となるデータをコピーすることなく本番データからブランチを作成できるようにすることで、このような隔離された開発とテストを処理できるように設計されています。テラバイト規模の本番データベースのブランチ作成には約1秒しかかからず、ブランチが親から分岐するまで追加のストレージコストは発生しません。

ゼロへのスケール：サーバーレス価格設定がエージェントの経済性をどのように変えるか

毎年、クラウド支出の27%が無駄になっており、アイドル状態や十分に活用されていないコンピュートが一貫してその最大の要因となっています。エージェントデータベースは、その理由を示す分かりやすい例です。ほとんどのエージェントは継続的に実行されません。起動してタスクを実行し、結果を書き込み、次のリクエストが来るまで休止します。24時間体制で専用コンピュートの料金を支払うことは、チームが実行しているすべてのエージェントデータベースで、同じアイドルコンピュートの問題に対して料金を支払うことを意味します。

サーバーレスの「ゼロへのスケール」モデルは、アクティブな接続がない期間が続いた後にコンピュートを一時停止し、作業が再開されたときに再開することで、この問題に対処します。これにより、コストはアイドル時間ではなく、実際の使用状況に連動するようになります。ただし、起動速度はコスト削減と同じくらい重要です。データベースの起動に20秒や30秒も待たされるエージェントは、特にユーザーに応答しているときや次のツール呼び出しを待っているときには実用的ではありません。

LakebaseはPostgresにこのモデルを採用しており、新しいクエリから数百ミリ秒以内にコンピュートが再開されます。これにより、起動の遅延が十分に小さく抑えられ、インタラクティブなエージェントのワークロードでゼロへのスケールが機能するようになります。

ハイブリッド検索：1つのクエリで4つのメモリレイヤーすべてを検索

ベクトル検索だけでは、「何となく似ているもの」だけでブラウズでき、正確な請求記号では検索できない図書司書のようなものです。データベースアーキテクチャに関するドキュメントを探すように頼めば、うまく機能するでしょう。しかし、アカウントID「48291」のレコードを求めると、そこに確実にたどり着く方法はありません。意味的類似性は、完全一致のために構築されているわけではないからです。

これこそが、多くの検索拡張生成（RAG）パイプラインがベクトル検索のみに依存している場合に直面するギャップです。ハイブリッド検索は、別々のシステムからの結果を繋ぎ合わせるのではなく、単一のクエリでベクトル類似性、キーワードマッチング、メタデータフィルタリングを組み合わせることで、このギャップを埋めます。これをベクトルインデックスとリレーショナルストアに分割すると、エージェントは1回ではなく2回の呼び出しを行うことになります。システム間で同期がずれる可能性があり、ホップが増えるたびにレイテンシが追加され、エージェントのループがそれを常に吸収できるとは限りません。検索を100ミリ秒未満に抑えることは、緊密な推論サイクル内で実用性を維持するために不可欠です。

Lakebase Searchは、運用データがすでに存在する同じPostgresテーブルに対してベクトル、キーワード、メタデータのクエリを実行するため、同期がずれるような第2のシステムは存在しません。そのLTAPアーキテクチャにより、データは最新の状態に保たれ、書き込みパフォーマンスは標準のPostgresよりも最大5倍高速です。つまり、エージェントが書き込んだばかりの内容を、ほぼ即座に検索に利用できるようになります。

マルチエージェントシステムにおけるACID保証

2つのサポートエージェントが同じ顧客レコードを同時に更新している状況を想像してみてください。一方は請求の問題を解決してサブスクリプション層を調整しており、もう一方は返金を記録しています。適切な分離が行われていないと、一方の更新が他方の更新を上書きしてしまい、どちらのエージェントも意図しない状態でレコードが残されてしまう可能性があります。

そのため、マルチエージェントのワークロード向けにデータベースを評価する際、トランザクション保証は必須の基準となるはずです。ACIDは、開発者が確認すべき4つの特性を提供します。

• 原子性（Atomicity）：トランザクションが完全に完了するか、まったく完了しないかのどちらかになります。
• 一貫性（Consistency）：データベースは、すべてのトランザクションの前後で有効な状態を維持します。
• 分離性（Isolation）：並行トランザクションが、予期しない方法でお互いの作業を妨害することはありません。
• 永続性（Durability）：コミットされた書き込みは、クラッシュや再起動後も維持されます。

マルチエージェントシステムにおいては、頭字語（アクロニム）そのものよりも、実用的な問いの方が重要です。ツールの出力コミットを原子的に実行し、中途半端なアクションが完了したものとして処理されないようにすることは可能か？2つのエージェントが同じレコードを更新するとどうなるか？データベースはどの分離レベルをサポートしているか？コミットされた状態を失うことなく、再起動後にエージェントを再開できるか？

データベースを比較する際は、単に「トランザクションをサポートしている」という主張だけでなく、実際にサポートしている分離レベルとコミットセマンティクスを確認することをお勧めします。複数のエージェントが運用データを共有するようになると、並行作業が予測可能な状態に保たれるかどうかは、これらの詳細によって決まります。

統合プラットフォーム：ETLなしでAIスタックに運用データを統合

パイプラインの追いつきを待っているエージェントは、古いデータに基づいて意思決定を行っていることになります。そのパイプラインが実行される頃には、処理対象のレコードがすでに再び変更されている可能性があります。データベースを評価する際は、運用データと、それに依存する分析およびAIシステムがどれほど緊密に連携しているかを確認してください。

統合プラットフォームにより、個別の抽出・変換・書き出し（ETL）パイプラインを間に挟むことなく、同一データに対してオペレーショナルな書き込みと分析用の読み取りを維持できます。エージェントは最新のデータを利用でき、モデルはバッチ処理を待つことなくリアルタイムの結果を使用できます。また、データチームはエージェントのワークロードを追跡が困難な別のシステムに移行させることなく、同一プラットフォーム上でガバナンスと監査証跡を維持できます。 Unity Catalogは、Databricksにおけるオペレーショナルデータと分析データの両方にわたって、そのガバナンスレイヤーを適用するものです。 Superhumanの事例は、これが実際にどのように機能するかを示しています。キャッシュレイヤーやマネージドNoSQLストアへのカスタム同期パイプラインを統合プラットフォームに置き換えることで、データ統合の期間を3か月近くから約2週間に短縮しました。

easyJetも、レベニューマネジメントのスタックで同様のアプローチを採用しました。Since moving to Lakebaseに移行して以来、同社は同一のレイクハウスデータ上で分析と同時にリアルタイムの予約・価格設定アクティビティをキャプチャし、100以上のGitリポジトリを2つに統合し、アプリの開発サイクルを6〜9か月から約4か月に短縮しました。

LakebaseはオペレーショナルデータをDatabricksレイクハウスに保持するため、個別のETLパイプラインを必要とせず、同一のデータでトランザクションワークロードとダウンストリーム分析の両方をサポートできます。

AIエージェントデータベース評価スコアカード

比較対象のベンダーに関わらず、候補となるデータベースをこれら5つのチェックにかければ、どこが優れていてどこが不足しているかが数分でわかります。

これらの最低基準のうち2つ以上に合格しないデータベースは、エージェントを大規模に運用する際にプロダクション環境でのリスクとなります。後から回避できるような些細なトレードオフではありません。

まとめ

AIエージェント用のデータベースの選択は、機能リストではなく、ワークロードへの適合性で決まります。このガイドに記載されている5つの基準は、開発者やデータチームがプロダクション環境に導入する前に、あらゆるデータベースを評価するための実用的なフレームワークを提供します。候補となるデータベースが現在これらの要件を満たせない場合、より多くのユーザー、タスク、同時実行ワークロードを処理するようになると、最終的にプロダクション環境のエージェントでその欠陥が露呈することになります。

AIエージェント用のデータベースを評価している場合は、 Lakebaseを探索して、Databricksがトランザクションワークロード、ブランチ作成、サーバーレススケーリング、ハイブリッド検索、およびオペレーショナルデータへの統合アクセスをどのようにサポートしているかを確認してください。

よくある質問

AIエージェントにデータベースは必要ですか？

はい、必要です。ほとんどのエージェント実装では、明示的に永続化して再ロードしない限り、呼び出し間で短期的なコンテキスト、エピソード履歴、手続き的知識、またはリアルタイムのタスク状態が保持されません。データベースがない場合、通常、エージェントはセッションが終了した瞬間にそのコンテキストを失い、中断したところからタスクを再開することができなくなります。

AIエージェントにはベクトルデータベースだけで十分ですか？

単体では十分ではありません。ベクトルデータベースはセマンティック検索を適切に処理しますが、エージェントはオペレーショナルな状態の書き込みや更新、同時書き込みにおけるトランザクションの整合性の確保、類似度検索では確実にとらえられない構造化フィールドのフィルタリングも行う必要があります。セマンティック検索はエージェントが必要とする機能の一部をカバーしているに過ぎず、ワークロード全体をカバーしているわけではありません。

AIエージェントのRAGに最適なデータベースは何ですか？

唯一の正解はありません。AIエージェントのRAGにおいて最適なデータベースとは、1つのクエリでハイブリッド検索を実行でき、エージェントのループに対して十分に高速な検索を維持でき、メモリの陳腐化を防ぐために十分に最新の状態を保てるデータベースです。

マルチエージェントシステムはデータベースの要件をどのように変えますか？

複数のエージェントが共有データに同時に書き込みを行うようになると、トランザクションの整合性は必須になります。データベースは、あるエージェントの更新が別のエージェントの更新を警告なしに上書きしないように同時書き込みを分離する必要があり、また、中途半端なアクションが完了したものとして処理されないように、ツールの出力をアトミックにコミットする必要があります。

AIエージェントにおけるOLTPとOLAPの違いは何ですか？

エージェントのリアルタイムのアクション、ツールの出力の書き込み、状態の更新、および進行状況のチェックポイント作成は、 OLTPワークロードです。そのデータ上でのレポート作成やモデルトレーニングはOLAPワークロードです。エージェントがそれらの間にパイプラインを挟むことなく同一のデータから動作するには、通常、両方が必要になります。そのため、このガイドの基準では、トランザクションの多いエージェントの作業とダウンストリーム分析の両方を同一のデータから処理できるデータベースに焦点を当てています。

PostgresはAIエージェントに適していますか？

標準的なPostgresは、強固なACID保証と成熟したエコシステムを提供し、エージェントが必要とする機能の一部をカバーします。しかし、それ自体ではゼロコピーのブランチ作成、ゼロへのスケール（scale-to-zero）コンピュート、または統合されたオペレーショナルおよび分析アクセスは提供されません。これらは、その周囲に構築されたプラットフォームに依存します。

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