1. はじめに
本記事は以下のシリーズ（？）の第5弾です。
| 回 | テーマ |
|---|---|
| 第1弾 | Oracle Autonomous AI Database の MCP サーバを Claude Desktop につないで「いま重い SQL」を聞けるようにしてみた |
| 第2弾 | oracle/skills を Claude Skill に登録すると AWR 解析で何が変わるか — Haiku/Sonnet × Skill 有無の 4 パターン比較 |
| 第3弾 | SELECT AI と MCP サーバを同一ユースケースで比較してみた |
| 第4弾 | oracle/skills を MCP と組み合わせると何が変わるか |
| 第5弾（本記事） | oracle/skills × SQLcl MCP で自律診断ループを実現する |
第4弾では「MCP が取得経路、Skills が読み解き」という分業構造が確認できました。
本記事ではそれをさらに一歩進め、Claude Code（claude-sonnet-4-6）を使って診断ループ全体を自律実行させることを試みます。
本記事が試したのは、oracle/skills（Oracle 実践ガイド集）と SQLcl MCP を組み合わせて、Claude に「知識の参照」と「実際のクエリ実行」を同時にやらせること です。
具体的には「遅いクエリを診断して」の一言だけ渡して、Claude が V$SQL → 実行計画 → ASH（Active Session History）の順に自律的に調査を回し、診断レポートを生成するところまでを検証しました。
用語の整理
- SQLcl MCP: SQLcl 25.2 以降で使える MCP サーバ機能。Claude Code から Oracle DB を直接操作できる
- oracle/skills: Oracle が公開している実践ガイド集。Claude Code のスキルとして組み込める
- ASH（Active Session History）: Oracle が 1 秒ごとにアクティブセッションをサンプリングした診断ビュー
今回の検証ゴール
| # | 検証項目 | 確認できれば OK な状態 |
|---|---|---|
| 1 | oracle/skills + SQLcl MCP で「自律診断ループ」が成立するか | 人手なしで V$SQL→実行計画→ASH の順に調査が完結する |
| 2 | dba_copilot ユーザーで診断に必要な情報が取れるか |
V$SQL・V$SQL_PLAN・ASH・AWR すべてに実データが取得できる |
| 3 | 診断結果が「原因・根拠・対処」の形でまとまるか | 根拠付きの診断レポートが自動生成される |
結論の先出し
- ✅ 5 クエリで診断が完結した ― V$SQL で特定 → 実行計画取得 → ASH 分析 → 改善提案まで自律実行
- ✅ oracle/skills が「何を見るべきか」の判断を担い、SQLcl MCP が「実際に叩く」役割を担った
2. 検証環境
| 項目 | 値 |
|---|---|
| OS | Windows 11 Pro |
| Claude Code | claude-sonnet-4-6 |
| SQLcl | 26.1.0.0（MCP モード） |
| oracle/skills | anthropic-skills:oracle-db-skills |
| DB | Oracle AI Database 26ai（ADB on OCI ap-tokyo-1） |
| 診断ユーザー | dba_copilot（V$SQL・ASH・AWR 等参照権限あり） |
| 負荷スキーマ | SCOTT |
| 負荷テーブル | DUMMY_DATA_LOAD（10億行・インデックスなし） |
3. 構成
Claude Code が「知識」と「実行」の両方を持つ構成です。
SQLcl MCP のセットアップ
MCP サーバの登録には claude mcp add コマンドを使います。
claude mcp add sqlcl -s user `
-e "JAVA_TOOL_OPTIONS=" `
-e "TNS_ADMIN=C:\Users\<ユーザー名>\wallet\Wallet_<ADB名>" `
-- C:\PROGRA~1\sqlcl\bin\sql.exe -mcp
接続情報の保存（-savepwd には -save が必須）：
-- SQLcl /nolog で起動後に実行
CONN -save adbtest02_dba_copilot -savepwd dba_copilot/<パスワード>@adbtest02_high
4. 検証手順
4.1. Phase 0 ― 事前確認
dba_copilot ユーザーで診断ビューにアクセスできるかを確認しました。
SELECT 'V$SQL' v, COUNT(*) FROM v$sql WHERE ROWNUM=1
UNION ALL SELECT 'V$SQL_PLAN', COUNT(*) FROM v$sql_plan WHERE ROWNUM=1
UNION ALL SELECT 'V$ACTIVE_SESSION_HISTORY', COUNT(*) FROM v$active_session_history WHERE ROWNUM=1
UNION ALL SELECT 'DBA_HIST_ACTIVE_SESS_HISTORY', COUNT(*) FROM dba_hist_active_sess_history WHERE ROWNUM=1
UNION ALL SELECT 'DBA_HIST_SNAPSHOT', COUNT(*) FROM dba_hist_snapshot WHERE ROWNUM=1
UNION ALL SELECT 'V$SQL_MONITOR', COUNT(*) FROM v$sql_monitor WHERE ROWNUM=1;
全 6 ビューにエラーなくアクセスできることを確認。DUMMY_DATA_LOAD の状態は以下のとおりです。
| 項目 | 値 |
|---|---|
| 行数 | 1,083,503,113（約10億行） |
| ブロック数 | 20,858,504（約163GB相当） |
| インデックス数 | 0 |
| AWR スナップショット間隔 | 1時間 / 保持30日 |
4.2. Phase 1 ― 負荷クエリの実行（SCOTT 接続）
以下のクエリを SCOTT ユーザーで実行しました。
10億行（インデックスなし）のため、フルスキャンが確実に発生します。
SELECT COUNT(*), MAX(amount), MIN(amount), AVG(amount)
FROM scott.dummy_data_load
WHERE code = 'TARGET_CODE_99999'
AND description LIKE '%SLOW%'
4.3. Phase 2 ― 自律診断（Claude への指示）
Claude に渡した指示は この一行だけ です。
adbtest02_dba_copilot に接続して、直近で遅かった SQL を診断してください。
Claude が自律的に実行した診断の様子：
Claude は以下の 5 ステップを人手なしで実行しました。
| Step | 使ったビュー | 目的 |
|---|---|---|
| 1 | V$SQL | 遅い SQL の特定・SQL_ID の取得 |
| 2 | DBMS_XPLAN.DISPLAY_CURSOR | 実行計画の取得 |
| 3 | V$ACTIVE_SESSION_HISTORY | 待機イベントの分析 |
| 4 | DBA_TABLES / DBA_INDEXES | テーブル統計・インデックス状況の確認 |
| 5 | DBA_TABLES（DEGREE） | 並列度の確認 |
5. 実行結果
5.1. V$SQL ― 遅い SQL の特定
SQL_ID ELAPSED_SEC CPU_SEC EXECUTIONS BUFFER_GETS GETS_PER_EXEC
dbubtmhr741uh 6.4 2.4 1 20,837,686 20,837,686
1 回の実行で 2,083 万ブロック を読み取っています。
gets_per_exec = 20,837,686 という数字がフルスキャンの規模を示しています。
5.2. 実行計画 ― TABLE ACCESS STORAGE FULL
---------------------------------------------------------------
| Id | Operation | Name | E-Rows |
---------------------------------------------------------------
| 0 | SELECT STATEMENT | | |
| 1 | SORT AGGREGATE | | 1 |
|* 2 | TABLE ACCESS STORAGE FULL| DUMMY_DATA_LOAD | 1 |
---------------------------------------------------------------
Predicate Information:
2 - storage(("CODE"='TARGET_CODE_99999' AND "DESCRIPTION" LIKE '%SLOW%'))
filter(("CODE"='TARGET_CODE_99999' AND "DESCRIPTION" LIKE '%SLOW%'))
Note:
- automatic DOP: Computed Degree of Parallelism is 1
5.3. ASH ― 待機イベント分析
EVENT WAIT_CLASS ASH_SAMPLES PCT AVG_WAIT_MS
cell smart table scan User I/O 6 85.7% 10 ms
(on CPU) — 1 14.3% —
処理時間の 85.7% がストレージ I/O（cell smart table scan）に費やされています。
ASH サンプル数について
ASH は 1 秒ごとにアクティブセッションをサンプリングします。今回のクエリは 6.4 秒で完了したため、サンプル数は 7 件（6 + on CPU 1）となりました。件数は少ないですが、これは ASH の仕様上、短時間クエリでは理論値に近い件数です。統計的な信頼性を高めるには、より長時間実行されるクエリを対象にすることをお勧めします。
6. 考察
6.1. TABLE ACCESS STORAGE FULL は速い
ADB の Exadata Smart Scan がストレージ層でフィルタリングするため、10億行のフルスキャンでも elapsed_time = 6.4秒 と驚くほど速い。
6.2. oracle/skills が果たした役割
Claude は Step 1〜5 を通じて「V$SQL → DBMS_XPLAN → ASH → テーブル統計 → 並列度」
という DBA が手動で行う診断順序を自律的に再現しました。
oracle/skills の以下のガイドがそれぞれ「何を・どの順で見るべきか」の知識源となっています。
-
skills/performance/awr-reports.md— AWR レポートの読み方・ボトルネック特定 -
skills/performance/ash-analysis.md— ASH によるリアルタイム・履歴分析 -
skills/performance/explain-plan.md— DBMS_XPLAN を使った実行計画の読み方
SQLcl MCP のツール提供だけでは「何を実行するか」の判断が難しい場合があります。oracle/skills との組み合わせによって、知識（何を見るか）と実行（実際に叩く）が統合されました。
7. まとめ
| # | 検証項目 | 結論 |
|---|---|---|
| 1 | 自律診断ループが成立するか | ✅ 5 クエリで V$SQL→実行計画→ASH→対処提案まで自律完結 |
| 2 | dba_copilot で診断情報が取れるか | ✅ 全ビューにアクセス可。AWR 履歴も参照可能 |
| 3 | 「原因・根拠・対処」形式でまとまるか | ✅ インデックス欠如・先頭ワイルドカード問題を特定し改善策を提示 |
oracle/skills が「DBA の思考フロー」を提供し、SQLcl MCP が「DBA の手」として動く構成は実用も可能と考えてます。
一方で課題もあります。
- 診断の深さは指示の質に依存する ― 「直近で遅かった SQL を診断して」という曖昧な指示でも動きましたが、「特定の SQL_ID を詳細分析して」のように具体的な指示を与えるとより精度の高い診断が期待できます
- 短時間クエリの履歴消失リスク ― 今回は実行直後のため V$ACTIVE_SESSION_HISTORY（インメモリ）で捕捉できましたが、ASH データが AWR（DBA_HIST_ACTIVE_SESS_HISTORY）へ書き出される際は間引かれます。数秒で終わるクエリは過去に遡って分析しようとしても AWR にデータが残らないこともあります
- 本番環境での実行時はガードレールを設定する ― 自律診断が回ると V$ などの動的パフォーマンス・ビューに対して短時間に複数クエリが発行されます。稼働中の本番環境ではパース負荷やラッチ競合を引き起こすリスクがあるため、実行するビューの種類や頻度を制限するガードレールの設定を検討してください
Oracle PAF との使い分け
Oracle は同様のユースケースを想定した自社製エージェント基盤 PAF（Private Agent Factory） を OCI 上で提供しています。
| 観点 | Claude Code + oracle/skills + SQLcl MCP (or ADB MCP) | Oracle PAF |
|---|---|---|
| 実行環境 | ローカル（開発者 PC / CI） | OCI マネージド |
| ガバナンス | Claude Code の権限設定 | OCI IAM + ポリシー |
| Oracle 製品との統合 | MCP 経由で任意に拡張 | Oracle サービスとネイティブ連携 |
| 向き不向き | 素早い検証・PoC・開発者主導の調査 | エンタープライズ運用・組織統制が必要な本番環境 |
「まず試す」「DBA が自分で調べる」用途には Claude Code + oracle/skills の組み合わせが即戦力になります。本番環境でのガバナンスや Oracle サービスとの深い統合が求められる場面では PAF が選択肢に上がります。
参考
本シリーズ
- 第1弾: Oracle Autonomous AI Database の MCP サーバを Claude Desktop につないで「いま重い SQL」を聞けるようにしてみた
- 第2弾: oracle/skills を Claude Skill に登録すると AWR 解析で何が変わるか — Haiku/Sonnet × Skill 有無の 4 パターン比較
- 第3弾: Oracle ADB に「重い SQL 教えて」と聞く 2 つの方法 ─ SELECT AI と MCP サーバを同一ユースケースで比較してみた
- 第4弾: oracle/skills を MCP と組み合わせると何が変わるか — リアルタイム TOP SQL 解析で Skill の効果を検証する
公式ドキュメント