はじめに

前回の記事では、MCP（Model Context Protocol）サーバーを自作し、AIエージェントがDb2上のデータを自律的に探索・分析するデモをご紹介しました。

今回はその続編として、AIエージェントに「デモ環境そのものを作らせる」というアプローチに挑戦しました。テーブル設計、DDL実行、テストデータ投入、デモクエリの作成と実行、さらには実行計画の分析まで——すべてをチャットの対話だけで完結させます。

従来のデモ準備では、担当者がSQLスクリプトを手作業で書き、テストデータを用意し、動作確認を繰り返すという時間のかかるプロセスが必要でした。MCPを介したAIエージェントは、このプロセスをどこまで自動化できるのか？実際に試した記録をお伝えします。

使用したMCPサーバーとツール体系

今回使用したのは、Db2 Warehouse on Cloud（Tokyo リージョン）のREST APIをラップした db2woc MCPサーバーです。前回記事で紹介した自作MCP（TypeScript/Node.js製）とは別に、Db2 WoCのREST API層を活用するアプローチをとっています。

このMCPサーバーの特徴は、2つのメタツールで構成されている点です。

AIエージェントは「まず何ができるか調べ、次に実行する」という探索→実行のループを自律的に回します。これは前回記事の固定19ツール方式とは対照的で、ツールが動的に増減する環境にも柔軟に対応できるアーキテクチャです。

実際に今回のデモ構築で使われた内部ツールは以下の4つです。

デモ1：再帰SQLによる部品表（BOM）展開

やりたいこと

製造業でおなじみの部品表（Bill of Materials）を題材に、Db2の再帰CTE（WITH RECURSIVE）を実演するデモを作ります。

チャットでの指示

ユーザーが伝えたのはたった一言——「再帰SQLが利用可能な部品表をCREATE TABLEしてください。」

AIエージェントはこの指示から以下を自律的に判断・実行しました。

1. 「自転車」を最上位とした3階層の部品表を設計
2. CREATE TABLEとINSERTを一括実行
3. エラー発生時に原因を分析し、即座に修正して再実行

エラーからの自己修正

最初の実行で SQLCODE=-433（値が長すぎる）というエラーが発生しました。原因は VARCHAR(20) に対して「ブレーキレバー」（UTF-8で21バイト）が収まらないこと。AIエージェントはエラーメッセージを読み取り、VARCHAR(50) に拡張して即座に再作成しました。

CREATE TABLE MY_SCHEMA.BOM (
  PARENT_PART  VARCHAR(50) NOT NULL,
  CHILD_PART   VARCHAR(50) NOT NULL,
  QUANTITY     INTEGER NOT NULL DEFAULT 1,
  UNIT_COST    DECIMAL(10,2) DEFAULT 0,
  PRIMARY KEY (PARENT_PART, CHILD_PART)
)

投入されたデータは23行。自転車を頂点に、フレーム・前輪・後輪・ハンドルなどの中間部品、さらにその下のパイプ・スポーク・ギアといった末端部品まで、3階層のツリー構造です。

再帰CTEの実行——Db2固有の制約を乗り越える

次に、BOM全展開のクエリを実行します。ここでもう一つのエラーが発生しました。

SQLCODE=-345——Db2の再帰CTEでは、再帰部分に JOIN ... ON 構文が使えないというDb2固有の制約です。他のRDBMS（PostgreSQLやSQL Serverなど）では許容されるケースが多いため、見落としがちなポイントです。

AIエージェントはこの制約を理解し、カンマ結合 + WHERE句のスタイルに自動で書き換えました。

WITH BOM_TREE (...) AS (
  -- アンカー部
  SELECT ... FROM MY_SCHEMA.BOM B
  WHERE B.PARENT_PART = '自転車'

  UNION ALL

  -- 再帰部：カンマ結合 + WHERE（JOIN ... ONは使用不可）
  SELECT ...
  FROM BOM_TREE T, MY_SCHEMA.BOM B
  WHERE B.PARENT_PART = T.PART
)
SELECT ... FROM BOM_TREE ORDER BY PATH

結果は23行が正常に展開され、最下層（リーフ）部品の合計原価は ¥26,500 と算出されました。

実行計画の分析

AIエージェントは db2_explain_sql ツールを使い、ビジュアル実行計画を取得しました。主要なオペレータの構造はこのようになっています。

BOMテーブルが23行と小さいため全表スキャンが選択されていますが、データ量が増えた場合は PARENT_PART へのインデックス作成で再帰部のNested Loop JoinがIndex Scanに切り替わることが期待できます。

デモ2：地理空間機能による東京配送ネットワーク分析

やりたいこと

Db2のSpatial機能（DB2GSEスキーマ）を使い、店舗検索・商圏分析・配送ルート距離計算を組み合わせたデモを作ります。

チャットでの対話

ユーザーが「地理空間の機能のデモを作りたい」と伝えると、AIエージェントはテーマと地域を質問しました。ユーザーの回答は「店舗・拠点分析＋配送・物流の組み合わせ、東京周辺で」。

この対話から、AIエージェントは東京周辺コンビニ配送ネットワークというシナリオを自ら設計しました。

Spatial型カラムの壁を越える

テーブル作成時、DB2GSE.ST_POINT 型をカラムとして定義しようとして SQLCODE=-1666 が発生しました。Db2 Warehouse on Cloudはデフォルトがカラム型テーブル（COLUMN ORGANIZED）であり、Spatial型カラムをサポートしていません。

AIエージェントの対処は明確でした。

1. ORGANIZE BY ROW を指定して行編成テーブルとして作成
2. 緯度経度は DOUBLE 型で格納
3. ST_POINT はクエリ時に関数として動的生成

この「格納はスカラ、クエリ時にジオメトリ化」というパターンは、Db2 WoCでSpatial機能を使う際の実践的なベストプラクティスです。

作成されたテーブルとデータ

4本のデモクエリ

AIエージェントは以下4つのデモクエリを設計・実行しました。

① 最寄り店舗検索（ST_DISTANCE）

東京駅を基準に、距離が近い順にTOP5を検索。ST_POINT と ST_DISTANCE によるメートル単位の距離計算です。

② 商圏分析（ST_BUFFER + ST_WITHIN）

渋谷駅の半径約2km圏内にある店舗を抽出。ST_BUFFER でバッファ円を生成し、ST_WITHIN で包含判定を行います。渋谷ハチ公口店と中目黒駅前店の2店舗がヒットしました。

③ 配送エリアマッチング（ST_CONTAINS + ST_GEOMFROMTEXT）

WKT形式で定義されたポリゴン（配送エリア）に対して、各店舗が含まれるかを ST_CONTAINS で判定。同時に ST_DISTANCE でデポからの距離も算出します。15店舗がいずれかのエリアにマッチしました。

④ デポ別配送負荷サマリ

Spatial関数と集約関数を組み合わせ、デポごとの担当店舗数・総需要・最遠距離・車両あたり需要を一括算出。

東京湾岸デポの負荷が突出しており、エリア再編や車両増強の検討材料になります。このようにSQLの結果からビジネス上の示唆を導き出すところまで、一連のチャットの中で完結しています。

エラー対処のまとめ——AIはどう「失敗」したか

今回のデモ構築で、AIエージェントは3つのエラーに遭遇しました。いずれも人間のDBAでも遭遇し得る実践的な問題です。

注目すべきは、AIが単にエラーを報告するのではなく、原因を特定して代替案を即座に実行した点です。特にSQLCODE=-345（再帰CTEのJOIN制約）は、Db2固有の仕様でありドキュメントを読み込んでいなければ対処が難しいものです。AIの学習データにDb2の知識が含まれていることの実用的なメリットが表れた場面でした。

前回との比較：「分析させる」から「環境を作らせる」へ

前回記事との違いを整理します。

前回は「AIにデータを分析させる」段階でした。今回は、デモ環境そのものをAIに設計・構築させる段階に進んでいます。人間が行ったのはチャットで「再帰SQLのBOMを作って」「地理空間で東京周辺の配送ネットワークを」と要件を伝えただけ。テーブル設計、日本語テストデータの生成、エラー対処、デモクエリの設計・実行まで、すべてAIエージェントが自律的に遂行しました。

おわりに：MCPが変える「デモ準備」の常識

技術営業やPoC（Proof of Concept）の現場では、「デモを見せたいが、環境準備に時間がかかる」というジレンマが常にあります。

MCP経由のAIエージェントは、このボトルネックを根本から変える可能性があります。

• お客様の前で「では、御社のユースケースに合わせたデモをその場で作りましょう」と提案し、チャットで対話しながらリアルタイムにテーブルを作り、データを投入し、クエリを実行して見せる
• エラーが出ても、AIがその場で原因を説明し修正する過程自体が、Db2の堅牢性とAI連携の可能性を示すデモになる

「準備されたデモ」ではなく「目の前で生まれるデモ」。MCPとDb2の組み合わせは、技術検証の在り方そのものを変えていくのではないでしょうか。

技術スタック: db2woc MCP Server, IBM Db2 Warehouse on Cloud, Model Context Protocol, DB2GSE (Spatial)