データオーケストレーション 2025 完全ガイド: dbt・SQLMesh・Dagster・Airflow・Prefect、データ契約、CI/CD (2025)

Season 5 Ep 4 — Ep 3 が「誰が速くクエリするか」だったとすれば、Ep 4 は「誰がパイプラインを治めるか」。2025年のデータオーケストレーションは、エンジニアリング原則（CI/CD・テスト・契約）がデータに移植されている最中だ。

Prologue — 「データパイプラインもソフトウェアだ」
第1章 · オーケストレーションツールの分類
- 1.1 2つの軸
- 1.2 主要ツール
第2章 · dbt — Analytics Engineer の標準
第3章 · SQLMesh — 「dbt の代替か補完か」
第4章 · Dagster — 「Asset-centric の革命」
第5章 · Airflow — 「依然として最も広く使われている」
第6章 · Prefect — 「Pythonic なオーケストレーション」
第7章 · Temporal — 「ワークフローエンジンの別系譜」
第8章 · データ契約（Data Contracts）
第9章 · データパイプラインの CI/CD
第10章 · オブザーバビリティ（Observability）とアラート
第11章 · 実際のスタック構成5種
第12章 · 韓国企業の実務 Tips
第13章 · アンチパターン10選
第14章 · チェックリスト — データパイプライン成熟度の12項目
第15章 · 次回予告 — Season 5 Ep 5:「Semantic Layer・Metrics Store・Reverse ETL」

Prologue — 「データパイプラインもソフトウェアだ」

2010年代のデータエンジニアリングは「SQL スクリプト + cron」だった。2025年は違う:

パイプラインが Git で管理される
変更は PR + レビュー + CI テスト を経る
データモデルは型・制約・テストを持つ
障害はOpenLineage・データ契約で予防される

この変化は Analytics Engineer という新しい職種を生み、dbt がその中心に立った。しかし 2025年は dbt だけではない — SQLMesh・Dagster が実質的な代替として、Airflow・Prefect は依然として汎用オーケストレーションの王座を守っている。

第1章 · オーケストレーションツールの分類

1.1 2つの軸

データ変換（Transformation） vs ワークフローオーケストレーション
SQL 中心 vs コード（Python）中心

1.2 主要ツール

ツール	主な役割	哲学
dbt Core / Cloud	SQL 変換	Analytics Engineer の標準
SQLMesh	SQL 変換	バージョン・増分・状態
Dagster	オーケストレーション	Asset-centric
Airflow 2/3	オーケストレーション	Task DAG、汎用
Prefect 3	オーケストレーション	Pythonic、動的
Temporal	ワークフロー	信頼性・ステートマシン
Mage, Kestra	オーケストレーション	新世代

第2章 · dbt — Analytics Engineer の標準

2.1 アイデンティティ

SQL でデータ変換をコードのように管理する
依存グラフ・テスト・ドキュメントを自動生成
Snowflake/BigQuery/Databricks/Redshift/Postgres/DuckDB などのアダプタ

2.2 コア概念

Model: SELECT 文で定義されたテーブル/ビュー
Source: 外部システムのデータ定義
Seed: CSV データのロード
Snapshot: SCD Type 2
Test: カラム・モデル単位の検証（not_null, unique, accepted_values, リレーション）
Macro: Jinja による再利用ロジック

2.3 依存関係の管理

-- models/fact_orders.sql
SELECT *
FROM {{ ref('stg_orders') }}
JOIN {{ ref('dim_customers') }} USING (customer_id)

ref()・source() で依存関係を宣言
DAG を自動生成 → 正しい順序で実行
dbt build でパイプライン全体を実行

2.4 2024–2025 の動向

dbt Cloud: IDE・スケジュール・環境・コラボレーションの SaaS
dbt Semantic Layer / MetricFlow: 指標の中央化
dbt Mesh: 複数プロジェクトの連合
dbt-fusion エンジンの発表（2024）: 性能・開発体験の改善

2.5 限界

増分（incremental）ロジックが複雑になるほど維持が難しい
状態追跡が弱い（実行履歴・変更検知）
Jinja マクロのデバッグが難しい
大規模プロジェクトでのビルド時間の問題

2.6 使いどころ

ほぼすべてのモダンデータチームのデフォルト
BI・ML feature のモデリング

第3章 · SQLMesh — 「dbt の代替か補完か」

3.1 アイデンティティ

2022年に登場、2024年に注目を集める
dbt の弱点（増分・バージョン・テスト）を改善
Tobiko Data が商用サポート

3.2 コアとなる差別化点

Virtual environments: 変更を仮想環境で事前にテスト
Automatic incremental: 増分ロジックの自動化
State tracking: モデルバージョン + 変更の影響分析
Backfill: 過去データの再処理ワークフローを内蔵
dbt 互換: 既存の dbt プロジェクトを import 可能

3.3 哲学

「dbt の生産性 + データウェアハウスの厳格さ + DevOps のセーフティネット」

3.4 例 — 増分モデル

MODEL (
  name core.fact_orders,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column order_date,
  ),
);

SELECT *
FROM raw.orders
WHERE order_date BETWEEN @start_date AND @end_date;

→ SQLMesh が増分処理・バックフィル・キャッシュを自動管理する。

3.5 限界

エコシステム・コミュニティはまだ dbt に比べて小さい
コネクタ・アダプタの数が限られる
学習資料・サンプルが不足

3.6 使いどころ

増分・バージョン・backfill が中心のチーム
dbt の限界に苦しむ中大規模チーム
新しく始めるチームの代替オプション

第4章 · Dagster — 「Asset-centric の革命」

4.1 アイデンティティ

2018 Elementl → Dagster Labs
データアセット（Asset）を中心に据えたモデル
Airflow の task 中心から一歩先へ

4.2 コアとなる違い

Task DAG (Airflow): 「A を実行した後に B を実行」
Asset DAG (Dagster): 「このテーブルを作る関数」 + 依存関係の自動化

from dagster import asset

@asset
def orders(raw_data):
    return transform(raw_data)

@asset
def customer_lifetime_value(orders, customers):
    return compute_clv(orders, customers)

4.3 強み

パイプラインがデータ資産の集合としてモデリングされる
マテリアライズ状態・freshness・メタ情報が第一級の概念
dbt・Fivetran・Hightouch などの統合が豊富
ローカル開発体験が優れている

4.4 2024–2025 の動向

Dagster+: クラウド SaaS
Dagster Components: 再利用可能なパイプラインブロック
Asset-based scheduling: 鮮度ベースのスケジューリング
AI/ML パイプライン統合の強化

4.5 限界

学習コスト（新しい概念）
エコシステム・プラグインが Airflow に比べて小さい
大規模エンタープライズのリファレンスは蓄積中

4.6 使いどころ

データプロダクト中心のチーム
dbt と Airflow の「継ぎ目」で苦しむチーム
モダンデータスタックの新規構築

第5章 · Airflow — 「依然として最も広く使われている」

5.1 アイデンティティ

2014 Airbnb → Apache
Python DAG でワークフローを定義
最大のエコシステム・コミュニティ

5.2 Airflow 2.x

TaskFlow API で Python 関数をそのままタスク化
Dynamic task mapping
Datasets（データ中心のスケジューリング）
数百のプロバイダ（AWS・GCP・Snowflake・dbt・Databricks など）

5.3 Airflow 3.0 (2024–2025)

アーキテクチャの大改編（Task Execution Interface, Task SDK）
言語非依存のタスク実行（Python 以外も）
DAG Versioning
より良い UI・セキュリティ・マルチテナンシー

5.4 マネージドの選択肢

Astronomer (Astro)
AWS MWAA
GCP Cloud Composer
Azure Data Factory managed Airflow

5.5 強み

どこでも動く、数多くのプロバイダ
エンタープライズでの検証済み
汎用オーケストレーション（データ以外の作業も）

5.6 限界

Task 中心（データ資産の追跡が弱い）— Datasets で緩和中
スケール時に複雑（Celery/Kubernetes Executor のチューニング）
UI・開発体験が Dagster・Prefect に比べて重いという評価

第6章 · Prefect — 「Pythonic なオーケストレーション」

6.1 アイデンティティ

2018 Prefect → Prefect Cloud
Airflow の代替として出発
Python-native、動的ワークフロー

6.2 Prefect 2.x → 3.0

2024年に Prefect 3.0 をリリース
性能・UI・セキュリティを大幅に改善
Flow・Task の抽象化
非同期がデフォルト、動的グラフが自然

6.3 強み

Python コードがワークフローそのもの
ローカルとクラウドで同じ体験
スケジュール・リトライ・アラートがシンプル

6.4 限界

エコシステムが Airflow に比べて小さい
エンタープライズのリファレンスは蓄積中
dbt・ML の統合は Dagster に強みがある

6.5 使いどころ

Python エンジニア中心のチーム
動的パイプライン（パラメータ・実行時の決定）
スタートアップ・中堅企業

第7章 · Temporal — 「ワークフローエンジンの別系譜」

7.1 アイデンティティ

2020年に Uber Cadence からフォーク
長時間実行・ステートマシン・信頼性が中心
一般ワークフロー（決済・注文）+ データワークフロー

7.2 Airflow との違い

Airflow: バッチ ETL・定期実行
Temporal: イベント駆動・長時間実行・ユーザー主導のワークフロー

7.3 使いどころ

LLM Agent のオーケストレーション（2024–2025 に拡大）
注文・決済・配送のステートマシン
ユーザージャーニーのワークフロー

第8章 · データ契約（Data Contracts）

8.1 何なのか

データの生産者と消費者の間のスキーマ・SLA・オーナーを明示した合意
コードの API contract のデータ版
2022–2025 に浮上した概念

8.2 構成

Schema: カラム・型・制約
SLA: freshness, completeness, uniqueness
Owner: データチーム・サービスチーム
Lifecycle: 変更ポリシー、バージョン、deprecation

8.3 ツール

Soda: データ品質 + 契約
Schemata / Monte Carlo / Metaplane / Datafold: オブザーバビリティ + 契約
OpenLineage: リネージの標準
dbt Contracts: dbt モデルに契約を宣言
Great Expectations: 検証の標準

8.4 例 (dbt Contract)

models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: bigint
        constraints: [{type: primary_key}, {type: not_null}]
      - name: email
        data_type: varchar
        constraints: [{type: not_null}]

8.5 運用

PR で契約変更をレビュー
Breaking change → バージョンアップ + deprecation の告知
消費者テーブルで契約違反が起きたら自動アラート

第9章 · データパイプラインの CI/CD

9.1 Git・ブランチ戦略

main: プロダクションのパイプライン
dev: 開発環境
Feature branch → PR → レビュー → CI 通過 → マージ

9.2 CI のステージ

Lint（sqlfluff, dbt lint）
コンパイル（dbt compile, SQLMesh plan）
ユニットテスト（モデル単位のサンプル）
契約の検証
Staging 環境で部分実行
統計 diff（Datafold など）

9.3 環境の分離

Dev / Staging / Prod のデータセットを分離
アクセス権限を厳密に区分
Staging では Prod の一部サンプルを使用可

9.4 デプロイ戦略

Blue-Green（テーブルの新バージョン + スイッチ）
Canary（一部のユーザー/クエリだけ新バージョン）
Shadow（新バージョンは計算のみ、比較する）
ロールバック計画

9.5 オブザーバビリティの統合

デプロイ後の鮮度・失敗・遅延をモニタリング
アラート → Slack・PagerDuty
事故後の Postmortem

第10章 · オブザーバビリティ（Observability）とアラート

10.1 5つの柱（Monte Carlo）

Freshness: データは最新か
Volume: 行数は正常か
Schema: カラム・型が変わっていないか
Quality: 値の分布・欠損
Lineage: 上流・下流の依存関係

10.2 ツールの地形

Monte Carlo, Metaplane, Bigeye, Anomalo: SaaS のオブザーバビリティ
Datafold: デプロイ前のデータ diff
Great Expectations: オープンソースの検証
Soda: オープン + 商用
OpenLineage + Marquez: リネージの標準

10.3 アラートの設計

Severity 等級: P1（パイプライン全面停止）/ P2（遅延）/ P3（品質）
スロットリング: 同一アラートの繰り返しを防止
オンコールローテーション: データチームで最低2名

10.4 SLO

パイプラインごとの鮮度・成功率 SLO
月間エラーバジェットの管理
違反時はデプロイ凍結・レビュー

第11章 · 実際のスタック構成5種

11.1 Startup（小規模）

ストレージ: BigQuery / Snowflake
変換: dbt
オーケストレーション: dbt Cloud のスケジュール or GitHub Actions
オブザーバビリティ: dbt tests + Elementary

11.2 Scale-up

ストレージ: Snowflake / Databricks + Iceberg
変換: dbt + 一部 SQLMesh
オーケストレーション: Dagster or Airflow
オブザーバビリティ: Monte Carlo / Metaplane

11.3 Data-heavy SaaS

ストレージ: Iceberg + ClickHouse
ストリーミング: Flink/RisingWave
変換: dbt + Spark
オーケストレーション: Dagster
オブザーバビリティ: Datadog + OpenLineage

11.4 Enterprise

ストレージ: Snowflake/Databricks + Iceberg
変換: dbt + カスタム
オーケストレーション: Airflow (Astronomer) + 一部 Dagster
契約: OpenLineage + Monte Carlo
ガバナンス: Unity/Polaris + Collibra

11.5 韓国の金融・公共

ストレージ: オンプレ Iceberg + StarRocks / Snowflake Private
変換: dbt（開発）+ Spark（プロダクション）
オーケストレーション: Airflow on Kubernetes
セキュリティ・監査: 自前構築 + Ranger/OPA

第12章 · 韓国企業の実務 Tips

12.1 採用・組織

Analytics Engineer という職種の採用が増加（カカオ・トス・Karrot・クーパンなど）
データエンジニア + アナリティクスエンジニア + データサイエンティストの3層
チーム規模が5人以上になったらツールスタックの標準化が必要

12.2 ツール導入の順序

dbt + スケジュール（シンプルに）
テスト・ドキュメントの拡充
オーケストレーション（Airflow/Dagster）
オブザーバビリティ（Monte Carlo/Metaplane）
契約（dbt Contracts/Soda）

12.3 言語・ロケール

韓国語のカラム名は避ける（互換性の問題）
タイムゾーンは UTC で保存し、分析時に KST へ変換
祝日・週末のロジックは別途管理

12.4 セキュリティ・監査

PII の検出・マスキングのパイプライン
アクセスログの長期保管
デプロイ履歴を監査で追跡可能に

第13章 · アンチパターン10選

13.1 「cron + SQL」のまま

Git・テスト・ドキュメントの不在 → 事故が頻発。

13.2 テストのない dbt

モデル数百個 → 回帰が爆増。

13.3 増分ロジックを手作業で

dbt で手作業の増分 → 保守が悪夢に。SQLMesh の検討を。

13.4 Airflow DAG のモノリシック化

1つの DAG に100個のタスク → 障害が伝播。

13.5 Dagster・Prefect・Airflow の同時運用

1社に3つはオーバーエンジニアリング。

13.6 契約なしで消費者が多数

1つの変更が5チームを壊す。

13.7 オブザーバビリティを後回し

事故をユーザーが先に発見する。

13.8 CI なしで Prod へ直接デプロイ

PR レビューの省略 → 言い訳のできないミス。

13.9 環境分離がない

Dev から Prod のデータを書き換える事故。

13.10 自動生成ドキュメントだけを信じる

自動ドキュメントは構造しか見せない。ビジネスの説明は人がやる。

第14章 · チェックリスト — データパイプライン成熟度の12項目

第15章 · 次回予告 — Season 5 Ep 5:「Semantic Layer・Metrics Store・Reverse ETL」

パイプラインがデータを作るなら、Semantic Layer は語る。Ep 5 はデータをビジネス言語につなぐ軸。

Semantic Layer の歴史と再発見
dbt Semantic Layer / MetricFlow
Cube / AtScale / Looker の意味論
Metrics Store パターン
Headless BI（Transform, Lightdash）
Reverse ETL (Hightouch, Census, Grouparoo): 分析データを運用ツールへ
Data activation の戦略
ソフトウェアエンジニアリングとの境界の消滅
韓国企業の Semantic Layer 成熟度
AI と Semantic Layer の出会い

「データの意味を一度だけ定義する」という約束の 2025年版。

次回の記事で会おう。

まとめ: 2025年のデータオーケストレーションは「パイプラインもソフトウェア」という原則が完成する段階。dbt が変換の標準となり、SQLMesh が増分・バージョンで補完し、Dagster が asset-centric なオーケストレーションとして登場した。Airflow は 3.0 の大改編で再飛躍し、Prefect 3.0 は Pythonic な代替。データ契約とオブザーバビリティがエンジニアリング品質を押し上げ、CI/CD + SLO + オンコールがデータチームの日常になった。スタックは規模・文脈によって変わるが、コア原則は「Git・テスト・契約・オブザーバビリティ・ロールバック」という5つの言葉に要約される。次回はこのすべての上に乗る「ビジネス言語で語る層」。