1. はじめに
シリーズの位置づけ
「いま重い SQL を 3 件教えて」── Oracle のパフォーマンス分析の入り口にあたる問いです。
このフレーズを Oracle 公式が提供する NL2SQL / MCP 系の各サービス に投げて答えてもらう、という遊びをしばらく続けてきました。
| 経路 | 過去記事 |
|---|---|
| SELECT AI | Oracle ADB に「重い SQL 教えて」と聞く 2 つの方法 ─ SELECT AI と MCP サーバを同一ユースケースで比較してみた |
| ADB 26ai 組み込み MCP | Oracle Autonomous AI Database の MCPサーバを Claude Desktop につないで「いま重いSQL」を聞けるようにしてみた |
| SQLcl MCP Server | Claude Code が DBA になる ― oracle/skills × SQLcl MCP で Oracle 26ai を自律診断してみた |
| OCI Database Tools MCP Server（セットアップ編） | OCI Database Tools MCP Server を Claude Desktop につないでみた |
本記事は最後の OCI Database Tools MCP Server の続編（実用編）です。前回はセットアップして組込み schema_information ツールが動いたところまで。今回は「任意の SELECT を実行できるツールを追加して、本当に『いま重い SQL を 3 件教えて』に答えさせる」のがゴールです。
結論先出し
- 「いま重い SQL を 3 件教えて」に Claude Desktop 経由で OCI Database Tools MCP Server が回答できた
- 前回予告した Custom SQL Tool より、もう 1 つの選択肢 「カスタマイズ可能なレポート・ツール（Reporting Tool）」 のほうが LLM 時代向けに作り込まれた設計だった
- Reporting Tool には Custom SQL Tool には無い LLM 向けのメタ情報（説明・目的・命令・列）と 接続非依存な SQL レポート資産設計があった
- Oracle 公式チュートリアルは Custom SQL Tool しか扱っておらず、Reporting Tool は公式 Docs 側でのみ解説されている隠れキャラ
- 役割分離は強力:
report_sql（裏 SQL を見るツール）は MCP_User に対して 「403 で拒否」ではなく「ツール一覧に公開しない」 という最小露出設計が実装されていることを実測で確認
検証ゴール
| # | 検証項目 | 達成判定 |
|---|---|---|
| 1 | SQL レポート（独立サービス）と Reporting Tool 型ツールセットを作成し、Claude Desktop から呼び出せるか | ツール一覧に report_list / report_execute が増え、呼出成功 |
| 2 | 「いま重い SQL を 3 件教えて」に Claude が自律的に正しいツール選択・パラメータ組み立てで応答できるか | ツール名を一切指定しない自然言語プロンプトで TOP 3 SQL が返る |
2. 前回のおさらい: 3 ツールタイプの整理
OCI Database Tools MCP Server には 3 種類のツールセットタイプがあります。
| タイプ | 公式説明 | 想定用途 | 公式チュートリアルでの扱い |
|---|---|---|---|
| ①組込み SQL ツール | アドホック SQL / PL/SQL スクリプトの実行 | LLM が自由に SQL を組み立てる（schema_information 等） |
言及のみ |
| ②カスタム SQL ツール | ユーザー定義のパラメータ化された SQL/PL/SQL を実行 | 「1 SQL = 1 ツール」で公開、PL/SQL や DML も可 | 詳細に解説（チュートリアル） |
| ③カスタマイズ可能なレポート・ツール | 事前作成済のパラメータ駆動型 SQL レポートを検索・実行 | 承認済み読み取り SQL を LLM に動的公開 | 未収録（公式 Docs 側でのみ） |
前回記事では「組込み SQL ツール」の schema_information まで確認済み。本記事の本題は 3 つ目のタイプです。
実機ではこんな選択画面になっています:
3. 検証環境
| 項目 | 内容 |
|---|---|
| OCI リージョン | ap-tokyo-1 |
| ADB | Oracle AI Database 26ai Enterprise Edition 23.26.2.1.0 |
| DB ユーザー |
DBA_COPILOT（前回記事から流用） |
| MCP Server |
dbtools-mcp-server（前回記事の Phase 2 で作成） |
| Application Role |
MCP_User（自分のユーザに付与済み） |
| OS | Windows 11 Pro |
| Node.js | v18+（npx mcp-remote 経由） |
4. SQL レポート（独立サービス）の作成
ここから本題です。
4.1. SQL レポートは「MCP の外」にある独立サービス
OCI コンソールで Reporting Tool 型のツールセットを作ろうとすると、フォームには 「コンパートメント内の SQL レポート」 というドロップダウンが現れます。
ところが何も選択肢がない（「使用可能なデータがありません」と表示される）。「SQL レポート」自体を別画面で先に作る必要があるのです。
ナビゲーション: OCI コンソール > 開発者サービス > データベース・ツール > SQL レポート
ここで気付く 3 つの構造的特徴:
| 特徴 | 観察事実 | 概要 |
|---|---|---|
| ① 接続選択欄がない | 「Database Tools 接続」を選ぶ UI が無い | SQL レポートは接続非依存。1 つの定義を複数 DB で使い回せる |
| ② 目的・命令の入力欄がある | Custom SQL Tool には無かったフィールド | LLM 向けに「いつ使うべきか」を明示できる |
| ③ 列メタデータを個別に定義できる | 名前・タイプ・説明を 1 列ずつ入れる | LLM が結果スキーマを意味的に理解できる |
これらは Custom SQL Tool には無く、Reporting Tool にしかない設計要素です。
4.2. 入力した値
完成形のスクリーンショット:
Oracle 公式が画面上で「AI 向け」と明言している
スクショ冒頭の英語キャプションに注目: 「Create a Database SQL Report with a clearly defined purpose and instructions intended for consumption by AI applications, ...」。
SQL レポートが AI アプリ消費を前提として設計されていることを、Oracle が画面 UI レベルで明示しています。
入力値のうち 再現時にコピペが必要なもの だけを以下に置きます。説明・目的・命令の本文と SQL ソースは上のスクショ通りです。
SQL ソース（コピペ用）
SELECT sql_id,
ROUND(elapsed_time/1000000, 2) AS elapsed_sec,
executions,
buffer_gets,
disk_reads,
SUBSTR(sql_text, 1, 200) AS sql_text_excerpt
FROM V$SQL
ORDER BY elapsed_time DESC
FETCH FIRST :N ROWS ONLY
変数（バインド）
| 名前 | タイプ | 説明 |
|---|---|---|
N |
NUMBER |
返す上位 SQL の件数（1〜50 を推奨。指定がなければ 3） |
列メタデータ（6 列）
LLM が結果スキーマを意味的に理解できるように、列ごとに名前・型・説明を個別に登録します。
| 名前 | タイプ | 説明 |
|---|---|---|
SQL_ID |
VARCHAR2 |
SQL を一意に識別する 13 文字のハッシュ ID |
ELAPSED_SEC |
NUMBER |
この SQL の累計経過時間（秒）。値が大きいほど DB 負荷が高い |
EXECUTIONS |
NUMBER |
この SQL の実行回数。1 回あたりの負荷を見るには ELAPSED_SEC / EXECUTIONS で割る |
BUFFER_GETS |
NUMBER |
バッファキャッシュからの読込回数。論理 I/O 量の指標 |
DISK_READS |
NUMBER |
ディスクからの物理読込回数。物理 I/O 量の指標。多いと I/O ボトルネック候補 |
SQL_TEXT_EXCERPT |
VARCHAR2 |
SQL 本文の先頭 200 文字。長文 SQL は途中で切れる |
「列の説明」を丁寧に書いておくと、後で LLM が結果を要約するときに 「disk_reads が多いから I/O 系のボトルネック」 のように 列の意味を踏まえた考察を返してくれるようです（§6 参照）。
公式 Docs も同じ思想を明言しています:
Tool name および Tool description は、大規模言語モデル(LLM)がツールの目的と機能を理解するのに役立ちます。明確で詳細な説明を提供することで、結果の品質を向上させることができます。
—— MCPツールセットの作成
5. MCP ツールセット（Reporting Tool 型）の作成
SQL レポートが出来たら、それを MCP に公開するための薄いブリッジ層を作ります。
5.1. 入力した値
| 欄 | 入力値 |
|---|---|
| 名前 | perf-report-toolset |
| タイプ | 「カスタマイズ可能なレポート・ツール」 |
| デフォルト実行タイプ | 同期 |
| コンパートメント内の SQL レポート | ルート |
| SQL レポート |
top-sql-by-elapsed ← §4 で作成済み |
| 許可ロール | MCP_User |
完成画面:
5.2. 自動で付いてくる 3 メタツール
タイプを「カスタマイズ可能なレポート・ツール」に切り替えた瞬間、フォーム下部の「ツール」セクションに自動で 3 つのメタツールが現れます。これらが MCP クライアント（Claude Desktop）に公開されます:
| メタツール | 役割 | デフォルト許可ロール |
|---|---|---|
report_list |
利用可能なレポート一覧を取得 | MCP_User / MCP_Operator / MCP_Administrator |
report_execute |
レポートを実行 | MCP_User / MCP_Operator / MCP_Administrator |
report_sql |
レポートの裏の SQL を取得 | MCP_Operator / MCP_Administrator のみ |
役割分離が「最小露出の原則」レベルで実装されている
report_sql（裏の SQL を見るツール）は、ツールセット作成画面のデフォルトで MCP_User が許可ロールから除外されていました。
さらに、MCP_User しか持たない自分のユーザ向けに report_sql を Claude Desktop から直接呼ぼうとしたところ、Claude は report_sql というツール自体が MCP プロトコル経由で取得できるツール一覧に含まれていない ことを確認しました（§6.3 で詳述）。
つまり OCI Database Tools MCP Server は、未許可のツールに対して「403 Forbidden で実行を拒否」ではなく「そもそも MCP tools/list レスポンスから除外」する実装になっています。これは 最小権限の原則 を一歩踏み込んだ 最小露出の原則（principle of least exposure） で、攻撃面を LLM のコンテキストから物理的に消し去る設計です。
5.3. 公式 Docs の表記揺れ（メタツール名）
公式 Docs（MCPツールセットの作成）にはメタツール名がこう書かれています:
| 公式 Docs の名前 | 実機 UI の名前 |
|---|---|
dbtools_list_reports |
report_list |
dbtools_execute_report |
report_execute |
dbtools_get_report_sql |
report_sql |
dbtools_get_tool_request |
（request_status に対応？） |
実機 UI と Docs で表記が違うところは GA 直後らしさを感じます。Claude Desktop に MCP ツールとして見えるのは実機 UI 側の名前です。
6. Claude Desktop からの動作検証
ここが本番です。MCP Server に新しいツールを追加したら、Claude Desktop を完全再起動して反映を待ちます。
設定 > Connectors > oci-dbtools-mcp を開いて、ツール一覧に report_list / report_execute が増えていることを確認:
後述しますが、上のスクショには
GET_TOP_SQL_TOOL（Custom SQL Tool 版）も並んでいます。これは私の作業ミスで残っていたもので、§6.3 で「両ツールが並存していたら Claude はどちらを選ぶか？」という追加検証の起点になりました。
6.1. T1: report_list を単独で叩いてみる
まずは小手調べに、レポート一覧を取得してみます。
プロンプト
oci-dbtools-mcp の report_list ツールを使って、利用可能なレポート一覧を取得して。
結果
返ってきた内容（要点抜粋）:
| 項目 | 内容 |
|---|---|
| レポート名 | top-sql-by-elapsed |
| 説明 | V$SQL から経過時間（elapsed_time）上位 N 件の SQL を返す |
| 用途 | 「重い SQL / 遅い SQL / 負荷の高いクエリ」の素早い特定 |
| 返却カラム（6 件） | SQL_ID / ELAPSED_SEC / EXECUTIONS / BUFFER_GETS / DISK_READS / SQL_TEXT_EXCERPT |
| パラメータ | N (NUMBER) — 返す件数、指定なしの場合は規定値 3 |
この応答から確認できたこと
- ✅ §4.2 で書いた 「命令」フィールドの文章が「用途」として LLM の認識に入っている
- ✅ 「指定がなければ 3」と書いたデフォルト値を Claude が拾った
- ✅ 列ごとの説明（
大きいほど DB 負荷が高い等）が整形された応答に活きている - ✅ 最後に 「実行しますか？」 と確認を取った → メタツール 2 段（list → execute）の自律的な組み立て準備
6.2. T2: 自然言語クエリ（クライマックス）
新しい会話を開いて、ツール名もサーバ名も一切指定しない自然言語で投げます。
プロンプト
いま重い SQL を 3 件教えて
結果
Claude が選んだ経路:
-
oci-dbtools-mcpのreport_executeを選択 -
report_id = <top-sql-by-elapsed の OCID>,n = 3を組み立てて呼び出し - 表形式で 3 件返却 + 自然言語で考察
返ってきた TOP 3（実機データ抜粋）:
| # | SQL_ID | elapsed_sec | executions | buffer_gets | disk_reads | SQL 本文（要約） |
|---|---|---|---|---|---|---|
| 1 | e7eatzxbfgyrn5 |
53 | 1 | 1,732,224 | 16,576 | DBMS_AUTOTASK_PRV.VT_run_autotask |
| 2 | 92aebsfqhfgs7 |
39 | 1 | 1,300,946 | 28,540 |
Continuous Query Gathering 系 |
| 3 | 1bw9swhnigi8 |
28 | 1 | 36,604 | 1,025 |
DBMS_AUTO_INDEX 系 |
そして Claude は、ただ表を出すだけでなく、列の意味を踏まえた考察を添えてきました（要約）:
「これらは Oracle のシステム内部タスクが大半。ユーザーアプリケーションの SQL ではなく、DB の自律メンテナンス（自動タスク・統計収集・自動インデックス管理）が上位を占めている」
この応答が示すこと
- ✅ ツール選択: 自然言語からノーヒントで
report_executeを選択 - ✅ パラメータ抽出: 「3 件」→
n=3を正しく組み立て - ✅ 意味的考察: §4.2 で書いた列の説明（
disk_reads = 物理 I/O 量の指標等）と SQL_TEXT_EXCERPT から、システムタスク vs ユーザー SQL を自律的に区別
この時の検証は Reporting Tool 単独で見えている前提でした
当初の作業ミスで Custom SQL Tool 版（GET_TOP_SQL_TOOL）も作成されていました。Claude のツール選択が「Reporting Tool を自律的に選んだ」ように見えたのは、他の選択肢が見えていなかったからでした。両者並存環境での挙動は §6.3 で。
6.3. T3+: 両ツール並存環境で Claude はどちらを選ぶか
前段: report_sql の不在を Claude に確認
§5.2 で予告したとおり、report_sql ツールは MCP_User からは見えないはずです。実際に Claude Desktop で直接指名してみました:
oci-dbtools-mcp の report_sql ツールを使って、top-sql-by-elapsed レポートの裏の SQL を取得して。
Claude (Sonnet 4.6) は内部でツール検索を実施した上で「mcp__oci-dbtools-mcp__report_sql は現在の MCP サーバーには 存在しないツールでした」と回答。利用可能なのは:
-
report_list/report_execute/GET_TOP_SQL_TOOL/request_status/schema_information
の 5 つのみと判明しました。役割分離は「最小露出の原則」レベルで実装されていることが実機で確認できた瞬間です。
GET_TOP_SQL_TOOL も並んでいた
同時に発覚したのが、上の応答に GET_TOP_SQL_TOOL（Custom SQL Tool 版）が混ざっていたことです。当初フォームを「カスタム SQL ツール」で開いて入力していたものを登録してしまってた模様です。
結果的に 「同じユースケースに対して 複数のアプローチが並存したとき、LLM はどちらを選ぶか」 を実施で観察できる機会となりました。
検証: 両ツールが並んだ状態で Claude はどう選ぶ？
新規セッション（Sonnet 4.6）で、ツール名もサーバ名も一切指定しない、§6.2 と完全に同じプロンプトを投げます:
いま重い SQL を 3 件教えて
Claude (Sonnet 4.6) のツール呼び出し順
| 順 | ツール | サーバ | 結果 |
|---|---|---|---|
| ① | GET_TOP_SQL_TOOL |
oci-dbtools-mcp（Custom SQL Tool） | ❌ Request timed out |
| ② | MY_RUN_SQL_TOOL |
adb-dba-copilot | ✅ 成功 |
事前仮説（「Reporting Tool は 4 階層メタ情報がリッチだから LLM はそちらを優先するはず」）はハズレ。Sonnet 4.6 は Reporting Tool（report_execute）を選びませんでした。まあ、途中で取れれば止めるのは当然の動きではありますが。
最終応答の所見（adb-dba-copilot 経由で返ってきた TOP 3）
最終的に adb-dba-copilot 経由で得た TOP 3 SQL について、Claude は内部タスクを識別する所見を添えてきました:
→ ここでも §4.2 で SQL レポート側に書いた「列の説明」と同等の意味理解が効いていることが分かります（ただし今回は adb-dba-copilot 経由の生 SQL 実行なので、Reporting Tool のメタ情報が直接効いたわけではなく、列名から Claude が一般知識で推論したと考えられます）。
Claude 自身による選択ロジックの説明
追加で「他にも同じ質問に答えられそうなツールはありましたか？なぜそちらではなくこのツールを選んだのか教えて」と聞いたら、Claude (Sonnet 4.6) は自分の選択を表＋文章で説明しました:
応答の要約:
- 5 つのツールが選択肢にあった（GET_TOP_SQL_TOOL / MY_RUN_SQL_TOOL / MY_RUN_SQL_TOOL2 / EXECUTE_SQL / schema_information）
GET_TOP_SQL_TOOLは description が「Returned top N SQL ... by elapsed time from V$SQL」で、質問と直接マッチしていたので最初に試した- タイムアウト時は汎用 SELECT ツール（adb-dba-copilot 側）にフォールバック
report_executeへの言及はなかった
→ つまり Claude のツール選択は「メタ情報の豊富さ」ではなく 「ツール名と description の意味的マッチ」 が支配的でした。GET_TOP_SQL_TOOL は名前自体が "TOP SQL" と質問に直結している一方、report_execute は抽象的で、何のレポートかは別途 report_list で発見する必要がある。Reporting Tool の二段構造（list → execute）は、LLM の最初の検討フェーズでは不利だった、ということです。
副次的な発見: 答えは結局 adb-dba-copilot から返った（マルチ MCP の罠）
最終回答は OCI Database Tools MCP Server の機能ではなく、前回記事の adb-dba-copilot（ADB 26ai 組み込み MCP）の汎用 SELECT ツール から返ってきました。GET_TOP_SQL_TOOL がタイムアウトしたので、LLM がサーバを跨いで代替手段を探した結果です。
これは LLM × MCP 運用設計に大事な意味があると考えてます:
- 複数 MCP サーバを並べて使う環境では、LLM はそれらを意識せず横断的に探索する
- 「OCI DB Tools MCP の動作を測りたい」のに、別サーバが代行してしまうことがある
- 計測検証では MCP サーバを 1 つだけにして 切り分ける、という運用上の知恵が必要
7. 考察: Custom SQL Tool と Reporting Tool の設計差
§4 と §5 で見てきた Reporting Tool の特徴を Custom SQL Tool と並べ、Oracle が両者をなぜ別タイプとして用意したのか、その設計思想の差を整理します。
7.1. 構造の違い
以下の比較表は、OCI コンソールの両ツールセット作成画面と、SQL レポート作成画面、および MCPツールセットの作成 で確認した内容です。
| 観点 | カスタム SQL ツール | カスタマイズ可能なレポート・ツール |
|---|---|---|
| SQL の置き場所 | ツールセット内に直書き | 別サービス（SQL レポート） に資産化 |
| 1 ツール = ? | 1 SQL = 1 MCP ツール（名前付き） | 3 メタツール（list/execute/sql）でレポート群を動的探索 |
| 接続との関係 | ツールセット作成時に SQL を書く（接続はツールセット側） | SQL レポートは接続非依存、複数 DB で再利用可 |
| LLM 向けメタ情報 |
tool description 1 段階 |
説明 / 目的 / 命令 / 列 の 4 段階 |
| ガバナンス | MCP 管理者がコントロール | SQL レポート管理者と MCP 管理者を分離可能 |
| 役割分離 | ツール単位の許可ロール | メタツール単位で許可ロール（report_sql は Operator+ がデフォルト） |
| 想定操作 | データベース操作全般（PL/SQL/DML も可） | データ分析（読み取り中心、承認済みクエリのみ） |
| LLM の自由度 | このツールに紐づいた SQL を呼ぶだけ | レポート集合の中から動的に選んで呼ぶ |
7.2. なぜ「Reporting Tool は LLM 向けにできている」と言えるか
公式 Docs (MCPツールセットの作成) に次のように記載があります:
「LLM は、ツールの説明を使用して、各レポート・ツールの動作を理解し、それらを使用するタイミングを決定します。」
「Tool name および Tool description は、大規模言語モデル(LLM)がツールの目的と機能を理解するのに役立ちます。明確で詳細な説明を提供することで、結果の品質を向上させることができます。」
さらに SQL レポート作成画面の冒頭にも 「intended for consumption by AI applications」 と明記されています（§4.2 のスクショ参照）。
つまり Reporting Tool は最初から 「LLM が動的に判断して使う」前提で設計されている、ということです。具体的に効く仕掛けは以下の 4 点で、いずれも実機 UI で確認できます:
- 「命令」フィールド — LLM に対する「いつ使うか」の指示を、SQL レポート定義側に書いておける（§4.2）
- 列ごとの説明 — 結果スキーマの意味的解釈を LLM に渡せる（§4.2、応答品質に効くのは §6.2 で確認）
-
report_listメタツール — LLM が「利用可能なレポートを発見する」ステップを踏める（§6.1） - SQL レポート資産の独立性 — 接続非依存で定義され（§4.1）、SQL を書く DBA と MCP に公開する管理者を分離可能
Custom SQL Tool は「LLM に決まった SQL を実行させる」設計、Reporting Tool は「LLM がレポート集合を読んで自分で選ぶ」設計。両者は思想がワンレイヤー違うように見えます（厳密には Custom SQL Tool も複数定義すれば LLM が選べますが、report_list のような明示的な発見ステップは無いという点で差があります）。
ただし、これだけ手厚い LLM 向け設計をしても、LLM が必ず Reporting Tool を選ぶとは限らないことが §6.3 で判明しました。
7.3. 「公式チュートリアル未収録」の意味するところ
公式チュートリアル は Custom SQL Tool（従業員検索クエリ）で「最小動作」を見せる構成になっており、Reporting Tool は登場しません。Reporting Tool は 公式 Docs のリファレンス側 でのみ解説されています。
7.4. 予想外の発見: メタ情報の豊富さ < ツール名の意味的明確さ
§6.3 で観察した結果は、§7.2 で組み立てた論理（「Reporting Tool は LLM 向けに作り込まれているから LLM が選ぶはず」）を部分的に裏切るものでした。
何が起きたか（再掲）
- Custom SQL Tool (
GET_TOP_SQL_TOOL) と Reporting Tool (report_execute) を両方公開した状態で、同じ質問を Sonnet 4.6 に投げた - Claude は
GET_TOP_SQL_TOOLを最初に試した（タイムアウトで失敗） - その次も別のツールで、
report_executeは選ばれなかった
仮説の更新
ここから読み取れる LLM のツール選択ロジックは、以下のように仮説立てできます:
| 階層 | 何が効くか |
|---|---|
| 第 1 階層: ツール名の意味的マッチ | 質問のキーワード（"TOP SQL", "重い SQL"）とツール名のキーワード（GET_TOP_SQL_TOOL）の直接マッチ |
| 第 2 階層: tool description | 名前で同点だった場合の補助。「Returned top N SQL by elapsed time」のような直接的記述が効く |
| 第 3 階層: メタ情報の豊富さ | 「目的」「命令」「列の説明」── 選ばれた後の応答品質に効くが、選択そのものには効きにくい |
| 第 4 階層: 多段ツール構造 |
report_list → report_execute のような発見プロセスは、最初の検討フェーズでは想起されにくい
|
Reporting Tool の本来の価値はどこにあるか
ここからは私なりの解釈です:
- MCP_User しか持たない統制環境: Custom SQL Tool そのものを公開せず、レポート集合経由でしか SQL を実行させたくない場合
-
複数レポートを動的に運用する場面:
report_listで発見させる前提で、5〜10 個のレポートをまとめて公開する場合 - SQL 資産を複数 DB で再利用したい場合: SQL レポートが接続非依存なので、1 定義を複数の MCP サーバから参照できる
- 応答品質を最大化したい場面: 「命令」「列の説明」が応答時の自然言語要約に直接効く（§6.1 / §6.2 で実測）
逆に 「特定の質問に直接答える単発ツール」を作るなら、Custom SQL Tool のほうが LLM に選ばれやすい。これは前回記事の §6.2 で「Custom SQL Tool の追加が必要」と書いたときの直感は、結果として LLM のツール選択ロジックに沿っていた、ということでもあります。
マルチ MCP 環境の注意点
さらに副次的な発見として、GET_TOP_SQL_TOOL がタイムアウトした際、LLM は 別の MCP サーバ（adb-dba-copilot）の汎用 SQL ツールに自動でフォールバック しました。これは Claude Desktop に複数の MCP サーバを並列接続している場合の自然な挙動です。
- 計測検証時は MCP サーバを 1 つに絞る（他サーバが代行してしまうと真の挙動が見えない）
- 本番運用時は冗長化として利用できる（1 サーバが落ちても LLM が代替手段を見つける）
8. 次回？: シリーズ横ぐし比較
冒頭で書いたとおり、同じ問い 「いま重い SQL を 3 件教えて」 を、以下の 4 経路で検証してきました:
| # | 経路 | 役割の置き場 |
|---|---|---|
| 1 | SELECT AI | DB 内の LLM が NL → SQL を自動生成 |
| 2 | ADB 26ai 組み込み MCP | DB 自身が MCP サーバ化、外部 LLM が SQL を書く |
| 3 | SQLcl MCP Server | ローカル CLI が MCP サーバ、外部 LLM が SQL を書く |
| 4 | OCI Database Tools MCP Server（本記事） | OCI マネージドの MCP サーバ、DBA が定義したレポートを LLM が呼ぶ |
次回は これら 4 アプローチを「セットアップ工数 / カスタム性 / 認証粒度 / LLM への自由度 / 向くユーザー層」の観点で横ぐし比較してみたいと思います。同じ問い・同じ DB に向けて 4 通りの実装をぶつけた結果を、1 枚の比較表に集約するイメージです。
9. まとめ
9.1. 検証ゴールの達成状況
| # | 検証項目 | 結果 |
|---|---|---|
| 1 | SQL レポート + Reporting Tool 型ツールセットを作って Claude から呼べた | ✅ 達成 |
| 2 | 「いま重い SQL を 3 件教えて」に Claude が自律的に正しく応答できた | ✅ 達成（条件付き — §9.2 参照） |
9.2. 確認できたポイント
| ポイント | 内容 |
|---|---|
| ★ Reporting Tool は隠れキャラ | 公式チュートリアル未収録、公式 Docs リファレンスでのみ解説。GA 直後でまだ日本語情報がほぼない |
| 4 階層メタ情報 | 説明 / 目的 / 命令 / 列の説明 ── 画面冒頭に Oracle 自身が "intended for consumption by AI applications" と明記 |
| SQL レポートは接続非依存 | 1 定義を複数 DB / 複数 MCP サーバで再利用可 |
| 最小露出の原則 |
report_sql は MCP_User に対しツール一覧から物理的に消去（403 拒否ではなく非公開） |
| Reporting Tool 単独環境 | Claude は 4 階層メタ情報を活かした高品質応答（§6.2） |
| Custom SQL Tool と並存環境 | Claude は名前マッチで Custom を先に試した（メタ情報の豊富さは無視された）（§6.3） |
| マルチ MCP 環境 | LLM はサーバを跨いで代替手段を自律探索する |
9.3. 設計指針（ちょっと仮設含み・・）
- 「特定の質問に直接答える単発ツール」を作るなら Custom SQL Tool（LLM に選ばれやすい）
- 「複数の承認済みクエリ集合を統制下で LLM に公開する」なら Reporting Tool（接続非依存・役割分離・メタ情報リッチ）
- 計測検証では MCP サーバを 1 つだけにして切り分ける（マルチ MCP は代行されて挙動が読めない）
GA 直後でまだ情報が薄く、公式チュートリアルにも載ってない Reporting Tool。動かしてみたら 「これ、最初から LLM を相手にする前提で作ってあるな」 と思うような設計でした。
ただし「LLM 向けに作り込めば LLM が選ぶ」というほど単純な世界ではなく、ツール名の意味的明確さという古典的な要素が支配的だった、というのがまた難しいところです。Reporting Tool の本来の出番は、統制環境での SQL 公開や複数レポートを並列運用するシナリオにありそうです。
また、自身の環境で様々なツールを登録してしまっているため、きちんとクリーンな環境で本当は実施した方が良いことが改めてわかりました。ただ、それらは公式にお任せしてとりあえず何ができるのか、やりたいことをしたい場合にどうすればよいのか、を自身が把握するために検証は続けようと思います。
参考
公式 Docs
- Release Notes: Database Tools MCP Server (2026-05-12)
- MCPツールセットの作成 — 3 タイプの違い、LLM 向け設計の根拠
- チュートリアル: Database Tools MCPサーバーの設定とMCPクライアントとの統合 — Custom SQL Tool による最小構成チュートリアル
- MCPサーバーの作成
- アプリケーション・ロール
シリーズ過去記事
- OCI Database Tools MCP Server を Claude Desktop につないでみた（セットアップ編）
- Claude Code が DBA になる ― oracle/skills × SQLcl MCP で Oracle 26ai を自律診断してみた
- Oracle ADB に「重い SQL 教えて」と聞く 2 つの方法 ─ SELECT AI と MCP サーバを同一ユースケースで比較してみた
- Oracle Autonomous AI Database の MCPサーバを Claude Desktop につないで「いま重いSQL」を聞けるようにしてみた