Oracle Cloud Infrastructure（OCI）の リソース・プリンシパル（Resource Principal） とは、Resource PrincipalをサポートするOCIリソース自身を、IAM上のPrincipal（認証主体）として扱う認証方式です。
人間のOCIユーザーとして認証する代わりに、Autonomous AI Database、OCI Functions、Data Science Notebook SessionなどのOCIリソース自体がIdentityとなり、許可されたOCIサービスへアクセスします。
Resource Principalは、有効期限の短いセッション・トークンと保護された認証情報を使用します。リソースの認証に使用する証明書はOCIによって作成、割当て、ローテーションされるため、利用者がOCIユーザーのAPI署名秘密鍵をダウンロードし、コードやデータベースCredentialへ保存して管理する必要がありません。
主なメリットは次です。
- ユーザー管理の長期認証情報が不要：OCIユーザーのAPI署名鍵、秘密鍵、Fingerprintをアプリケーションやデータベースへ登録せずにOCIサービスへアクセスできます。
- 認証情報のライフサイクルをOCIが管理：証明書とセッション・トークンはOCIによって作成、管理、ローテーションされます。
- きめ細かなアクセス制御：Dynamic GroupとIAM Policyを使用し、権限を付与するOCIリソースと実行可能なAPI操作を限定できます。
- 秘密鍵漏洩リスクを低減：長期間使用するユーザー秘密鍵を、ローカル・ファイル、ソースコード、SQL、データベースCredentialへ保存する必要がありません。
OCIがResource Principalをサポートしているサービス間接続では、まず「秘密鍵をどこへ保管するか」ではなく、「秘密鍵を使わない構成にできないか」を検討することができます。
本記事では、このResource PrincipalをAutonomous AI DatabaseのSelect AIへ適用し、OCI Generative AIを呼び出します。
Autonomous AI DatabaseのSelect AIで使用する場合、
Select AIからOCI Generative AIへ接続する場合、OCIユーザーのAPI署名鍵をCredentialへ登録する方法があります。ただし、この方式では次の情報を作成・管理する必要があります。
- OCI User OCID
- Tenancy OCID
- API署名秘密鍵
- 公開鍵のFingerprint
- API署名鍵を格納するデータベースCredential
Autonomous AI Databaseでは、データベース自身をOCI IAM上のIdentityとして扱うResource Principalを使用できます。Resource Principalを使用すると、OCIユーザーのAPI署名秘密鍵をAutonomous AI Databaseへ登録せず、Dynamic GroupとIAM PolicyでOCI Generative AIへのアクセスを認可できます。
Select AI Profileでは、ユーザーが作成したOCI Credentialの代わりに、システム定義のOCI$RESOURCE_PRINCIPALを指定します。
ということで、Autonomous AI DatabaseのResource Principalを使用して、API署名鍵なしでSelect AIからOCI Generative AIへ接続してみてみます。
■ 今回のポイント
今回の構成では、次の設定を行います。
- 対象のAutonomous AI Database 1台だけがDynamic Groupのメンバーになるよう、OCIDを使用してMatching Ruleを設定
- Dynamic GroupへOCI Generative AIのChat APIを実行する最小権限を付与
- Autonomous AI DatabaseでResource Principalを有効化
-
ADB_USERへOCI$RESOURCE_PRINCIPALの使用権限を付与 - Select AI Profileの
credential_nameへOCI$RESOURCE_PRINCIPALを指定 - OCI Generative AIの
cohere.command-a-03-2025をSelect AIから実行
今回の実行経路では、OCIユーザーのAPI署名鍵を使用しません。また、OCI Generative AIへの接続では外部ホスト向けのNetwork ACLも追加しません。
■ OCI API署名鍵方式とResource Principal方式の違い
Select AIからOCI Generative AIへ接続する方法の1つとして、OCIユーザーのAPI署名鍵をデータベースCredentialへ登録する方式があります。一方、Resource Principalを使用すると、Autonomous AI Database自身をOCI IAM上の認証主体として扱い、ユーザーのAPI署名鍵を登録せずにOCI Generative AIへアクセスできます。
ここでいうAPI署名鍵は、OCI APIリクエストをOCIユーザーとして署名するための秘密鍵です。OpenAI APIキーなど、外部AIプロバイダーが発行するAPIキーとは別の認証情報です。
本記事でいう「API署名鍵」は、User OCID、Tenancy OCID、秘密鍵、Fingerprintを使用するOCIユーザーのAPI署名鍵です。OCI Generative AI専用のAPI Keyや、OpenAIなど外部AIプロバイダーのAPIキーとは別の認証情報です。
| 項目 | OCIユーザーのAPI署名鍵方式 | Autonomous AI Database Resource Principal方式 |
|---|---|---|
| OCI APIの実行主体 | OCIユーザー | Autonomous AI Database |
| OCI Generative AIへのIAM認可先 | OCIユーザーが所属するGroup | 対象ADBが所属するDynamic Group |
| OCI User OCID | 必要 | 不要 |
| Tenancy OCID | 必要 | 不要 |
| API署名秘密鍵 | 必要 | 不要 |
| Fingerprint | 必要 | 不要 |
| ユーザー作成Credential | 必要 | 不要 |
Select AI Profileのcredential_name
|
ユーザー作成OCI Credential | OCI$RESOURCE_PRINCIPAL |
| Dynamic Group | 不要 | 必要 |
| IAM Policy | User Groupへ付与 | Dynamic Groupへ付与 |
| 秘密鍵ローテーション | 利用者側で実施 | Resource Principal用証明情報をOCIが管理・ローテーション |
| 権限の限定方法 | OCIユーザーの権限に依存 | 対象ADBと許可するOCI APIをPolicyで限定 |
| 権限の制御方法 | OCIユーザーが所属するGroupのIAM Policyで制御 | 対象ADBが所属するDynamic GroupのIAM Policyで制御 |
| 認証主体の単位 | 人間またはサービス用OCIユーザー | Autonomous AI Databaseリソース |
| 権限主体と処理実体 | OCIユーザーとADBが別 | 権限主体が対象ADB自身 |
どちらの方式でもIAM Policyによる最小権限化は可能です。Resource Principalの主な違いは、権限主体がOCIユーザーではなく、実際に処理を実行するAutonomous AI Database自身になる点です。
API署名鍵方式では、秘密鍵を安全に保管しても、鍵ペア、公開鍵登録、Fingerprint、Credentialの更新を管理する必要があります。
Resource Principal方式では、秘密鍵の保管場所を変更するのではなく、OCIユーザーのAPI署名鍵を実行経路からなくします。今回のように認証元と接続先がどちらもOCIリソースである場合に、構成と鍵管理を単純化できます。
■ 検証環境
| 項目 | 設定値 |
|---|---|
| Autonomous AI Database | Serverless |
| Database Version | Autonomous AI Database 26ai |
| ADBリージョン | Japan East（Tokyo）／ap-tokyo-1
|
| OCI Generative AIリージョン | Japan Central（Osaka）／ap-osaka-1
|
| モデル | cohere.command-a-03-2025 |
| SQLクライアント | SQLcl 26.2.1 |
■ 構成
認証・認可の流れは次のとおりです。
-
ADB_USERがSelect AIを実行 - Select AI Profileが
OCI$RESOURCE_PRINCIPALを使用 - Autonomous AI DatabaseがResource Principalの一時トークンでOCIへ認証
- Dynamic GroupのMatching Ruleによって対象ADBであることを判定
- IAM Policyで許可されたOCI Generative AI Chat APIを実行
■ 前提
今回は、前回の次の記事で作成した環境を引き続き使用します。
- Autonomous AI Database Serverlessを作成済み
- データベース・ユーザー
ADB_USERを作成済み -
SHサンプル・スキーマを利用可能 -
ADB_USERから次の表を参照可能SH.CUSTOMERSSH.SALESSH.PRODUCTSSH.COUNTRIES
- OCIでDynamic GroupとIAM Policyを作成できる権限を保有
- OCI Generative AIの呼出しに使用するコンパートメントを作成済み
今回使用するモデルは、次とします。
cohere.command-a-03-2025
本記事の主題はLLMの性能比較ではなく、Autonomous AI DatabaseのResource Principalを使用して、OCIユーザーのAPI署名鍵なしでOCI Generative AIへ接続する方法の確認です。
今回は、次の理由からCohere Command Aを使用します。
・ 日本中央部（大阪）リージョンでオンデマンド利用できる
・ Dedicated AI Clusterと専用Endpointを作成せずに検証できる
・ 長いコンテキストを扱える
・ Tool Use、Agent、RAGなどのEnterprise AI用途を想定したモデルである
・ 多言語に対応している
今回はSelect AIのCHAT、SHOWSQL、通常実行、EXPLAINSQL、NARRATEを確認します。
本記事ではRAGそのものの精度検証は実施しませんが、今後、Autonomous AI DatabaseのAI Vector SearchやSelect AI RAGを組み合わせる場合も候補にしやすいモデルです。
Cohere Command Aは日本中央部（大阪）リージョンでオンデマンド利用できます。オンデマンド・モデルを使用するため、Dedicated AI Clusterと専用Endpointは作成しません。
■ 設定値
記事中では、次の設定値を使用します。
| 項目 | 設定値 |
|---|---|
| Dynamic Group名 | ADB_SELECT_AI_RP_DG |
| IAM Policy名 | ADB_SELECT_AI_GENAI_POLICY |
| データベース・ユーザー | ADB_USER |
| Select AI Profile名 | OCI_GENAI_RP |
| OCI Generative AIリージョン | ap-osaka-1 |
| OCI Generative AIモデル | cohere.command-a-03-2025 |
| ADB OCID | <ADB_OCID> |
| OCI Generative AI呼出し用コンパートメント名 | <GENAI_COMPARTMENT_NAME> |
| OCI Generative AI呼出し用コンパートメントOCID | <GENAI_COMPARTMENT_OCID> |
| Identity Domain名 | <IDENTITY_DOMAIN_NAME> |
■ 設定値確認
● Autonomous AI DatabaseのOCID確認
1) OCI Consoleへログイン
OCI Consoleへログインし、ナビゲーション・メニューから、次を選択
Oracle Database
└ Autonomous AI Database
2) 対象のAutonomous AI DatabaseからOCIDをコピー
Select AIを実行するAutonomous AI Databaseを選択し、OCIDをコピー
ocid1.autonomousdatabase.oc1.ap-tokyo-1.<...>
このOCIDは、Dynamic GroupのMatching Ruleで使用します。
● OCI Generative AIのリージョンとモデル確認
・ OCI Generative AIのリージョン確認
今回は、Japan Central (Osaka)のOCI Generative AIを選択します。
リージョン名: Japan Central (Osaka)
リージョン識別子: ap-osaka-1
リージョン・キー: KIX
日本東部（東京、ap-tokyo-1／NRT）のAutonomous AI Databaseから呼び出す場合でも、Select AI Profileのregionへap-osaka-1を指定することで、大阪リージョンのOCI Generative AIへ接続できます。
- 参考: OCI リージョン情報
・モデル確認
1) Consoleのリージョンを大阪へ切替
OCI Console右上のリージョンを、次へ切り替え
Japan Central (Osaka)
2) Generative AI Playgroundを表示
ナビゲーション・メニューから、次をクリック
Analytics & AI
└ Generative AI
└ Playground
3) Generative AI Overview画面
[Playground]をクリック
4) Cohere Command Aを確認
ChatモデルとしてCohere Command Aを選択できることを確認
OCIモデル名は次です。
cohere.command-a-03-2025
Select AI Profileの
regionを省略した場合、OCIプロバイダーのデフォルト・リージョンはus-chicago-1です。今回は日本から大阪のモデルを使用するため、ap-osaka-1を明示します。
■ Dynamic Groupの作成
Autonomous AI Database自身へOCI IAMの権限を付与するため、対象ADBをDynamic Groupへ所属させます。
今回は最小権限にするため、コンパートメント内のすべてのADBではなく、対象ADB 1台のOCIDを指定します。
● Dynamic Group作成画面を表示
1) Identity Domainを表示
OCI Consoleのナビゲーション・メニューから、次を選択します。
Identity & Security
└ Domains
2) Identity Domainを選択
Dynamic Groupを作成するIdentity Domainを選択
通常、Default Identity Domainを使用している場合はDefaultを選択
3) Dynamic groupsを選択
Identity Domainの詳細画面で、次を選択します。
Dynamic groups
└ Create dynamic group
● Dynamic Groupを作成
次の値を入力し、Create dynamic groupをクリック
| 項目 | 設定値 |
|---|---|
| Name | ADB_SELECT_AI_RP_DG |
| Description | Resource Principal for Select AI to call OCI Generative AI |
| Matching Rule | resource.id = '<ADB_OCID>' |
● Identity Domainを明示する場合
Autonomous AI DatabaseがDefault以外のIdentity Domainに関連付けられている環境では、Oracle公式ドキュメントの例に従って、Identity Domain名を含めます。
resource.id = '<IDENTITY_DOMAIN_NAME>/<ADB_OCID>'
例です。
resource.id = 'MyDomain/ocid1.autonomousdatabase.oc1.ap-tokyo-1.<...>'
Default Identity Domainで最初のルールが正常に動作する環境では、Identity Domain名の追加は不要です。
■ IAM Policyの作成
Dynamic Groupに所属したAutonomous AI Databaseへ、OCI Generative AIを呼び出す権限を付与します。
● 最小権限のPolicy
Select AIでCohere Command AなどのChatモデルを呼び出すために必要なAPI操作は、OCI Generative AIのChatです。
OCI IAMのResource Typeは、次です。
generative-ai-chat
必要なVerbは、次です。
use
そのため、本記事では次のPolicyを使用します。
Allow dynamic-group ADB_SELECT_AI_RP_DG to use generative-ai-chat in compartment <GENAI_COMPARTMENT_NAME>
● IAM Policyを作成
1) OCI コンソール Policies画面
OCI Consoleのナビゲーション・メニューから、次を選択
Identity & Security
└ Policies
2) Policy画面
対象のGenerative AI呼出し用コンパートメントを参照できる、ルート・コンパートメントまたは親コンパートメントを選択し、[Create Policy]をクリック
検証環境で構成を単純にする場合は、ルート・コンパートメントへPolicyを作成します。
3) Create Policyを選択
Allow dynamic-group ADB_SELECT_AI_RP_DG to use generative-ai-chat in compartment <GENAI_COMPARTMENT_NAME>
次の値を入力し、Createをクリック
| 項目 | 設定値 |
|---|---|
| Name | ADB_SELECT_AI_GENAI_POLICY |
| Description | Allow one Autonomous AI Database to call OCI Generative AI Chat API |
| Policy Builder | Manual editor |
| Policy Statement | Allow dynamic-group ADB_SELECT_AI_RP_DG to use generative-ai-chat in compartment |
● Default以外のIdentity Domainを使用する場合
PolicyのSubjectへIdentity Domain名を追加します。
Allow dynamic-group <IDENTITY_DOMAIN_NAME>/ADB_SELECT_AI_RP_DG to use generative-ai-chat in compartment <GENAI_COMPARTMENT_NAME>
Default Identity DomainのDynamic Groupは、Identity Domain名を省略できます。
Dynamic Group名ではなくOCIDを使用することもできます。
Allow dynamic-group id <DYNAMIC_GROUP_OCID> to use generative-ai-chat in compartment <GENAI_COMPARTMENT_NAME>
● manage generative-ai-familyを使用しない理由
Select AIのサンプルやSandbox向けの例では、次のような広いPolicyを見かけることがあります。
Allow dynamic-group ADB_SELECT_AI_RP_DG to manage generative-ai-family in compartment <GENAI_COMPARTMENT_NAME>
manage generative-ai-familyは、Chatの実行だけでなく、Generative AI関連リソースに対する広い管理権限を含みます。
今回は既存のオンデマンドChatモデルを呼び出すだけなので、次の最小権限にします。
use generative-ai-chat
● Embeddingを使用する場合の追加権限
OCI Generative AIのEmbeddingモデルを使用する場合は、用途に応じて次の権限を追加します。
Allow dynamic-group ADB_SELECT_AI_RP_DG to use generative-ai-text-embedding in compartment <GENAI_COMPARTMENT_NAME>
今回のNL2SQL、SHOWSQL、RUNSQL、EXPLAINSQL、NARRATE、CHATの検証では、Chatモデルを使用するため、この権限は追加しません。
Resource Principalのトークンは最大2時間キャッシュされます。Dynamic GroupやIAM Policyを変更した直後は、変更内容の反映に最大2時間かかる場合があります。
■ ADB_USERの権限確認
本記事では、Select AI ProfileをADB_USERが所有し、通常のSelect AI実行にもADB_USERを使用します。
● DBMS_CLOUD_AIの実行権限を確認
1) ADMINユーザーで接続
sql admin/<ADMIN_PASSWORD>@ADW
接続ユーザーを確認します。
SHOW USER
USER is "ADMIN"
2) ADB_USERの権限を確認
SELECT grantee,
owner,
table_name,
privilege
FROM dba_tab_privs
WHERE grantee = 'ADB_USER'
AND table_name = 'DBMS_CLOUD_AI';
GRANTEE OWNER TABLE_NAME PRIVILEGE
----------- ------------------- ---------------- ----------
ADB_USER C##CLOUD$SERVICE DBMS_CLOUD_AI EXECUTE
前回の記事で設定済みのため、今回は追加のGRANTを実行しません。
結果が0件の場合だけ、ADMINユーザーで次を実行します。
GRANT EXECUTE ON DBMS_CLOUD_AI TO ADB_USER;
● SHサンプル・スキーマを参照できることを確認
ADB_USERへ接続し直します。
sql adb_user/<ADB_USER_PASSWORD>@ADW
SELECT COUNT(*)
FROM SH.CUSTOMERS;
COUNT(*)
-----------
55500
Autonomous AI DatabaseのSHとSSBは、読み取り専用のサンプル・スキーマとして提供され、データベース・ユーザーは追加設定なしで問合せできます。
そのため、本記事では次のようなGRANT SELECTを実行しません。
-- 実行しない
GRANT SELECT ON SH.CUSTOMERS TO ADB_USER;
Oracle管理のサンプル・スキーマに対してADMINから権限付与を試みると、ORA-01031: insufficient privilegesになることがあります。自作スキーマの表をSelect AIで使用する場合は、その表の所有者または権限を持つ管理者から、実行ユーザーへ必要なSELECT権限を付与します。
● 今回作成しない設定
Resource Principalを使用するため、OCIユーザーのAPI署名鍵を格納するCredentialは作成しません。
-- 今回は実行しない
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'GENAI_CRED',
user_ocid => '<USER_OCID>',
tenancy_ocid => '<TENANCY_OCID>',
private_key => '<PRIVATE_KEY>',
fingerprint => '<FINGERPRINT>'
);
END;
/
今回のOCI Generative AI Resource Principal構成では、前回のOpenAI API版で使用したapi.openai.comなど、外部AIプロバイダーのホストへ接続するためのNetwork ACLは使用しません。
■ Resource Principalの有効化
OCI IAM側のDynamic GroupとPolicyを作成した後、Autonomous AI Database側でResource Principalを有効化します。
● ADB_USERでResource Principalを使用可能にする
ADMINユーザーでAutonomous AI Databaseへ接続し、次を実行します。
BEGIN
DBMS_CLOUD_ADMIN.ENABLE_PRINCIPAL_AUTH(
provider => 'OCI',
username => 'ADB_USER'
);
END;
/
PL/SQL procedure successfully completed.
provider => 'OCI'はOCI Resource Principalを有効化する指定です。username => 'ADB_USER'を指定することで、Select AI Profileを作成・実行するADB_USERへOCI$RESOURCE_PRINCIPALの使用権限を付与します。
ENABLE_PRINCIPAL_AUTHは指定したProviderのPrincipal認証を有効化するプロシージャです。Resource Principal専用のENABLE_RESOURCE_PRINCIPALも提供されていますが、OracleのSelect AI＋OCI Generative AI公式例ではENABLE_PRINCIPAL_AUTH(provider => 'OCI')が使用されているため、本記事もこの形式にしています。
すでにResource Principalが有効な環境では、再実行時に「すでに有効」であることを示すエラーになる場合があります。その場合は、次の確認SQLでCredentialと
ADB_USERへの権限が存在することを確認します。
● Resource Principal Credentialを確認
ADMINユーザーで確認します。
SELECT owner,
credential_name
FROM dba_credentials
WHERE credential_name = 'OCI$RESOURCE_PRINCIPAL'
AND owner = 'ADMIN';
OWNER CREDENTIAL_NAME
-------- -----------------------
ADMIN OCI$RESOURCE_PRINCIPAL
OCI$RESOURCE_PRINCIPALはシステム定義のCredentialです。OCIユーザーの秘密鍵を格納したユーザー作成Credentialではありません。
● ADB_USERへの使用権限を確認
ADB_USERで接続し、次を実行します。
SELECT grantee,
table_schema,
table_name,
grantor
FROM all_tab_privs
WHERE grantee = 'ADB_USER'
AND table_name = 'OCI$RESOURCE_PRINCIPAL'
AND table_schema = 'ADMIN';
GRANTEE TABLE_SCHEMA TABLE_NAME GRANTOR
----------- --------------- ------------------------- ----------
ADB_USER ADMIN OCI$RESOURCE_PRINCIPAL ADMIN
これで、ADB_USERがSelect AI ProfileからOCI$RESOURCE_PRINCIPALを参照できる状態になりました。
■ Select AI Profileの作成
ADB_USERでAutonomous AI Databaseへ接続します。
1) ADB_USERで接続
sql adb_user/<ADB_USER_PASSWORD>@ADW
● 既存の同名Profileを削除
同名のProfileを作り直す場合は、先に削除します。
force => TRUEを指定すると、Profileが存在しない場合のエラーを無視できます。
BEGIN
DBMS_CLOUD_AI.DROP_PROFILE(
profile_name => 'OCI_GENAI_RP',
force => TRUE
);
END;
/
PL/SQL procedure successfully completed.
● Resource Principalを使用するProfileを作成
次のSQLでSelect AI Profileを作成します。
<GENAI_COMPARTMENT_OCID>は、OCI Generative AIの呼出しに使用するコンパートメントOCIDへ置き換えます。
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name => 'OCI_GENAI_RP',
attributes => q'~
{
"provider": "oci",
"credential_name": "OCI$RESOURCE_PRINCIPAL",
"oci_compartment_id": "<GENAI_COMPARTMENT_OCID>",
"region": "ap-osaka-1",
"model": "cohere.command-a-03-2025",
"object_list": [
{"owner": "SH", "name": "CUSTOMERS"},
{"owner": "SH", "name": "SALES"},
{"owner": "SH", "name": "PRODUCTS"},
{"owner": "SH", "name": "COUNTRIES"}
],
"object_list_mode": "all",
"enforce_object_list": true,
"comments": false,
"constraints": true,
"temperature": 0
}
~',
status => 'enabled',
description => 'OCI Generative AI using Autonomous AI Database Resource Principal'
);
END;
/
PL/SQL procedure successfully completed.
今回指定した主な属性です。
| 属性 | 設定値 | 内容 |
|---|---|---|
provider |
oci |
OCI Generative AIを使用 |
credential_name |
OCI$RESOURCE_PRINCIPAL |
ADBのResource Principalで認証 |
oci_compartment_id |
<GENAI_COMPARTMENT_OCID> |
OCI Generative AI呼出しの認可対象コンパートメント |
region |
ap-osaka-1 |
大阪リージョンを明示 |
model |
cohere.command-a-03-2025 |
Cohere Command Aを使用 |
object_list |
SHの4表 | LLMへ送信する対象メタデータを限定 |
object_list_mode |
all |
指定した4表のメタデータを使用 |
enforce_object_list |
true |
指定外の表をSQL生成対象にしない |
comments |
false |
表・列コメントをLLMへ送信しない |
constraints |
true |
主キー・外部キーなどの関係をSQL生成に使用 |
temperature |
0 |
SQL生成結果のばらつきを抑制 |
object_list_modeをautomatedにすると、関連オブジェクト選択用のVector Indexが自動作成される場合があります。今回はEmbedding権限を追加せず、構成を単純にするためallを指定しています。
● Profileを確認
・ Profileの状態確認
SELECT profile_name,
status,
description
FROM user_cloud_ai_profiles
WHERE profile_name = 'OCI_GENAI_RP';
PROFILE_NAME STATUS DESCRIPTION
_______________ __________ ____________________________________________________________________
OCI_GENAI_RP ENABLED OCI Generative AI using Autonomous AI Database Resource Principal
・ Profileの属性確認
SELECT profile_name,
attribute_name,
attribute_value
FROM user_cloud_ai_profile_attributes
WHERE profile_name = 'OCI_GENAI_RP'
ORDER BY attribute_name;
特に、次の値を確認します。
credential_name = OCI$RESOURCE_PRINCIPAL
provider = oci
region = ap-osaka-1
model = cohere.command-a-03-2025
PROFILE_NAME ATTRIBUTE_NAME ATTRIBUTE_VALUE
_______________ ______________________ ___________________________________________________________________________________
OCI_GENAI_RP comments false
OCI_GENAI_RP constraints true
OCI_GENAI_RP credential_name OCI$RESOURCE_PRINCIPAL
OCI_GENAI_RP enforce_object_list true
OCI_GENAI_RP model cohere.command-a-03-2025
OCI_GENAI_RP object_list [{"owner":"SH","name":"CUSTOMERS"},{"owner":"SH","name":"SALES"},{"owner":"SH","
OCI_GENAI_RP object_list_mode all
OCI_GENAI_RP oci_compartment_id <GENAI_COMPARTMENT_OCID>
OCI_GENAI_RP provider oci
OCI_GENAI_RP region ap-osaka-1
OCI_GENAI_RP temperature 0
11 rows selected.
■ Select AI Profileを現在のセッションへ設定
1) Select AI Profile設定
DBMS_CLOUD_AI.SET_PROFILEは、Select AIを実行するデータベース・セッションごとに実行します。
BEGIN
DBMS_CLOUD_AI.SET_PROFILE(
profile_name => 'OCI_GENAI_RP'
);
END;
/
SQLclでは、次のようにも実行できます。
EXEC DBMS_CLOUD_AI.SET_PROFILE('OCI_GENAI_RP');
PL/SQL procedure successfully completed.
2) Profileの確認
現在のProfileを確認します。
SELECT DBMS_CLOUD_AI.GET_PROFILE()
FROM dual;
DBMS_CLOUD_AI.GET_PROFILE()
______________________________
"ADB_USER"."OCI_GENAI_RP"
本記事ではADB_USERでProfileを作成したため、所有者もADB_USERと表示されます。ADMINと表示される場合は、ProfileをADMINユーザーで作成しています。
■ Select AIを実行
LLMが生成するSQLは、モデル、モデルの更新、データベースのメタデータ、プロンプトによって変わる場合があります。
本番データへ適用する前に、最初にSHOWSQLでSQLを確認します。
● OCI Generative AIへの接続確認
最初にCHATを実行し、OCI Generative AIのChat APIを呼び出せることを確認します。
SELECT AI CHAT
Autonomous AI DatabaseのResource Principalとは何ですか？;
RESPONSE
________________________________________________________________________________
**Autonomous AI DatabaseのResource Principal**は、Oracle Cloud Infrastructure
(OCI)のセキュリティ機能の一つで、データベースが他のOCIリソースと
安全に通信するための認証メカニズムです。
主な特徴として、データベース内へユーザーのAPI署名鍵を保存せず、
IAM Policyで許可されたOCIリソースへアクセスできます。
...（応答の一部を省略）
CHATの応答が返ることでOCI Generative AIのChat APIへ接続できたことを確認できます。ただし、応答本文はモデルが生成した内容です。Resource Principalを使用したこと自体は、後述するProfile属性とCredential権限で確認します。
● SHOWSQLで生成SQLを確認
SELECT AI SHOWSQL 最も売れた商品と販売数量を表示してください;
RESPONSE
_____________________________________
SELECT
p."PROD_NAME" AS 商品名,
SUM(s."QUANTITY_SOLD") AS 販売数量
FROM
"SH"."SALES" s
JOIN
"SH"."PRODUCTS" p
ON
s."PROD_ID" = p."PROD_ID"
GROUP BY
p."PROD_NAME"
ORDER BY
販売数量 DESC
FETCH FIRST 1 ROWS ONLY
想定する処理内容は、SH.SALESとSH.PRODUCTSを結合し、商品ごとのQUANTITY_SOLDを集計して最大の行を取得するSQLです。
次を確認します。
- 使用している表が
object_list内であること -
SALES.PROD_IDとPRODUCTS.PROD_IDを正しく結合していること -
QUANTITY_SOLDをSUMで集計していること - 降順に並べ、先頭1件を取得していること
● 自然言語からSQLを実行
SHOWSQLの内容を確認後、同じ問い合わせを実行します。
SELECT AI 最も売れた商品と販売数量を表示してください;
PROD_NAME TOTAL_QUANTITY_SOLD
____________ ______________________
Mouse Pad 29282
SHOWSQLと通常のSELECT AIは別々にモデルを呼び出すため、列別名やSQLの書式が異なる場合があります。処理内容と実行結果が期待どおりかを確認します。
● 生成SQLを説明
SELECT AI EXPLAINSQL
最も売れた商品と販売数量を表示してください;
RESPONSE
__________________________________________________________________________________________________________________________________________
SELECT p."PROD_NAME", SUM(s."QUANTITY_SOLD") AS total_quantity_sold
FROM "SH"."SALES" s
JOIN "SH"."PRODUCTS" p ON s."PROD_ID" = p."PROD_ID"
GROUP BY p."PROD_NAME"
ORDER BY total_quantity_sold DESC
FETCH FIRST 1 ROWS ONLY;
**説明:**
1. **SELECT句:**
- `p."PROD_NAME"`: 商品名を選択します。
- `SUM(s."QUANTITY_SOLD") AS total_quantity_sold`: 各商品の販売数量を合計し、`total_quantity_sold` というエイリアスを付けます。
2. **FROM句:**
- `"SH"."SALES" s`: `SALES` テーブルに `s` というエイリアスを付けます。
- `"SH"."PRODUCTS" p`: `PRODUCTS` テーブルに `p` というエイリアスを付けます。
3. **JOIN句:**
- `JOIN "SH"."PRODUCTS" p ON s."PROD_ID" = p."PROD_ID"`: `SALES` テーブルと `PRODUCTS` テーブルを `PROD_ID` 列で結合します。これにより、販売データと商品情報が関連付けられます。
4. **GROUP BY句:**
- `GROUP BY p."PROD_NAME"`: 商品名ごとにデータをグループ化します。これにより、各商品の販売数量が合計されます。
5. **ORDER BY句:**
- `ORDER BY total_quantity_sold DESC`: 販売数量の合計を降順に並べ替えます。
6. **FETCH FIRST 1 ROWS ONLY:** 最も売れた商品（販売数量が最も多い商品）のみを返します。
このクエリは、最も売れた商品とその販売数量を表示します。
● 問合せ結果を自然言語で説明
SELECT AI NARRATE 最も売れた商品と販売数量を説明してください;
RESPONSE
_______________________________________
最も売れた商品は「Mouse Pad」で、販売数量は29,282個です。
NARRATEはSQLの実行結果をLLMへ渡し、自然言語の説明を生成します。実データを使用する場合は、組織のデータ取扱いポリシーを確認してから使用します。
■ Resource Principalを使用できていることの確認
今回の認証方式は、Profile、Credential権限、未作成のOCI署名Credentialの3点で確認します。
● ProfileのCredentialを確認
SELECT attribute_value AS credential_name
FROM user_cloud_ai_profile_attributes
WHERE profile_name = 'OCI_GENAI_RP'
AND attribute_name = 'credential_name';
CREDENTIAL_NAME
-----------------------
OCI$RESOURCE_PRINCIPAL
● ADB_USERのResource Principal権限を確認
SELECT grantee,
table_schema,
table_name
FROM all_tab_privs
WHERE grantee = 'ADB_USER'
AND table_name = 'OCI$RESOURCE_PRINCIPAL'
AND table_schema = 'ADMIN';
GRANTEE TABLE_SCHEMA TABLE_NAME
----------- --------------- -------------------------
ADB_USER ADMIN OCI$RESOURCE_PRINCIPAL
● OCIユーザーのAPI署名鍵を登録していないことを確認
今回の手順では、次の情報をSelect AI Profileやユーザー作成Credentialへ登録していません。
- OCI User OCID
- Tenancy OCID
- API署名秘密鍵
- Fingerprint
Profileは次の組合せでOCI Generative AIを呼び出しています。
provider = oci
credential_name = OCI$RESOURCE_PRINCIPAL
region = ap-osaka-1
model = cohere.command-a-03-2025
これにより、OCIユーザーのAPI署名鍵を作成、ダウンロード、SQLへ貼り付け、Credentialへ登録することなくSelect AIを実行できました。
■ Select AIでLLMへ送信される情報
Resource Principalは認証情報の管理を安全にする仕組みです。一方、LLMへ送信するプロンプト、メタデータ、問合せ結果の管理は別に必要です。
● NL2SQL／SHOWSQL／通常実行
Select AIは、自然言語からSQLを生成するため、対象表のメタデータでプロンプトを拡張します。メタデータには、設定に応じて次の情報が含まれます。
- オブジェクト所有者名
- 表名／ビュー名
- 列名
- データ型
- 表・列コメント
- Annotation
- 主キー／外部キーなどの制約
今回のProfileでは、対象をSHスキーマの4表へ限定し、コメントは送信せず、制約をSQL生成に利用します。
{
"object_list": [
{"owner": "SH", "name": "CUSTOMERS"},
{"owner": "SH", "name": "SALES"},
{"owner": "SH", "name": "PRODUCTS"},
{"owner": "SH", "name": "COUNTRIES"}
],
"object_list_mode": "all",
"enforce_object_list": true,
"comments": false,
"constraints": true
}
通常のNL2SQLでは、SQL生成の中心になるのは表のメタデータです。生成後のSQLはAutonomous AI Database内で実行されます。
● NARRATE
NARRATEは、データベースで実行したSQLの問合せ結果をLLMへ送り、自然言語の説明を生成します。
そのため、機密データ、個人情報、社外秘情報を含む問合せでNARRATEを使用する場合は、組織のデータ取扱いポリシーを確認します。
● CHAT
CHATは入力した自然言語プロンプトをLLMへ送信します。今回のProfileでは会話履歴を有効化していませんが、conversationを有効化する構成では、会話履歴に含まれる情報も考慮が必要です。
■ セキュリティ上のポイント
● Dynamic GroupはADB 1台に限定
Matching Ruleでは、対象ADBのOCIDを直接指定しました。
resource.id = '<ADB_OCID>'
コンパートメント内のすべてのADBを対象にするルールよりも、権限を与える対象を狭くできます。
● IAM PolicyはChat APIの実行だけに限定
Allow dynamic-group ADB_SELECT_AI_RP_DG
to use generative-ai-chat
in compartment <GENAI_COMPARTMENT_NAME>
OCI Generative AIのChat操作に必要なVerbはuseです。manage generative-ai-familyは使用していません。
● Select AI Profileの対象表を限定
object_listとenforce_object_listを使用し、SQL生成対象をSHスキーマの4表へ限定しました。
ただし、最終的なデータアクセス制御はデータベース権限です。実業務のスキーマを使用する場合は、ADB_USERへ不要な表や列への権限を付与しないことも重要です。
● 最初にSHOWSQLで確認
自然言語から生成されたSQLを無条件に実行せず、最初にSHOWSQLで参照表、JOIN条件、WHERE条件、集計方法を確認します。
● Resource Principalとデータガバナンスは別管理
Resource PrincipalによってOCIユーザーの秘密鍵管理は不要になりますが、LLMへ送信するメタデータ、プロンプト、NARRATEの問合せ結果については、組織のデータガバナンスに従って管理します。
● 利用リージョンを明示
今回のProfileはregion: ap-osaka-1を明示しています。東京リージョンのADBから実行する場合でも、OCI Generative AIの推論処理先は指定した大阪リージョンです。利用リージョンとデータ取扱い要件を事前に確認します。
■ トラブルシューティング
| 症状 | 確認内容 |
|---|---|
| OCI Generative AIの認可エラーになる | Dynamic GroupのMatching Rule、IAM PolicyのSubject、対象コンパートメントを確認 |
NotAuthorizedOrNotFound相当のエラーになる |
Dynamic Group名、Identity Domain名、Policyの対象コンパートメント、ADB OCIDを確認 |
| Policy変更後も同じエラーになる | Resource Principalトークンが最大2時間キャッシュされるため、反映を待って再実行 |
| モデルが見つからない |
regionとmodelの組合せをOCI Generative AIのModels by Regionで確認 |
| 東京のADBから大阪モデルを呼び出せない | Profileのregionがap-osaka-1、oci_compartment_idが正しい値になっているか確認 |
OCI$RESOURCE_PRINCIPALを使用できない |
ENABLE_PRINCIPAL_AUTHのusernameがProfile所有者のADB_USERと一致しているか確認 |
DBMS_CLOUD_AIを実行できない |
ADMINでADB_USERへのEXECUTE権限を確認 |
GRANT SELECT ON SH...でORA-01031になる |
SHはOracle管理の読取り専用サンプル・スキーマのため追加GRANTは行わず、ADB_USERから直接SELECTして確認 |
GET_PROFILE()がADMIN所有を示す |
Profileを作成したユーザーを確認。ADB_USER所有にする場合はADB_USERでProfileを作成してSET_PROFILEを実行 |
| Profileが見つからない | Profileを作成したDBユーザーで接続しているか確認 |
| Select AIでProfile未設定エラーになる | セッションごとにDBMS_CLOUD_AI.SET_PROFILEを実行 |
| 意図しない表を使用するSQLが生成される |
object_list、enforce_object_list、DBユーザーの権限を確認 |
| JOIN条件が不正確 |
constraints: true、主キー／外部キー、表・列名を確認 |
| 日本語のSQL生成精度が安定しない | プロンプトを具体化し、SHOWSQLで確認。同じ質問を複数回試して評価 |
● 確認用SQL
-- 現在のSelect AI Profile
SELECT DBMS_CLOUD_AI.GET_PROFILE()
FROM dual;
-- Profileの状態
SELECT profile_name,
status,
description
FROM user_cloud_ai_profiles;
-- Profileの属性
SELECT profile_name,
attribute_name,
attribute_value
FROM user_cloud_ai_profile_attributes
WHERE profile_name = 'OCI_GENAI_RP'
ORDER BY attribute_name;
-- Resource Principal Credential（ADMINで実行）
SELECT owner,
credential_name
FROM dba_credentials
WHERE credential_name = 'OCI$RESOURCE_PRINCIPAL'
AND owner = 'ADMIN';
-- ADB_USERへのResource Principal権限
SELECT grantee,
table_schema,
table_name,
grantor
FROM all_tab_privs
WHERE grantee = 'ADB_USER'
AND table_name = 'OCI$RESOURCE_PRINCIPAL'
AND table_schema = 'ADMIN';
■ 検証環境を片付ける場合
検証環境を片付ける場合は、Profile、データベース・ユーザーのResource Principal使用権限、OCI IAM設定の順に削除します。
● Select AI Profileを削除
ADB_USERで接続し、現在のセッションに設定しているProfileをクリアします。
BEGIN
DBMS_CLOUD_AI.CLEAR_PROFILE;
END;
/
続けて、ADB_USERが所有するSelect AI Profileを削除します。
BEGIN
DBMS_CLOUD_AI.DROP_PROFILE(
profile_name => 'OCI_GENAI_RP',
force => TRUE
);
END;
/
● ADB_USERのResource Principal使用権限を削除
ADMINユーザーで接続し、ADB_USERからOCI Resource Principalの使用権限を外します。
BEGIN
DBMS_CLOUD_ADMIN.DISABLE_PRINCIPAL_AUTH(
provider => 'OCI',
username => 'ADB_USER'
);
END;
/
これにより、ADB_USERからOCI$RESOURCE_PRINCIPALを使用できなくなります。
● Autonomous AI Database全体でResource Principalを無効化する場合
ほかのDBユーザーやDBMS_CLOUD処理がResource Principalを使用していないことを確認した場合だけ、ADMIN用のResource Principalも無効化します。
BEGIN
DBMS_CLOUD_ADMIN.DISABLE_PRINCIPAL_AUTH(
provider => 'OCI'
);
END;
/
共有環境では、ほかの処理へ影響するため、利用状況を確認せずに実行しないようにします。
● OCI IAM設定を削除
ほかの処理から使用していないことを確認して、次をOCI Consoleから削除します。
- IAM Policy
ADB_SELECT_AI_GENAI_POLICY - Dynamic Group
ADB_SELECT_AI_RP_DG
Dynamic Groupの削除時にメンバーが存在することを示すエラーになる場合は、先にMatching Ruleを変更し、対象ADBがDynamic Groupへ所属しない状態にしてから削除します。
■ まとめ
Autonomous AI DatabaseのResource Principalを使用し、API署名鍵なしでSelect AIからOCI Generative AIへ接続しました。
今回の構成では、次を確認できました。
- OCIユーザーのAPI署名秘密鍵をAutonomous AI Databaseへ登録しない
- OCI User OCID、Tenancy OCID、FingerprintをSelect AI用Credentialへ登録しない
- 秘密鍵をダウンロード、ローカル保存、SQLへ貼り付けしない
- OCIユーザーのAPI署名鍵を手動ローテーションしない
- 対象ADB 1台をDynamic Groupで指定する
- OCI Generative AIのChat APIだけを最小権限で許可する
-
ADB_USERへOCI$RESOURCE_PRINCIPALの使用権限を付与する - Select AI Profileで
cohere.command-a-03-2025を使用する -
CHAT、SHOWSQL、通常実行、EXPLAINSQL、NARRATEを実行する
Resource Principalは、OCIユーザーの秘密鍵を安全な場所へ移す方法ではありません。Autonomous AI Database自身をOCI IAM上のIdentityとして扱い、ユーザーのAPI署名鍵を不要にする仕組みです。
Oracle DatabaseからOCIサービスへ接続するために、ユーザーの秘密鍵をデータベースへ預けるのではなく、Autonomous AI Database自身をIdentityとして扱う。
単にCredentialの作成手順が減るだけでなく、「実際に処理するリソース」と「IAM上の認証主体」が同じになるところが、今回一番すっきりしたと感じたところです。Oracle Databaseを長く触ってきた人ほど、この鍵管理から解放される構成にはグッとくるものがあると思います。
一方、OpenAIなど外部AIプロバイダーへ接続する場合は、外部APIキーの管理が引き続き必要です。次回は、そのAPIキーをOCI Vaultで安全に管理しながらSelect AIから使用する構成を検証してみてみたいです。
いいじゃない、Resource PrincipalでSelect AI！
■ 解説
初心者でもわかりやすく解説してます。
セールストークにどーぞ
■ おまけ
■ 参考
● 前回記事
● Autonomous AI Database / Select AI
- Examples of Using Select AI
- Use Resource Principal to Access Oracle Cloud Infrastructure Resources
- DBMS_CLOUD_ADMIN Subprograms
- Manage AI Profiles
- DBMS_CLOUD_AI Package
- Select AI Concepts
- Use Sample Data Sets in Autonomous AI Database
● OCI IAM
● OCI Resource Principal
- Accessing Oracle Cloud Infrastructure Resources from Your Autonomous Database using Resource Principal
- About Using Resource Principal to Access Oracle Cloud Infrastructure Resources
- リソースプリンシパルを使用してOracle Cloud Infrastructureリソースにアクセス
● OCI Generative AI
- IAM Policies for OCI Generative AI
- Models, Clusters, and Keys - API Permissions
- Generative AI Regions
- Regional availability for Generative AI models
- Cohere Command A
