Db2 AI エディション(Db2 AI Advanced, Db2 AI Standard)にはフル機能のDb2 Genius Hubがバンドルされています。
このGenius Hubは、v1.1.3以降からDb2 Genius Hub MCP Serverが搭載されました。
当記事ではこのMCPサーバーのセットアップ方法とIBM Bobから接続する方法をまずご紹介しています。
そして、IBM Bobから簡単な自然言語を与えるだけで、指定したデータベースに関するキャパシティ・プランニング・レポートを作成する方法を解説しています。

ここからは次のBlogの抄訳です。
"IBM's Genius Hub MCP AI Agents– A Hands-On Guide with a Real Use Case"
https://community.ibm.com/community/user/blogs/aadesh-rasal/2026/07/13/ibms-genius-hub-mcp-hands-on-guide

はじめに

Db2 Genius Hub 1.1.3の最新リリースでは、「Genius Hub MCP Server」が導入されました。
これはGenius HubとAIエージェントを仲介するインターフェースであり、Db2の監視、診断、分析機能を、対話型および自律型のワークフローに直接組み込むことを可能にします。

セットアップの詳細に入る前に、この機能がさまざまな役割を担うユーザーにもたらす価値について確認しておきましょう。
データベース環境の管理、監視、サポートを担当するチームは、パフォーマンス問題の調査、リソース使用状況の分析、競合（コンテンション）シナリオの特定、システム健全性の検証、あるいはバックアップや災害復旧（DR）への備えの確認を行う際、信頼できる運用上の知見（インサイト）に迅速にアクセスする必要があります。

こうした情報にタイムリーにアクセスできれば、チームは潜在的なリスクを早期に発見し、十分な情報に基づいた運用上の意思決定を行うことができます。
Db2 Genius Hubは、こうした調査に必要なデータやアラートをすでに提供していますが、必要な回答を得るためには、多くの場合、複数のインターフェースを操作したり、特定のクエリを実行したり、異なるビューやツールにまたがる情報を手動で関連付けたりする必要がありました。

Db2 Genius Hub MCP Serverは、Model Context Protocol (MCP) を介してこれらの機能を提供することで、このプロセスを簡素化します。
これにより、外部のAIエージェントは、構造化され、再利用可能かつ一貫性のある方法で、Db2の監視・診断機能とやり取りできるようになります。
その結果、ユーザーは自然言語による対話や自動化されたワークフローを通じて、運用上の知見により効率的にアクセスし、調査を合理化し、問題解決を迅速化することが可能になります。

本記事では、MCP Serverのセットアップに焦点を当て、具体的な例を挙げてその機能を紹介します。

セットアップ

本ガイドでは、Genius Hub MCPサーバーに接続するMCPクライアントとして、IBMの社内AIエージェント「Bob」を使用します。
サーバーをBobに接続する前に、MCPサービスが稼働しており、かつ接続可能であることを確認しておくと良いでしょう。
これにより、後々の設定トラブルを防ぐとともに、クライアントがツールを検出する前にサーバーの準備が整っていることを確認できます。

ステップ 1 – サービスが実行されていることを確認する

最初のステップは、MCP サービスを含むすべての Db2 Genius Hub コンポーネントが正常に実行されていることを確認することです。
これはコマンドラインから行うことができます。

Db2 Genius Hub v1.1.3 のインストール後、ibm_db2GeniusHub/bin ディレクトリに移動します。

次に、ステータス確認用スクリプト ./status.sh を実行します。

これにより、製品のステータス全体がチェックされ、実行中のすべてのサービスとそれらがリッスンしているポートが一覧表示されます。
表示されるサービスの数は、ライセンスによって異なる場合があります。以下の出力は、Genius MCP サービスがポート 8000 でリッスンしていることを示しています。

========================================== 
IBM Db2 Genius Hub - Product Status Check 
========================================== 
 
-~/ibm-db2GeniusHub/bin# ./status.sh 
 
Component Status Summary: 
Liberty Server            RUNNING         PID: 2782189 | Port(s): 11100(HTTP),11101(HTTPS) 
Agentic AI Service        RUNNING         PID: 2783147 | Port(s): 11108 
Anomaly Detection Service RUNNING         PID: 2783238 | Port(s): 11109 
DRS Agent Service         RUNNING         PID: 2782614 | Port(s): 11096 
Job Scheduler Service     RUNNING         PID: 2782691 | Port(s): 11107 
Redis Service             RUNNING         PID: 2782866 | Port(s): 6379 
Genius MCP Service        RUNNING         PID: 2820152 | Port(s): 8000 
 
Overall Status: [OK] All components are running

ステップ 2 – MCP エンドポイントへの到達可能性を確認する

サービスが稼働していることを確認した後、サーバーが設定されたエンドポイントで応答していることを検証します。
この段階での目的は、データベースのすべての機能をテストすることではなく、単に MCP エンドポイントに到達可能であり、有効な応答が返されることを確認することです。
curl を使用して /health エンドポイントにリクエストを送信してください。

curl https://<your-genius-hub-url>:8000/health

サーバーが正常に動作しており、想定されるエンドポイントでリクエストを待ち受けている場合、レスポンスは次のようになります。

{ 
  "status": "healthy", 
  "server": "genius-mcp", 
  "version": "0.1.0", 
  "deployment_mode": "multi_tenant", 
  "connection_pool": { 
    "total_connections": 2, 
    "active_pools": 1 
  } 
}

deployment_mode フィールドは、この MCP サーバーインスタンスがマルチテナント接続をサポートしていることを示しています。
つまり、個別にデプロイすることなく、同一のサーバーで複数の Genius Hub プロファイルを処理することが可能です。
connection_pool は、ヘルスチェックの時点でサーバーが管理しているアクティブなデータベース接続の状態を反映しています。

ステップ3 – MCPクライアントへのサーバー登録

サーバーの検証が完了したら、次はMCP設定ファイルを通じてクライアントにサーバーを登録します。
これにより、エージェントは利用可能なツールを検出し、要求に応じてそれらを呼び出せるようになります。
設定ファイルの場所は、使用するMCPクライアントによって異なります。
Bobの場合、設定ファイルは .bob ディレクトリ内の mcp.json という名前で配置されます。
これが初めて設定するMCPサーバーである場合、ファイルがまだ存在しない可能があります。
その場合は、指定されたパスに手動でファイルを作成してください。

ファイルの準備ができたら、以下のサーバーエントリを追加します。

{ 
  "mcpServers": { 
    "db2-genius-mcp": { 
      "type": "streamable-http", 
      "url": "https://<your-genius-hub-url>:8000/mcp", 
      "headers": { 
        "X-Genius-Hub-Hostname":     "<your-genius-hub-host>", 
        "X-Genius-Hub-Port":         "<your-genius-hub-port>", 
        "X-Genius-Hub-Protocol":     "<protocol-used-by-genius-hub>", 
        "X-Genius-Hub-Token":        "<ibm-genius-hub-token>", 
        "X-Genius-Hub-Profile-Name": "<default-db-profile>" 
      }, 
      "disabled": false 
    } 
  } 
}

設定フィールドに関するいくつかの注意点：

type: streamable-http — このMCPサーバーで使用されるトランスポートタイプです。
Genius Hub MCPはHTTPベースのストリーミングを使用しており、これにより、複数ステップにわたるツール呼び出しの間も接続が維持されます。

X-Genius-Hub-Token — Genius Hubによって発行される認証トークンです。
これは、Genius Hub REST APIの認証に使用されるものと同じトークンです。
このトークンは、リモートマシンから以下のAPI呼び出しを行うことで発行できます。

リモートマシン: -

curl -X POST 'https://<genius-hub-hostname>:11101/dbapi/v4/auth/tokens' -H 'Content-Type: application/json' -d '{"userid": "your-genius-hub-username", "password": "your-corresponding-password"}' --cacert  <path-to-genius-hub-ca-cert.pem>

ホストマシン: -

curl -X POST 'http://<genius-hub-hostname>:11100/dbapi/v4/auth/tokens' -H 'Content-Type: application/json' -d '{"userid": "your-genius-hub-username", "password": "your-corresponding-password"}'

X-Genius-Hub-Profile-Name — 実行時に上書きされない限り、エージェントが使用するデフォルトのデータベースプロファイルです。
この設定が空の場合、エージェントはデータベースツールを呼び出す前に、プロファイルを明示的に選択する必要があります。

この設定を保存したら、Bob（または使用しているクライアント）を再起動して、新しいサーバーエントリーを読み込ませてください。
クライアントはMCPエンドポイントに接続してツールマニフェストを取得し、それらのツールを会話で使用できるようにします。

インタラクションとユースケース

セットアップが完了し、クライアントがMCPサーバーに接続されていることを前提として、実際のツールセットの動作を見ていきましょう。
以下の例では、主要なユースケースに移る前に、基本的な診断フローをいくつか順を追って説明します。

データベースプロファイルのリスト表示

まずは、Genius Hubインスタンスに登録されているデータベースプロファイルを一覧表示するシンプルなプロンプトから始めます。
エージェントは fetch-dic-db-profiles ツールを呼び出し、利用可能なプロファイル名を返します。

プロンプト: 「データベースプロファイルをリスト表示して」*1
*1 "List the db profiles."

プロファイルへの接続

プロファイル一覧を取得したら、次のステップはプロファイルの一つに接続することです。エージェントはconnect-to-profileツールを呼び出し、プロファイル名を引数として渡します。この例では、エージェントはsteven-spilldbプロファイルに接続し、接続は正常に確立されました。

プロンプト：「steven-spilldbプロファイルに接続してください」*2
*2 "Connect to the profile steven-spilldb."

接続が確立されると、エージェントは対話形式でそのデータベースに対して診断クエリを実行できるようになります。
以下のプロンプトは、利用可能な機能の例を示しています。
診断プロンプトの例

エージェントはfetch_tablesツールにクエリを実行し、ページ数とテーブルスペース割り当てを含む、順位付けされたテーブルリストを返します。

プロンプト：「テーブルスペース使用量の降順でソートされたテーブルのリストを取得してください」*3
*3 "Get me the list of tables sorted by tablespace usage in descending order."

エージェントは、指定されたSQLに対して接続プロファイル上でget_explain_planツールを実行し、アクセスプランを返します。
アクセスプランには、推定コスト、テーブルスキャンまたはインデックスアクセスが使用されているかどうか、および関連するソート操作が含まれます。

プロンプト：「このクエリのexplainプランを取得します：SELECT * FROM BDI50.CUSTOMER WHERE C_BIRTH_YEAR > 1990」*4
*4 "Get the explain plan for this query: SELECT * FROM BDI50.CUSTOMER WHERE C_BIRTH_YEAR > 1990"

エージェントクエリはバッファプール統計情報を取得し、ヒット率が最も低いテーブル（メモリ割り当ての増分やインデックスチューニングによって最も効果が得られる可能性が高いテーブル）を表示します。

プロンプト：「バッファプールヒット率でソートした上位10個のテーブルを表示してください」*5
*5 "List the top 10 tables sorted by buffer pool hit ratio."

エージェントはカタログをスキャンし、RUNSTATSが一度も実行されていないテーブル、または最終統計収集日が不明なテーブルを特定します。
これは、クエリ最適化プランの回帰を調査する前に一般的に行われる診断手順です。

プロンプト：「統計情報が収集されていないすべてのテーブルを一覧表示してください」*6
*6 "List all the tables for which statistics have not been collected."

ここまで、利用可能なツールの一部をご紹介しました。
他にも、ロックの分析、バックアップ状況の確認、HADR状態の調査など、活用できるツールは数多くあります。
これらのツールはそれぞれ自然言語で呼び出すことができ、複数のステップからなるワークフローとして組み合わせることも可能です。
次のセクションでは、稼働中のデータベース・インスタンスを対象に、包括的なキャパシティプランニング・レポートを生成するという、具体的なエンド・ツー・エンドのユースケースを解説します。

ユースケース — SPILLDBのキャパシティ・プランニング・レポート

より実践的なワークフローを試すため、接続先のデータベースインスタンス（プロファイル：steven-spilldb / データベース：SPILLDB）に関する詳細なキャパシティプランニング・レポートの作成を求める以下のプロンプトをエージェントに送信してみます。

プロンプト：「接続先データベースのキャパシティ・プランニングに関する詳細なレポートを生成してください。その際、表スペースの使用率、容量を多く消費している上位の表、I/Oアクティビティの概要、容量枯渇の予測、および実行可能な推奨事項を含めてください」*7
*7 "Generate a detailed capacity planning report for the connected database. Include tablespace utilization, the top space-consuming tables, an I/O activity summary, space exhaustion projections, and actionable recommendations"

エージェントは、表スペース使用率メトリックの取得、サイズ順での最大級の表の特定、SYSIBMADMビューからのバッファー・プールおよびI/O統計の抽出といった一連のツール呼び出しをバックグラウンドで実行し、それらすべてのデータを構造化されたHTMLレポートにまとめ上げました。

レポートで判明したこと

レポートは直ちに重要な事実を明らかにしました。
USERSPACE1の容量使用率が99.8%に達しており、メンバー0と1の双方で、空き容量がわずか約8～9 MBしか残っていなかったのです。
自動サイズ変更機能は有効になっていましたが、表スペースの最大サイズ設定は「無制限（Unlimited）」でした。
つまり、基盤となるファイルシステムに空き容量がある場合にのみ自動拡張が行われる仕組みであり、この点はOSレベルでの即時の確認が必要な状況でした。

この状況の主な要因となっていたのは、TPC-DSの以下の3つのファクト表でした。

BDI50.STORE_SALES — 4.26 GB（表スペース割り当て量の約38%）

BDI50.CATALOG_SALES — 3.39 GB（約30%）

BDI50.INVENTORY — 1.81 GB（約16%）

これら3つの表を合わせると、割り当てられた表スペースの84%以上を占めていました。

I/Oに関しては、過去7日間のIBMDEFAULTBPのバッファー・プール・ヒット率が99.68%でした。
これは、読み取りワークロードのほぼすべてがメモリから処理されており、物理ディスクへの負荷が低いことを示しています。
一方、パッケージ・キャッシュ・ヒット率は0%でした。
これは、インスタンスが最近再起動されたか、あるいはコンパイル済みプランが再利用されないアドホック・クエリがワークロードの大半を占めていることを示唆しています。

さらにレポートでは、BDI50スキーマ内のすべての表に関する統計情報が古くなっている（最後に収集されてから3ヶ月以上経過している）ことも指摘されました。
統計情報が古いと、クエリ・オプティマイザーが最適ではないアクセス・プランを生成する恐れがあります。
これは特に、ストレージのホットスポットとして特定された大規模なファクト表において重要な問題となります。
エージェントが生成した推奨事項

直ちに行うべきアクション:

自動ストレージ・パスのファイルシステム空き容量を確認する — USERSPACE1は自動拡張されますが、OSレベルでのディスク空き容量が必要です。

ファイルシステムも容量不足に近い状態であれば、容量が枯渇する前に、ストレージ・コンテナーの追加や表スペースの拡張を事前に行う。

大規模な表に対してREORGを実行し、再利用可能なエクステントを回収する（USERSPACE1では再利用可能スペース機能が有効になっていることが確認されています）。

短期的なアクション（1週間以内）:

TS4MONITORの自動サイズ変更（auto-resize）を有効にする — 現在は無効になっています。無制限な肥大化を防ぐため、明示的な最大サイズ上限を設定してください。

すべてのBDI50表に対してRUNSTATSを実行し、データ分布に関するオプティマイザーの情報を最新の状態にする。

保持ポリシーが存在する場合、STORE_SALESおよびCATALOG_SALESに対してデータ・アーカイブまたはパージのポリシーを適用可能かどうかを検討する。

監視に関する推奨事項:

RTMONイベント・モニター（CONFIG、DDL、UTILITY）を有効にし、適切な履歴メトリックのベースラインを確立する。
USERSPACE1の使用率が80%を超えた場合にアラートが通知されるよう、IBM Data Consoleで設定を行う。
現在容量不足に近い状態であることを踏まえ、自動ストレージ・パスのディスク使用量を毎週監視する。
TEMPSPACE1ファイルシステムの空き容量を注視する — ソート処理の負荷が高いTPC-DSワークロードでは、大量のデータが一時表スペースにスピル（あふれ出し）する可能性があります。

生成されたレポート

エージェントによって出力されたレポートの全内容は以下の通りです。
これには、表領域の詳細表、使用率を視覚的に示すバーを伴う「容量を多く消費している上位項目」の内訳、データ取り込み速度ごとの容量増加予測、過去7日間のI/Oアクティビティの概要、優先順位付けされた推奨事項、およびDBAが直接実行可能なSQLスニペット（即座に利用できるSQLコード）が含まれています。

レポート内に記載されているSQLクイックリファレンス：

-- Check filesystem auto-storage path usage 
SELECT STORAGE_GROUP_NAME, DB_STORAGE_PATH, FS_TOTAL_SIZE, FS_USED_SIZE, 
       DECIMAL(FS_USED_SIZE * 100.0 / NULLIF(FS_TOTAL_SIZE,0), 5, 2) AS PCT_USED 
FROM SYSIBMADM.STORAGE_PATHS; 
 
-- Reorg to reclaim space in USERSPACE1 
REORG TABLE BDI50.STORE_SALES ALLOW WRITE ACCESS RECLAIM EXTENTS; 
 
-- Refresh statistics on the largest tables 
RUNSTATS ON TABLE BDI50.STORE_SALES WITH DISTRIBUTION AND INDEXES ALL; 
RUNSTATS ON TABLE BDI50.CATALOG_SALES WITH DISTRIBUTION AND INDEXES ALL; 
RUNSTATS ON TABLE BDI50.INVENTORY WITH DISTRIBUTION AND INDEXES ALL;

このユースケースは、MCP統合の重要な実用的メリットを示しています。
エージェントは単に一つのメトリックを取得するだけではありません。
複数のツール呼び出しを調整し、表領域（テーブルスペース）のビュー、I/Oモニター、カタログ統計にわたる結果を関連付け、即座に行動に移せる構造化された出力を生成します。
通常、同様のワークフローを行うには、DBAが手動で複数のクエリを実行し、複数のシステムビューを照合し、I/Oモニターのデータを調査した上で、その結果をまとめる必要があります。
ここでは、それら一連のプロセス全体がたった一度の自然言語プロンプトによって実行できることをご紹介しました。

まとめ

Db2 Genius Hub MCPは、単にクエリを簡素化するだけの抽象化レイヤーではありません。
これは、多段階の対話型ワークフロー向けに設計されたプロトコルを介し、DBA（データベース管理者）が使用するのと同じ診断データにAIエージェントが直接アクセスできるようにする「架け橋」となるものです。
利用可能なツールには、表スペースの使用率、バッファープールのパフォーマンス、クエリの実行計画（Explain Plan）、インデックス分析、ロックの監視、HADRの状態、バックアップ状況などが含まれます。

セットアップは非常に簡単です。
サービスの稼働と/healthエンドポイントの応答を確認し、クライアント側のMCP設定にJSONブロックを1つ追加するだけで、エージェントとの対話ですぐにこれらのツールを利用できるようになります。
導入後は、キャパシティプランニングのユースケースが示すように、自然言語を用いてこれらのツールをどのように組み合わせるかによって、分析の深さが決まります。

さわってみよう Db2 AIエディション・シリーズのご紹介

#1から#5まではAIアシスタント機能についてご紹介しています。
#6と#7はモニタリング機能についてご紹介しています。
#8は耐量子暗号化機能についてご紹介しています。
#9は耐量子暗号化機能を含むv12.1.5の新機能についてご紹介しています。
#10と#11はv12.1.5以降で利用できるようになったSQLによる生成AI機能についてご紹介しています。
#12ではDb2 Genius Hub 1.1.3以降で利用できるようになったDb2 Genius Hub MCP ServerとIBM Bobからそれを利用する方法について概説しています。

#1では、Db2入門者、初心者には作成が難しいと思われる複雑なSQLをAIアシスタントを使って作成しています。加えて、Db2 Genius Hub概要、無料評価版のダウンロードサイトやマニュアルURLもご紹介しています。#1からお読みいただくことをお勧めいたします。
さわってみよう Db2 AI エディション #1 〜エージェント型AIアシスタント編 Part#1〜
https://qiita.com/ibm_tk/items/e763bbea3fcf5e8a27a9

#2では、AIアシスタントでデータベースの稼働状況のサマリーを表示しています。
さわってみよう Db2 AI エディション #2 〜エージェント型AIアシスタント編 Part#2〜
https://qiita.com/ibm_tk/items/e11986879f6eca23c249

#3では、AIアシスタントでデータベースの応答時間の履歴を表示しています。
さわってみよう Db2 AI エディション #3 〜エージェント型AIアシスタント編 Part#3〜
https://qiita.com/ibm_tk/items/24647bc2db6a3a266d7c

#4では、AIアシスタントでデータベースのバックアップ履歴とプロセッサー利用状況の履歴を表示しています。
さわってみよう Db2 AI エディション #4 〜エージェント型AIアシスタント編 Part#4〜
https://qiita.com/ibm_tk/items/8d11c4e9fd39740d923d

#5では、AIアシスタントでクエリのスループットを表示しています。
さわってみよう Db2 AI エディション #5 〜エージェント型AIアシスタント編 Part#5〜
https://qiita.com/ibm_tk/items/e2583b00f624e351ce02

#6となる"さわってみよう Db2 AIエディション#6 〜モニタリング編 Part#1〜"ではモニタリング機能をご紹介しています。
https://qiita.com/ibm_tk/items/cdedc3a878998199cfee

#7となる"さわってみよう Db2 AIエディション#7 〜モニタリング編 Part#2〜"では監視(モニター)レポート作成機能をご紹介しています。
https://qiita.com/ibm_tk/items/81608900a0e2c89c18fc

#8となる"さわってみよう Db2 AIエディション#8 〜耐量子暗号化機能編 Part#1〜"では耐量子暗号化機能と登場した背景などについて記述しています。
https://qiita.com/ibm_tk/items/57a115c0d284697dd147

#9となる"さわってみよう Db2 AIエディション#9 〜v12.1.5新機能編 Part#1〜"ではv12.1.5の新機能のハイライトをご紹介しています。
https://qiita.com/ibm_tk/items/daabdf8215b430e804d8

#10となる"さわってみよう Db2 AIエディション#10 〜SQLで生成AI編 Part#1〜"ではv12.1.5以降で利用できるようになったSQLから使える生成AI機能(TEXT_GENERATION関数など)をご紹介しています。
https://qiita.com/ibm_tk/items/54a169cffcfbb9be0fed

#11となる"さわってみよう Db2 AIエディション#11 〜SQLで生成AI編 Part#2〜"ではv12.1.5以降で利用できるようになったSQLから使える生成AI機能(TO_EMBEDDING関数, セマンティック検索など)をご紹介しています。
https://qiita.com/ibm_tk/items/3085c90674561b9d80e7

#12となる"さわってみよう Db2 AIエディション#12 〜Db2 Genius Hub MCP Server編 Part#1〜"ではDb2 Genius Hub v1.1.3以降で利用できるようになったDb2 Genius Hub MCP Serverの概説とIBM Bobからそれにアクセスする方法などをご紹介しています。
https://qiita.com/ibm_tk/items/639e85ed43f1bfad8f07