9月26日、Databricksが「From Data to Dialogue: How S&P Global Energy Made Its Structured Data Estate Conversational with Databricks Genie Agents and MCP」と題した記事を公開した。この事例の核心は「SME（ドメイン専門家）がコードを一行も書かずにAIエージェントを公開できる」という点にある。S&P Global EnergyがDatabricks Genie AgentsとMCP（Model Context Protocol）を活用し、LNGや化学品など複雑な構造化データ資産をAIエージェントが自然言語で問い合わせられる仕組みに変えた実装事例だ。
エンジニアリングいらずでデータを「会話可能」にする——何が面白いか
従来、構造化データをAIに繋げようとすると、手書きのテキスト-to-SQLパイプライン、ユースケースごとのカスタムAPI、あるいは外部AIツールへのデータエクスポートという三択を迫られた。いずれも「データを最もよく理解している人（SMEやアナリスト）」と「アクセス層を作る人（エンジニア）」が分離するという構造的な問題を抱えており、新しい対話型データ体験のリードタイムは数ヶ月単位だった。
S&P Global EnergyのVP、Priyanka John氏が示した解答は、この分離を根本から解消するアーキテクチャだ。その設計思想をひと言で言えば「専門知識の所在とツール公開の権限を一致させる」ということになる。SMEが業界固有の定義をGenie Agent上に書き込み、そのエージェントがそのままMCPサーバーとして自動公開される。エンジニアへのチケット起票も、カスタムAPIの実装も不要だ。
なお、ここで使われているMCPはAnthropicが策定したオープンプロトコルで、AIエージェントが外部ツールやデータソースと標準化された方法でやり取りするための仕様だ。オープンスタンダードであるため、社内エージェントだけでなく顧客の外部エージェントも同一エンドポイントに接続できる点が、エンタープライズ用途での強みになっている。
アーキテクチャの全体像：3層構造
Layer 1：SMEがGenie Agentをキュレーションする
最初の層はコード不要でSMEが担う。
S&P Global Energyのデータは、LNG・化学品・原油・精製品・ガス＆電力など多岐にわたり、LNG単体でも「設備仕様」「カーゴ」「アウテージ」「供給需要ファンダメンタルズ」「ネットバック」「価格」などのデータセットに分かれる。
重要なのは「コモディティごとに一つの巨大エージェント」を作らないという設計判断だ。LNGの例では：
- LNG Assets & Contracts Genie Agent — 設備、オペレーター、長期契約
- LNG Cargo Genie Agent — カーゴ追跡、フィクスチャー、商業条件
- LNG Tenders Genie Agent — テンダー情報
- LNG Outages Genie Agent — アウテージと設備能力への影響
- LNG Supply & Demand Genie Agent — 地域別シナリオ
- LNG Netbacks Genie Agent — ハブ価格・海上運賃・ボイルオフを考慮したネットバック
- LNG Prices Genie Agent — 過去・予測価格カーブ
データソースがDatabricks以外にある場合は、Lakehouse Federationコネクタでデータ移動なしに取り込める。
各エージェントの中でSMEが行う作業は、テーブル・カラムの説明、クエリ例、ビジネス定義の追加だ。「浮体貯蔵（floating storage）とは、閾値速度以下で3日以上停泊しているカーゴを指す」といった業界固有の定義をここに書き込む。汎用的なテキスト-to-SQLがスキップしがちなこのステップが、ユーザーの信頼を左右するとPriyanka John氏は強調する。こうしたセマンティック層への投資こそが、デモ品質と本番品質を分かつ最大の変数だという。
Layer 2：Genie AgentがそのままMCPサーバーになる
各Genie Agentは、追加デプロイなしで自動的にDatabricks管理のMCPサーバーとして公開される。エンドポイントの形式は：
https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}
各サーバーが公開するツールはシンプルで2つだけだ：
- genie_query_space — 自然言語の質問を投げる
- genie_poll_response — 会話IDとメッセージIDを使って結果を取得する
この「質問して、ポーリングで受け取る」パターンは、SQLウェアハウスに対する非同期実行と相性がいい。権限管理はUnity Catalogがそのまま機能するため、セキュリティレイヤーを別途構築する必要がない。
Layer 3：FastMCPプロキシでクロスドメイン合成
「サビン・パスのアウテージがアジア向けカーゴプレミアムにどう影響したか？」という質問は、OutagesとCargo両方のエージェントをまたぐ。ナフサ価格が化学品の生産マージンに与える影響を問えば、Refined ProductsとChemicalsを横断する。こうした質問はエネルギー市場では日常的に発生するが、単一エージェントでは対処しきれない。
そこで登場するのがFastMCPだ。FastMCPはJlowin氏が開発したOSSのPythonライブラリで、MCPサーバーの構築・合成・プロキシ化を簡潔に記述できる。複数の独立したMCPサーバーを束ねて一つのエンドポイントとして公開するプロキシ・合成機能が、このアーキテクチャではとくに重要な役割を果たす。個別Genie AgentをそれぞれMCPサーバーとして扱い、コモディティ単位のコンポジットエンドポイントとして統合することで、クライアントは接続先を一本化しながらクロスドメイン質問に対応できる。
from fastmcp import FastMCP
# グループ別Genie AgentをDatabricksのMCPサーバーとして取得
cargo = FastMCP.as_proxy(genie_mcp_config("lng_cargo_agent_id"), name="cargo")
outages = FastMCP.as_proxy(genie_mcp_config("lng_outages_agent_id"), name="outages")
netbacks= FastMCP.as_proxy(genie_mcp_config("lng_netbacks_agent_id"),name="netbacks")
# コモディティバンドルとして合成
lng = FastMCP(name="lng-composite")
lng.mount(cargo, prefix="cargo")
lng.mount(outages, prefix="outages")
lng.mount(netbacks, prefix="netbacks")
クライアントはコモディティごとに1つのエンドポイントに接続するだけで、cargo_genie_query_agent、outages_genie_query_agentなどのツール群にアクセスできる。どのグループエージェントにルーティングするかはLLMが判断し、クロスグループ質問であれば複数に並列で投げて結果を統合する。ツール名にcargo_やoutages_のようなプレフィックスを明示するのも、LLMの正確なルーティングを助けるための意図的な設計だ。
ビジネスへの影響
- リードタイム：新しいデータドメインの公開が「数ヶ月」から「数日」に短縮
- 役割の変化：SMEがチケットを起票してエンジニアに依頼する側から、自分でGenie Agentをキュレーションして公開する側に
- ガバナンス：Unity Catalogの権限管理がそのまま適用され、並列のセキュリティスタックが不要
- 外部連携：MCPはオープンスタンダードのため、社内エージェントだけでなく顧客の外部エージェントも同じエンドポイントに接続可能
- 品質の継続的担保：Genie Agent Benchmarksによる精度の自動測定
最後の「品質の継続的担保」について補足しておきたい。AIエージェントの本番運用において見落とされがちなのが、指示やデータを更新した後の品質リグレッションだ。Genie Agent Benchmarksは、同一の質問を複数の表現バリエーションで投入し、生成されたSQLや回答の精度を自動測定する仕組みだ。SMEが新しいビジネス定義を追記したり、テーブル構造が変わったりした際に再測定を走らせることで、改修前後の精度変化を定量的に把握できる。単なるデプロイ後の動作確認にとどまらず、「SMEが生成SQLに同意する割合」をユーザー採用の先行指標として継続追跡できる点が、本番品質を維持するうえで重要だとPriyanka John氏は述べている。
実装で得た教訓
- Genie Agentは狭くキュレーションする。一つのコモディティに一つの大きなエージェントではなく、データセットグループごとに一つ。クロスドメインの合成はMCP層で行う
- パイプラインより先にLakehouse Federationを試す。新たなETLジョブを作らずに「会話可能」な状態に到達できる
- セマンティック層への投資を惜しまない。カラム説明、ビジネス定義、クエリ例がデモと本番品質を分ける
- ツール名のプレフィックスを明確に。
cargo_やoutages_のような命名がLLMの正確なルーティングを助ける - レイテンシより信頼性を測る。SMEが生成SQLに同意する割合が、ユーザー採用の先行指標になる
詳細はFrom Data to Dialogue: How S&P Global Energy Made Its Structured Data Estate Conversational with Databricks Genie Agents and MCPを参照していただきたい。
