dbt v2 の新機能：パーシングの高速化、共通のアダプタ層の導入、そして巨大な manifest.json を省略したドキュメント体験

最終編集日時：2026年10月26日

dbt Labsのv2アダプタ担当プロダクトマネージャーであるHope Watson氏は、このセッションを19世紀の鉄道に例えた比喩で切り開きました。異なる軌間を採用する二つの鉄道システムでは、技術的には何ら問題はないものの、両者間での乗り換えには時間とコストが必ず伴います。dbt v1とdbt v2は過去1年間にわたり別々のコードベースとして稼働しており、特定の機能についても、各エンジンが先にリリースした方へ対応するまで待たざるを得ませんでした。

ワトソンの講演では、dbt Labsがユーザーに「移行コスト」を負担させることなくそのギャップを解消している方法について説明されました。根本的な解決策はアーキテクチャ上のもので、dbtはv1とv2の重複する部分をオープンソース化することで、エコシステム全体が時間の経過とともに一つのエンジンと一つのバイナリへと収束していくようにしています。ただし、移行自体には数年を要する見込みです。

今日のアップグレードを実用的にするため、dbtはv1.12にv2パーサーを搭載し、チームが切り替えを確定する前に互換性を確認できるようにしています。さらに、ライブデモにおいて約5分で22件の警告された問題を解決するdbt autofix deprecationsコマンドも提供されています。本講演の前日には、v2がほとんどのアダプタで一般提供となりました。

アダプターは、ワトソンがdbtの「秘密の基盤」と呼んだものとして独自のセグメントを形成しており、その層によって、識別子の大文字化が行われるSnowflakeや小文字化が行われるPostgres、さらにSnowflakeには3種類のタイムスタンプ型がある一方でBigQueryには2種類しかないといった、極めて異なるデータベース間でも、dbt内部では一貫した見た目を実現しています。dbt v1では、各アダプターがそれぞれ独自のリポジトリに格納され、独自の依存関係チェーンを持っていたため、第2のアダプターをインストールすると、静かにdbtコアがダウングレードされたり、互いに矛盾するSDKが取り込まれたりするリスクがありました。

dbt v2では、アダプターがADBCドライバー標準に基づいて構築された共有レイヤー上に、エンジンと同じバイナリに同梱されて提供されるため、SnowflakeおよびDatabricksで実際にデモされている複数のアダプターを、バージョン競合なく同時にインストールして実行できます。

パーシングの改善は、合成的な1,800モデル・72 YAMLファイルからなるプロジェクトにおいて、対照的に実証されました。v1では約10〜13秒、v2では約3秒で処理が完了しました。エラー検出に関しては、OSS版ディストリビューション（データウェアハウスとの往復が必要）ではSQLの誤字一つを捕捉するのに約1.5秒かかるのに対し、SQLを直接理解するdbtのフルディストリビューションではわずか0.06秒でした。

新しいリンターは、小文字表記のルール違反を検出し自動修正するデモが行われ、他のリンターより50〜100倍高速であると説明されました。Docs v2では、単一で膨大なmanifest.json（同じ1,800モデルのプロジェクトにおいて、約50万行に及ぶJSONファイル）に代わり、クエリ可能な小さなParquetファイルが導入されています。

デモでは、WatsonはClaudeを用いてそれらのファイルに対してアドホックなクエリを実行しました。これには、列レベルのリネージクエリや、上流の単一の列名を変更したことで影響を受けるすべての下流モデルを示す「ブラストラジス」クエリが含まれており、このような影響分析は通常であれば膨大なJSONファイルを手作業で解析しなければなりません。また、再設計されたドキュメントUIにはDAGによるグループ化ビューも追加されました。

dbt Summit 2026の基調講演および分科会をすべてオンデマンドで視聴できます。dbt Summit 2026をオンデマンドで視聴する →

dbtの利用を開始する

実際にスケールするデータインフラを構築しているアナリティクスエンジニアの仲間に加わりましょう。

dbt Wizard CLI をインストールする

分析エンジニアリング専用に設計されたエージェントで、すぐに使い始めることができます。どのツールを呼び出すべきか、どのコンテキストを取得すべきかを把握し、あなたに結果を提示する前に自らの作業を確認します。

情報源

dbt