dbt platform で dbt Fusion の Snowflake 接続機能が一般提供になったので、移行手順と主要機能を試してみた
はじめに
2026年5月のアップデートで、dbt platform（旧 dbt Cloud）上での Fusion と Snowflake の接続機能（Fusion + Snowflake connection experience）が一般提供となりました。
以下の内容を試してみましたので、こちらの検証内容を本記事でまとめます。
- 非推奨記法（Deprecation）の検出と AutoFix による自動修正
- Fusion エンジンへの切り替えと動作確認
- Fusion 固有の機能の挙動確認
- 静的解析による存在しないカラムのチェック
- Preview CTE
- State-aware orchestration
dbt Fusion の概要
本機能については以下に記載があります。
dbt Fusion engineは、dbt Labs 社が開発したデータ変換のための新しい実行エンジンです。従来の dbt Core エンジンが Python で構築されていたのに対し、Fusion は SDF 社の技術をベースとして Rust 言語で完全に書き直されています。
これにより、パフォーマンスの向上とともに、SQL のコンパイラとしてコードの意味を理解する、という機能が追加されています。
具体的には、dbt Fusion Engineを使用することで、以下のような特有の機能や特徴にアクセス可能になります。
- パフォーマンスの向上
- コンパイル時間の高速化により、大規模なプロジェクトでの処理のもたつきの解消が期待されます
- 高度な開発支援機能
- ライブエラー検出とオートコンプリート：文法エラーや、存在しないカラム・モデルの参照などをエディタ上で検出できます
- Preview CTE：開発中にモデル内で使用される CTE（共通テーブル式）単位でのデータ結果プレビューが可能です
- State-aware orchestration（状態認識オーケストレーション）
- コードの変更や上流のデータの状態をリアルタイムで追跡し、更新が必要なモデルだけを再構築できます
- 変更のない不要な計算処理を自動的にスキップすることで、コンピュートコストの大幅な削減とデータ更新スピードの向上が期待できます
利用方法について dbt platform の場合は、対象プロジェクトの環境設定から Fusion が有効なバージョンにアップグレード・指定することでアクセスが可能です。本機能自体は、dbt Core を利用しているユーザーであっても、ローカル環境（CLI）に無料でインストールして利用することができます。
移行にあたっては、公式から移行手順に関するドキュメントも提供されています。
なお、dbt Fusion engine 自体は現在もプレビューの段階であり、今後の GA に向けた準備が進められている状態と理解しています。
試してみる
本記事では、以下の公式ガイドに沿って進めていきます。
前提条件
ここでは以下の環境を使用してます。
- dbt platform
- 移行前のプロジェクトでは、開発・本番環境で Latest リリーストラックを使用
- 既存のプロジェクトを安全に Fusion へ移行するために、まずは現在の dbt Core 環境で段階的に準備を進めることが推奨されています
- 具体的には、最新の dbt Core バージョン（Latest）へのアップグレードし動作を検証します。ここでは、すでに Latest である前提で進めています
サンプルの dbt プロジェクトには、以下のクイックスタートをベースに Source やモデルを追加しています。
検証開始時点で下図のリネージを確認できる状態です。
アカウントの Fusion readiness features を有効化する
dbt platform のアカウント設定で Enable Fusion readiness & upgrade features を有効化すると、以下が利用可能になります。
- すべての管理者・開発者が各プロジェクトの Fusion 対応状況を確認できる（どのジョブが対応済み・未対応かとその理由）
- 管理者が開発環境・環境設定・ジョブ設定から Fusion へのアップグレードを開始できる
- こちらは Studio 等から手動で開発者ごとのバージョンを変更もできますが、この手順が簡略化されるものでした
Deprecation の検出
簡単な設定ではありますが移行の手順も試してみます。
従来の dbt Core では非推奨（Deprecation）の警告が出つつも実行できていた古い記法や設定が、新しい Fusion エンジンにアップグレードするとエラーとなります。
一部抜粋ですが、具体的には、以下のような記法・設定の変更対応が必要となります。
- カスタム設定（メタデータ）の格納場所の変更
- YAMLファイル内でユーザーが独自に定義していたトップレベルのキーなどは、直接記述するのではなく config.meta の下にネストして記述するよう変更する必要がある
- dbt_project.yml での + プレフィックスの必須化
- dbt_project.yml でリソースの設定（例: materialized など）を記述する際、フォルダ名やファイル名と区別するために + プレフィックスを付けることが必須となる
- データテストの引数指定方法
- カスタムのジェネリックテスト等に渡す引数は、トップレベルのプロパティとしてではなく、新たに arguments プロパティの下にネストして記述する形に変更する必要がある
非推奨の問題とその解決方法のリストは以下に記載があります。
これらの変更を手動で全て探して修正する必要はなく、dbt platform の Studio IDE や、ローカルの VS Code 拡張機能に「Autofix ツール」が用意されています。
Fusion へ切り替えるための準備として、現在の dbt Core 環境でこの Autofixツールを利用し、すべての非推奨警告を事前に解決しておくことが推奨されています。
ここでは、検証用に、以下の非推奨記法を既存のサンプルプロジェクトに追加しました。
| # | Deprecation | ファイル | 内容 |
|---|---|---|---|
| 1 | MissingPlusPrefixDeprecation |
dbt_project.yml |
モデル設定に+プレフィックスなし |
| 2 | PropertyMovedToConfigDeprecation |
source_jaffle_shop.yml |
meta/tagsをconfig:の外に記述 |
| 3 | MissingArgumentsPropertyInGenericTestDeprecation |
schema.yml |
accepted_valuesの引数をarguments:なしで記述 |
具体的には、それぞれ以下の内容です。
MissingPlusPrefixDeprecation
dbt_project.yml のモデル設定でコンフィグキーに + プレフィックスを付けない旧形式。パス名との衝突を防ぐため Fusion では必須になります。
# 旧形式（非推奨）
models:
my_new_project:
staging:
materialized: view # '+' なし
# 修正後
models:
my_new_project:
staging:
+materialized: view
PropertyMovedToConfigDeprecation
meta / tags / freshness などを source や model のトップレベルに直接記述する旧形式。Fusion では config: 以下への移動が必須になります。
# 旧形式（非推奨）
sources:
- name: jaffle_shop
meta:
owner: data_team
tags: [raw]
# 修正後
sources:
- name: jaffle_shop
config:
meta:
owner: data_team
tags: [raw]
MissingArgumentsPropertyInGenericTestDeprecation
accepted_valuesなどのテスト引数をarguments:プロパティを使わず直接記述する旧形式。
# 旧形式（非推奨）
- name: status
data_tests:
- accepted_values:
values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']
# 修正後
- name: status
data_tests:
- accepted_values:
arguments:
values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']
以下のコマンドで非推奨記法を検出できます。
dbt parse --no-partial-parse --show-all-deprecations
dbt platform の Studio では、下図の下部にある横三点リーダーから「Check & fix deprecations」をクリックします。
すると、下図のようにコマンドが実行され、非推奨記法が検出されます。
公式ドキュメントの手順は以下に記載があります。
クイックスタートの内容もわかりやすいです。
ここでは、以下のように警告として検出されていました。
[WARNING][MissingPlusPrefixDeprecation]: Deprecated functionality
Missing '+' prefix on `materialized` found at
`my_new_project.staging.materialized` in file
`/dbt_project/xxxxxxxxxxxxxxxxxxxx/dbt_project.yml`.
Hierarchical config values without a '+' prefix are deprecated in
dbt_project.yml.
[WARNING][PropertyMovedToConfigDeprecation]: Deprecated functionality
Found `meta` as a top-level property of `sources[0]` in file
`models/sources/source_jaffle_shop.yml`. The `meta` top-level property should be
moved into the `config` of `sources[0]`.
[WARNING][PropertyMovedToConfigDeprecation]: Deprecated functionality
Found `tags` as a top-level property of `sources[0]` in file
`models/sources/source_jaffle_shop.yml`. The `tags` top-level property should be
moved into the `config` of `sources[0]`.
[WARNING][MissingArgumentsPropertyInGenericTestDeprecation]: Deprecated
functionality
Found top-level arguments to test `accepted_values` defined on 'stg_orders' in
package 'my_new_project' (models/schema.yml). Arguments to generic tests should
be nested under the `arguments` property.
AutoFix による自動修正
公式ガイドでは、AutoFix 実行前に修正内容を安全に確認・切り戻しできるよう、新しいブランチを作成しておくことが推奨されています。
検出された非推奨記法を dbt Studio の AutoFix 機能で自動修正します。下図の「Autofix warnings」をクリックします。
下図の表示になるので、問題なければ「Continue」をクリックします。
一連のコマンドが自動実行され、非推奨記法が修正されました。
修正内容を確認後、コミット & Sync（Push）を実施します。
※なお、AutoFix 機能でもすべての非推奨警告を自動で修正できるわけではありません。ツール実行後にも残る警告ログは、それぞれ確認し手動で対応を進める必要があります。
これで、最新のリリーストラック上での非推奨項目の修正が完了しました。
なお、本記事では開発・本番環境ともにすでに Latest リリーストラックを使用している前提で進めています。まだ Latest に移行していない場合は、Fusion への移行前にまず Latest へのアップグレードを行うことが推奨されています。
アップグレードの際は、いきなり環境全体を更新するのではなく、アカウント設定の「User development settings」にある Override（上書き）機能で個人の開発環境のバージョンのみ Latest に変更して動作を確認します。問題がなければ Override を解除し、チーム共有の開発環境（Development environment）の設定を Latest に更新します。
この点は以下に詳しく記載があります。
dbt パッケージの検証
非推奨記法の修正後、使用している dbt パッケージが Fusion に対応しているかを確認します。packages.yml または dependencies.yml を開き、dbt Hub でパッケージの Fusion 互換性をチェックします。対応バージョンがあれば、以下のコマンドで更新します。
dbt deps --upgrade
今回の検証プロジェクトでは外部パッケージを使用していないため、このステップはスキップしています。パッケージを使用している場合は以下を参照してください。
Fusion エンジンへの切り替え
非推奨記法が修正できたので、まずは開発環境を Fusion エンジンに切り替えます。
この際、冒頭の「アカウントの Fusion readiness features を有効化」しておくことで、下図のように既存のジョブが Fusion エンジンに対応しているか確認できます。
上図で「Preview job」をクリックすると、下図の表示となり「Debug on Fusion」から開発環境やデプロイメント環境で一時的に Fusion エンジンを使用する設定とできます。
「Debug in Studio」をクリックすると、Studio に遷移します。
対象のユーザーの開発環境において Fusion エンジンが使用される設定となっています。
先と同様に修正が必要な場合 Autofix ツール等で修正を行います。開発環境で警告やエラーなく実行されたら、変更をコミットします。
ここでは、その後、開発環境全体で Fusion エンジンを使用する設定としました。
Fusion の機能確認(高度な開発支援機能)
開発環境で Fusion エンジンが機能したので、高度な開発支援機能を試してみます。
Static Analysis
Fusion では列の存在チェックなどの静的解析が、実行時よりも前に行われます。
デフォルトはbaselineモード（CTE 結果のプレビューは可能）となっています。strictモードを有効化すると、最大限に厳密な解析が行われ、列名の自動リファクタリングにも対応します。
models:
my_new_project:
+static_analysis: strict
strictモードでは、実行前にエラーが検出されます。
通常モード（baseline）では DB 実行時にエラーとなります。
Static Analysis の詳細は以下に記載があります。
Preview CTE
Fusion では CTE 単位でのプレビューが可能です。
赤枠部分をクリックすると、結果ウィンドウにプレビュー結果が表示され、途中経過を確認しながら開発が行えます。
デプロイメント環境の Fusion 移行
デプロイメント環境のエンジンを変更する際は、先と同様にジョブ画面の「Preview job > Run once in Fusion」を使用できます。
これは、既存のジョブを恒久的に Fusion へ切り替える前に、単発で Fusion エンジンで試験実行できる機能です。本番ジョブや手動で Fusion エンジンを使用するジョブを定義せず済みます。
実行後、問題なければ下図の表示となります（dbt バージョンが Latest である必要があります）。
その後、既存のデプロイメント環境のジョブのエンジンを変更します。
State-aware Orchestration
Fusion エンジンの特徴的な機能である State-aware Orchestration を試してみます。
デプロイジョブの設定で State-aware orchestration を有効化します。
一度、Fusion エンジンでジョブが実行された後、特にソースデータを変更せずに再度ジョブを実行してみます。
実行結果は下図のようになり、テストやモデルビルドにおいて、前回結果が再利用されています。
ここで、片方のソーステーブルのみ Snowflake 側で更新してみます。
INSERT INTO RAW.JAFFLE_SHOP.CUSTOMERS (ID, FIRST_NAME, LAST_NAME) VALUES (101, 'Taro', 'Yamada');
この上でジョブを実行すると、更新されたデータと関連するモデルのみ再実行され、変更のないモデルは再利用されました。
このように State-aware orchestration は上流のデータ更新状況にあわせて、再構築不要な下流のモデルの更新を自動でスキップする機能となり、更新の影響を受けるモデルのみ自動実行され、不要なコンピューティングコストの発生を防ぐことができます。
Cost Insights では、日別に再利用された割合が可視化されます。
さいごに
簡単ではありますが、dbt Fusion エンジンへの移行検証として、Deprecation の検出・AutoFix・Fusion 固有機能・State-aware Orchestration を試してみました。開発時の高度な支援と State-aware Orchestration は注目度の高い機能と思います。他にも関連機能があるので、今後試せればと思います。
こちらの内容がどなたかの参考になれば幸いです。
