dbt Summit 2026 最速レポートDay2―Keynoteを聞いてきました―

こんにちは、DATUM STUDIOの淡島です。今年もdbt SummitにやってきたのでKeynoteの感想をお届けします。
感想以外はAIにまとめてもらいました。便利な時代になったものですね。

dbt v2の発表とエンジン統合・オープンソースへの回帰

• ・背景・経緯
  これまでdbt CoreとFusionの2つのエンジンおよびコードベースが存在し、CLIやライセンスの複雑化がコミュニティやエンタープライズユーザーの課題となっていました。
• ・議論の内容
  dbt CoreとFusionを統一し、ブランド名をシンプルに「dbt」に一元化した「dbt v2」のGA（一般提供）が発表されました。Apache 2.0ライセンスのもとでオープンソースとして提供されます。Spotifyの事例では、プロジェクトのコンパイル時間が90秒以上から9分の1に短縮され、CI/CD処理時間の大幅削減（推定20万時間の短縮）と移行の容易性が報告されました。
• ・結論
  dbt v2への統一により、開発速度と互換性が飛躍的に向上し、オープンソース標準としての基本路線が再確認されました。
• ・感想
  調べてみたところdbt v2は完全にRustベースでした。FusionをCore仕様にしてリブランディングしたもの、という理解でよいのでしょうか。ETLレイヤーでは2025年からOSS化を促進する戦略に切り替えており、大きな転換点を感じます。一方で、今後どこまでマネタイズしていくのかという点は気になったパートでした。

dbtの機能強化

• ・背景・経緯
  データモデルの増大に伴い、データウェアハウス（DWH）のコンピューティングコスト高騰と開発スピードの低下が大きな課題となっていました。
• ・議論の内容
  デモを交えて以下の3つの主要機能が実演・解説されました。
• 
  
  • 1.dbt State（GA）：変更されたコードおよびデータのみを認識して増分実行（Auto-cloning対応）し、DWH利用料を15〜40%削減。
  • 2.テストのローカル実行：SQLFluff互換の超高速リンターの導入、複数テストの単一クエリ化（Batch tests）、およびDuckDBを利用して BigQuery / Snowflakeのテストをローカルで10ミリ秒で高速実行する機能。
  • 3.Lake Compute（Beta）：Apache Iceberg形式のテーブルを介し、一部の重いモデル処理のみをdbt側が管理するDuckDBベースの低コスト計算基盤「Lake Compute」へオフロード・相互運用する仕組み。
  • 
    
• ・結論
  これら新機能により、費用対効果の高い開発環境と本番運用を実現できることが実証されました。
• ・感想
  dbt StateについてはGAになったものの、そもそもstateを保有してパイプラインの動作を切り替えるという挙動自体が不測の事態に繋がりやすいため、導入は慎重にならざるを得ないだろうなと思います。テストのローカル実行およびLake Compute下での実行についても、エンジンを置き換えての実行が果たして個別エンジンの挙動の完全再現ができているのかという問題が残るため、実際に使ってみないとわからないというのが正直なところです。

コンテキストエンジニアリングとAIエージェント連携

• ・背景・経緯
  企業内で生成AIやAIエージェントの利用が急増していますが、正確なメタデータやコンテキストが不足していると、誤った集計結果（ハルシネーション）を出力するリスクが高まります。
• ・議論の内容
  データアナリティクスエンジニアの役割は「コンテキストエンジニア」へ進化すると定義されました。AIエージェントに正確なコンテキストを提供するための枠組みとして、以下が提示されました。
  
  
  1. 1.Fivetran Context Layer：非構造化データを含む社内データからメタデータやベクターを抽出し、DWH内のAgents Schemaに配置してエージェントの検索性を高める仕組み。
     
  2. 2.dbt Charts：ダッシュボードやチャートの定義をYAMLコードとしてdbtプロジェクト内でバージョン管理・ガバナンス管理する仕様。
     
  3. 3.dbt Wizard （Public Preview）：アナリティクスエンジニアリング専用AIエージェント。自然言語での探索（Explore mode）、セマンティック層の自動定義、デスクトップアプリ版（Private Preview）によるローカル開発環境との統合が披露されました。
• ・結論
  データモデルだけでなく、コンテキストやガバナンスそのものをコード化して提供することが、AI時代における最重要成果物であると合意されました。
• ・感想
  dbt Chartsのアプローチには既視感があり、今後どう差別化していくのかが気になります。ただ、方向性は非常に興味深いと感じました。Fivetran Context Layerも同様に面白いと感じたのですが、これは常日頃から、インターフェースとなる別サービス側のデータ定義は別サービス側で実施するのが最も効率的であると考えているためです。それをコネクタ側でラッピングするというのはある種の代替措置になり、dbt + Fivetranというエコシステムの中に全てのコンテキストを投下するという戦略にフィットするよい製品だなと思いました。
• 冒頭で触れたdbt v2のOSS化に対して、マルチデータソース・マルチDWH環境下におけるコンテキストマネジメントおよび分析エージェント提供化という明確なマネタイズポイントが用意された点については非常によい戦略に見えます。

最終的な感想

最後のコンテンツではSnowflake、MotherDuck、Microsoftのリーダー達が登壇し、以下の点を討論しました。

• ・セキュリティとガバナンスの標準化
  Iceberg RESTプロトコルにおける新たなアクセス制御など、カタログレベルでの統合ガバナンス推進。
• ・マルチエンジンの共存：
  データがIceberg等の標準形式で保存されていれば、負荷や用途に応じて最適な計算エンジン（Snowflake / Microsoft Fabric / MotherDuck / Lake Compute等）を自由に選択可能。
• ・セマンティック層の標準化：
  AIエージェントがビジネスロジックを理解するための共通言語の重要性。

こうした討論とは別に感じたことがあります。我々の普段のビジネスからすると、概ね単一のDWHに収束させるような案件が多く、このようなオープン・マルチエンジンという方向性が今後どこまで進むのか、dbt Summit 2026のKeynoteで発表されたプロダクトの成功に大きく影響していくと感じられる、とてもインパクトのある発表でした。

個人的な視点としては、マルチエンジンになりがちなケースは企業間でのコラボレーションだと考えており、Data Clean Roomあたりの機能がLake Compute絡みで追加機能として加わるとだいぶ面白くなりそうです。

以上、それでは他メンバーの記事も楽しんでいただければ幸いです。