本記事の結論 Phase 2のPFSをAzure : PFS2048 / Oracle Alloy : GROUP14（ともにDH Group 14）で 明示的に一致させることで、2020年当時に報告されていた「約1時間後の通信断」は発生せず、 Phase 2 Rekeyの正常完了と、Rekey前後で通信可能な状態が維持されることまで確認できました。 1. はじめに AzureとOracle Cloud Infrastructure（OCI）をSite-to-Site VPNで接続する機会があり、構成を検討する中で、2020年に公開された「AzureとOCIでサイト間(S2S)V

本記事は 2026 年 9 月 8 日 に公開された「 Getting started with Oracle Database@AWS: A complete onboarding guide 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、Oracle Exadata Database Service と Oracle Autonomous Database を AWS データセンター内でネイティブに提供します。Oracle ワークロードは専用設計の Exadata インフラストラクチャ上で動作し、 Amazon Bedrock 、 Amazon Redshift 、 AWS Key Management Service (AWS KMS) 、 Amazon CloudWatch 、 AWS CloudTrail といった AWS サービスに低レイテンシーでアクセスできます。同時に、Oracle データベースエンジン、Exadata のパフォーマンス特性、そしてチームが現在使っている DBA ツールもそのまま維持できます。 本記事では、Oracle Database@AWS のオンボーディングを、サービスの選定からプロビジョニング可能な環境が整うまで通して解説します。必要なサービスに応じて、簡略化されたパブリックオファーの経路と、5 ステップからなるプライベートオファーの経路のどちらかをたどります。どちらの経路も解説します。 Autonomous Database Serverless (ADB-S) と Exascale Infrastructure (ExaDB-XS) 上の Exadata Database Service については、 AWS Marketplace でパブリックオファーが提供されており、事前の調達手続きは要りません。サブスクライブすれば数分でプロビジョニングを始められます。ステップ 1 のサービス選定表で、適切な出発点がわかります。 オンボーディングの全体像 サービスの選定からプロビジョニング可能な環境が整うまでの流れは、2 つのフェーズに分かれます。 調達 (ステップ 1〜2): サービスを選び、オファー (パブリックまたはプライベート) を確保し、AWS Marketplace で承諾します。 オンボーディング (ステップ 3〜5): アカウントの前提条件を確認し、OCI テナンシをリンクし、両クラウドで ID とアクセス許可を設定します。 ここまで終われば、プロビジョニングの準備が整います。ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターの作成は「次のステップ」で扱います。 2 つのフェーズに対応する 5 つのステップは次のとおりです。 サービスを選定し、オファーを確保する。 オファーを承諾する。 前提条件を確認する。 OCI テナンシをリンクする。 AWS Identity and Access Management (IAM) のグループとロールを設定する。 次の図は、5 つのステップを 2 つのフェーズにグループ分けしたものです。 図 1: 調達フェーズとオンボーディングフェーズに分けた 5 つのオンボーディングステップ ステップ 1: サービスを選定し、オファーを確保する まず、ワークロードに適した Oracle Database@AWS のサービスを見極めます。選んだサービスによって、使える機能とたどる調達経路の両方が決まります。 サービスと調達経路を選ぶ サービス オファーの種類 選ぶ場面 Exadata Database Service on Dedicated Infrastructure (ExaDB-D) プライベートオファー (ステップ 1〜5) 次のいずれかが必要な場合。完全なシングルテナント分離を備えた専用 Exadata ラック、ノード数・ECPU・メモリを完全に制御できる Oracle RAC、大規模な統合環境向けの極めて高いスケーラビリティ、Oracle COTS アプリケーション (PeopleSoft、E-Business Suite、JD Edwards、Siebel、CC&B) 向けの認定 MAA アーキテクチャ。 Exadata Database Service on Exascale Infrastructure (ExaDB-XS) パブリックオファー (ステップ 3 へ) またはプライベートオファー 専用インフラストラクチャなしで Exadata の性能をフルに使いたい場合。規模の異なる本番データベース、サービス間 Data Guard による DR スタンバイ、開発・テスト環境、小さく始めて成長するワークロードに向いています。インフラストラクチャの最小コミットメントはありません。 Autonomous Database Serverless (ADB-S) パブリックオファー (ステップ 3 へ) またはプライベートオファー インフラストラクチャに関する判断が一切不要なフルマネージドの Oracle データベースを使いたい場合。パッチ適用、チューニング、スケーリング、可用性は Oracle が担います。OLTP、分析、混在ワークロード、アイドル時の自動一時停止に向いています。 Autonomous Database on Dedicated Exadata Infrastructure (ADB-D) プライベートオファー (ステップ 1〜5) 完全な専用インフラストラクチャ上で自律運用が必要な場合。パッチ適用とチューニングは Oracle が担いつつ、メンテナンスウィンドウとシングルテナント分離の制御は自社で保持します。 ワークロードが ExaDB-XS または ADB-S に合っていて、パブリックオファーで要件を満たせるなら、インフラストラクチャのサイジングや Oracle との事前調整は要りません。 Oracle Database@AWS の AWS Marketplace ページからサブスクライブし、ステップ 3 に進んでください。パブリックオファーで提供されるサービスの最新のリージョン対応状況は、 Regional Availability for Oracle AI Database@AWS を参照してください。 ExaDB-D または ADB-D をデプロイする場合、あるいは交渉価格やコミット条件が必要な場合は、以降のセクションのプライベートオファーのプロセスに進みます。 プライベートオファーをリクエストする プライベートオファーは、ワークロード要件に合わせて自社と Oracle の間で結ぶ交渉ベースの契約です。手順は次のとおりです。 AWS Management Console の Oracle Database@AWS 製品ページで Request private offer を選びます。OCI にリダイレクトされ、AWS リージョン、ワークロード要件、連絡先情報を入力します。 あるいは、Oracle のアカウントチームか AWS チャネルパートナーに直接依頼してリクエストを開始することもできます。 最初に AWS アカウント ID を伝えます。Oracle が正しいアカウント向けにオファーを生成するために必要です。 ヒント: AWR Miner や Oracle 提供のサイジングユーティリティ (Cloud Premigration Advisor Tool ( CPAT )、 ORAchk ) を、移行元データベースに対して早い段階で実行しておきましょう。出力はそのままサイジング作業に使えるため、最初から精度の高いオファーを組み立てられます。 購入者アカウントを選ぶ ODB@AWS を調達すると、エンタイトルメントは購入者アカウント (buyer account) と呼ばれる単一の AWS アカウントに紐付きます。マルチアカウント環境では、組織の管理アカウントである必要はありません。AWS のベストプラクティスとしては、商用契約を保持する専用の購入者アカウントを推奨します。購入者アカウントは AWS Resource Access Manager (AWS RAM) を使い、同一 AWS Organization 内のワークロードアカウントとエンタイトルメントを共有します。調達のガバナンスとインフラストラクチャのデプロイを分離でき、監査証跡も明確に保てます。単一ワークロードのデプロイなら、購入者アカウントとワークロードアカウントを同じにしても構いません。 概念 説明 ODB@AWS での役割 購入者アカウント プライベートオファーを承諾し、AWS Marketplace のサブスクリプションを保持する AWS アカウント ODB@AWS のエンタイトルメントを受け取り、OCI SKU の請求先となり、OCI テナンシとリンクされます。プロビジョニングはすべてこのアカウントから行うか、このアカウントから共有されます。 管理アカウント 一括請求と SCP を管理する AWS Organization のルートアカウント 購入者アカウントである場合もそうでない場合もあります。組織が専用の調達アカウントを使っているなら、管理アカウントではなくそのアカウントが購入者になります。 重要: 購入者アカウントは、オンボーディング後に OCI テナンシと恒久的にリンクされます。後から変更するには再オンボーディングが必要です。 オファーをリクエストする前に、概念実証 (PoC) の段階であってもアカウントの選定を済ませておきましょう。本番で使う予定の購入者アカウントで PoC を始めれば、プライベートオファーをその場で追加するだけで本番へ移行できます。OCI テナンシのリンク、ネットワーク構成、既存のインフラストラクチャはそのまま引き継がれます。オンボーディング後に購入者アカウントを変更すると、再オンボーディングを一からやり直すことになり、OCI テナンシの再マッピング、ネットワークの再構築、場合によってはデータ移行まで必要になります。 マルチアカウント構成の組織では、 AWS License Manager を使い、購入者アカウントから同一 AWS Organization 内のワークロードアカウントへ ODB@AWS のサブスクリプションを共有できます。アカウント間のリソース共有には AWS Resource Access Manager (AWS RAM) を使います。オファーをリクエストする前に、購入者アカウントの方針を決めておきましょう。 シンプル構成: 購入者アカウントとワークロードアカウントが同一。単一ワークロードや PoC のデプロイに向いています。 エンタープライズ構成: 専用の購入者アカウントまたは調達アカウントを用意し、License Manager でエンタイトルメントを共有します。複数のワークロードアカウントを持つランディングゾーンのパターンに向いています。 詳細な手順は Request Offer for Oracle AI Database@AWS を参照してください。マルチアカウントでの共有については Subscription Sharing for Oracle AI Database@AWS を参照してください。 ターゲットアーキテクチャとサイジングを決める (ExaDB-D と ADB-D) 専用インフラストラクチャのサービスでは、サイジングによって SKU の数量が決まり、それがそのままオファーに反映されます。サイジングは Oracle、AWS、そしてチャネルパートナーが関わる場合はパートナーも含めた共同作業です。移行元データベースの AWR Miner の出力を Oracle に提供します。そのデータをもとに、ワークロードの特性を Exadata の構成 (シェイプ、ECPU の割り当て、ストレージ容量、環境数) に落とし込む作業を Oracle が支援します。 データベース層では、次の点を計画します。 Exadata インフラストラクチャの配置 (アベイラビリティーゾーンの選定)。 VM クラスターの構成。一般には本番クラスター、マルチ AZ Data Guard 用の DR クラスター、1 つ以上の非本番クラスターです。 Oracle のマルチテナントアーキテクチャを使った CDB/PDB の統合方針。 Autonomous Recovery Service (ARS) 、Amazon Simple Storage Service (Amazon S3)、またはその両方を使ったバックアップ方針。 Navigating backup and recovery options for Oracle Database@AWS を参照してください。 クライアントサブネットとバックアップサブネットの CIDR を含む ODB ネットワークの設計。 アプリケーション層では、次の点を計画します。 app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、ODB@AWS のプレイスメントグループ内に EC2 インスタンスを配置する。 高性能ネットワーキングのプレイスメントグループ を参照してください。 Virtual Private Cloud (VPC) の設計、サブネット、セキュリティグループ、ODB ピアリングの接続構成。 ロードバランシング (Application Load Balancer または Network Load Balancer) と Auto Scaling グループ。 コンテナ化したアプリケーションコンポーネント向けの Amazon Elastic Kubernetes Service (Amazon EKS) または Amazon Elastic Container Service (Amazon ECS)。 Amazon Elastic File System (Amazon EFS) による共有ストレージ、Amazon CloudWatch によるモニタリング、Terraform または AWS CloudFormation による Infrastructure as Code。 オファーの種類を選ぶ Oracle のプライベートオファーには、調達チャネルに応じて 2 種類あります。 オファーの種類 仕組み 選ぶ場面 Marketplace Private Offer (MPPO) Oracle が購入者アカウント向けに AWS Marketplace 上で直接オファーを生成します。 すでに Oracle と直接取引があり、条件を Oracle と直接交渉したい場合。 Channel Partner Private Offer (CPPO) チャネルパートナーが、Oracle 提供のオファーを AWS Marketplace から自社アカウントに提示します。 チャネルパートナー経由で調達する場合、またはそのパートナー経由で請求をまとめたい場合。 すでに Oracle と直接取引があるなら MPPO を選びます。 チャネルパートナー経由で調達する場合、またはそのパートナー経由で請求をまとめたい場合は CPPO が適しています。 請求モデルを最初に確認しておきます。自社の AWS アカウントへの直接請求 (MPPO) か、パートナー経由 (CPPO) かです。 オファーの前提情報を揃える: アカウント ID、SKU、契約条件 Oracle またはチャネルパートナーがオファーを生成する前に、次の情報を揃えます。 AWS 購入者アカウント ID: オファーを承諾する 12 桁の AWS アカウント ID。 検討対象の SKU: Exadata Cloud Infrastructure X11M および X11MV (データベースサーバーとストレージサーバーを含む固定インフラストラクチャコスト)。 Exadata Database ECPU、License Included または BYOL (変動するコンピュートコスト)。 Autonomous Database を使う場合は Autonomous AI Database ECPU (LI または BYOL)。 パブリックオファーのサービスを使う場合は ExaDB-XS または ADB-S (従量課金、最小コミットメントなし)。 バックアップ要件に応じて Autonomous Recovery Service または Zero Data Loss Recovery。 OCI 側のストレージを追加で必要とする場合は OCI Object Storage。 契約期間: 通常は 1 年、3 年、またはカスタム期間。 SKU ごとのライセンスモデル: License Included (LI) または Bring Your Own License (BYOL)。 各環境 (本番、DR、非本番) を、具体的な SKU の数量と使用時間に対応付けます。ECPU コストを最適化するため、非本番環境の稼働時間を決めておきます。非本番環境では月 264 時間が一般的な目安です。 Oracle がオファーを生成する 前提情報がすべて確定した後、最終的な入力からオファーが利用可能になるまでの目安は 2〜5 営業日です。流れは次のとおりです。 Oracle の営業担当が、指定された購入者アカウントを対象に AWS Marketplace 上でプライベートオファーを作成します。 オファーには、合意した SKU、数量、価格、契約期間が含まれます。 CPPO の場合、Oracle はチャネルパートナーから提供された情報をもとにオファーを生成します。 オファーは AWS Management Console の Oracle Database@AWS に表示されます。 View private offer を選んで内容を確認し、承諾します。 詳細な手順は Purchase Oracle AI Database@AWS を参照してください。 ステップ 2: オファーを承諾する Oracle からプライベートオファーが提示されたら、AWS Management Console で承諾し、Oracle Database@AWS のサブスクリプションを有効化します。 オファーを承諾する手順は次のとおりです。 AWS Management Console で Oracle Database@AWS に移動し、 View private offer を選びます。 オファーの条件、価格、EULA を確認します。 Create contract を選び、画面の指示に従って承諾します。 承諾後、コンソールに表示されるアクティベーションリンク、またはメールで届いたリンクから OCI アカウントを有効化します。 Oracle Cloud アカウントを新規作成するか、既存のアカウントをリンクするかを選びます。 アクティベーションを完了します。完了が確認されるとダッシュボードが使えるようになります。 マルチアカウント構成の組織では、次の対応が可能です。 AWS License Manager を使い、AWS Organization 内のアカウント間で ODB@AWS のサブスクリプションを共有する。 調達を単一の支払いアカウントに集約しつつ、プロビジョニングはワークロードアカウントで行う。 注: Oracle Database@AWS のダッシュボードは、プライベートオファーを承諾する (またはパブリックオファーでサブスクライブする) までは使えません。オンボーディングが完了するまで、プロビジョニングの API 呼び出しは失敗します。 オンボーディングが完了すると、AWS アカウントが OCI テナンシとリンクされ、サポート対象のリージョンに複製されます。OCI コンソールから使いたいリージョンを有効化すれば、サブスクリプションの手続きを繰り返さずに、サポート対象の AWS リージョンで Oracle Database@AWS を使えます。 ステップ 3: 前提条件を確認する OCI テナンシのリンクと AWS Identity and Access Management (IAM) の設定に進む前に、AWS アカウント環境の準備が整っているか確認します。次のチェックリストが主な確認項目です。 カテゴリ 確認する内容 重要な理由 Service Quotas 対象リージョンの VPC、サブネット、ENI の上限。 ODB ネットワークとピアリング接続に十分な余裕があるか確認します。 ネットワーク計画 クライアントサブネットとバックアップサブネットの CIDR 範囲。 既存の VPC CIDR と重複してはいけません。どちらも /24 以上が必要です。 IAM 必要な権限を持つ管理者ユーザーまたはロール。 詳細なポリシー設定はステップ 5 を参照してください。 DNS Amazon Route 53 のアウトバウンドリゾルバーエンドポイントと転送ルール。 アプリケーション VPC から ODB ネットワーク内の Oracle データベースのホスト名 (SCAN リスナー) を解決するために必要です。 ネットワーク計画の詳細 クライアントサブネットの CIDR: ODB ピアリング経由でアプリケーションがデータベースに接続するために使います。 バックアップサブネットの CIDR: OCI Autonomous Recovery Service または Amazon S3 へのバックアップトラフィックに使います。 どちらの CIDR も /24 以上が必要で、既存の VPC のアドレス空間と競合してはいけません。 アプリケーション VPC と ODB ネットワークの間の ODB ピアリング接続も計画しておきます。 Service Control Policy (SCP) に関する考慮点 リージョンを制限する SCP を適用している組織では、ODB@AWS のオンボーディング時に特有の注意点があります。主なデプロイ先がどこであっても、次の 2 つのリージョンを許可する必要があります。 米国東部 (バージニア北部) us-east-1: AWS License Manager のエンタイトルメント付与、AWS Marketplace のサブスクリプション承諾、グローバルサービス (IAM、AWS Organizations、STS) に必要です。SCP でこのリージョンを制限したままワークロードを別リージョンにデプロイすると、エンタイトルメントの共有が失敗します。 対象の ODB@AWS リージョン: Exadata インフラストラクチャ、ODB ネットワーク、VM クラスターをプロビジョニングするリージョンです。 重要: 組織レベルの AWS Service Control Policy (SCP) や権限境界はユーザーの権限を上書きし、オンボーディングの失敗につながることがあります。作業を進める前に AWS Organization の管理者に確認してください。 ステップ 4: OCI テナンシをリンクする Oracle Database@AWS はコントロールプレーンが分かれています。ネットワークや Exadata などのインフラストラクチャリソースは AWS 側で管理し、DB Home、PDB、パッチ適用といったデータベース管理は OCI 側が担います。そのため、インフラストラクチャには慣れた AWS のツールを使いながら、データベースのライフサイクル層は Oracle が管理します。OCI テナンシのリンクは、2 つのコントロールプレーンをつなぐクラウド間の接続を確立する作業です。 選択肢 使う場面 手順 OCI テナンシを新規作成する Oracle Cloud の利用実績がない場合 アクティベーション時に自動的に作成されます。オンボーディングを実施したユーザーがテナンシ管理者になります。 既存の OCI テナンシをリンクする Oracle のサポート契約を含む OCI アカウントをすでに持っている場合 アクティベーション時に接続します。対象の AWS リージョンとペアになる OCI リージョンにテナンシがサブスクライブされている必要があります。 OCI テナンシは、対象の AWS リージョンとペアになる OCI リージョンにサブスクライブされている必要があります。たとえば米国東部 (バージニア北部) は OCI の US East (Ashburn) と、アジアパシフィック (シドニー) は OCI の Australia East (Sydney) とペアになります。現在のペアリングの一覧は Supported Regions for Oracle Database@AWS を参照してください。 リンクしたテナンシでは、日々のデータベース運用を次のように行います。 データベースのコントロールプレーン: OCI コンソールまたは API から DB Home、CDB、PDB を作成・管理します。 Data Guard: 高可用性と DR のためにスタンバイデータベースを構成します。 バックアップ管理: OCI Object Storage または Amazon S3 への自動バックアップ。 パッチ適用: データベース、Grid Infrastructure、OS のパッチを自社のスケジュールで適用します。 モニタリング: OCI 側のパフォーマンスメトリクスと診断情報。 注: オンボーディング時にテナンシを新規作成した場合、オンボーディングを実施したユーザーが自動的に OCI テナンシの管理者になります。 ステップ 5: グループとロールを設定する ODB@AWS では、AWS 側と OCI 側の両方で IAM の権限設定が必要です。2 つのクラウドにまたがるガバナンスモデルでは、最小権限と職務の分離を保つために入念な計画が求められます。 AWS IAM の権限 ODB@AWS では、プロビジョニング権限を付与する出発点として AmazonODBFullAccess という AWS 管理ポリシーが用意されています。インフラストラクチャチームが使う IAM ロールまたは許可セットにアタッチしてください。このポリシーは、ODB ネットワークと VM クラスターの作成に必要な odb:* の主要アクションと EC2 ピアリング操作を含みます。 次の例は、ネットワーク、プレイスメントグループ、DNS に関して追加することが多い権限をまとめたものです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ODBFullAccess", "Effect": "Allow", "Action": ["odb:*"], "Resource": "*" }, { "Sid": "NetworkingForODB", "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:CreatePlacementGroup", "ec2:DescribePlacementGroups", "ec2:CreateTags", "route53resolver:CreateResolverEndpoint", "route53resolver:CreateResolverRule" ], "Resource": "*" } ] } 重要: この例の odb:* は Oracle Database@AWS のすべての API アクションへのアクセスを許可するもので、初期セットアップや PoC デプロイの出発点として想定しています。本番環境では、odb:* をワークロードに必要なアクションだけ (たとえば odb:CreateOdbNetwork、odb:CreateCloudExadataInfrastructure、odb:CreateCloudVmCluster) に置き換え、Resource 要素も特定の ARN に絞り込んでください。アクションの全一覧は Actions, resources, and condition keys for Oracle Database@AWS を、最小権限のガイダンスは AWS managed policies for Oracle Database@AWS を参照してください。 管理ポリシーには、アーキテクチャの選択に依存する権限があえて含まれていません。次の権限はカスタマー管理ポリシーで追加します。 機能 追加するアクション 必要になる条件 Amazon VPC Lattice と VPC エンドポイント vpc-lattice:*、ec2:CreateVpcEndpoint、ec2:DeleteVpcEndpoints 常に必要: ODB ネットワークの作成に必須 (S3 バックアップ連携はデフォルトでプロビジョニングされます) プレイスメントグループの管理 ec2:CreatePlacementGroup、ec2:AttachResourcesToPlacementGroup、ec2:DeletePlacementGroup 常に必要: マネージドクラスタープレイスメントグループをサポートする AZ で必須 ODB ピアリングと DNS 向けの EC2 ネットワーキング ec2:CreateRoute、ec2:DeleteRoute、route53resolver:* 常に必要: VPC ルートテーブルの更新と DNS 転送に必須 リソース共有 (クロスアカウント) ram:CreateResourceShare、ram:AssociateResourceShare インフラストラクチャや ODB ネットワークをアカウント間で共有する場合のみ カスタマー管理の暗号化 kms:CreateKey、kms:CreateGrant、kms:GenerateDataKey* Autonomous Database でカスタマー管理の KMS キーを使う場合のみ 必要なアクションをすべて含む完全なポリシー JSON は、 AWS managed policies for Oracle Database@AWS を参照してください。 DNS 計画に関する注意 : プロビジョニング後、アプリケーション VPC から ODB ネットワーク内の Oracle データベースのホスト名 (SCAN リスナー) を解決できるようにする必要があります。そのためには、Amazon Route 53 のアウトバウンドエンドポイントと、ODB ネットワークの DNS リスナーを宛先とする転送ルールが必要です。IAM 権限 (route53resolver:*) とサブネットの配置は、この段階で計画しておきましょう。設定は ODB ネットワークを作成した後に行います。詳細は Configuring DNS for Oracle Database@AWS を参照してください。 OCI IAM の権限 OCI テナンシの管理者でないユーザーは、対象コンパートメントで次のポリシーステートメントを持つグループに所属する必要があります。 # Broad admin access (simplest) Allow group <group_name> to manage database-family in compartment <compartment_name> # Narrower least-privilege policies Allow group <group_name> to use cloud-vmclusters in compartment <compartment_name> Allow group <group_name> to manage db-homes in compartment <compartment_name> Allow group <group_name> to manage databases in compartment <compartment_name> Allow group <group_name> to manage db-backups in compartment <compartment_name> 職務の分離 各ロールに必要な範囲だけにアクセスを絞れるよう、ペルソナとクラウドごとの権限を対応付けます。 ペルソナ AWS の権限 OCI の権限 クラウド管理者 odb:* (本番では特定のアクションに絞る) とネットワーキング manage all-resources in tenancy ネットワーク管理者 VPC、サブネット、ピアリング向けの ec2:* manage virtual-network-family DBA odb:Get*、odb:List* manage database-family in compartment 読み取り専用 / 監査担当 odb:Get*、odb:List* read all-resources in compartment 注: 「Missing permissions: P[DB_HOME_CREATE], P[DATABASE_CREATE]」というエラーが出る場合、マッピングされたコンパートメントの OCI IAM ポリシーに「manage db-homes」と「manage databases」が不足しています。AWS 側ではなく OCI 側の権限の問題です。 AWS と OCI 間の ID フェデレーション ODB@AWS では運用の境界が明確です。VM クラスターまでのインフラストラクチャとネットワーク層は AWS が担い、その内側のデータベースライフサイクル層は OCI が担います。ID は両方のクラウドをまたいで使えるため、個別の認証情報は不要で、OCI 側で新しいユーザー、ロール、グループを作る必要もありません。 オンボーディング時に、OCI が必要な ID 構成を自動的に作成します。具体的には、テナンシのリンク、AWS アカウントと 1 対 1 で対応するコンパートメント、そしてマルチクラウドサービスがユーザーに代わって操作することを認可する IAM ポリシーとユーザーグループのセットです。ユーザーは引き続き IAM か、IAM Identity Center 経由で社内の ID プロバイダーで認証します。OCI 側の認可はクラウド間の信頼関係が透過的に処理します。 日々のインフラストラクチャ作業では、AWS コンソールから離れる必要はありません。CDB/PDB の作成、Data Guard の構成、パッチ適用といったデータベースのライフサイクル操作では、AWS コンソールの Manage in OCI ボタンから OCI コンソールを開きます。SAML フェデレーションを構成しておけば、別途ログインせずに認証済みの状態で OCI コンソールに移動できます。 操作 実施場所 インターフェイス ODB ネットワークの作成・管理 AWS コンソール、CLI、API、CloudFormation Exadata インフラストラクチャのプロビジョニング AWS コンソール、CLI、API、CloudFormation VM クラスターの作成 AWS コンソール、CLI、API、CloudFormation TGW、DNS、VPC ピアリングの構成 AWS コンソール、CLI、API VPC Lattice 連携と Zero-ETL の有効化 AWS コンソール、CLI、API CloudWatch によるモニタリング AWS コンソール、CLI、API AWS RAM によるリソース共有 AWS コンソール、CLI、API Autonomous Database Serverless の作成 AWS コンソール、CLI、API Exadata データベース (CDB/PDB) の作成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) 専用インフラストラクチャ上の Autonomous DB の作成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) Data Guard の構成 OCI コンソール、OCI CLI、OCI API データベースのパッチ適用と更新 OCI コンソール、OCI CLI、OCI API データベースの ECPU/OCPU のスケーリング OCI コンソール、OCI CLI、OCI API PDB の管理、クローン、リストア OCI コンソール、OCI CLI、OCI API OCI ネットワークセキュリティグループの構成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) 注: AWS 側の「コンソール」は AWS Management Console を指します。OCI 側の「コンソール」は、Manage in OCI ボタンからアクセスする Oracle Cloud Console を指します。SAML フェデレーションを構成していれば、OCI に別途ログインする必要はありません。 オプション: SAML フェデレーションを設定する データベース運用のために OCI コンソールへアクセスする必要があるチームでは、SAML フェデレーションを構成すれば既存の社内 ID プロバイダーでシングルサインオンできます。SAML フェデレーションの構成はオンボーディング後のオプション作業で、AWS 側・OCI 側の操作を妨げるものではありません。OCI 専用のユーザー認証情報を作成・管理する手間もなくなります。作業内容は、ID プロバイダー (IAM Identity Center、Okta、Azure AD、または SAML 2.0 対応の IdP) を OCI Identity Domains に登録し、グループをオンボーディング時に自動作成された OCI グループにマッピングすることです。手順の詳細は Federation for Oracle AI Database@AWS and Federating with SAML 2.0 Identity Providers を参照してください。 ID 管理の姿を整理すると、OCI のユーザー作成もグループ管理もロールの割り当てもパスワードのローテーションも不要です。自動作成されるポリシーとフェデレーションがすべてを引き受けます。セキュリティチームは 1 つの ID 基盤を維持すればよく、運用チームは主に AWS コンソールで作業し、OCI 側のデータベース操作は ID 管理の負担なく SSO でアクセスできます。 次のステップ 5 つのステップが完了すれば、環境のオンボーディングは終わり、プロビジョニングを始められます。次のような作業が可能です。 プレイスメントグループの自動プロビジョニングを伴う ODB ネットワークの作成。 ExaDB-D 向けの Oracle Exadata インフラストラクチャ (Quarter、Half、Full Rack) のデプロイ。 高可用性のための RAC 構成の Exadata VM クラスターの作成。 アプリケーション VPC と ODB ネットワークの間の ODB ピアリングの確立。 app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、プレイスメントグループ内での EC2 インスタンスの起動。 プロビジョニングの手順は、AWS ドキュメントの Getting started with Oracle Database@AWS を参照してください。 まとめ 本記事では、Oracle Database@AWS のオンボーディングを一通り解説しました。パブリックオファーのサービス (ADB-S と ExaDB-XS) なら、AWS Marketplace のサブスクリプションとアカウントの前提条件を満たすだけで始められます。専用インフラストラクチャのサービス (ExaDB-D と ADB-D) では、オファーの調達、テナンシのリンク、2 つのクラウドにまたがる IAM 設定を 5 つのステップで進めます。サービスの選定、サイジング、購入者アカウントの方針、IAM を事前にしっかり計画しておくことが、プロビジョニングを滞りなく進める鍵になります。 オンボーディングが済んだら、次は ODB ネットワークの作成、Exadata インフラストラクチャのプロビジョニング、最初の VM クラスターのデプロイに進みます。次のリソースが役立ちます。 プロビジョニングのガイドと API リファレンスは Oracle Database@AWS のドキュメント 。 マルチアカウントのパターンは Best practices for cross-account sharing in Oracle Database@AWS 。 料金、リージョン、機能の概要は Oracle Database@AWS の製品ページ 。 まずは AWS Marketplace の Oracle Database@AWS にアクセスしてみてください。ADB-S と ExaDB-XS はパブリックオファーで直接サブスクライブできます。専用インフラストラクチャのサービスは、 AWS Management Console からプライベートオファーをリクエストしてください。 著者について Raghu Soma AWS のシニアパートナーソリューションアーキテクトです。お客様やパートナーと協力し、Oracle Database@AWS や Oracle Applications (COTS) を含む Oracle ワークロードを AWS 上で設計・デプロイしています。Oracle 環境全体でコストを抑え、耐障害性を高め、クラウドネイティブな機能を活用できるよう支援しています。 Simon Cunningham Simon は AWS のプリンシパルパートナーソリューションアーキテクトで、Oracle ワークロードの支援に 25 年以上携わってきました。お客様のエンタープライズ COTS アプリケーションを AWS と ODB@AWS へ移行・モダナイズし、耐障害性の向上、コスト削減、そして適切な場面でのクラウドネイティブサービスの活用を支援しています。 Manak Nanda Manak は Amazon Web Services (AWS) でパートナーソリューションアーキテクトのマネージャーを務めており、シアトルを拠点としています。彼のチームはビジネスアプリケーション領域を専門とする AWS テクノロジーパートナーを支援し、南北アメリカでの Build、Market、Co-Sell の実行を推進しています。技術リーダーシップ、クラウドアーキテクチャ、エージェント型 AI、パートナービジネスの成長が注力分野です。 この記事は Solutions Architect の 矢木 覚 がレビューしました。

本記事は 2026 年 8 月 11 日 に公開された「 Natural language queries on Oracle Database 26ai: Getting started with Select AI on Amazon RDS for Oracle with Amazon Bedrock 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle で Oracle Database 26ai が利用可能になりました。Amazon RDS における Oracle 初の AI ネイティブなデータベースリリースで、生成 AI、ベクトル検索、機械学習がエンジンに直接組み込まれています。バックアップ、パッチ適用、マルチ AZ による高可用性、リードレプリカは Amazon RDS が処理するため、インフラストラクチャの管理ではなく AI アプリケーションの構築に集中できます。 本記事では、新機能のなかでも特に効果の大きい Select AI を紹介します。Select AI では、Amazon Bedrock の基盤モデル (FM) を使い、自然言語のプロンプトでリレーショナルデータを照会できます。「今四半期の売上上位 5 社の顧客は?」とデータベースに尋ねれば、コードを 1 行も書かずに、正しい SQL とその実行結果が返ってきます。内部では、Oracle の DBMS_CLOUD_AI パッケージがテーブルのスキーマを含むプロンプトを組み立て、選択した基盤モデルに送信します。生成された SQL を実データに対して実行し、結果を返すまでのすべてが同一のデータベースセッション内で完結します。 このアーキテクチャなら、AI インフラストラクチャを自前で構築する運用負荷がなくなります。Amazon Bedrock はフルマネージドかつサーバーレスです。プロビジョニングする GPU も、ホストするモデルも、維持する推論エンドポイントもありません。Anthropic、Meta、Amazon といったプロバイダーの基盤モデルに単一の API でアクセスでき、 DBMS_CLOUD_AI プロファイルの属性を 1 つ変えるだけでモデルを切り替えられます。セキュリティは、すでに使い慣れた Amazon RDS のモデルに従います。Select AI のリクエストは Virtual Private Cloud (VPC) インターフェイスエンドポイントを経由するため、データは VPC 内に留まり、パブリックインターネットを通りません。 DBMS_CLOUD_AI はネイティブな PL/SQL なので、すでに持っている SQL のスキルで生成 AI 機能を構築できます。別途 AI スタックを学んだり維持したりする必要はありません。 本記事は、Amazon RDS 上の Oracle Database 26ai の AI 機能を扱う 3 回シリーズの第 1 回です。今回は、Amazon Bedrock の認証情報の設定から自然言語クエリの実行まで、Select AI を一通り解説します。第 2 回では Oracle AI Vector Search による Retrieval Augmented Generation (RAG) を、第 3 回では SQL プロパティグラフを使った GraphRAG を取り上げ、グラフ探索、ベクトル検索、リレーショナルなフィルタリングを 1 つの SQL クエリで組み合わせる方法を紹介します。 Amazon RDS 上の Oracle Database 26ai の AI 機能 Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock を組み合わせると、次の機能が使えます。 機能 内容 ユースケースの例 Select AI (NL2SQL) 自然言語のプロンプトを SQL に変換し、クエリを実行して、単一の SQL セッション内で結果を返す ビジネスアナリストが SQL を書かずに売上データを照会する。経営層がダッシュボードから即座に答えを得る DBMS_CLOUD_AI.GENERATE PL/SQL から基盤モデルを呼び出し、チャット、要約、翻訳、合成データ生成を行う CLOB 列に格納されたサポートチケットを要約する。開発/QA 環境向けに現実的なテストデータを生成する。製品説明を翻訳する Oracle AI Vector Search 標準的な SQL でベクトル埋め込みをリレーショナルデータと並べて保存、インデックス化、検索する 製品カタログのセマンティック検索。類似する顧客プロファイルの検索。レコメンデーションエンジンの実現 Retrieval Augmented Generation (RAG) ベクトル検索と大規模言語モデル (LLM) の生成を組み合わせ、AI の回答を実際のビジネスデータに基づかせる 社内文書やデータベースのレコードを使って質問に答える AI アシスタント データベース内 ONNX 推論 埋め込み、分類、回帰などの ML モデルを、外部 API を呼び出さずに Oracle 内部で実行する 挿入時に埋め込みを生成する。不正な取引をリアルタイムで分類する。ラウンドトリップなしでリードをスコアリングする プロパティグラフでの Select AI SQL プロパティグラフに対して、自然言語のプロンプトでグラフの関係を照会する 「サプライヤー X と顧客 Y の間の最短サプライチェーン経路を見せて」 ソリューションの概要 この手順を終えると、次のことができるようになります。 AWS Identity and Access Management (IAM) の認証情報を作成し、 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle 内に格納する。 VPC インターフェイスエンドポイントを設定し、プライベートな Amazon RDS インスタンスからインターネットを経由せずに Amazon Bedrock に到達できるようにする。 Claude Sonnet や Amazon Nova などの Amazon Bedrock の基盤モデルを指す DBMS_CLOUD_AI プロファイルを作成、管理する。 LLM から Oracle のテーブルに合成テストデータを直接生成する。 SELECT AI の SQL 構文を使い、自分のテーブルに対して自然言語クエリを実行する。 DBMS_CLOUD_AI.GENERATE() をチャット、SQL の説明、要約に使う。 次の図は全体のアーキテクチャです。 図 1: Amazon RDS for Oracle 26ai と Amazon Bedrock による Select AI 主なコンポーネントは次のとおりです。 コンポーネント 役割 Amazon RDS for Oracle Database 26ai DBMS_CLOUD_AI を含み、Select AI のクエリを実行する Amazon Bedrock 基盤モデル (Claude、Nova) へのマネージドなアクセスを提供する VPC インターフェイスエンドポイント ( bedrock-runtime ) プライベートな Amazon RDS のサブネットからの Amazon Bedrock API 呼び出しを、インターネットを経由せずにルーティングする IAM 認証情報 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle に格納したアクセスキー ID とシークレット。Oracle がすべての Amazon Bedrock 呼び出しを SigV4 で署名するために使う 動作の流れ: ユーザーが SQL クライアントで自然言語の質問を入力します。Oracle が SELECT AI ステートメントを受け取り、質問と対象テーブルのスキーマメタデータを含むプロンプトを構築します。そして IAM ユーザーのアクセスキーで署名したリクエストを、VPC インターフェイスエンドポイント経由で HTTPS により Amazon Bedrock に送信します。LLM が返した SQL を Oracle が実データに対して実行し、結果セットを返します。ここまでのすべてが同一の SQL セッション内で行われます。 前提条件 始める前に、次を確認してください。 プライベートな VPC サブネットにデプロイした Amazon RDS for Oracle Database 26ai インスタンス。本記事では、データベースインスタンスとして一般的なパターンかつ推奨構成である、プライベートな Amazon RDS for Oracle インスタンスを前提とします。テスト目的であれば、インスタンスをパブリックに公開することもできます。 DBMS_CLOUD パッケージと DBMS_CLOUD_AI パッケージがインストールされていること (確認方法はステップ 1 で説明します)。 IAM ユーザーと VPC エンドポイントを作成する権限を持つ AWS アカウント。 対象の AWS リージョンで Amazon Bedrock が利用できること。Amazon Bedrock ではほとんどの基盤モデルがデフォルトで利用可能です。必要に応じて Amazon Bedrock コンソールの モデルアクセス で確認してください。 踏み台ホストまたは AWS Systems Manager Session Manager のポートフォワーディング経由で Amazon RDS インスタンスに接続した SQL Developer、SQLcl、その他の Oracle SQL クライアント。 Amazon RDS インスタンスに関連付けられた VPC ID、サブネット ID、セキュリティグループ ID。 DBMS_CLOUD と DBMS_CLOUD_AI の両方に EXECUTE 権限を持つデータベースユーザー (例: AIUSER)。必要なら、先に作成しておきます。 GRANT EXECUTE ON DBMS_CLOUD TO AIUSER; GRANT EXECUTE ON DBMS_CLOUD_AI TO AIUSER; ステップ 1: DBMS_CLOUD_AI が利用可能か確認する 設定を始める前に、必要なパッケージがインストールされていることを確認します。Amazon RDS for Oracle 26ai では、インスタンス作成時に DBMS_CLOUD と DBMS_CLOUD_AI がデフォルトでインストールされます。 SELECT object_name, object_type, status FROM dba_objects WHERE object_name IN ('DBMS_CLOUD', 'DBMS_CLOUD_AI') AND object_type IN ('PACKAGE', 'PACKAGE BODY') ORDER BY 1, 2; 4 行が返るはずです。 DBMS_CLOUD と DBMS_CLOUD_AI のそれぞれについて PACKAGE と PACKAGE BODY です。パッケージが見つからない場合は、Amazon RDS インスタンスが Oracle Database 26ai で動作しているか確認してください。 ステップ 2: Amazon Bedrock ランタイム用の VPC インターフェイスエンドポイントを作成する Amazon RDS for Oracle DB インスタンスは、ポート 443 (HTTPS) で Amazon Bedrock ランタイムのエンドポイント ( bedrock-runtime.<region>.amazonaws.com ) に到達できる必要があります。この通信を AWS ネットワーク内のプライベートな経路に留め、インターネットアクセスを不要にするには、Amazon Bedrock ランタイムサービス用の VPC インターフェイスエンドポイントを作成します。Amazon RDS インスタンスをプライベートに保てるため、VPC インターフェイスエンドポイントの利用が推奨されます。本記事の例でも VPC インターフェイスエンドポイントを使います。 もう 1 つの選択肢は NAT ゲートウェイです。NAT ゲートウェイを使う場合、DB インスタンスのサブネットに NAT ゲートウェイ経由でインターネットへ向かうルートが必要です。NAT ゲートウェイの設定は、 ドキュメント の「Amazon VPC network requirements」セクションのオプション 2 を参照してください。 エンドポイントを作成する AWS マネジメントコンソールで VPC 、 エンドポイント 、 エンドポイントを作成 の順に移動します。 サービスカテゴリ で AWS サービス を選択します。 サービス名 の検索で bedrock-runtime と入力し、 com.amazonaws.<your-region>.bedrock-runtime を選択します。 VPC では、Amazon RDS インスタンスがある VPC を選択します。 サブネット では、Amazon RDS の DB サブネットグループが使っているサブネットと同じものを選択します。 セキュリティグループ では、Amazon RDS インスタンスのセキュリティグループからの インバウンド TCP ポート 443 を許可するセキュリティグループをアタッチします。 ポリシー では フルアクセス を選択します。 プライベート DNS 名 を有効にします。ここが重要です。有効にすることで Oracle が bedrock-runtime.<region>.amazonaws.com をプライベート IP に解決し、通信が VPC 内でルーティングされます。 エンドポイントを作成 を選択し、状態が 利用可能 になるまで待ちます。 ステップ 3: Amazon Bedrock エンドポイントへのネットワーク ACL アクセスを許可する Oracle はアクセスコントロールリスト (ACL) でアウトバウンドのネットワークアクセスを制御します。AIUSER ユーザーに、 bedrock-runtime.<your-region>.amazonaws.com への HTTP/HTTPS のアウトバウンド接続を許可します。 BEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host => 'bedrock-runtime.<your-region>.amazonaws.com', ace => xs$ace_type( privilege_list => xs$name_list('connect', 'resolve', 'http'), principal_name => 'AIUSER', principal_type => xs_acl.ptype_db ) ); END; / DNS 解決を確認する エンドポイントが有効になったら、Oracle が Amazon Bedrock のホスト名をプライベート IP に解決することを確認します。 -- Should return a private IP, not a public AWS IP SELECT UTL_INADDR.GET_HOST_ADDRESS( 'bedrock-runtime.<your-region>.amazonaws.com' ) AS resolved_ip FROM dual; 出力例: RESOLVED_IP --------------- 172.31.17.236 ステップ 4: AWS の認証情報を作成し Oracle Database に格納する DBMS_CLOUD_AI は IAM のアクセスキー ID とシークレットアクセスキーで Amazon Bedrock に認証します。設定手順としては、Amazon Bedrock の基盤モデル呼び出しに必要な最小限の権限だけを付与した専用の IAM ユーザーを作成し、そのユーザーのアクセスキーを発行します。認証情報を取得したら、 DBMS_CLOUD.CREATE_CREDENTIAL を呼び出して Oracle データベース内に格納します。Oracle はキーを保存時に暗号化し、 DBMS_CLOUD_AI がアウトバウンドの Amazon Bedrock API リクエストの署名に自動的に使用します。 ステップ 4a: Amazon Bedrock アクセス用の IAM ユーザーを作成する 次のポリシーを持つ IAM ユーザーまたはロールを作成します (既存の ID にアタッチしても構いません)。 { "Version": "2012-10-17", "Statement": [{ "Sid": "BedrockInvoke", "Effect": "Allow", "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"], "Resource": ["arn:aws:bedrock:region::foundation-model/*"] }] } 特定のモデルだけにアクセスを制限するには、ワイルドカードを次のように個別のモデル ARN に置き換えます。 arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 ステップ 4b: アクセスキーを発行する 作成したユーザーを開き、 セキュリティ認証情報 タブに移動します。 アクセスキー で アクセスキーを作成 を選択します。 ユースケースを選択し、 アクセスキーを作成 を選択します。 アクセスキー ID とシークレットアクセスキーをコピーまたはダウンロードします。 セキュリティに関する注意: アクセスキーは長期的な認証情報です。本番環境では、IAM コンソールで定期的にローテーションすることを検討してください。この IAM ユーザーにはコンソールアクセス (パスワード) を与えないようにします。 ステップ 4c: IAM ユーザーのアクセスキーを Oracle に格納する Amazon Bedrock のモデルアクセス: 2025 年時点で、Amazon Bedrock のほとんどの基盤モデルはデフォルトで利用可能で、明示的な有効化は不要です。アカウントとリージョンでのモデルの利用可否は、 Amazon Bedrock コンソール の モデルアクセス で確認または変更できます。Amazon RDS for Oracle 26ai の DBMS_CLOUD_AI で動作を検証済みのモデルは次のとおりです。 モデル名 モデル ID 備考 Anthropic Claude Sonnet 4.6 us.anthropic.claude-sonnet-4-6 NL2SQL の精度が最も高い (推奨) Anthropic Claude Haiku 4.5 us.anthropic.claude-haiku-4-5-20251001-v1:0 最速 / 最低コスト Amazon Nova Pro us.amazon.nova-pro-v1:0 高性能な AWS ネイティブモデル Amazon Nova Lite amazon.nova-lite-v1:0 単純なクエリ向けの超高速モデル 重要: クロスリージョン推論のプレフィックス: Anthropic Claude と Amazon Nova Pro のモデル ID には us. プレフィックスが必要です。このプレフィックスによってリクエストがクロスリージョン推論プロファイル経由でルーティングされ、可用性が高まります。プレフィックスのないベースモデル ID を使うと ORA-20400: HTTP 400 が返ります。 DBMS_CLOUD.CREATE_CREDENTIAL を使い、ステップ 4a で取得したアクセスキーとシークレットキーを Oracle の認証情報ストアに格納します。Oracle は認証情報を暗号化し、所有ユーザーだけがアクセスできるようにします。 BEGIN DBMS_CLOUD.CREATE_CREDENTIAL( credential_name => 'AWS', username => '<your-access-key-id>', password => '<your-secret-access-key>' ); END; / 認証情報が正しく作成されたか確認します。 SELECT credential_name, username, enabled FROM all_credentials WHERE credential_name = 'AWS'; username 列には指定したアクセスキー ID が表示されます。シークレットキーは暗号化されて格納され、クエリでは返りません。 ステップ 5: サンプルテーブルを作成する Select AI のデモには E コマースのスキーマを使います。既存のテーブルがある場合は、ステップ 6 に進んでプロファイルの object_list で自分のテーブルを指定してください。 CREATE TABLE customers ( customer_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, first_name VARCHAR2(50), last_name VARCHAR2(50), email VARCHAR2(100), city VARCHAR2(50), country VARCHAR2(50), signup_date DATE, segment VARCHAR2(20) -- 'PREMIUM', 'STANDARD', 'NEW' ); CREATE TABLE products ( product_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, product_name VARCHAR2(100), category VARCHAR2(50), unit_price NUMBER(10,2), stock_qty NUMBER ); CREATE TABLE orders ( order_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, customer_id NUMBER REFERENCES customers(customer_id), order_date DATE, status VARCHAR2(20), -- 'COMPLETED', 'PENDING', 'CANCELLED' total_amount NUMBER(10,2) ); CREATE TABLE order_items ( item_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, order_id NUMBER REFERENCES orders(order_id), product_id NUMBER REFERENCES products(product_id), quantity NUMBER, unit_price NUMBER(10,2) ); ステップ 6: DBMS_CLOUD_AI プロファイルを作成する プロファイル は Select AI の中心となる設定オブジェクトです。AI プロバイダー、認証情報、呼び出す Amazon Bedrock のモデル、そしてプロンプトのコンテキストにスキーマを含めるデータベーステーブルを指定します。 DBMS_CLOUD_AI はデフォルトで bedrock-runtime.us-east-1.amazonaws.com に接続します。us-east-1 以外のリージョンの Amazon Bedrock ランタイムエンドポイントを使う場合は、プロファイル属性の JSON に region 属性と target_language 属性を含めます。 region には Amazon Bedrock ランタイムエンドポイントがあるリージョン (例: us-west-2) を設定します。 region を設定する場合は、 target_language (または source_language ) も含める必要があります。 chat や runsql のように翻訳を使わないアクションでも、この 2 つの属性は必ずセットで設定してください。 target_language の値が影響するのは translate アクションだけです。セットで指定しなければならないのは、Oracle の DBMS_CLOUD_AI パッケージに既知の制限があるためです。 region なしで target_language だけを指定した場合、プロファイルは bedrock-runtime.us-east-1.amazonaws.com を使い続けます。VPC インターフェイスエンドポイントが別のリージョンにあると、Oracle はエンドポイントが存在しないリージョンへパブリックインターネット経由で接続を試み、ネットワーク構成でパブリックアクセスを許可していない限り、すべての呼び出しが ORA-30699 でタイムアウトします。 次の例では、Amazon Bedrock のクロスリージョン推論 (CRIS) 経由で Anthropic Claude Sonnet 4.6 を使うプロファイルを作成します。 BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'CLAUDE_SONNET', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.anthropic.claude-sonnet-4-6", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / object_list は、LLM 向けのスキーマコンテキストを構築するときに含めるテーブルとビューを Oracle に伝えます。Oracle はデータディクショナリから列名、データ型、列コメントを自動的に読み取り、プロンプトに組み込みます。スキーマを手作業で記述する必要はありません。 異なるモデルを指すプロファイルを複数作成し、セッションごとに切り替えることもできます。 -- Amazon Nova Pro profile BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'NOVA_PRO', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.amazon.nova-pro-v1:0", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / セッションでプロファイルを有効化し、確認します。 EXECUTE DBMS_CLOUD_AI.SET_PROFILE('CLAUDE_SONNET'); -- Confirm active profile SELECT DBMS_CLOUD_AI.GET_PROFILE() FROM dual; -- List all profiles SELECT profile_name, status FROM user_cloud_ai_profiles; ステップ 7: 合成データを生成する Amazon Bedrock にアクセスできる AI プロファイルを設定したら、 DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA でテーブルに現実的なテストデータを自動投入できます。 GENERATE_SYNTHETIC_DATA は、指定した AI プロファイル経由で LLM を使い、文脈に沿ったレコードを生成します。 object_list パラメータには、対象テーブルとそれぞれの生成レコード数を指定する JSON 配列を渡します。 次の PL/SQL ブロックを実行して、4 つのテーブルに合成データを生成します。 BEGIN DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA( profile_name => 'CLAUDE_SONNET', object_list => '[ {"owner": "AIUSER", "name": "CUSTOMERS", "record_count": 50}, {"owner": "AIUSER", "name": "PRODUCTS", "record_count": 250}, {"owner": "AIUSER", "name": "ORDERS", "record_count": 500}, {"owner": "AIUSER", "name": "ORDER_ITEMS", "record_count": 1000} ]' ); END; / 実行すると、顧客 50 件、製品 250 件、注文 500 件、注文明細 1,000 件が生成されます。テストデータを手作業で作り込まなくても、クエリ、レポート、アプリケーションロジックの検証に使える現実的なデータセットが手に入ります。 内部では、Oracle が対象テーブルの DDL、制約、メタデータを読み取り、データ型と外部キーを満たす現実的な行を生成するよう LLM にプロンプトを出します。生成方法は次の要素でカスタマイズできます。 sample_rows : 既存のレコードを例として渡し、生成されるデータを実データのスタイルに合わせます。 user_prompt : 「英国の郵便番号のみ」「2009 年公開の映画」といったルールを指定します。 テーブル統計 (デフォルトで有効): 列の最大値・最小値と個別値のリストを使って出力範囲を制限します。 列コメント: 列にヒント (例: 許可される Status の値) を付けると、LLM は生成時にヒントに従います。 一意制約: LLM のレスポンスから重複行を自動的に破棄します。 ステップ 8: Select AI で自然言語クエリを実行する プロファイルを設定してデータを投入したら、 SELECT AI の SQL 構文で平易な英語のままリレーショナルデータを照会できます。Oracle はステートメントを受け取り、質問と object_list のテーブルスキーマメタデータを組み合わせたプロンプトを構築し、Amazon Bedrock のモデルを呼び出して結果を返します。 実行前に生成された SQL を確認する showsql を使うと、LLM が生成した SQL を実行せずに確認できます。精度の検証や信頼性の確認に役立ちます。 SELECT AI showsql how many customers do we have per country; 出力例: SELECT country, COUNT(*) AS customer_count FROM customers GROUP BY country ORDER BY customer_count DESC 実行して結果を返す runsql に切り替えると、生成された SQL を実行して結果を返します。 SELECT AI runsql how many customers do we have per country; SELECT AI runsql what is the total revenue by product category; SELECT AI runsql who are the top 3 customers by total spend; SELECT AI runsql how many orders were cancelled; SELECT AI runsql show me all pending orders with customer name and amount; 結果を自然言語の文章で返す narrate アクションは、クエリ結果を平易な英語で要約して返します。ビジネスレポートやダッシュボードに適しています。 SELECT AI narrate give me a sales summary for 2024; SELECT AI narrate who are our best customers and what do they buy; 1 つ目のクエリの出力例: Based on the 2024 sales data, total completed revenue is $14,299.98 across six completed orders. Frank Wilson is the top-spending customer at $7,000.00, followed by Alice Johnson at $6,099.99. The Software category leads all product categories in revenue. Two orders remain in Pending status with a combined value of $2,500.00. 既存の SQL を平易な英語で説明する explainsql アクションは、既存の SQL クエリを受け取って平易な英語の説明を返します。ドキュメント作成やオンボーディングに役立ちます。 SELECT AI explainsql SELECT c.first_name, c.last_name, SUM(o.total_amount) AS total FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE o.status = 'COMPLETED' GROUP BY c.first_name, c.last_name ORDER BY total DESC; 出力例: Query Analysis & Oracle SQL Conversion Original Query Issues: - Missing schema names - Missing double quotes around case-sensitive identifiers - 'COMPLETED' is not in double quotes in the question; must use UPPER() for case-insensitive comparison Converted Oracle SQL: SELECT c."FIRST_NAME" AS first_name, c."LAST_NAME" AS last_name, SUM(o."TOTAL_AMOUNT") AS total FROM "AI_TEST"."CUSTOMERS" c JOIN "AI_TEST"."ORDERS" o ON c."CUSTOMER_ID" = o."CUSTOMER_ID" WHERE UPPER(o."STATUS") = UPPER('COMPLETED') GROUP BY c."FIRST_NAME", c."LAST_NAME" ORDER BY total DESC; ステップ 9: DBMS_CLOUD_AI.GENERATE() を他の AI タスクに使う SELECT AI 構文に加えて、 DBMS_CLOUD_AI.GENERATE() を使うと Amazon Bedrock のモデルに直接アクセスできます。自由形式のチャット、要約、プロンプトからの SQL 生成のように、データベースのスキーマコンテキストを必要としないタスクに使えます。 テキストを要約する SELECT DBMS_CLOUD_AI.GENERATE( prompt => 'Oracle Database 26ai introduces AI Vector Search, hybrid BM25 and semantic search, an embedded ONNX inference runtime, SQL/PGQ property graph queries, JSON-Relational Duality Views, native BOOLEAN type, and lock-free reservations for high-concurrency workloads.', profile_name => 'CLAUDE_SONNET', action => 'summarize' ) AS summary FROM dual; インラインのテキストを要約するだけでなく、 DBMS_CLOUD_AI.GENERATE を Amazon Simple Storage Service (Amazon S3) バケットに保存された文書を直接処理することもできます。次のクエリは Amazon S3 から PDF を取得し、 DBMS_VECTOR_CHAIN.UTL_TO_TEXT でテキストに変換します。そのうえで内容を LLM に渡して要約させます。ここまでを 1 つの SQL ステートメントで実行します。 SELECT DBMS_CLOUD_AI.GENERATE( prompt => DBMS_VECTOR_CHAIN.UTL_TO_TEXT( DBMS_CLOUD.GET_OBJECT( credential_name => 'AWS', object_uri => 'https://s3.us-west-2.amazonaws.com/<Bucket Name>/<File Name>')), profile_name => 'CLAUDE_SONNET', action => 'SUMMARIZE') FROM DUAL; / 内部では、3 つの関数が 1 つの SQL ステートメント内で連鎖します。 DBMS_CLOUD.GET_OBJECT が指定した認証情報を使って Amazon S3 バケットから PDF 文書を取得します。 DBMS_VECTOR_CHAIN.UTL_TO_TEXT がバイナリの内容を LLM が処理できるプレーンテキストに変換します。 DBMS_CLOUD_AI.GENERATE が抽出したテキストを AI プロファイル経由で Amazon Bedrock に送信し、要約を返します。Amazon RDS for Oracle インスタンスから Amazon S3 に到達できるようにするには、前提条件が 2 つ追加で必要です。1 つは Amazon S3 用の VPC ゲートウェイエンドポイントで、Amazon RDS のサブネットに関連付けられたルートテーブルに追加し、通信をパブリックインターネットから切り離します。もう 1 つは対象バケットへの s3:GetObject と s3:ListBucket の権限を付与する IAM ポリシーで、ステップ 4a で作成したユーザーにアタッチします。 トラブルシューティング 次の表に、遭遇しやすいエラーと根本原因、対処方法をまとめます。 エラー 根本原因 対処 ORA-30699: network connection failed: connection timed out bedrock-runtime の VPC エンドポイントがない、またはプロファイルの "region" が未指定か誤っている 正しいリージョンに bedrock-runtime の VPC インターフェイスエンドポイントを作成する。すべてのプロファイルに "region": "<your-region>" を追加する DNS がパブリック IP に解決される VPC エンドポイントでプライベート DNS 名が有効になっていない エンドポイントを編集してプライベート DNS 名を有効にする ORA-20400: HTTP 400 モデル ID が単一リージョン / オンデマンドの形式 (旧形式) になっている モデル ID にクロスリージョン推論の us. プレフィックスを追加する ORA-20404: HTTP 404 そのリージョンでモデルが利用できない、またはアクセスが有効になっていない Amazon Bedrock → モデルアクセスでリージョンでのモデルの利用可否を確認する。モデル ID が正しいことを確認する ORA-20400: HTTP 403 IAM ユーザーに bedrock:InvokeModel の権限がない BedrockInvokeModelPolicy が IAM ユーザーにアタッチされているか確認する ORA-20001: profile not found プロファイルが作成されていない、または名前が間違っている SELECT profile_name FROM user_cloud_ai_profiles を実行する ORA-29024: Certificate validation failure Oracle ウォレットに Amazon Bedrock の CA 証明書がない Amazon RDS では file:/rdsdbdata/rds-metadata/dbms_cloud_wallet にプリインストールされたウォレットに必要な CA が含まれているため、対応は不要 クリーンアップ この手順で作成したリソースを削除するには、次を実行します。 -- Drop AI profiles EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('CLAUDE_SONNET'); EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('NOVA_PRO'); -- Drop the Bedrock credential EXECUTE DBMS_CLOUD.DROP_CREDENTIAL('AWS'); -- Drop sample tables (if created for this walkthrough) DROP TABLE order_items; DROP TABLE orders; DROP TABLE products; DROP TABLE customers; AWS マネジメントコンソールでは、次の手順を実行します。 IAM → ユーザー で、ステップ 4a で作成した IAM ユーザーを削除します。 VPC → エンドポイント で、 bedrock-runtime の VPC インターフェイスエンドポイントを削除します。 まとめ 本記事では、AI プロバイダーとして Amazon Bedrock を使い、Amazon RDS for Oracle Database 26ai で Select AI を設定する一連の手順を説明しました。IAM コンソールでの AWS 認証情報の作成、Oracle への認証情報の格納、VPC エンドポイントのセットアップ、自然言語クエリの実行までを、パブリックインターネットアクセスのないプライベートな Amazon RDS インスタンスで行いました。 Select AI を使えば、データを活用する人に SQL のスキルは不要になり、AI のロジックは信頼できる Oracle 環境の内側に留まります。ビジネスアナリストは SQL Developer や Oracle に接続したツールから、平易な英語で本番データを直接照会できます。データベース管理者は、モデルに公開するテーブル、有効にする基盤モデル、使用する IAM 認証情報を完全に制御し続けられます。いずれも Oracle 標準のプロファイルと認証情報の仕組みで管理できます。 本記事は Oracle Database 26ai と Amazon Bedrock を扱う 3 回シリーズの第 1 回です。 第 1 回 (本記事): Amazon RDS での Select AI と DBMS_CLOUD_AI による自然言語クエリ。 第 2 回: Oracle 26ai のネイティブなベクトル検索と Amazon Bedrock による RAG パイプラインの構築。 第 3 回: Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock によるデータベース内 GraphRAG。 著者について Yamuna Palasamudram Yamuna は AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで、Oracle などの商用データベースエンジンを担当しています。お客様と協力して AWS 上のリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援し、技術的なガイダンスを提供することにやりがいを感じています。 Ibrahim Emara Ibrahim は Amazon Web Services のデータベーススペシャリストソリューションアーキテクトで、AWS のお客様向けにデータベースソリューションの設計と実装を担当しています。Oracle、PostgreSQL、Amazon Aurora、AWS Database Migration Service に関する専門知識を活かし、クラウド移行の推進とデータベースパフォーマンスの改善に取り組んでいます。 Minu Hong Minu は AWS の Amazon RDS for Oracle のシニアプロダクトマネージャーです。クラウドネイティブかつ AI を活用したソリューションで、お客様がデータの可能性を最大限に引き出せるよう支援することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。