dbt Fusionとは、dbt LabsがRustで作り直したdbtの実行エンジンです。2026年9月15日の正式版（GA）でdbt v2となり、名前も「dbt」に変わりました。この記事では、2026年11月時点の公式ドキュメントとPyPIの実測をもとに、改称の経緯、dbt OSSやdbt-core 1.12との違いとライセンス、インストールとドライバー取得の注意点、dbt-autofixを使った移行手順、移る条件と1.12系に残る条件までを、コマンド付きで整理しました。
まとめ：dbt Fusionは2026年9月から無償の「dbt」本体、Coreとはライセンスで分かれる
dbt Fusionという製品名は、もう公式の表記から外れています。旧Fusionエンジンは「dbt」、オープンソースのdbt Core v2は「dbt OSS」と呼ばれ、どちらも2.0.11（2026年11月3日公開）が最新です。
違いの中心はライセンスです。dbtは社内利用なら無料・人数無制限ですが、Apache 2.0ではなく独自のdbt Product Licensing Agreement（PLA）で提供されます。SQLの解析、リンター、VS Code拡張のLSPはdbtだけの機能です。
移行はdbt-coreを1.12へ上げ、--use-v2-parserとdbt-autofixで非推奨の記述を片付けてから進めます。接続先がSnowflake・BigQuery・Databricks・Redshiftなら移行を検討し、PostgreSQLやSQL Serverなら当面は1.12系に残る、というのが2026年11月時点の結論です。
dbt Fusionの正体：Rust製エンジンがdbt v2の既定版になるまでの経緯
検索すると「Fusion」「dbt v2」「dbt OSS」が混在して出てきます。まず時系列と配布物を切り分けます。
2025年5月のベータ発表から2026年9月のGAと改称までの時系列
dbtのライセンスFAQによると、Fusionエンジンの発表は2025年5月28日です。当初はElastic License 2.0（ELv2）でしたが、2026年6月1日にコードがオープンソースのリポジトリへ移されてApache 2.0となり、同時に完全版向けのPLAが導入されました。ELv2は、競合サービスとしての提供を防ぐことを優先しないという理由で廃止されています。
2026年9月15日にはdbt v2がGAとなり、名称が「dbt」と「dbt OSS」に整理されました。翌16日の公式ブログdbtとdbt OSSの違いは、dbtを「ほぼすべての人が使うべき既定版」と位置づけています。2025年の記事にある「パブリックベータ」「ELv2」は、どちらも過去の情報です。
dbt・dbt OSS・dbt-core 1.12の3配布物とライセンスの違い
PyPIで2026年11月11日に実測した版と、公式ブログの機能比較表をまとめました。
| 配布物 | 最新版 | ライセンス | SQL解析・リンター・LSP | dbt Mesh・Catalog |
|---|---|---|---|---|
| dbt（旧Fusion） | 2.0.11 | PLA（無償） | あり | 使える |
| dbt-oss（旧Core v2） | 2.0.11 | Apache 2.0 | なし | 使えない |
| dbt-core（1.x） | 1.12.6 | Apache 2.0 | なし | 使えない |
dbtとdbt OSSは同じ言語仕様とコードベースを共有し、dbt buildの結果は同じになると公式ブログは説明しています。dbt OSSを選ぶのは、社内規程でApache 2.0のソフトウェアしか使えない場合か、dbtの動作を改変・フォークしたい場合に限られます。開発者の手元はdbt、本番の実行環境だけdbt OSSという組み合わせも可能です。
dbt FusionとCoreの違い：ADBCドライバー・静的解析・新コマンドの実装差
名前が変わっただけではありません。実行の仕組みと、使えるコマンドが変わっています。
Pythonアダプターをやめ単一バイナリとADBCドライバーで接続する仕組み
Upgrading to v2（2026年10月29日更新）によると、v2はRustで書き直された単一のバイナリで、実行にPythonのランタイムを必要としません。DWHへの接続は、1.x系のdbt-snowflakeのようなPythonライブラリではなく、ADBCドライバーが担います。
ドライバーはバイナリに同梱されていません。初回実行時にdbt LabsのCDNから取得してキャッシュし、以降はオフラインでも動きます。1.x系で必須だったpip install dbt-<アダプター名>は不要になり、profiles.ymlのtypeに応じて必要なドライバーだけが入ります。
対応アダプターは、BigQuery・Databricks・Redshift・Snowflakeの4製品に、ClickHouse（非公開ベータ）、Apache Spark（CLIのみのベータ）、DuckDB（CLIのみ）が加わります。PostgreSQLとSQL Serverは一覧にありません。
static_analysisのbaselineとstrictで変わる列と型の検証範囲
Fusionの中核は、SQLを文字列ではなく構文として読む静的解析です。既定のbaselineはコンパイル時にSQLの構造を解析し、問題を警告として出して実行は止めません。strictにすると、実行前に列の型とプロジェクト全体の参照を検証します。
# dbt_project.yml
models:
shop_dbt:
+static_analysis: strict # 既定は baseline
strictは、列単位のリネージ（column-level lineage）を表示する前提条件でもあります。一度に全モデルへ掛けるとエラーが大量に出るので、新しく作るマートのフォルダから順にstrictを付けていく方が現実的です。なおonとunsafeはstrictの非推奨の別名で、将来削除されます。
dbt lint・dbt check・バッチテストなどv2だけで使える新コマンド
v2では、1.x系に無かったコマンドが本体に入りました。追加ツールなしで使えるものを、運用で効く順に並べます。
dbt lint：SQLFluff互換のリンター。既存の.sqlfluff設定とCP01などのルールコードをそのまま読み、--fixで自動修正する--batch-tests：テストをまとめて発行する。公式の社内計測ではテスト時間40%減、クエリ数65%減dbt check：checks/に置いたSQLのルールを実行する。dbt buildでも自動で走るdbt freshness：ソースに加えてモデルの鮮度もまとめて検査する
変更点はほかにもあります。dbt buildはユニットテストをすべて先に実行してから残りのDAGを処理するようになりました。SnowflakeとDatabricksでは並列数をdbtが自動で調整し、threadsは上限値として扱われます。
dbt Fusion導入：pip・Homebrew・wingetとドライバー取得
ここからはpip・Homebrew・wingetで本体を導入し、接続に必要なドライバーを取得する手順です。1.x系の環境とは分けて入れます。
OS別のインストールコマンドとdbt –versionでの導入確認
Install dbtが案内する導入方法は5通りあります。社内で手順をそろえるなら、Pythonの有無に左右されないHomebrewかwingetが扱いやすい方法です。
# pip（PyPIのdbtはPython 3.10以上を要求する）
python -m pip install dbt
# macOS
brew tap dbt-labs/dbt
brew install dbt-labs/dbt/dbt
# Windows
winget install --id dbtLabs.dbt --exact
# 導入の確認と更新
dbt --version
dbt system update # curl・PowerShellのインストーラーで入れた場合
注意点は、dbt OSSやdbt-core 1.x系と同じPython環境に入れないことです。どれもdbtという同名のコマンドを提供するため、PATHの先にある方が動きます。dbt --versionの表示が2.0.xであることを確かめてから先へ進みます。
プロキシ環境でのドライバー取得：CDNの許可とinstall-drivers
企業ネットワークで最初につまずくのが、ドライバーの取得です。dbt v2のネットワーク要件は、public.cdn.getdbt.comの許可に加えて、そのドメインから.dll・.so・.dylibのネイティブライブラリをダウンロードできるようにすることを求めています。ドメインを許可しても、プロキシのコンテンツ検査がライブラリを止める例があるからです。
# 社外に出られる端末で、全ドライバーを先に取得してキャッシュする
dbt system install-drivers
# 取得対象: Snowflake・BigQuery・Postgres・Databricks・Redshift・DuckDB
完全に閉じた環境では、バイナリとドライバーを束ねたtar.gzかDockerイメージを社内に置き、SHA-256のチェックサムで検証してから配る方法が示されています。匿名の利用統計はp.vx.dbt.comへ送られ、到達できない場合は、実行のたびにログへエラーが出る仕組みです。許可しない方針なら、利用統計を無効にしておきます。
VS Code拡張とdbt loginで使える機能の範囲と制約
Fusionの恩恵を一番受けやすいのは、エディタ上の開発体験です。dbtのVS Code拡張は無料で、refやマクロの補完、定義への移動、コンパイル後のSQLやCTE単位のプレビュー、テーブル単位のリネージ表示がログインなしで使えます。
dbt loginが要るのは、dbt platformのデータを読むCatalogタブと、本番環境を参照した変更比較だけです。拡張は2026年9月15日の改訂でPLAの対象になり、以前の15ユーザーの上限は撤廃されました。SSH経由のリモート開発には未対応なので、踏み台サーバー上でdbtを動かしているチームは注意が要ります。
dbt Core 1.xからFusionへ移行する手順と解析器・非推奨記述の修正
移行の作業は、1.x系の環境のまま大半を済ませられます。
dbt-core 1.12へ上げて–use-v2-parserでv2の解析器を試す手順
最初の作業は、dbt-coreを1.12系へ上げることです。1.12には、解析器だけをv2に切り替える--use-v2-parserフラグがあり、ほかの動作を変えずにv2で読めるかを確かめられます。1.12系のインストールとprofiles.ymlの設定はdbt Coreの使い方で手順を解説しています。
python -m pip install "dbt-core~=1.12.0" "dbt-snowflake~=1.12.0"
dbt parse --use-v2-parser
# 警告とエラーが0件になるまで、次のh3の手順で直す
v2のマニフェストはv12で、1.x系との互換性を備えた形式です。そのためstate:modifiedや--deferは、1.x系とv2が混在する期間も動きます。CIだけ先にv2へ切り替え、本番は1.12のまま様子を見るという段階的な移行が取れます。
dbt-autofixで非推奨記述とパッケージ依存を修正する実行手順
非推奨の記述は、dbt Labsが公開するdbt-autofix（Apache-2.0、2026年11月時点の最新は0.22.6）でまとめて直します。必ずGit管理下で、差分を確認してから実行します。
# 変更内容だけを確認する
uvx dbt-autofix deprecations --path . --dry-run
# 適用する（挙動が変わる修正も含めるなら --all）
uvx dbt-autofix deprecations --path .
# packages.yml を v2 対応版へ更新し、依存を入れ直す
uvx dbt-autofix packages --path .
dbt deps
deprecationsは、モデルのプロパティをconfig:の下へ移す、独自のキーをmetaへ移す、-mを-sへ書き換えるといった修正を行います。--include-packagesでパッケージ内まで直すこともできますが、次のdbt depsで元に戻るため、恒久対応はパッケージ自体の更新です。require-dbt-versionが">=1.10.0,<3.0.0"のように2.0を含むパッケージはv2対応で、dbt_utilsやdbt_project_evaluatorは対応済みです。
v2でエラーになる–models・未定義マクロ・YAMLアンカーの直し方
v1では無視されたりdbt compileまで見逃されたりした記述が、v2では解析の段階でエラーになります。自動修正で残りやすい箇所は次の4つです。
--models・-m：エラーになる。ジョブ定義やシェルスクリプトも--selectへ書き換える- 存在しないマクロ・変数・generic testの呼び出し：
dbt parseで失敗する - YAMLの最上位に置いたアンカー：未知のキーとしてエラーになる。
anchors:の下へ移す metaだけにあるキーのconfig.get()：値が返らない。config.meta_get()へ置き換える
# models/schema.yml（v2で通る書き方）
anchors:
- &id_column
name: id
data_tests:
- not_null
- unique
手で直した箇所は、非推奨の一覧と突き合わせてからdbt parseを再実行します。ローカルパッケージとdbt Hubのパッケージで版指定が食い違う場合もエラーになるため、packages.ymlの版は完全一致で書きそろえます。
dbt Fusionへ移る条件と1.12系に残る条件：接続先とライセンス規程
最後に、自社の基盤でどちらを選ぶかを決めます。
dbt Fusionへ移る条件とdbt-core 1.12系に残る条件の分かれ目
移るべきなのは、接続先が対応アダプターの4製品のどれかで、モデル数が増えてコンパイル待ちや列名の誤りによる手戻りが目立つチームです。静的解析とVS Code拡張の補完だけでも、開発中の失敗の多くが実行前に見つかります。
見送るのは、PostgreSQLやSQL Serverを変換先にしている基盤、dbt-autofixで直らない古い書き方のマクロを大量に抱えるプロジェクト、SSH越しのリモート開発が前提のチームです。公式ブログによると、1.13が機能を追加する最後のマイナー版で、セキュリティとインストールの修正は3〜5年続く見込みです。急いで移る理由はありません。
料金がかかるのはdbt platformのMeshやCatalogなどを使う場合で、プラン別の試算はdbt 料金の全体像で整理しています。移行の工数見積もりや、取り込みからBIまでを含むデータ基盤の再設計を任せたい場合は、一創のデータ分析基盤構築・MLOps構築支援でご相談を受けています。
顧客向けデータ基盤に組み込む前に確かめるPLAの3つの制限と例外
社内のデータ基盤で使う限り、PLAの制限はほぼ関係しません。注意が要るのは、受託や自社サービスとして顧客にdbtの実行環境を提供する場合です。ライセンスFAQは、次の3点を禁止しています。
- dbtを組み込んだ製品を、顧客がログインせずに使える形で提供すること
- ログイン機能の回避や、非公開のソースコードの導出
- ライセンス表示や商標・著作権表示の削除
マネージドサービスとして提供すること自体は、エンドユーザーがdbtの全機能を使え、ログインと有料機能の利用を妨げなければ認められています。この条件を満たせない構成では、Apache 2.0のdbt OSSを使えばPLAは適用されません。その場合も商標ポリシーは守ります。
よくある質問
dbt Fusionについて、検索でよく見かける疑問に答えます。
dbt Fusionは無料で使えますか？
使えます。dbt（旧Fusion）は社内利用なら無料で、ユーザー数の上限もありません。ライセンス上の注意は、Apache 2.0ではなくPLAという独自ライセンスである点だけです。費用が発生するのは、dbt platformのdbt MeshやCatalogなどのシート課金機能と、dbt StateやWizardなどの従量課金機能を使う場合です。DWHの利用料は別にかかります。
dbt Fusionはどのデータベースに対応していますか？
2026年10月29日更新の移行ガイドでは、BigQuery・Databricks・Redshift・Snowflakeが対応済みです。ClickHouseは非公開ベータ、Apache SparkはCLIのみのベータ、DuckDBはCLIのみの対応です。dbt system install-driversはPostgresのドライバーも取得しますが、移行ガイドの対応アダプター一覧にPostgreSQLは載っていません。PostgreSQLの基盤は1.12系で運用を続けます。
dbtfコマンドとdbtコマンドの違いは何ですか？
同じものです。curlのインストーラーは~/.local/bin/dbtにバイナリを置き、シェルの設定ファイルにalias dbtf=$HOME/.local/bin/dbtを追加します。dbtfは常にこのバイナリを指すため、PATHの先に1.x系のdbtがある端末でもdbtfならv2が動きます。混乱を避けるなら、仮想環境を分けたうえでdbt --versionで版を確かめてから実行してください。
dbt Fusionで処理はどのくらい速くなりますか？
公式が数値を出しているのはテストです。移行ガイドによると、バッチテストを有効にした社内計測でテストの実行時間が40%、発行クエリ数が65%、テストにかかるDWHの費用が15%減りました。モデルの実行時間はSQLを処理するDWH側で決まるため、エンジンの置き換えで縮むのは主に解析とコンパイルの待ち時間です。
dbt Fusionへ移行したあと1.x系に戻せますか？
1.x系への切り戻しは可能です。v2のマニフェストはv12で1.x系と互換があり、v2だけの項目は1.x系が無視します。dbt-autofixの修正は1.x系で出ていた非推奨警告を解消するものなので、適用後は1.12系のdbt parseが通ることを確かめておけば、切り戻し先として使えます。移行の初期は本番を1.12系に残し、CIと開発者の手元だけをv2にする並行運用から始めると切り戻しが容易です。
関連記事
- dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方【2026年版】：dbtの仕組みと採用判断
- dbt Coreの使い方：インストールからprofiles.yml・dbt build・CIまでの手順【1.12対応】：移行前に整える1.12系の手順
- dbtのmarts層とは？3層の分け方とMetricFlowで指標を定義する手順【dbt 1.12対応】：strictを付ける前のレイヤ設計
- Fivetranとは？ELTの仕組み・MAR課金・dbt統合後の構成を実装視点で解説【2026年版】：合併後の取り込み側との役割分担
- DuckDBの使い方：インストールからCLI・Python・ファイル読み込みまでの手順【1.5.6対応】：v2をCLIで試す接続先
