dbt Partner様向け資料 · 営業用 · 抜粋

ターゲット別 営業プレイブック

顧客が今どうやってデータを加工しているか、AIエージェントの施策がどこまで進んでいるかで、聞く課題と提案の順番は変わる。3つのターゲット像ごとに、聞くべき課題と出やすい反論をまとめた。

出典：「dbt platform 営業ガイド」第9章 9.2 ターゲット別の入口の抜粋。デッキv2（「既存のデータ基盤は人間のために設計されている」「信頼性の崩壊・スケールの停滞・コストの爆増」）に合わせて更新。営業スクリプト本文は同ガイド側にあり、ここでは省いている。数字は同ガイドの第3章（機能カード）、第12章（数字の使い方）にあるものだけを使っている。

00ターゲットを見分ける

最初の会話で「今、データの加工処理は何で組んでいますか」と聞く。ストアドやビュー、batで組んでいればターゲット1。dbt Coreか dbt Projects on Snowflakeで動かしていればターゲット2。そのうえで「AIエージェントの施策は動いていますか」と聞き、経営スポンサー付きの施策があればターゲット3を重ねる。ターゲット3は1や2と両立するので、加工処理の状態とAI施策の有無を別々に押さえる。

ターゲット 1

自前実装で加工している顧客

Stored Procedure、ビュー、batで加工処理を組んでいる。dbtは未導入。

  • 似たようなストアドやテーブルが増えて、どれが最新かわからない
  • 秘伝のタレのようなクエリがあり、さわれる人が限られる
  • 「なぜか今月の売上が多い」から原因探し
主役：Git、シンプルなSQL、テスト、Wizard → ターゲット 2

dbt Core／Projects on Snowflakeの顧客

dbtを運用中。モデル数と使う人が増えてきた。

  • 実行頻度をコストで決めている
  • レビューを通さず本番へデプロイできる
  • 同じスキーマへの書き込み、自前CI
主役：platformのマネージドCIとガバナンス、Mesh、Wizard、State → ターゲット 3

AIエージェント施策を進めている顧客

経営スポンサー付きの施策がある。PoCは動くが本番に行けない。

  • 信頼性の崩壊：指標の定義がツールごとに違う、根拠を説明できない
  • スケールの停滞：コンテキストの断片化、ベンダーロックイン
  • コストの爆増：繰り返しの取得、全体再構築
主役：MCP Server、Semantic Layer、Catalog、State →

01-03ターゲット別の入口

ターゲット 1

自前実装で加工している顧客：ストアドとビューの資産を、信頼できるデータに変える

主役の機能
Gitによるバージョン管理、シンプルなSQLでのモデル定義、宣言的テスト、リネージとCatalog、dbt Wizard（移行）。
聞くべき課題
課題（顧客の声）解決策質問
「似たようなストアドやテーブルがいくつもあって、どれが最新かわからない。」Git管理が前提。定義はひとつで、変更はすべて履歴に残り、テーブルは常にその定義から作られる。誤ったバージョンのコードを使うリスクがなくなる。同じ集計のテーブルやストアドが何種類ありますか。「最新はどれか」に今すぐ答えられる人はいますか。
「秘伝のタレのようなクエリがあちこちに散在していて、ストアドをさわれるのが限られた人だけになっている。」DWH固有の記法を最小化したシンプルなSELECT文でモデルを定義。増分更新の例では62行が16行（74%削減）。属人化が解け、アナリストも開発に参加できる。ストアドの中身を理解して修正できる人は何人いますか。その人が休んだら止まる処理はありますか。
「『なぜか今月の売上が多い』と言われてから原因を探す。特定に何日もかかる。」テーブル毎のテスト（order_idがunique、nullなし）をYAMLに宣言し、継続的にエラー検知。「order_idにダブりあり、増分更新ロジックがおかしい」と即座に原因を特定できる。直近で「数字がおかしい」と言われたのはいつで、原因の特定に何人・何日かかりましたか。
「ストアド・スクリプトの実行順序はジョブ設定で手で管理している。変え忘れて壊したことがある。」依存関係（DAG）から実行順序を自動解決。順序制御のためのbatやジョブ制御設定といった開発物そのものが不要になる。実行順序はどう管理していますか。順序を変え忘れて壊れたことはありますか。
「どのマートがどのソースから来ているかはExcelで管理していて、最新かどうかわからない。」リネージをSQLから自動で可視化。モデルとカラムの説明、テスト結果がCatalogに反映される。Excelリネージの廃止が最初の成果になる。マートの依存関係をどこで管理していますか。最後に更新されたのはいつですか。
「試しにAIに生データを見せて『月ごと・商品ごとの売上』を聞いたら、答えが毎回違ったし、クエリとトークンのコストも莫大だった。」中間集計で正しい集計ロジックを前もって適用しておく。エージェントの参照データ量と会話ラリーが減り、コスト効率が上がる。今の基盤整備が、そのままAI-Readyの土台になる。生データにAIを直接向けて試したことはありますか。同じ質問で答えは揃いましたか。クエリとトークンのコストは、本番運用できる規模に収まっていましたか。
出やすい反論
出やすい反論まず認めるこう返す
「今動いているから困っていない」動いているものを止める理由はない。困るのは動かなくなったときではなく、変えたくなったときです。最後に大きめの改修をしたとき、何人で何週間かかりましたか。
「書き直しの見積りが巨額だった」外注で全量を人手で書き直せば、そうなる。dbt Wizardなら、既存のストアドをdbtコードへ自動変換できます。人手での全量書き直しが前提でなくなれば、内製での移行が現実になります。1本のPoCで工数の桁を確かめてから判断してください。
「複雑なSQLを書ける人がいない」手続き的なストアドは難解で、書ける人が少ないのは当然。dbtのモデルは宣言的なSELECT文で、同じ処理が62行から16行になります。アナリストが開発に参加できるようになるのが、デリバリーが速くなる理由です。
「AI活用はまだ先の話」基盤の整備が先、という順序は正しい。だからこそ、今の整備の仕方が問題です。不正確なデータ、指標の不整合、リネージの欠如は、そのままエージェントの信頼性崩壊に直結します。dbtで整備すれば、その土台がそのままAI-Readyになります。
ターゲット 2

dbt Core または dbt Projects on Snowflake を使っている顧客：置き換えず、チーム開発の穴を埋める

主役の機能
dbt platformのマネージドCI、開発者・PRごとの専用スキーマ、環境保護とRBAC、dbt Mesh、dbt Wizard、dbt State（Core v1.7以上でプラグイン）。
Projects on Snowflakeの顧客に対する前提

小規模チームでSnowflake内で完結させたいなら現実的な選択肢。否定しない。差は、チーム開発の課題（安全なコード変更、データの競合、CI/CD、複数部署の管理）をマネージドで防ぐか、運用ルールと自前実装でカバーするか。下の表で「Projects」と付けた行がその差を聞く質問。

聞くべき課題
課題（顧客の声）解決策質問
「コストが気になるので、ジョブの回数を減らしている。鮮度は我慢している。」共通dbt Stateがデータとコードの変更を検出し、上流が変わっていないモデルをスキップ。平均30%のコンピューティングコスト削減。Core v1.7以上にプラグインで載り、Fusion、platformでも使える。メインのジョブは1日何回走り、上流が変わっていない実行はどれくらいありますか。回数を減らしたことは。
「PRごとに全部ビルドすると遅くて高いのでCIは止めた。あるいは外部のワークフローサービスで自前で組んでいる。」共通dbt特化のCI/CDをマネージドで提供。PR作成時にdbt buildが検証環境（dbt_pr_1）で走り、変更されたものだけをビルドする。自前実装の開発・運用コストがなくなる。PRごとにdbt buildは走りますか。CI/CDは何で組んでいて、誰が維持していますか。
「ワークスペースから、レビューを通さずにそのまま本番のdbt projectをデプロイできてしまう。」Projectsplatformは統合開発環境上でGitでのバージョン管理を強制し、本番ジョブは常にGitブランチをcloneして実行。マージ済みのコードだけが本番に反映される。Projectsではデプロイ時点のスナップショットがGitと同期せず、OWNERSHIPをCI/CD専用ロールに限定するなどの運用が必要。レビューを経ずに本番のdbt projectオブジェクトをデプロイできる人は、今何人いますか。その制限はどう担保していますか。
「開発者同士やCIジョブが同じスキーマに書き込んで、レビュー時のデータが当てにならない。」共通・Projectsは自前開発者・PRごとの専用スキーマ（dbt_alice、dbt_bob、dbt_pr_1）が自動で作成・適用される。Projectsではenv.ymlとCURRENT_USER()で分離できるが、設計と管理はチーム側の責務。開発者ごと、PRごとのスキーマ分離はどう実現していますか。その設定を誰が管理していますか。
「開発のビルドが本番に当たったことがある。今は気をつけるしかない。」共通環境保護機能とRBAC・SSO。レビューを経ない本番適用を防ぎ、アクセスレビューをプラットフォームが答える。開発の実行が本番を上書きしたことはありますか。今それを何が止めていますか。
「全部モノレポで小さな変更にも重いレビューが要る。逆に部署ごとに分けたら依存が見えなくなった。」共通・Projectsは相当機能なしdbt Meshで部署毎にプロジェクトを分割しつつ、モデルのアクセス権限管理と横断的なデータ依存の可視化を実現。チーム別リポジトリに分離しても、複数チームが本番影響なしで並行開発できる。Projectsには相当機能がなく、分割と統制は運用設計に依存。モデルを作るチームはいくつで、リポジトリやプロジェクトはいくつですか。他チームのモデルへの依存はどこで見えますか。
「アナリストはSQLを書けないので、小さな変更でもチケットで数週間待つ。」共通dbt Wizard。自然言語の指示から統制されたdbtモデルを生成・修正できる。ガードレールと監査証跡がデフォルトで有効なので、SQLを書かない人でも安全に変更を出せる。SQLを書かない人は、小さな変更をどれくらい待っていますか。
「Snowflakeだけで完結して追加ライセンスが要らないのは楽。でも使う人を増やしたら、ワークスペースの関連付けとデプロイの手作業が回らなくなってきた。」Projectsplatformでは設定はプロジェクトに1回で、全員が同じGitリポジトリ、同じJobs、Environments、Catalogを共有する。デッキのアップグレード目安は、アナリストをオンボードしてスケールしたいとき、手動管理がトラブル対応の負担になったとき、実行がコンピュートコストを押し上げているとき。今後1年でdbtを使う人数はどれくらい増えますか。ワークスペースの関連付けとスナップショットのデプロイは誰がやっていますか。
出やすい反論
出やすい反論まず認めるこう返す
「Coreで十分。なぜ払うのか」Coreは本当に良く、動いているなら引き剥がすべきでない。置き換えではありません。StateはCoreに載り、Fusionは無料です。有料の話は、チーム開発の4課題をマネージドで防ぐ場所、マルチリポとMesh、環境保護、RBACだけです。最近できなかったことは何でしたか。
「Projects on Snowflakeで足りる。追加ライセンスも要らない」個人・小規模で、Snowflakeだけで完結させたいなら現実的な選択肢。人数が少ないほど整備コストは小さい。違いは、全員で1つのプロジェクトを共有するか、個人単位のワークスペースをGitに手動で関連付けるかです。レビューを経ない直接デプロイ、スキーマ分離の自前設計、外部でのCI/CD構築、Meshに相当する機能がないこと、この4つを運用ルールで担保し続けられるかどうか。使う人が増えたとき、その運用は誰が守りますか。
「Airflowで回っている」良いツールで、置き換えは時間の無駄。論点はスケジューラーではなくstateです。DAGが発火したとき、全部を再ビルドしていますか、変わったものだけですか。スケジューラーは残して、stateを足します。
「CIは自分たちで組んである」組めるチームは強い。その接着剤の維持に月あたり何エンジニア日かかっていますか。その人がそうでなければ何を作っているか、がマネージドCIの価値です。
ターゲット 3

AIエージェント施策を進めている顧客：信頼性・スケール・コストの3つの壁を先に取り除く

主役の機能
dbt MCP Server（Models、Docs、Freshness、Metrics、Lineage、Ownershipを構造的に渡す）、Semantic Layer、Catalogとリネージ、dbt State、dbt Wizard。基盤側にdbt platformのガバナンス。
聞くべき課題
課題（顧客の声）解決策質問
「売上の定義がBIとノートブックとコパイロットで違う。」信頼性Semantic Layerで指標の定義をコードとして一元管理。BI、ノートブック、エージェントはすべて同じ定義に問い合わせるので、どこから聞いても同じ答えになる。MCP Server経由でエージェントにもMetricsとして渡る。「売上」「アクティブ顧客」の定義はどこにあり、ツール間で一致していますか。
「エージェントの答えの根拠を、経営や監査に説明できない。」信頼性Catalogとリネージ。MCP ServerがLineageとOwnershipを渡し、どのソースからどんな加工を経た数字かを構造データで答えられる。エージェントの回答の出所を、経営や監査に説明できますか。
「エージェントにデータの説明を丸ごと読ませていて、ひとつの質問に答えるだけで時間もコストもかかる。」スケールMCP Serverが、テーブルの説明、鮮度、指標の定義、依存関係、担当者といった情報を、質問に必要な分だけエージェントに渡す。あちこちに散らばった説明を一本化する。エージェントはデータの説明をどこから読んでいますか。ひとつの質問に答えるのに、どれくらい時間とコストがかかっていますか。
「特定のベンダーの形式に寄せてしまって、他のDWHやLLMに動かせない。」スケールdbtはSQLで、DWHを問わない共通レイヤー。マルチDWH構成でも同じモデル、同じコンテキストをエージェントに渡せる。ロックインされたフォーマットから外れる。3年後にプラットフォームやLLMを変えるとしたら、今の仕組みのどれだけを書き直しますか。
「エージェントが同じデータを何度も取りに行って、トークン代とクエリ代が読めない。」コスト中間集計とMCP Serverで参照データ量と会話ラリーを減らす。APIの推論トークン消費は2025年に前年比320倍。エージェントは人間より大量にクエリしうるので、1回答あたりのコストが論点になる。1回答あたりのトークン数とクエリ数を計測していますか。エージェントを増やしたときのコストの見通しはありますか。
「小さな変更ひとつで、パイプライン全体が再構築される。」コストdbt Stateで変更されたモデルだけをビルド。平均30%のコンピューティングコスト削減。実行回数を制限せず、ビジネスの必要に応じて鮮度を保てる。メインのジョブは1日何回走り、上流が変わっていない実行はどれくらいありますか。
「PoCはできたが本番に行けない。ROIを説明できない。」ROI企業の95%がAI実装からROIを得られていない。原因は基盤側にある。信頼できるデータと意味をコスト効率よく提供し、dbt Wizardで安全な変更（インシデント平均15〜20%削減）を組み込むことで、本番化の障害を先に取り除く。PoCが本番に行けない理由は何ですか。何をもって成功と判断しますか。
出やすい反論
出やすい反論まず認めるこう返す
「フロンティアモデルに社内文書や生データを直接参照させたら、それで動いた」試すだけなら、それで動く。1回の回答にかかる時間とコストは、本番の問い合わせ量でも許容できる規模ですか。生データを毎回読ませる限り、時間もコストも問い合わせ量に比例して増え続けます。
「BIにセマンティックレイヤーがある」全社が1つのBIで働いているなら役目を果たす。明日エージェントが売上定義を必要としたら、どこから取得しますか。2つ目のツールが必要とした瞬間に、定義はBIの中に閉じ込められます。
「DWHのオントロジー基盤でコンテキストを育てる」DWH内で閉じるなら、立ち上がりは速い。そのコンテキストは、DWHやLLMを変えたときに持ち出せますか。特定ベンダーの形式で育てるほど、引っ越しの負担は大きくなります。dbtはDWH横断で共通のインターフェースを持つので、データとコンテキストを乗り換えに縛られずに長く育てられます。
「まだPoC段階だから基盤投資は早い」PoCで価値を確かめてから投資する順序は正しい。95%がROIを得られていない原因は基盤側です。PoCが本番に行けない理由、答えのばらつき、根拠の説明、コストの見通し、を先に取り除かないと、PoCはPoCのまま終わります。

--使い方と共通ルール

  • ビジネス課題が先、dbtは答え。切り出しは製品名ではなく、顧客の加工処理の状態、実行頻度、指標のばらつきから始める。
  • 聞くべき課題は全部聞かなくてよい。答えられた質問だけを使う。「はい」が付いた課題が、そのまま提案の順番になる。
  • 反論はまず認める。正しい部分を認めずに返すと信用を失う。認めたあと、論点をずらさずに返し、質問で主導権を戻す。
  • 数字は顧客の数字で作り直す。30%（dbt State）、74%削減（増分更新のSQL行数）、15〜20%（Wizard）、70%・95%・320倍（デッキv2の市場データ）はいずれも出典と条件付きの目安。公表数値がない機能は、監査の人日、チケット列の長さ、CI維持のエンジニア日、直近6か月の請求を一緒に数える。
  • 次のアクションは棚卸しとPoC。ターゲット1はストアド一覧とジョブ制御設定、ターゲット2は直近6か月のジョブ履歴とモデル数・テスト数・実行回数、ターゲット3は指標3つの候補と定義の所在。顧客側で棚卸しを用意してもらい、こちらが試算かPoC計画を持っていく形で締める。

本資料は「dbt platform 営業ガイド」（「what's dbt for Partners v2」デッキの章立てに沿い、Partner Account Planner v13の内容を日本語化したもの）から、第9章 9.2を抜粋したものです。dbt StateとFusionエンジンに関する数値はdbt Labsのパートナー向け資料に基づく目安であり、保証値ではありません。