1. はじめに
前回の記事（Oracle Autonomous AI Database の MCPサーバを Claude Desktop につないで「いま重いSQL」を聞けるようにしてみた）では、MCP サーバを使って Oracle ADB に「いま重いSQL」を自然言語で問い合わせる仕組みを作りました。
ところで、Oracle ADB には SELECT AI という自然言語 → SQL 変換機能も組み込まれています。外部のクライアントツールを用意しなくても、SQL Worksheet から SELECT AI 重いSQLを教えて と打つだけで AI が SQL を生成して実行してくれます。
では、同じ「いま重いSQL上位3件教えて」というユースケースで両者を比べてみます。
SELECT AI の主なアクション
| 構文 | 動作 |
|---|---|
SELECT AI <自然言語> |
自然言語 → SQL に変換して実行。結果セットを返す |
SELECT AI SHOWSQL <自然言語> |
変換した SQL を表示するだけ（実行しない） |
SELECT AI NARRATE <自然言語> |
実行結果を自然言語で要約して返す |
今回の検証ゴール
| # | 検証項目 |
|---|---|
| 1 | SELECT AI でも V$SQLAREA を使った「TOP SQL」クエリが自然言語で実行できるか |
| 2 | 同じ質問を MCP と SELECT AI それぞれに投げ、回答品質を比較できるか |
| 3 | 「どちらをどの場面で使うべきか」を実測結果に基づいて整理できるか |
結論先出し
- SELECT AI の NARRATE は動いた。分析指示を加えると
USE_NLヒントや全表スキャン（FTS）など SQL テキストを読んだ診断が出てきた - ただし「設定するまでの障壁が多い」「回答フォーマットが毎回変わる」「会話を継続できない」という実用上の制約が明確になった
- DBA が日常的に深掘りしながら使うユースケースは MCP が優位。SQL Worksheet から手軽にワンショットで聞くなら SELECT AI が手軽
2. 検証環境と全体像
| 項目 | 内容 |
|---|---|
| マシン | Windows 11 Pro |
| DB | Oracle Autonomous AI Database (Serverless) / ap-tokyo-1
|
| DB ユーザ |
dba_copilot（前回記事で作成済み） |
| SELECT AI プロバイダー | Google Gemini (gemini-2.5-flash) |
| 負荷シナリオ | 前回記事③（articles/2026-04-30）の load_test を流用 |
Geminiを利用したのは今回は無料でAPIを実行できるからです。利用できる LLM は SELECT AI の AI プロバイダと LLM の選択 にあるとおり、 Anthropic/Claude なども利用できます。
MCP のフロー
SELECT AI のフロー
SELECT AI は DB サーバー自身が Gemini API を呼びに行きます。MCP はクライアント側（Claude Desktop）が外部 API を呼ぶのと対照的です。
3. SELECT AI の準備
3.1. 必要な権限の付与（ADMIN で実行）
-- ADMIN で実行
GRANT EXECUTE ON DBMS_CLOUD TO dba_copilot;
GRANT EXECUTE ON DBMS_CLOUD_AI TO dba_copilot;
また、DB サーバーから Gemini API への外部接続を許可するため、ネットワーク ACL の設定も必要です。
-- ADMIN で実行：外部 HTTPS 接続を許可
BEGIN
DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
host => '*',
ace => xs$ace_type(
privilege_list => xs$name_list('http'),
principal_name => 'DBA_COPILOT',
principal_type => xs_acl.ptype_db
)
);
END;
/
MCP との違い：MCP（Claude Desktop）はクライアント側が外部 API を呼ぶため、DB 側のネットワーク ACL 設定は不要でした。SELECT AI は DB サーバー自身が外部 API を呼ぶため、この設定が必要になります。
hostを * にしているのはテスト環境のため、本番などでは適切に設定しましょう。
3.2. AI プロファイルの作成（dba_copilot で実行）
Google AI Studio で取得した API キーを使って資格情報とプロファイルを作成します。
-- dba_copilot で実行
BEGIN
DBMS_CLOUD.CREATE_CREDENTIAL(
credential_name => 'GEMINI_CRED',
username => 'GOOGLE',
password => 'AIzaSy...' -- Google AI Studio の API キー
);
END;
/
BEGIN
DBMS_CLOUD_AI.CREATE_PROFILE(
profile_name => 'GEMINI_PROFILE',
attributes => '{
"provider": "google",
"credential_name": "GEMINI_CRED",
"model": "gemini-2.5-flash",
"max_tokens": 4096,
"object_list": [
{"owner": "DBA_COPILOT", "name": "V_TOP_SQLAREA"}
]
}'
);
END;
/
EXEC DBMS_CLOUD_AI.SET_PROFILE('GEMINI_PROFILE');
max_tokens: 4096 は適切に設定してください。デフォルトのまま実行すると回答が途中で切断されました。プロファイル作成時に明示的に指定してください。
3.3. V$SQLAREA のラッパービュー（ADMIN で実行）
SELECT AI は「テーブル/ビューのカラム定義を読んで AI に渡す」仕組みです。V$SQLAREA は動的パフォーマンスビューのため通常のデータ辞書クエリではカラム情報が取得できず、AI が列名を推測して無効な SQL を生成してしまいました。そこで dba_copilot スキーマにラッパービューを作成します。
-- ADMIN で実行
CREATE OR REPLACE VIEW dba_copilot.v_top_sqlarea AS
SELECT
sql_id,
SUBSTR(sql_text, 1, 200) AS sql_text_preview,
executions,
ROUND(elapsed_time / GREATEST(executions,1) / 1e6, 3) AS elapsed_per_exec_sec,
ROUND(cpu_time / GREATEST(executions,1) / 1e6, 3) AS cpu_per_exec_sec,
ROUND(buffer_gets / GREATEST(executions,1)) AS gets_per_exec,
ROUND(disk_reads / GREATEST(executions,1)) AS reads_per_exec
FROM sys.v_$sqlarea;
最終的にはラッパービュー不要で実行することができましたが、ここでは全体をラッパービューで確認していたため、ラッパービューについての記載は残します。
3.4. 準備で踏んだエラーの一覧
比較記事として正直に書くと、今回の SELECT AI セットアップでは以下のエラーを順番に踏みました。MCP（設定ファイル 1 本 + OAuth ログインで完了）と比べて、DB 側の設定工数が多い点として記録しておきます。
| # | エラー | 原因 |
|---|---|---|
| 1 | ORA-20401: Authorization failed |
特定モデルのリージョン制限、または IAM 権限設定の問題（今回は OCI Gen AI の Tokyo リージョン未対応が原因） |
| 2 | ORA-24247: Network access denied |
DB の ACL 設定が必要 |
| 3 | ORA-24244: invalid host or port |
ACL のポート指定形式が ADB 非対応 |
| 4 | 回答が途中で切断 |
max_tokens のデフォルト値が小さい |
4. 同一ユースケースで比較する
4.1. SELECT AI SHOWSQL ─ 生成 SQL の確認
まず SHOWSQL で Gemini が生成する SQL を確認します。
SELECT AI SHOWSQL いま重いSQL上位3件教えて;
生成された SQL:
SELECT
t."SQL_ID" AS "SQL_ID",
t."SQL_TEXT_PREVIEW" AS "SQL_TEXT_PREVIEW",
t."ELAPSED_PER_EXEC_SEC" AS "ELAPSED_TIME_PER_EXEC_SEC",
t."CPU_PER_EXEC_SEC" AS "CPU_TIME_PER_EXEC_SEC"
FROM
"DBA_COPILOT"."V_TOP_SQLAREA" t
ORDER BY
t."ELAPSED_PER_EXEC_SEC" DESC
FETCH FIRST 3 ROWS ONLY
ORDER BY elapsed DESC と FETCH FIRST 3 ROWS ONLY は正しく生成されています。ただし、ビューが持つ 7 列のうち AI が選んだ 4 列のみが返ります。
MCP の GET_TOP_SQL_TOOL は関数の中で返却列が固定されているため、毎回同じ 7 列が返ってきます。今回の実行では 4 列が返りました。返却列は AI の判断で決まるため、実行ごとに変わる可能性があります。なお、NARRATE は SHOWSQL とは別タイミングで SQL を生成するため、実際に NARRATE が使った SQL はここに示した例と列構成が異なる場合があります。
4.2. SELECT AI NARRATE ─ MCP の「読み解き」との比較
記事②のシナリオ A と同一プロンプトを両者に投げて回答を並べます。
プロンプト（共通）: 「いま重いSQL上位3件教えて」
MCP（Claude Desktop）の回答（記事②より）
- 3 件とも
Buffer Gets ≒ Disk Reads（ヒット率ほぼゼロ）でディスクから毎回読み直していると診断 -
Elapsed > CPUの差が大きく、I/O 待ちが支配的と特定 - 検索条件にインデックスが整備されていない可能性が高い
- 次アクション: 「この SQL の実行計画を確認」「
APP_TEST_USERSのインデックス一覧を確認」
SELECT AI NARRATE（Gemini）の回答（今回）
いま最も負荷の高いSQLは以下の3件です。
SQL_ID: dvc6hs2j7b1p5（約 2,146 秒 / Elapsed のほぼ全てが CPU / Buffer Gets: 約 4.2 億 / Disk Reads: なし）
ループ内で結合とカウントを行う SQL です。SQL_ID: 5yvxavxrvg74k（約 185 秒 / Disk Reads: 約 4 億 / Buffer Gets: 約 4 億）
ループ内で全表スキャンと大量の集計を行う SQL です。SQL_ID: 6var1rj5w7949（約 87 秒 / Buffer Gets: 約 1,700 万 / Disk Reads: なし）
結合されたテーブルからレコード数を数える SQL です。
回答品質の比較
V$SQLAREA は累積統計のため、同じ負荷スクリプトでも蓄積状態によって TOP 3 の SQL ID は変わります。記事②と今回のテストで SQL ID は異なりますが、SQL #2（5yvxavxrvg74k）で Buffer Gets ≒ Disk Reads（約 4 億 / 約 4 億）という記事②と同じパターンが現れたため、この SQL を軸に分析アプローチを比較します。
| 観点 | MCP（Claude） | SELECT AI（Gemini）短プロンプト |
|---|---|---|
| 回答スタイル | 診断的（問題の根因を特定） | 記述的（メトリクスと SQL の動作を説明） |
| メトリクスの解釈 |
Buffer Gets ≒ Disk Reads → 「ディスクから毎回読み直している」と診断 |
SQL の動作（全表スキャン等）は説明したが、Buffer Gets ≒ Disk Reads から I/O ボトルネックを根因として診断するまでには至らない |
| I/O 待ちの特定 |
Elapsed > CPU → 「I/O 待ちが支配的」と明言 |
言及なし |
| 問題点の明示 | 「インデックス整備不足の可能性」と明言 | 問題点を特定しない |
| 次アクションの提示 | 実行計画確認・インデックス確認を明示 | 言及なし |
| 会話の継続 | 「その SQL の実行計画も見せて」と深掘り可能 | 1 クエリ完結。前の回答は引き継がれない1 |
| 回答フォーマットの安定性 | 毎回同じ JSON 構造を整形 | 同一プロンプトでも文体・詳細度が変化する |
| 返却データの構造 | 毎回同じ 7 列（構造化） | AI が選んだ列のみ（今回は 4 列） |
同じ負荷・同じプロンプトに対して、MCP（Claude Desktop）は Buffer Gets ≒ Disk Reads というパターンから「ディスクから毎回読み直している」「I/O 待ちが支配的」と根因を診断し、次アクションまで提示しました。SELECT AI NARRATE（Gemini）は SQL #2（5yvxavxrvg74k）で同じデータパターンを前にしながらも、動作の記述に留まりました。
SELECT AI NARRATE に「各 SQL の Elapsed Time・Buffer Gets・Disk Reads の傾向から問題点と次のアクションを提案してください」という分析指示を加えると、以下のような診断が得られました。
-
SQL #2（
5yvxavxrvg74k）: 「Buffer Gets と Disk Reads がともに 4 億 → ハードディスクからの大量読み込みがボトルネック」— MCP の「Buffer Gets ≒ Disk Reads → ディスクから毎回読み直している」と実質同等 -
SQL #1（
dvc6hs2j7b1p5）: 「JOIN処理とループ処理が原因。USE_NLヒントが最適でない可能性があり、削除を検討」 -
SQL #3（
6var1rj5w7949）: 「USE_NLヒントとBETWEEN 1 AND 5の組み合わせがデータ量に対して非効率な可能性」
分析の質は同等でも、MCP は短いプロンプトで自律的にここまで到達するのに対し、SELECT AI では分析指示を明示する必要がある点が実用上の差です。
5. 比較・考察
5.1. 設計思想の違い
2 つのアプローチは「何を AI に渡すか」という設計思想が根本的に異なります。
| 軸 | MCP | SELECT AI |
|---|---|---|
| AI に渡すもの | ツール定義（関数名・引数の説明） | テーブル/ビューのスキーマ定義 |
| AI がやること | 引数を組み立てて関数を呼ぶ | SQL 全体を毎回生成する |
| 実行されるもの | 事前に設計した PL/SQL 関数 | AI が生成した SQL（毎回異なる可能性） |
SELECT AI はこの「スキーマ定義」のみから文脈を推論するため、実運用では3.3節で触れたような DB側（テーブルやビュー）へのアノテーションによる事前の意味付けが重要となります。MCPの「対話の中で文脈を推論・補完できる」柔軟性との根本的な違いがここにあります。
MCP は「何を実行するかを開発者が設計し、AI は意図を解釈して引数を渡す」モデルです。SELECT AI は「AI がスキーマを見て SQL を組み立てる」モデルです。
5.2. SELECT AI が意外と良かった点
-
SQL テキスト参照の精度: 分析指示を付加すると、
USE_NLヒントや全表スキャン（FTS）といった SQL テキスト内の手がかりを読んで問題点を特定した -
I/O ボトルネックの識別:
Buffer Gets ≒ Disk Readsのパターンに対して「ハードディスクからの大量読み込みがボトルネック」と診断でき、MCP と実質同等の結論を出した（ただし明示的な分析指示が必要） -
セットアップの少なさ（接続後）: プロファイルとビューさえ作れば SQL Worksheet から
SELECT AI NARRATEの 1 行で動く
5.3. MCP が際立つ場面
会話の継続性が最大の違いです。
MCP（Claude Desktop）では「TOP SQL → その SQL の実行計画を見せて → 待機イベントも確認して」という一連の深掘りが 1 つのスレッドで完結します。記事③で実装した GET_WAIT_EVENTS_TOOL / GET_SQL_PLAN_TOOL との連携がこの典型例です。
SELECT AI では各クエリが独立しており、「前の NARRATE の結果を踏まえて」という指示は機能しません。
また、返却データの安定性も実用上の差です。MCP の GET_TOP_SQL_TOOL は常に同じ 7 列（elapsed_per_exec_sec / cpu_per_exec_sec / gets_per_exec / reads_per_exec 等）を返すため、結果を downstream で処理したり、複数回の結果を比較したりするのが容易です。SELECT AI の返却列は AI の判断に委ねられます（§4.1 参照）。
6. どちらをどの場面で使うか
| 場面 | 推奨 | 理由 |
|---|---|---|
| インシデント初動で「とりあえず何が重いか」を確認したい | SELECT AI | SQL Worksheet で即実行。設定済みなら 1 行で動く |
| 重い SQL → 実行計画 → 待機イベントと深掘りしたい | MCP | 会話の継続性が必須 |
| DBA 以外（アプリ開発者・運用担当）にも使わせたい | MCP | Claude Desktop を配布するだけ。DB 設定は共通のまま |
| 業務テーブルの自然言語クエリも併用したい | SELECT AI | 業務テーブルの SELECT AI との共存が自然 |
| DB 外部のネットワーク設定を変えられない環境 | MCP | ACL 設定が不要（クライアント側で接続） |
| 結果を構造化データとして後続処理に渡したい | MCP | 関数の返却値が固定スキーマ |
組み合わせる選択肢もあります。「SELECT AI で素早くワンショット確認 → 怪しい SQL が見つかったら Claude Desktop で深掘り」という使い分けが現実的かもしれません。
7. まとめ
| # | 検証項目 | 結論 |
|---|---|---|
| 1 | SELECT AI でも「TOP SQL」クエリが自然言語で実行できるか | 可能。ただし V$SQLAREA は直接使えず、ラッパービューが必要 |
| 2 | MCP と SELECT AI の回答品質を比較できるか | 比較できた。短プロンプトでは MCP が診断まで自律的に到達。分析指示を加えれば SELECT AI も同等の診断を出せる。会話継続性・返却構造の安定性は MCP が優位 |
| 3 | 場面別の選択指針を整理できるか | 整理できた。「ワンショット確認」は SELECT AI、「深掘り・連携」は MCP |
SELECT AI の NARRATE は、分析指示を加えれば MCP と同等の診断を出せる場面もありました。一方で、短いプロンプトでの自律的な分析・会話継続性・返却列の安定性・セットアップ工数という実用面では MCP が優位です。どちらが「正解」というより、用途によって使い分けるのが現実的な結論です。
本記事執筆中（2026-04-30）、Oracle が Select AI 事前構築済みAIエージェント を発表しました。
今回検証した SELECT AI NARRATE の「NL to SQL → 結果を説明」という機能を発展させた NL2SQL Data Retrieval Agent が含まれており、曖昧さへの対処・チャート生成・Web 検索連携などが追加されています。また「Autonomous AI Database MCP Server を通じて活用することもできる」とされており、本記事で比較した SELECT AI と MCP の 2 つのアプローチが今後は融合していく方向性が見えます。
参考
- MCPサーバーの使用 | Oracle Autonomous AI Database Serverless
- SELECT AI の概要 | Oracle Docs
- 前回記事①: MCPサーバーと統合された Oracle Autonomous AI Database を使ってみた
- 前回記事③: oracle/skills を MCP と組み合わせると何が変わるか — リアルタイム TOP SQL 解析で Skill の効果を検証する