ビジネスに関する問いへの答えは、データの中にあります。しかし、ダッシュボードはそれをどこまで効果的に引き出せているでしょうか。私の考えでは、あまり効果的ではありません。
ダッシュボードが答えるのは「昨日の問い」です。構築する前に抱えていた問いに応えるために作られており、ビジネスの焦点が変わった時点で作り直しが必要になります。
これは持続可能ではありません。AIの登場により、ダッシュボードがデータから答えを得るための最善の手段であり続ける期間も、長くはないでしょう。そこで私のチームは、この数年をかけて、まったく異なるものを構築してきました。静的なプロセスを、大規模言語モデルとのリアルタイムな対話へと変える仕組みです。社内のデータに関する質問の90%に、数秒で答えるEnterprise MCPが、それを支えています。
私たちはこれを「Enterprise Data by Workato MCP」と呼んでいます。そして、ビジネスインテリジェンスの自然な次の進化だと考えています。
Enterprise Data MCPが描くビジョン
このMCPの構築を始めた当初、従来のビジネスインテリジェンスのワークフローをAIで置き換えることは、現実的ではないと受け止められていました。AIが大きな変革をもたらすと確信している人たちでさえ、予測不能なビジネスの問いに対して、事実に基づく正確で再現性のある回答を生成する方法が見つかるのか、懐疑的でした。
しかし、ビジネスの問いはダッシュボードの依頼としてデータチームに届くわけではなく、会話として届きます。
- 「先四半期、EMEAでパイプラインが減少したのはなぜか」
- 「拡張率(エクスパンション率)が最も高い顧客セグメントはどれか」
- 「解約への影響が最も大きい製品はどれか」
私は自問しました。なぜこうした問いを、わざわざダッシュボードに置き換え続けているのか。データが直接、問いに答えればよいのではないか、と。
明確なビジネス上の問いに答えを得るために、データの所在を知っている必要も、レポートを作成する権限を持っている必要も、テーブル構造を理解している必要もあるべきではありません。しかも理想的には、ダッシュボードが完成する数日後ではなく、すぐに答えが得られるべきです。
私のビジョンは違うものでした。私のチームが Medallion Architecture の基準に沿って丁寧に構築・保守する、ごく少数のゴールドレイヤーのダッシュボードを、AIが直接クエリできるナレッジベースに供給するという形です。
Enterprise Data MCPのスコープ
このビジョンを最初に提案した時点では、対話型BIは、より大きなデータ戦略の一部にすぎませんでした。データ管理、データエンジニアリング、アナリティクスにも機会がありました。
しかし議論が進むにつれ、ひとつのことが明らかになりました。経営層に至るまで誰もが、データと対話する手段を求めていたのです。誰もが同じ課題、つまり「必要な情報を、今すぐ得るにはどうすればよいか」を抱えているからです。
このプロジェクトには、次のことが求められました。
エンドユーザーの多様性
エンドユーザーのグループを、職種(当初はプロダクト、営業、マーケティング、カスタマーサクセス)と、レベル(担当者から経営層まで)の両面で整理する必要がありました。
信頼できるデータ
データを検証し、想定される質問に対して適切なSnowflakeのテーブルを対応付ける必要がありました。
使いやすいインターフェース
ユーザーがMCPにアクセスする手段として、ClaudeとSlackのどちらを使うかを決める必要がありました。
実装上の課題
データエージェント、AI搭載のアナリティクスツール、対話型BIプラットフォームは、何年も前から存在しています。多くの企業が試してきましたが、安定した信頼性を実現できた例は多くありません。
LLMをデータセットに接続して質問すること自体は、難しくありません。難しいのは、モデルがビジネスを本当に理解していることを保証する点です。多くの人が私たちのビジョンに懐疑的だったのは、そのためです。
たとえば営業責任者がパイプラインについて質問したとき、システムはどのパイプライン定義を使うべきかを理解しているでしょうか。その理解がなければ、対話型アナリティクスはすぐに信頼の問題に行き着きます。
私たちは、想定されるあらゆるクエリを見越し、それぞれに答える方法を定義する必要がありました。さらに、MCPが回答の範囲外の質問に対しては、もっともらしい答えを作り出す(ハルシネーションを起こす)のではなく、範囲外であると認めることも必要でした。
また、MCPに寄せられた質問を匿名で集計し、回答できるクエリの範囲を拡大していく仕組みも必要でした。そして、その結果をMCPへ還元するフィードバックループも欠かせませんでした。
この問題は解決するには難しすぎると考える人が多くいました。概念実証(PoC)を作ることと、本番環境で一貫して正確な回答を返すシステムを構築することは、まったく別の話だったのです。
異論を突きつけられたとき、私とチームのもう一人のエンジニアは、その姿勢を一層強めました。周囲の雑音には耳を貸さず、取り組みに集中しました。あらゆるものの頭脳となるのはセマンティックモデルだと、わかっていたからです。
根本的な問いはこうでした。AIシステムが確実に推論できるビジネスの意味的な理解を、どのように作り上げるのか。そして、そのセマンティックモデルを、自動化でき、スケーラブルで、容易に保守できるものにするにはどうすればよいのか。これが私たちの焦点となりました。
MCPの構築方法
最も重要な要素はAIモデルではなく、モデルがビジネスを正しく理解できるようにするハーネスです。これが、WorkatoのEnterprise Data MCPを構築して学んだ教訓です。
ユーザーの目に触れるのは対話体験ですが、それを信頼に足るものにしているのは、その下にあるセマンティックなアーキテクチャです。次に、その部分を掘り下げていきます。
ここでは、アーキテクチャの各レベルとコンポーネントの概要を示します。
- MCPクライアントは、エンドユーザーまたはAIエージェントにとってのインタラクションレイヤーです。
- セマンティックレイヤーは、Workato上に構築された、ビジネス上のコンテキストと定義を提供します。
- MCPインテリジェンスは、Workato上に構築された、クエリを実行する層です。
- データソースは、データを提供します。
- アウトプットは、データをMCPクライアントに再び表示します。
セマンティックモデルを構築するために、Workatoはレシピを構築し、既存のビジネスインテリジェンスのワークブックをクロールして、そこに埋もれている指標の定義、計算フィールド、フィルターを抽出し、そのロジックからVQRを自動生成しました。この方法により、長年にわたって蓄積された組織の知見が、数時間でVQRライブラリになりました。また、クエリ履歴を確認し、VQRとして適格なクエリを判定して、VQRライブラリにアップサートしています。同じパイプラインがスケジュールに従って、またスキーマのドリフトが発生した際に実行され、バージョン管理を通じて更新がデプロイされます。
セマンティックレイヤーとMCPインテリジェンスレイヤーは、エージェントへの指示を自動でロードし、コアワークフローとSQL分類ルールを実行します。Enterprise Data by Workato MCPを使った呼び出しの例を次に示します。
すべての質問は、主に次の3つのパスのいずれかをたどります。
- VQR(Verified Query Repository:検証済みクエリリポジトリ)に一致する場合。VQRとは、事前に検証された質問からSQLへのパターンであり、高い信頼性で回答が返されます。
- 既存のVQRに近い場合。モデルがそのクエリを適応させます。
- どちらにも当てはまらない場合に限り、LLMがセマンティックモデルから直接SQLを生成します。このクエリは検証対象としてフラグが付けられます。
この階層化によって、重要な部分で回答の決定性が保たれています。
端的に言えば、正確性をもたらすのがVQRであり、VQRに一致するすべての回答は、推測ではなく検証済みのSQLに裏付けられています。そして決定性をもたらすのが、プログレッシブディスクロージャーを備えたWorkatoのツールです。すべての質問が決まった順序のツールを通過し、必要なコンテキストだけをロードするため、同じ質問には毎回同じ答えが返されます。
MCPの改善方法
WorkatoのEnterprise Data MCPのセマンティックモデルには、システムを継続的に改善していくための仕組みが組み込まれています。
可観測性
すべての質問、その質問に答えたパス(VQR、適応されたVQR、LLMが生成したSQL)、そして成功したかどうかを記録しています。このメタデータから、ギャップがどこにあるかが正確にわかり、次に何を調整すべきかが決まります。
自己修復型セマンティックモデル
ゴールドレイヤーのテーブルは変更されます。放置すると、そのドリフトがセマンティックモデルを気づかないうちに壊し、誤った回答が返されたり、回答が返らなくなったりします。私たちはVQR、リレーションシップ、テーブル定義の更新を自動化しており、マージ前のすべてのプルリクエストで、人によるレビュー(ヒューマン・イン・ザ・ループ)を行っています。
自己学習型セマンティックモデル
オンボーディングエージェントが新しいゴールドレイヤーのテーブルを監視し、セマンティックモデルに追加して、そのテーブル向けのVQRを提案します。その際、既存の指標とVQRを照合し、重複が生じないようにしています。
合成VQR
LLMが生成した良質なクエリは、検証を経たうえでVQRライブラリに昇格されます。ユーザーが投げかけたすべての新しい質問が、次のユーザーにとっての検証済みの回答になり得ます。システムは複利的に成長していきます。
利用コストとレイテンシーの削減方法
時間をかけて得た大きな教訓のひとつが、コストの管理方法でした。本番バージョンでは、クエリのたびにセマンティックモデル全体をロードしており、1回の質問あたり約185Kトークン、4〜6秒を要します。これに対し、次の2つの後継アプローチが、そのコスト構造を変えます。
プログレッシブディスクロージャー(ベータ)は、まずインデックスをロードし、その質問に必要なコンテキストだけを追加でロードします。
コンテキストグラフ(開発中)はキャッシュファーストの方式です。キャッシュにヒットすれば約200ミリ秒で回答でき、回答するクエリが増えるほど、次のクエリは速くなります。
同じ質問に対して同じ正しい答えを、80〜96%低いコストで提供できます。
ウェアハウスのコストインテリジェンス
同じアプローチは、ウェアハウス側のコストでも成果を上げています。Snowflake自身のACCOUNT_USAGEメタデータをセマンティックモデルに取り込み、コストに関する質問を自然言語で行えるようにしました。たとえば、アイドル状態のウェアハウスはどれか、ディスクにスピルしているクエリはどれか、支出の責任者が不明な領域はどこか、といった問いです。この分析により、ゾンビウェアハウスや非効率なクエリが明らかになり、Snowflakeの年間コストの大幅な削減につながるインサイトが得られました。これは、ウェアハウスのベンダーにはあなたのために構築する動機がほとんどない種類のインサイトです。
数字で見るEnterprise Data MCPの成果
現在、Enterprise Data by Workato MCPは、Workatoで最も利用されている社内MCPです。以前は、シンプルなデータの質問に答えるのに5分から10日かかり、セルフサービスで利用できるユーザーは20%に満たない状況でした。現在では、ユーザーからの質問の90%に、質問した場所のツール上で、数秒で答えが返されます。
最新バージョンの状況は次のとおりです。
- 138テーブルにアクセス可能
- 214の指標を追跡
- 121のリレーションシップを管理
- 1,032件の検証済みクエリに回答可能(当初の149件から7倍に増加)
- 社内900名以上のユーザーにサービスを提供
- 2026年6月以降、40,000件以上のクエリを実行
- 週次の失敗率は約6〜7%で、リリース当初の約30%から低下
このMCPは、「Acmeの今月のタスク使用量はどれくらいか」といったシンプルな事実に関する質問に答えることができ、これはアカウントマネージャーにとって関心の高い内容です。また、「今月、使用量が大幅に減少していて、かつ未解決のサポートチケットがあるアカウントはどれか(解約の兆候になり得るもの)」といった複雑な分析的な質問にも答えます。こちらはカスタマーサクセスのリーダーにとって関心が高く、ビジネス戦略にも影響を与える内容です。
Customer 360を実現するため、WorkatoはEnterprise Data MCPを、Snowflake、Salesforce、Gong、Gmail、SlackのMCPと接続しました。これにより、ユーザーはSnowflakeからアカウントのARRと消費データ、Salesforceから進行中の商談、Gongから直近の通話サマリー、Gmailから経営層との最新のやり取りに、すばやくアクセスできます。このような全体像はこれまで得られず、アカウントチームの働き方を変えました。
多くの企業では、データへのアクセスにいまだ専門的な「翻訳レイヤー」が必要です。ビジネスユーザーは質問をアナリストへの依頼に翻訳し、アナリストはそれをクエリに翻訳して、ビジネスユーザーが当然のものとして期待しているダッシュボードやレポートを構築します。このプロセスには時間がかかります。
私たちは、Data MCPがこの翻訳レイヤーを取り除くことを確認しました。頭の中にある問いが、そのまま投げかける問いになり、答えがすぐに返ってきます。
こうした手軽さのおかげで、探求する価値のある問いの数も大幅に広がります。インサイトがオンデマンドで手に入るようになることで、好奇心は罰せられるのではなく、報われるようになります。
最も大きな価値として見えてきたのは、このEnterprise Data MCPを、Gmail、Slack、GongといったほかのMCPと接続できることでした。これにより、これまで不可能だった真のCustomer 360分析を実現できています。これは私たちのビジネスの進め方を根本から変えました。
詳細については、WorkatoとDispatchによるこちらのウェビナーをご覧ください。
