Dagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けを実装者目線で解説【2026年版】

Dagsterとは、データパイプラインを「実行する処理の並び」ではなく「生成されるデータ資産の集まり」として宣言するオーケストレーション基盤にあたります。読み方は「ダグスター」で、Dagster Labsが開発するApache License 2.0のオープンソースソフトウェアです。Apache Airflowが「どのタスクをどの順で流すか」を記述するのに対し、Dagsterは「どのテーブルがどのテーブルから作られるか」を記述します。この一段の抽象度の違いによって、再実行の粒度からデータ品質検査の置き場所まで、運用設計が広く変わる構造です。本記事では、資産指向の設計思想、実装コードの書き方、宣言的自動化、費用の見積り、そしてAirflowからの段階移行までを実装者の視点で整理します。

まとめ：Dagsterが宣言するのはタスクではなく生成物である

先に示す結論は明確です。Dagsterを選ぶかどうかは、機能の多寡ではなく「パイプラインの主語をテーブルに置き換えたいか」で決まります。主語がテーブルになると、依存関係はテーブル間の系譜としてUIに現れ、再実行は資産単位・パーティション単位で指定でき、品質検査は資産に付随する検査として定義可能です。逆に、扱う処理がデータ生成を伴わない汎用のバッチジョブ中心であれば、この抽象化は空回りします。

費用面は判断が分かれやすい箇所です。OSS版は無償で自前運用でき、マネージドのDagster+はSoloが月額10ドル、Starterが月額100ドルから始まります。ただし本体価格より効くのはクレジット課金で、資産のマテリアライズとopの実行が1件ずつ加算される仕組みのため、細粒度に資産を割った設計ほど請求は膨らみます。設計と課金が直結する点は最初に押さえてください（2026年7月時点の公開情報）。

Airflow資産を抱えている場合でも、全面刷新を前提にする必要はありません。dagster-airliftというツールキットが、可視化だけを行う段階から実行権限を移す段階まで4つのステップに分けた移行経路を用意しています。既存DAGを止めずに並走させられるため、切り替えの意思決定を後ろ倒しにできます。

Dagsterとは？パイプラインを生成されるデータ資産として宣言する

アセット指向という定義とタスク指向との考え方の違いを押さえる

タスク指向のオーケストレータでは、開発者は「抽出する」「変換する」「書き込む」という動詞を並べ、その実行順序を有向グラフとして宣言します。何が生成されたかは処理の副作用であり、ツールからは見えません。Dagsterはここを反転させ、「注文テーブル」「日次売上サマリ」という名詞を宣言し、それぞれの生成方法と依存元を関数として結び付けます。

この反転がもたらす実利は3つあります。第一に、系譜がコードから自動的に導出されるため、ドキュメントと実態がずれません。第二に、障害からの復旧が「壊れた資産とその下流だけを作り直す」という指定で済み、DAG全体を回し直す必要がなくなります。第三に、資産にはメタデータと検査を紐付けられるので、行数や鮮度の確認が処理の外側に散らばらずに済みました。

一方で、この抽象化は無料ではありません。既存のスクリプトをそのまま移植しようとすると「この処理は何を生成しているのか」を定義し直す作業が必ず発生します。生成物が明確でない処理には、Dagsterも従来型のジョブとopという枠組みを残していますが、そこに寄せた設計では資産指向の利点はほとんど得られないと考えてください。

AirflowやPrefectとの違いを宣言対象と検知単位で比較する

近接するツールとの差は、次の観点で整理すると判断しやすくなります。

Airflowそのものの仕組みと3系の変更点はApache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説に、Python関数をそのままフロー化する系統の考え方はPrefect（Python）とは？ワークフロー管理の使い方と3系の始め方にまとめてあります。比較検討の段階であれば、対抗馬側の記事も合わせて読むと軸が定まります。

Dagsterの構成要素をコードと実行基盤の両面から分けて把握する

assetとresourceとIOマネージャの3層でコードを組み立てる

コード側の中心は@dg.assetデコレータです。関数1つが資産1つに対応し、引数またはdepsで上流資産を指定すると、それがそのまま系譜になります。

import dagster as dg

@dg.asset
def raw_orders():
    return fetch_orders_from_api()

@dg.asset(deps=[raw_orders])
def daily_sales():
    df = read_table("raw_orders")
    write_table("daily_sales", aggregate(df))

defs = dg.Definitions(assets=[raw_orders, daily_sales])

接続情報や外部クライアントは資産の中に直接書かず、リソースとして外へ出します。こうすると本番と検証で接続先だけを差し替えられ、テスト時には偽物のリソースを注入できます。さらにIOマネージャという層を挟むと、戻り値の保存先をコードから切り離せるため、同じ資産定義のままローカルではファイル、本番ではオブジェクトストレージへ書き分ける構成が取れました。

この3層の分離は、受託開発でとくに効いてきます。案件ごとに保存先や認証方式が変わっても、資産の定義そのものは触らずに済むからです。

webserverとdaemonとコードロケーションが動く実行基盤の仕組み

自前で運用する場合、常駐させるプロセスは3種類あります。UIとGraphQL APIを提供するdagster webserver、スケジュールとセンサーと実行キューを回すdagster daemon、そして定義のメタデータを返すコードロケーションサーバです。webserverは複数レプリカに増やせますが、daemonは単一で動かす前提になっている点に注意してください。

実行履歴やイベントログの保存先は既定でSQLiteが使われ、そのままでは同時実行や複数レプリカに耐えません。検証を抜けて本番に載せる段階では、PostgreSQL側のストレージ実装へ差し替えるのが定石です。実行の launcher と executor も差し替え可能で、ローカルのサブプロセス、コンテナ、Kubernetesのポッドと、実行媒体を構成ファイルで選べます。

なお、パイプラインの入口となる差分取り込みの設計はCDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説、集計結果の格納先を列指向データベースに置く場合の判断はClickHouseとは？列指向DBの仕組み・MergeTreeの実装からBigQueryとの使い分けまで実装者向けに解説で扱っています。Dagsterはあくまで統括役なので、上流と下流の選定は別軸で決めてください。

宣言的自動化とパーティション定義によって更新条件を資産側へ実装する

AutomationConditionで動かす条件を資産の側へ持たせる実装

Dagsterには従来型のスケジュールとセンサーもありますが、資産指向を前面に出した仕組みが宣言的自動化です。「いつ動かすか」をスケジュール定義側ではなく資産の属性として書きます。

import dagster as dg

@dg.asset(
    deps=["raw_orders"],
    automation_condition=dg.AutomationCondition.on_cron("@hourly"),
)
def hourly_sales():
    ...

@dg.asset(automation_condition=dg.AutomationCondition.eager())
def sales_report():
    ...

用意されている条件のうち、実務でよく使うものは次の3つです。on_cronは指定周期に加えて上流の更新が済んでいることを待ちます。eagerは上流が更新され次第すぐ追随する条件です。on_missingは上流が揃った未生成の区画だけを埋めにいきます。単純なcronと違い、上流が失敗して古いままなら下流を動かさないという判断が組み込まれている点が違いです。

条件を評価するには、デーモン側の自動化センサーの有効化が必要です。デーモンを立てずに挙動だけ確認したい場合は、evaluate_automation_conditionsを使ってテストコード内で条件を評価できます。導入時はこの関数で意図した回数だけ発火するかを先に確かめておくと、無駄な実行による課金を避けられます。

パーティション定義と資産チェックでデータ品質を分割して検証する

日次や地域別に区切って処理する場合、資産にパーティション定義を与えると、区画ごとに独立した実行と再実行ができるようになります。過去1年分の埋め戻しも、失敗した1日分だけの作り直しも、同じ仕組みで扱えます。

この区画に対して品質検査を掛けられるのが資産チェックです。1.13では検査自体をパーティション対応にできるようになり、データセット全体ではなく特定の区画に対して検証を走らせられるようになりました。

@dg.asset_check(asset=daily_sales, partitions_def=daily_partitions)
def amount_not_null(context):
    bad = count_null_rows(context.partition_key)
    return dg.AssetCheckResult(passed=bad == 0)

検査が資産の属性として並ぶため、UI上で「この資産は最後にいつ更新され、そのとき検査を通ったか」が一箇所に集まります。品質検査を別のジョブとして切り出す構成に比べ、担当者が結果を見落としにくくなる構成でした。

1.12以降のdg CLIとコンポーネントで実装の入口が変わった

dgコマンドとComponentsが既定になった構成の実装手順を追う

2026年7月末時点のPyPI最新版はdagster 1.13.16系で、対応Pythonは3.10から3.14までです。ここ2版で入口が大きく変わったため、古い解説記事のとおりに進めると噛み合いません。1.12でdg CLIとComponentsフレームワークが正式提供に移り、新規プロジェクトの標準的な作り方として位置付けられました。

uv tool install dagster-dg-cli
dg init my_pipeline
cd my_pipeline
dg scaffold defs dagster.asset assets/raw_orders.py
dg list defs
dg dev

Componentsは、dbtやFivetranといった外部連携を、Pythonコードではなく設定ファイルで宣言する仕組みです。各コンポーネントはexecuteとget_asset_specという2つのメソッドを備え、独自の挙動が必要なら継承して差し替えられます。外部から取得したメタデータを保持する用途には、状態を設定と別に持てる基底クラスが用意されています。

1.13で入った仮想アセットとAIスキルという新しい選択肢を押さえる

2026年4月9日に公開された1.13では、実験的機能として仮想アセットが加わりました。データベースのビューのように実体の生成を伴わない対象をis_virtual付きで資産として表現し、系譜には出しつつマテリアライズは要求しない、という扱いができます。dbtのビューを自動でこの扱いにする設定も用意されました。

もう一つの追加がAIスキルです。コーディングエージェント向けの手順書を集めた公式リポジトリが公開され、dg api系のコマンドも拡張されて、ジョブや資産の状態を機械可読な形で取得できるようになっています。エージェントにパイプライン定義を書かせる運用を検討しているなら、この経路を前提に環境を組むほうが手戻りが減ります。統合本数も20種類以上が追加され、dbt Cloudや主要クラウドのストレージが標準で揃いました。

費用と移行の見積りにDagster+の課金体系と段階移行を織り込む

OSS版とDagster+の料金体系をクレジット単位で見積もる

2026年7月時点で公開されている料金体系は次のとおりです。

見積りで効くのはクレジットの定義です。資産のマテリアライズ1回とopの実行1回が、それぞれ1クレジットとして数えられます。つまり同じ処理でも、資産を細かく割るほど請求が増える設計です。加えて、実行環境をDagster側に任せるサーバーレス構成では計算時間が1分あたり0.010ドルで別途加算されます。自社インフラで実行するハイブリッド構成なら、この計算時間ぶんの課金は生じません。有料プランには30日間の試用期間が設けられています。

実務上の落とし穴は、パーティションを細かく切った資産の埋め戻しです。365区画×資産10本を作り直せば3,650クレジットが一度に発生します。パーティション粒度を決める段階で、月あたりのマテリアライズ回数を概算しておいてください。

dagster-airliftの4段階でAirflow資産を止めずに引き継ぐ

すでにAirflowで動いている資産がある場合、dagster-airliftが段階的な移行経路を提供します。第1段階のピアリングでは、AirflowインスタンスをDagsterのUIから見えるようにするだけで、実行は従来どおりAirflow側が担う仕組みです。第2段階のオブザーブでは、DAGを資産の系譜へ写像し、どのタスクがどのテーブルを作っているかをDagster側に持たせます。

第3段階のマイグレートで、タスク単位またはDAG単位に実行責任をDagsterへ移します。ここが可逆であることが大きく、1タスクずつ移して問題が出た場合も元に戻すことが可能です。最後の第4段階でAirflow側のコードを撤去します。パッケージは2026年7月時点で0.26系が公開されており、対応Pythonは本体と同じ3.10から3.14までです。MWAA向けの追加依存も用意されています。

マネージドAirflowを使っている場合の移行元の前提は、Amazon MWAAとは？Airflow 3.2対応とサーバーレス版の違い・料金・環境設計を実装者目線で解説やCloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説で費用構造を確認しておくと、移行前後の比較がしやすくなります。

Dagsterを採用する条件と、素直に見送るべき場面を切り分ける

受託の現場で判断してきた基準を、条件付きで示します。まず採用してよい場面です。第一に、パイプラインの成果物が明確なテーブルやファイルで、それらの依存関係が複雑に絡んでいるとき。系譜がコードから導出される利点が、そのまま運用コストの削減になります。第二に、dbtを軸にした変換処理を抱えているとき。dbtのモデル1本がDagsterの資産1つへ写像されるため、dbt内外の依存を一枚の系譜で扱えます。第三に、データ品質の検証を仕組みとして担保したいとき。資産チェックが標準機能である差は、実装量として明確に表れます。

逆に見送るべき場面も明確です。動かしたい処理がデータ生成を伴わない汎用ジョブ、たとえば通知の送信やファイルの転送が中心なら、資産という抽象を無理に当てはめる意味がありません。この場合はAirflowのほうが素直に書けます。運用担当者がPythonを書かず、GUIでDAGを組む前提の体制でも外れます。Dagsterはコードで定義することを前提に設計されているためです。

既存のAirflow資産が数百DAG規模で、かつ安定して回っている場合も慎重に判断してください。移行経路が用意されているとはいえ、移行工数に見合う改善が得られるかは別問題です。判断材料としては、直近半年で「どのテーブルが壊れたか特定できずDAG全体を回し直した」回数を数えるのが実務的でした。この回数が月に数回あるなら資産指向へ移す価値があり、ほとんどないなら現状維持で構いません。

費用面での見送り条件も一つ挙げます。パーティションを時間単位で切る要件があり、資産本数も多い構成では、クレジット課金が想定より膨らみます。マネージド版の見積りが自前運用の人件費を上回るなら、OSS版をKubernetes上に載せる構成を先に検討してください。

どの構成を選ぶべきかの切り分けや、取り込みから集計までを含めた基盤の設計は、データ分析基盤構築・MLOps構築支援でご相談を受け付けています。既存のAirflow環境を残したまま部分的に移す設計から対応しています。

よくある質問

Dagsterの読み方は何ですか？

「ダグスター」と読むのが一般的です。有向非巡回グラフを指すDAGと、星を意味するsterを組み合わせた造語とされています。開発元はDagster Labsで、ライセンスはApache License 2.0です。

DagsterとAirflowはどちらを選ぶべきですか？

扱う処理がデータ資産の生成であればDagster、汎用のジョブ実行が中心ならAirflowが素直です。判断の分かれ目は「壊れたテーブルだけを作り直したい場面が日常的にあるか」に置いてください。ある場合は資産単位で再実行できる差が効いてきます。

Dagsterは無料で使えますか？

OSS版は無償で、自社サーバーやKubernetes上に構築すれば費用はインフラ代のみで済みます。マネージド版のDagster+はSoloが月額10ドル、Starterが月額100ドルからで、これとは別に資産のマテリアライズ回数に応じたクレジット課金が加わります（2026年7月時点）。

dbtと組み合わせて使えますか？

組み合わせられます。dbtのモデル1本がDagsterの資産1つへ写像されるため、dbt実行の前後にある取り込み処理や配信処理と同じ系譜の中で扱えます。1.13ではdbt Cloud向けのコンポーネントも追加され、設定ファイルによる宣言だけで連携できる範囲が広がりました。

本番運用でSQLiteのまま動かしても問題ありませんか？

避けてください。既定のSQLiteストレージは検証用の想定で、同時実行やwebserverの複数レプリカに耐えません。本番へ載せる段階でPostgreSQL側の実装へ差し替え、デーモンは単一で常駐させる構成にしてください。

関連記事

• Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説
• Prefect（Python）とは？ワークフロー管理の使い方と3系の始め方
• Cloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説
• Amazon MWAAとは？Airflow 3.2対応とサーバーレス版の違い・料金・環境設計を実装者目線で解説
• CDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説
• ClickHouseとは？列指向DBの仕組み・MergeTreeの実装からBigQueryとの使い分けまで実装者向けに解説