Oracle AI Data Platform(AIDP)：Private Endpointの AI Lakehouseで Knowledge Base・RAG検索してみてみた

Oracle AI Data Platform（AIDP） では、Knowledge BaseやAgentなどのAI機能を利用するために、Oracle Autonomous AI Lakehouse（AI Lakehouse） を関連付けます。このAI Lakehouseは、Knowledge Baseのベクトル保存・検索を担います。

このAI LakehouseをPrivate Endpointのみの構成にした場合、どのWorkspaceでComputeを作成すればよいのでしょうか。公開ドキュメントを確認した範囲では、この構成でのAI Compute作成条件を読み取れなかったため、実際にAIDPの作成から文書取り込み、RAG検索まで試してみることにしました。

今回は、このAI Lakehouseを「プライベート・エンドポイント・アクセスのみ」に設定しました。パブリック・アクセスを無効にした状態で、AIDPの作成から文書の取り込み、RAGツールによる検索・回答生成まで確認します。

ということで Private EndpointのみのAI LakehouseをAIDPに関連付けて、RAG検索までしてみてみます。

今回の環境では、以下を確認できました。

確認項目	結果
既存のPrivate EndpointのみのLakehouseを指定してAIDPを作成	成功
初期化時のユーザー・スキーマ作成、モデルロード	NotificationsでSuccessを確認
Knowledge BaseへのTXTファイル取り込み	Succeeded、Files added：1
既定WorkspaceでAI Computeを作成	Subnet不一致を示すエラーで拒否
Lakehouseと同じSubnetのPrivate WorkspaceでAI Computeを作成	成功
RAGツールのGUIからKBを選択	プルダウンが反応せず選択できなかった
JSONでKBを指定してRAGツールをテスト	成功。確認コード・担当者・参照元文書を取得
AI Lakehouse内の保存データをSQLで確認	別SubnetのOracle Linux Computeから接続し、テスト文書の本文と、384次元・FLOAT32のベクトルを同じ行で確認

今回のポイントは、AI Computeを作成するWorkspaceのネットワーク設定です。 Private EndpointのみのAI Lakehouseを関連付けた場合、AI Computeの作成先には、AI Lakehouseと同じSubnetを設定したPrivate Workspaceを使用します。

以降は、2026年10月の検証環境での画面・操作を紹介します。

■ 構成と各リソースの役割

● 今回使用したリソース

項目	検証時の値
AIDP名	Private-AIDP
Lakehouse表示名	AI-Lakehouse
LakehouseのDB名	CDB
DBバージョン	26ai
アクセス方式	プライベート・エンドポイント・アクセスのみ
パブリック・アクセス	無効
相互TLS（mTLS）認証	不要
VCN	VCN-10.100.0.0
Subnet	Client-Subnet
LakehouseのPrivate Endpoint IP	10.100.1.193
Lakehouse側NSG	NSG-ALH
AIDP側NSG	NSG-AIDP
SQL確認用Compute	AI Lakehouseとは異なるSubnetに配置したOracle Linux Compute
既定Workspace	Workspace：Private Network無効
自動作成されたPrivate Workspace	Pvt_vector_db_CDB：上記VCN・Subnetを設定
標準カタログ／スキーマ	default／default
Volume	vol_aal_test
Knowledge Base	kb_aal_connection_test2
Private Workspace内のSpark Cluster	Cluster1
Sparkバージョン	3.5.0（検証時の選択肢はこの1種類）
AI Compute	ai_compute_aal_test
Agent project	agent_aal_connection_test

リソース名・IPアドレスは検証時の値です。再現時は利用環境の値へ読み替えます。Subnet名だけではなく、LakehouseとWorkspaceが参照するSubnet OCIDの一致も確認します。

● 処理と保存先

構成要素	役割
Volume／OCI Object Storage	原本のTXTを保存
Spark Compute	文書の読み取り・チャンク化などの取り込み処理を実行
AIDPに関連付けたAI Lakehouse	文書チャンクの本文とベクトルを保存し、Oracle Database 26ai Vector Searchで検索
AI Compute	Agent・RAGツールを実行
OCI Generative AIのLLM	取得した文書を使って回答を生成

Workspaceは、Notebook・Compute・Agentなどをまとめる論理的な単位です。Private Workspaceでは、データソースへの接続に使用するVCN・Subnetなどを設定します。AI Lakehouse側では、指定したSubnetにPrivate Endpointが作成されます。

また、取り込み用のSpark Computeと、Agent・RAGツールを実行するAI Computeは別リソースです。文書を取り込む段階と、取り込んだ文書を検索する段階で、それぞれのComputeを使用します。

本記事で設定するのは、WorkspaceからPrivateなデータソースへ接続するためのネットワークです。AIDP自身へのアクセスをPrivate化するPrivate Service Access（PSA）の構成は、本検証の対象に含めていません。

なお、AIDP名のPrivate-AIDPは今回付けた任意の名称です。この名称がAIDP自身のPrivateアクセス構成を示すわけではありません。

■ 事前確認とAIDP作成

1) Lakehouseのネットワークを確認する

OCIコンソールから対象のAutonomous AI Lakehouseを開きます。

• DBバージョンが26ai以上であることを確認します。
• ネットワーク・アクセスを「プライベート・エンドポイント・アクセスのみ」にします。
• VCN、Subnet、Private Endpoint IP、NSGを控えます。
• 「パブリック・アクセス」が無効であることを確認します。
• 接続に必要なNSG／Security Listルールを確認します。

NSG／Security Listでは、Private Workspace側からAI Lakehouseへ必要な接続を許可します。同じSubnetやNSGの指定だけで通信が自動許可されるわけではありません。ネットワーク・ルールの設定は、末尾の「Configure Network Access with Private Endpoints」も参照してください。本記事では接続元IP・ポートの実測までは行っていないため、最小ルールの定義は扱いません。

今回使用したNSGの設定は以下です。画面の「Stateless」は、すべてNoでした。用途欄は画面のDescriptionに基づきます。

・ Autonomous AI Lakehouse(ALH)用 NSG

NSG	方向	接続元／宛先（CIDR）	プロトコル	宛先ポート	用途・備考
NSG-ALH	Ingress	接続元：10.100.0.0/16	TCP	1521	TLS
NSG-ALH	Ingress	接続元：10.100.0.0/16	TCP	1522	mTLS
NSG-ALH	Ingress	接続元：10.100.0.0/16	TCP	443	Database Actions／APEX／ORDS
NSG-ALH	Egress	宛先：10.100.0.0/16	All Protocols	すべて	VCN内への送信許可

・ AIDP用 NSG

NSG	方向	接続元／宛先（CIDR）	プロトコル	宛先ポート	用途・備考
NSG-AIDP	Ingress	接続元：10.100.0.0/16	All Protocols	すべて	指定CIDRからの受信許可
NSG-AIDP	Egress	宛先：10.100.0.0/16	All Protocols	すべて	VCN内への送信許可

NSG-ALHのTCP受信ルールでは、接続元ポートはいずれもAllです。上記は成功した検証環境の設定であり、各ルールが今回のRAG処理に必須であることや、実際に使用されたポートを示すものではありません。特に、1522の許可は、今回の接続でmTLSを使用したことを意味しません。

ここに掲載しているのはNSGの設定です。Subnet側のSecurity Listの一覧は掲載していないため、再現時はNSGと併せて確認します。

2) 既存Lakehouseを指定してAIDPを作成する

1. OCIコンソールからAI Data Platformの作成画面を開きます。
2. AIDP名と初期Workspace名を入力します。
3. Oracle autonomous AI lakehouse configurationで Choose existing を選びます。
4. 対象コンパートメントとAI-Lakehouseを選びます。
5. ADMINパスワードを入力し、必要なIAMポリシー等の前提条件を満たして作成します。
6. 作成後、AIDPを開きます。

3) 初期化結果とWorkspaceを確認する

Notificationsで以下の成功を確認します。

• CREATE_WORKSPACE
• CREATE_CATALOG：vector_db_CDB等
• CREATE_USER_SCHEM…：ベクトルDB用ユーザー・スキーマのプロビジョニング
• LOAD_MODEL_IN_CAT…：モデルロード

Workspaces一覧には、今回WorkspaceとPvt_vector_db_CDBが自動作成されていました。

Pvt_vector_db_CDBの Actions → Edit を開き、以下を確認します。

• Enable private network：有効
• VCN：VCN-10.100.0.0
• Subnet：Client-Subnet
• Lakehouse側とSubnet OCIDが一致

既定のWorkspaceの編集画面には Private network cannot be enabled for Default workspace と表示され、Private Networkを有効にできませんでした。今回は、自動作成されたPvt_vector_db_CDBを使用します。

■ テスト文書とVolumeを準備する

1) TXTファイルを作成する

ファイル名：aidp_connection_test.txt
文字コード：UTF-8

これはAIDPとAI Lakehouseの接続確認用文書です。
検証プロジェクト名は「しろくま湖」です。
しろくま湖の確認コードは「AAL-7319」です。
しろくま湖の担当者は「青葉」です。

質問文には確認コードや担当者の答えを入れず、取り込んだ文書から取得できるかを確認します。

2) Managed Volumeを作成する

1. 左メニューの Master catalog を開きます。
2. 標準カタログdefaultを開きます。
3. スキーマdefaultを開きます。
4. Volumes → Create Volume を選びます。
5. 名前をvol_aal_test、種類を Managed にして作成します。

Volumeは、Master catalog → default（標準カタログ）→ default（スキーマ）→ Volumesに作成します。元文書はこのVolumeへ配置し、ベクトルの保存・検索には関連付けたAI Lakehouseを使用します。

3) TXTをアップロードする

vol_aal_testを開き、アップロード操作からaidp_connection_test.txtを配置します。今回の保存先は以下です。

/Volumes/default/default/vol_aal_test/aidp_connection_test.txt

今回の専用Volumeにはテスト文書だけを配置し、Knowledge BaseのデータソースとしてVolume全体を指定します。複数文書がある場合は、専用フォルダを用意してそのフォルダを指定します。

■ 取り込み用Spark Clusterを準備する

1) Private Workspaceへ切り替える

左のWorkspace選択からPvt_vector_db_CDBを選びます。

2) Spark Clusterを確認・作成する

Compute → Clusters を開きます。既存Clusterがなければ、同Workspaceで取り込み用のSpark Clusterを作成します。今回はCluster1を使用し、状態がActiveになったことを確認して進めます。

Create Cluster画面では、Sparkバージョンとして3.5.0を選択しました。検証時の画面に表示された選択肢は、この1種類だけでした。これは当該環境・検証時点での表示であり、ほかのバージョンとの比較検証は行っていません。

今回の入力は小さなTXTファイル1件です。取り込み用Clusterは、検証用の構成として作成します。

公式手順では、Knowledge Base作成時にClusterを未選択にするとDefault Master Catalog Computeが使用されます。今回は、取り込みに使う環境を明示するため、Private Workspace内のSpark Clusterを選択します。

Knowledge Base作成画面の「Cluster used for ingestion」で選ぶのは、このSpark Clusterです。

■ Knowledge Baseを作成して取り込む

1) Knowledge Baseを作成する

Master catalog → default → default → Knowledge Bases → Create Knowledge Base を開きます。

項目	設定
Name	kb_aal_connection_test2
Description	Private Endpoint Lakehouse接続確認用
Workspace for compute	Pvt_vector_db_CDB
Cluster used for ingestion	同WorkspaceのCluster1
Embedding model	MULTILINGUAL_E5_SMALL
Chunk size	500
Chunk overlap	50

日本語の文書を使うため、Embeddingモデルには多言語向けのMULTILINGUAL_E5_SMALLを選びます。Chunk sizeは分割するテキストの文字数、Chunk overlapは隣り合うチャンクで重複させる文字数です。今回の短いテスト文書では、それぞれ500、50としました。

以降のJSONでも、ここで作成した名前kb_aal_connection_test2を使用します。

2) データソースを追加する

1. 作成したKBを開きます。
2. Data Source → Add data source を選びます。
3. default.default.vol_aal_testを指定します。
4. 必要に応じてPrivate Workspace内の取り込みClusterを指定します。
5. ファイル形式でTXTに対応する項目を選びます。今回の画面では text と表示されました。
6. Start ingestion job on add を選んで追加するか、追加後に Parameters → Ingest now を実行します。

KBの取り込み元はVolumeまたはVolume内のフォルダです。ファイル単体を選択する方式ではありません。

3) 取り込み結果を確認する

KB → Data Source → vol_aal_test → Job runs を開きます。

項目	今回の成功値
Status	Succeeded
Files added	1
Files modified	0
Files deleted	0

Parametersでは保存先パス、Workspace key、Cluster keyも確認できます。ジョブが成功しても処理対象が0件の場合は、パスとファイル形式の選択を確認します。

■ AgentとAI Computeを準備する

1) 同じPrivate WorkspaceでAI Computeを作成する

Compute → AI Compute → Create、またはAgent画面からAI Computeの新規作成を選びます。

項目	今回の設定
Name	ai_compute_aal_test
OCPUs	1
Memory	16 GB
Compute replicas	1
Auto-scaling	無効

作成画面に表示された使用量は 115 AIDP units per hour でした。これは当該画面の構成表示であり、通貨換算した料金ではありません。再現時には現在の表示を確認します。

作成後、状態がActiveになるまで待ちます。

2) Private Workspace内にAgent projectを作成する

Pvt_vector_db_CDBを選択した状態で Agents → Create を開きます。

項目	設定
Name	agent_aal_connection_test
Description	AI LakehouseへのRAG接続確認
Agent authoring mode	Visual builder
AI Compute（optional）	作成したai_compute_aal_testを選択

先に作成したAI Computeを選択してAgent projectを作成します。Agent定義の作成時には省略することもできますが、RAGツールのTest／Playground実行までに接続が必要です。

3) AgentとAI Computeの接続を確認する

Agent画面右上の Select Playground AI Compute でai_compute_aal_testを選択します。名称と ACTIVE が緑色で表示されることを確認します。

● 今回発生したSubnet不一致エラー

既定のWorkspaceでAI Computeを作成すると、以下のエラーが表示されました。

AI compute cannot be created because the Oracle Autonomous AI
Lakehouse (ALH) attached with this AIDP workbench is configured
with a different subnet than current workspace. To resolve this
issue create a AI compute in private workspace with the same
subnet as ALH attached to AIDP workbench.
SubnetId used with ALH: <LakehouseのSubnet OCID>

対処として、Lakehouseと同じSubnetを設定したPvt_vector_db_CDBに切り替え、AI Computeを作成しました。

この動作について製品チームへ確認したところ、意図した動作であるとの回答がありました。今回のPrivate Endpoint構成では、関連付けたAI Lakehouseと同じSubnetを設定したPrivate WorkspaceへAI Computeを作成します。

今回のエラーは、DBへの接続テスト時ではなく、AI Computeの作成時に表示されました。ネットワーク上の到達性とは別に、作成時の条件としてWorkspaceとAI Lakehouseの同一Subnetが要求されることを確認しています。同じVCNでも、Subnetが異なればこの条件は満たしません。

一方、後述のSQL確認では、AI Lakehouseとは異なるSubnetに配置したOracle Linux Computeから接続できました。したがって、今回確認した同一Subnet条件は、AI Compute作成時のWorkspace設定に関するものであり、すべてのSQLクライアントに同一Subnetを要求するという意味ではありません。別SubnetのWorkspaceでAI Computeを作成する構成や、別VCNからの接続は今回検証していません。また、この同一Subnet条件を明記した公開ドキュメントは検証時点では見つからず、ドキュメント更新についても検討が依頼されました。

この条件は、今回のAI Compute作成について確認したものです。Notebookで行うPython／Sparkの機械学習や、External Catalogを通じた外部DB接続とは区別して考えます。

■ RAGツールを設定する

1) RAGツールを配置する

Agent projectの Flow → Development を開き、左の Tool templates → RAG をキャンバスへドラッグします。今回のノード名はRAG_1です。

今回はRAGツールのTest機能を使います。Agent project内にRAGツールを配置し、ツール単体で質問を送って文書検索と回答生成を確認します。

2) モデルとKnowledge Baseを指定する

RAG_1を選択し、Parametersに以下を設定します。

項目	今回の設定
Model configuration	OCI Generative AI service
Response Synthesizer Model Region	us-ashburn-1
Response Synthesizer Model	xai.grok-4.7
Knowledge base	default.default.kb_aal_connection_test2
Limit - number of documents to retrieve	5

Limitは、ベクトルストアから検索で取得する文書チャンク数の上限です。今回の設定値は5ですが、5ファイルを取得する指定ではありません。

回答生成に使用するLLMとして、今回は画面に表示されたxai.grok-4.7を選択しました。利用できるモデルはリージョンや権限等に応じて確認します。

● KBプルダウンが反応しない場合のJSON回避方法

今回、Knowledge base欄の▼を押しても候補が開かず、文字入力もできませんでした。KBは作成済みで、文書取り込みも成功していました。

Configuration右側の<>をクリックし、JSON表示へ切り替えます。今回の画面で取得できたJSONの形式に合わせて、以下を入力しました。

{
  "catalogKey": "default",
  "schemaKey": "default",
  "knowledgeBase": "kb_aal_connection_test2",
  "llm": {
    "type": "OCI_GEN_AI",
    "modelId": "xai.grok-4.7",
    "compartmentId": null,
    "endpointUrl": null,
    "provider": "xai",
    "regionId": "us-ashburn-1"
  },
  "modelSettings": null,
  "topK": "5"
}

元のJSONではcatalogKey、schemaKey、knowledgeBaseがnullだったため、それぞれdefault、default、kb_aal_connection_test2を入力しました。表形式へ戻すと、Knowledge base欄にdefault.default.kb_aal_connection_test2が表示されました。

Apply／保存操作がある場合は反映し、ノードを開き直して値が保持されていることを確認します。別の製品版ではフィールド形式が異なる可能性があるため、利用画面から取得したJSONを基に変更します。今回のtopKは元のGUIの文字列形式を維持しています。

プルダウンが反応しない原因は特定できていませんが、今回はJSONで直接指定することで回避できました。

■ RAG検索を実行して判定する

1) Testを実行する

1. Agent画面右上でAI ComputeがACTIVEで接続済みであることを確認します。
2. RAG_1の Test タブを開きます。
3. Queryに以下を入力します。
4. Submit を押します。

入力質問

しろくま湖の確認コードと担当者を教えてください。

2) 回答と参照元を確認する

今回、Test resultsに以下が表示されました。

出力結果

しろくま湖の確認コードは「AAL-7319」、担当者は「青葉」です。

併せて、取り込んだ文章と以下の参照元パスが表示されました。

/Volumes/default/default/vol_aal_test/aidp_connection_test.txt

回答の正しさに加えて、取得した文章と参照元が表示されていることを成功条件とします。画面に表示されたScoreは検索結果の指標であり、回答の正答確率や接続の信頼度として扱いません。

3) 接続確認の結果

段階	確認できたこと
AIDP初期化成功	関連付け・スキーマ作成・モデルロード等の初期化
TXT取り込み成功	1文書の取り込み処理とKB登録
RAGツールTest成功	文書の検索と回答生成までの一連の動作

AI Lakehouseのパブリック・アクセスを無効にした構成で、文書の取り込みからRAG検索・回答生成まで成功しました。

なお、今回は機能の動作確認を行っており、VCNフローログなどによる通信経路や接続元IPの詳細確認は行っていません。

■ 取り込んだ文書とベクトルの保存先をAI Lakehouseで確認する

RAGの回答は取得できましたが、取り込んだ文書とベクトルがAI Lakehouseのどこに保存されているのかも気になります。

ということで AI LakehouseへSQLで接続して、取り込んだ文書とベクトルの保存先を確認してみてみます。

今回は、AI Lakehouseとは異なるSubnetに配置したOracle Linux Computeから、AIDPに関連付けたAI LakehouseへADMINで接続して、以下のSELECTを実行しました。スキーマ名・テーブル名は今回の環境で確認できた値なので、別環境では検索結果に合わせて読み替えます。

1) 接続先のAI Lakehouseを確認する

SELECT
    SYS_CONTEXT('USERENV', 'DB_NAME')      AS db_name,
    SYS_CONTEXT('USERENV', 'SERVICE_NAME') AS service_name,
    SYS_CONTEXT('USERENV', 'SESSION_USER') AS session_user
FROM dual;

今回の実行結果は以下でした。

項目	実行結果
DB_NAME	G912A29DFC5DE89_CDB
SERVICE_NAME	G912A29DFC5DE89_CDB_tp.adb.oraclecloud.com
SESSION_USER	ADMIN

2) VECTOR型の列を持つテーブルを探す

データ・ディクショナリから、VECTOR型の列を持つテーブルを検索します。

SELECT
    c.owner       AS schema_name,
    c.table_name,
    c.column_name AS vector_column
FROM dba_tab_columns c
JOIN dba_tables t
  ON t.owner = c.owner
 AND t.table_name = c.table_name
WHERE c.data_type = 'VECTOR'
ORDER BY c.owner, c.table_name, c.column_id;

SCHEMA_NAME	TABLE_NAME	VECTOR_COLUMN
AIDP_2UHUP2WQ_KB_WRITE	EMBEDDING_TABLE_D46AC2B	EMBEDDING
VECSYS	CANDIDATE_QUERY_VECTORS$	QUERY_VECTOR

今回は、AIDP_2UHUP2WQ_KB_WRITE.EMBEDDING_TABLE_D46AC2Bを候補として調べます。テーブル名だけで判断せず、後続のSQLでテスト文書の本文と一致することを確認します。

3) 候補テーブルの列構成を確認する

SELECT
    column_id,
    column_name,
    data_type,
    data_length
FROM dba_tab_columns
WHERE owner = 'AIDP_2UHUP2WQ_KB_WRITE'
  AND table_name = 'EMBEDDING_TABLE_D46AC2B'
ORDER BY column_id;

COLUMN_ID	COLUMN_NAME	DATA_TYPE	DATA_LENGTH
1	DOCID	VARCHAR2	1024
2	CHUNKID	VARCHAR2	64
3	BODY	CLOB	4000
4	EMBEDDING	VECTOR	8200
5	PAGE_NUMBERS	VARCHAR2	128
6	OFFSET	NUMBER	22
7	LEN	NUMBER	22

本文を保存するBODY列はCLOB型、ベクトルを保存するEMBEDDING列はVECTOR型でした。なお、DATA_LENGTHの8200はベクトルの次元数ではありません。実際のベクトルの次元数と形式は、次のSQLで確認します。

4) テスト文書の本文とベクトルの次元数を確認する

文書に入れた「しろくま湖」を検索し、同じ行のベクトル情報を取得します。

SELECT
    docid,
    chunkid,
    DBMS_LOB.SUBSTR(body, 1000, 1) AS chunk_text,
    VECTOR_DIMENSION_COUNT(embedding) AS vector_dimensions,
    VECTOR_DIMENSION_FORMAT(embedding) AS vector_format
FROM AIDP_2UHUP2WQ_KB_WRITE.EMBEDDING_TABLE_D46AC2B
WHERE DBMS_LOB.INSTR(body, 'しろくま湖') > 0
FETCH FIRST 10 ROWS ONLY;

VECTOR_DIMENSION_COUNTはベクトルの次元数、VECTOR_DIMENSION_FORMATはベクトルの格納形式を返します。

今回、以下の行を取得できました。

項目	実行結果
DOCID	3_2
CHUNKID	chunk_0
VECTOR_DIMENSIONS	384
VECTOR_FORMAT	FLOAT32

CHUNK_TEXTには、以下のテスト文書の本文が入っていました。読みやすいよう改行して掲載します。

これはAIDPとAI Lakehouseの接続確認用文書です。
検証プロジェクト名は「しろくま湖」です。
しろくま湖の確認コードは「AAL-7319」です。
しろくま湖の担当者は「青葉」です。

テスト文書の本文と、384次元・FLOAT32のベクトルが、AI Lakehouseの同じテーブルの同じ行に保存されていることを確認できました。

5) ベクトルの数値を表示する

VECTOR_SERIALIZEでベクトルを文字列へ変換し、先頭500文字を表示します。

SELECT
    chunkid,
    DBMS_LOB.SUBSTR(
        VECTOR_SERIALIZE(embedding RETURNING CLOB),
        500,
        1
    ) AS vector_preview
FROM AIDP_2UHUP2WQ_KB_WRITE.EMBEDDING_TABLE_D46AC2B
WHERE DBMS_LOB.INSTR(body, 'しろくま湖') > 0
FETCH FIRST 3 ROWS ONLY;

chunk_0のベクトルは、以下の数値から始まっていました。ここでは実行結果の冒頭のみを抜粋しています。

[7.12562129E-002,-1.042281E-002,-3.45408507E-002,1.05754682E-003,7.66558498E-002,...

これで、ベクトルの次元数や形式だけでなく、保存された数値も確認できました。SQLでは先頭500文字に切り詰めているため、表示が数値の途中で終わる場合があります。

● 今回確認できた保存先

データ	今回確認した保存先
原本のTXTファイル	/Volumes/default/default/vol_aal_test/aidp_connection_test.txt
文書チャンクの本文	AI LakehouseのAIDP_2UHUP2WQ_KB_WRITE.EMBEDDING_TABLE_D46AC2BのBODY列
文書チャンクのベクトル	同じテーブルのEMBEDDING列（384次元・FLOAT32）

AIDPの画面で指定したKnowledge Baseの名前はdefault.default.kb_aal_connection_test2ですが、SQLで確認したDB側のスキーマ名・テーブル名は上記のとおりでした。画面上のカタログ・スキーマ名と、DB側の保存先の名前を分けて確認できました。

このSQL確認で特定したのは、今回取り込んだテスト文書とそのベクトルの保存先です。KB名とDBテーブル名を対応付ける管理メタデータや、RAG実行時のSQLトレースまでは確認していません。また、ここに記載したスキーマ名・テーブル名は今回の環境で確認したもので、固定の名称として扱わないようにします。

■ トラブルシューティング

症状	確認・対処
Master catalogにVolumeが見えない	標準カタログ→スキーマ→Volumesまで開く
Cluster used for ingestionに候補がない	選択したPrivate Workspace内のSpark Clusterを確認。AI Computeとは別
AI Compute作成でSubnet不一致	Lakehouse側Subnet OCIDとPrivate WorkspaceのSubnet OCIDを確認
Knowledge BaseがGUIで選べない	画面再読み込み後も反応しなければ、今回のJSON指定で回避
KB名を指定しても見つからない	実際の名前がkb_aal_connection_test2であること、カタログ・スキーマ・キーを確認
Testタブが無効	AgentにAI Computeを接続し、ACTIVE表示を確認
取り込み対象が0件	Volume／フォルダ、TXTの配置、text選択を確認
DB接続エラーが出る	NSG、Security List、DNS、接続先・ポートを確認。エラー全文とrequest IDを保存
LLM呼び出しで失敗	モデルの提供リージョンとOCI GenAI関連IAM権限を確認

■ 検証後の停止

使い終わったら、必要に応じてPrivate Workspaceの Compute → AI Compute → Actions → Stop でAI Computeを停止します。公式では停止によりComputeのメータリングが止まると説明されています。Spark Clusterも利用状況に合わせて停止します。

AI Computeの停止だけで、LakehouseやObject Storageを含む全リソースの費用が停止するわけではありません。

再開時は必要なComputeを起動し、Activeを確認します。今回の接続テストを完了するためだけにAgentをDeployする必要はありません。

■ 今回わかったこと

Private EndpointのみのAI LakehouseをAIDPへ関連付け、TXTファイルをKnowledge Baseへ取り込み、RAGツールから回答を取得できました。

今回、特に確認できたのは次の4点です。

• AI Compute用Workspaceは、関連付けたPrivateなAI Lakehouseと同じSubnetにそろえる。 既定Workspaceでは作成時にエラーとなり、同じSubnetのPrivate Workspaceで成功しました。
• Spark ComputeとAI Computeの役割が異なる。 文書の取り込みにはSpark Compute、Agent・RAGツールの実行にはAI Computeを使用しました。
• GUIでKBを選べない場合でも、JSON指定で回避できた。 取り込み済みのKBを指定することで、検索結果と参照元文書を取得できました。
• 取り込んだ文書の本文とベクトルをAI Lakehouse内で確認できた。 SQLで保存先を調べ、BODY列のテスト文書と、EMBEDDING列の384次元・FLOAT32のベクトルを取得できました。

画面上では「Knowledge Baseを作成して質問する」という操作ですが、その裏側には、原本を置くVolume、取り込み用のSpark、ベクトルを保存・検索するAI Lakehouse、RAGを実行するAI Computeがあります。それぞれの役割とネットワーク設定を確認できた検証になりました。

■ 参考ドキュメント

以下はOracleの公開ドキュメントです（2026年10月19日確認）

ドキュメント	主な参照内容
Get Started with Oracle AI Data Platform	AI機能用Lakehouseの役割、26ai以上の前提、AIDP作成・IAM要件
Workspaces	Workspaceの役割、Private Network、VCN・Subnet設定
Standard Catalogs	標準カタログとスキーマ・Volumeの構成
Volumes	Managed／External Volumeの役割と作成手順
Knowledge Bases	KB作成、Embeddingモデル、チャンク設定、取り込み・Job runs
AI Compute	AI Compute作成、Agentへの接続、起動・停止
Agent Creation	Visual builder、Agent project、Playground
About Agent Tools	RAGツール、JSONによる設定、単体Test
Configure Network Access with Private Endpoints	Autonomous DatabaseのPrivate Endpointとセキュリティ・ルール
ALL_TAB_COLUMNS／関連するDBA_TAB_COLUMNS	スキーマ名、テーブル名、列名、データ型などの列情報
Constructors, Converters, Descriptors, and Arithmetic Operators	VECTOR_DIMENSION_COUNTとVECTOR_DIMENSION_FORMATによる次元数・格納形式の確認
VECTOR_SERIALIZE	VECTOR型を文字列へ変換し、ベクトルの数値を表示

■ おまけ