AIエージェントに必要なデータベースの要件は、すでに明確になっている

PerconaのCEOであるPeter Farkas氏は、The Registerとの最近のインタビュー（https://www.theregister.com/databases/2026/09/18/the-ideal-database-for-ai-agents-doesnt-exist-yet-says-percona-ceo/5296906）で、AIエージェント向けの理想的なデータベースアーキテクチャはまだ構築されておらず、専用システムをゼロから設計するにはエージェントのエコシステムが成熟する必要があると主張しました。ガバナンスフレームワークや運用境界など、エージェント展開の重要な側面がまだ流動的であるという彼の指摘は正しいです。AIデータベースのデータレイヤー要件は既に​​明確になっています。彼が説明したシナリオは、これらのワークロードが何を要求するかを示しています。

AIエージェント用のデータレイヤーは、運用データに対して直接、3つの要件を同時に満たす必要があります。第一に、Composability（構成可能性）により、事前に誰も記述していないアドホックなクエリに応答できること。第二に、Concurrency（同時実行性）により、多数のユーザーやエージェントからのクエリに同時に対応できること。第三に、Consistency（一貫性）により、すべてのクエリが現在の運用状態を参照でき、チェックとその後のアクションが同じデータを読み取ること。多くのデータベースはこれらの要件のうち1つか2つしか満たしていません。ビジネスアクションを実行するエージェントは、これら3つすべてを満たす必要があります。

AIエージェントが登場するずっと以前から、リアルタイムの不正評価やアルゴリズムによるリスク管理といったトランザクションシステム（機械学習を活用したものを含む）は、同様の要件に直面していました。エージェントが追加するのは、ソフトウェアが実行時に生成するクエリであり、しかもそれらのクエリがはるかに多く同時に実行される点です。

エージェント型AIおよび複数回試行型エージェントワークロードに必要なデータベース要件

Farkas氏は、AIエージェントが単一のタスクに対して150個の候補ソリューションを生成し、その後、人間または下流システムが最適なソリューションを選択するというシナリオを概説しました。人間のオペレーターは、これほど多くの選択肢を試すことはないでしょう。試行するたびに、企業データに対する1つ以上のクエリがトリガーされ、従来のデータベースでは想定されていなかったワークロードが発生します。

クエリは試行ごとに変化します。単一のワークフローでは、まずアクティブな顧客注文と在庫状況を確認し、次に現在の配送遅延と過去数年分の返品履歴を組み合わせて、代替製品を安全に提供できるかどうかを判断する場合があります。エージェントは実行時にこれらのクエリを作成するため、事前計算されたビューやキャッシュレイヤーは役に立たず、データベースはすべての回答をその場で計算する必要があります。

それらは同時に到着します。単一のタスクが数百のクエリに発展し、マルチエージェントシステムで多数のエージェントが既存のユーザーやアプリケーションと並行して実行されると、同時負荷は急速に増加します。トランザクションシステムは、予測可能なインデックス付きキーバリュー検索を提供することで、高い同時実行性を長年処理してきました。エージェントが予測不可能なクエリを大規模に発行する場合、データベースには各スキャンを関連データに限定するインデックスが必要です。インデックスがないと、エージェントのトラフィックによってシステム上の他のすべての処理が遅くなります。

いずれかのオプションが採用されると、エージェントは在庫のロックや保留などの運用上の変更を行い、これはビジネスの稼働状況に即座に反映されなければなりません。2つのエージェントが別々の同期されていないレプリカから在庫レベルを読み取ると、両方とも最後のアイテムが利用可能であると認識し、それを取得しようとする可能性があります。それぞれの判断は読み取ったスナップショットに対しては正しかったため、同じアイテムが2回販売されてしまいます。

Farkas氏は、モデル設計においても同様の問題があると指摘しました。すなわち、あらゆるタスクを試行するシステムは、得られる価値よりも実行コストが高くなるという問題です。データ層についても同様です。150回のクエリ実行のうち149回が破棄される場合、組織は1つの結果を得るために150回の計算処理に費用を支払うことになります。この比率では、各クエリのコストがエンジニアリング上の制約となります。データの冗長コピーに対して試行を実行すると、インフラストラクチャの費用が増大し、これらのコピーを同期するパイプラインは、試行の出力が保持されているかどうかに関わらず、継続的に実行されます。

アクティブデータインテリジェンスとは何か？

アクティブデータとは、保留中の注文や現在の口座残高など、ビジネス運営において常に使用されるリアルタイムの運用データのことです。ストリーミングデータは、パイプラインを通過するイベントのリアルタイムコピーです。アクティブデータは、注文や残高の変更に応じてその場で更新され、ビジネスの現状を常に正確に反映します。アクティブデータインテリジェンスは、同時実行エージェントが生成する運用データに構成可能な分析機能を提供することで、人、自動化システム、自律エージェントが、現状のビジネスを分析し、同じシステム内でそれに基づいて行動できるようにします。中間コピーがないため、データの作成から分析、意思決定、そして行動まで、プロセスは直接的に行われます。

それは、Farkas氏の例にある3つの要件を満たす必要があります。

• Composability（構成可能性）：ライブトランザクションと数年分の履歴を組み合わせる結合など、あらゆるクエリをオンデマンドで実行できる機能。
• Concurrency（並行処理）：インデックスを使用して各クエリのコストを低く抑えながら、ユーザー、アプリケーション、および自律エージェントからの大量のリクエストを一度に処理する能力。
• Consistency（一貫性）：すべてのクエリがシステムの同じ現在の状態を参照することを保証するものであり、検証とその後の処理が同じデータに基づいて行われることを意味します。

既存のデータシステムは、これらの要件のうち1つか2つを満たすことが多いです。データウェアハウスは、少数のアナリストチームのあらゆる質問に答え、トランザクションデータベースは、事前に分かっている質問に対して高い同時処理能力を発揮します。多くのワークロードは、構成可能性と同時処理能力の両方を必要とします。分析機能を製品に組み込んだソフトウェア企業では、数千もの顧客が同時に質問を投げかけてくるため、数秒の遅延はほとんど問題になりません。ビジネスアクションを実行するエージェントにも、一貫性が求められます。

運用データ上で直接実行することが重要なのは、中間コピーごとに分析結果と現在の状態との間に遅延が生じるためです。従来の意思決定パイプラインは、夜間のデータウェアハウス同期やキャッシュ層など、複製されたデータ上で依然として実行されています。この遅延は、数時間または数日かけて意思決定を行う人には適していますが、ソフトウェアやエージェントがミリ秒単位で動作する必要がある場合には問題となります。

AIエージェント向けのデータベースは、すでに成熟していると言えるだろうか？

Farkas氏は、データベースが成熟するまで待つべきだと主張し、確立された信頼できるデータベースプラットフォームがその実力を証明するのに数十年かかったこと、そしてAIエージェント向けに構築されたシステムにはまだその時間が経っていないことを指摘しました。

私はコンテナへの移行期にMesosphereで4年間勤務し、私のチームは製品スイートをKubernetesに移行しました。Kubernetesは2014年6月にGitHubで最初のコードを公開しました。その設計は、Googleが社内で10年近く大規模に運用していたクラスタマネージャであるBorgから着想を得ており、多くのエンジニアがBorgの開発に携わっていました。コードは新しいものでしたが、その要件はGoogleの規模で10年間実証されていました。要件とコードの成熟は異なるタイムラインで進み、多くの場合、要件の方が先に成熟します。

エージェント向けのデータベース要件も同様の道をたどりました。AIエージェントが登場するずっと前から、ソフトウェアは、カード取引の不正チェックやトレーディングデスクのリスク制限の適用など、人間が行っていた重大な意思決定を担うようになりました。これらのシステムは、ミリ秒単位の遅延で毎秒数千件の意思決定を行い、古いデータはすぐに損失につながります。承認後に不正が発覚すれば既に損失が発生しており、1分前のスナップショットを読み取るリスクチェックでは、制限を超える同時取引が通過してしまう可能性があります。こうしたワークロード向けに構築されたデータベースは、10年以上も本番環境で稼働しています。2011年にMemSQLとしてリリースされたSingleStoreもその一つです。

SingleStoreを導入している米国の大手銀行は、不正検出処理を夜間のバッチ処理からリアルタイムのトランザクション処理に移行しました。現在、同行のシステムは50ミリ秒以内に約70種類のクエリを実行しており、トランザクション承認に必要な1秒という時間制限を十分に下回っています。これは、AIエージェントのデータベースプロファイルと言えるでしょう。つまり、リアルタイムデータと履歴データの両方を対象に、1つのエンティティに関する多数のターゲットクエリを、厳しいレイテンシー制限の下で実行し、その回答によって支払いの可否が決まるのです。

違いは予測可能性にあります。銀行のエンジニアは、70個のクエリすべてを事前に作成し、調整していました。一方、エージェントは実行時にクエリを作成するため、事前に計算したり、個別に調整したりすることはできません。エージェントは、どのAIモデルを使用しているかにかかわらず、不正対策システムやトレーディングシステムで実証されたレイテンシと同時実行性の要件を継承し、誰も計画していなかったクエリでそれらの要件を満たさなければなりません。

どのエージェントワークロードが、構成可能性、並行処理、一貫性を同時に必要とするのか

エージェントによって、データベースに求めるものは異なります。エンタープライズエージェントのパイロットテストでは、4つのパターンがよく見られます。

検索および監視エージェントは、ベクトルインデックス、ベクトルデータベース、ストリームプロセッサなどの標準的なインフラストラクチャ上で正常に動作します。分析エージェント群には、製品に組み込まれた分析機能と同様に、構成可能性と並行処理の両方が必要です。小規模なアナリストチーム向けに構築されたデータウェアハウスは、前者と後者の一部のみを処理します。運用アクションにはこれら3つすべてが同時に必要であり、誤ったデータは直接的に金銭的損失につながります。

エージェントは時間の経過とともに、運用業務へと移行していく傾向があります。今日質問に答えていたサポート担当者が、明日には払い戻し処理の権限を与えられるかもしれません。収益変動を説明する分析担当者が、後に予算配分を変更するかもしれません。異常を検知する監視担当者が、保留措置を開始するかもしれません。権限が大きくなると、データ要件も厳しくなります。データを変更するエージェントは、同時に動作する他のすべてのシステムとの整合性を維持する必要があり、さらにシステム全体が独自のクエリを作成し続けることになります。

エージェント型AIのためのデータアーキテクチャを選択することは、将来エージェントにどのような処理を許可するかを決定する上で重要な判断となります。データ検索はコピー上で行えます。エージェントが処理を実行できるようになると、組織は期限に追われる中で本番データに移行するか、あるいは既に本番データに対応したインフラストラクチャ上で運用しているかのどちらかになります。組織がエージェントをどの程度信頼するかを決定するまでは、現在のクエリを処理し、将来発生するであろう処理にも対応できる基盤を構築することが、より安全な選択肢と言えるでしょう。

AIデータベースを構成する要素とは何でしょうか？

インタビューの最後に、Farkas氏は、PostgresやMongoDBを単に「AIデータベース」と改名することに反対するPerconaの立場を改めて表明しました。私も、アーキテクチャ上の理由から、その意見に賛成です。

既存のデータベースをAIに対応させる一般的な方法は、エンジン周辺に機能を追加することです。例えば、ベクトル拡張機能、検索インデックス、運用レコードをデータウェアハウスにミラーリングするためのETLパイプラインなどです。これらの追加機能はそれぞれ機能しますが、それぞれ独自の同期スケジュールでデータのコピーをもう1つ追加します。ベクトルインデックスは基となるテーブルに遅れて反映され、分析ウェアハウスは主要なトランザクションシステムに遅れて反映されます。これらのすべてをクエリしてからアクションを実行するエージェントは、ビジネスの3つの異なるバージョンを見ることになります。

データエンジニアリングでは、この問題は以前にも経験されています。2011年、ネイサン・マーズは、バッチ処理と高速処理を並行して実行することで完全性と鮮度の両方を実現する、ラムダアーキテクチャとして知られるようになった手法を発表しました。これは機能しましたが、チームは互いに矛盾する可能性のある2つのコードパスを維持する必要がありました。コピーに基づいて構築されたエージェントアーキテクチャも、同様のトレードオフを抱えています。エージェントは人間が不一致に気づく前に動作できるため、リスクは以前よりも高くなっています。

共有ストレージ上で別々のエンジンを実行することで、この問題の一部は解決されます。しかし、各エンジンは独自のトランザクション境界を持つため、一方のエンジンでのチェックと他方のエンジンでのアクションでは、異なる状態が認識される可能性があります。こうしたギャップは、後になってエクスポージャー制限の超過や在庫の過剰販売といった形で顕在化します。

SingleStoreは、アクティブデータインテリジェンス向けに構築された運用データベースです。トランザクション、分析、全文検索、ベクトル検索を単一のエンジンでライブデータに対して実行するため、アプリケーションやエージェントは、在庫確認と在庫予約を同じステップで行うなど、単一のACIDトランザクションで状態の読み取りと書き込みを行うことができます。新しい書き込みは行としてメモリに格納され、その後、圧縮されインデックスが付けられたカラムストアに移動するため、アドホッククエリは高い同時実行性でも高速に処理されます。データが古くなると、ローカルSSDからApache Icebergなどのオープンフォーマットのオブジェクトストレージへと階層化され、分析結果を変更することなくクエリコストを削減します。

従来の記録システムやデータウェアハウスは、依然として長期監査や履歴データに基づくモデル学習を担っています。しかし、AIエージェントなど、リアルタイムで意思決定や行動を行うワークロードには、単一のライブデータ基盤が必要です。

AIエージェント向けデータベースを評価するための重要な質問

ラベル付けは省略し、エージェント実行ループの要求に対してプラットフォームをテストしてください。弊社を含め、どのベンダーにも以下の質問をしてください。

1. クエリの適応性とレイテンシ： AIデータベースは、ライブ運用データと数年分の履歴を結合するアドホッククエリを、エージェントのループ内に収まるほど高速に実行できるか？
2. フリートの同時実行性：大規模なマルチエージェント環境で、本番アプリケーションと並行してこれらのクエリを実行する場合、応答時間はどの程度維持されるのか？
3. トランザクションの分離性：エージェントがアクションを実行する前に条件をチェックする場合、チェックとアクションは同じスナップショットを参照することが保証されるのか、それとも他のエージェントがその間に状態を変更できるのか？
4. 複製と遅延： AIアプリケーションと主要な記録システムの間には、いくつの中間データコピーが存在するのか？それぞれの同期遅延はどれくらいか？
5. 統一ガバナンス：ポイント検索、ベクトル検索、テキスト検索、広範な分析クエリなど、エージェント型AIが使用するすべてのパスを管理するには、1つのアクセス制御ポリシーで十分か？
6. 事後監査可能性：システムは、エージェントがアクションを実行した際に読み取った正確なデータを再構築および検証できるか？

試行回数が増えるほど、監査は難しくなります。エージェントが150個の候補パスを試してから1回だけアクションを実行する場合、149個の放棄された分岐が残ります。監査担当者に決定理由を説明するため、またエンジニアがデバッグを行うための情報を提供するために、最終的に成功した試行内容を正確に記録しておく必要があります。

リアルタイムデータのビジネスへの影響

リアルタイムデータに基づいて直接運用することで、コスト削減、新たな収益源の創出、損失の防止が可能になります。

コスト削減

パフォーマンス向上のためだけに存在するキャッシュやレプリカは、インフラストラクチャのコストと管理作業を増加させます。ワークロードを実際の運用データに移行することで、これらのコピーは不要になります。また、最初のアプリケーション以降は、同じ実際のデータ基盤を再利用するため、コストも削減されます。

新たな収益

顧客がまだ関心を持っている間にリアルタイムで意思決定を行うことで、以下のことが可能になります。

• 自動融資：金融機関は、中小企業が数分で融資を申請できるようにし、1秒で自動的に承認することができます。
• 小売業：小売業者は、買い物客がカートを放棄する前に代替商品を提案することができます。
• ダイナミックプライシング：マーケットプレイスは、需要と供給の変化に応じて価格を変更できます。

従来はスケジュールされたバッチジョブや静的レポートを待っていた処理が即座に実行できるようになるため、AIエージェントにも適しています。

少ない損失

損失防止は、最も簡単に測定できる投資収益です。

• 承認前に不正取引を検知し、阻止する。
• 在庫過剰販売や注文不履行を防ぐ。
• リアルタイムで厳格なリスクおよびエクスポージャー制限を適用する。

どこから始めればいいのか

Farkas氏は実践的なアドバイスとして、現在のワークロードに対応できるスタックを選択し、それが永遠に最良の選択肢であり続けるとは限らないことを挙げました。このアドバイスは、どこから始めるべきかを示唆するものでもあります。

ほとんどの組織では、既に何らかのワークロードで問題点が顕在化しています。例えば、クエリの遅延を回避するためにキャッシュを追加したり、口座残高を一致させるために2つのシステムを手作業で照合したりといったケースです。古くなったデータや矛盾したデータによって最もコストがかかるユースケースを見つけ出し、そのプロセスをライブデータ層に移行しましょう。

組織は依然として、AIエージェントにどの程度の自律性を与えるべきかを検討している段階です。エージェントが払い戻しや注文のフラグ付けを行う権限を得ると、リアルタイムの不正検出ツールや在庫予約ツールと同じデータとアクセス権限に基づいて動作します。このワークロードをアクティブデータに移行することで、エージェントが関与する前の段階でパフォーマンスが向上し、後から導入されるエージェントもビジネスの現状を把握した上で作業を開始できます。