「いま重い SQL を 3 件教えて」を Claude × Oracle 公式 4 経路で 3 ターン会話してみた

Posted at 2026-05-25

1. はじめに

シリーズの位置づけ

「いま重い SQL を 3 件教えて」── Oracle のパフォーマンス分析の入り口にあたる問いです。

このフレーズを Oracle 公式が提供する NL2SQL / MCP 系の各サービスに投げて答えてもらう、というシリーズを書いてきました。

#	経路	過去記事
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 にお願いしてみた

本記事は 同じ問いを 3 ターン続けて Claude に投げ、ツール選択がどう変わるかを実測するものです。

結論先出し

⭐ Claude のツール選択は揺らぎます: 3 セッション × 3 ターン = 9 ターンで、ターンごとに違うツールが選ばれる現象を観測
⭐ 会話が深まると Claude は自律的に経路を組み立てます: 権限不足を察知して別 MCP に乗り換えたり、ツール一覧に無い手段を試行錯誤で探したり
⭐ 前回記事 7.4 章で立てた「ツール選択 4 階層仮説」は概ね正しいが、動的自己訂正と同等機能の並存による揺らぎの追記が必要でした

検証ゴール

#	検証項目	達成判定
1	3 MCP 同時公開 × 3 セッション + 単独 × 1 セッションで、Claude（Sonnet 4.6）のツール選択遷移を観測	4 セッション × 3 ターン = 12 ターンを完走
2	前回記事 7.4 章「ツール選択 4 階層仮説」を拡張または反証する	仮説の更新ロジックを 1 枚のマトリクスで提示できれば OK

本記事は 「LLM が MCP ツールをどう選ぶか」 に焦点を絞っています。

4 経路の設計差を 6+2 観点で並べた横ぐし比較表や、運用設計（ユーザー層ごとに経路を絞る + Application Role） は別記事に切り出しました。本記事の派生として近日公開予定です。

2. 4 経路のおさらい

シリーズで扱ってきた 4 経路の役割の置き場所だけ簡単に整理します（詳細比較は派生記事を参照）。

#	経路	役割の置き場所	サーバ実体
1	SELECT AI	DB 内 LLM が NL → SQL を自動生成	ADB 自身（`DBMS_CLOUD_AI.GENERATE`）
2	ADB 26ai 組み込み MCP	DB 自身が MCP サーバ化、外部 LLM が SQL を書く	ADB の MCP エンドポイント
3	SQLcl MCP Server	ローカル CLI が MCP サーバ、外部 LLM が SQL を書く	`sql -mcp`（SQLcl 26.1）
4	OCI Database Tools MCP Server	OCI マネージドの MCP サーバ、DBA が定義したレポートや SQL を LLM が呼ぶ	OCI Database Tools サービス

このうち OCI DB Tools MCP は内部に複数のツールセットタイプを持ちます（公式: MCPツールセットの作成）。本記事では Custom SQL Tool（OCI-Custom） と Reporting Tool（OCI-Report） の 2 タイプを観察対象とします。

SELECT AI は Claude のツール選択対象に乗りません（DB 内で SELECT AI ... 構文として実行）。後述の多段会話検証は MCP 3 経路に絞ります（adb-dba-copilot / sqlcl / oci-dbtools-mcp）。

3. 検証環境

項目	内容
OCI リージョン	`ap-tokyo-1`
ADB	Oracle AI Database 26ai Enterprise Edition 23.26.2.1.0
クライアント	Claude Desktop
モデル	Claude Sonnet 4.6（4 セッション通じて固定）
OS	Windows 11 Pro
Node.js	v18+（`npx mcp-remote` 経由）

検証本番前に、V$SQL の TOP3 がシステムタスクや MCP インフラ系の PL/SQL で埋まらないよう、アプリケーション風の重い SQL を 3 本（集計 / 時系列 / GROUP BY）仕込んでいます。最終的に V$SQL の TOP3 は以下の状態:

順位	SQL_ID	経過時間	種別
1	`abqas1gw8a90r`	279.0 秒	perf_test_v3（集計）
2	`0db4fyjk09pdf`	229.2 秒	perf_test_v3c（時系列）
3	`4jussyy8s2rnm`	219.0 秒	perf_test_v3b（GROUP BY）

4. 多段会話で Claude のツール選択を実測する

4.1. 検証設計

モデル: Claude Sonnet 4.6（4 セッションで固定）
接続 MCP（Claude Desktop の Connectors の ON/OFF トグルで制御）:
- adb-dba-copilot（ADB 26ai 組み込み MCP）
- sqlcl（SQLcl MCP）
- oci-dbtools-mcp（OCI Database Tools MCP / Custom + Reporting の両方公開）
会話フロー（1 セッション = 3 ターン）:

ターン	プロンプト	意図
T1	「いま重い SQL を 3 件教えて」	浅い・直接的な問い
T2	「1 番上の SQL の実行計画を見せて」	中・派生の問い
T3	「この SQL のチューニング案を出して」	深・分析の問い

セッション構成:

構成	ON にする MCP	セッション数	目的
前半	ALL ON（3 MCP すべて）	3 セッション（S1/S2/S3）	自然な多 MCP 環境での選択・再現性
後半	`oci-dbtools-mcp` 単独 ON	1 セッション（S4）	Custom SQL Tool vs Reporting Tool の純粋勝負

観測項目: 各ターンで①選択 MCP サーバ ②選択ツール ③引数の要約 ④応答時間 ⑤エラー有無 ⑥応答の系統
試行ルール: 各セッションは新規会話、プロンプトは完全コピペ、ツール名・サーバ名は一切指定しない

4.2. S1〜S3（ALL ON 環境）の結果

4.2.1. S1（最初の 1 セッション）

ターン	選択 MCP	選択ツール	観察
T1	adb-dba-copilot	`EXECUTE_SQL`	自分で `SELECT ... FROM V$SQL ORDER BY elapsed_time DESC FETCH FIRST 3 ROWS ONLY` を組み立てて実行
T2	adb-dba-copilot	`EXECUTE_SQL`	T1 で取得した `SQL_ID` を引数に `DBMS_XPLAN.DISPLAY_CURSOR`
T3	（MCP は呼ばず）	Claude 自身の知識ベースで応答	5 案のチューニング推奨を返却

4.2.2. S2（再現性確認の 2 セッション目）

ターン	選択 MCP	選択ツール	観察
T1	`oci-dbtools-mcp`	`GET_TOP_SQL_TOOL`	S1 と違うツール選択。Custom SQL Tool が拾われた
T2	`sqlcl` → adb-dba-copilot 切替	`run-sql` → DBMS_XPLAN	Claude 自身が「DBA 権限が必要かも」と判断して乗り換え
T3	adb-dba-copilot 等で DBA_INDEXES / DBA_TAB_STATISTICS を取得しつつ Claude 自身の知識で応答	MCP context + 独自考察	テーブル統計の具体値（10.83 億行、統計 2026-01-09）を引用

4.2.3. S3（再現性確認の 3 セッション目）

ターン	選択 MCP	選択ツール	観察
T1	`oci-dbtools-mcp`	`GET_TOP_SQL_TOOL`	S2 と同じ。Custom SQL Tool に収束気味
T2	adb-dba-copilot	`MY_RUN_SQL_TOOL`	S1 = `EXECUTE_SQL`, S2 = sqlcl, S3 = `MY_RUN_SQL_TOOL` で3 通り全部違う
T3	（MCP は呼ばず）	Claude 自身の知識ベースで応答	S1 と同じパターン。5 案のチューニング推奨を返却

4.3. S4（oci-dbtools-mcp 単独 ON 環境）の結果

Connectors で adb-dba-copilot / sqlcl を OFF、oci-dbtools-mcp のみ ON にして、(oci-dbtools-mcpの) Custom SQL Tool vs Reporting Tool の純粋勝負を観測しました。

ターン	選択 MCP	選択ツール	観察
T1	`oci-dbtools-mcp`（唯一の選択肢）	`GET_TOP_SQL_TOOL`	他選択肢が無いので自明。Reporting Tool は単独環境でも選ばれず
T2	`oci-dbtools-mcp` のみ	9 ツール試行錯誤	① Reporting Tool で実行計画レポートを探す（なし）→ ② 「SQLcl で...」と発話するが実際の sqlcl MCP は OFF → ③ 「DBA 権限のある adbtest02_dba_copilot で接続して...」→ DBMS_XPLAN 取得成功
T3	`oci-dbtools-mcp` で DBA_TAB_COLUMNS 等の context 取得	MCP context + 独自考察	4 ツール使用してテーブル情報取得、その後はチューニング案 4 件を独自に組み立て

S4-T2 の謎: 公開ツール一覧（GET_TOP_SQL_TOOL / report_execute / report_list / request_status / schema_information）に汎用 SQL 実行手段は無いはずですが、Claude は 9 ツール試行の末に DBMS_XPLAN を成功させました。Claude の発話「SQLcl で...」「adbtest02_dba_copilot 接続で...」は別途確認したいですね

4.4. ツール選択マトリクス（4 セッション × 3 ターン）

        S1 (ALL ON)         S2 (ALL ON)             S3 (ALL ON)             S4 (oci のみ)
T1   →  adb.EXECUTE_SQL     oci.GET_TOP_SQL_TOOL    oci.GET_TOP_SQL_TOOL    oci.GET_TOP_SQL_TOOL
T2   →  adb.EXECUTE_SQL     sqlcl.run-sql → adb     adb.MY_RUN_SQL_TOOL     多段試行（9 ツール）
T3   →  MCP 呼ばず・独自考察 MCP context + 独自考察  MCP 呼ばず・独自考察    MCP context + 独自考察

観点	安定度
T1	`GET_TOP_SQL_TOOL` に 3/4 で収束 ◯
T2	4/4 全部違う（最大の揺らぎ）❌
T3	MCP では事前定義された手段が無く、Claude が独自で組み立て
Reporting Tool	0/4 で選ばれず（公式想定どおり、後述）

5. 考察 — LLM のツール選択ロジック

本章は S1〜S4 のスクリーンショット / 会話ログと Oracle 公式 Docs にひもづく範囲で記述します。それを超える解釈には「〜と考えられます」「〜の可能性があります」と慎重な書き方を用います。

5.1. ターン別のツール選択を実測で並べる

T1（浅い・直接的）

セッション	選択ツール
S1	adb-dba-copilot.`EXECUTE_SQL`
S2	oci-dbtools-mcp.`GET_TOP_SQL_TOOL`
S3	oci-dbtools-mcp.`GET_TOP_SQL_TOOL`
S4	oci-dbtools-mcp.`GET_TOP_SQL_TOOL`

4 セッション中 3 セッションで GET_TOP_SQL_TOOL が選ばれました。GET_TOP_SQL_TOOL のツール名（および description: "Returned top N SQL ... by elapsed time from V$SQL"、前回記事 6.3 章で確認）はユーザー発話「重い SQL」「TOP SQL」と直接対応しています。これは前回記事 7.4 章で立てた「名前マッチが第 1 優先」仮説と整合する結果です。

T2（中・派生）

セッション	選択ツール
S1	adb-dba-copilot.`EXECUTE_SQL`
S2	sqlcl.`run-sql` → 接続権限不足を察知して adb-dba-copilot に切替
S3	adb-dba-copilot.`MY_RUN_SQL_TOOL`
S4	oci-dbtools-mcp 内で 9 ツール試行

4 セッションすべてで異なるツールが選ばれました。Claude のツール一覧には汎用 SQL 実行ツール（EXECUTE_SQL / MY_RUN_SQL_TOOL / sqlcl.run-sql 等）が複数の MCP に並んで見えている構成です（4.1 章）。

T3（深・分析）

セッション	挙動
S1	MCP を呼ばず、5 案のチューニング推奨を組み立て
S2	MCP で `DBA_INDEXES` / `DBA_TAB_STATISTICS` を取得後、5 案を組み立て
S3	MCP を呼ばず、5 案を組み立て
S4	MCP で `DBA_TAB_COLUMNS` 等を取得後、4 案を組み立て

4 セッションすべてで「チューニング案を出す」専用の MCP ツールは呼ばれませんでした（そのようなツールは公開されていません）。Claude は応答本文を自前で組み立てており、S2 / S4 では事前に MCP でテーブル情報を取得する挙動も見られました。

5.2. Reporting Tool（`report_execute`）は今回のテストでは選ばれなかった

                            選択された回数 / 全試行数
GET_TOP_SQL_TOOL (Custom)            3 / 4
EXECUTE_SQL (adb-dba-copilot)        1 / 4
report_execute (Reporting)           0 / 4

ALL ON 環境（S1〜S3）+ oci-dbtools-mcp 単独環境（S4）を通じて report_execute は一度も選ばれませんでした。

MCPツールセットの作成では、3 種類のツールセットタイプが以下のように位置付けられています:

タイプ	公式の位置付け
組込み SQL	DBA 向け
カスタム SQL ツール	開発者向け
カスタマイズ可能なレポート・ツール	ビジネスユーザー / アナリスト向け

今回のテスト（「重い SQL」「実行計画」「チューニング案」）は内容として DBA 寄りであり、公式のユーザー層位置付けからすると Reporting Tool の主たる想定外にあたります。

本記事の検証範囲では「report_execute が選ばれなかった」という事実までしか確認しておらず、その原因がツール名の抽象度なのかユーザー層の不一致なのか 多段ツール構造（list → execute） なのかまでは切り分けていません。

5.3. 動的自己訂正 — Claude は経路を組み立て直す

S2-T2 と S4-T2 で、Claude がツール選択を実行途中で変える挙動が観測されました。

S2-T2 の事例: 権限不足の察知と乗り換え

ユーザー: 1 番上の SQL の実行計画を見せて

Claude:  sqlcl.run-sql を使用しました
Claude:  I need to connect first. Let me check what connections are available.
Claude:  I'll connect using adbtest02_dba_copilot since it likely has DBA privileges
          needed for DBMS_XPLAN.DISPLAY_CURSOR.
Claude:  adb-dba-copilot 経由で実行計画取得成功

最初に sqlcl.run-sql を呼んだあと、接続情報を確認したうえで「DBA 権限が必要」と発話し、adb-dba-copilot 経由に切り替えています。発話ログから、ツール選択を実行途中に変えたことが読み取れます。

S4-T2 の事例: ツール不在環境での試行錯誤

oci-dbtools-mcp 単独 ON 環境では、汎用 SQL 実行ツールが公開ツール一覧（GET_TOP_SQL_TOOL / report_execute / report_list / request_status / schema_information）には含まれていません。それでも Claude は 9 ツール呼び出しを経て DBMS_XPLAN を取得しました。

Claude:  DBMS_XPLAN.DISPLAY_CURSOR で実行計画を取得します
Claude:  ToolSearch を使用しました
Claude:  利用可能なレポートを一覧して実行計画を取得します  ← Reporting Tool を探した
Claude:  使用済み 2個のツール
Claude:  実行計画レポートがないので、SQLcl で直接実行します  ← 経路変更
Claude:  使用済み 2個のツール
Claude:  SQLcl への接続が必要です。接続ツールのスキーマを取得します
Claude:  使用済み 2個のツール
Claude:  DBA 権限のある adbtest02_dba_copilot で接続して実行計画を取得します
Claude:  使用済み 3個のツール（合計 9 ツール）
Claude:  実行計画が取得できました。

「Reporting Tool 一覧を確認した」「実行計画レポートが無いことを確認した」「経路を変えた」というステップが発話に明示されており、Claude が取得経路を順次変更していることが読み取れます。

なお、公開ツール一覧に汎用 SQL 実行手段が無いはずの構成で最終的に DBMS_XPLAN が取得できた理由は特定できていません。。

5.4. 「ツール選択 4 階層仮説」の更新

前回記事の 7.4 章で立てた仮説:

階層	何が効くか
第 1 階層	ツール名の意味的マッチ
第 2 階層	tool description
第 3 階層	メタ情報の豊富さ
第 4 階層	多段ツール構造（`list` → `execute`）

今回の実測で観測された追加要素は以下の 2 点です:

追加	内容	根拠
動的自己訂正	ツール選択を実行途中で変える挙動が観測された	S2-T2 / S4-T2 の発話ログ（5.3 章）
同等機能の並存による揺らぎ	同等機能の汎用 SQL 実行ツールが複数 MCP に並存する状況で、4 セッション全てが異なるツールを選んだ	T2 の 4 セッション結果（5.1 章）

「ツールが具体的なほど浅い質問で勝つ」仮説の評価

事前仮説（plan.md §2.2）と本検証の実測の対比:

ターン	事前仮説	実測	評価
T1	具体的なツール（`GET_TOP_SQL_TOOL`）が勝つ	3/4 で勝った	✅ 仮説と整合
T2	汎用 SQL ツールが勝つ	4/4 で汎用 SQL ツール系列が勝ったが、どれが選ばれるかは不安定	△ 「勝つカテゴリ」は当たり「どれが」は外れ
T3	MCP では扱えず Claude 自身に流れる	4/4 で「チューニング案」専用ツールは無く Claude が自前で組み立て	✅ 仮説と整合

上記の実測範囲では、ツール選択はツールの抽象度に応じて層が変わると整理できそうです（具体的ツール → Custom SQL Tool、汎用 SQL ツール → 汎用 SQL exec、分析的問い → Claude 自身の知識ベース）。ただし「層が変わる」原因がツール名の意味的マッチなのか、他の階層（description / メタ情報 / 多段構造） との重み付けによるものなのかは本検証では切り分けていません。

6. まとめ

6.1. 検証ゴールの達成状況

#	検証項目	結果
1	4 セッション × 3 ターンの選択遷移を観測	✅ S1〜S4 完走
2	「ツール選択 4 階層仮説」を拡張または反証	✅ 拡張（動的自己訂正 + 同等機能並存による揺らぎを追加）

6.2. 確認できたポイント

ポイント	内容
⭐ ツール選択は揺らぐ	ALL ON 環境では同じ Sonnet 4.6・同じプロンプトでも T1/T2/T3 で別の選択をする
⭐ 動的自己訂正	権限不足やツール不在を察知して別経路に乗り換える（S2/S4 で観測）
⭐ 名前マッチが第 1 優先	`GET_TOP_SQL_TOOL` のような具体的なツール名は浅い質問で圧倒的に有利
Reporting Tool の出番	今回は 0/4 だが、Reporting Tool は本来「ビジネスユーザー / アナリスト向け」と公式で位置付けられている。DBA 寄りの問いで選ばれないのは標準的な挙動

そもそも、MCPツールを並列に、というところ自体があまり想定してないだろう、というところは想像できます。

7. 今後の課題

ちょっとどこまでやるかはわかりませんが・・

派生記事（近日公開）: 4 経路の設計差を 6+2 観点で比較したガイドと、ユーザー層ごとに経路を絞る運用設計（Application Role 含む） を切り出して別記事化します
ガバナンス観点: 監査ログ・SQL 承認フロー・誰がどう承認するかは本記事スコープ外。独立記事で扱う予定
S4-T2 の追加検証: oci-dbtools-mcp 単独で DBMS_XPLAN がなぜ動いたのか
SELECT AI の多段会話検証: 業務ユーザー視点での T1〜T3 挙動は未実施
モデル差の検証: 本記事は Sonnet 4.6 のみ。Opus や他モデルでツール選択の支配要因がどう変わるかは未検証
Private Agent Factory との関係整理: 今回扱った 4 経路に加え、OCI Generative AI Agents の Private Agent Factory で構築したエージェント経由でも同じ問いに答えられる可能性があります。Agent Factory はナレッジベース統合・ツール設計を OCI 側で完結させる形になり、本記事で見た「LLM クライアント側でツール選択が揺らぐ」問題に対する別アプローチとして位置付けられます

参考

公式 Docs

Using MCP Server with Autonomous AI Database
Using the Oracle SQLcl MCP Server (26.1)（英語版のみ）
MCPツールセットの作成

シリーズ過去記事（同じ問いを別経路で）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up