エージェント型AIを本番環境に投入しようとするエンタープライズのデータチームは、データ層で一貫した失敗ポイントにぶつかっている。ベクトルストア、リレーショナルデータベース、グラフストア、レイクハウスのそれぞれにまたがって構築されたエージェントには、コンテキストを最新に保つための同期パイプラインが必要だ。しかし本番の負荷がかかると、そのコンテキストが古くなる。
フォーチュン・グローバル100のうち97%の企業の取引システムを同社の自己申告によれば支えているオラクルは、いまや、その問題を解決するのにデータベースこそが適切な場所だという、直接的なアーキテクチャ上の主張を打ち出している。
オラクルは今週、Oracle AI Database向けのエージェント型AI機能群を発表した。これは、そのパターンに対する直接的な反論を土台に構築されている。
今回のリリースの中核はUnified Memory Core（統合メモリ・コア）だ。これは、単一のACID（Atomicity、Consistency、Isolation、Durability＝原子性、一貫性、分離性、耐久性）トランザクション・エンジンであり、同期レイヤーなしでベクトル、JSON、グラフ、リレーショナル、空間、列指向データを処理する。さらにオラクルは、Apache Icebergのテーブルに対するネイティブなベクトル索引として、Icebergテーブルを参照するVectors on Iceを発表した。また、スタンドアロンのAutonomous AI Vector Databaseサービス、そしてエージェントがカスタム統合コードなしで直接アクセスできるAutonomous AI Database MCP Serverも発表した。
今回のニュースは、オラクルが新機能を追加したというだけではない。名前の由来になっている自社のデータベースが提供してきたものを超えて、AIの世界で何かが変わったことに、世界最大級のデータベースベンダーが気づいている、という点にある。
「皆が今日、すべてのデータをオラクルのデータベースに保存しているんだよと言いたい気持ちはあるけれど、あなたも私も現実の世界で生きている」オラクルでMission-Critical Data and AI Enginesのプロダクトマネジメント担当バイスプレジデントであるMaria Colgan氏はVentureBeat.にこう語った。「それが本当ではないことは分かっています。」
4つの機能、分断されたエージェント・スタックに対する1つの建築的な賭け
オラクルの今回のリリースは、相互に連携する4つの機能にまたがっている。これらは合わせて、特化したツールのスタックよりも、収束（統合）されたデータベース・エンジンの方が本番のエージェント型AIのより良い基盤になる、という建築上の論拠を形作る。
Unified Memory Core（統合メモリ・コア）。複数のデータ形式を同時に推論するエージェント――ベクトル、JSON、グラフ、リレーショナル、空間――には、それらの形式が別々のシステムに存在する場合、同期パイプラインが必要になる。Unified Memory Coreは、それらすべてを単一のACIDトランザクション・エンジンにまとめる。内部では、Oracleのデータベース・エンジン上のAPIレイヤーであるため、別個の整合性メカニズムを用意しなくても、すべてのデータ型にわたってACIDの一貫性が適用される。
「メモリをデータと同じ場所に置くことで、データベース内のデータと同じように、アクセスできるものをコントロールできます」Colgan氏は説明した。
Vectors on Ice（Ice上のベクタ）。オープンソースのApache Icebergテーブル形式でデータレイクハウス・アーキテクチャを運用しているチーム向けに、オラクルは、Icebergテーブルを直接参照するベクトル索引をデータベース内に作成するようになった。その索引は、基盤となるデータが変化すると自動で更新される。さらに、DatabricksやSnowflakeによって管理されているIcebergテーブルとも連携する。チームは、Icebergのベクトル検索を、Oracleに保存されたリレーショナル、JSON、空間、グラフのデータと組み合わせて、単一のクエリで実行できる。
Autonomous AI Vector Database（自律型AIベクトル・データベース）。Oracle 26aiエンジン上に構築された、完全マネージドで開始が無料のベクトルデータベース・サービス。このサービスは、開発者の入口となることを想定しており、ワークロード要件が増えてきた際には、ワンクリックでフルのAutonomous AI Databaseへアップグレードできるよう設計されている。
Autonomous AI Database MCP Server（自律型AIデータベースMCPサーバー）。外部のエージェントやMCPクライアントが、カスタムの統合コードなしでAutonomous AI Databaseに接続できるようにする。エージェントが接続した際に、Oracleの行レベルおよび列レベルのアクセス制御が適用される。エージェントが何を要求するかにかかわらず、適用は自動で行われる。
「同じ標準API呼び出しを、ほかのプラットフォームで行うのと同様にしていても、LLMがそうした質問を投げているときにユーザーに付与されている特権が引き続き効いてくる、という点があります」Colgan氏は述べた。
スタンドアロンのベクトルデータベースは出発点であって、到達点ではない
Autonomous AI Vector Databaseは、Pinecone、Qdrant、Weaviateなどの専用に作られたベクトル・サービスが占める市場に投入される。オラクルが引いている違いは、「ベクトルだけでは十分でないときに何が起きるか」に関するものだ。
「ベクトルが終わったら、本当に選択肢はありません」オラクルのプロダクトマーケティング担当グローバル・バイスプレジデントで、データベースおよび自律型サービスを率いるSteve Zivanic氏はVentureBeatにこう語った。「これにより、グラフ、空間、時系列など、必要なものを手に入れることができます。行き止まりではありません。」
Constellation ResearchのプリンシパルアナリストであるHolger Mueller氏は、別のベンダーがこれを（まずデータを移すことなく）実現できないため、この建築的な主張がまさに説得力を持つのだと述べた。ほかのデータベースベンダーでは、エージェントがそこにわたって推論できるようになる前に、トランザクションデータをデータレイクへ移すことが必要になる。Mueller氏の見解では、オラクルの統合されたレガシー（既存資産）を収束させたアプローチが、土台からの作り直しなしには再現しにくい構造的な優位性を与えている。
しかし、機能セットが差別化されていると見る人が全員ではない。HyperFRAME ResearchのCEO兼プリンシパルアナリストであるSteven Dickens氏はVentureBeatに対し、ベクトル検索、RAG統合、Apache Icebergのサポートは現在ではエンタープライズ・データベースにおける標準的な要件になっており、Postgres、Snowflake、Databricksはいずれも同等の機能を提供している、と語った。
「オラクルが“データベースそのものをAI Databaseと呼ぶ”ように動いたことは、主に、現在のヒープサイクルに合わせるための、収束したデータベース戦略のリブランディングだ」Dickens氏は述べた。氏の見立てでは、オラクルが主張する本当の差別化点は機能レベルではなく、アーキテクチャ・レベルにある。そしてUnified Memory Coreこそが、この主張を成り立たせるか、崩すかの分かれ目だ。
エンタープライズのエージェント導入はどこで実際に行き詰まるのか
オラクルが今週出荷した4つの機能は、具体的で、かつよく文書化された本番の失敗パターンに対する回答だ。エンタープライズのエージェント導入がモデル層で崩れているわけではない。崩れているのはデータ層である。分断されたシステムにまたがって構築されたエージェントは、ワークロードがスケールした瞬間に、同期レイテンシ、古くなったコンテキスト、一貫性のないアクセス制御に直面する。
Moor Insights and Strategyのバイスプレジデント兼プリンシパルアナリストであるMatt Kimball氏はVentureBeat に対し、本番環境の制約が最初に表面化するのはデータ層だ、と語った。
「それらを本番で動かすことが大変なのです」Kimball氏はこう言った。「ギャップはほとんど即座にデータ層で見えてきます――アクセス、ガバナンス、レイテンシ、一貫性。これらがすべて制約になります。」
Dickensは、この根本的な不一致を、ステートレス対ステートフルの問題として捉えている。多くのエンタープライズ向けエージェント・フレームワークでは、メモリを過去のやり取りをフラットなリストとして保存する。つまり、エージェントは事実上ステートレスになる一方、クエリ対象のデータベースはステートフルだ。両者の遅れの部分で、判断が間違ってしまう。
「データチームは、分断に疲れ切っています」Dickens氏は語った。「1つのエージェントを動かすだけのために、別々のベクトルストア、グラフデータベース、リレーショナルの仕組みを管理するのは、DevOpsの悪夢です。」
オラクルのUnified Memory Coreがまさに排除しようとしているのは、その分断そのものだ。次に来るのはコントロールプレーンの問いである。
「従来のアプリケーションモデルでは、コントロールはアプリ層にあります」Kimball氏は言った。「しかしエージェント型システムでは、エージェントがアクションを動的に生成し、ポリシーの一貫した強制が必要になるため、アクセス制御がかなり早く崩れます。そうしたすべてのコントロールをデータベースに押し込めれば、より一様なやり方で適用できます。」
これがエンタープライズのデータチームに意味すること
エンタープライズのエージェント型AIスタックにおいて、制御がどこにあるべきかという問いは、まだ決着していない。
ほとんどの組織は、いまだに断片化されたシステム群にまたがって構築を続けています。そして、今まさに下されているアーキテクチャ上の意思決定――どのエンジンがエージェントのメモリを基盤とするのか、どこでアクセス制御が適用されるのか、レイクハウスのデータがどのようにエージェントのコンテキストへ取り込まれるのか――は、大規模になるほど、覆すのが難しくなります。分散データの課題こそが、いまなお本当の試金石です。
"データはSaaSプラットフォーム、レイクハウス、イベント駆動型システムにますます分散されており、それぞれが独自のコントロールプレーンとガバナンスモデルを持っています"とキンボール氏は述べました。"いまの機会は、そのモデルを、今日のほとんどの企業環境を定義する、より広範で分散度の高いデータ資産全体へと拡張することにあります。"
