公開2026.07.31更新2026.09.27 データ分析・BI

Dagsterとは？アセット指向の仕組み・dg CLIでの実装手順とAirflow移行を解説【2026年9月版】

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

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

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

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

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

バージョンは動いています。公式changelogの先頭は本体1.13.23／統合ライブラリ0.29.23で、PyPIのdagsterパッケージも同じ1.13.23が2026年9月16日に公開されています（いずれも2026年9月時点）。対応Pythonは3.10以上3.15未満、つまり3.10系から3.14系までです。1.12以降はプロジェクト作成のコマンド自体が入れ替わっているため、古い解説の手順をそのままなぞると最初のステップで詰まります。

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

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

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

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

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

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

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

観点	Dagster	Airflow	Prefect
宣言する単位	データ資産	タスク	タスクとフロー
依存の表現	資産どうしの系譜	DAGの実行順序	関数の呼び出し順
再実行の粒度	資産・区画単位	タスク単位	タスク単位
品質検査	資産チェックが標準	個別に実装	個別に実装
dbtとの連携	モデルを資産へ写像	コマンド実行のみ	コマンド実行のみ
向く場面	分析基盤の構築	汎用ジョブの実行	Python処理の統括

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

create-dagsterで検証環境を作り最初の資産を動かすまでの手順

uvxでプロジェクトを作成しdg devでUIを立ち上げる作業手順

1.12より前の解説ではdagster project scaffoldやdg initが入口として紹介されています。現行の手順は、それとは異なるものです。公式のプロジェクト作成ガイドが示す標準はcreate-dagsterで、uvを使う場合は仮想環境とロックファイルまで一度に生成されます。

uvx create-dagster@latest project my_pipeline
cd my_pipeline
source .venv/bin/activate
dg dev

Windowsで進めるなら3行目を.venv\Scripts\activateに読み替えてください。dg devを叩くとローカルのwebserverとdaemonがまとめて起動し、ブラウザのポート3000でUIが開きます。生成されるのはpyproject.toml、src/my_pipeline/definitions.py、src/my_pipeline/defs/、tests/という構成で、以降に書く資産はdefs配下へ置きます。

uvを入れていない環境ではpip経由でも構いません。その場合はcreate-dagster project my_pipelineのあとに自分でpython -m venv .venvを作り、pip install --editable .まで実行します。手順が1段増えるだけで、できあがる構成は同じです。

defs配下にassetを書きdg list defsで定義を確認する

プロジェクトができたら、資産のひな形をコマンドで作ります。dg CLIのコマンドリファレンスにあるとおり、dg scaffoldがファイル生成、dg listが定義の一覧、dg checkが読み込み検証を担当します。

dg scaffold defs dagster.asset assets/raw_orders.py
dg list defs
dg check defs

ここで確認したいのは3点です。dg list defsに書いたはずの資産名が並ぶか。dg check defsが定義の読み込みでエラーを出さないか。そしてUIの系譜図で、上流と下流の矢印が意図した向きに繋がっているか。この3つが揃えば、環境構築は終わりです。

逆に、ここでつまずく典型はdefs配下にファイルを置き忘れているケースでした。Dagsterはディレクトリ構造から定義を探索するため、src/my_pipeline/直下に置いたモジュールはdg list defsに出てきません。dg check defsが沈黙したまま資産が0本という状態になったら、まず置き場所を疑ってください。

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は単一で動かす前提になっている点に注意してください。

実行の launcher と executor も差し替え可能です。OSS版のインスタンス設定ドキュメントにはDefaultRunLauncher、DockerRunLauncher、K8sRunLauncherの3つが挙げられており、ローカルのサブプロセス、コンテナ、Kubernetesのポッドと実行媒体を設定ファイルで選べます。

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

dagster.yamlをPostgreSQLへ差し替える本番前の設定作業

実行履歴やイベントログの保存先として、既定で使われるのはSQLiteです。同時実行やwebserverの複数レプリカには耐えないため、検証を抜ける段階でPostgreSQLへ差し替えます。設定は環境変数DAGSTER_HOMEが指すディレクトリのdagster.yamlに書きます。

storage:
  postgres:
    postgres_db:
      username:
        env: DAGSTER_PG_USERNAME
      password:
        env: DAGSTER_PG_PASSWORD
      hostname:
        env: DAGSTER_PG_HOST
      db_name:
        env: DAGSTER_PG_DB
      port: 5432

run_coordinator:
  module: dagster.core.run_coordinator
  class: QueuedRunCoordinator
  config:
    max_concurrent_runs: 10

キー名は公式ドキュメントの記載そのままです。DAGSTER_HOMEを設定しないまま起動すると、Dagsterは一時ディレクトリを使い、プロセス終了時に実行履歴ごと消えます。検証中に「昨日の実行ログが見当たらない」となる原因はたいていこれでした。

あわせてQueuedRunCoordinatorを入れておくと、同時実行数の上限とタグ単位の制限を宣言できます。パーティションの埋め戻しで数百実行が一斉に走る構成では、この上限が外部DBやAPIの保護弁になります。

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

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と違い、上流が失敗して古いままなら下流を動かさないという判断が組み込まれている点が違いです。

条件を評価するには、UIのAutomationタブでコードロケーションを選び、default_automation_condition_sensorを有効にする操作が必要です。デーモンを立てずに挙動だけ確認したい場合は、evaluate_automation_conditionsをテストコードから呼べます。

import dagster as dg

def test_hourly_sales_fires_once():
    result = dg.evaluate_automation_conditions(
        defs=defs,
        instance=dg.DagsterInstance.ephemeral(),
    )
    assert result.total_requested == 1

導入時はこの関数で意図した回数だけ発火するかを先に確かめておくと、無駄な実行による課金を避けられます。クレジット課金はマテリアライズ1回ずつ積み上がるので、条件の書き間違いがそのまま請求に出ます。

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

日次や地域別に区切って処理する場合、資産にパーティション定義を与えると、区画ごとに独立した実行と再実行ができるようになります。過去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上で「この資産は最後にいつ更新され、そのとき検査を通ったか」が一箇所に集まります。品質検査を別のジョブとして切り出す構成に比べ、担当者が結果を見落としにくくなる構成でした。

dg CLIとComponentsで実装の入口が変わった1.13系の構成

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

2026年9月時点の本体最新版はdagster 1.13.23、統合ライブラリ群は0.29.23です。ここ2版で入口が大きく変わったため、古い解説記事のとおりに進めると噛み合いません。1.12でdg CLIとComponentsフレームワークが正式提供に移り、新規プロジェクトの標準的な作り方として位置付けられました。

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

1.13ではこの状態の保持が既定になりました。dbt、Fivetran、Airbyte、Tableau、Lookerのように外部メタデータへ依存する統合が、永続化されたローカル状態を使うようになっています。コードロケーションの読み込みが外部APIの応答時間に左右されなくなるため、起動の遅さに悩んでいた構成ほど差が出ます。

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

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

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

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

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

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

区分	月額	クレジット単価	主な制約
OSS版	無償	課金なし	自前で運用する
Solo	10ドル	0.040ドル	1ユーザー
Starter	100ドル	0.035ドル	3ユーザーまで
Pro	要問い合わせ	個別見積り	ユーザー数の上限なし

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

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

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

すでにAirflowで動いている資産がある場合、dagster-airliftが段階的な移行経路を提供します。公式の移行ガイドが定める段階は、Peer・Observe・Migrate・Decommissionの4つです。

第1段階のPeerでは、Airflow REST API経由でAirflowインスタンスをDagsterのUIから観測できるようにします。DAGが資産定義として読み込まれ、実行履歴をポーリングするセンサーが作られるだけで、実行そのものを担うのは、従来どおりAirflow側です。第2段階のObserveでは、DAG IDとタスクIDを資産の集合へ写像し、どのタスクがどのテーブルを作っているかをDagster側に持たせます。タスクが成功するたび、対応する資産にマテリアライズが記録されます。

第3段階のMigrateで、タスク単位またはDAG単位に実行責任をDagsterへ移します。ここが可逆であることが大きく、1タスクずつ移して問題が出た場合も元に戻すことが可能です。最後のDecommissionでAirflow側のコードを撤去します。公式ガイドは4段階すべてを完走する必要はないと明記しており、Observeで止めて可視化だけを得る運用も選択肢に入ります。パッケージは2026年9月時点で0.29.23が公開され、対応Pythonは本体と同じ3.10系から3.14系までです。

マネージド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上に載せる構成を先に検討してください。

バージョン追従の負荷も見積りに入れてください。1.13系は公式のリリース方針どおりセマンティックバージョニングで運用され、パッチは破壊的変更なしと約束されています。ただし1.12から1.13にかけてプロジェクト生成コマンドとコンポーネントの既定値が入れ替わったように、マイナー間では周辺の作法が動きます。社内に追従担当を置けない体制なら、その負荷ごと外部に預ける前提で見積もるのが現実的です。

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

よくある質問

導入検討の場でくり返し出る質問を、公式ドキュメントの記載と突き合わせて答えます。

Dagsterの読み方は何ですか？

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

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

扱う処理がデータ資産の生成であればDagster、汎用のジョブ実行が中心ならAirflowが素直です。判断の分かれ目は「壊れたテーブルだけを作り直したい場面が日常的にあるか」に置いてください。ある場合は資産単位で再実行できる差が効いてきます。両方を並走させる選択肢もあり、dagster-airliftのObserve段階で止めれば、実行はAirflowのまま系譜だけをDagsterで見られます。

Dagsterは無料で使えますか？

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

Dagsterの最新バージョンと対応Pythonは何ですか？

2026年9月時点で公開されている本体は1.13.23、統合ライブラリ群は0.29.23です。対応Pythonは3.10以上3.15未満で、3.10系から3.14系までが動きます。1.12より前の解説にあるdagster project scaffoldやdg initは現行の入口ではないため、create-dagsterを使う手順に読み替えてください。

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

避けてください。既定のSQLiteストレージは検証用の想定で、同時実行やwebserverの複数レプリカに耐えません。本番へ載せる段階でdagster.yamlのstorageをPostgreSQLの設定へ差し替え、デーモンは単一で常駐させる構成にしてください。DAGSTER_HOMEの設定漏れにも注意が要ります。