dbt MCPサーバー：ツール、セットアップ、そしてエージェントに安全にメタデータを提供する方法

dbt MCPサーバーとは

dbt MCPサーバーは dbt MCPサーバー 、dbt Cloudの一部としてdbt Labsが運用するリモートMCPサーバーです。 Model Context Protocol（MCP） は、エージェントが外部システムのツールを検出し呼び出せるようにするためのオープン標準です。dbtの実装では、dbt Cloudプロジェクトを呼び出し可能なツールとして公開します。TrueFoundryのドキュメントによると、セマンティックレイヤーを通じたメトリクスのクエリ、モデルメタデータの調査、SQLの実行が可能です。

ほとんどのデータMCPサーバーは、エージェントに データ を提供します（Snowflakeなら行データ、Postgresなら行データなど）。一方、dbt MCPサーバーが提供するのは マップです。つまり、どのモデルが存在し、何から構築され、各カラムが何を意味し、どのテストで保護され、組織がどのようにメトリクスを定義しているかといった情報です。

正直な注意点として、ドキュメントには機能リストではなく機能領域が記載されており、ツールとしてはexecute_sqlのみが挙げられています。上記以外の機能については、 ツール タブで確認してください。[検証] ドキュメントページにはジョブのトリガーや実行オーケストレーションに関するツールは記載されていないため、本稿でもそれらについては言及していません。

なぜメタデータが重要なのか

分析チームなら誰もが経験する失敗例があります。誰かがエージェントに「前四半期の純収益維持率（NRR）は？」と尋ねたとします。エージェントはデータウェアハウスの認証情報を持っており、fct_subscriptionsやdim_customers、そしてmrr_amtやmrr_amount_usdといった名前の40個のカラムを目にします。そこでエージェントはクエリを作成し、数値が返ってきます。しかし、その数値は間違っており、それを指摘する術もありません。

エージェントはSQLで失敗したのではなく、 定義どの列が何を意味するのか、チャーンをどう扱うべきか、ダウングレードを含めるべきかどうかを推測し、4つの推測に基づいて自信満々に回答を出力していました。dbt MCPサーバーは、こうした推測を2つの方法で排除します。

リネージと列のコンテキストです。 エージェントは、fct_subscriptionsが何から構築されているのか、各列の意味は何か、どのテストがパスしているのかを問い合わせることができます。これは、人間のアナリストは知っていても、生のデータウェアハウス接続からは得られないコンテキストです。

名前付きメトリクス。 純収益維持率（NRR）がセマンティックレイヤーで定義されていれば、エージェントがそれを構成する必要はありません。エージェントは粒度とディメンションを指定してメトリクスを名前で呼び出し、dbtがSQLをコンパイルします。定義はバージョン管理下にあり、所有者によってレビューされます。これが、 セマンティックレイヤーMCP が独自の検索キーワードである理由です。クエリを記述するだけのエージェントと、合意済みの回答を読み取るエージェントを区別するからです。

これこそが、データウェアハウスの前にdbtを接続すべき理由です。セマンティックレイヤーのないText-to-SQLエージェントは、クエリ権限を持ったハルシネーション（幻覚）生成マシンに過ぎません。dbtを介することで、エージェントは辞書を手に入れることになります。

エージェントが実際にそれを使って行うこと

実用的なワークフローでは、単一のツールを呼び出すのではなく、ツールを連鎖させます。

• ビジネス上の問いに正しく回答する。 メトリクスを一覧表示し、問いに一致するものを見つけ、適切な粒度で名前を指定してクエリを実行し、数値とその定義を返します。
• 変更前の影響分析。 エンジニアがステージングモデルを変更する前に、エージェントがリネージを辿って下流への影響をリストアップし、何が壊れるかを特定します。
• 変動した数値を説明する。 メトリクスの定義を取得し、ソースモデルまで遡り、テストの失敗が原因かどうかを確認します。
• 新メンバーのオンボーディング。 古くなりがちなWikiに頼ることなく、特定のドメインにどのようなモデルが存在し、それらがどう関連しているかを問い合わせます。

これら4つのうち3つはメタデータのみを必要とするため、この統合は安全に実装しやすくなっています。

真のリスクが潜む場所

ここではウェアハウスサーバーの場合よりも範囲を絞ります。リスクを過大評価することは誠実ではありません。

メタデータの読み取りは低リスクです。 モデル名、列の説明、リネージエッジ、テスト結果は顧客データではありません。情報漏洩やコスト発生の心配はありません。

execute_sqlは、結果が伴う操作です。 ドキュメントには明記されています。エージェントが直接SQLを実行する必要がない限り、無効にしてください。これには開発環境IDとユーザーIDが必須であり、それ自体が重要なシグナルとなります。エージェントが大規模なテーブルに対してループ処理を行うとウェアハウスの利用料金が発生し、トークンの範囲によってはデータ流出の経路にもなり得ます。

セマンティックレイヤーのクエリが2つ目の領域です。 定義が固定されているため生のSQLよりは安全ですが、無料ではありません。メトリッククエリはウェアハウスでの処理を伴うため、エージェントが3年分の日次データに対してあらゆるディメンションでクエリを乱発すれば、高額なスキャンコストが発生します。

トークンのスコープは、これら両方のリスクを増幅させます。 パーソナルアクセストークン（PAT）はユーザーの権限を継承しますが、サービストークンは割り当てられた権限セットを使用します。アカウント管理者のPATをエージェントの設定に貼り付けると、そのエージェントに管理者権限を与えてしまいます。ドキュメントでは、無人環境での標準的な設定として、共有読み取りアクセスにはサービストークンの使用を推奨しています。また、3つのヘッダーとトークンを全アナリストのラップトップにコピーするような運用では、15人規模でも監査は不可能です。

これらはdbtの接続を否定するものではありません。その前に制御プレーンを置くべきだという主張であり、それこそが MCPゲートウェイ の役割です。

Want to try it on your own project?

Register the dbt MCP server on TrueFoundry, leave metadata tools on, and turn execute_sql off in the same sitting.

Get started free

TrueFoundry経由でdbt MCPサーバーを接続する

dbtは ワンクリックで 追加できる「管理対象MCP」カタログには含まれていません。以下の手順で設定します。 「任意のリモートMCPサーバーを接続」ここには、自身で作成したトークンと、自分だけが知るヘッダー情報が必要になるためです。

前提条件：Starter、Team、またはEnterpriseプランのdbt Cloudアカウント、アカウント管理者権限、本番環境、execute_sql用の開発環境、およびdbt AI機能の有効化が必要です。

ステップ 1 — dbt トークンを作成する。 個人でのアクセスや execute_sql が必要な場合はパーソナルアクセストークンを、共有の読み取りアクセスにはサービス用トークンを使用してください。トークンは作成後すぐにコピーしてください。

ステップ 2 — 数値 ID を収集する、dbt Cloud の URL から取得します。

ステップ 3 — ピッカーを開く。 MCP Gateway で、 MCP Gatewayをクリックし、 サーバーを追加 を選択して、 リモート MCP サーバーを接続を選択します。

ステップ 4 — サーバー情報を入力する。 名前、 名前、 説明、 URL、 コラボレーター および 認証データ。URLは標準のdbt MCPエンドポイントです：

https://cloud.getdbt.com/api/ai/v1/mcp/

マルチセルアカウントの場合は、セルのホスト名を使用してください（例：https://abc123.us1.dbt.com/api/ai/v1/mcp/）。

ステップ5 — 認証とヘッダーの設定 Bearerトークン認証を追加し、dbtトークンを設定して、x-dbt-*ヘッダーを指定します。接続レベルでリスクのあるツールを非表示にするには、x-dbt-disable-toolsetsまたはx-dbt-disable-toolsを追加します。これらはツールを削除するための独立した2つの手段であり、多層防御として機能します。

認証の仕組み

TrueFoundryは、 インバウンド 認証（クライアントがゲートウェイに対して自身を証明する方法）と、 アウトバウンド認証（ゲートウェイがdbtに対して自身を証明する方法）を分離しています。

インバウンド は、TrueFoundry APIキー、サービス間通信用のバーチャルアカウントトークン、独自のIdP（Okta、Entra、Auth0、Cognito）からのJWT用IDプロバイダトークン、およびIDEツール用のTrueFoundry OAuthをサポートしています。注意点として、バーチャルアカウントトークンはすべてのリクエストに同一のアクセス権を付与するため、ユーザーごとのアクセス範囲を制限することはできません。

アウトバウンド （dbt向け）は、 API キー タイプ。2 つの認証モードがあります。

共有認証情報 つまり、すべてのユーザーに 1 つのキーを割り当てることができます。ヘッダー名と値を一度設定します。これは、読み取り専用のメタデータに限定されたサービストークンのモードです。

個人認証情報 各ユーザーが独自のキーを指定することを意味します。ヘッダーに Bearer {{API_KEY}} などのプレースホルダーを設定し、各ユーザーがトークンを追加します 認証オーバーライド タブ。

マッピングは直接行われます。共有認証情報はサービストークンとペアになり、個人認証情報はPATとペアになります。execute_sqlが有効な場合は、SQLの実行範囲が実行者のみに限定されるので、これが必要となります。

dbt はベアラートークン認証を使用するため、OAuth 同意画面やリダイレクト URI はここにはありません。<tfy-control-plane-base-url>自己登録リモートサーバーで OAuth2 を設定する場合、リダイレクト URI はコントロールプレーンコールバック、https:///api/svc/v1/llm-gateway/mcp-servers/oauth2/callback であり、マネージド MCP が使用する auth.truefoundry.com コールバックではありません。

出荷前のスコーピングツール

ザの ツール タブでは、エージェントが実行できる操作を決定します。dbt の場合は、設定の中で最も価値のある 5 分間です。

ツールごとの切り替え。 ツールをオフにすると、そのツールはツール/リストから完全に除外されます。クライアントには表示されず、呼び出すこともできません。これはプロンプト層のフィルタリングではありません。推奨される dbt 設定は簡単です。メタデータと検出ツールはオンのままにして、特定のエージェントが必要としない限り execute_sql はオフにしてください。execute_sql を呼び出せないエージェントを、ランナウェイクエリに結び付けることはできません。

新しいツールはデフォルトで有効になっています。 オンのままにすると、新しい上流ツールが自動的に表示されます。オフにすると、有効にしたツールしか使用できないため、将来の dbt リリースでは、エージェントができることを静かに広げることはできません。

一括アクション。 各行をチェックボックスに切り替えるので、一度に多くのツールを切り替えることができます。

ツール上の鉛筆をクリックすると、モデルへの表示方法が変更されます。

ザの [説明] 最大 20,000 文字までのオーバーライドで、ツール選択を指示します。メトリクスクエリツールを「既知のメトリクス用に SQL を作成するのではなく、常にこれを呼び出す」ように書き直し、モデルを自分の定義に微調整します。 MCP ツール注釈 ツールにマークを付ける 読み取り専用 または 破壊的、読み取り専用ヒントまたは破壊ヒントを設定します。

誰が何をできるか:コラボレーターの役割

アクセス制御は、ユーザー、チーム、または仮想アカウントに、IDがどのサーバーに到達するか、そしてIDがサーバー内のどのツールを呼び出すかという2つの側面で結び付けられます。

つまり、どのDBTツールが存在するかをプラットフォームチームが管理し、他のチームがそれらを使用するのも同じです。 MCP アクセスコントロール モデルはレジストリ全体に適用されます。

Ready to scope your first data server?

Connect dbt, keep lineage open, and hold SQL execution behind a human.

Start free on TrueFoundry

危険な 2 つのツールの人間による承認

execute_sql を無効にするのは至難の業です。エージェントに SQL を実行させたり、コストのかかるメトリクスクエリを実行させたりしたい場合がありますが、ただ無人ではいられません。それがツール承認ポリシーの目的であり、制限が設けられている範囲が小さいため、このポリシーが負債に見合うのです。

ゲーテッドツールが呼び出されると、コールは保留され、リクエストが作成され、承認者に通知されます。承認後、設定可能な期間の呼び出しが成功し、新たな承認が必要となります。

下にポリシーを作成 AI ゲートウェイ → ポリシー → MCP ツール承認、現在ベータ版としてマークされています:

各ポリシーは、ゲートして選択するサーバーに名前を付けます 承認範囲: リストしたツールのみに名前を付けて、DestructiveHint とマークされたすべてのツールを破壊ゲートする:true、すべてがすべてをゲートする。スコープが重なっている場合、名前付き > 破壊的 > すべてという最も限定的なものが勝ちます。dbt の場合、通常は名前を付けるのが正直な選択です。2 つか 3 つのツール名が実際の露出を網羅し、すべてをゲートすると、承認者は系統読み取りをクリックすることになります。

有効性 のどちらかです 一度、1 回の実行、または 時間ベース、分単位の所要時間。ポリシーが競合する場合、最も制限の厳しいものが優先されます。10 分のウィンドウを 1 回突破すると 30 分間のウィンドウが優先されます。承認者には、電子メール、Slack、PagerDuty、または MS Teams を通じて通知が届きます。

各リクエストにはツール、ポリシー、リクエスタ、および実際の引数が表示されるため、承認者は処理前に SQL を読むことができます。保留中、呼び出し元には、エラーではなく _meta.approval_status:「保留中」という内容の JSON-RPC 結果が表示されるため、正常に動作するエージェントは待機して再試行します。許可の範囲はリクエスト者ごとに設定され、拒否されても誰も永久にブロックされるわけではありません。そのためには、ツールを無効にするか、ユーザーを削除してください。

ツールプレイグラウンドでのテスト

最初に手でテストしてください。サーバー詳細ページでをクリックします。 試してみる ツールの横でパラメーターを入力し、JSON を読み取ります。 試してみる オフにしたツールでは無効になっています。これにより、環境 ID が間違っていたり、dbt AI 機能が有効になっていなかったり、トークンが期限切れになったりといった、退屈な dbt の障害を早期に発見できます。

IDE から使用する

を開きます 使用方法 タブには、テナント固有のゲートウェイ URL とスニペットが表示されます。

クロード・コード、VSコード、クロード・デスクトップ、カーソル、ウィンドサーフ、コーデックス、PythonとTypeScript MCP SDKをカバーしています。 MCP をカーソルに追加 コンフィグを書き込みます。 API キーを表示 トークンを明らかにします。

URL を自分で組み立てるのではなく、このタブから取得してください。URL はテナントごとに異なり、クライアントが接続してもツールを一覧表示しない原因としては、手動で構築したエンドポイントが原因です。ただし、副次的な影響もあります。アナリストが TrueFoundry エンドポイントを設定するため、dbt 認証情報はラップトップには届きません。

ゲートウェイの後ろに置くと得られるもの

ツールレベルのメトリクス。 ダッシュボードには、1 秒あたりのリクエスト数、P50 ～ P99 のレイテンシー、エラータイプ別の失敗率、ツールごとのリクエスト数が分類されています。

データサーバーの目的はコスト管理であり、単なるダッシュボードではありません。エージェントが 1 回の実行でメトリクスクエリを 200 回呼び出したことを確認する方法です。

フルリクエストオブザーバビリティ。 すべてのツールコールは、呼び出し元のID、ツール名、入力、レイテンシーで追跡され、OpenTelemetryを介してエクスポートされます。「どのエージェントが、誰のために、どのような引数でそのクエリを実行したか」は、調査ではなく検索になります。

ガードレール。 プレツールとポストツールのガードレールは、MCPツール呼び出しに対してポリシーを実行します。

オーバーヘッドが低い。 ゲートウェイはだいたい追加します 3-4 ミリ秒 レイテンシーとハンドルの 1 つの仮想 CPU で 350 以上の RPS、一緒に 1,000 以上のLLM。

1 つのレジストリ。 複数のサーバーを登録すると、厳選されたツールのサブセットを 1 つのエンドポイントにまとめることができます。 仮想 MCP サーバー —dbtのメタデータツールとウェアハウス読み取りツール、他には何もありません。これが信頼できる分析エージェントの形です。dbt が定義を提供し、ウェアハウスが行を提供します。

アクセス権限の取り消し

テナント管理者は、横にある3つのドットのメニューから、保存されているすべての認証情報を消去できます [編集]:

すべてのトークンを取り消す は、そのサーバー上のすべてのユーザーおよび仮想アカウントの認証オーバーライドと保存済みトークンを削除します。この操作は次回の要求から有効になり、アクティビティログに記録されます。取り消しはできず、実行後は全員が認証情報を再入力する必要があります。また、この操作はテナント管理者のみに表示されます。注意すべき制限として、この操作はトークンをクリアします。 ゲートウェイ上でのみdbt Cloud内ではクリアされないため、インシデント発生時にはdbt側のトークンもローテーションしてください。

知っておくべき注意点

ヘッダーの設定が重要です。 初回設定で失敗する原因の多くは、認証の問題ではなく、x-dbt-* IDの欠落や誤りです。開発環境IDとユーザーIDはSQLおよびFusionツールでのみ必要となるため、最初のSQL呼び出しが行われるまでは接続が正常に見えることがあります。

設定にはアカウント管理者権限が必要ですが、使用する際には不要です。 トークンの作成とIDの読み取りには、dbt Cloudのアカウント管理者権限が必要です。ただし、エージェントに管理者権限を持たせる必要はありません。管理者として作成した後、エージェントにはスコープを制限したサービス用トークンを渡してください。

メタデータの品質はプロジェクトの記述に依存します。 ドキュメント化されていないプロジェクトのリネージをエージェントが読み取っても、ラベルのないマップしか得られません。

関連資料

• MCPゲートウェイとは — アーキテクチャの入門ガイド
• MCPのアクセス制御 — ツールおよびサーバーレベルの権限設定
• 仮想MCPサーバーの解説 — dbtメタデータとデータウェアハウス読み取りの統合
• MCPの認証 — インバウンドおよびアウトバウンド認証
• MCPサーバーのセキュリティベストプラクティス — ハーデニングチェックリスト

結論

dbt MCPサーバーは、データスタックにおいて最も過小評価されている統合機能です。その理由は、一見すると地味だからです。このサーバーはデータを返すのではなく、定義、リネージ、ドキュメントを返します。これこそが、ビジネス上の問いに正確に答えるエージェントと、推測でカラムを指定して一見もっともらしいSQLを書くエージェントを分かつ「コンテキスト」なのです。

また、このサーバーは驚くほど簡単に安全性を確保できます。リスクは「execute_sql」と負荷の高いセマンティックレイヤーのクエリに集中していますが、これらは数分で対策可能です。管理者用PATではなくスコープを限定したサービス用トークンを使用する、メタデータは公開しつつSQL実行は無効化するツールごとの切り替え設定、承認ゲートの設置、そして呼び出しログの追跡などが有効です。

Connect the dbt MCP server on TrueFoundry

Free to start