【環境構築編】既存DBに手を加えずAI活用！OCI上にSelect AI × Sidecar環境を構築する方法

第1回では、既存DBを変更せずに最新のAI機能を手に入れる「Sidecar」構成のメリットを解説しました。第2回となる今回は、いよいよ実践編です。

Oracle Cloud Infrastructure（以下、OCI）上に、データのハブとなる「Oracle Autonomous AI Database（以下、ADB）」を構築し、同じプライベートサブネット内にある既存DBに見立てたBase Database Service（以下、BaseDB）とセキュアに接続します。さらに、専門知識が必要だった複雑な3テーブルの結合クエリを、Select AIを使って「自然言語」で実行する最初の一歩までを、実際の構築手順とともに徹底解説します！

今回の「AIデータ分析基盤」の全体像（環境構成図）がこちらです。
東京リージョン内に、既存DBに見立てたBaseDB、SidecarとなるADB、操作用のComputeを配置します。ADBはBaseDBのデータを参照しながら、Select AIの実行時には大阪リージョンのOCI Generative AI Serviceを利用します。

以下に、それぞれの要素の位置関係と役割を詳細に解説します。

・プライベートサブネット

ここにはBaseDBとADBを配置します。同じサブネット内に置くことで、インターネットを経由しないセキュアなDB Linkによるデータ連携が可能になります。

・パブリックサブネット

プライベートサブネット内のBaseDBとADBを操作するために、パブリックサブネットにCompute（踏み台サーバー）を1台構築します。ここから、BaseDBのテーブルの作成やADBへのSelect AIの設定を行っていきます。

・OCI Generative AI Service

今回は、大規模言語モデル（以下、LLM）としてOCI Generative AI Serviceを利用し、大阪リージョンで処理を行っています。「東京のDBから、なぜわざわざ大阪のLLMを呼び出すの？」 と思われた方もいるかもしれませんが、現時点（2026年6月）において、東京リージョンではOCIの生成AIモデルが使用できません。そのため、後述するAIプロファイルの設定時に大阪リージョンを指定しています。

既存の基幹システムに見立てたBaseDB側には、検証用として3つのテーブルを用意しました。以下に、その構造とサンプルデータを示します。
今回の検証のテーマは、「全社で導入している生成AIツールのアカウントを社員に与えている企業において、『退職済み社員のアカウント』や『全く利用していない社員のアカウント』を特定して、無駄なコストを最適化する」というものです。

次回の【シナリオ実装編】 にて、このテーブル内の情報からSelect AIを使って無駄なコストの最適化を実施していきます。

今回は環境構築編として、メインとなるADBの構築の手順を解説します。
あわせて、ADBからBaseDB上の3つのテーブルを参照できるようにする設定も行います。

OCIのコンソール画面を使って作成手順を解説します。

※この時点でComputeとBaseDBは作成済みであることを想定しています。
　ComputeとBaseDBの作成手順は割愛します。

OCIにサインイン後、左上の「≡マーク」を押下し
Oracle AI Database → Autonomous AI Databaseの順に選択します。

「Autonomous AI Databaseの作成」を押下します。

以下のように選択します。
　表示名：任意のもの
　データベース名：任意のもの
　コンパートメント：任意の場所
　ワークロード・タイプ：「トランザクション処理」

以下のように選択します。
　データベース・バージョンの選択：26ai
　ECPU数：2
　ストレージ：20
　ストレージ単位サイズ：GB

以下のように選択します。
　パスワード：任意のものを入力
　アクセスタイプ：「プライベート・エンドポイント・アクセスのみ」
　　※今回はBaseDBと同じサブネット内からアクセスするため
　仮想クラウド・ネットワーク：BaseDBと同じものを選択
　サブネット：BaseDBと同じものを選択

作成が完了しました。

作成したADBが、BaseDBの中のテーブルを参照できるように設定を行います。 まずは、パブリックサブネット内に作成したCompute（踏み台）から、sqlclを使ってADBに管理者（admin）として接続します。

[opc@bastion ~]$ sql admin/<パスワード>@(description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1521)(host=<ホスト名>))(connect_data=(service_name=<サービス名>))(security=(ssl_server_dn_match=no)))
SQLcl: Release 26.1 Production on Thu Jun 04 05:06:43 2026
Copyright (c) 1982, 2026, Oracle.  All rights reserved.
Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.2.2.0 - Production

（※以降の作業は、すべてADBの adminユーザー で実行します）

ADBにBaseDBのユーザー情報を登録するため、DBMS_CLOUD パッケージの CREATE_CREDENTIAL プロシージャを実行します。

SQL> BEGIN
  2    DBMS_CLOUD.CREATE_CREDENTIAL(
  3      credential_name => 'DBCS_DB_LINK_CRED',
  4      username        => 'SALES',          -- ※BaseDBのスキーマ名（大文字必須）
  5      password        => '<BaseDBのSALESユーザーのパスワード>'
  6    );
  7  END;
  8  /

続いて、同じサブネット内にあるBaseDBを指し示すDB Linkを作成します。今回はプライベート接続にするため、private_target => TRUE を指定するのがポイントです。

SQL> BEGIN
  2    DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
  3      db_link_name       => 'SALES_LINK',   -- 任意のリンク名
  4      hostname           => '<BaseDBノードのFQDNまたはプライベートIP>',
  5      port               => '1521',
  6      service_name       => '<BaseDB内の接続サービス名>',
  7      ssl_server_cert_dn => NULL,
  8      credential_name    => 'DBCS_DB_LINK_CRED', -- 1で作成した資格情報
  9      directory_name     => NULL,
 10      private_target     => TRUE
 11    );
 12  END;
 13  /

最後に以下のコマンドを実行します。ADBからの外向き通信をプライベート・エンドポイントに強制するための設定です。

SQL> ALTER DATABASE PROPERTY SET ROUTE_OUTBOUND_CONNECTIONS = 'PRIVATE_ENDPOINT';

これでBaseDBに接続するための準備がすべて整いました。 実際にADBから既存DBのデータが見えるか、先ほど作成したDB Link（@SALES_LINK）を使ってテストしてみましょう。

SQL> select * from EMP_MASTER@SALES_LINK;
  EMP_ID EMP_NAME       STATUS_CODE
_________ ___________ ______________
      501         A                        1
      502         B                        9
      503         C                        1

BaseDB内のテーブル情報をADBから参照することができました。

ADBの中にビューを作成し、Select AIはそのビューを参照できるようにします。

SQL> CREATE OR REPLACE VIEW EMP_MASTER AS SELECT * FROM EMP_MASTER@SALES_LINK;
 SQL> CREATE OR REPLACE VIEW LICENSE_MASTER  AS SELECT * FROM LICENSE_MASTER@SALES_LINK;
 SQL> CREATE OR REPLACE VIEW USAGE_LOGS AS  SELECT * FROM USAGE_LOGS@SALES_LINK;

本記事の肝であるSelect AIの設定をついに実施していきます。
まず、Select AIに読み込ませる認証情報をOCIコンソールを使って作成します。

再びOCIコンソール画面を使って手順を解説します。

右上の「人マーク」を押下し、ご自身のユーザー名を選択します。

「トークンおよびキー」タブを選択し、「APIキーの追加」を押下します。

「APIキー・ペアの生成」を選択した状態で、「秘密キーのダウンロード」を押下し、ファイルを保存してから「作成」を押下します。
　※ダウンロードした.pemファイルは後ほど使いますので、大切に保管してください。

追加完了後に表示される「構成ファイルのプレビュー画面」の右にある「コピー」を押下し、手元にメモしておきます。

ここからは再びADBの中（Compute上のsqlcl）に戻り、adminユーザーとして設定を進めます。

ADBに先ほど作成したAPIキーを登録します。
再び、DBMS_CLOUD パッケージの CREATE_CREDENTIAL プロシージャを実行します。

SQL> BEGIN
  2      DBMS_CLOUD.CREATE_CREDENTIAL(
  3          credential_name => 'OCI_CRED', -- 任意の名前
  4          user_ocid       => 'ocid1.user.oc1..XXXXX',  -- ユーザーのOCID
  5          tenancy_ocid    => 'ocid1.tenancy.oc1..YYYY', -- テナンシのOCID
  6          private_key     => '-----BEGIN PRIVATE KEY-----
  7                              MIIE...<中略>...CzA==
  8                              -----END PRIVATE KEY-----',
  9          fingerprint     => 'xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
 10      );
 11  END;
 12* /

user_ocid、tenancy_ocid、fingerprint には、先ほどメモした「構成ファイルのプレビュー」の値を貼り付けます。 private_key には、ダウンロードした秘密キー（.pemファイル）をテキストエディタで開き、中身をそのままコピペしてください。

次に、LLMのモデルや対象とするテーブル（ビュー）を定義した「AIプロファイル」を作成します。

SQL> BEGIN
  2      DBMS_CLOUD_AI.CREATE_PROFILE(
  3          'ai_profile' , -- 任意の名前
  4          '{
  5              "provider": "oci",
  6              "credential_name": "OCI_CRED", 
  7              "model":"openai.gpt-oss-120b",
  8              "region": "ap-osaka-1", -- 大阪リージョンを指定
  9              "object_list": [
 10                      {"owner": "admin", "name": "EMP_MASTER"}, 
 11                      {"owner": "admin", "name": "LICENSE_MASTER"},
 12                      {"owner": "admin", "name": "USAGE_LOGS"}
 13              ]
 14          }'
 15      );
 16  END;
 17  /

今回LLMの処理は大阪リージョン上で行うため、"region": "ap-osaka-1" を明示的に指定しています。また、大阪リージョンで利用可能なモデル（openai.gpt-oss-120b）を指定します。

作成したプロファイルは、現在のセッションで有効化しなければ使えません。最後に以下のプロシージャを実行します。

SQL> EXEC DBMS_CLOUD_AI.SET_PROFILE('ai_profile');

すべての準備が整いました！
それでは、Select AIを使って、基幹DB内のデータへ「日本語」で問いかけてみましょう。

SQL> SELECT AI 従業員の情報を表示してください;
   EMP_ID    STATUS_CODE EMP_NAME
_________ ______________ ___________
      501              1 　　　　　　A
      502              9 　　　　　　B
      503              1 　　　　　　C

見事に返ってきました！

入力したのは日本語の指示だけですが、ADBがAIと連携して裏側でSQLを生成し、プライベートネットワーク越しにBaseDBのデータを取得してくれました。

Select AIには、デフォルトの問い合わせ以外にも、実行時にキーワード（アクション）を指定することで様々な振る舞いをさせることができます。

いくつか実際に実行してみましょう。

SQL> SELECT AI showsql 従業員の情報を表示してください;
RESPONSE
______________________________________
SELECT
  e."EMP_ID" AS "EMP_ID",
  e."STATUS_CODE" AS "STATUS_CODE",
  e."EMP_NAME" AS "EMP_NAME"
FROM
  "ADMIN"."EMP_MASTER" e

SQL> SELECT AI narrate 従業員の情報を表示してください;
RESPONSE
_________________________________________________________________________
- 従業員ID 501 は、ステータスコードが 1 で、名前は「A」です。
- 従業員ID 502 は、ステータスコードが 9 で、名前は「B」です。
- 従業員ID 503 は、ステータスコードが 1 で、名前は「C」です。
「EMP_ID」は従業員を識別する番号、「STATUS_CODE」は従業員の状態や区分を示すコード、「EMP_NAME」は従業員の名前です。

お疲れさまでした！これでOCI上に「AIデータ分析基盤」の骨組みが完成しました。

今回の構築で最も重要なのは、「既存の基幹DBには設定変更もデータ追加も一切行わず、安全な閉域網（プライベートサブネット）の中で最新のAIを利用できた」という点です。既存環境への影響を抑えながらAI活用を試せる、現実的なアプローチであることを実感いただけたのではないでしょうか。

しかし、今のSelect AIは、いわば「言葉は通じるけれど、自社の業務ルール（文脈）をまだ知らない」状態です。今回作成した「3つのテーブルの複雑な関係性」をAIが理解するには、もう一工夫が必要です。

次回はいよいよ本連載のハイライト【シナリオ実装編】です！ このSidecar構成に「アノテーション（文脈）」という名の知恵を与えます。専門知識がなければ書けなかった3テーブルを結合したクエリを、日本語の問いかけだけで問い合わせる様子をお届けします。