dbt CoreとCloudは何が違う?1枚図で整理

dbt CoreはApache 2.0ライセンスで公開されているオープンソースのCLIツールです。ターミナルから dbt run と叩けば、書いた変換SQLをDWH上で順に実行してくれる、その本体だけを提供します。
一方のdbt Cloudは、同じOSS本体をSaaSで包んだサービスです。ブラウザ上のIDE、ジョブスケジューラ、Pull Request単位のCI、ドキュメントホスティング、Slack通知、SSOといった「dbtを組織で運用するときに周辺で必要になる部品」をまとめて提供します。
Model / ref / test変換ロジック本体
+自前で用意
実行基盤(EC2 / Cloud Run など)
スケジューラ(Airflow / Cron)
CI/CD(GitHub Actions)
ドキュメント公開(S3 / GitHub Pages)
通知・監視(Slack Webhook)
Model / ref / testCoreと同じOSS本体を実行
+SaaS側で提供
ブラウザIDE(dbt Studio)
ジョブスケジューラ
PR単位のCI(Slim CI)
ドキュメントホスティング
Slack / メール通知
Semantic Layer / dbt Catalog(プラン別)
変換ロジック本体(Model・ref・test)は共通。dbt Cloudは実行基盤・IDE・スケジューラ・ドキュメントホスティングをまとめてSaaS化したラッパー図のように、緑色の「Model / ref / test」の部分、つまり変換ロジックそのものはどちらでも同じコードが動きます。CoreからCloudに移行するときも、SQLファイルの書き換えは基本的に不要です。違いは「周辺の部品を自前で組むか、SaaSに任せるか」の一点に集約されます。
dbtが担う「T(変換)」の位置づけや、モダンデータスタックの中での役割については、モダンデータスタックとは?2026年の構成例と費用を参照してください。
「同じOSS本体が動く」ことの意味
この事実は、選定の議論を大きく単純化します。「dbt Cloudのほうが機能が多い/少ない」という比較は、正確には「dbt Cloudには周辺の運用機能がバンドルされている」と言い換えるべきです。
たとえばdbt Coreでも、Airflowを立てればスケジューラは持てます。GitHub Actionsを組めばCIも走ります。ドキュメントもS3に静的ホスティングすれば公開できます。つまりCoreで「できないこと」はほとんどなく、あるのは「自分たちで作る/運用する必要があるかどうか」の差だけです。
この理解を持たずに「Cloudにしか機能がないから」と選ぶと、必要のない上位プランを掴んでしまう可能性があります。逆に「Coreは無料だから」と選ぶと、後述する見えないコストで足を掬われます。
dbt Cloudの料金プラン(2026年版)

2026年時点のdbt Cloudの料金プランは、次の4段階で構成されています(すべて年契約が基本)。
| プラン | 料金(1シート/月) | 含まれるシート | モデル実行上限 | プロジェクト数 | 主な追加機能 |
|---|
| Developer | 無料 | 1 | 3,000 モデル/月 | 1 | ブラウザIDE・スケジューラ・MFA |
| Starter | $100 | 5 | 15,000 モデル/月 | 1 | dbt Catalog(基本)・Semantic Layer(基本)・dbt Copilot・API |
| Enterprise | 要相談($200〜) | カスタム | 100,000 モデル/月 | 30 | SSO / RBAC・dbt Canvas・dbt Insights・dbt Mesh |
| Enterprise+ | 要相談 | カスタム | 100,000 モデル/月 | 無制限 | PrivateLink・IP制限・ロールバック・ハイブリッドプロジェクト対応 |
Developerは1名で試すためのフリーミアム枠、Starterは分析チームが数人で運用に入る段階、Enterprise以上は情報システム部門の統制要件(SSO・監査ログ・PrivateLink)が入ってくる大規模組織向け、という棲み分けです。
「モデル実行上限」は何をカウントするのか
dbt Cloudの料金表には「successful models built」という上限が含まれます。これは、月間にdbt Cloud上のジョブで正常に完了したモデル実行回数の合計です。
たとえば50個のモデルを1日1回実行する場合、月間で 50 × 30 = 1,500 モデル/月を消費します。同じ50モデルを1時間ごとに回すと 50 × 24 × 30 = 36,000 モデル/月となり、Developer無料枠の3,000は簡単に超えます。
この上限は、Developerプランで数十モデルを日次バッチする程度なら余裕がありますが、時間単位の実行を始めた瞬間に一気に消費します。実行頻度と対象モデル数の掛け算で試算する癖を付けておくと、プラン選定を誤りにくくなります。
円換算のざっくり目安
2026年8月時点の為替を1ドル150円で換算すると、Starterプランは5シートで最低月額7.5万円($500 × 150円)から。10シートに増やすと月額15万円、Enterpriseで20シートを想定すると相場感で月額60〜120万円($400〜800×20×150円)に到達します。年契約なので、それぞれ12倍が年間の予算感になります。
同様の「発注検討者向け料金整理」のアプローチは、TROCCOとは?料金・評判・代替ツールを中立比較やFivetranの料金を抑えるコスト最適化のポイントでも扱っています。ETL側とTransform側の両方で予算を組むときに、あわせて読んでください。
dbt Coreは「本当に無料」ではない

dbt CoreはOSSでライセンス料はゼロです。ただし、Coreを「業務で継続的に運用できる状態」に持っていくと、次の周辺コストが発生します。
- 実行基盤:EC2 / Cloud Run / GKE / Cloud Composer などのクラウドリソース
- スケジューラ:Airflow / Dagster / Prefect の自前運用、またはCloud Composer利用料
- CI/CD:GitHub Actions / CircleCI の実行時間課金
- ドキュメント公開:S3 + CloudFront / GitHub Pages / Cloudflare Pagesのホスティング
- 通知・監視:Slack Webhook実装、CloudWatch / Datadogでのジョブ監視
- 秘密管理:Secrets ManagerやHashicorp Vaultによる接続情報の管理
- SSO統合:BIツール側で個別にIdP連携する手間
実際にかかる金額の目安
Evastで支援した中規模の案件(モデル数80、日次〜時間バッチ、開発者3名)を例にすると、Core運用時の周辺コストは月に7〜12万円程度でした。内訳の目安は次のとおりです。
- Cloud Composer(Airflow):月4〜7万円
- Cloud Run + Artifact Registry:月0.5〜1万円
- GitHub Actions(有料枠):月0.3〜0.5万円
- ドキュメント公開(S3 + CloudFront):月0.2〜0.5万円
- 監視・ログ・Secrets:月1〜3万円
これに、初期構築での人件費が加わります。Airflow環境の立ち上げからCI/CDパイプラインの整備、ドキュメント公開の自動化までを一通り組むと、Evastの実績ではエンジニア40〜80時間が目安です。時給1万円換算で40〜80万円が初期でかかる計算です。
同じチーム構成をdbt Cloud Starterに置き換えると、5シートで月7.5万円(年間90万円)です。周辺運用の面倒を見なくてよい分、Cloudのほうが実質的に安く済むケースがあるという結論になります。
Coreを選ぶ合理的なケース
とはいえ、Coreが有利なケースも明確にあります。次のいずれかに当てはまるなら、Coreを検討する価値があります。
- 既にAirflow / Dagster等の実行基盤があり、そこに乗せるだけで済む
- BigQuery / Snowflakeのプロジェクトに強い制約があり、外部SaaS経由の接続を避けたい
- モデル数が大規模(数千以上)で、Cloudのモデル上限に収まらない or 割高になる
- 専任のデータプラットフォームエンジニアが1名以上いて、運用工数が確保できる
Airflow / Dagster / Prefectの選び方については、Airflow vs Dagster vs Prefect:データワークフローツールの選び方にまとめています。Core運用を検討するなら、スケジューラ選定は同時に決めることになります。
3パターンで見る、実務での選び方

抽象論だけだと決めきれないので、Evastで実際によく相談される3つのパターンで選び方を整理します。
dbt CoreとCloudどちらを選ぶ?
データエンジニアが1人以上いる?
NO
まずは1人で試したい
PoC
dbt Cloud Developer無料・1シート
5人以下の分析チームで運用
運用
dbt Cloud Starter$100/seat/月
データエンジニアが1人以上いる?
YES
Airflow等の実行基盤が既にある
既存
dbt CoreOSSを既存基盤に組み込む
30人以上・複数プロジェクト・SSO必須
組織
dbt Cloud Enterprise要相談・SSO / RBAC
パターンA:検証・PoCフェーズ(1〜2名)
「まずdbtが自社のデータに合うかを試したい」という段階です。この場合は迷わず**dbt Cloud Developer(無料)**から始めます。
無料でブラウザIDEとスケジューラが使えるので、ローカルにPython環境を作る手間もありません。1シートしかないので同時開発はできませんが、PoC段階で複数人が同時に触る状況は稀です。BigQueryやSnowflakeへの接続を数分で終わらせて、5〜10モデルを動かしてみて、感覚を掴むのに最適です。
「Cloud Developerで詰まったらCoreに移す」ではなく、「Cloud Developerで詰まったらStarterに上げる」ほうが移行コストは小さくなります。
パターンB:分析チーム3〜10名で運用(データエンジニア不在)
分析部門やマーケティング部門のメンバーがSQLを書いてBIを整備している、というよくある構成です。この場合はdbt Cloud Starterが第一候補になります。
理由は3つあります。ひとつめは、ブラウザIDEでGit操作を意識せずに触れるので、非エンジニアの分析メンバーが乗りやすいこと。ふたつめは、PR単位でCIが自動で走るので、モデル変更でBIが壊れる事故を減らせること。みっつめは、月7.5万円(5シート)が固定費で、社内のエンジニアリソースを消費しないこと。
Coreを選ぶと、Airflow運用に強い人が最低1人必要になります。この人材が社内にいないなら、Cloud Starterの月7.5万円は「実質的にエンジニア工数を月半人月ぶん買っている」と考えると割安です。
パターンC:30名以上・複数プロジェクト・SSO必須
情報システム部門の統制が入る規模の組織では、**dbt Cloud EnterpriseまたはEnterprise+**か、Core + 内製の実行基盤の2択になります。
判断軸は「専任のデータプラットフォームチームがいるかどうか」です。データエンジニアが3名以上おり、Airflow / Kubernetes運用の経験があるなら、CoreをKubernetes上で回して既存のIdP・監視基盤に載せるほうがトータルコストは下がります。
一方、専任チームが薄い場合はEnterpriseを選ぶほうが安全です。dbt Meshによる複数プロジェクト分割・SSO / RBAC・監査ログといった機能を1つずつ自前実装するのは、シート単価を大きく上回るコストになります。
データエンジニアリング組織の内製化と外注の判断については、データ基盤は内製と外注のどちらが正解?費用・スピード・ノウハウで比較で扱っています。
dbt導入でよくある3つの誤解

Evastで発注前の相談を受けているときに、繰り返し聞く誤解を3つ挙げます。
誤解1:「無料だからCore」で始めて後で詰まる
Coreの初期学習コストが低く見えるので、非エンジニアが「まずCoreで」と始めて、Airflowの導入で数か月止まる、というパターンをよく見ます。dbt Coreの学習と、Airflowの学習と、CI/CDの整備は別の技術領域です。
「dbtを試したいだけ」なら、Cloud Developerのほうが立ち上げが速いです。無料ですし、後からCoreに移行するのも、同じSQLファイルがそのまま動くので難しくありません。
誤解2:「モデル上限があるから青天井」
dbt CloudのStarterプランは月15,000モデル、Enterpriseは月10万モデルが上限です。一見大きな数字ですが、「モデル数 × 実行頻度」で消費するため、時間バッチを始めた瞬間に一気に減ります。
50モデルを1時間ごとに回すだけで月36,000モデルを消費するので、Starterでは足りず、Enterpriseにジャンプする必要があります。時間バッチが必要な要件が来る前に、日次バッチで済ませられないかを先に検討するのが、コスト最適化の要点です。
誤解3:「dbt Fusionが出たからCoreは終わり」
dbt Labsは2025年にRust製の新実行エンジン「dbt Fusion」を発表しました。既存のCore(Python製)を段階的に置き換える方針で、性能面ではFusionが優れているのは事実です。
ただし、Core本体がすぐEOLになる予定はなく、既存の投資が無駄になるわけではありません。新規プロジェクトを2026年以降に立ち上げるなら、Fusion対応が進むdbt Cloud側で環境を組むほうが、将来の移行コストは抑えやすくなります。
まとめ:価格だけで選ばず「運用工数」を計算する
dbt Coreとdbt Cloudの選択は、ライセンス料だけを比べても答えが出ません。判断のポイントを整理すると次のようになります。
- dbt Coreは本体無料だが、実行基盤・スケジューラ・CI・ドキュメント公開などの周辺コストで月7〜12万円+初期40〜80時間が発生する
- dbt Cloud Starterは5シート月7.5万円で運用一式が入るため、データエンジニア不在のチームでは実質的に割安になりやすい
- Enterpriseが必要かどうかは、専任データプラットフォームチームの有無・SSO / RBAC要件・モデル数で決まる
- モデル実行上限は「モデル数 × 実行頻度」でカウントされるため、時間バッチ設計は早めに固める
- dbt Fusionへの移行を見据えるなら、新規プロジェクトはCloud側で組むほうが将来コストを抑えやすい
Evastでは、BigQueryやSnowflakeでのdbt導入を、Cloud / Coreどちらの構成でも支援しています。「Cloudを検討中だが、Coreとの差額が本当に見合うかを社内説明したい」といった段階でも構いません。データ基盤構築サービスやdbt導入・構築支援の費用と進め方から、まずは相談ベースでお問い合わせください。