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 クエリ完結。前の回答は引き継がれない¹
回答フォーマットの安定性	毎回同じ 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 つのアプローチが今後は融合していく方向性が見えます。

参考

AIプロファイルで会話機能を有効にする、あるいはSelect AI Agentを利用することで、1クエリ完結ではなく文脈（コンテキスト）を維持した対話も可能です ↩