「いま重い SQL を 3 件教えて」を聞ける Oracle 公式 4 経路の横ぐし比較 ─ ユーザー層別の選択ガイド

Last updated at 2026-05-30Posted at 2026-05-26

1. はじめに

シリーズの位置づけ

「いま重い SQL を 3 件教えて」～の前回の記事が長くなりすぎてしまったので、分割しました。。

#	経路	過去記事
1	SELECT AI	Oracle ADB に「重い SQL 教えて」と聞く 2 つの方法 ─ SELECT AI と MCP サーバを同一ユースケースで比較してみた
2	ADB 26ai 組み込み MCP	Oracle Autonomous AI Database の MCPサーバを Claude Desktop につないで「いま重いSQL」を聞けるようにしてみた
3	SQLcl MCP Server	Claude Code が DBA になる ─ oracle/skills × SQLcl MCP で Oracle 26ai を自律診断してみた
4	OCI Database Tools MCP Server	「いま重い SQL を 3 件教えて」を OCI Database Tools MCP Server にお願いしてみた
前回（多段会話実測）	4 経路の Claude ツール選択を 3 ターン実測	「いま重い SQL を 3 件教えて」を Claude × Oracle 公式 4 経路で 3 ターン会話してみた

前回記事では「同じ問いを 3 ターン続けて Claude に投げ、ツール選択がどう変わるか」に焦点を当てました。本記事はそこから切り出した設計選択ガイドです。「実機挙動はわかったが、結局どの経路を誰に渡せばよいか」という問いを扱います。

結構主観が入ってるので、エンプラでちゃんと公式に則って進めたい方は公式情報を参照しましょうね！

結論先出し

設計の 2 軸は「LLM 自由度」と「認証認可粒度」: SQLcl-MCP は LLM に最大の自由を与え、OCI DB Tools MCP は最も細かい認証認可を持つ──この 2 軸が経路選択の骨格です
LLM に選ばれやすい経路と、会話を深掘りできる経路は別物: GET_TOP_SQL_TOOL（OCI DB Tools MCP の Custom SQL Tool）は浅い問いで圧倒的に有利、SQLcl-MCP は多段会話に強い
複数 MCP を同じ LLM クライアントに並存させると揺らぐ: 異なる MCP 製品を同時接続するとツール選択が非決定論的になります。ユースケースごとに 1 経路に絞るのが素直な運用です

想定読者

Oracle ADB / OCI で MCP 系の導入を検討している設計者・DBA
「どの経路をどのユーザーに渡すべきか」が知りたい人
前回記事で実機挙動を確認して「で、どう設計すればいいか」を求めている人

2. 4 経路のおさらい

シリーズで扱ってきた 4 経路を簡単に整理します。各経路の詳細は個別の過去記事を参照してください。

#	経路	対象 DB	役割の置き場所	サーバ実体
1	SELECT AI	ADB-S（Autonomous Database Serverless）	DB 内 LLM が NL→SQL を自動生成	ADB 自身（`DBMS_CLOUD_AI.GENERATE`）
2	ADB 26ai 組み込み MCP	ADB-S 26ai（公式 Docs は Serverless 配下）	DB 自身が MCP サーバ化、外部 LLM が SQL を書く	ADB の MCP エンドポイント
3	SQLcl MCP Server	Oracle DB 全般（ADB-S / ADB-D / Base DB / オンプレ等、SQLcl が接続できる Oracle DB）	ローカル CLI が MCP サーバ、外部 LLM が SQL を書く	`sql -mcp`（SQLcl 26.1）
4	OCI Database Tools MCP Server	OCI Database Tools Connection が対応する DB（ADB-S / ADB-D / Base DB / MySQL HeatWave 等）	OCI マネージドの MCP サーバ、DBA が定義したレポートや SQL を LLM が呼ぶ	OCI Database Tools サービス

本記事のシリーズで検証してきた経路は、いずれも ADB-S（Autonomous Database Serverless） で動作確認しています。本記事内で単に「ADB」と表記している場合は ADB-S を指します。ADB-D（Dedicated）での SELECT AI / ADB 26ai 組み込み MCP の動作は本シリーズの検証範囲外です。

OCI DB Tools MCP は内部に 3 種類のツールセットタイプ（組込み SQL / Custom SQL Tool / Reporting Tool）を持ちます（MCPツールセットの作成）。それぞれ想定ユーザーと設計思想が公式で明確に分かれていますが、本記事では経路選択ガイドの見通しを優先して OCI DB Tools MCP を 1 経路としてまとめて扱います。3 タイプ間の詳細比較は別記事（OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみた）で扱いました。

SELECT AI は LLM クライアント側のツール選択対象ではありません（DB 内で SELECT AI ... 構文として実行されるため）。「LLM がツールを選ぶ」という観点では比較対象外ですが、ユーザー層ごとの経路設計には含めます。

3. 設計思想ベースの 6 観点比較

3.1. 比較表

各経路を 6 つの設計観点で並べます。シリーズの過去記事での実測と、公式 Docs に基づいてまとめています。

観点	SELECT AI	ADB 26ai MCP	SQLcl MCP	OCI DB Tools MCP
① セットアップ工数	中 GRANT・ACL・AI プロファイル・ラッパービュー作成	中 PL/SQL Function 1 本＋`CREATE_TOOL` 登録＋OAuth 初回ログイン	軽 `claude mcp add` 1 コマンド＋接続プロファイル保存	重〜最重 MCP Server 作成 10 ステップ＋ツールセット定義（Reporting Tool は SQL レポートを独立資産として別管理する分、さらに工数大）
② カスタム性	中ラッパービュー＋`object_list` でスキーマに意味付け	中 PL/SQL Function を `CREATE_TOOL` で横展開	低カスタム定義なし、知識は `oracle/skills` で補う設計	高〜最高 1 ツール = 1 SQL（PL/SQL / DML も可）、SQL レポートとして独立資産化すれば複数 DB で再利用可
③ 認証・認可粒度	DB ユーザー＋AI プロファイル単位	DB ユーザー＋OAuth ログイン	SQLcl 接続プロファイル＋DB ユーザー権限のみ	IAM（Dynamic Group / ポリシー）＋Application Role＋個人アクセス・トークン（PAT）、ツールセット単位・メタツール単位の許可ロール（最も粒度細）
④ LLM 自由度	高 DB 内の LLM が毎回生 SQL を生成	低事前設計の PL/SQL Function に引数を渡すのみ、戻り値は固定 JSON	最高 LLM が生 SQL を書いて任意ビューを叩ける	低〜中事前承認された SQL / レポートのみ実行。Reporting Tool は `report_list` → `report_execute` で動的選択
⑤ 応答品質の決定要因	ビューの `COMMENT ON` 列メタ＋プロンプト指示	Function 戻り値の固定スキーマ＋LLM 側の考察	`oracle/skills` の知識（診断順序・観点）＋LLM の組み立て力	ツールセット内のメタ情報設計次第（ツールタイプによりメタ情報の階層数が異なる。詳細は別記事）
⑥ 向くユーザー層	業務ユーザー / DBA Database Actions / SQL Worksheet から即実行可	DBA / 運用 / 企画 MCP クライアント配布で非 DBA にも開放しやすい	開発者 / DBA の PoC・自律診断	幅広い層ツールタイプにより DBA（組込み SQL）/ 開発者（Custom SQL Tool）/ ビジネスユーザー・アナリスト（Reporting Tool）と公式で分離（公式）

3.2. 読み解きポイント

観点④「LLM 自由度」が両極端

SQLcl-MCP は LLM が生 SQL を書いて任意のビュー・DBA_HIST を叩けます。一方、ADB 26ai MCP と OCI DB Tools MCP は「事前承認された SQL / PL/SQL Function / レポートのみ実行」の設計で、LLM は引数を組み立てる、もしくは公開済みレポート集合から選ぶだけです。この差はセキュリティと柔軟性のトレードオフを直接表しています。

観点⑤「応答品質の決定要因」は経路によって思想が大きく異なる

SELECT AI は列メタ（COMMENT ON）とプロンプト指示で誘導、ADB 26ai MCP は Function 戻り値の固定スキーマ、SQLcl MCP は外部知識（oracle/skills）に寄せる設計、OCI DB Tools MCP はツールセットのメタ情報設計次第──と方針が分かれます。どれが優れているかではなく、「DBA がどこまでメタデータを整備するか」という運用負荷の差として現れます。

観点③「認証・認可粒度」は OCI DB Tools MCP が頭一つ抜ける

IAM Dynamic Group / ポリシー / Application Role / PAT の組み合わせで、ツールセット単位・メタツール単位まで公開範囲を絞れます。他の 3 経路は DB ユーザー権限か OAuth が認証の主体で、LLM クライアントへの公開範囲は粗め、または DB 権限に依存します。

4. 実機検証由来の 2 観点

前回記事の 4 セッション × 3 ターン実測から、設計に直接効く 2 観点を補足します（詳細は前回記事の 4〜5 章を参照）。

4.1. 観点 ⑦: LLM に選ばれやすさ

「いま重い SQL を 3 件教えて」という浅い・直接的な問いへの選択回数（4 セッション）を評価します。

経路	評価	実測
SELECT AI	—	ツール選択対象外
ADB 26ai MCP	○	1/4 で `EXECUTE_SQL` が選ばれた
SQLcl MCP	×	T1 では 4 セッション通じて出番ゼロ
OCI DB Tools MCP	◎（Custom SQL Tool）/ ×（Reporting Tool）	`GET_TOP_SQL_TOOL`（Custom）が 3/4 で選ばれた一方、`report_execute`（Reporting）は 4/4 で選ばれず

GET_TOP_SQL_TOOL という名前が「重い SQL」「TOP SQL」という問いと意味的に直結するため、名前マッチが効いています（前回記事 5.1 章）。同じ OCI DB Tools MCP でもツールタイプによって選ばれやすさが大きく分かれた点が、本記事の経路選択ガイドの根拠になります。

4.2. 観点 ⑧: 会話深掘り耐性

T2「実行計画を見せて」/ T3「チューニング案を出して」という派生・分析質問への自己完結度を評価します。

経路	T2（実行計画）	T3（チューニング案）	総合
SELECT AI	—	—	—
ADB 26ai MCP	◎	△	○
SQLcl MCP	◎	◎	◎
OCI DB Tools MCP	△（Custom）/ ×（Reporting）	△（Custom）/ ×（Reporting）	△

SQLcl MCP は生 SQL を書く自由度が最高のため T2 も自然に対応でき、T3 では oracle/skills との連携で品質の高いチューニング推奨が返ります。OCI DB Tools MCP の Reporting Tool は「実行計画レポート」「チューニング案レポート」を事前定義しない限り完全に出番がなく、DBA 寄りの深掘り問いには向きません。

観点⑦⑧のトレードオフが経路選択の核心です。「LLM に選ばれやすい = 浅い問いに強い」（OCI DB Tools MCP の Custom SQL Tool）と「深掘りに強い = 汎用性が高い」（SQLcl-MCP）は基本的に別の経路です。

5. ユーザー層別の経路選択ガイド

5.1. 推奨経路マトリクス

6+2 観点の比較と実機挙動から、ユーザー層ごとの推奨経路を整理します。

前提: この推奨は対象 DB によって選択肢が変わります（2 章の「対象 DB」列を参照）。

ADB-S: 4 経路すべてが選択肢
ADB-D: SQLcl MCP / OCI DB Tools MCP が中心（SELECT AI / ADB 26ai 組み込み MCP は本シリーズ未検証）
Base DB: SQLcl MCP / OCI DB Tools MCP
オンプレ Oracle DB: SQLcl MCP が中心

以下の表は ADB-S を前提とした 4 経路フル選択肢の場合の推奨です。

ユーザー層	第 1 推奨	第 2 推奨	推奨の主な理由
業務ユーザー（SQL を書かない）	SELECT AI	OCI DB Tools MCP（Reporting Tool）	Database Actions / SQL Worksheet から NL で即実行可。プロファイル単位での権限分離も可能（※DB バージョンが 21c 以下の Base DB / オンプレ環境では SELECT AI が利用できないため、第 2 推奨の OCI DB Tools MCP が実質的な第 1 選択肢となります）
アプリ開発者	ADB 26ai MCP	OCI DB Tools MCP（Custom SQL Tool）	DBA が事前設計した PL/SQL Function / Custom SQL を LLM 経由で呼び出す。固定 JSON 戻り値でアプリ側から扱いやすい（※DB バージョンが 21c 以下の場合は ADB 26ai MCP が利用できないため、第 2 推奨の OCI DB Tools MCP が実質的な第 1 選択肢となります）
DBA（個人作業 / 自律診断）	SQLcl MCP + oracle/skills	ADB 26ai MCP	生 SQL を書ける自由度と `oracle/skills` の知識ベースで深い診断が可能
エンタープライズ DBA（統制環境）	OCI DB Tools MCP	—	IAM 統制 + Application Role でツールタイプ単位の公開範囲分離。OCI Audit への統合も容易

5.2. 補足: Reporting Tool の実運用上の注意

OCI DB Tools MCP の Reporting Tool（report_execute）は観点⑦評価が「×（4/4 で選ばれず）」でした。ただしこれは「設計が悪い」ではなく、公式が想定するユーザー層と今回のテストが合っていなかったことによる、予想通りの結果です。

Reporting Tool は公式で「ビジネスユーザー / アナリスト向け」と位置付けられています。今回のテスト（「重い SQL 特定」「実行計画」「チューニング案」）は DBA 寄りの問いで、想定ユーザー層と一致しません。

【追記】ただし 0/4 の主因はユーザー層よりも「名前マッチの競合」でした
後日の検証で、Custom SQL Tool（GET_TOP_SQL_TOOL）を公開対象から外すと、同じ「いま重い SQL を 3 件教えて」でも Claude は report_list → report_execute を自力で選びました（OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみた）。「DBA 寄りの問いだから選ばれない」だけではなく、名前マッチする Custom SQL Tool が同居していたことが 0/4 の主因だった、と切り分けられています。

業務ユーザー向けに Reporting Tool を実際に活用する具体的な設計パターン（Application Role 等での公開範囲制御）は、OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみたで扱いました。

6. 複数 MCP を同じ LLM クライアントに並存させたときの注意

ADB 26ai MCP / SQLcl MCP / OCI DB Tools MCP という異なる製品を同じ LLM クライアントに同時接続する構成では、前回記事でツール選択が揺らぐことを実測しました（前回記事 4〜5 章）:

        S1 (ALL ON)         S2 (ALL ON)             S3 (ALL ON)
T1   →  adb.EXECUTE_SQL     oci.GET_TOP_SQL_TOOL    oci.GET_TOP_SQL_TOOL
T2   →  adb.EXECUTE_SQL     sqlcl.run-sql → adb     adb.MY_RUN_SQL_TOOL

同じ Sonnet 4.6・同じプロンプト・同じ DB 状態でも、セッションをまたぐとツール選択が変わっています。特に T2 は 3 セッションすべてで異なるツールが選ばれました。

これは各 MCP が独立した製品・認証モデル・ツール設計を持つことに起因します。Oracle の公式 Docs は現時点で「複数の MCP を同じ LLM クライアントに同時接続する」という構成を明示的に想定していません（各製品の Docs はそれぞれ単独での利用を前提として書かれています）。

複数の異なる MCP サーバを同じ LLM クライアントに並存させると、どのツールが選ばれるかが非決定論的になる可能性があります。本番環境ではそれぞれのユーザや環境によって利用できるツールを限定する形になると思いますので、あくまで検証環境ではこうなったよ、というように捉えて頂ければと

なお、同じ OCI DB Tools MCP 内のツールセットタイプ（組込み SQL / Custom SQL Tool / Reporting Tool）の並存は Oracle 公式の標準構成であり、本章で扱う「異なる MCP 製品の並存」とは別の話です。OCI DB Tools MCP 単体の内部設計（3 タイプの違い、Application Role による公開範囲制御など）は別記事（OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみた）で扱いました。

7. まとめ

6+2 観点の比較と実機挙動から見えたポイントを整理します。

ポイント	内容
設計の 2 軸	LLM 自由度（SQLcl-MCP が最高、ADB 26ai MCP / OCI DB Tools MCP が低〜中）と認証認可粒度（OCI DB Tools MCP が最細）
LLM 選択のリアル	OCI DB Tools MCP の Custom SQL Tool（`GET_TOP_SQL_TOOL`）が浅い問いで圧倒的。Reporting Tool は DBA 寄りの問いでは選ばれない──これは公式想定どおりの挙動
会話深掘り耐性	SQLcl-MCP が最強。OCI DB Tools MCP は事前定義の範囲を超えると試行錯誤が必要
並存の注意	異なる MCP 製品を同じ LLM クライアントに並存させるとツール選択が揺らぐ → ユースケースごとに 1 経路に絞るのが素直

OCI DB Tools MCP 単体の内部設計（3 タイプのツールセット、Application Role による公開範囲制御）は本記事のスコープ外とし、別記事（OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみた）で扱いました。

前回も少し触れましたが、今回扱った 4 経路に加え、OCI Generative AI Agents の Private Agent Factory で構築したエージェント経由でも同じ問いに答えられる可能性があります。Private Agent Factory はナレッジベース統合・ツール設計を OCI 側で完結させる形になり、本記事で見た「LLM クライアント側でツール選択が揺らぐ」問題（6 章）に対する別アプローチとして位置付けられます。こちらも機会があれば別途整理する予定です。