はじめに

SQL Serverは、OCI上のWindows Server、オンプレミス、Azureなど、さまざまな場所に配置されます。本記事では、こうしたSQL Serverに対して、Autonomous AI Database（以下、ADB）のPrivate DB Linkを使って接続し、ADBから透過的に参照できるかを検証します。

検証対象には、OCI上のWindows Serverに構成したSQL Serverを使いました。まず同一VCN内でPrivate DB Linkによる接続を確認し、そのうえでオンプレミスや他クラウドへ広げる際の考え方も整理します。検証環境では、手元のSQL Server Expressを使用しています。

SQL Serverへつなぐ方法としてはGatewayを配置する構成もありますが、今回は顧客側VMに Oracle AI Database Gateway for SQL Serverを導入しない 方を先に試しました。使うのはOracle-managed heterogeneous connectivityです。本記事では、ADBからSQL ServerへDatabase Link（DB Link）を作り、最後にSelect AIから自然言語で参照するところまでを、実際に確認した順番でまとめます。

先に制約を一つだけ。この方式は参照専用です。SQL ServerへのINSERT、UPDATE、DELETEは対象外なので、まずは分析・参照用途として考えるのが分かりやすいです。

本記事で実施したこと

本記事では、ネットワーク、SQL Server、ADBの順で設定と確認を行います。全体の流れは次のとおりです。

OCI VCN内のPublic SubnetにWindows Serverを配置し、その上にSQL Serverを構成する
同じVCN内のPrivate SubnetにADBのPrivate Endpointを構成する
ADBから、Windows ServerのPrivate IPへ解決される内部FQDNに対してDB Linkを作成する
dbo.orders@MSSQL_PRIVATE_LINK を実行し、SQL Server上のテストデータをADBから参照する
ADB側ViewとAI Profileを設定し、Select AIからSQL Server上のテストデータを参照する

構成

今回の検証用VCNにはPublic SubnetとPrivate Subnetがあります。Public SubnetにはWindows Serverを置き、その上でSQL Serverを稼働させています。ADBはOracle管理サービスですが、Private Endpointを指定することで、Private Subnet側のネットワークに参加させます。

ポイントは、Windows ServerがPublic Subnetにあっても、DB LinkをPublic IPへ向けないことです。ADBのPrivate Endpointから、Windows ServerのPrivate IPへ解決される内部FQDNへTCP 1433で接続します。

クライアントからADBへ入る経路と、ADBからSQL Serverを読む経路は分けて考えると整理しやすくなります。

通信	経路	用途
クライアント端末 → ADB	Public Access + TLS	管理・SQL実行
ADB → SQL Server	ADB Private Endpoint + VCN内通信	DB Link経由のデータ参照

検証環境について

今回は検証を進めやすくするため、Windows ServerをPublic Subnetに配置しています。本番環境では、Windows ServerとSQL ServerはPrivate Subnetに配置する構成が一般的です。

DB Linkを作るという観点では、SQL ServerがPublic SubnetかPrivate Subnetかで手順の本質は変わりません。ADBからSQL Serverへネットワーク到達性を確保し、Security List／NSG、Windows Firewall、名前解決を設定したうえでDB Linkを作成します。同一VCN内ならPrivate IP通信、別VCNやOCI外ならPeering、VPN、FastConnectなどで到達性を用意します。

本記事で実証したのは、同一VCN内のWindows Serverへ接続する構成です。オンプレミスやAzure上のSQL Serverを対象にする場合も考え方は同じですが、VPN／FastConnectなどでVCNから対象ネットワークへの到達性とDNS名前解決を別途用意する必要があります。

前提条件

今回の検証では、次の構成・設定を前提としています。

ADBはPrivate Endpointを利用できる構成であること
ADBとWindows VMが同一VCN内、またはPeeringなどで疎通できること
Windows ServerにSQL Serverがインストール済みであること
SQL ServerでSQL Server認証（Mixed Mode）を利用できること
クライアント端末からPublic EndpointでADBを操作する場合は、Public Access ACLにクライアント端末のグローバルIPを登録済みであること

Public Accessは、クライアント端末からADBを操作するための設定です。ADBからSQL Serverへ接続するDB Link自体には不要です。

Oracle-managed heterogeneous connectivityを選ぶ理由

ADBから非OracleデータベースへDB Linkを作る方法は一つではありません。ここは最初に少し迷ったところです。大きくは次の2種類があり、Oracle-managed方式で対応するデータベース種別、ポート、および制約はOracleの公式ドキュメントで確認できます。

方式	接続経路	特徴
Oracle-managed heterogeneous connectivity	ADB → SQL Server	Gateway導入不要。導入と運用が軽い。参照専用
Customer-managed heterogeneous connectivity	ADB → Oracle AI Database Gateway → SQL Server	Gatewayの導入・Listener・証明書などが必要。更新可否を含む個別要件は、Gateway側の対応SQLと接続方式を確認する

今回はSQL Serverデータの参照と、後続のSelect AI利用が目的です。Gatewayを増やさず始められることを優先して、前者を選びました。

1. SQL Server側の準備

1.1 SSMS（SQL Server Management Studio）から接続する

SSMSはサーバーを必ずしも自動検出しないため、接続時にはインストール済みインスタンス名を明示します。今回の検証環境では、次の値で接続しました。

Server type:       Database Engine
Server name:       .\SQLEXPRESS
Authentication:    Windows Authentication

1.2 テストデータを作成する

まずはDB Linkだけを確かめられるよう、adbtestデータベースに小さな受注テーブルを作ります。業務テーブルをいきなり対象にしない方が、ネットワークの問題と権限の問題を切り分けやすくなります。

USE adbtest;
GO

CREATE TABLE dbo.orders (
    order_id       INT IDENTITY(1,1) PRIMARY KEY,
    customer_name  NVARCHAR(100) NOT NULL,
    product_name   NVARCHAR(100) NOT NULL,
    order_amount   DECIMAL(12,2) NOT NULL,
    order_date     DATETIME2 NOT NULL DEFAULT SYSDATETIME(),
    status         NVARCHAR(20) NOT NULL
);
GO

INSERT INTO dbo.orders
    (customer_name, product_name, order_amount, order_date, status)
VALUES
    (N'株式会社サンプル', N'クラウド利用料', 150000.00, '2026-08-01', N'完了'),
    (N'テスト商事', N'AI分析サービス', 280000.00, '2026-08-15', N'処理中');
GO

SELECT * FROM dbo.orders;
GO

dboはスキーマ名です。adbtest.dbo.ordersは「adbtestデータベースのdboスキーマにあるordersテーブル」を意味します。SQL Serverに慣れていない場合は、ここをデータベース名の一部と捉えると分かりやすいです。

1.3 TCP/IPとTCP 1433を設定する

DB Link側では接続ポートを明示するため、SQL Serverも固定ポートで待ち受けさせます。Windows ServerでSQL Server Configuration Managerを開き、次を設定します。

SQL Server Network Configuration
  → Protocols for <instance_name>
  → TCP/IP: Enabled

TCP/IP Properties
  → IP Addresses
  → IPAll
      TCP Dynamic Ports: 空欄
      TCP Port:          1433

設定後は、対象のSQL Serverサービスを再起動します。再起動を忘れると、設定は合っているのに接続できない、という状態になりがちです。

管理者PowerShellで待受を確認します。

Get-NetTCPConnection -State Listen -LocalPort 1433

次のように表示されれば、SQL ServerはTCP 1433で待ち受けています。

0.0.0.0:1433  Listen
[::]:1433     Listen

1.4 DB Link用の読取り専用ユーザーを作成する

ADBから使う資格情報には、ADMINやWindows管理者を流用せず、SQL Serverの読取り専用ログインを作ります。DB Link用のアカウントを分けておくと、後で権限を見直すときにも楽です。

USE master;
GO

CREATE LOGIN ADB_READER
WITH PASSWORD = '<十分に強いパスワード>';
GO

USE adbtest;
GO

CREATE USER ADB_READER FOR LOGIN ADB_READER;
ALTER ROLE db_datareader ADD MEMBER ADB_READER;
GO

2. ADBとVCNの設定

2.1 ADBをPrivate Endpoint経由でアウトバウンド接続させる

ADBがPrivate Endpoint構成であることを確認します。一方、手元のクライアント端末からADBを操作したい場合もあります。その場合に限り、Private Endpointに加えてAllow public accessを有効化し、クライアント端末のグローバルIPだけをACLに登録します。Allow public accessはECPUコンピュート・モデルで利用できます。

VS Codeからは、OCIコンソールのDatabase connection画面で以下を選択します。

TLS Authentication: TLS
Access:             Public endpoint URL

Oracle SQL Developer Extension for VS Codeでは、Custom JDBC URLを選び、コピーしたTLS接続文字列の先頭にjdbc:oracle:thin:@を付けて接続します。

jdbc:oracle:thin:@(description=...)

ここが今回の要所です。ADBに接続後、DB Linkなどのアウトバウンド通信をPrivate Endpoint経由に固定します。これを設定しないと、せっかくPrivate Endpointを構成しても、DB Linkの通信が期待した経路を通りません。ROUTE_OUTBOUND_CONNECTIONSの意味と選択肢は、Private Endpointのアウトバウンド接続に関する公式説明を参照してください。

ALTER DATABASE PROPERTY
  SET ROUTE_OUTBOUND_CONNECTIONS = 'PRIVATE_ENDPOINT';

本検証ではPRIVATE_ENDPOINTを使用しました。DB Linkに加え、DBMS_CLOUD_AIなどのDBMS_CLOUD系パッケージを含むアウトバウンド通信もPrivate Endpointの制御下に置く要件では、Oracleが推奨するENFORCE_PRIVATE_ENDPOINTも評価します。

PRIVATE_ENDPOINTとENFORCE_PRIVATE_ENDPOINTは、どちらか一方を設定します。本検証では前者を使用しました。

ALTER DATABASE PROPERTY
  SET ROUTE_OUTBOUND_CONNECTIONS = 'ENFORCE_PRIVATE_ENDPOINT';

このプロパティは、設定後に作成したDB Linkに適用されます。そのため、本記事ではDB Linkを作成する前に設定しています。

確認SQLです。

SELECT *
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'ROUTE_OUTBOUND_CONNECTIONS';

2.2 OCIとWindows FirewallでTCP 1433を許可する

以下では例として、ADB Private Endpoint IPを10.0.1.91としています。実環境の値へ置き換えてください。

OCI側

同一VCN内であっても、Security ListやNSGが通信を許可していなければ接続できません。今回のようにWindows ServerをPublic Subnet、ADB Private EndpointをPrivate Subnetへ配置する場合、SubnetのSecurity Listには次のルールを設定します。NSGを利用する場合も、考え方は同じです。

設定先	方向	送信元／宛先	プロトコル・ポート	用途
Windows ServerがあるPublic SubnetのSecurity List	Ingress	送信元: `<ADB Private Endpoint IP>/32`	TCP 1433	ADBからSQL Serverへの接続を許可
ADB Private EndpointがあるPrivate SubnetのSecurity List	Egress	宛先: `<Windows VMのPrivate IP>/32`	TCP 1433	ADBからSQL Serverへの送信を許可

Public Subnet側のIngressルールの例です。

Source CIDR:             <ADB Private Endpoint IP>/32
IP Protocol:             TCP
Destination Port Range:  1433
Stateless:               No

Private Subnet側のEgressルールの例です。

Destination CIDR:        <Windows VMのPrivate IP>/32
IP Protocol:             TCP
Destination Port Range:  1433
Stateless:               No

Windows Firewall側

OCI側だけでなく、Windows Firewallも通す必要があります。管理者PowerShellで、ADB Private Endpoint IPだけを許可するルールを追加します。

New-NetFirewallRule `
  -DisplayName "Allow SQL Server 1433 from ADB Private Endpoint" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 1433 `
  -RemoteAddress <ADB Private Endpoint IP> `
  -Profile Any

GUIで設定する場合は、wf.msc → Inbound Rules → New Rule → Customと進み、Scope画面でRemote IP AddressにADB Private Endpoint IPを設定します。

2.3 接続先にはWindows VMの内部FQDNを指定する

今回の検証では、DB Linkのhostnameに、VCN内でWindows VMのPrivate IPへ解決される内部FQDNを指定しました。OCIのVCN DNSの仕様では、VMのFQDNはHostname、Subnet DNS Label、VCN DNS Labelから構成されます。

OCIでVCN DNS Label、Subnet DNS Label、VNICのHostnameが設定されている場合、Windows VMには次の形式の内部FQDNがあります。

<hostname>.<subnet DNS label>.<VCN DNS label>.oraclevcn.com

Windows Server上で、Private IPを逆引きして確認できます。

nslookup <Windows VMのPrivate IP> 169.254.169.254

例:

Name:    win-sqlserver.sub09140458560.vcn.oraclevcn.com
Address: 10.0.0.56

このFQDNをDB Linkのhostnameへ指定します。今回のようにOCI既定の内部DNSが使えるなら、検証のためだけにPrivate DNS Zoneを自作せずに済みます。

3. Oracle-managed DB Linkを作成する

3.1 ADB側にSQL Server資格情報を登録する

ADBへSQL Serverログイン情報を暗号化して保存します。パスワードをDB Link作成SQLへ直接書かず、Credentialとして分けるのがポイントです。

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'MSSQL_ADBTEST_CRED',
    username        => 'ADB_READER',
    password        => '<ADB_READERのパスワード>'
  );
END;
/

3.2 DB Linkを作成する

db_typeの値はazureです。名前だけ見るとAzure SQL専用に見えますが、Oracle-managed heterogeneous connectivityの対応表ではMicrosoft SQL Serverにも使用します。ここはそのままsqlserverと書きたくなるので注意が必要です。

BEGIN
  DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
    db_link_name       => 'MSSQL_PRIVATE_LINK',
    hostname           => '<Windows VMの内部FQDN>',
    port               => 1433,
    service_name       => 'adbtest',
    credential_name    => 'MSSQL_ADBTEST_CRED',
    ssl_server_cert_dn => NULL,
    private_target     => TRUE,
    gateway_params     => JSON_OBJECT(
      'db_type' VALUE 'azure'
    )
  );
END;
/

Oracle-managed heterogeneous connectivityでは、ADBが対象DBへのセキュアな接続を処理します。本検証ではこの設定で接続できましたが、SQL Server側のForce Encryptionや証明書の構成は環境ごとに確認が必要です。Oracleの現行ドキュメントを確認し、切り分け時はTCP到達性、TLS、証明書、SQL Serverログインの順に確認します。

3.3 SQL ServerのデータをADBから参照する

SELECT *
FROM dbo.orders@MSSQL_PRIVATE_LINK;

実行結果です。SQL Serverのadbtest.dbo.ordersに投入した2件が、ADB側から取得できました。

order_id  customer_name      product_name        order_amount  order_date  status
--------  -----------------  ------------------  ------------  ----------  ------
1         株式会社サンプル   クラウド利用料      150000        26-08-01    完了
2         テスト商事         AI分析サービス      280000        26-08-15    処理中

adbtest.dbo.ordersに投入したテストデータがADBから返れば、DB Linkの疎通確認は完了です。

接続確認だけならここで終わりですが、アプリケーションやAI利用者にはDB Linkを直接公開せず、ADB側のViewとして公開する方が扱いやすくなります。公開する列や行を後から調整できるためです。

第5章のSelect AI検証では、このViewに対象列の説明を付け、AI ProfileにはViewだけを登録します。

4. 実際に詰まった点と対処

4.1 クライアント端末からPrivate Endpoint型ADBへ接続できない

Private Endpointだけでは、インターネット上のクライアント端末から接続できません。Walletを持っていれば何とかなるようにも見えますが、Private IPへのネットワーク経路は別途必要です。Private EndpointとPublic Accessの併用方法を確認してください。

今回の対処は、ADBでAllow public accessを有効化し、クライアント端末のグローバルIPだけをACLで許可することでした。VS CodeからはPublic Endpoint向けTLS接続文字列を使用します。

4.2 SSMSにSQL Serverが表示されない

SSMSの一覧へ自動表示されないことがあります。インストール済みのインスタンス名を明示して接続します。

.\<instance_name>

4.3 `ORA-28500` / `Connection refused`が発生した

次のエラーが発生しました。

[DataDirect][ODBC SQL Server Wire Protocol driver]
Connection refused. Verify Host Name and Port Number.

このエラーが出た時点では、SQL Serverユーザーやテーブル名より前、つまりTCP接続に問題があります。設定を一気に変えず、次を上から順に確認すると切り分けしやすいです。

SQL ServerがTCP 1433で待ち受けているか
Windows FirewallでADB Private Endpoint IPからの1433を許可しているか
OCI Security List／NSGで同じ通信を許可しているか
DB LinkのFQDNがWindows VMのPrivate IPへ解決されるか

4.4 DB Linkの接続先をPrivate IPで直接指定したい

今回の構成では、IPアドレス直指定ではなく、VCN DNSでPrivate IPへ解決できる内部FQDNを使用しました。OCI既定の*.oraclevcn.com形式の内部FQDNが使える場合は、Private DNS Zoneを追加しなくても済みます。

4.5 `DROP DATABASE LINK`で`ORA-01031`が発生した

DB Linkはスキーマ単位のオブジェクトです。作成したユーザー以外は削除できません。

ORA-01031: insufficient privileges

既存のリンクの所有者で接続して削除するのが本筋です。ただ、検証中であれば別名のDB Linkを作って接続先を切り替える方が、作業を止めずに済みます。

5. Select AIからSQL Serverのデータを参照する（チュートリアルの補足）

Select AIそのものの基本手順は、まずOCIチュートリアル「111: SELECT AIを試してみよう」を参照するのが分かりやすいです。ユーザー・データセット・Credential・AI Profileを準備し、コメントでメタデータを補足してからSELECT AIを実行する流れがまとまっています。

ここでは、そのチュートリアルを実施済み、または全体の流れを把握していることを前提に、DB Link経由のSQL Server表を対象にする場合の追加設定だけを扱います。チュートリアルではADB内の表を対象にしますが、今回はDB Link先のSQL Server表をADB側Viewとして公開し、そのViewをAI Profileの対象にします。

また、チュートリアルはOCIユーザーのAPIキーからCredentialを作る方式です。今回の検証では、ADB内にOCI API秘密鍵を保持しないResource Principalを採用しました。どちらもSelect AIでOCI Generative AIを呼ぶための認証方法ですが、Credentialの準備だけが異なります。

今回の追加点は次の3つです。

OCIユーザーAPIキーCredentialの代わりに、ADBのResource Principalを使う
DB Linkそのものではなく、DB Link先を参照するADB側ViewをAI Profileの対象にする
SQL Server側の列名の表記を保ってViewを定義し、列コメントで業務上の意味を補足する

5.1 今回追加した認証設定：Resource Principal

Select AIでOCI Generative AIを使うには、SQL Server用のMSSQL_ADBTEST_CREDとは別に、OCI Generative AIを呼び出す認証が必要です。今回は、ADB内に長期のOCI API秘密鍵を置かないResource Principalを使いました。

まずOCI IAMで、対象ADBだけをメンバーにしたDynamic Groupを作成します。

ALL {resource.type = 'autonomousdatabase', resource.id = '<ADBのOCID>'}

そのDynamic Groupに、OCI Generative AIの利用を許可します。

Allow dynamic-group <Dynamic Group名> to use generative-ai-family in compartment <コンパートメント名>

次にADBのADMINユーザーで、Resource Principalを有効化します。DB Linkを作成したスキーマでSelect AIを実行するため、ここではADMINを指定しています。別スキーマの場合はそのユーザー名に置き換えます。

BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL();
  DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL(username => 'ADMIN');
END;
/

DB Linkを作成したスキーマへ接続し、OCI$RESOURCE_PRINCIPALが確認できれば準備完了です。

SELECT credential_name
FROM user_credentials
ORDER BY credential_name;

今回の結果は次のとおりでした。

MSSQL_ADBTEST_CRED
OCI$RESOURCE_PRINCIPAL

MSSQL_ADBTEST_CREDはSQL Serverログイン用、OCI$RESOURCE_PRINCIPALはOCI Generative AI呼出し用です。用途が異なるため、分けて扱います。Resource Principalの設定方法は公式ドキュメント、Select AIのProfile属性はDBMS_CLOUD_AIのリファレンスを参照してください。

5.2 DB Linkの表をADB側Viewとして定義する

まず、Select AIへ公開する列だけをViewにします。業務テーブルをそのまま対象にせず、公開列をViewに閉じ込めておくと、不要な列をAI Profileの対象にしないで済みます。

今回のSQL Serverテーブルは、列名を小文字で定義していました。Oracle-managed DB Linkでは、未クォートの列名は大文字として扱われ、ORA-00904になることがあります。その場合は、SQL Server側で定義した表記をダブルクォートで指定し、ADB側Viewでは別名を付けます。

CREATE OR REPLACE VIEW v_mssql_orders AS
SELECT
  "order_id"      AS order_id,
  "customer_name" AS customer_name,
  "product_name"  AS product_name,
  "order_amount"  AS order_amount,
  "order_date"    AS order_date,
  "status"        AS status
FROM dbo.orders@MSSQL_PRIVATE_LINK;
/

5.3 Viewと列に説明を付ける

comments: trueを指定したAI Profileでは、Viewと列のコメントもSelect AIへ渡されます。列名だけでは意味が取りにくい場合や、集計の基準を伝えたい場合に役立ちます。

運用上の注意

comments: trueでは、ここで付与したView・列コメントがLLMに渡るメタデータになります。コメントに個人情報、認証情報、内部コード体系などを記載しないこと、object_listを必要なViewに限定することを運用ルールにします。

COMMENT ON TABLE v_mssql_orders IS
  'SQL Serverの受注データをADBから参照するためのView。1行が1件の受注を表す。';

COMMENT ON COLUMN v_mssql_orders.order_id IS
  '受注を一意に識別するID。';
COMMENT ON COLUMN v_mssql_orders.customer_name IS
  '受注顧客名。';
COMMENT ON COLUMN v_mssql_orders.product_name IS
  '受注した製品またはサービスの名称。';
COMMENT ON COLUMN v_mssql_orders.order_amount IS
  '受注金額。通貨は円。';
COMMENT ON COLUMN v_mssql_orders.order_date IS
  '受注日。';
COMMENT ON COLUMN v_mssql_orders.status IS
  '受注の処理状況。例: 完了、処理中。';

5.4 AI Profileを作成する

今回の検証では、OCI Generative AIのChicagoリージョンとxai.grok-4.3を使用しました。object_listにはDB LinkではなくV_MSSQL_ORDERSを指定し、enforce_object_list: trueでこのView以外を生成SQLの対象から外します。

BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'MSSQL_ORDERS_SELECT_AI',
    attributes   => q'~{
      "provider": "oci",
      "credential_name": "OCI$RESOURCE_PRINCIPAL",
      "region": "us-chicago-1",
      "model": "xai.grok-4.3",
      "comments": true,
      "enforce_object_list": true,
      "additional_instructions": "Use only V_MSSQL_ORDERS. This view contains SQL Server order data accessed through a database link. Use order_amount for monetary totals and averages. Return SQL that only reads data.",
      "object_list": [
        {"owner": "ADMIN", "name": "V_MSSQL_ORDERS"}
      ]
    }~',
    status      => 'ENABLED',
    description => 'Select AI profile for SQL Server orders exposed by V_MSSQL_ORDERS'
  );
END;
/

ownerはViewの所有者です。今回のViewをADMINで作成したためADMINにしています。別スキーマで作成した場合は、そのスキーマ名へ変更します。

同じProfile名がすでに存在する場合、CREATE_PROFILEはエラーになります。再実行する場合は既存Profileを削除するか、別のProfile名を指定してください。

DBMS_CLOUD_AI.GENERATEでは、呼出しごとにprofile_nameを明示します。このため、DBMS_CLOUD_AI.SET_PROFILEでセッションへProfileを設定する必要がなく、ステートレスなクライアントやアプリケーションからも利用できます。

5.5 `DBMS_CLOUD_AI.GENERATE`でSQLを生成・実行する

最初はshowsqlアクションで生成SQLを確認します。質問からV_MSSQL_ORDERSを参照するSELECT文が作られていることを確認します。

SELECT DBMS_CLOUD_AI.GENERATE(
  prompt       => '顧客ごとの受注金額合計を高い順に表示して',
  profile_name => 'MSSQL_ORDERS_SELECT_AI',
  action       => 'showsql'
) AS generated_sql
FROM dual;

今回の検証では、次のSQLが生成されました。対象がADMIN.V_MSSQL_ORDERSに限定され、顧客ごとの受注金額を降順で集計するSQLになっていることを確認できます。

SELECT "o"."CUSTOMER_NAME" AS "顧客名",
       SUM("o"."ORDER_AMOUNT") AS "受注金額合計"
FROM "ADMIN"."V_MSSQL_ORDERS" "o"
GROUP BY "o"."CUSTOMER_NAME"
ORDER BY "受注金額合計" DESC

問題なければ、runsqlアクションで実行します。ADBでViewを参照し、その実行時にDB Linkを経由してSQL Serverのdbo.ordersが読まれます。

SELECT DBMS_CLOUD_AI.GENERATE(
  prompt       => 'ステータスごとの受注件数と受注金額合計を教えて',
  profile_name => 'MSSQL_ORDERS_SELECT_AI',
  action       => 'runsql'
) AS result
FROM dual;

今回はこちらで、次の結果を取得できました。

[
  {
    "ステータス": "完了",
    "受注件数": 1,
    "受注金額合計": 150000
  },
  {
    "ステータス": "処理中",
    "受注件数": 1,
    "受注金額合計": 280000
  }
]

生成SQLの確認と実行を、どちらもDBMS_CLOUD_AI.GENERATEに統一しました。

生成SQLを通常のSQLとして直接実行して確認する場合は、次のとおりです。

SELECT "o"."STATUS" AS "Status",
       COUNT("o"."ORDER_ID") AS "Order_Count",
       SUM("o"."ORDER_AMOUNT") AS "Total_Amount"
FROM "ADMIN"."V_MSSQL_ORDERS" "o"
GROUP BY "o"."STATUS"
ORDER BY "o"."STATUS";

この構成では、Select AIにSQL Serverの接続先や資格情報を持たせる必要はありません。AI Profileが対象として知っているのはADBのV_MSSQL_ORDERSだけで、SQL Serverへの接続は既存のMSSQL_PRIVATE_LINKが担います。

まとめ

今回の構成で目指したのは、SQL ServerをSystem of Recordとして残したまま、ADBをAI／分析のサイドカーとして活用することです。既存の業務アプリケーションやデータモデルを一度に移行しなくても、データ活用の選択肢を段階的に広げられます。

Select AI：ADB側Viewを対象に、SQL Serverに残るデータを自然言語で参照する
Select AI Agent：業務ルールやツール呼出しを組み合わせたエージェント型の利用へ広げる
Oracle Machine Learning（OML）：分析用に整形したデータに対して、SQLやPythonを使ったモデル開発・推論を行う
RAG／AI Vector Search：必要な文書やデータのベクトルをADB側に管理し、検索拡張した生成AIアプリケーションを構成する

また、複数のSQL Serverデータベースを一つのADBへ収斂させれば、顧客やテナントごとに分散しているデータに対して、共通のAI／分析基盤を提供できます。データの所在をすぐに変えずに、横断的な分析、自然言語による問い合わせ、AI機能の適用範囲を広げられる点が、この構成の大きなメリットです。

つまり、データベース移行そのものを目的にするのではなく、既存のSQL Server資産を生かしながら、AIを利用したデータ活用を始めるための選択肢として考えられます。