Airflowでデータパイプラインを動かしていると、ある違和感に気づきます。Airflowが管理しているのは「タスクの実行」であり、「データそのもの」ではありません。テーブルが正しく作られたか、最後に更新されたのはいつか、どのテーブルがどこから派生しているか。こうした「データ側の事実」はAirflowの外で別途管理することになります。

Dagsterは、この違和感を出発点にしたオーケストレーターです。タスクではなく「データアセット（作られるテーブルやファイル）」を主役にし、リネージ・メタデータ・品質チェックがフレームワークに組み込まれています。dbt中心のデータ基盤と特に相性が良い、モダンな選択肢です。

Software-Defined Asset：データを主役にする

Dagsterの中核概念が「Software-Defined Asset（SDA）」です。「このテーブルは、これらの入力アセットから、このコードで作られる」という宣言を、Pythonで書きます。

from dagster import asset

@asset
def raw_orders():
    # 取り込み処理
    return load_orders_from_source()

@asset
def cleaned_orders(raw_orders):
    # cleaningロジック
    return raw_orders.dropna()

@asset
def daily_revenue(cleaned_orders):
    return cleaned_orders.groupby("date")["revenue"].sum()

関数の引数に他のアセットを取ると、自動的に依存関係が解釈されます。`daily_revenue`は`cleaned_orders`に、`cleaned_orders`は`raw_orders`に依存する、というDAGが構築されます。タスクの並びを書くより、「データはこう作られる」を宣言する書き方です。

dbtとのファーストクラス統合

Dagsterの真価が出るのが、dbtとの統合です。`@dbt_assets`デコレータでdbtプロジェクトを読み込むと、各モデルが自動的にDagsterのアセットになります。

from dagster_dbt import dbt_assets, DbtCliResource

dbt = DbtCliResource(project_dir="/opt/dbt")

@dbt_assets(manifest=dbt.cli(["parse"]).target_path)
def my_dbt_assets(context, dbt: DbtCliResource):
    yield from dbt.cli(["build"], context=context).stream()

これだけで、dbtの各モデルが個別のアセットとしてDagster UIに表示され、モデル単位で実行・再実行・依存追跡ができます。AirflowでCosmos相当の機能が、Dagsterでは標準で組み込まれているイメージです。dbt実装の基本はdbt実装ガイドを参照してください。

リネージとメタデータが標準

Dagsterは、定義したアセットのリネージを自動でUIに描画します。「このダッシュボードのデータはどこから来ているか」が、コードを読まずに視覚的に追えます。さらに、各アセットの実行履歴、行数、品質チェック結果といったメタデータが一緒に表示されます。

from dagster import asset, AssetCheckResult, asset_check

@asset
def daily_revenue(cleaned_orders):
    return cleaned_orders.groupby("date")["revenue"].sum()

@asset_check(asset=daily_revenue)
def revenue_not_negative(daily_revenue):
    return AssetCheckResult(
        passed=(daily_revenue >= 0).all(),
        metadata={"min": float(daily_revenue.min())},
    )

`@asset_check`でアセットに紐づく品質チェックを定義できます。実行されると、結果がアセットのメタデータとして残り、UIから追跡できます。品質運用はオーケストレーターと一体化しているのが、Dagsterの世界観です。データ品質ツールとの組み合わせはデータ品質ツール選定ガイドに整理しています。

Dagster OSSとDagster+（旧Dagster Cloud）

Dagster OSSDagster+
提供形態OSS（自前デプロイ）SaaS（マネージド）
UI・ローカル開発同じ同じ＋クラウド管理機能
マルチテナント・組織機能無し有り
監査ログ・SSO無し有り
費用無料（インフラコストは別途）規模に応じた課金

個人や小チームならOSSで十分回ります。組織として複数チームに展開する、SSO・監査ログが要件、運用負荷を下げたい、といった段階でDagster+を検討します。

運用上のハマりどころ

  • asset思考への概念転換：Airflowで慣れたTaskの並びの発想から、アセット中心の発想への切り替えが必要。最初の数週間は違和感がある。
  • パーティション設計：日付やバックフィルを扱うには、Partitioned Assetの概念を理解する必要がある。学習コストはあるが、効果は大きい。
  • 大規模dbtプロジェクト：dbtモデルが数百を超えると、Dagster UIの描画と起動時間が気になる。マニフェストのキャッシュ戦略を活用する。
  • コミュニティ規模：Airflowに比べると、求人や情報量で劣る。トラブルシュートで公式ドキュメント中心になる。

向く・向かない場面

  • 向く：dbt中心のデータ基盤、データ品質運用と統合したい、リネージを自動で持ちたい、新規プロジェクトでモダンな設計をしたい、開発体験を重視
  • 向かない：既存Airflow資産が大きく移行コストが見合わない、エコシステムの厚さ・求人重視（→Airflow）、シンプルなPython中心の運用（→Prefect）

まとめ

  • Dagsterは「タスクではなくデータ（アセット）を主役にする」モダンなオーケストレーター。
  • Software-Defined Assetで、データの作り方を宣言的に書く。
  • dbtとのファーストクラス統合があり、モデル単位の運用が標準で可能。
  • リネージ・品質チェックがフレームワークに組み込まれており、別ツール不要で開始できる。
  • 新規でdbt中心の基盤を作るなら、有力な選択肢。

全体像はオーケストレーター選び方ガイド、隣接の選択肢はAirflow とは・Prefect とはにあります。Dagsterの導入や設計の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. Airflowから移行する価値はありますか？

A. 既存Airflowが十分回っているなら、無理に移行する必要はありません。Airflowもエコシステム（Cosmos等）でアセット思考に近づいています。新規プロジェクトでdbt中心の基盤を作るときや、リネージ・品質運用を最初から組み込みたいときに、Dagsterは有力な選択肢になります。移行は段階的に、新しい領域からDagsterで作り、既存はAirflowに残す併走運用が現実的です。

Q. Dagsterは小規模でも使えますか？

A. 使えます。ローカル開発のしやすさと、UIの分かりやすさは小規模でも価値があります。少人数で「将来データ基盤として育てていきたい」場面では、最初からDagsterで始める判断もあります。一方で、ジョブが数個のレベルならcronやdbt Cloudのスケジューラで足り、オーケストレーター自体が過剰、というケースもあります。

Q. dbtのプロジェクトを丸ごとアセット化するときの注意点は？

A. dbtのモデル数が増えると、Dagsterの起動時に毎回dbtのmanifestを解析するコストが見えてきます。プロジェクトの大きさによっては、manifestをキャッシュする戦略（ビルド時に生成・コミット）を採るのが定石です。dbtでの層分けの実装はdbt実装ガイド、incremental設計はincremental models設計もあわせて参考にしてください。

Q. 品質チェックは、Dagsterだけで完結しますか？

A. シンプルなチェック（行数・範囲・null）はDagsterの`@asset_check`で書けます。より高度な検証（統計的な検査、宣言的YAML、複数プロジェクトの集約管理）は、Great Expectations・Soda・Monte Carloといった専用ツールを併用すると、それぞれの強みを活かせます。整理はデータ品質ツール選定ガイドを参照してください。