MCP で dbt と Databricks をエージェントへ接続する設計

dbt Labs は、Integral Ad Science が MCP を使い、AIエージェントを dbt と Databricks へ接続して BI の「なぜ」を調べる事例を紹介しました。ダッシュボードの数値異常を、モデル、SQL、上流データまで遡る設計が焦点です。

要点

• BI チャットボットが数値を説明できない「BI why」問題を、dbt と Databricks の文脈を渡して解く事例です。
• MCP server により、エージェントが dbt のモデル情報や Databricks の検証クエリへ接続されます。
• AIエージェントをBIに入れるには、意味層、変換ロジック、権限、検証クエリを安全に接続する必要があります。

今回のブログ記事で語られていること

この記事は、BI ダッシュボード上の数値に違和感があるとき、AIエージェントがどこまで理由を追えるかを扱っています。記事では、BI チャットボットはグラフの値やフィルタを説明できても、その数字がなぜそうなったのか、どの変換ロジックや上流モデルが関係しているのかまでは理解しにくいと説明されています。Integral Ad Science の例では、分析者が Looker、dbt モデル、SQL、Databricks の検証クエリをたどって原因を探すような作業を、AIエージェントに文脈として渡す設計が紹介されています。

中心になるのが MCP です。MCP server を使うことで、エージェントは dbt のモデル、変換ロジック、依存関係、Databricks 上のデータや検証クエリへ接続できます。これにより、単にチャートの値を要約するだけではなく、なぜその数字になったのか、どの upstream marts や分類ロジックが関係しているのかを調べる方向へ進めます。BI の自然言語インターフェースを本当に役立てるには、可視化ツールだけではなく、意味層、変換層、実データの検証までつなげる必要があります。

実務での読みどころは、AIエージェントの「データアクセス」を広げるほど、統制が重要になる点です。dbt と Databricks に接続できるエージェントは強力ですが、誤ったモデルを参照したり、権限外のデータを見たり、検証不足の結論を返したりするリスクもあります。導入側は、どのメタデータを渡すか、どのクエリを実行できるか、結果の根拠をどう表示するか、人がどこでレビューするかを設計する必要があります。この記事は、MCP をBI運用の文脈に接続する実例として価値があります。

今回のブログ記事が関係する人

dbt と Databricks を使う分析基盤チーム、BI チャットボットやデータエージェントを作るチーム、意味層と変換ロジックをAIへ接続したいデータプロダクト担当に関係します。

実務で確認したいポイント

• エージェントに渡す dbt メタデータ、リネージ、SQL、Databricks 権限を限定する。
• 回答に使ったモデル、クエリ、データ範囲、検証結果をユーザーが確認できるようにする。
• BI の数値異常を、可視化、意味層、変換、実データのどこで切り分けるか手順化する。

結局、今回のブログ記事をどう読むべきか

MCP は、BIエージェントを単なるチャットUIからデータ基盤の調査役へ近づけます。導入時は、接続範囲と根拠表示を設計しないと、便利だが危うい分析支援になります。