Dagster とはデータアセット指向の次世代基盤

2026年6月3日

Dagster は、ジョブやタスクではなく「Software-Defined Asset（SDA）」と呼ばれるデータ資産を一級概念に据えたオーケストレータです。元 Facebook で GraphQL を開発した Nick Schrock らが 2018 年に Elementl 社（現 Dagster Labs）を立ち上げ、開発をリードしています。テーブル・ファイル・モデルなど「最終的に生成すべきもの」を Python で宣言すると、必要な計算を逆算して実行する設計が特徴で、データの鮮度や系譜（リネージ）を自動的に追跡できます。ローカル開発体験を重視した Web UI「Dagit／Dagster UI」とともに、データプロダクト開発を加速します。

この記事の目次

Asset中心のプログラミングモデル
Elementl創業からDagster Labsへ
データプロダクト運用での活躍場面
Airflowとのアーキテクチャ思想差
まとめ

Asset中心のプログラミングモデル

Dagster の中核は @asset デコレータで、関数の戻り値を Snowflake のテーブルや S3 のパーティション、Parquet ファイルなど具体的なデータ資産に対応付けます。資産同士の依存は引数を介して暗黙的に宣言され、Dagster はそのグラフから「どの資産が古くなったか」を判定し、必要な箇所だけを再計算します。これにより、従来のジョブベース基盤では難しかった部分更新や系譜の可視化を、追加実装なしに得られます。

計算の最小単位は @op と呼ばれ、複数の op を @graph で束ねることでジョブを構成します。IO Manager と呼ばれる仕組みが永続化を抽象化しているため、ローカルではファイル、本番では S3 や DWH に保存する切り替えがコードを変えずに行えます。型付けとテスト容易性が高く、CI で資産単位の単体テストを書けることが、データエンジニアの間で評価されています。

Elementl創業からDagster Labsへ

Dagster は 2018 年に Nick Schrock が Elementl 社を共同創業して開発を開始し、2019 年 4 月にオープンソースとして公開されました。Airflow が依存グラフ中心であった一方で、Dagster は「データを成果物として捉える」という発想で差別化を図り、データメッシュ運用や複数チーム所有のパイプラインに親和的なモデルを提案しました。Sequoia Capital や Index Ventures などから複数回の資金調達を行い、エコシステムを拡大しています。

2022 年には SaaS 版「Dagster Cloud」を一般提供し、Hybrid と Serverless の 2 モードを用意しました。2023 年には社名を Dagster Labs に変更し、データプラットフォームベンダーとしてのブランドを明確化しています。dbt や Airbyte、Fivetran など主要 OSS との統合パッケージが充実しており、Discord・Tencent・Mapbox などが本番採用していると公表されています。

データプロダクト運用での活躍場面

Dagster は dbt と密接に統合されており、dagster-dbt を介して dbt の各モデルを自動的に資産として取り込めます。これにより、データチームが書いた SQL モデルと Python の特徴量計算を同一の系譜上で扱え、影響範囲の波及（インパクト分析）を UI 上でたどれるようになります。BI 側のテーブルが壊れた際に、原因となった上流の資産まで遡って再実行できる体験が評価されています。

機械学習用途では、特徴量・学習データ・モデルそのものを資産として宣言し、データの鮮度や品質 SLA を基準に再計算をトリガする運用が広がりつつあります。Sensor とスケジュールを併用すれば、上流ファイルの到着を契機としたイベント駆動の起動も自然に書けるため、ニアリアルタイム要件の分析基盤にも適合します。

Airflowとのアーキテクチャ思想差

Airflow がタスク（実行命令）を中心に据えるのに対し、Dagster は資産（結果物）を中心に据える点が最大の違いです。Airflow では「DAG が成功した」事実は分かっても「どのテーブルがいつ最新化されたか」を別途記録する必要があるのに対し、Dagster ではそれが第一級の情報になっています。鮮度ポリシーや欠損アラートを Web UI から直接設定できる点も特徴です。

一方で、運用実績や Operator の網羅性、エンタープライズでの導入事例の厚みでは Airflow に分があります。既存の Airflow 資産を活かしつつ新規開発を Dagster に寄せる併用パターンや、dbt 中心の小規模チームが最初から Dagster で構築するケースなど、組織のフェーズに応じた選択が現実的です。