はじめに
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を利用したデータ活用を始めるための選択肢として考えられます。