TL;DR

  • Oracle AI World 2026 のセッション「Oracle AI Database: What’s New and What’s Next」では、APEXlang、Agent Memory、Data Safe の進化など、Oracle AI Database の新しい機能や強化が紹介された。
  • AI エージェントの記憶や権限の制御を DB の中に持たせる機能と、マルチクラウドでの選択肢、パッチ適用の自動化とバックアップのリージョン間複製が同時に強化されている。
  • 本記事では、OCI Top Partner Engineers の視点で、それぞれの新機能やアップデートを、考察を交えて紹介する。

はじめに

OCI Top Partner Engineers 2026 の今井です。

今週は Oracle AI World 2026 に参加するため、ラスベガスに来ている。 2026年10月27日 11:45〜12:30（PDT）に行われたセッション「Oracle AI Database: What’s New and What’s Next」（LRN6095）では、Hasan Rizvi 氏（EVP, Product and Research, Database Engineering, Oracle）が、セッション名のとおり、Oracle AI Database の What’s New と What’s Next を紹介した。

セッション会場の看板表示。セッションの後に撮影
セッション会場の看板表示。セッションの後に撮影

このセッションは写真撮影が禁止だったため、本記事にはセッション中の写真を載せていない。 本記事では、新しく紹介された機能を中心に取り上げる。

セッションの全体像

セッションは、AI がデータベースに求めるものを4つに整理して進んだ。データの近くで AI を動かす「AI designed for data」、乱立するデータ基盤をまとめる「End data chaos」、動かす場所や AI を選べるようにする「End data lock-in」、データを守る「End data risk」だ。

全体を通して、「注文が遅れているのはなぜか」という顧客の問い合わせに AI が答える例が使われた。一般的な AI の回答と、自社のデータを知る AI の回答を比べ、その違いはデータにあるという話から始まった。

紹介された機能とできること

セッションで紹介された機能を、利用者の目線でまとめると次のとおりだ。

機能 できること
Agent Memory エージェントの記憶（会話、ドキュメント、構造化データ、関係、履歴など）を、業務データと同じ DB で管理する
APEXlang AI が生成した、読める形の宣言的なアプリ定義をチームがレビュー・版管理し、APEX Engine が実行する
GoldenGate Data Fabric 分散したデータの変更を、リアルタイムでアプリ・分析・AI に届ける
Base Database Cloud@Customer Base Database Service を自社のデータセンターで動かす
Oracle Migration Accelerator Oracle とパートナーがクラウドへの移行を支援する
Database Tools MCP Server MCP クライアントから Oracle AI Database に、アクセス制御付きでつなぐマネージドサービス
Autonomous AI Lakehouse Apache Iceberg のデータを含めて、Oracle 以外のデータにも Oracle の分析・AI を使う。Live AI Hub で運用データにもリアルタイムでアクセスする
Oracle Deep Data Security エンドユーザーごとのプライバシールールを DB で定義し、どの経路のアクセスにも強制する
Fleet Automation / Data Subsetting パッチ適用をフリート単位で自動化し、本番より小さいテスト用のコピーを作る
Crypto Assessment / Data Safe AI Agents Crypto Assessment は、暗号の使われ方を棚卸しし、直すべき箇所を示す。Data Safe AI Agents の中身は本記事では扱わない
Recovery Service の cross-region backup replication リージョンをまたいでバックアップを複製し、統合ダッシュボードで保護の状態を見る

AI をデータの近くで動かす

Agent Memory

エージェントが仕事をするには記憶が必要で、その記憶はベクトルだけでなく多くの種類のデータにまたがる、というのが登壇者の説明だ。Agent Memory はベクトルストアにとどまらない記憶として紹介され（”Agent memory is more than a vector store”）、記憶を業務データと一緒に管理し、別のデータの置き場を作らないことを狙っている。

記憶を別のベクトル DB などに置くと、業務データとの整合や、権限・バックアップの管理が二重になる。同じ DB に置けば既存の運用に乗せられる点が、実案件では大きい。 Agent Memory については、別のセッションをもとに書く記事で詳しく紹介する予定だ。ほかの機能についても、今後の記事で順次紹介していく。

APEXlang

AI を使えば、アプリは数分で作れる。ただ、AI が書いた数千行のコードで業務を動かすなら、変更のたびにレビューし、セキュリティやスケール、信頼性をテストし直す必要がある。登壇者はこれを課題に挙げ、AI でアプリを速く作ることではなく、統制して運用できる業務アプリを作ることが本当の課題だと述べた。

そこで Oracle APEX を拡張するのが APEXlang だ。登壇者は SQL にたとえた。SQL では欲しいデータを書けば、取り出し方は DB が考える。APEXlang では、AI がアプリのすべきことを、読める形の宣言的な定義として生成する。チームはそれをいつもの手順でレビューして版を管理し、APEX Engine がセキュリティ・スケール・可用性・運用を備えた形で実行する。AI が意図を生成し、APEX が信頼できる実行を担う（”AI generates intent, APEX provides trusted execution”）という役割分担だ。

公式ブログによれば、APEXlang は APEX 26.1 で登場した、人が読めるアプリ定義の言語だ。2026年10月6日に発表された APEX 26.2 では、ページや共有コンポーネント単位で .apx ファイルをインポートできるようになり、Oracle Deep Data Security との連携も加わった。26.2 はオンプレミス向けに一般提供が始まり、OCI やマルチクラウドへの展開は数週間以内の予定とされている。

私も過去の OCI のデモ作成で、AI を使って APEX アプリケーションを開発したことがあるが、なかなかうまくいかなかった。APEXlang を自分の環境で実際に使ってみたところ、簡単に意図どおりのアプリが作れて、拍子抜けするほどだった。

データ基盤を増やさない

MAA の Diamond tier

Oracle AI Database は、複数のワークロードとデータ型を1つのエンジンで扱う converged architecture を取っている。その土台を強めるのが、Maximum Availability Architecture（MAA）の Diamond tier だ。Oracle Globally Distributed AI Database を使い、3秒未満・データ損失ゼロのフェイルオーバーを実現するとしている。1つの論理データベースを、複数のパブリッククラウドとオンプレミスにまたがって動かせるとも説明された。

金融・保険のような止められない業務で、マルチクラウドとオンプレミスをまたぐ構成と、データ主権の要件を同時に満たす提案の材料になる。 Oracle Globally Distributed AI Database については、別のセッションをもとに書いた記事「【Oracle AI World 2026】Globally Distributed AI Database で実現する、複数クラウドにまたがって止まらないデータベース」で紹介している。

GoldenGate Data Fabric

ひとつの DB にまとめられないデータは、GoldenGate Data Fabric で変更をリアルタイムにつなぐ。クラウド間の経路は Oracle Multicloud Interconnects が担う（”Enabled by Oracle Multicloud Interconnects”）。詳細は、前日のセッション（LRN6075）をもとに書いた記事「【Oracle AI World 2026】レプリケーションの一歩先へ。Oracle GoldenGate Data Fabric 登場！」で紹介している。

動かす場所と AI を選べる

Base Database Cloud@Customer

動かす場所の選択肢として、Base Database Cloud@Customer が加わった。Base Database Service を自社のデータセンターに持ち込む、より簡単で低コストな方法だと登壇者は説明した。

オンプレミス → Cloud@Customer → OCI と段階的に移る道で、入口の選択肢が増える。移行計画を立てる側としてはありがたい。

Migration Accelerator とマルチクラウドの拡大

クラウドへの移行では、Oracle とパートナーが移行全体を支援する Oracle Migration Accelerator が紹介された。あわせて、パートナーの成長を加速させる10億ドルの新たな投資も示された。

マルチクラウドの面では、直近12か月でクラウドリージョンが35から71に増え、そのうち22は新しい AWS のリージョンだという。AWS、Google Cloud、Azure で使える Oracle AI Database のサービスも9つ増えた。使えるサービスはクラウドごとに異なる。

マルチクラウドで使えるリージョンが1年で倍以上になり、サービスも9つ増えた。「OCI 以外のクラウドで Oracle Database を使いたい」という要件に応えやすくなった。

Database Tools MCP Server

AI の選択肢について、登壇者は MCP などの標準に対応していることを強調し、最近リリースされた Database Tools MCP Server を紹介した。MCP クライアントから Oracle AI Database に、エンタープライズ水準のアクセス制御付きでつなぐマネージドサービスだ。

生成 AI のクライアントから DB に触れる経路が増えるので、「誰の代わりにアクセスしているか」を DB 側で縛る設計（後述の Deep Data Security など）とセットで考える必要がある。

Autonomous AI Lakehouse

Autonomous AI Lakehouse は、Apache Iceberg などのオープンな形式の上で、Oracle 以外のデータにも Oracle の分析と AI を使えるようにする。特徴として、No-ETL、AI 支援の Data Studio、エージェント向けの業務コンテキスト、ガバナンス付きのアクセス、”Live AI Hub: real-time operational data” が挙げられた。登壇者は例として、Databricks 上の Iceberg にある配送の分析データを、Oracle にコピーせずにエージェントが使える場面を挙げた。

分析基盤の選定で、「どこにデータを集めるか」から議論しなくて済む。置き場所の議論より、ガバナンスとアクセス経路の設計に時間を使えるようになる。

データを守る

Oracle Deep Data Security

エージェント、AI が生成したアプリ、自然言語のアクセス、MCP など、データに至る経路は AI で増えている。そこで、エンドユーザーごとのプライバシールールを DB で定義し、どの経路からアクセスしても DB が強制するのが Oracle Deep Data Security だ。ユーザーの ID とロールはリクエストとともに渡り、DB は AI が誰の代わりに動いているかを暗号学的に検証する。権限が変われば、強制される内容も自動で変わる。

エージェントや AI が生成したアプリが増えるほど、経路ごとにアプリで権限を実装する方式は破綻する。DB で一元的に強制するのは理にかなっている。 ただし、従来のセキュリティを置き換えるものではなく、さらにセキュリティを強化するためのものとして扱うのがよいと思う。

Fleet Automation と Data Subsetting

自分で DB を管理する場合は、最新のリリース・アップデートを遅れずに適用することが最も重要だと登壇者は述べた。そのために Fleet Automation を広げ、ソフトウェアのコンプライアンスをフリート全体で見えるようにする。Data Safe の Data Subsetting は、本番を丸ごと複製せずに、小さく現実的なテスト用のコピーを作る。

パッチ適用の遅れは、人手と検証時間の問題になりやすい。フリート単位の自動化と、本番より小さいテスト用のコピーを組み合わせれば、検証の待ち時間を短くできる。

Data Safe の Crypto Assessment と AI Agents

Data Safe には、Data Safe AI Agents と cryptographic posture assessment が加わる。暗号の評価では、暗号の使われ方を一覧にし、弱い・非推奨のプロトコル、短い鍵、期限切れが近い証明書、耐量子暗号への対応の不足など、先に直すべきものを示すと説明された。

耐量子暗号への移行に備える第一歩として、暗号の使われ方の棚卸しから始められる。

パッチ適用・テスト・ライフサイクル管理の自動化（”Automated patching, testing, and lifecycle management”）と、リスクの一元的な監視と軽減（”Centralized risk monitoring and mitigation”）のツールは、2027年2月28日まで無償または割引で提供されると示された。登壇者も、セキュリティとパッチ適用のツールを期間限定で無償にすると述べた。詳細は公式の情報を確認いただきたい。

Recovery Service の cross-region backup replication

Zero Data Loss Recovery の取り組みでは、Recovery Service に、リージョンをまたいだバックアップの複製と、データ保護の状態をまとめて見るダッシュボードが加わる。

リージョンをまたいだバックアップをマネージドで持てるのは、ランサムウェア対策と DR 設計の選択肢として分かりやすい。

押さえておきたい前提

本記事で紹介した機能は、セッションで話された内容をもとに書いている。GA か Preview か、提供の時期、東京・大阪リージョンで使えるかは、セッションでは確認できていない。詳細は公式の情報を確認いただきたい。

考察

新機能の多くは単体ではなく、セキュリティや可用性とセットで語られた。AI を入れるほど、DB が担う役割は増えていく。 AI 時代のデータベースに求められるセキュリティやアーキテクチャを牽引していくような新機能が多いと感じた。例えば APEXlang や Oracle Deep Data Security、Data Safe の進化などだ。 セッションの最後には、Oracle Database のライセンスを持っていれば、DB に組み込まれた AI の機能を追加費用なしで使えるという発言もあった。デモ開発などをしながら、積極的に触れて確かめていきたいと思う。

参考