2026.11.08 AI

dbt 料金の全体像：無料枠・Starter・Enterpriseの費用を規模別に試算【2026年版】

dbtの料金は、使う人の数（シート）と、本番で成功したモデルのビルド数の2軸で決まります。オープンソースの dbt Core を自前で動かすなら利用料はかからず、マネージド環境の dbt platform（旧 dbt Cloud）では無料のDeveloperから1シート月100ドルのStarter、年額契約のEnterpriseへと段階が上がる仕組みです。この記事では2026年11月時点の公式pricingと課金ドキュメントをもとに、課金されるビルドとされないビルドの区別、上限を超えたときの挙動、チーム規模別の月額試算、そしてdbtの請求書に載らないDWH側の計算料金までを整理しました。払うべき条件と払わなくてよい条件も、数字つきで言い切ります。

まとめ：dbtの費用はシート数とモデルビルド数とDWH計算料金の3つで決まる

1人で月3,000ビルド以内に収まるならDeveloperプランで0円、2〜5人のチームで月15,000ビルド以内ならStarterで「人数×月100ドル」が実額です。SSO・権限管理・複数プロジェクトが要件に入った時点でEnterpriseの個別見積りへ進みます。

見積りで外しやすいのは2点あります。1つは、viewもCIのビルドも課金対象に数えられること。もう1つは、DWH側の計算料金がdbtとは別の請求書で発生することです。毎時実行のような高頻度運用では、プラン選びより先にジョブ設計で両方を減らす方が効きます。

dbt Coreとdbt platformの料金体系・2026年11月時点のプラン別上限値

最初に、どの形態でいくら払うのかを公式の数字で確定させます。dbt全体の仕組みや導入判断はdbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方で扱っているので、ここでは費用に絞ります。

4プランの価格・シート・月間モデルビルド数とプロジェクト数の上限比較

dbtの公式pricingページに掲載されている内容を、2026年11月8日時点で表にしました。

プラン	価格	シート	月間モデルビルド	月間クエリメトリクス	プロジェクト
Developer	無料	1	3,000	記載なし	1
Starter	1シート月100ドル	5	15,000	5,000	1
Enterprise	個別見積り（年額）	個別	100,000	20,000	30
Enterprise+	個別見積り（年額）	個別	100,000	20,000	無制限

機能差で費用に響くのは、StarterでCatalogのリネージ・Semantic Layer・APIアクセスが加わり、EnterpriseでSSO・ロールベースの権限管理・SCIM・複数プロジェクト構成（dbt Mesh）が加わる点です。Enterprise+ではPrivateLinkとIP制限が付きます。Starterの決済はクレジットカードの月額払いに限られ、請求書払いはEnterpriseだけ。経理の支払い手段が請求書に限られる会社では、この1行がプラン選択を決めてしまうことがあります。

dbt Coreを自前で実行する場合にライセンス費用が発生しない範囲と条件

dbt Core はオープンソースで、自社のサーバーやCI上でコマンドを実行する限り、dbt Labsへの支払いは発生しません。シート数の制限もモデルビルド数の上限もない。代わりに、スケジューラ、実行ログの監視、ドキュメントの公開、権限管理を自分たちで用意します。

注意したいのはライセンスの読み方です。dbt Core のGitHubリポジトリはソースコードをApache 2.0で公開していますが、v2.0系のmainブランチでは、dbt Labsが配布する「dbt」のディストリビューションには別の製品ライセンスが適用されると説明されています。社内の法務確認が必要な会社では、ソースからビルドするのか配布物を使うのかを決めてから利用条件を読むと、確認の手戻りが減ります。

課金対象になるモデルビルドの定義と上限を超えたときの請求と停止の挙動

プラン表の数字だけで見積もると、何を1ビルドと数えるかで桁がずれます。公式ドキュメントの課金の仕組み（2026年10月8日更新）に書かれた定義を、実務の言葉に直します。

課金されるビルドとされないビルドの区別：testやseedやIDE実行は対象外

課金単位の「Successful Model Built」は、本番などのデプロイ環境で、dbtのオーケストレーション経由で成功したモデルを指します。スケジューラのジョブ、プルリクエストで起動するCIビルド、APIから起動した実行のすべてが含まれる。

数える：view、table、incremental の各マテリアライゼーション
数えない：ephemeral モデル、test、seed、snapshot
数えない：Studio IDE など開発環境でのビルド

見落としやすいのはviewです。テーブルを作らないので軽い処理に見えますが、1回の実行で1ビルドとして数えられます。もう1つ、ジョブが途中で失敗した場合も、それまでに成功したモデルは課金の対象です。公式の例では、100モデルのジョブが51モデル目の後で止まった場合、51ビルドが計上されます。

無料枠3,000ビルド超過で実行停止、Starterは翌月請求となる挙動の違い

上限を超えたときの扱いは、無料と有料で正反対です。公式のPlans and billing（2026年7月23日更新）によると、Developerプランは月3,000モデルを超えると、月が切り替わるか有料プランへ移るまで以降の実行がキャンセルされます。IDEなど他の機能は使えて作業内容も消えませんが、日次の本番ジョブは止まる。

Starterはブロックされません。15,000を超えた分は追加利用として翌月の請求書に後払いで加算されます。超過1ビルドあたりの単価は、pricingページにも課金ドキュメントにも2026年11月時点で記載がありません。超過が常態化しそうな運用なら、契約前に営業窓口で単価を確認し、見積書に残しておくべきです。

シート料金の前払いと月途中の追加・削除の日割りルールと繰り越し不可

Starterのシート料金は月初に前払いです。月の途中で人を足すとその場で日割り請求され、途中で外した分は次回請求に反映されるだけで返金されません。プロジェクトの繁忙期だけ一時的に増員する使い方は、思ったほど安くならない計算です。

含まれる15,000ビルドのうち使わなかった分は、翌月へ繰り越せません。2023年8月11日より前に旧Teamプランを購入したアカウントは、契約が良好な状態にある限り旧料金体系を続けられます。旧Teamから乗り換えると条件が変わるため、移行前に現在の請求内容を控えてから比較してください。

チーム規模とモデル本数とジョブ実行頻度から月額費用を見積もる試算手順

ここからは、自社の数字を当てはめて月額を出す手順です。試算はすべて、各ジョブが対象モデルを毎回全件ビルドする前提で置いています。

月間モデルビルド数をモデル本数×実行回数×日数とCIで見積もる計算式

本番ジョブのビルド数は「課金対象モデルの本数×1日の実行回数×月の稼働日数」で概算できます。課金対象モデルはview・table・incrementalの合計で、ephemeralとseed・snapshotは除きます。

ここにCIの分を足します。プルリクエスト1件ごとに、変更したモデルとその下流がビルドされるので「月のプルリクエスト件数×1件あたりのビルド対象モデル数」で見積もる。CIを全件ビルドにしていると、この項がいきなり本番ジョブと同じ桁に膨らみます。

1人・60本の日次運用から4人・200本の毎時運用までの3パターン試算

代表的な3つの規模で計算しました。円換算は仮に1ドル150円で置いた参考値です。

規模	本番ジョブ	CI	月間ビルド	該当プラン	月額
1人・60本・日次1回	60×1×30＝1,800	10件×10本＝100	1,900	Developer	0ドル
3人・150本・日次1回	150×1×30＝4,500	30件×20本＝600	5,100	Starter	300ドル（約4万5,000円）
4人・200本・平日10回	200×10×22＝44,000	40件×20本＝800	44,800	Starter＋超過	400ドル＋超過29,800ビルド分

3つ目は、シート代より超過分の方が読めない構成です。仮に200本のうち120本がviewで、それを本番の毎時ジョブから外せれば、本番分は80×10×22＝17,600まで下がります。それでも15,000は超えるため、毎時実行するのは鮮度が要るmarts層だけに絞る、といったジョブ分割まで踏み込んで初めてStarterの枠に収まります。

Semantic Layerのクエリ課金が発生する条件と月5,000件の上限の目安

Semantic Layerを使う場合は、もう1つの課金単位「Queried Metric」が加わります。Semantic Layer APIへの成功したリクエストが、指標1つにつき1件。dbt sl query --metrics revenue,gross_salesのように2指標を一度に引けば2件と数え、メタデータの取得は数えません。

BIダッシュボードから指標を引く構成では、閲覧者が開くたびにクエリが走ります。指標10個のダッシュボードを1日25回開けば、平日22日で5,500件となり、Starterの月5,000件を1枚で超える計算です。指標定義の考え方はセマンティックレイヤーとは何かと導入判断、OSSのBI側で指標を扱う選択肢はdbtで指標を定義するOSS BIのLightdashで比較できます。

dbtへの支払いとは別に発生するDWH計算料金とセルフホスト運用の費用

dbtの請求額だけを比べてプランを決めると、総額を見誤ります。dbtは変換のSQLをDWHへ投げるだけで、計算そのものはDWHが行うからです。

DWH側の計算料金はdbtの請求書に載らず、実行回数に比例して増える構造

Snowflake・BigQuery・Databricks・Redshiftのどれを使っても、dbtのジョブが走るたびにDWH側で計算資源の料金が発生します。この費用はdbt Labsではなく各DWHの請求書に載るため、dbtのUsage画面を見ていても気付けない。

前の試算で日次1回を平日10回に増やすと、dbtのビルド数が約10倍になるのと同時に、DWHの計算量もほぼ同じ比率で増えます。実行頻度を上げる判断は、dbtのプランとDWHの料金をセットで見積もり直す判断です。抽出・ロード側の従量課金も含めた基盤全体の費用構成は、データ分析基盤の構成要素と費用・内製と外注の判断基準にまとめています。

dbt CoreをGitHub Actionsで回す場合のランナー費用と運用工数の内訳

dbt Core を自前で定期実行する典型は、GitHub Actionsのスケジュール実行です。GitHub Actionsの課金ドキュメントによると、パブリックリポジトリの標準ランナーは無料で、プライベートリポジトリではLinux 2コアが1分0.006ドル。1回15分のジョブを毎日回しても月450分、2.7ドルにすぎません。

ランナー代は誤差です。費用の本体は人の時間にあります。ジョブ失敗時の通知、実行履歴の保管、ドキュメントの社内公開、CIでの変更差分ビルド、アダプタやdbt本体の更新を自分たちで組み、保守し続ける工数が、Starterのシート代と比較すべき相手です。

モデルビルド数とDWH計算料金を減らすジョブ設計と設定変更の具体策

プランを上げる前に、ジョブ設計で減らせる分を先に削ります。公式のコスト削減ガイド（2026年8月12日更新）に載っている手段のうち、効果が大きい順に2つ取り上げます。

viewを本番ジョブから外すセレクター設定と変更分だけ再ビルドする運用

マクロでSQLを動的に組み立てておらず、テストも無いviewは、定義が変わらない限り作り直す必要がありません。dbt 1.12以降では、次のセレクターをselectors.ymlに置くと、viewのビルドを外しつつviewへのテストは実行できます。

selectors:
  - name: skip_views_but_test_views
    description: "viewの再作成を外し、viewへのテストは残す"
    default: true
    definition:
      union:
        - union:
            - method: path
              value: "*"
            - exclude:
                - method: config.materialized
                  value: view
        - method: resource_type
          value: test

ジョブ側ではdbt build --select selector:skip_views_but_test_viewsで呼び出します。定義を変えたviewは、マージ後にdbt run -s state:modified+を実行するMerge Jobで、前回の実行状態と比較して作り直す。この2段構えで、viewの本数×実行回数の分がまるごと消えます。

Insightsタブで遅いモデルを特定しincrementalへ移す順番の決め方

ビルド数とは別に、DWHの計算料金を押し上げるのは実行時間の長いモデルです。ジョブ画面のInsightsタブには各モデルの直近20回の平均実行時間が出るので、上位から順に手を付けます。

行数が多く、過去分が書き換わらないファクトテーブルは、毎回作り直すtableから差分だけを足すincrementalへ移すと計算量が下がります。ただしincrementalでも1回の実行で1ビルドと数える点は変わらないため、ビルド数を減らす手段ではありません。ビルド数はジョブ設計、計算料金はモデル設計と、効く場所を分けて考えてください。層ごとのモデルの切り方はdbtのmarts層と3層の分け方が参考になります。

dbt platformへの支払いを決める条件とStarterで止めてよいチームの境界

ここまでの数字をもとに、どこで払い、どこで払わないかを条件で切ります。

Starterで十分な条件と、Enterpriseが必要なSSO・複数プロジェクト要件

Starterで止めてよいのは、開発者が5人以内、dbtプロジェクトが1つ、月間ビルドが15,000前後に収まるチームです。データ基盤を1部門で持ち、本番ジョブが日次中心ならこの条件にほぼ入ります。

Enterpriseへ進むべき条件は、費用ではなく要件で決まります。社内規程でSSOとロールベースの権限管理が必須になっている、部門ごとにプロジェクトを分けてdbt Meshで参照し合いたい、請求書払いしか通らない。このどれか1つでも当てはまるなら、Starterでの運用はいずれ止まるので、最初からEnterpriseの見積りを取る方が早く済みます。

有料プランに払わずdbt Coreで回すべき条件と払った方が安くなる条件

dbt Coreで回すべきなのは、GitHub ActionsなどのCIとワークフロー基盤がすでに社内で動いていて、それを保守している担当がdbtの面倒も見られる場合です。加えて、ビルド数が月15,000を大きく超える毎時運用なら、ビルド単位の課金そのものを避けられるCoreの方が総額は読みやすくなります。

逆に、CI基盤を新たに組むところから始めるなら、Starterに払った方が安い。スケジューラ・CIチェック・IDEの準備と保守を内製すると、1人の工数が月数日は消えます。3人チームで月300ドルのStarterは、その人件費より明らかに小さい額です。

dbt導入費用を内製で抱えるか受託開発に切り出すかを決める人件費の視点

dbtの費用で最も大きいのは、プラン料金ではなく、モデル設計とジョブ設計を担う人の時間です。SQLを書ける担当が2人以上いて、上で見たviewの除外や差分ビルドを自分たちで設計できるなら、内製でプラン料金だけを払う形が最も安く済みます。

SQLの担当が1人しかいない、DWHの選定や既存ETLからの移行も同時に進める、という状況では、設計の初期段階だけでも外部に任せた方が総額は下がります。最初のジョブ設計を誤ると、毎月のビルド超過とDWH計算料金として払い続けることになるからです。当社のデータ分析基盤構築・MLOps構築支援では、DWHとdbtの構成設計からジョブ設計、運用の引き継ぎまでを請けています。

よくある質問

dbtの費用を見積もる段階で出てくる質問を、5つに絞って回答します。

dbtのテストを実行した分も料金に含まれますか？

含まれません。公式の課金ドキュメントでは、test・seed・snapshot・ephemeralモデルはモデルビルドとして数えないと明記されています。テストを手厚くしても、dbt platformの請求額は増えない仕組みです。ただしテストもSQLとしてDWH上で実行されるため、DWH側の計算料金は発生します。テストを増やすときは、dbtの請求額ではなくDWHの請求額の変化を確認してください。

無料のDeveloperプランで月3,000ビルドを超えるとどうなりますか？

超えた後の本番ジョブの実行がキャンセルされます。追加料金が自動で請求されることはありませんが、月が切り替わるか有料プランへ移るまで定期実行が止まります。IDEでの開発や作成済みの資産は、そのまま引き続き利用可能です。モデル60本を日次で回す程度なら月1,800ビルドで収まるため、CIで全件ビルドをしていないかを先に確認すると、枠内に収まることが多いです。

Enterpriseプランの料金はどのくらいですか？

公式には公開されておらず、個別見積りです。pricingページでは、Enterpriseは開発者シート数と成功したモデルビルド数をもとに年額で請求されると説明されています。見積りを取る前に、必要なシート数、月間ビルド数の試算、SSOやdbt Meshなど必要な機能の一覧を揃えておくと、比較できる見積りが返ってきます。契約後の変更は管理画面ではなく営業担当経由です。

旧Teamプランを契約していると料金は変わりますか？

2023年8月11日より前に旧Teamプランを購入したアカウントは、契約が良好な状態にある限り、旧料金体系を続けられると公式ドキュメントに記載されています。旧体系はシート数ベースで、モデルビルド数は合理的な利用の範囲で無制限とされています。現行のStarterへ移ると月15,000ビルドの枠と超過課金が付くため、ビルド数が多いチームは移行前に試算してください。

dbt platformの使用量はどこで確認できますか？

アカウント設定のBilling／Usage画面で、当月の推定使用量とビルド数の多いプロジェクトを確認できます。Starterでは見られるのはOwnerグループのみです。ジョブ詳細のInsightsタブでは、ジョブごとの月間ビルド数と時間のかかるモデルが分かります。画面の値は推定値で反映が遅れることがあり、確定値は月次の請求書に載ります。課金の集計はUTC基準です。