2026年5月、dbt Fusionがdbt platform上でSnowflake向けにGAになりました。
GA、つまり一般提供開始です。ここ、地味に大きいです。
というのも、Fusionは「ちょっと便利な新機能」ではなく、dbtの中身そのものを更新する話だからです。
dbt Coreを長く使ってきた人ほど、「今のdbtがどう変わるの？」と気になるはず。この記事は、そのモヤっとした部分をかなり丁寧に整理してくれています。
個人的にも、Fusionは単なる“Coreの強化版”として見るより、SQL開発の考え方そのものを変える存在として捉えたほうが面白いと思います。
記事では、Fusionをこう説明しています。
買収した SDF Labs のデータ加工エンジンに、dbt のインターフェースをラップした次世代の dbt エンジン
ざっくり言うと、
dbtの見た目や使い勝手は保ちつつ、中ではもっと賢くSQLを扱えるようにしたものです。
ここで重要なのは、FusionがただのUI改善ではないことです。
dbt Coreは、主にSQL文を作るところまでが役割でした。実際にSQLを理解して実行するのは、SnowflakeやBigQueryなどのDWH側です。
一方Fusionは、SQLの文法や意味を自前で理解できるようになっています。
これがすごく大きい。なぜなら、SQLを「文字列」ではなく「構造」として扱えるからです。
たとえば、人間でもこういう違いがあります。
Fusionは後者に近づいています。
ここが本質だと筆者は述べていますが、私もかなり同意です。
記事の中心テーマはここです。
Fusionの本質は、各DWHの中に閉じていたSQL方言のコンパイラを、エンジン内部に取り込んだことだとされています。
少し補足すると、SQL方言とは、Snowflake、BigQuery、PostgreSQLのように、各データ基盤ごとに微妙に違うSQLの書き方のことです。
同じSQLでも、そのままでは別のDWHで動かないことがあります。
dbt Core時代は、この違いをある程度吸収しつつ、実際の実行はDWHに任せていました。
でもFusionは、SQLを自分で理解して、文法チェック、意味チェック、実行までを内部で完結できる方向に進んでいます。
これが何を生むかというと、次の3つがかなり面白いです。
これは普通に便利です。かなり。
dbt Coreでは、モデル作成やテストのたびにDWHのコンピュートを使う必要がありました。
つまり、開発のたびにクラウドの計算資源を消費する。地味にお金がかかるし、試行錯誤もしにくい。
Fusionでは、必要なデータがあればローカル実行ができます。
これによって、開発時のコスト削減が期待できます。
ここ、実務ではかなり効きます。
SQLを少し直して試すたびにDWHを叩くのって、積み重なると地味に重いんですよね。
ローカルで回せるなら、開発体験はかなり軽くなるはずです。
記事では、Fusionの実行エンジンとして Apache DataFusion が使われていると説明されています。
DataFusionは、Rust製のOSSクエリエンジンです。
そして、メモリ上のデータ表現として Apache Arrow を使っています。
難しく聞こえますが、要するに
「SQLを速く、安全に、いろんな環境で実行するための土台」
だと思えばOKです。
筆者はDataFusionを「データベース業界のLLVM」と表現しています。
LLVMは、ざっくり言えば「プログラムをいろんなCPU向けにうまく変換する中間基盤」のような存在です。
それになぞらえて、DataFusionも中間表現を受け取れば、その後の実行をうまく最適化できる世界を目指している、というわけです。
この比喩、かなりわかりやすいです。
Fusionが単なるdbtの便利機能ではなく、データ実行基盤の思想そのものに触れていることが伝わってきます。
ここは個人的にかなり面白いポイントです。
記事では、FusionがSQLを構造的に理解できることで、AIに対してより良い文脈を渡せると述べています。
ここでいう「ハーネス」は、AIが暴走しないように方向づけるための土台、くらいに考えるといいです。
雑に言えば、AIに「はい、これを参考にして答えてね」と渡せる材料が増える、ということです。
lineage（リネージ）は、データの由来をたどる仕組みです。
column-level lineageなら、特定のカラムがどの上流モデルから来たのかを追えます。
しかもFusionでは、単に「どこから来たか」だけでなく、
のような変化も表現できます。
これがAIにとって何がいいかというと、
AIがdbtモデルを生成するときに、やたらローデータ寄りのref()を使ってしまう問題を減らしやすくなることです。
つまり、「このカラムは本来どのレイヤーを見るべきか」がわかるので、dimensional modelingを踏まえた設計に寄せやすくなる。
これは現場感としてかなり重要です。
筆者が紹介している stable 社のレポートでも、column lineageを使うことで、AIのモデル生成が安定し、参照先がstg層ではなくint層に集まったとされています。
このあたりは、AIに“なんとなく全部任せる”時代から、ちゃんと構造を与えて賢く使う時代への移行を感じます。
これは実装検討中の機能です。
似たdbtモデルを検知する機能で、どちらかを少し直せば統一できるコードを見つけるのに役立ちそうです。
個人的には、これが入るとかなり嬉しいです。
というのも、データモデリングは放っておくと似たようなモデルが増えがちだからです。
人が増えるほど、微妙に違う同義のモデルが乱立する。あるあるです。
もしAIがmodel overlapを見て「この2つ、かなり似てますよ」と言えたら、リファクタリングの候補発見にかなり使えるはずです。
これも実装検討中の機能です。
PIIとは、個人を特定できる情報のことです。たとえば氏名、メールアドレス、電話番号などですね。
PII classifiersは、カラムのPIIラベルをdownstreamモデルへ伝播させる仕組みです。
複数カラムが合体しても、ラベルを追いかけられる想定です。
これがもし安定して動けば、
「どのデータが個人情報か」を機械的に追いやすくなるので、セキュリティやガバナンスがかなりやりやすくなります。
これは派手さはないけれど、実務では超重要です。
データ基盤って、最終的には「便利」だけじゃなくて「安全に使える」が問われるので、こういう機能は地味に効きます。
記事の3つ目の注目点は、クエリとコンピュートを疎結合にすることです。
これは少し抽象的ですが、要するに「書くもの」と「実行するもの」を切り離すという話です。
最近はIcebergを含むOTF（Open Table Format）の導入が増えています。
OTFは、ざっくり言えば、特定のDWHに縛られにくい形でデータを扱うための仕組みです。
でも、データ層がオープンになっても、クエリの側がDWHにべったりだと、まだ完全ではありません。
dbt Coreでは、結局DWHのコンピュートなしではクエリを実行できないので、SQLは「文字列」でしかない、という見方ができます。
Fusionはそこを変えます。
SQL方言を吸収して、自前の中間表現を作れる。
中間表現が作れるということは、実行計画を自由に作りやすいということです。
すると、ある方言のクエリを、別のクエリエンジンで実行できる未来も見えてきます。
つまり、クエリ実行層のvendor lock-inを弱められる可能性がある。
これはかなり野心的です。
もし本当に進めば、データ基盤の自由度はかなり上がると思います。
「どのDWHに乗るか」だけでなく、「どの実行エンジンでどう走らせるか」を考えられるようになるからです。
ここは実務派にとって大事な部分です。
Fusionを試したいなら、いきなり入れるのではなく、事前準備が必要です。
記事では、概要として次の流れが紹介されています。
まず、使っているdbt packagesや周辺ツールがFusionに対応しているかを確認します。
特に require-dbt-version が 2.0.0 以上かが目安になります。
これは地味ですが超重要です。
自分のプロジェクト本体が対応していても、依存しているライブラリが古いとそこで詰まります。
移行あるあるです。
次に、dbt Coreを最新にします。
Fusionに移る前提条件として、ここは避けられません。
そして、dbt compile して出る警告を全部潰します。
deprecation警告は「その書き方、いずれ使えなくなりますよ」というお知らせです。
Fusionでは、これが残っているとエラーになることがあるとのこと。
なので、今のうちにちゃんと直しておくのが大事です。
記事では、dbt-autofix がかなり役立つと紹介されています。
さらにdbt platformを使っているなら、Studio IDE内でautofix toolが使えます。
また、dbt agent skills を使うと、自律的に修正を進めることもできるそうです。
このあたりは、移行作業を「人力の根性勝負」から「ツールでかなり補助できる作業」に変えていく流れを感じます。
正直、こういうのはありがたいです。移行は楽しいけど面倒でもあるので。
この記事を読んで強く感じるのは、Fusionは単なる新機能の集合ではなく、
dbtをSQL理解の深い実行基盤へ進化させる試みだということです。
本質は、SQL方言のコンパイラをエンジンに取り込んだこと。
そこから、
といった話がつながっていきます。
個人的には、特にAIとの相性の良さが今後の大きな差別化になるのではないかと思います。
SQLを書けるAIはもう珍しくないですが、**“どのデータをどう扱っているか”を構造的に理解できるAI**は、まだ強い武器です。
GAになったことで、Fusionはかなり試しやすくなりました。
もしdbtを日常的に使っているなら、これは一度触ってみる価値がかなりあると思います。
「ただ便利そう」ではなく、「データ開発の前提が変わるかもしれない」と感じるからです。
