■ はじめに
Select AI Agent は、Autonomous AI Database の中で ReAct 型のエージェントを動かし、自然言語から SQL を生成したり、RAG や Web 検索などのツールを組み合わせて処理できる仕組みです。
今回は、Oracle が公開している Select AI Pre-Built AI Agents の中から、Select AI Inspect を試してみます。
Pre-Built AI Agents は、Oracle が GitHub で公開している Select AI Agent ベースのサンプル集 です。
今回はその中でも データベース・オブジェクトの調査に特化した Inspect 系エージェント を試してみます。
以前、Select AI Agent 自体については、こちらの記事で概要や基本的な考え方をまとめているのでご参照ください。
■ この記事で分かること
- Select AI Pre-Built AI Agents とは何か
- Select AI Inspect とは何か?どんな用途に向いているか
- インストール時の流れと設定ポイント
- 実際にどんな質問ができるか
■ Select AI Pre-Built AI Agents とは?
Select AI Pre-Built AI Agents は、Oracle が Select AI Agent フレームワークを使って実装した GitHub 公開のサンプル集です。
現時点(2026年4月)では以下のようなエージェントが公開されています。
- NL2SQL Data Retrieval Agent(自然言語をSQLに変換してデータを取得するエージェント)
- Autonomous AI Database Provisioning and Lifecycle Agent(Autonomous AI Databaseの作成・管理などを自然言語で操作するエージェント)
- Database Inspect Agent(DBオブジェクトや依存関係を調査・分析するエージェント)
- Insight Agent for Jira(Jiraのチケット情報からインサイトを抽出するエージェント)
- OCI Object Storage Agent(Object Storage上のデータを操作・検索するエージェント)
- OCI Vault Agent(Vault内のシークレットや鍵を管理するエージェント)
これは実際に動かせるコードとして GitHub で公開されており、インストールすればすぐに使えるところが魅力的です!
ゼロから Agent / Task / Tool を全部組むよりも、まずは完成済みのサンプルを試してから、自分の用途に合わせて広げられるのも良さそうです。
■ Select AI Inspect とは?
Select AI Inspect は、データベース・オブジェクトやそのメタデータを自然言語で調べるための AI エージェントです。
GitHub の README に詳細が書いてありますが、Oracle Database 26ai 上で動く、Select AI Agent フレームワークベースのデータベース inspection ツールとして紹介されています。
自然言語で、データベース・オブジェクトやそのメタデータ、依存関係を調べられるのが特徴です。
たとえば、次のような質問を自然言語で投げられます。
- どのオブジェクトがこの表を参照している?
- この関数呼び出しでエラーになるのはなぜ?
- この関数は何のために使われている?
- このパッケージを変更したら、どこに影響が出る?
用途としては、初見のスキーマの把握、レガシーコードの調査、依存関係の確認、テストケース生成、ソースコードからのドキュメント生成などが挙げられています。Oracle 公式ブログでも、オンボーディング、デバッグ、依存関係分析、変更影響の確認を自然言語で行える点が強調されています。
つまり、単に「表定義を見るツール」だけでなく、
既存の Oracle Database オブジェクトを自然言語で理解・調査することができるエージェントです。
また、Inspect の対象にできるオブジェクトとしては Tables / Views / Types / Type Bodies / Triggers / Functions / Procedures / Packages / Package Bodies / Schema となります。スキーマ単位でも、個別オブジェクト単位でも範囲を指定できます。
■ 内部的には何をしているのか
このエージェントは DATABASE_INSPECT という PL/SQL パッケージとして提供されていて、内部では inspection 用のツール群を使い分けながら回答します。
ユーザーが自然言語で質問すると、まずその意図を解析し、「構造確認」「依存関係解析」「コード理解」「検索」といった適切なツールに分解します。その上で、Oracle のデータディクショナリ(USER/ALL/DBA ビュー)からテーブル・ビュー・カラム情報を取得し、対象の構造を把握します。さらに依存関係ビューを使って、どのオブジェクトがどこを参照しているかを解析し、影響範囲を特定します。また、PL/SQL のソースコードを取得して内容を解析し、処理の役割やロジックを説明できるようにします。加えて、キーワード検索やベクトル検索を組み合わせて関連オブジェクトを横断的に探索し、必要な情報を統合します。これらの結果をまとめて最終的な回答を生成することで、単なるクエリ実行ではなく「DB全体を理解して説明するエージェント」として動作します。
■ 事前準備
README に記載されている前提条件は次のとおりです。
- Oracle Autonomous AI Database 26ai
- Select AI と
DBMS_CLOUD_AI_AGENTが有効になっていること -
ADMINまたは同等権限のユーザー -
DBMS_CLOUD_AI.CREATE_PROFILEで作成した Select AI プロファイル - そのプロファイルに
embedding_modelが含まれていること - OCI Generative AI を使う場合は
oci_compartment_idも必要
ここで特に気をつけたいのは、Inspect 用のプロファイルでは embedding 系の設定が必要 という点です。
Select AI で単純に NL2SQL を試すときには必要なかった設定を確認する必要があります。
次章からは事前設定が進んでいる前提で、次のインスールに進みますが、事前準備については以下を参照に行ってください。
事前準備の手順はこちらをクリック!
1. ADBの作成
Autonomous AI Database(バージョン26ai)を作成します。
ADB上でACL(Access Control List)設定
以下、外部APIの利用を許可するためACLの設定をAdminユーザーで行います。
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => '*',
ace => xs$ace_type(privilege_list => xs$name_list('connect'),
principal_name => 'adb_agent',
principal_type => xs_acl.ptype_db)
);
END;
/
2. クレデンシャルの作成
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL (
credential_name => 'OCI_GENAI_CRED',
user_ocid => '<your_user_ocid>',
tenancy_ocid => '<your_tenancy_ocid>',
private_key => '<your_private_key>',
fingerprint => '<your_fingerprint>'
);
END;
3. AIプロファイルの作成
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name =>'SELECTAIINSPECT',
attributes =>'{
"provider" : "oci",
"credential_name" : "OCI_GENAI_CRED",
"oci_compartment_id" : "<your_compartment_ocid>",
"comments" : "TRUE",
"conversation" : "TRUE",
"embedding_model" : "cohere.embed-v4.0",
"object_list": [
{ "owner": "admin", "name": "orders" },
{ "owner": "admin", "name": "order_items" },
{ "owner": "admin", "name": "products" }
]
}'
);
END;
/
また、今回テストで使用しているデータは、こちらの記事で作成した販売データです。サンプルデータが必要な場合は利用してください。
■ インストールしてみる
インストールは 2 段階になっています。
まず database_inspect_tool.sql で DATABASE_INSPECT パッケージとツール層を入れ、その後 database_inspect_agent.sql で Agent Team を作成します。
実行方法としては SQL*Plus / SQLcl のほか、SQL Developer などでもスクリプト実行モードで動かす想定です。database_inspect_agent.sql は対話入力を含むため、ワークシートに1文ずつ貼るのではなくスクリプトとして実行する必要があります。
Step 1. リポジトリを確認する
まずはGithubのサンプルリポジトリを確認します。
- GitHub:
oracle-autonomous-database-samples / autonomous-ai-agents / database_inspect
README を見ると、database_inspect 配下には主に次のファイルがあります。
database_inspect_tool.sqldatabase_inspect_agent.sqlREADME.md
こちらのレポジトリをクローンしインストールファイルを利用できるようにします。
git clone https://github.com/oracle-devrel/oracle-autonomous-database-samples.git
cd oracle-autonomous-database-samples/autonomous-ai-agents/database_inspect
Step 2. database_inspect_tool.sql を実行する
最初に database_inspect_tool.sql を実行します。
sqlplus admin@<adb_connect_string> @database_inspect_tool.sql
このスクリプトでは、SCHEMA_NAME の入力を求められます。(今回はADMINを指定。)
ここで指定したスキーマに対して、DATABASE_INSPECT パッケージのコンパイルや必要な権限付与が行われます。
以下のコマンドで正常に実行されたか確認できます。
SELECT object_name, object_type, status
FROM user_objects
WHERE object_name = 'DATABASE_INSPECT';
PACKAGE と ``PACKAGE BODYの STATUS が両方VALID` になっていれば問題ありません。
Step 3. database_inspect_agent.sql を実行する
続いて、Inspect 用のエージェントチームを作成するために database_inspect_agent.sql を実行します。
sqlplus admin@<adb_connect_string> @database_inspect_agent.sql
こちらは対話形式で、次のような項目を入力します。
-
INSTALL_SCHEMA_NAME:Agent Team を作成するスキーマ(ここではADMIN) -
AI_PROFILE_NAME:推論やEmbeddingに使用するAIプロファイル(ここではSELECTAIINSPECT) -
AGENT_TEAM_NAME:作成するエージェントチーム名(例えばDB_INSPECT_TEAM。ここではinspectionで作成。) -
RECREATE_EXISTING:既存のTeamを再作成するか(Y / N)(初回の場合はN) -
SCOPE_MODE:調査対象の範囲指定(SCHEMA / TABLE / PACKAGE / JSON)(ここではSCHEMA)
※対象を絞りたい場合は、TABLEやPACKAGEモードで特定オブジェクトだけを対象にすることもできます。
■ SCOPE_MODEごとの指定
選択したモードによって入力項目が変わります。
SCHEMAモード:SCOPE_OWNERS = 対象スキーマ(複数可)
TABLE / PACKAGEモード:OBJECT_OWNER = スキーマ名、OBJECT_NAMES = オブジェクト名(カンマ区切り)
JSONモード:TEAM_ATTRIBUTES_JSON = JSON形式で詳細指定
※使わない項目は空欄でOKです
Step 4. ジョブログを確認する
この agent installer はバックグラウンドジョブとして進み、進捗は DATABASE_INSPECT_AGENT_JOB_LOG$ に記録されます。
確認用の SQL 例は次のとおりです。
SELECT *
FROM <INSTALL_SCHEMA_NAME>.DATABASE_INSPECT_AGENT_JOB_LOG$
ORDER BY run_id DESC;
ステータスは、 PRECHECK、QUEUED、RUNNING、SUCCEEDED、FAILED などがあります。
■ 実際に問い合わせてみる
エージェントチームを作成できたら、Select AI Agent と同様に DBMS_CLOUD_AI_AGENT.SET_TEAM を使って、そのチームを現在のセッションに設定して利用します。
以下を実行します。
EXEC DBMS_CLOUD_AI_AGENT.SET_TEAM('DB_INSPECT_TEAM');
それでは準備が整ったので、select ai agent に続いて、自然言語の問い合わせを投げてみます。
まずはサンプル質問として出ている質問にします。
select ai agent Show me all database objects available for us to inspect;
検査可能なオブジェクトをリストアップしてくれました。
検査可能なオブジェクトをリストアップしてくれました。
日本語で聞いてみます。
select ai agent PRODUCTSテーブルのカラム定義を表示し、さらにこのテーブルを参照または依存しているすべてのデータベースオブジェクトを一覧で 示してください。;
回答を日本語にするように指示文に加えてみます。
select ai agent order_itemsテーブルの主キーは何ですか?また、IDENTITY列は使われていますか?日本語で回答してください。;
日本語で回答するよう指示を出すと、日本語で回答してくれました。
オーダー・アイテムテーブルの主キーはITEM_ID列であり、IDENTITY列は使用されています。ITEM_ID列はNUMBER型で、GENERATED BY DEFAULT AS IDENTITYで自動的に生成されます。
単にテーブル定義を取得するだけでなく、その内容を理解したうえで自然な日本語で回答してくれました。主キーの特定やデータ型、さらにIDENTITY列の有無や生成方法まで含めて整理して回答しており、単なるメタデータ参照を超えて「意味のある説明」に変換しています。従来であればDDLを確認して人が読み解く必要があった情報を、自然言語の質問だけでここまで分かりやすく把握できるのは非常に実用的です。
エージェントの内部動作を確認してみる
続いて、問い合わせをした時にエージェントがどのように機能しているかを確認してみます。
select ai agent このスキーマに含まれるテーブルの一覧と、それぞれの役割を推測して説明してください。日本語で回答して。;
回答
このスキーマには、ORDERSテーブル、ORDER_ITEMSテーブル、PRODUCTSテーブルが含まれています。
ORDERSテーブルは注文情報を格納するテーブルであり、ORDER_ITEMSテーブルは注文アイテム情報を格納するテーブルであり、PRODUCTSテーブルは商品情報を格納するテーブルです。ORDER_ITEMSテーブルの主キーはITEM_ID列であり、IDENTITY列が使用されています。ORDERSテーブルとPRODUCTSテーブルについても同様の情報が得られました。
USER_AI_AGENT_TOOL_HISTORYビューを確認すると、エージェントがどのツールを利用したのか、入力や出力を確認できます。
今回は、問い合わせ内容に対してエージェントが5つのツールを呼び出し、それぞれに対応するプログラム(SQLベースのメタデータ取得・解析処理)を実行しています。
| ステップ | ツール名 | 入力 | 何をしているか(技術+価値) | 出力(結果) |
|---|---|---|---|---|
| 1 | LIST_OBJECTS_1 | OBJECT_TYPE=TABLE | データディクショナリからテーブル一覧を取得し、探索対象の候補集合を作る | ORDERS / ORDER_ITEMS / PRODUCTS など |
| 2 | LIST_INCOMING_DEPENDENCIES_1 | ORDER_ITEMS | 依存関係ビューを参照し、ORDER_ITEMSを参照しているオブジェクトを逆引き(影響範囲分析) | なし([]) |
| 3 | LIST_OUTGOING_DEPENDENCIES_1 | ORDER_ITEMS | ORDER_ITEMSが依存しているテーブルを特定し、外部キー相当の関係からER構造を推定する | ORDERS / PRODUCTS |
| 4 | SUMMARIZE_OBJECT_1 | ORDERS | 内部で retrieve_object_metadata → ベクトル検索+テキスト検索で関連DDLを抽出し要約、カラム構成や主キーから「注文テーブル」という業務的意味を理解する |
注文情報テーブルの要約 |
| 5 | SUMMARIZE_OBJECT_1 | PRODUCTS | 同様に構造を解釈し、「商品マスタ」という役割を特定する | 商品テーブルの要約 |
■ どこが便利そうか
Select AI Inspectエージェントを使ってみて、特に便利そうだと感じたのは次の点です。
1. 「何がどこで使われているか」を自然言語で追いやすい
テーブル定義を見るだけでなく、依存関係まで含めて確認しやすいのが良いです。
カラム名変更やパッケージ修正の前に、「どこに影響が出るか」を先に聞けるのは、かなり実務向きだと思いました。
2. 初見スキーマや既存PL/SQLの把握に向いている
README では、legacy code や unfamiliar code の inspection / debugging がユースケースとして挙げられています。
「この関数は何をするものか」「この procedure の目的やビジネスルールは何か」といった既存のパッケージや関数が何のためにあるのかの問いに使えるのは、保守運用の文脈でも相性が良さそうです。
3. ただの説明だけでなく、ドキュメント生成やテスト生成にもつながる
Inspect は、要約や PLDoc コメント生成、テストケース生成といった用途も想定されています。
単なる “見る” ツールというより、理解 → 変更影響確認 → ドキュメント整備 までつながる入口として使えそうです。
■ おわりに
今回は、Oracle が公開している Select AI Pre-Built AI Agents の中から、Select AI Inspect を見てみました。
Pre-Built AI Agents は、Select AI Agent をゼロから組む前に試せる実装サンプルとして分かりやすく、その中でも Inspect は DBオブジェクトの理解、依存関係の把握、変更影響の確認 という、かなり現実的な用途に使えそうなエージェントだと感じました。
利用しているOracle Database について
「この table / package / function が結局何なのかをもっと自然に調べたい」
という場面がある場合に、一度試してみる価値はありそうです。
Pre-Built AI Agents では、他にも便利なエージェントが提供されているのでぜひ使ってみてください!









