「dbtを入れたいが、社内にdbtを触れる人がいない」。この相談は、BigQueryやSnowflakeを導入し終えた会社から特に多く受けます。
dbt（data build tool）自体はオープンソースで、ドキュメントも豊富です。それでも社内だけで進めると、既存SQLの棚卸しで止まったり、ディレクトリ設計で迷ったり、CI/CD組み込みで詰まったりして、半年経ってもPoCから抜け出せない、というケースをよく見ます。
そこで、dbt導入を外部に依頼するときに知っておきたい情報を通しでまとめます。何を頼めるか、いくらかかるか、どう進めるか、どんな会社を選ぶか、そしてよくある失敗はどこか。社内にdbt経験者がいない、あるいは1〜2人だけで手が回らない状況を前提に整理しました。
dbt自体の仕組みや機能を先に押さえたい方は、dbtとは？データ変換をコード管理するツールの仕組みを解説を参照してください。
社内だけでdbt導入を進めると、大きく3つの壁でつまずきます。順に見ていきます。
BigQueryやSnowflakeを何年か運用してきた会社では、変換SQLがあちこちに散らばっています。Scheduled Query、スプレッドシートのIMPORTRANGE、Airflowのタスク、退職者の個人リポジトリ。これを一覧化するだけで、想定の3倍の時間がかかることが多いです。
「動いているけれど誰も中身を知らないSQL」が数十本〜数百本ある状態からのスタートになるため、棚卸しと優先順位づけの経験がないと、この時点で数か月消えます。
dbtには staging / intermediate / marts のような推奨ディレクトリ構造と、view / table / incremental のマテリアライゼーションという設計上の判断ポイントがあります。
これらは後から変えるとレビュー依頼と影響調査が大量発生するため、最初に決めきる必要があります。dbt Labs公式のベストプラクティスは公開されていますが、自社の分析要件・データ量・コスト制約に合わせて具体化するには経験が要ります。
dbtの真価は、dbt test をCI/CDに組み込んでプルリクエストごとにデータ品質チェックが走る状態になったときに出ます。ここまで到達すると、変換ロジックの変更が安全にレビュー・マージできるようになります。
一方で、GitHub Actions・GitLab CI・dbt Cloudジョブのどれをどう設計するか、テストが失敗したときの通知経路、本番マージ後の実行順序など、dbt特有のCI/CD設計知識が必要です。データエンジニアリング経験のあるメンバーが社内にいないと、この段階で止まる会社が非常に多い印象です。
外部に依頼する場合、スコープは大きく5つの型に分かれます。全部を1社に頼む必要はなく、自社に足りない部分だけを切り出して依頼できます。
| スコープ | 主な作業内容 | 向いているフェーズ |
|---|---|---|
| PoC支援 | 対象データを1〜2系統に絞り、Model 5〜15本とテストを整備して型を作る | dbt未導入。まず1つのユースケースで効果を試したい |
| 初期構築 | 30〜50本のModel設計、ディレクトリ構造、マテリアライゼーション、CI/CDまで一括整備 | PoCが成功し、本格導入に進む段階 |
| 大規模移行 | 既存Scheduled Query・ETLジョブ100本以上をdbt Modelに移行、段階的リリース | 既存資産が大きく、社内リソースだけでは移行しきれない |
| CI/CD・テスト整備のみ | すでにModelは書けているが、テスト自動化と本番運用の型を作りたい | エンジニアはいるが、dbt運用経験が浅い |
| 教育・伴走支援 | 週1〜2回のレビュー、ペアプロ、勉強会。社内メンバーが自走できる状態を作る | 内製化を最終ゴールにしたい |
会社によっては、初期構築後に「教育・伴走支援」だけを月契約で続ける、という形も一般的です。データ基盤の内製と外注のバランスの考え方は、データ基盤は内製と外注どちらがいい？判断軸とハイブリッド運用で詳しく整理しています。
費用の目安を、規模別と継続支援に分けて整理します。以下はEvastの見積もり実績と、複数の支援会社の公開情報から見た市場感の概算です。
| スコープ | Model数の目安 | 費用の目安 | 期間 |
|---|---|---|---|
| PoC支援（1ユースケース＋テスト自動化） | 5〜15 | 100万〜300万円 | 1〜2か月 |
| 初期構築（ディレクトリ設計・CI/CD・ドキュメント） | 30〜50 | 300万〜800万円 | 2〜4か月 |
| 大規模移行（既存Scheduled Query群のdbt化） | 100以上 | 800万〜2,000万円 | 4〜6か月 |
| CI/CD・テスト整備のみ | - | 100万〜300万円 | 1〜2か月 |
| 支援形態 | 費用の目安 | 稼働の目安 |
|---|---|---|
| レビュー中心（PR確認・相談窓口） | 月20万〜40万円 | 月2〜4日相当 |
| 伴走型（ペアプロ・設計相談） | 月40万〜80万円 | 月4〜8日相当 |
| 定額オンサイト | 月80万〜150万円 | 月8〜15日相当 |
dbt Cloudを使う場合、開発者1名あたり月100ドル前後（Starterプラン）が別途かかります。5人チームで年間約90万円が上乗せです。dbt CoreのままGitHub Actionsに載せる構成なら、この費用は発生しません。プラン別の詳細と、Coreの周辺運用コストまで含めた比較は、dbt CloudとCoreの違いと料金は？発注判断のための選び方にまとめています。
BigQuery側のコスト設計まで含めた費用の考え方は、データ基盤構築の費用相場は？見積もりの内訳と判断基準を解説で詳しく解説しています。
外部の支援会社と一緒に進める場合の、典型的な4ステップです。PoC〜初期構築の想定で説明します。
現行のDWH構成、Scheduled Queryやスプレッドシートで動いている変換SQL、誰がどのダッシュボードを使っているかを洗い出します。この段階で「dbt化する優先度」の順位付けを行います。
Evastで支援するときは、この段階を短くするために、事前ヒアリングシートと現行環境の棚卸しテンプレートを渡し、初回打ち合わせまでに埋めてもらう形が多いです。
staging / intermediate / marts の3層構造をベースに、社内の分析要件に合わせて設計します。マテリアライゼーション（view/table/incremental）の判断基準、命名規則、テスト方針をこの段階で決めきります。
ここを飛ばして「動くModel」だけ先に作ると、あとで作り直しになりがちです。時間はかかりますが、飛ばさないことが結果的に早いです。
Modelファイルの実装、schema.yml へのテスト定義、dbt docs generate によるドキュメント整備を並行して進めます。CI/CD（GitHub Actionsまたはdbt Cloud）にプルリクエスト時の dbt test と、mainマージ時の dbt run を組み込みます。
このステップの後半で、社内メンバーにペアプロ形式で書き方を移していきます。単に納品するのではなく、書ける人を残すのがdbt導入の肝です。
本番運用に切り替え、初期の1〜2か月は週次でレビューと相談を受ける形で伴走します。新規Modelの追加や、既存Modelのリファクタリングを社内メンバーが自走できる状態を目指します。
初期構築が終わっても、社内でdbtの運用経験が浅い場合は、月次または隔月のレビュー契約を数か月続けるのがおすすめです。dbt導入プロジェクト全体の期間感については、データ基盤構築の期間はどのくらい？進め方と期間目安をフェーズ別に解説も参考になります。
dbtを扱える会社は増えていますが、実運用まで持ち込める会社はまだ限られます。以下の5点で見比べると、外れが少なくなります。
1. 自社が使う（使う予定の）DWHでの構築実績
BigQueryなのか、Snowflakeなのか、Redshiftなのか。dbtは共通ですが、パーティション設計・マテリアライゼーション・コスト最適化はDWHごとに勘所が違います。BigQuery案件でSnowflake経験しかない会社を選ぶと、コスト設計で苦戦することがあります。
2. dbt Coreとdbt Cloud、両方の構築経験
Coreしか触っていない会社は、非エンジニアが混じるチームでのdbt Cloud運用の勘所を持っていないことがあります。逆にCloudしか触っていない会社は、GitHub Actionsとの組み合わせのような柔軟な構成が苦手なことがあります。両方の選択肢を提示できるかを確認してください。
3. テスト設計・CI/CD組み込みの実装例
「Modelは書けますよ」だけの会社と、「CI/CDで dbt test を回してSlack通知まで組み込みますよ」の会社では、成果物の完成度が大きく違います。過去案件のCI/CD構成を、抽象化した図でよいので見せてもらいましょう。
4. 教育・ドキュメント整備までスコープに含めるか
納品してハイ終わり、では社内でdbtが動かなくなります。ペアプロ、勉強会、ドキュメント整備がスコープに含まれているか、あるいはオプションで頼めるかを事前に確認します。
5. 見積もりの内訳が明確か
「一式500万円」ではなく、「Model設計に○人日、CI/CD構築に○人日、テスト整備に○人日」と工数の内訳が出せる会社を選びます。追加スコープが発生したときの追加費用の考え方も、契約前に確認しておくとトラブルが減ります。
支援会社を比較検討するときの一般的な視点は、データ基盤構築の会社の選び方・比較｜失敗しない発注先にまとめています。
最後に、社内・外注のどちらで進める場合でも起きがちな失敗を4つ挙げます。
失敗1：既存SQLの完璧移行を狙う
「動いているSQLを全部dbt化してから使い始める」と、初期の構築期間が半年〜1年に膨らみ、投資回収が見えなくなります。新規Modelから徐々にdbt化し、動いている既存クエリは触らない方針の方が、現実的に成果が出ます。
失敗2：教育を後回しにする
外部に構築だけ依頼して、社内で誰も書けないままリリースすると、次の要件変更で止まります。構築フェーズと並行して社内メンバーが1〜2本Modelを書ける状態を作ることが、内製化の最短ルートです。
失敗3：ツール選定が先行する
「dbt Cloudを入れました。次は何をしましょう？」という状態は要注意です。ツール導入が目的化して、解決したい分析要件（何のダッシュボードを・誰が・どの粒度で見るか）が後回しになっています。先にユースケースを1つ決めてから、dbtを入れる順序を守ります。
失敗4：BigQueryやSnowflakeのコスト設計を無視する
dbtは変換SQLを大量に並列実行するため、マテリアライゼーションを何も考えずに table に統一すると、BigQueryのストレージ費とSnowflakeのクレジット消費が急増します。導入と同時に、BigQueryのコスト削減やSnowflakeのコスト最適化の観点も設計に組み込みます。
dbt導入支援を頼む前に、押さえておきたいポイントをまとめます。
いきなり全社データをdbt化する必要はありません。まずは1つのユースケースで型を作り、社内で書ける人を1〜2人残すところまでを最初のゴールにするのが、投資対効果の高い進め方です。
株式会社Evastでは、BigQuery / Snowflake + dbt を中心としたデータ基盤の設計・構築から運用定着までを一貫して支援しています。広告・小売・外食チェーンなど、dbtで変換ロジックを整理し社内で運用が回る状態を作る案件が中心です。
現状のDWHとdbtの利用状況の棚卸しからで構いません。自社に合う進め方を知りたい方は、データ活用の無料診断もご利用ください。
データ基盤モダンデータスタックは2026年も主流だが、Fivetran＋Snowflake＋dbt＋Lookerのフル構成は月146万円超の重装備。中堅の現実解はBigQuery＋TROCCO＋dbt Coreで月20〜80万円に収まる。5層構成・費用差・Agentic Data Stackへの移行を実装現場から整理。
データ基盤SnowflakeからBigQueryへの移行費用と工程を、稟議にそのまま使える形で整理。2026-04 GAのBigQuery Data Transfer Service、SQL方言差、判断基準、失敗パターンまで。10TB規模で初期1,200万〜2,500万円、期間3〜4ヶ月が目安です。
データ基盤Snowflake導入支援を外部に頼む場合の費用と進め方を発注者目線でまとめました。PoC・スモールスタートは100万〜400万円・4〜8週間、本格構築は400万〜1,500万円・3〜6か月が2026年時点の相場です。支援内容の内訳、内製と外注の分担、失敗しない会社選びの判断軸まで、DWH選定を終えて「何をどこまで頼むか」で迷う情シス・データ責任者向けに解説します。
