データから対話へ：S&P Global EnergyがDatabricks Genie AgentとMCPを活用して構造化データ資産との対話を実現した方法

S&P Globalの目標は、お客様が当社のデータやリサーチ製品全体からインサイトを発見し、活用する方法を根本的に改善することでした。AIを活用した検索や要約も重要ですが、より大きなビジネス価値は、信頼できるデータへの自然言語によるアクセス、より豊かなコモディティ横断的な分析、そして従来は別々の事業部門に存在していたインサイトを結びつける能力を通じて、より迅速な意思決定を可能にすることから生まれます。AIエージェントは、お客様が関係性を明らかにし、より効率的にリサーチを生成し、従来よりも幅広い情報から実用的なインテリジェンスを導き出すのを支援します。   —Priyanka John, Vice President, S&P Global Energy

大規模で複雑な構造化データ資産をAIエージェントやアシスタントで利用できるようにしようとしたことがあるなら、おそらく私たちと同じ壁にぶつかったことがあるでしょう。エージェントの性能はアクセスできるコンテキストの質に左右されますが、企業のデータが1つの整理され、十分に文書化された場所に保管されていることは滅多にありません。

S&P Global Energyでは、当社のデータは 化学物質、原油、石油製品、ガス＆電力、液化天然ガス（LNG）など 多岐にわたり、各コモディティ自体が豊富なデータセット群で構成されています。LNGだけでも、施設の仕様、カーゴ（積荷）、停止情報、需給ファンダメンタルズ、ネットバック、過去および予測価格、契約などが含まれます。化学物質は、生産能力、生産量、稼働率、貿易、最終用途別および誘導体別の需要、在庫変動、国・地域レベルの需給バランスに及びます。他のコモディティも同様のパターンをたどります。このデータは、Databricksおよびいくつかの非Databricksソースにまたがって存在しています。

私たちの目標は野心的ですが、表現はシンプルです。 Model Context Protocol（MCP）を通じて、構造化データ資産全体を外部のAIエージェントが利用できるようにすること です。これにより、自社だけでなくお客様のエージェントやアシスタントも、自然言語で質問し、ガバナンスの効いた信頼できる回答を得られるようになります。

私たちはいくつかのアプローチを評価しました。その中で圧倒的に効果的だったのは、管理された MCPサーバーとして公開され、MCPプロキシレイヤーによってドメイン固有のバンドルに構成された Databricks Genie Agentsでした。

この記事では、以下の内容について説明します。

• 当社の分野専門家（SME）が、エージェントのコードを1行も書くことなく、各コモディティ内のデータセットグループごとに1つずつ、焦点を絞ったGenie Agentsをどのようにキュレートしているか。
• 各Genie Agentがどのように自動的にガバナンスの効いたMCPサーバーになり、任意のMCP互換クライアントやエージェントにすぐに接続できるようになるか。
• FastMCPベースのプロキシを使用して、複数のGenie MCPサーバーをドメイン横断的な質問用の複合エンドポイントにどのように構成しているか。
• このアーキテクチャにより、AIを活用したデータ製品の市場投入期間（Time to Market）がなぜ劇的に短縮されたのか。

Genie Agentsにより、当社のドメイン専門家はデータに関する知識を直接製品化できるようになりました。以前は完全な開発サイクルが必要だった作業が、今では数日で完了し、すべての回答が当社のガバナンス境界内に留まります。—Priyanka John, Vice President, S&P Global Energy

課題：構造化データは保存するのは簡単だが、対話するのは難しい

大規模言語モデルは会話や推論に非常に優れていますが、データへの架け橋を構築しない限り、データに関する質問に答えることはできません。企業の構造化データにおいて、その架け橋は歴史的に以下のいずれかを意味していました。

1. 手動で構築されたText-to-SQLパイプライン — 強力ですが脆弱です。スキーマの変更、曖昧なカラム名、ドメイン固有のメトリクス定義（「何をもって停止日とするか」など）のたびに、エンジニアリング作業が発生します。
2. ユースケースごとのカスタムAPI — 新しい質問パターンごとに、新しいエンドポイント、新しいスプリント、新しいリリースが必要になります。
3. 外部のAIツールへのデータの書き出し — データの重複が発生し、最新性が失われ、ガバナンスの境界外に出てしまいます。

これらのアプローチはいずれも同じ課題を抱えています。 データを最もよく理解している人々（当社のSMEやアナリスト）が、アクセスレイヤーを構築する人々ではないということです。 すべてのインサイトはエンジニアリングのバックログを経由しなければなりませんでした。新しい対話型データエクスペリエンスの市場投入期間は、数ヶ月単位で測定されていました。

私たちが必要としていたのは、ドメイン専門家がデータへの対話型アクセスを直接キュレートして公開でき、エンジニアリング部門がエージェントの接続方法を標準化でき、ガバナンスが中央集中化されたアプローチでした。それこそが、Genie AgentsとMCPの組み合わせによって実現したことでした。

アーキテクチャ：セマンティックレイヤーとしてのGenie Agents、コントラクトとしてのMCP

当社のアーキテクチャには3つのレイヤーがあり、各レイヤーはそれに最も適した人々によって所有されています。上の図は、S&P Global Energyのネットワーク内にあるものと、外部のクライアント環境にあるものを含む、エンドツーエンドのフローを示しています。

レイヤー1：SMEがデータセットグループごとに1つのGenie Agentをキュレートする

ここから魔法が始まります。特筆すべきは、コードが一切不要である点です。

当社のSMEは、まずビジネスドメインに関連するテーブルを選択することから始めます。

• テーブルがすでにDatabricks内にある場合、Unity Catalogを通じて直接使用します。
• データが 非Databricksソースにある場合、Lakehouse Federation コネクタを介して取り込みます。データの移動や重複するパイプラインは不要です。フェデレーションテーブルはネイティブテーブルと並んで表示され、同じガバナンスを継承します。

その後、関連するテーブルをグループ化し、コモディティごとに1つの巨大なエージェントを作るのではなく、 データセットグループごとに1つのGenie Agent を作成します。コモディティの各サブカテゴリが、それぞれ焦点を絞った独自のGenie Agentになります。例えば、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 — 過去および予測の価格曲線

他のすべてのコモディティも、独自のサブカテゴリを持つ同じパターンに従います。例えば、化学物質には、 生産能力、生産量、稼働率、貿易、最終用途別および誘導体別の需要、在庫変動、国・地域レベルの需給バランスのためのグループレベルのGenie Agentsがあります。原油、石油製品、ガス＆電力も同様に整理されています。その結果、少数のばらばらで無秩序に広がるAIツールではなく、細かくスコープが絞られた小さなGenie Agentsのフリートが構築されます。

各エージェントの内部で、SMEはText-to-SQLを現実世界で実際に機能させるためのコンテキストを追加します。これには、テーブルやカラムの説明、クエリの例、重要なメトリクスのための信頼できるアセット、ビジネス定義（例：「洋上貯蔵（floating storage）とは、しきい値速度未満で航行する船舶内で3日以上停泊しているカーゴと定義する」など）が含まれます。これは一般的なText-to-SQLソリューションが省略しがちなステップであり、ユーザーが回答を信頼するかどうかを決定づけるステップでもあります。

組織における重要な気づき： キュレーションはエンジニアリングの仕事ではなく、ドメインの仕事になったということです。 LNGの文脈における「洋上貯蔵（floating storage）」の意味を理解している人が、Genieにその意味を教える人になります。

レイヤー2：すべてのGenie Agentが自動的にMCPサーバーに

ここでDatabricksが面倒な作業をすべて引き受けてくれました。各Genie Agentは、設定不要でDatabricks管理下のMCPサーバーとして、以下のような形式のエンドポイントで公開されます。

https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}

デプロイやホストの手間は一切ありません。各サーバーは、シンプルで洗練されたツールインターフェースを提供します。基本的にはエージェントごとに2つのツールが用意されています。

1. クエリツール（genie_query_space） — エージェントが自然言語の質問をエージェントに送信します。
2. レスポンスツール（genie_poll_response） — エージェントは同じ会話IDとメッセージIDでポーリングを行い、準備ができ次第、生成されたSQLや結果セットを含む完全なレスポンスを取得します。

この「質問してポーリングする」という2つのツールを用いたパターンは、エージェント型のワークロードに非常に適していることがわかりました。質問はSQLウェアハウスに対して非同期で実行され、エージェントはレスポンスの準備ができるまで、クエリツールから返された会話IDとメッセージIDを使ってポーリングを行います。

同様に重要な点として、これらの管理サーバーはUnity Catalogによってガバナンスが効いています。Genie Agent（またはその背後にいるユーザー）は、アクセス権限を持つエージェントや基盤となるテーブルにのみアクセスできます。認証はプラットフォームによって処理されます。AIアクセス用のセキュリティレイヤーを新たに構築する必要はなく、既存のセキュリティレイヤーをそのまま引き継ぐことができました。

レイヤー3：FastMCPプロキシを使用してグループGenie Agentをコモディティバンドルに構成する

データセットグループごとに1つのGenie Agentを配置することで、各エージェントのフォーカスと精度を高く維持できます。しかし、実際のビジネス上の質問は日常的に複数のグループにまたがります。例えば、「Sabine Passでの最近の操業停止は、アジア向けの貨物プレミアムにどのような影響を与えましたか？」という質問は、Outages（操業停止）とCargo（貨物）の両方のGenie Agentに同時に関係します。また、「ナフサ価格は化学品の生産マージンにどのように影響していますか？」といったコモディティをまたぐ質問は、Refined Products（石油製品）とChemicals（化学品）のGenie Agentにまたがります。

1つの巨大なエージェントを構築したり（回答の質が低下します）、すべてのクライアントに多数の個別サーバーを設定させたりする代わりに、FastMCPのプロキシ機能と構成機能を使用して、複合MCPエンドポイントを作成しました。通常はコモディティごとに1つ作成し、そのコモディティのグループレベルのGenie MCPサーバーを、名前空間付きのツールを持つ単一のサーバーの背後にマウントします。より高レベルの複合エンドポイントでも、同様の方法で複数のコモディティをバンドルできます。

from fastmcp import FastMCP

# Each group-level Genie Agent is a managed MCP server on Databricks 
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”) 

# Compose the group Genies into one commodity bundle 
lng = FastMCP(name=“lng-composite”) 
lng.mount(cargo, prefix=“cargo”)
lng.mount(outages, prefix=“outages”)
lng.mount(netbacks, prefix=“netbacks”) 

# The same pattern repeats for Chemicals, Crude Oil, Refined Products, Coal …

（図解用のスニペットです。お使いのFastMCPのバージョンや認証設定に合わせて調整してください。）

その結果、エージェントはコモディティごとに 1つ の複合エンドポイントに接続し、厳選されたグループツールのセット（cargo_genie_query_agent、outages_genie_query_agent、netbacks_genie_query_agentなど、それぞれ対応するgenie_poll_responseとペアになっています）を参照できます。エージェントのLLMは、質問をどのグループのGenieにルーティングするかを決定するか、あるいはグループをまたぐ質問を複数のGenieに分散して送信し、その結果を統合します。

これにより、両方のメリットを享受できるようになりました。 下層には特定の領域に特化した高精度なグループレベルのGenie Agentを配置し、上層にはコモディティや資産全体をカバーする広範な対話型アクセスを提供します。

ビジネスにおける変化

ビジネスのステークホルダーにとって、上記の技術的な詳細は、いくつかの非常に具体的な成果をもたらします。

市場投入までの時間が劇的に短縮されました。 以前は、新しい対話型データ体験を立ち上げるには、要件定義、API設計、text-to-SQLエンジニアリング、テスト、デプロイという完全な開発サイクルが必要でした。このアーキテクチャでは、新しいデータセットグループ（またはコモディティ全体）を立ち上げることは、SMEが対応するGenie Agentを作成してキュレーションすることを意味します。エージェントが作成された瞬間に、MCPエンドポイントも存在することになります。

SMEは依頼者ではなく、パブリッシャーになりました。 LNG貨物や化学品の需給バランスを理解しているドメインエキスパートは、データを公開するためにチケットを起票する必要はもうありません。彼らがGenie Agentをキュレーションすれば、すぐに本番環境に反映されます。エンジニアリングの取り組みは、オーダーメイドのアクセスレイヤーの構築から、薄く再利用可能な1つのプロキシレイヤーの維持へとシフトしました。

ガバナンスが組み込まれています。 エージェントが送信するすべての質問は、管理されたテーブル（ネイティブまたはフェデレーション）上で、完全な監査性を備えたUnity Catalogの権限を介して実行されます。AIでデータを利用できるようにすることは、管理外でデータを利用できるようにすることを意味するわけではありません。

1つの統合パターンで、社内外の多くのコンシューマーに対応。 MCPはオープンスタンダードであるため、同じ複合エンドポイントが社内エージェント、顧客向けのAI体験、そして極めて重要なこととして、管理されたS&P Global Energyデータに独自のMCP互換エージェントやアシスタントを直接接続できる外部顧客にも対応します。架け橋を一度構築すれば、社内外を問わず、すべてのMCPクライアントがそれを利用できます。

回答の品質は測定可能であり、その状態が維持されます。 価格設定、供給、契約データが実際の意思決定を左右するドメインでは、ユーザーはすべての回答と計算を信頼できる必要があります。Genie Agent Benchmarksを使用すると、SMEはユーザーが実際に質問する方法を反映したテスト質問（同じ質問の複数の言い回しを含む）を定義し、検証済みの回答に対してエージェントの精度を自動的にスコアリングする組み込みの方法を利用できます。同様に重要な点として、指示、データ、またはビジネスロジックを微調整した後にベンチマークを再実行できるため、長期にわたって精度が維持されます。その結果、「キュレーション、ベンチマーク、改善、再ベンチマーク」という効率的な継続的品質ループが実現し、データや顧客の質問が進化しても、エージェントの精度を維持できます。

得られた教訓とベストプラクティス

同様の道を検討しているチームに向けて、私たちの取り組みから得られた実践的なポイントをいくつか紹介します。

1. Genie Agentの対象範囲を絞り、十分にキュレーションされた状態を維持する。 エージェントが明確な指示とサンプルクエリを使用して、1つの特定のデータドメインをカバーしている場合に、回答の品質が最も高くなります。コモディティごとに1つのエージェントを構築したり、さらに悪いことに、すべてを支配する1つの巨大なエージェントを構築したりしたくなる誘惑に耐えてください。代わりに、MCPレイヤーで複数のデータドメインを統合します。
2. パイプラインを構築する前にLakehouse Federationを使用する。 Databricks以外のソースの場合、フェデレーションを使用することで、新しいETLジョブを1つも作成することなく「対話型」を実現できました。頻繁にアクセスされるパス（ホットパス）は、後からいつでもマテリアライズできます。
3. セマンティックレイヤーに投資する。 列の説明、ビジネス定義、信頼できるサンプルクエリこそが、デモと製品を分ける要素です。これは、SMEの時間を費やす価値が十分にあります。
4. 複合ツールの名前空間を明確にする。 エージェントが多くのグループGenieのツールを参照する場合、cargo_やoutages_などのプレフィックスを付けることで、LLMが質問を正しくルーティングできるようになります。
5. レイテンシーだけでなく、信頼性を測定する。 私たちは、キュレーション中にSMEがGenieの生成したSQLにどの程度同意したかを追跡しました。これは、ビジネスユーザーがその体験を採用するかどうかを示す最良の先行指標です。

結論

私たちの目標は、LNG、化学品、原油、石油製品、ガス＆電力などにまたがる構造化データ資産全体を、安全、正確、かつ迅速にAIエージェントが利用できるようにすることでした。SMEがキュレーションしたセマンティックレイヤーとしてのDatabricks Genie Agent、デプロイ不要の統合コントラクトとしての管理されたMCPサーバー、およびクロスドメイン構成のためのFastMCPプロキシを使用することで、まさにそれを実現しました。

• スピード： 新しい対話型データドメインは、開発サイクルを経ることなく数日で本番環境に反映され、市場投入までの時間を劇的に短縮します。
• 正確性： ドメインに特化し、SMEがキュレーションしたエージェントが、ビジネスユーザーが本当に信頼できる回答を提供します。
• ガバナンス： Unity Catalogが、ネイティブデータとフェデレーションデータの両方において、すべての質問を保護します。並行して維持管理するセキュリティスタックは不要です。
• オープン性： 1つのMCP標準ブリッジが、社内外を問わず、現在および将来のすべてのエージェントに対応します。

しかし、より本質的な変化は組織的なものです。データを理解している人々が、データへのアクセスを公開する立場になったのです。単一のテクノロジー以上に、この変化こそが、ユーザーがクエリを実行する対象であった構造化データを、単に会話ができる対象へと変えたのです。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事