はじめに
こんにちは！富士ソフトでデータエンジニアを担当している左手です。
データ活用が進んでいく近年、このような悩みを抱えていませんか？
「異なるシステムのデータを組み合わせて分析したいが、都度ETLパイプラインを構築する必要があり、開発コストや時間がかかる・・・」
「SQLが書けない現場担当者でも、複数のデータベースにまたがって情報を確認できる仕組みが欲しい・・・」
こうした課題の解決策として注目しているのが、Oracle Autonomous AI Database（以下、Oracle ADB）の「SELECT AI」機能です。SELECT AIを活用すると、データを物理的に移動させることなく、Oracle ADB と Snowflakeをはじめとする外部データソースをまたいだ自然言語照会が実現できます。
本記事では、SELECT AI機能とSidecar構成に着目し、概要から実際の検証結果・考察までをご紹介します。
Oracle Autonomous AI Database の SELECT AI とは？
Oracle ADBは、Oracle Cloud Infrastructure（OCI）上で提供されるフルマネージドなデータベースサービスです。自律的な性能チューニングやセキュリティパッチの自動適用など、運用負荷を大幅に削減する機能を標準で備えています。
この Oracle ADB に搭載されている機能の一つが「SELECT AI」です。SELECT AIでは、自然言語（日本語を含む）で入力した問い合わせを AI が自動的に SQL へ変換してクエリを実行します。エンドユーザーは SQL構文を意識することなく、質問形式でデータにアクセスできます。
「SELECT AI」が実現する外部データソース接続（Sidecar）とは？
Oracle ADBには、「AI Proxy Database for Select AI」と呼ばれる機能が提供されています。マニュアル上では「Sidecar」とも呼ばれており、本記事では以降この構成を「Sidecar構成」と表記します。
Sidecar構成とは、SELECT AIが外部のデータベースやSaaSサービスへ接続するための接続構成コンセプトの名称です。SnowflakeをはじめとするクラウドDWH、各種RDB、Salesforceなどのサービスへの接続機能が豊富に用意されている点が特長です。
この仕組みを活用することで、Oracle ADBを起点に、外部データソースへのフェデレーションクエリ（複数のデータソースをまたいで発行するクエリ）を実行できます。つまりユーザーは、データがどのシステムにあるかを意識することなく、1つの問いかけで複数のDBに横断アクセスできます。
今回の検証では、外部データソースとしてSnowflakeを利用しました。構成のイメージは以下のとおりです。
OCI上に構築したOracle ADBのSELECT AI と Sidecar構成を組み合わせることで、ユーザーはデータの所在を意識せずシームレスに問合せできます。なお、本機能はOCI上のOracle ADB固有の機能です。
2026年3月時点でSidecar構成はSnowflake以外にも対応しており、Oracle管理の異機種間接続（DB Link）を使用した場合は、以下のデータソースへの接続が可能です。最新情報は下記公式ドキュメントをご確認ください。
参考：Oracle公式ドキュメント - AIプロキシデータベースを使用した Select AI NL2SQL
| カテゴリ | 対応外部データソース（例） |
|---|---|
| クラウドDWH | Snowflake、Amazon Redshift、Google BigQuery、Databricks |
| RDB（オンプレ・クラウド） | PostgreSQL、MySQL、SQL Server、Azure SQL、DB2、Teradata |
| その他 | Salesforce、Oracle ADB（別インスタンス）など |
Oracle ADB が「自然言語からSQLへの変換」と「異なるDBへの横断クエリ」の両方を担うためデータ活用のハードルを下げることが期待できます。
今回の検証シナリオ：家電量販店のカスタマーサポート業務
「Sidecar構成＋SELECT AI機能」の有効性を検証するため、今回は家電量販店のカスタマーサポート業務を想定したシナリオで検証を行いました。
背景
「FSI家電」では、販売管理システムはOracle ADB、カスタマーサポートシステムはSnowflakeで運用されています。部門ごとに最適なシステムを選択した結果、データは複数の基盤に分散しています。
課題
カスタマーサポート担当者が顧客対応に必要な情報（顧客情報・購入履歴・保証状況・過去の問い合わせ履歴）を参照するには、複数システムにアクセスし、Excelでデータを突き合わせる手作業が必要です。これにより、顧客対応中のリアルタイムな情報照会が困難になっていました。
カスタマーサポート品質向上のための横断的な分析を迅速に進めたいと考えていましたが、それを実現するためにはETLツールの導入・開発コストや、その後の運用・保守にかかる管理負荷が見込まれていました。
担当者間で、分析にかかるスキルに差が生まれており、初心者でも対象のデータを見つけられるような仕組みが整備されていませんでした。
データ構成
検証で使用したテーブル構成は以下のとおりです。
| DB | テーブル名 | 概要 |
|---|---|---|
| Oracle ADB | 顧客マスタ | 顧客名、会員レベル、連絡先など |
| 購入履歴 | 購入日、店舗名、製品IDなど | |
| 保証情報履歴 | 保証状態（VALID／EXPIRED）、保証期限など | |
| Snowflake | 製品マスタ | 製品カテゴリ、ブランド名など |
| 問い合わせ履歴 | 問い合わせ種別、問い合わせ内容など | |
| 修理履歴 | 修理種別（FREE：無償／CHARGE：有償）、交換部品など |
SELECT AIとSidecar構成のセットアップ手順
SELECT AIとSidecar構成を使用するには、主に3つの手順が必要です。
- 外部データソースへのデータベースリンク（DB Link）の構築
- DB Link経由のビューの作成
- 接続認証情報（CREDENTIAL）とSELECT AI プロファイルの作成
Oracle ADBには、外部データソースとDB Linkで連携するための「Oracle管理の異機種間接続（Oracle Managed Heterogeneous Connectivity）」という機能が備わっています。この機能では、OCI側がProgress DataDirectコネクタを通じて接続基盤を管理・提供するため、利用者がドライバを個別にインストールしたり、専用のゲートウェイVMを自前で構築したりする必要がありません。接続はエンドツーエンドで暗号化され、Snowflakeをはじめとした各種外部データソースへの安全な接続が可能です。
参考：Oracle公式ドキュメント - Oracle管理の異種間接続によるOracle以外のデータベースへのデータベース・リンクの作成
外部のデータソースを参照するために、SELECT AIのプロファイルには直接の外部テーブルを登録するのではなく、DB Link経由で作成したビューを登録します。
SELECT AIを使用するには、AIモデルに接続するための接続認証情報と、AIが検索対象とするテーブル・ビューを定義するプロファイルを作成する必要があります。プロファイルとはSELECT AIが参照するデータソースを一元管理する設定で、Oracle ADB内のテーブルとSTEP 2で作成したビューを同じプロファイルの中に登録します。
SELECT AI の使い方：RUNSQL と SHOWSQL
SELECT AIでデータを照会するにはDBMS_CLOUD_AI.GENERATEプロシージャを使用し、以下ACTIONパラメータを指定できます。
・RUNSQL：自然言語をSQLに変換して実行した結果データを取得します。
・SHOWSQL：SELECT AIが生成したSQL文そのものを表示します。
今回の検証ではRUNSQLとSHOWSQLをそれぞれ以下のように使用することによって、RUNSQLで結果を確認し、SHOWSQLで生成されたSQL内容のチェックを行い、動作理解やデバッグを容易なものとしました。
-- RUNSQL: 自然言語をSQLに変換し、実行結果（テーブルデータ）を返す SELECT DBMS_CLOUD_AI.GENERATE(prompt => '田中太郎の購入履歴を表示', profile_name => '--プロファイル名--', action => 'RUNSQL') FROM dual; -- SHOWSQL: 生成されたSQL文そのものを表示する（開発・デバッグ時に有効） SELECT DBMS_CLOUD_AI.GENERATE(prompt => '田中太郎の購入履歴を表示', profile_name => '--プロファイル名--', action => 'SHOWSQL') FROM dual;
それぞれの実行結果はこのようになります。
SELECT AIでプロンプトを用いて問い合わせ結果は下記のようになります。
ACTIONパラメータ「RUNSQL」時の結果
DBMS_CLOUD_AI.GENERATE(PROMPT=>'田中太郎の購入履歴を表示',PROFILE_NAME=>'--プロファイル名--',ACTION=>'RUNSQL')
----------------------------------------------------------------------------------------------------
[
{ "製品ID" : "PRD002", "製品名" : "4K Smart Display 27", "保証状態" : "VALID", "保証開始日" : "2024-10-21T00:00:00.000000Z", "保証終了日" : "2027-10-21T00:00:00.000000Z" },
{ "製品ID" : "PRD003", "製品名" : "Wireless Ergonomic Mouse", "保証状態" : "VALID", "保証開始日" : "2024-06-29T00:00:00.000000Z", "保証終了日" : "2026-06-09T00:00:00.000000Z" },
{ "製品ID" : "PRD005", "製品名" : "Antivirus Pro 1-Year License", "保証状態" : "VALID", "保証開始日" : "2024-12-09T00:00:00.000000Z", "保証終了日" : "2027-12-09T00:00:00.000000Z" }
]
Elapsed: 00:00:04.047
1行が選択されました。
ACTIONパラメータ「SHOWSQL」時の結果
DBMS_CLOUD_AI.GENERATE(PROMPT=>'田中太郎の購入履歴を表示',PROFILE_NAME=>'--プロファイル名--',ACTION=>'SHOWSQL')
----------------------------------------------------------------------------------------------------
SELECT
P.PURCHASE_ID,
P.UPDATED_AT,
P.CREATED_AT,
P.WARRANTY_MONTHS,
P.PRICE,
P.STORE_NAME,
P.PURCHASE_DATE,
P.PRODUCT_ID
FROM "SATE"."PURCHASE_HISTORY_10001" P
INNER JOIN "SATE"."CUSTOMERS_10001" C
ON P.CUSTOMER_ID = C.CUSTOMER_ID
WHERE UPPER(C.CUSTOMER_NAME) = UPPER('田中太郎')
Elapsed: 00:00:03.799
1行が選択されました。
双方共通して、PROMPTには問い合わせ文が、PROFILE_NAMEにはSTEP 3で設定したプロファイルが指定されます。
これにより、Oracle ADBとSnowflakeをまたいだクエリが1つのプロシージャ呼び出しで実行されます。
以上で環境構築と基本動作の確認が完了しました。
SELECT AIとSidecar構成を用いた検証：アノテーションで精度はどこまで上がるか
ここまで構築した環境を用いて、想定ユースケースにおける自然言語照会の回答精度を検証します。
自然言語照会の精度を向上させるためには、データベースのテーブルやカラムにメタデータ（データのための補足データ）を付与し、AIが検索対象のデータを正しく理解できるよう意味付けを行うことが重要です。
たとえば「ゴールド会員」という日本語表現とデータ上の値「GOLD」の対応関係は、アノテーション（メタデータ）として明示することで、AIがデータを正しく認識できるようになります。
本検証ではOracle ADB で利用可能な「ANNOTATIONS型」のアノテーション機能を使用いたしました。
こちらの機能を採用した背景として、SELECT AIへのメタデータ付与方法についてOracle社に確認した結果、「ANNOTATIONS型」による付与がSELECT AIとの親和性が高く、推奨される方法であるとの回答を得たことが挙げられます。
Oracle ADBでは、上記機能によってメタデータ付与を実現できます。
今回の検証の流れ
検証の評価指標は、SELECT AIが生成したSQLが想定通りの構文となっているかを示す「生成されたクエリの正しさ」と「応答時間（秒）」の2軸としました。
「生成されたクエリの正しさ」については、下記のような3段階で評価しています。
| 判定 | クエリの状態 | 判定基準 |
|---|---|---|
| ○ | 適切なクエリ | 意図した結果を正確に返すSQLが生成された。不要な条件や欠落がなく、結果が期待どおり一致している |
| △ | 部分的・冗長なクエリ | SQLは実行できるが、条件が冗長・過不足あり、または結果の一部が欠けている・余分なデータが含まれるなど精度にばらつきがある |
| × | 不正なクエリ | 意図した結果と異なるSQLが生成された。カラムや条件の認識が誤っており、結果が期待と一致しない |
Phase 1：アノテーション付与なしの状態から自然言語で問い合わせを実施（ベースライン検証）
下記のようなデータパターンを想定してテーブル設計とデータを投入し、SELECT AIを使用した自然言語の問い合わせを10問実施しました。なお、質問の一部はあえて抽象的な表現を含む形にしており、アノテーションなし状態でどこまで認識できるかを意図的に確認しています。
アノテーションなしの状態で実施し、以下の傾向が確認できました。検証した質問の一例を以下に示します。
| No | 質問（自然言語） | 判定 | 結果の概要 |
|---|---|---|---|
| 1 | ゴールド会員の顧客数は？ | × | 「ゴールド会員」という日本語業務用語を認識できず、誤ったSQLが生成された |
| 2 | 田中太郎さんの購入履歴を表示してください | ○ | 顧客名での検索とJOIN処理を正しく実施。Oracle ADB内のデータを正確に照会できた |
| 3 | 過去3ヶ月の購入者で問い合わせありのものは？ | △ | Oracle ADBとSnowflakeの横断JOINは実行できたが、出力項目が意図と一部ずれていた |
【検証結果】
No.2のように条件がシンプルであり、組み立てが容易な質問は正確に動作しました。一方でNo.1のような業務特有の日本語表現（ゴールド会員＝GOLD）はアノテーションなしでは変換できず、アノテーション設計の必要性が明確になりました。
Phase 2：アノテーション付与を通してデータに意味付けを行い、同じ質問で再検証
Phase 1 の結果から、日本語業務用語と DB 値の対応付けができないことが最大の課題とわかりました。
そこで、 Oracle ADB で利用可能な「ANNOTATIONS型」を使い、テーブルやビュー、またそれらに含まれているカラムにアノテーションを付与し、以下の対比で効果を確認しました。
| No | 質問 | アノテーションなし （Phase 1） |
アノテーションあり （Phase 2） |
|---|---|---|---|
| 1 | ゴールド会員の顧客数は？ | ×：「ゴールド会員」を認識できず誤ったSQLが生成された | ○：「ゴールド会員＝GOLD」の対応を認識し、正確なSQLが生成された |
| 3 | 過去3ヶ月の購入者で問い合わせありのものは？ | △：横断JOINは実行できたが出力項目が一部ずれていた | ○：Oracle ADBとSnowflakeの横断JOINが正確に実行され、出力項目も期待通りとなった |
【検証結果】
Q1の「ゴールド会員→GOLD」のように、アノテーションによって日本語業務用語とDB値の変換に成功しました。
アノテーション設計の質が SELECT AI の精度に直結することが確認できました。
また、平均応答するまでの速度の向上も確認できました。
考察：アノテーション設計が精度を左右する
今回の検証で最も明確になったのは「アノテーション設計がSELECT AIの精度に直結する」という点です。適切に設計されたアノテーションは、AIが自然言語とDBの値を橋渡しする「地図」として機能します。
一方で、複数テーブルの横断JOIN＋期間指定のような複合条件クエリは、条件の複合度が上がるほど生成されるSQLにばらつきが生じやすい傾向があるため、アノテーションの充実に加え、クエリ対象のデータ構造をあらかじめシンプルに整えておく設計アプローチも、精度向上に有効な対策となります。
まとめ
本記事では、Oracle ADB の SELECT AI および Sidecar構成を活用した自然言語データ照会の検証手順と検証結果、回答精度の向上方法をご紹介しました。Sidecar構成を活用することで、Oracle ADBとSnowflakeをはじめとした各種データソースを横断したデータ照会を可能とし、SELECT AI機能を使って自然言語検索によるデータ活用の民主化（誰もが簡単にデータを活用できる仕組み）を実現することが期待できます。
データの民主化とは？ 初心者でもわかる基礎から実践まで徹底解説
「SQLを書かずにデータに質問できる」体験はデータ活用のすそ野を広げる大きな可能性を持っています。その精度を最大化するカギは、DBのメタデータ設計という「準備の工程」にあります。（Oracle ADBではANNOTATIONS機能がこれに相当します）
富士ソフトでは、データ基盤構築からデータ連携・AI活用・可視化まで、組織のデータ利活用を強力に推進するご支援しています。
Snowflake・データ分析基盤構築の経験・検証（PoC）の経験を活かし、以下のようなお悩みに対応しています。
- 「データ基盤を新規で構築したい、または刷新したい」
- 「SQL が書けない現場担当者でもデータを活用できる仕組みを作りたい」
- 「データ基盤のメタデータ設計のサポートをしてほしい」
お客様の業務やデータ特性に合わせた PoC や導入支援も承っております。
本記事がデータ活用・AI活用を次のステージへ進めるきっかけとなれば幸いです。
※留意事項 (2026年3月時点)
本記事の検証内容は2026年3月時点の環境をもとにしています。製品のバージョンアップにより、機能や挙動が変更される場合があります。また、Select AI の精度はアノテーション内容や使用する AI モデル、データ構造により異なります。本記事の結果は参考値としてご利用ください。
