Autonomous Database Select AI

解決する課題

データに答えがあるのに、SQL を書けない利用者やスキーマを知らない利用者は問い合わせられません。Select AI は、Autonomous Database に対して自然言語の質問をそのまま投げると LLM が SQL を生成・実行し、結果を返す仕組みを SQL の中に組み込みます。BI ツールや独自のチャット UI を作り込まなくても、データベース側で自然言語インターフェースを提供できるのが価値です。

• SQL を書けない業務ユーザーにも自然言語でデータを問い合わせさせたい
• アプリにLLM ベースのチャットや要約を、別基盤を立てずに組み込みたい
• 社内文書やデータに基づく回答（RAG）を、ベクトル検索とまとめて使いたい
• LLM 利用を Autonomous Database の IAM・ネットワーク・監査の枠内で統制したい
• 既存の SQL/アプリ資産から、最小の追加コードで生成 AI を呼びたい

AWS では Amazon Bedrock とデータソースを自前で連携させる構成、Azure では Azure OpenAI の「on your data」に近い位置づけですが、Select AI はデータベース自身が NL2SQL とプロンプト実行を担う点が特徴です。

主要概念と用語

• Select AI: Autonomous Database に組み込まれた機能で、自然言語プロンプトを SQL 変換・チャット・要約・RAG に橋渡しする。専用の SELECT AI 構文や DBMS_CLOUD_AI パッケージから呼ぶ
• AI プロファイル（AI Profile）: 利用する LLM プロバイダ・モデル・対象スキーマ（テーブル/ビュー）などをまとめた設定。DBMS_CLOUD_AI.CREATE_PROFILE で作成し、セッションで有効化する
• NL2SQL（自然言語からの SQL 生成）: 質問とスキーマのメタデータを LLM に渡し、実行可能な SQL を生成する処理。SELECT AI のデフォルト動作
• アクション（action）: プロンプトの扱い方の指定。runsql（生成して実行）、showsql（SQL を表示）、explainsql（説明）、narrate（結果を自然言語で説明）、chat（一般的なチャット）など
• LLM プロバイダ: 実際の生成を担う外部サービス（OCI Generative AI や他社の生成 AI など）。プロファイルで指定し、資格情報を介して呼ぶ
• 資格情報（Credential）: 外部 LLM プロバイダへ接続するための認証情報。DBMS_CLOUD.CREATE_CREDENTIAL などで作成し、プロファイルから参照する
• メタデータ（スキーマ情報）: テーブル名・列名・コメントなど、LLM が正しい SQL を書くための文脈。プロファイルの対象オブジェクトとして与える
• RAG（検索拡張生成）: ベクトルストアで関連文書を検索し、その内容をプロンプトに添えて回答の根拠を補強する手法。Select AI は Oracle Database のベクトル検索と組み合わせて利用する
• ベクトルストア / 埋め込み: 文書をベクトル化して保存・近傍検索する仕組み。RAG の検索側を担う
• Autonomous Database: フルマネージドの自律型データベース。Select AI はその上で動く機能で、別途インフラを用意しない

仕様・制限・クォータ

• Select AI は Autonomous Database（Serverless など）の機能として提供され、対応バージョン／構成での利用が前提になる。利用可否はリージョンや構成に依存する
• 実際の生成は外部の LLM プロバイダが担うため、利用には資格情報の設定とプロバイダ側の利用条件・上限が関わる。使えるモデルやプロバイダは時期・リージョンで変わりうる
• NL2SQL の精度は与えるメタデータの質に大きく左右される。列コメントや適切なオブジェクト選択がないと、誤った SQL を生成しやすい
• LLM に渡せる**コンテキスト長（トークン上限）**があり、対象スキーマが大きすぎると全テーブルを文脈に入れられない。プロファイルで対象オブジェクトを絞る必要がある
• 生成 SQL は実行ユーザーの権限で動くため、参照できないデータは返らない。逆に権限設計を誤ると意図しない参照を許す
• プロンプトやレスポンスに関わるレート・データ量の上限はプロバイダおよびデータベースの構成に従う。具体的な数値は変動するため公式ドキュメントで確認する

内部の仕組み

Select AI は、ユーザーの自然言語プロンプトと、AI プロファイルで指定されたスキーマのメタデータを組み合わせて LLM に送り、返ってきた SQL をそのデータベース上で実行して結果を返します。生成と実行がデータベース内で完結するのが要点です。

• セッションで AI プロファイルを有効化すると、SELECT AI ... 構文や DBMS_CLOUD_AI で渡したプロンプトが、プロファイルのプロバイダ・モデル設定に従って処理される
• NL2SQL（runsql）: 質問＋対象オブジェクトのメタデータをプロンプトとして LLM に送り、生成された SQL をデータベースが実行して結果セットを返す
• showsql / explainsql: SQL を実行せずに、生成された SQL や、その意図の説明を返す。検証やデバッグに使う
• narrate: SQL を実行した結果を、LLM が自然言語で説明し直して返す
• chat: スキーマに依存しない一般的な質問を、そのまま LLM に投げて回答を得る
• RAG: ベクトルストアで関連文書を検索し、その断片をプロンプトに添えて回答させる。検索（ベクトル）と生成（LLM）を組み合わせて、データに根ざした回答を作る
• 外部 LLM への接続は資格情報を介して行われ、ネットワーク経路はデータベースの構成（プライベート/パブリック、サービスゲートウェイ等）に従う

設計パターン / ベストプラクティス

• 対象オブジェクトを絞る: プロファイルには質問対象に必要なテーブル/ビューだけを含め、コンテキスト長と誤生成を抑える。広いスキーマには用途別ビューを用意して対象にする
• メタデータを充実させる: 列コメントやわかりやすいオブジェクト名を整え、LLM が正しい結合・絞り込みを書けるようにする。略称だけの列は誤解されやすい
• まず showsql で検証: 新しいプロンプトや重要な集計は、いきなり実行せず生成 SQL を確認してから runsql に切り替える
• 最小権限のユーザーで実行: Select AI を呼ぶスキーマ／ユーザーには、参照を許すデータだけにアクセス権を与える。生成 SQL はその権限内でしか動かない
• RAG とファインチューニングを切り分ける: 社内文書に基づく回答はまず RAG（ベクトル検索＋プロンプト添付）で実現し、モデルのカスタム学習は別途検討する
• プロバイダ/モデルを設定値に: プロファイルでプロバイダ・モデルを管理し、世代交代や切り替えに追従できるようにする

運用・監視

• 生成 AI 呼び出しを含むデータベースの稼働状況は OCI Monitoringで追跡し、Autonomous Database のメトリクスとあわせて見る
• 誰がいつプロファイルを作成・変更したか、どの資格情報を使ったかは OCI Audit やデータベース監査で追跡する
• 外部 LLM プロバイダへの到達不可・タイムアウト・認証エラーは、資格情報の失効やネットワーク経路（プライベート構成での経路不足）を疑う
• NL2SQL の精度低下や誤生成が続く場合は、対象オブジェクトの見直し・列コメントの追加・プロンプトの明確化で対処する
• プロンプト/レスポンスのやり取りは外部プロバイダへ送信される点を運用ルールに明記し、送信内容（機微データを含めない）を統制する
• LLM 利用のコストとトークン消費は呼び出し量に比例するため、想定外の大量呼び出しを監視する

コスト

Select AI 機能自体は Autonomous Database の利用に含まれますが、実体としての費用は Autonomous Database の稼働コスト と 外部 LLM プロバイダの推論コスト に分かれます。生成 AI の呼び出し回数とトークン量が増えるほどプロバイダ側のコストが増える点が主因です。具体的な単価はプロバイダ・モデル・時期で変動するため、公式の価格表で確認してください。

セキュリティ

• 外部 LLM への接続は**資格情報（Credential）**として管理し、平文の鍵をアプリやコードに埋め込まない。失効・ローテーションを運用に組み込む
• アクセス制御は OCI IAM とデータベースの権限で行い、プロファイル作成・利用を許すユーザーを限定する。生成 SQL は実行ユーザーの権限内でしか動かないため、最小権限を徹底する
• プロンプトや対象データの一部は外部プロバイダへ送信されうる。機微情報・個人情報を不用意にプロンプトへ含めないよう入力を統制し、必要に応じてマスキングする
• 通信は TLS で保護される。プライベート構成ではサービスゲートウェイやプライベートエンドポイントで OCI/データベースのネットワーク内に経路を閉じる
• 操作は OCI Audit とデータベース監査に記録され、コンプライアンス上の追跡が可能
• RAG で参照するベクトルストアや元文書のアクセス制御・暗号化も併せて最小化する

関連サービス・比較

Select AI は OCI Generative AI をはじめとする LLM プロバイダを「呼ぶ側」で、自身は Autonomous Database の機能としてデータと自然言語をつなぎます。生成 AI の基盤モデルそのものを API で使いたいなら Generative AI、データベース上で自然言語問い合わせや RAG を完結させたいなら Select AI、という棲み分けです。下表は Select AI と、自前で同等の自然言語データ問い合わせを組む AWS 側構成の対応です。

ハンズオン / CLI例

Select AI の設定・利用は SQL（DBMS_CLOUD_AI と SELECT AI 構文）で行いますが、その前提となる Autonomous Database の確認は oci CLI で行えます。以下は CLI とプロファイル設定 SQL の最小例です。

# 1) コンパートメント内の Autonomous Database を一覧し、対象 DB を確認する
oci db autonomous-database list \
  --compartment-id "$COMPARTMENT_OCID" \
  --query 'data[].{name:"db-name",state:"lifecycle-state",ocid:id}' \
  --output table

# 2) 対象 Autonomous Database の詳細（状態・接続情報など）を取得する
oci db autonomous-database get \
  --autonomous-database-id "$ADB_OCID"

# 3) DB 内では SQL で Select AI を設定・利用する（参考: SQL 側の最小例）
#    -- 外部 LLM への資格情報を作成（鍵はハードコードせず資格情報として管理）
#    -- BEGIN DBMS_CLOUD.CREATE_CREDENTIAL(credential_name=>'GENAI_CRED', ...); END;
#    -- AI プロファイルを作成（プロバイダ・モデル・対象オブジェクトを指定）
#    -- BEGIN DBMS_CLOUD_AI.CREATE_PROFILE(profile_name=>'SALES_AI', attributes=>'{...}'); END;
#    -- セッションでプロファイルを有効化して自然言語で問い合わせる
#    -- EXEC DBMS_CLOUD_AI.SET_PROFILE('SALES_AI');
#    -- SELECT AI showsql 先月の売上が最も多い製品は;
#    -- SELECT AI runsql  先月の売上が最も多い製品は;