TECH BLOG
データサイエンティスト、dbt Coalesce on the road Tokyoに参加する
DX技術本部に所属するデータサイエンティストの岡部です。
入社以来、機械学習モデルの構築・運用を担当してきたのですが、最近はアセット開発運用Teamの一員として、分析者がパフォーマンスを発揮できるような分析環境の整備にも従事しています。なかでも、データエンジニアリングやMLOps/DataOpsについて学んでいるなかで、dbtに出会いました。
本記事では、データサイエンティストの目線から、dbtの年次イベントdbt Coalesce on the road Tokyoに参加した体験談を報告したいと思います。
はじめに:dbtとは
dbtはdata buiild toolの略で、ETL/ELTのT、つまりデータのTransformation(変換)用のツールです。データソースから抽出したデータを処理する際に、Gitによるバージョン管理、依存関係の明示、CI/CDといったソフトウェアエンジニアリングのベストプラクティスを適用することで、開発効率を爆上げしてくれます。
そんなdbtの年次カンファレンスdbt Coalesce(2025/10/13~16@ラスベガス)に続き、東京でもdbt Coalesce on the road Tokyoカンファレンスが開催されたので参加してきました。
dbt Coalesce on the road Tokyo参加レポート

カンファレンスは英語と日本語のバイリンガルで進行し、登壇者が英語を話すと日本語の、日本語を話すと英語の翻訳字幕が常にスクリーンで映し出されるという言語バリアフリー空間。
発表では、dbtを導入した各社が実運用においてどういった課題を解消し、効率化を達成しているかに関するしみじみしたお話を多く聞くことができました。
また、dbt Labs社のプロダクトマネージャー、エライアス・デファリア氏によるdbt Fusionエンジンの発表では、静的解析を利用してローカルでのSQLクエリの検証を実現している様子の実演があり、カラムレベルのリネージの可視化、クエリの実行前のエラー検出、カラムのリネームによるインパクト分析など、開発者フレンドリーな機能満載で大変盛り上がりました。そしてとにかく実行が早い!Rustを採用することで30倍の高速化を達成しているそうです。
以下では特に、dbtの提唱するオープンデータインフラストラクチャについて、dbt Labs社のプロダクトマーケティングVP、クラーク・パターソン氏による基調講演と、同じくdbt Labs社からの発表の一つを取り上げて考察したいと思います。
基調講演
Rewriteをテーマに、Rewrite with open standards、Rewrite with the rules、Rewrite with AIという三つのポイントに沿った内容でした。包括的な解説は他の記事にゆずり、本記事ではなかでもRewrite with open standardsに注目して解説したいと思います。
dbt Labs社は、オープンデータインフラストラクチャを指向しています。つまり、特定のプロダクトやベンダーに癒着しておらず、標準規格(standards)によって統合された、オープンなデータ基盤の実現を目指しているということです。
従来、特定のデータ基盤(例えばSnowflakeやdatabrciks)にデータを置くことは、そのデータ基盤の提供する形式でそのデータを保存(ストレージ)、あるいは計算・処理(コンピュート)することを内包していました。
一方でdbtは、図中のOpen computeという層が示すように、どの基盤のコンピュートエンジンとも統合可能なツールとして設計されています。また、All compute engines「あらゆるコンピュートエンジン」だけではなく、All LLMs「あらゆるLLM」、All BI tools「あらゆるBIツール」とも連携可能である点も強調されていました。
オープンデータインフラストラクチャの概念図(引用元)
こういったオープンなエコシステムは、SQL、MCP、Apache Arrow、そしてApche Icebergといった、特定のプロダクト・ベンダーに紐づかない、オープンなオプションを採用することで実現されています。
この点について、カンファレンスの最終発表「dbt on dbt: Icebergとクロスプラットフォームなデータメッシュ」がその内容を最もよく表していると思いますので、発表を振り返ってみたいと思います。
発表:dbt on dbt: Icebergとクロスプラットフォームなデータメッシュ
カンファレンス最後の発表は、伊藤俊廷氏、リー・ボンド=ケネディー氏による、複数データプラットフォーム上でのデータ処理におけるdbt Meshの活用に関する発表でした。
デモでは、Apache Iceberg形式でs3に保存したデータのメタデータをDatabricksのUnity Catalogに登録し、それをSnowflakeのカタログリンクデータベースとして登録することで、dbt MeshからDatabricks・Snowflakeの両サイド上のテーブル操作が可能になることの実演がありました。オープンソースのテーブルフォーマットであるApache Icebergを活用することで、特定のデータ基盤・コンピュートエンジンに縛られないデータの保存・操作を目指すオープンデータインフラストラクチャの具体例として非常に興味深く拝聴しました。
ストレージとコンピュートの分離や、その具体例の一つとしてのDatabricksとSnowflakeの相互運用などの複数プラットフォーム連携は近年のトレンドですが、データへのアクセスがオープンになることによる実利(ベンダーロックインの回避、データをコピーするコストの削減、ユースケースに合わせた最適なデータ処理ツール(エンジン)選択など)があるという点を考慮しても魅力的だと思いました。
まとめ:抽象化レイヤーの設定によるオープンなエコシステムの実現
カンファレンスを通して、dbtが「オープンであること」を非常に重視していることが伝わってきた一日でした。基調講演の冒頭でも、ビジネスを支える様々な技術で使われているロジックを抽象化し、単純化(simplify)することができる、と強調されており、特定のプロダクトから疎結合のエコシステムを構築することで、コンポーネントを入れ替え可能なオープンなシステムの構築を目指していることが理解できました。Apache Icebergのiceberg「氷山」も、目に見えるデータの下に複雑な構造を隠すことで抽象化を図るという同様のコンセプトに由来すると考えると、dbtの目指すエコシステムとの相性が良いことも納得です。
また、データを活用するエンドユーザー側のデータサイエンティストとしては、データがどのように保存されているか、どこから読み込まれてくるかを気にせずにモデル構築や分析が可能になるのは非常に便利に思いました。巷でよく言われることですが、データサイエンティストは必ずしもデータエンジニアリングやMLOps/DataOpsに知悉しているわけではなく、データの扱いについては見様見真似ということがよくあります。(自分個人の経験を思い出してもそうです。)なので自戒も込め、高品質なSingle Source of Truth「信頼できる唯一の情報源」を担保しやすい仕組みやツールについては、今後も是非キャッチアップを続けていきたいと思っています。
今回のカンファレンス参加を通して、dbtやApache Iceberg導入による実際の作業時のメリットにとどまらず、理念面においても、自チームのミッションである「分析者がパフォーマンスを発揮できるような分析環境の整備」において考慮すべき観点を多く学ぶことができました。業務にも積極的に生かしていきたいと思います。
参考資料
-
dbt Labs + Fivetran: Open data Infrastructure for analytics and AI | dbt Labs
-
[レポート]Coalesce on the road Tokyo KEYNOTE #dbtCoalesceTokyo | DevelopersIO
-
[レポート] Icebergとクロスプラットフォームなデータメッシュ #dbtCoalesceTokyo | DevelopersIO
-
The dbt Revolution: How It Transformed Data Engineering and Set a New Industry Standard | Medium
-
Apache Iceberg™ テーブルにはカタログリンクデータベースを使用します | Snowflake Documentation
-
Snowflake, Databricks, Tabular, Iceberg, what does it all mean? | Starburst