クラウドインテグレーション事業部の片山です。
2026年10月26日〜28日（現地時間）にラスベガスで開催されたイベント、Oracle AI World 2026に今年も現地参加してきました！

今回は、「Build Portable Multicloud Applications with Oracle AI Database」というセッションのレポートをお届けします。

セッション表紙スライド「Build Portable Multicloud Applications with Oracle AI Database」

セッション概要

本セッションは、Oracle AI Databaseを使うアプリを、OCI・Microsoft Azure・AWS・Google Cloudのどこでも作り直さずに動かすための仕組みを、Oracleのドライバー担当者が紹介する開発者向けのセッションです。カタログ記載の登壇者はAlex Keh氏で、当日はスライド表紙のとおり、Paul Parkinson氏、Srinath Krishnaswamy氏を加えた3名での登壇でした。

内容は、(1)接続情報やドライバー設定を各クラウドのサービスに置くCentralized Configuration Providers、(2)トークン認証とDeep Data Security、(3)エージェント連携のデモの3つです。

セッション内容：DBだけでなく「クライアント」もマルチクラウドに

1. マルチクラウドは「ずっと続く」前提で考える

Keh氏は冒頭で「クラウドが始まったころは、すべてのアプリを1つのクラウドに集約するのが夢だった。しかしその夢はこれからも実現しないだろう」と切り出しました。ハイパースケーラーごとに得意なサービスが違い、国ごとにデータの保管や処理の規制もあるため、マルチクラウドの世界はずっと続く、という前提です。

課題として挙げられたのは、クラウドごとに違う認証の仕組み、バラバラな構成管理と監視ツール、それによる運用負荷です。Oracleの答えが「One Approach, Every Cloud」で、Java・Python・Node.js・.NET・Rust・Go・Cの各ドライバーに同じ考え方の構成プロバイダーを用意しています。

「The Solution: Centralized Configuration Providers」。単一の構成モデル、一貫した認証、統一された監視を各言語のドライバーで提供

2. ドライバーが各クラウドのネイティブサービスに直接つながる

構成図では、Oracle AI Database 26aiのドライバーが4種類のプロバイダーを通じて、各クラウドのサービスに直接つながる様子が示されました。

  • Config：接続文字列やドライバー設定を、Azure App Configuration、OCI Object Storage、AWS AppConfig、Amazon S3、Cloud Storageなどから読み込む
  • Resource：パスワードやDBトークンを、OCI Vault、Azure Key Vault、AWS Secrets Manager、Secret Managerなどから取得する
  • Tracer：DBとの往復などのイベントを、OpenTelemetry、OCI APM、Application Insightsなどへ送る
  • Cache：構成の変更通知を、OCI Notifications、Azure Event Grid、Amazon SQS、Pub/Subなどで受け取る

OCIとMicrosoft Azure向けのプロバイダー構成図（左がOracle AI Database 26aiの各ドライバー、右が接続先のサービス）

AWSとGoogle Cloud向けのプロバイダー構成図。考え方はOCI・Azure版と同じ

Keh氏によると、OCIとAzureの対応を先に作り、そのあとAWSとGoogle Cloudに広げたとのことです。公開情報では、2026年6月にJDBC向けの拡張ライブラリ（Oracle JDBC Extensions v1.1.0）でAWS AppConfigとParameter Storeに対応し、9月のpython-oracledb 26.0.0でAWSとGoogle Cloudに対応しました。10月の26.1.0では、AWSとGoogle Cloudの通知を受けて構成キャッシュを自動で更新できるようになっており、図の「Cache」はこの機能にあたります。

3. 構成をクラウドに置く3つの利点と、リソースプロバイダーとの使い分け

構成プロバイダーの解説では、接続記述子、認証情報、コネクションプールの上限や文キャッシュのサイズといったドライバー設定を、クラウドのストアにJSONで置けることが紹介されました。利点は次の3つです。

  1. セキュリティ：推奨はトークン認証だが、移行の途中でパスワードが残る場合も、コードに書かずVaultに置ける。アプリを変えずにセキュリティチームが管理できる
  2. 俊敏性：「DB接続が多すぎる」と分かったときも、全アプリを直して回らず、クラウド上の構成を1か所変えれば次の接続から反映される
  3. 柔軟性：OCIからAzureへ移すときも、構成URLを差し替えるだけで済む

Pythonでは、クラウドごとのプラグインを読み込み、config-awss3://やconfig-azure://で始まるURLを接続メソッドに渡すだけです。取得した構成はドライバーがキャッシュし、有効期限（TTL）が切れると取り直します。

続いてKeh氏が、構成プロバイダーとリソースプロバイダーの違いを説明しました。前者はアプリと同じ環境（同じインフラや同じクラウド）の設定を扱い、後者は別のクラウドを含むリモートにあるリソースを扱います。使い分けの判断軸は次の2点です。

  1. 情報がアプリと同じクラウドにあるか：同じなら構成プロバイダー、別のクラウドから取ってくるならリソースプロバイダー
  2. 何を一元管理したいか：接続先やプール設定をまとめて変えたいなら構成、パスワードやウォレットなどの秘密情報を寄せたいならリソース

リソースプロバイダーの例。JavaもC#（.NET）も、接続文字列にconfig-azure形式でAzureの構成名とキーを指定する

デモでは、ノートPCで動かすC#アプリが、Azureから接続文字列とウォレットを取得し、トレースとメトリクスをApplication Insightsに送り、DB本体はOCIで動いているという構成が示されました。1つのアプリが3か所にまたがる例で、Application Insightsには.NETドライバーから送られた接続数の推移がグラフで表示されていました。

4. パスワードレス認証とDeep Data Security

Parkinson氏は、トークン認証の利点を「コードに認証情報を書かない、シークレットを手動でローテーションしない、クラウドのIDがそのままDBにつながる」とまとめました。DB側は外部認証を有効にし、クラウドのIDで識別されるユーザーを作るだけです。

パスワードレス認証の流れ。JavaアプリがMicrosoft Entra IDでOAuth 2.0のトークンを取得し、JDBCドライバーがそのトークンでDBに認証する

続くDeep Data Securityは「この1年でOracle Databaseに入った最大級の機能の一つ」と紹介されていました。ブラウザで認証したユーザーのIDを、On-Behalf-Ofの流れでDB用のトークンに変えてDBまで渡し、データロールとデータグラントで行・列単位のアクセスをDB側で強制します。「社員は自分の情報だけ、マネージャーは部下の情報まで」といった制御を、アプリではなくDBが担う形です。

Deep Data Securityの設定例。DB側でEntra IDのロールをデータロールに対応付け、Java側はSpring Bootの設定だけでもエンドユーザーのコンテキストを付けられる

Deep Data Securityは2026年3月23日にOracle AI Database 26aiの機能として発表され、6月からAutonomous AI Databaseでも使えるようになっています。データベース側で重ねるセキュリティ制御の全体像は、弊社今井のレポートにて紹介しています。

5. マルチクラウドのエージェント連携

後半でParkinson氏は、MCP Toolkitを土台に、A2A（エージェント間連携）とA2UI・MCP Appsを組み合わせた「AIフルスタックツールキット」を紹介しました。どのクラウドにも持ち運べる構成で、「使うかどうかは任意のオープンソースのライブラリー」と説明されていました。

AI Full Stack Toolkitの層構造。既存のMCP Toolkitのツールを、MCPやA2Aのエージェントとして公開する

Google Cloudのデモ構成。Gemini EnterpriseからA2AとMCPを通じてOracle AI Database Agentとデータ層につながる

デモでは、Gemini EnterpriseにOracle AI Database Agentを追加する画面や、Microsoft FoundryにA2Aのエンドポイントを登録して問い合わせる画面が紹介されました。Autonomous AI DatabaseのA2Aサーバーは7月7日に発表されたもので、各クラウドとの連携は弊社新川のレポートよりご確認ください。

おわりに

以上、「Build Portable Multicloud Applications with Oracle AI Database」に現地参加してのセッションレポートをお届けしました。

まとめのスライド。DBとクライアントの両方がマルチクラウドに対応し、主要ハイパースケーラーのどこでも動かせる

マルチクラウドの話題では、Oracle AI Database@AWSのように「DBをどのクラウドに置けるか」が注目されがちです。本セッションは、その裏側にあるアプリの接続設定と認証を、各クラウドのネイティブサービスに寄せて揃える話でした。DBの置き場所とアプリの構成管理を分けて考えられるようになった、と感じました。

弊社としては、AWSやGoogle Cloudでシステムを運用しながらOracle Databaseも使っているお客様に、特に有効な仕組みだと考えています。接続情報を普段使っているサービスで管理でき、トークン認証へ移行するまでの間もパスワードをコードから外せます。DBの配置に関するマルチクラウドの全体像とあわせて、移行計画の早い段階からアプリ側の構成管理を設計に入れるよう提案していきたいです。

引き続き、現地で聴いたセッションの深掘りレポートをお届けします。

最後までお読みいただきありがとうございました！