🧱 AIにSQLを書かせる前に整える信頼できるデータ基盤: Fivetran+dbt と dbt MCP

検証日: 2026-06-02 / 対象: dbt MCP server・Semantic Layer (MetricFlow)・Agents Schema を含む Fivetran+dbt 統合基盤
起点: dbt Labs Blog「What we announced at Snowflake Summit and why it matters」

2026 年 6 月、Fivetran と dbt Labs の合併が完了しました。新会社が掲げたメッセージは「Data Infrastructure for Trusted AI Agents (信頼できる AI エージェントのためのデータ基盤)」です。本記事では、この「信頼できるデータ基盤」を構成する要素が AI エージェントに対して何の失敗を防ぐのかを構造的に整理し、dbt MCP server と Semantic Layer がエージェントとデータをどう接続するかを技術的に追い、最後にロックインや採用コストといった反証を踏まえて採用判断の条件を示します。

概要

2026 年 6 月 1 日、Fivetran と dbt Labs の合併が完了しました。統合後の正式プレスタイトルは "Create the Data Infrastructure for Trusted AI Agents" であり、新会社の競争軸を「信頼できる AI エージェントのためのデータ基盤」に定めました。

この統合の核心は、競争軸が「より賢いモデル」から「エージェントが信頼して行動できるデータ」に移ったという主張にあります。Tristan Handy (President) の言葉がその思想を端的に示します。

"The companies that deploy AI successfully over the next decade will be the ones whose agents can be trusted to act. Trust is built at the infrastructure layer, on high-quality tooling and on open standards." — Tristan Handy

AI エージェントは自律的に行動します。誤った・古い・未検証のデータの上で動くと、意思決定が静かに破綻します。そこで Fivetran+dbt は、AI にクエリを書かせる前に、データ側で lineage (来歴) / data contract (契約) / test (品質テスト) / semantic layer (指標定義) / incremental (差分実行) を整えるべきだと主張します。

合併の基本事実

役割分担

アナリストの要約が統合の本質を一言で示します (二次: TechTarget)。

"Fivetran moves the data and dbt makes it trustworthy."

• Fivetran (ELT): 多数のデータソースから継続的・完全にデータを取り込む。エージェントが完全で同期済みの信頼できるデータの上で動くことを保証する。
• dbt (transformation + governance): 取り込まれたデータを検証し、意味を付与し、信頼できるものにする。tested business logic・共有セマンティック・ガバナンスを提供する。

従来、取り込みと変換は別ツール・別 lineage で分断されていました。統合により、ソース取込から変換・テスト・セマンティック定義・メトリクスまでが 1 つの lineage / コンテキスト層として束ねられます。

AI-ready データ基盤の定義と業界収斂

「AI-ready データ基盤」という言葉は Fivetran+dbt だけでなく、Databricks・Snowflake も同時期に打ち出しています。構成要素は 3 陣営とも概ね「governed + modeled/tested + lineage + semantic context」に収斂しています。Fivetran+dbt の差別化は、これを特定プラットフォームに依存しないオープン標準として提供しようとする点にあります。

特徴

失敗の形を「もっともらしい誤答」から「エラーメッセージ」に変える

生の text-to-SQL (LLM にスキーマを渡して直接 SQL を書かせる方式) の最大の問題は、実行は成功するが間違った数値を返す点です。dbt Semantic Layer (MetricFlow) が SQL 生成を決定的 (deterministic) に担うことで、LLM の仕事を「正しい metric / dimension を選ぶこと」だけに縮小します。不正な join や集計は構造的に起こせなくなります。

"With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message." — dbt Labs

dbt Labs の自社ベンチ (ACME Insurance データセット、11 問 × 20 回 × 複数 LLM という限定条件) では、Semantic Layer scope 内で gpt-5.3-codex が Text-to-SQL 84.1% から Semantic Layer 100.0% へ、claude-sonnet-4-6 が 90.0% から 98.2% へ達したと報告されています (一次: dbt docs blog semantic-layer-vs-text-to-sql-2026、モデル名は 2026 年時点の同ブログ表記)。自社ベンチである点と SL scope 内という条件には留意が必要で、トレードオフはカバレッジであり、モデル化済みの範囲しか答えられません。

5 要素は役割が階層的に分かれている

contract は構造しか見ず logic を見ない限界があり、test と補完関係にあります。incremental は他 4 要素のように誤りを直接防ぐのではなく、freshness とコスト効率を支える土台です。

dbt MCP server を「governed control layer」と位置づける

dbt MCP server (dbt-labs/dbt-mcp、Apache-2.0) の公式定義は次の通りです。

"these dbt MCP server tools make dbt not just the structured context layer, but also the governed control layer between your data workflows and your AI, the bridge between the governed warehouse and your LLMs, agents, and AI-powered tools." — dbt Labs 公式ブログ

単なる接続口ではなく、アクセス権限とコンテキストを統制するレイヤーとして位置づけます。Local (uvx) と Remote (HTTP) の 2 形態があり、Remote は consumption-only (dbt CLI 不可) です。

Agents Schema で一気通貫のコンテキストをエージェントに渡す

Agents Schema は、データウェアハウス/レイク内の単一スキーマに、メトリクス定義・セマンティックモデル・dbt lineage・ビジネスドキュメントをプレーンな SQL テーブルとして格納する OSS 標準です。

"one schema in a data warehouse or data lake that is compatible across systems as the shared context layer for agentic AI." — citybiz (合併完了発表ミラー, 2026-06-01)

エージェントは「どのソースから来た、どう検証された、どのメトリクス定義の数字か」を辿れます。「customer-owned context layer」と表現することで、ベンダー側でなく顧客のガバナンスポリシー内で動く点を強調します。

ELT + transformation の統合による lineage の一気通貫

取り込みと変換が 1 ベンダーになることで、ソース取込から変換・テスト・セマンティック定義・メトリクスまでの lineage が途切れません。公式の整理 (一次: Fivetran 公式まとめ) は次の通りです。

"combining reliable data movement, governed transformation, and consistent business logic into a unified, context-rich foundation."

dbt Wizard は「汎用コーディングエージェントではない」

dbt Wizard (および dbt Copilot) は、分析エンジニアリングの文脈を知る専用エージェントとして位置づけられます (一次: docs.getdbt.com)。

"Analytics engineering requires more than code generation — it requires understanding your data, how it connects, and what breaks when something changes." — dbt docs

汎用 AI コーディングアシスタントは構文は分かるが頑健なデータパイプラインに必要な深い文脈を欠きます。dbt の AI 群は lineage / tests / contracts / metric 定義に grounded である点を差別化とします。

オープン標準を差別化軸とする

• dbt Core v2.0: Apache 2.0 ライセンスで OSS 化 (Fusion runtime 部分)。ただし alpha 段階。
• Agents Schema: OSS 標準として公開。
• dbt MCP server: Apache-2.0 ライセンス (dbt-labs/dbt-mcp で確認)。

ただし注意点が 2 つあります。dbt Fusion (proprietary distribution) は Elastic License (source-available) であり OSI 承認の OSS ではありません。MetricFlow のライセンスは、2025-10 の合併公表時に「Apache 2.0 でのフル OSS 化」が言及された一方、公式 licenses-faq では BSL (Business Source License、非本番用途はフリー) 表記が残っており、現時点のライセンス状態は要確認です。

構造

システムコンテキスト図

アクター

外部システム

コンテナ図

Fivetran ELT

dbt Transformation - Test - Contract

Semantic Layer - MetricFlow

dbt MCP server

Agents Schema

Catalog - Lineage

コンポーネント図

dbt MCP server と Semantic Layer のドリルダウンです。

dbt MCP server コンポーネント

Read 系 toolset

Write 系 toolset

制御層

Semantic Layer コンポーネント

SL APIs

実行層

定義層

データ

概念モデル

情報モデル

構築方法

前提条件

共通の前提は次の通りです。

• dbt Cloud アカウント (Starter 以上)
• Semantic Layer / Discovery API 利用は Team / Enterprise プランが必要
• execute_sql / Fusion tools 利用は Personal Access Token (PAT) が別途必要

Local MCP は追加で uv のインストール、ローカルの dbt プロジェクト (dbt_project.yml)、dbt CLI のローカルインストールが必要です。Remote MCP はローカルインストール不要で、dbt platform の AI 機能が有効である必要があります。

Local MCP server のセットアップ

ローカルマシンで uvx dbt-mcp を起動し、MCP プロトコルで AI エージェントと通信する形態です。dbt CLI コマンドを含む全 toolset が利用できます。

uvx dbt-mcp
# 正常起動したら Ctrl+C で停止

Claude Code 設定例 (.mcp.json、dbt platform 併用) は次の通りです。

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": ["dbt-mcp"],
      "env": {
        "DBT_PROJECT_DIR": "/Users/yourname/projects/my_dbt_project",
        "DBT_PATH": "/opt/homebrew/bin/dbt",
        "DBT_HOST": "abc123.us1.dbt.com",
        "DBT_TOKEN": "YOUR_SERVICE_OR_PAT_TOKEN",
        "DBT_PROD_ENV_ID": "123456",
        "DBT_DEV_ENV_ID": "789012",
        "DBT_USER_ID": "42",
        "DBT_ACCOUNT_ID": "9999"
      }
    }
  }
}

claude mcp add コマンドでも設定できます。

claude mcp add dbt \
  -e DBT_PROJECT_DIR=/Users/yourname/projects/my_dbt_project \
  -e DBT_PATH=/opt/homebrew/bin/dbt \
  -- uvx dbt-mcp

Remote MCP server のセットアップ

ローカルインストール不要で dbt platform への HTTP 接続のみで動作します。Semantic Layer / SQL / Discovery / Admin API / Fusion の各 toolset は Remote でも利用でき、Local 専用は dbt CLI コマンドと Codegen tools のみです。エンドポイント URL は Account settings の Access URLs から取得、または https://YOUR_DBT_HOST_URL/api/ai/v1/mcp/ の形式で構築します。

Claude Code 設定例 (Token 認証) は次の通りです。

{
  "mcpServers": {
    "dbt": {
      "type": "http",
      "url": "https://YOUR_DBT_HOST_URL/api/ai/v1/mcp/",
      "headers": {
        "Authorization": "Token YOUR_DBT_ACCESS_TOKEN",
        "x-dbt-prod-environment-id": "123456",
        "x-dbt-user-id": "42",
        "x-dbt-dev-environment-id": "789012"
      }
    }
  }
}

OAuth (Enterprise / Enterprise+、private beta) では url のみ指定し、初回接続でブラウザサインインと同意画面を経ます。多くの MCP クライアントは RFC 7591 dynamic registration に対応します。

必要な環境変数一覧

Local CLI 変数は次の通りです。

dbt Platform 接続変数は次の通りです。

Semantic Layer チューニング変数として、DBT_MCP_SL_METRICS_RELATED_MAX (既定 10) と DBT_MCP_SL_MAX_RESPONSE_CHARS (既定 16000) があります。

利用方法

API / ツール 必須パラメータ早見表

エージェントの指標取得フロー

AI エージェントが MCP ツールを通じて指標を取得する典型シーケンスは 3 ステップです。

1. list_metrics()
   → [{ name: "monthly_revenue" }, { name: "order_count" }, ...]

2. get_dimensions(metrics=[{ name: "monthly_revenue" }])
   → [{ name: "metric_time" }, { name: "region" }, ...]

3. query_metrics(
     metrics=[{ name: "monthly_revenue" }],
     group_by=[{ name: "region" }, { name: "metric_time", grain: MONTH }],
     where=[{ sql: "{{ Dimension('customer__customer_segment') }} = 'enterprise'" }],
     limit=12
   )
   → { jsonResult: [...], sql: "SELECT ...", status: "SUCCESSFUL" }

内部では Semantic Layer API の createQuery から query(queryId) のポーリングが行われ、MetricFlow が join を含む SQL を生成し、Gateway service がウェアハウスで実行します。実行せず生成 SQL のみを確認したい場合は get_metrics_compiled_sql を使い、監査・レビュー用途に適します。

Semantic Layer GraphQL API

MCP ツールを介さず外部システムから直接呼び出す場合のインタフェースです。エンドポイントはリージョン別 (例: NA は https://semantic-layer.cloud.getdbt.com/api/graphql)、認証は Authorization: Bearer <SERVICE_TOKEN_OR_PAT>、各リクエストに environmentId が必須です。

クエリ生成 mutation は次の通りです。

mutation CreateRevenueQuery {
  createQuery(
    environmentId: 123456
    metrics: [{ name: "monthly_revenue" }]
    groupBy: [{ name: "metric_time", grain: MONTH }, { name: "region" }]
    where: [{ sql: "{{ Dimension('customer__customer_segment') }} = 'enterprise'" }]
    order: [{ groupBy: { name: "metric_time", grain: MONTH }, descending: true }]
    limit: 12
  ) {
    queryId
  }
}

結果取得は非同期ポーリングです。

query PollResult {
  query(environmentId: 123456, queryId: "QueryID_abc123") {
    sql
    status
    error
    jsonResult(orient: TABLE, encoded: true)
    arrowResult
  }
}

status が SUCCESSFUL または FAILED になるまでポーリングします。WhereInput.sql では Jinja テンプレート ({{ Dimension(...) }} / {{ TimeDimension(...) }} / {{ Metric(...) }}) を使用します。

semantic model / metric の YAML 定義例

MetricFlow による semantic model と metric の定義例です。ratio metric の numerator / denominator は metric 名を参照します。

semantic_models:
  - name: orders
    model: ref('orders')
    defaults:
      agg_time_dimension: ordered_at
    entities:
      - name: order
        type: primary
        expr: order_id
      - name: customer
        type: foreign
        expr: customer_id
    dimensions:
      - name: ordered_at
        type: time
        type_params:
          time_granularity: day
      - name: order_status
        type: categorical
    measures:
      - name: order_total
        agg: sum
        expr: order_amount
      - name: order_count
        agg: count
        expr: order_id

metrics:
  - name: total_revenue
    type: simple
    type_params:
      measure: order_total

  - name: total_orders
    type: simple
    type_params:
      measure: order_count

  - name: revenue_per_order
    type: ratio
    type_params:
      numerator: total_revenue
      denominator: total_orders

read-only 化の設定

dbt MCP に明示的な read-only フラグは存在しません。DISABLE_x (true で無効化) と DBT_MCP_ENABLE_x (allowlist) の組み合わせで権限を絞ります。DISABLE_SQL / DISABLE_DBT_CODEGEN / DISABLE_MCP_SERVER_METADATA は既定で true (無効) です。

Semantic Layer と Discovery のみを許可し書き込み系を閉じる構成例は次の通りです。

{
  "env": {
    "DBT_HOST": "cloud.getdbt.com",
    "DBT_TOKEN": "YOUR_SERVICE_TOKEN",
    "DBT_PROD_ENV_ID": "123456",
    "DISABLE_DBT_CLI": "true",
    "DISABLE_ADMIN_API": "true",
    "DISABLE_SQL": "true",
    "DISABLE_DBT_CODEGEN": "true"
  }
}

優先順位は高い順に DBT_MCP_ENABLE_TOOLS から DISABLE_TOOLS、toolset enable、toolset disable、default です。空の DBT_MCP_ENABLE_x= は他全 toolset を黙って無効化するため注意します。

運用

dbt MCP クレジット消費と遮断

text_to_sql のみが dbt Wizard クレジットを消費します。Semantic Layer クエリ・Discovery ツール・Admin API ツールはクレジットを消費しません (一次: docs.getdbt.com/docs/dbt-ai/about-mcp)。クレジット枯渇時は Remote MCP 経由の全ツールが遮断され、ローカル MCP から Remote にプロキシされるツール (SQL 実行・Remote Fusion) も停止します。ad hoc 分析ループで text_to_sql を繰り返すとクレジットが急減するため、Semantic Layer 経由 (query_metrics) に切り替えることで消費をゼロにできます。

Semantic Layer クエリのレイテンシ

クエリパスは「MCP クライアントから dbt MCP server、SL GraphQL API、Service layer、MetricFlow、Gateway、ウェアハウス」と多段になります。warehouse 直 SQL に比べホップ数が増える分、レイテンシのオーバーヘッドは避けられません。GraphQL は createQuery から query(queryId) の非同期ポーリング構造のため、短時間クエリでもポーリング往復が加わります。高頻度・低レイテンシ要件がある場合は metric を事前 materialize した dbt モデルを参照する設計も選択肢です (鮮度とコストのトレードオフあり)。DBT_MCP_SL_MAX_RESPONSE_CHARS / DBT_MCP_SL_METRICS_RELATED_MAX で応答サイズを絞れます。

freshness と incremental によるデータ現行性の維持

dbt MCP は freshness 情報を公開しており、get_model_health で run status・テスト結果・上流 source freshness を一括取得できます。incremental モデルは全行を毎回 rebuild せず新規・変更行だけを処理し、大規模テーブルでも低コスト・高頻度に最新化を維持します。「古いデータで誤答する」問題の緩和に寄与します。ただし incremental はエージェントの誤りを直接防ぐというより基盤の運用効率 (鮮度とコスト) を支える位置づけで、lineage・contract・test・semantic layer とは役割が異なります。

ベストプラクティス

エージェント権限は read-only から始める

1. DISABLE_DBT_CLI=true でモデルの build/run/test を封じる。
2. Admin API のジョブ操作が不要なら DISABLE_ADMIN_API=true。
3. SQL 書き込みリスクが不安なら DISABLE_SQL=true (既定値は true)。
4. DBT_MCP_ENABLE_x allowlist 方式で明示したツールセット以外を全遮断する。
5. service token に最小権限スコープ (Semantic Layer 読み取り・Discovery 読み取りのみ) を付与する。
6. Remote MCP (consumption-only) はローカル CLI ツールが存在せず、書き込み誤実行リスクが低い。

エージェントは人が止める異常を止めない (Fivetran 一次) ことを前提に、書き込み権限は人間の承認フローを経てから付与します。

正確性が要る指標は Semantic Layer 経由、探索は text-to-SQL

board data・監査・OKR・KPI・週次レポート等、数値の正確性と再現性が必須の場面は Semantic Layer 経由を使います。MetricFlow が deterministic に SQL を生成します。未モデル化データの探索・仮説検証の初回クエリ・スキーマ把握は text-to-SQL (ad hoc 探索) を使い、もっともらしいが誤った答えが返る可能性を念頭に置きます。推奨ワークフローとして、ad hoc で答えが重要と判明したら最小の dbt モデルを作成し Semantic Layer に組み込みます。dbt 公式実験では 3 モデル追加でカバレッジが 72.7% から 100% に拡大しました。

AI の前に metric と test を最優先で整える

優先順位の目安は次の通りです。

1. 主要ビジネス指標の metric 定義 (Semantic Layer)
2. primary key の unique と not_null test、参照整合性 (relationships) test
3. data contract (スキーマの breaking change 検出)
4. freshness SLA の設定と監視
5. その後に AI エージェントを接続

dbt ADE-bench の最難問は、コードが正しくてもデータを実際にクエリしないと解けない問題でした (join を壊す bad value・不可能な数値・誤った WHERE 条件等)。これらは test が整っていなければエージェントがそのまま使ってしまいます。

ロックインを採用判断に織り込む

ライセンス区分の確認が必要です。dbt Fusion (Platform 側の proprietary distribution) は ELv2 (無料だが OSI 非承認)、MetricFlow は公式 licenses-faq の BSL 表記と最新発表の Apache-2.0 化で情報が分かれており要確認、dbt Core は Apache-2.0 据え置きですが「将来ビジョンは Core でなく Fusion」と公言され開発投資の重点移行リスクがあります (二次情報: tobikodata.com, driftwave.io, getdbt.com/licenses-faq)。価格面では、競合ベンダー Nexla は Fivetran が 2025 年に一部顧客で価格を 4〜8 倍に引き上げたと主張する一方、Fivetran 公式は大多数のユーザーで値下げになると説明しており、評価は分かれます (二次情報: nexla.com, techtarget.com, fivetran.com)。ingestion と transformation を 1 ベンダーで統合すると切り替えコストが増大するため、Databricks Metric Views や Snowflake Semantic Views など warehouse-native の代替が自社スタックに合うかを先行評価します。

Semantic Layer 採用コストを踏まえた段階導入

dbt native チームでも Semantic Layer の採用率は 18% との分析があります (算出母集団・基準は要確認の未検証試算、二次情報: typedef.ai)。コスト試算の一例 (100 人チーム) は SaaS $50K/年 + エンジニア $15K/年 = $65K/年です (同上、算出方法は要確認)。段階導入の推奨は次の通りです。

1. unique と not_null test + primary key contract を全主要モデルに整備する (低コスト・高効果)。
2. 問い合わせ頻度が高い 3〜5 指標を MetricFlow で定義する。
3. AI 精度・運用コストを検証してから範囲を拡大する。
4. SL 外の ad hoc は text-to-SQL で補い、有用な答えを順次モデル化する。

トラブルシューティング

まとめ

Fivetran+dbt が掲げる「信頼できる AI エージェント向けデータ基盤」の本質は、AI にクエリを書かせる前に lineage / contract / test / semantic layer / metric を整え、dbt MCP server を governed control layer としてエージェントに read-only から接続することにあります。一方でライセンスのロックインや Semantic Layer の採用コストは無視できず、「特定ベンダー束を常に先に整えるべき」という普遍命題は規模と文脈に依存する条件付きの主張として捉えるのが妥当です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント (dbt / Fivetran / Snowflake / Databricks)
  • dbt docs: About dbt MCP server
  • dbt docs: Available MCP tools
  • dbt docs: MCP environment variables
  • dbt docs: Remote MCP quickstart
  • dbt docs: Semantic Layer overview
  • dbt docs: Semantic Layer architecture
  • dbt docs: Semantic Layer GraphQL API
  • dbt docs: MetricFlow metrics overview
  • dbt docs: Model contracts
  • dbt docs: Column-level lineage
  • dbt docs: About dbt AI and intelligence
  • dbt docs: About dbt Copilot (Wizard)
  • dbt blog: Semantic Layer vs text-to-SQL (2026)
  • dbt blog: Building a better data agent benchmark
  • Fivetran: Agentic AI Readiness Index 2026
  • Fivetran + dbt Labs merger
  • Snowflake: dbt Fusion Is Now Available on Snowflake
  • Databricks: Governing AI agents at scale with Unity Catalog
• GitHub
  • dbt-labs/dbt-mcp
  • dbt-core#14395: Model Contracts EPIC (open)
  • dbt-core#11997: Semantic Layer YAML EPIC (open)
• 解説・批判・プレス
  • Business Wire: Fivetran + dbt Labs Complete Merger (2026-06-01)
  • TechTarget: complete merger to form data layer for AI
  • Techzine: data infrastructure for reliable agentic AI
  • Tobiko: The False Promise of dbt Contracts
  • Tobiko: Is dbt Fusion the death of dbt Core?
  • typedef.ai: Semantic Layer Architectures
  • Datacoves: dbt + Fivetran Merger Risks