dbt MCP — ユースケース, インストール & ライブデモ

なぜ使うのか

主な機能

ファーストパーティ — dbt Labs公式MCP
dbt Core（ローカル）とdbt Cloud/Platform（ホスティング）の両方に対応
Semantic Layer統合: list_metrics、query_metrics、get_dimensions
リネージ、モデルの健全性、パフォーマンスをすぐに利用可能

ライブデモ

実際の動作

dbt.replay ▶ 準備完了

0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "dbt": {
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "dbt",
      "command": "uvx",
      "args": [
        "dbt-mcp"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json

{
  "context_servers": {
    "dbt": {
      "command": {
        "path": "uvx",
        "args": [
          "dbt-mcp"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add dbt -- uvx dbt-mcp

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： dbt

dbtモデルが失敗している原因を診断し、修正案を提示する

👤 アナリティクスエンジニア ⏱ ~15 min intermediate

使うタイミング： スケジュールされたdbt実行が失敗した場合。5つのUIを開かずに、何が壊れたのか、その原因を知りたいとき。

前提条件

dbt Cloudアカウント + サービストークン — dbt Cloud → Profile → API Tokens
ローカルのdbtプロジェクトのチェックアウト（CLIツール使用時） — dbtリポジトリをgit cloneする

フロー

失敗した実行を特定する

dbt Cloudの直近10件のジョブ実行を一覧表示してください。失敗したものとそのエラー概要を表示してください。✓ コピーしました

→ 失敗した実行のIDとタイムスタンプ
失敗したモデルを深掘りする

失敗した実行で、最初に失敗したモデルはどれですか？その詳細（SQL、説明）と上流リネージを取得してください。✓ コピーしました

→ 失敗したモデルと依存関係チェーン
修正案を提示する

dbt compileでモデルをローカルで実行してください。コンパイルされたSQLでエラーを確認し、最小限の修正案を提示してください。✓ コピーしました

→ 根拠付きの具体的なSQL修正案

結果： 15分以内に壊れたモデルの検証済み修正案を得られます。

注意点

Cloud実行の失敗は環境要因（接続/認証情報）であり、コードの問題ではない場合がある — SQLを編集する前に、runツールで同じモデルがローカルで実行できるか確認する。実行できれば、コードではなくインフラの問題

組み合わせ： sentry · linear

dbt Semantic Layerを使ってビジネスの質問に回答する

👤 セルフサービス分析を推進するアナリティクスエンジニア ⏱ ~10 min beginner

使うタイミング： ステークホルダーから「先月のプラン別MRRはいくら？」と聞かれた場合。dbt SLにメトリクスが定義されているとき。

前提条件

dbt PlatformプロジェクトでSemantic Layerが有効化されていること — dbt Cloud → Account Settings → Semantic Layer

フロー

メトリクスを探す

SLで利用可能なメトリクスを一覧表示してください。MRRまたはmonthly_revenueを探しています。✓ コピーしました

→ 該当するメトリクスが見つかる
ディメンションを確認する

MRRメトリクスはどのディメンションでクエリ可能ですか？プランと月でフィルタ/グループ化したいです。✓ コピーしました

→ 有効なディメンションの一覧
クエリして解釈する

先月のMRRをプラン別にグループ化してクエリしてください。結果をテーブル形式にし、主要な貢献者についてコメントしてください。✓ コピーしました

→ テーブル + 簡単な分析

結果： ステークホルダーが2分で信頼性の高いガバナンスされた回答を得られます。アドホックなSQLを書く必要はありません。

注意点

サポートされていないディメンションでクエリすると、明確なエラーなしに空の結果が返される — 必ず先にメトリクスに対してget_dimensionsを呼び出す。推測で進めないこと

組み合わせ： notion

コアモデルを編集する前に影響範囲を確認する

👤 基盤モデルを変更しようとしているアナリティクスエンジニア ⏱ ~20 min intermediate

使うタイミング： dim_customersを変更しようとしている場合。まず、すべての下流コンシューマーを把握する必要があるとき。

フロー

リネージを取得する

dim_customersの下流リネージを取得してください。モデル、エクスポージャー、メトリクスを含めてください。✓ コピーしました

→ 完全な下流グラフ
影響を定量化する

各下流モデルについて、model_performanceとmodel_healthを取得してください。クリティカルなもの（エクスポージャーで使用、毎日実行）はどれですか？✓ コピーしました

→ 変更を誤った場合に壊れるものの優先順位リスト
変更計画を策定する

変更計画を作成してください：追加すべきテスト、通知すべき下流オーナー（エクスポージャーを確認）、デプロイ後に監視すべき項目。✓ コピーしました

→ ロールアウト計画

結果： 共有モデルの変更を、影響範囲の想定外の拡大なく、認識を持って実施できます。

注意点

エクスポージャーはメンテナンスしている場合のみ存在する — BIツール内のサイレントな下流依存は追跡されない — BIツールのAPI（Looker、Tableau）と組み合わせて実際のコンシューマーを特定する。dbtは登録されたものしか把握できない

生ソースからステージングモデルをスキャフォールドする

👤 新しいソースをオンボーディングするアナリティクスエンジニア ⏱ ~30 min intermediate

使うタイミング： 新しいFivetran/ソースデータが到着した場合。各テーブルにstg_*モデル + ymlが必要なとき。

前提条件

新しいデータのsources.ymlエントリ — 先にソースを定義する。エージェントがそこからステージングを生成する

フロー

ソースブロックを生成する

generate_sourceを使って、データベース'raw'、スキーマ'stripe'のソースを生成してください。出力をmodels/staging/stripe/_sources.ymlに書き込んでください。✓ コピーしました

→ 全テーブルが記載されたソースyml
ステージングモデルをスキャフォールドする

各ソーステーブルに対して、generate_staging_modelを呼び出してください。それぞれmodels/staging/stripe/stg_stripe__<table>.sqlに書き込んでください。✓ コピーしました

→ ソーステーブルごとに1つの.sqlファイル
ドキュメントとテストを追加する

各新規ステージングモデルに対して、generate_model_yamlを呼び出してください。主キーにnot_nullテストを追加してコミットしてください。✓ コピーしました

→ クリーンでテスト済みのステージングレイヤー

結果： 数分で完全なステージングレイヤーが完成します。コピー＆ペーストによるズレが発生しません。

注意点

生成されたモデルがSELECT *を使用し、PII列まで取り込んでしまう — 生成後、マージ前に明示的に列を列挙し、機密性のある列を除外またはハッシュ化する

組み合わせ： git

組み合わせ

他のMCPと組み合わせて10倍の力を

dbt + sentry

dbtモデルの失敗が下流の機能に影響を与えた場合、Sentryのエラースパイクと関連付ける

過去24時間で失敗したdbt実行を検索してください。それぞれについて、該当モデルのテーブルに依存するサービスでSentryのエラースパイクが発生していないか確認してください。✓ コピーしました

dbt + linear

繰り返し発生するdbtテスト失敗に対してLinearバグを作成する

過去1週間で3回以上失敗したdbtテストを一覧表示してください。それぞれについて、テストの詳細を含めてAnalyticsチームにLinearバグを作成してください。✓ コピーしました

dbt + notion

メトリクスをNotionグロッサリーに自動ドキュメント化する

Semantic Layer内のすべてのメトリクスについて、Metrics GlossaryデータベースにNotionページを作成または更新してください。名前、説明、オーナーを含めてください。✓ コピーしました

ツール

このMCPが提供する機能

ツール	入力	呼び出すタイミング	コスト
list_metrics / get_dimensions / get_entities / query_metrics	metric name, dimensions, filters	ビジネスメトリクスに関する質問	SL queries billable per dbt Cloud plan
execute_sql / text_to_sql	sql or natural language	dbtコンテキストを使ったアドホックSQL探索	Warehouse credits
get_all_models / get_model_details / get_lineage	model identifiers	ディスカバリーと影響分析	free
get_model_health / get_model_performance	model id	データプラットフォームのSREスタイルのチェック	free
build / run / test / compile / parse / show / docs / list	dbt CLI args	ローカルでのdbt Core使用	warehouse compute for run/test/build
list_jobs / trigger_job_run / get_job_details / cancel_job_run / retry_job_run / list_job_runs	job/run IDs	dbt Cloudの運用操作	1 Admin API call
generate_source / generate_staging_model / generate_model_yaml	source/model refs	新しいモデルのスキャフォールディング	free
get_exposures / get_exposure_details	exposure name	エクスポージャーとして登録された下流コンシューマーの検索	free

コストと制限

運用コスト

APIクォータ: dbt Cloud Admin API: プランにより異なります。Semantic Layer: プランごとの制限があります。
呼び出しあたりのトークン: リネージグラフやモデル一覧は大きくなる可能性があります — ページネーションを使用してください
金額: MCPは無料、dbt Coreは無料、dbt Cloud/Platformは有料です。ウェアハウスクエリはご利用のウェアハウスで課金されます。
ヒント: ディスカバリーツール（get_model_details、get_lineage）は自由に使用できます — メタデータのみです。execute_sql / query_metricsはウェアハウスに対して実行されるため注意してください。

セキュリティ

権限、シークレット、影響範囲

認証情報の保管： dbt Cloudサービストークンは環境変数に格納。Coreはprofiles.ymlを使用します

データ送信先： Cloudツールはdbt Cloud（cloud.getdbt.com）へ、SQLツールはご利用のウェアハウスへ接続します

トラブルシューティング

よくあるエラーと対処法

Admin API呼び出しで401エラー

サービストークンが期限切れか、必要なアカウントが不足しています。dbt Cloud → Account Settings → Service Tokensで再生成してください。

Semantic Layerツールが'not configured'を返す

SLは有料機能であり、プロジェクトごとに有効化する必要があります。dbt Cloud → Project Settings → Semantic Layerを確認してください。

CLIツール（run/build）が'No profile'で失敗する

DBT_PROFILES_DIRをprofiles.ymlを含むディレクトリに設定するか、ローカルのprofiles.ymlがあるプロジェクトルートから実行してください。

確認： dbt debug

get_lineageが空を返す

マニフェストが古くなっています。まずparseを実行してmanifest.jsonを再生成してください。

代替案

dbt 他との比較

代替案	代わりに使う場面	トレードオフ
SQLMesh MCP	dbtの代わりにSQLMeshを使用している場合	変換パラダイムが異なるため、単純な置き換えにはならない
Direct warehouse MCPs (Snowflake, BigQuery)	dbtメタデータではなく、生のSQLのみが必要な場合	モデル/リネージ/テストの認識が失われる

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る