夜間の処理は、cronに40本ほど登録されています。深夜1時に基幹とECからデータを取り込み、2時にdbtで集計し、3時にダッシュボードを更新する流れです。ある日、取り込みが30分遅れました。dbtは予定どおり2時に走り、前の日のデータのまま集計を終えます。朝のダッシュボードは前日の数字のままで、誰も気づきません。営業は前日の在庫数を見て受注を受けました。再実行は、前任者が残したメモを見ながら、ジョブを1本ずつ手で順番に叩くしかありません。そこへ経営企画から「Airflowを入れるという話を聞いたけれど、費用はどれくらいで、何が変わるのか」と聞かれます。

オーケストレーションツールは、「Aが終わったらBを動かす」という依存関係を定義し、失敗したら再試行し、止まった箇所から再実行し、結果を通知する仕組みです。Airflow・Dagster・Prefectのどれを選ぶかは、性能の差よりも、チームが何を主役に考えたいかと、インフラを誰が運用するかで決まります。

cronで足りなくなる兆しと、ツールで変わること

cronで起きていること困ることオーケストレーターで変わること
前の処理の終了を待たず、時刻で次を動かしている遅れた日に、古いデータのまま集計が走る前の処理が成功したら次を動かす
失敗したジョブを手で叩き直している依存関係を知っている人しか復旧できない失敗した箇所から、後続ごと再実行できる
「先週金曜の分を作り直して」に応えられない日付を指定して再処理する仕組みがない対象の期間を指定して再処理（バックフィル）できる
失敗に気づくのが、利用者からの連絡朝の会議まで誰も知らない失敗をSlackやメールに通知する
ジョブが数十本を超え、全体の流れが頭で追えない前任者が異動すると止まる依存関係を画面で確かめられる

1つでも当てはまり、その影響が業務に出ているなら、導入を検討する時期です。逆に、ジョブが数本で直列の依存もなく、dbtだけで完結しているなら、dbtの実行サービスに付いているスケジューラで足りることもあります。

状況から候補を絞る早見表

自社の状況まず検討する候補これを選ぶと後で困ること
すでにAirflowが動いている、またはクラウド各社のマネージド版から選びたいAirflow概念が多く、新しく入った人が書けるようになるまで時間がかかる
dbtが中心で、表ごとの更新状況や品質の検査結果を1つの画面で見たいDagsterタスクの順番ではなく「作られるデータ」で考える発想に、慣れるまで違和感がある
Pythonのスクリプトが多く、件数が日によって変わる処理を素直に書きたいPrefect使いたいシステムとの連携部品があるかを先に確かめないと、自分で書くことになる
インフラを運用する人がいない各ツールのマネージド版（MWAA、Cloud Composer、Astronomer、Dagster+、Prefect Cloud）月額の費用がかかり、利用量によって変動する
AWSかGoogle Cloudに基盤がそろっているMWAA（AWS）、Cloud Composer（Google Cloud）メジャーバージョンを上げるときに、環境の作り直しが要る場合がある

どれを選んでも、cronの5つの困りごとは解消できます。決め手になるのは、このあとの「古い記事と違う点」と「運用の費用」です。

2026年10月時点で、古い記事と違う点

3つのツールは、ここ1〜2年で大きなバージョンアップを済ませています。検索で見つかる解説やサンプルコードには古い書き方が多いので、公式ドキュメントで確かめた主な変更を表にまとめます。

ツール変わったこと古い記事のまま書くと起きること
Airflow3.0が2025年4月22日に一般提供された。DAGやtaskの読み込み元がairflow.sdkに移り、BashOperatorなどは標準プロバイダ（apache-airflow-providers-standard）に分かれた古い読み込み元は警告が出て、将来の版で削除される
Airflowタスクの文脈からexecution_dateが削除され、logical_dateを使う。SubDAGも削除されたexecution_dateを参照する処理が動かない
Airflow過去分をまとめて実行する設定（catchup）の既定が、Falseになった既定に頼った2系のDAGは、移行後に動きが変わる
Prefect実行を担っていたagentは2系だけの仕組みで、3系ではworker（作業キューを監視して実行するプロセス）とwork pool（作業キュー）を使うprefect agent startは使えない
Prefectdbt連携は、PrefectDbtRunnerが推奨になり、DbtCoreOperationは旧APIの扱いになった旧APIの書き方で新規に作ることになる
Dagsterdbtプロジェクトを読み込む部品（DbtProjectComponent）が案内されている。dbtのテストはアセットの検査として表示される手書きの設定が増える

Airflow：実績と人材を優先するとき

Airflowは2014年10月にAirbnbで始まり、2019年1月にApacheソフトウェア財団のトップレベルプロジェクトになりました。連携部品が多く、AWSのMWAAやGoogle CloudのCloud Composerといったマネージド版もそろっています。3系での最小の例です。

import pendulum
from airflow.sdk import dag, task
from airflow.providers.standard.operators.bash import BashOperator

@dag(
    schedule="@daily",
    start_date=pendulum.datetime(2026, 1, 1, tz="Asia/Tokyo"),
    catchup=False,
    default_args={"retries": 2},
)
def daily_orders():
    extract = BashOperator(task_id="extract", bash_command="python /opt/jobs/extract_orders.py")
    dbt_build = BashOperator(task_id="dbt_build", bash_command="cd /opt/dbt && dbt build --select orders+")

    @task
    def notify_done():
        print("orders pipeline finished")

    extract >> dbt_build >> notify_done()

daily_orders()

冒頭の「取り込みが遅れたのにdbtが走った」は、extract >> dbt_buildの1行で起きなくなります。前の処理が成功するまで、次は動きません。

dbtのモデルが数百になると、dbt buildを1つのタスクで叩く形では、どのモデルで失敗したかが追いにくくなります。その段階では、dbtのプロジェクトをAirflowのDAGやタスクグループとして展開するAstronomer Cosmosを検討します。CosmosはApache 2.0ライセンスで、Airflow 2.9以上を前提にしています。

マネージド版の対応状況も確かめておきます。MWAAの対応表には、3.3.1、3.2.1、3.0.6と2系の版が並んでいます（2026年10月17日に確認）。MWAAで上げられるのはマイナーバージョンまでで、2系から3系へは新しい環境を作って移ります。Cloud Composer 3にはAirflow 3.3.1のビルドがありますが、既定のビルドは2.11.1です。

Dagster：dbtが中心で、データの状態を画面で追いたいとき

Dagsterは、タスクの順番より「どの表が、どの表から、いつ作られたか」を主役にします。作られるテーブルやファイルを「アセット」と呼び、関数の引数で依存関係を表します。

import dagster as dg

@dg.asset
def cleaned_orders(raw_orders):
    return raw_orders.dropna()

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

@dg.asset_check(asset=daily_revenue, blocking=True)
def revenue_not_negative(daily_revenue):
    return dg.AssetCheckResult(passed=bool((daily_revenue >= 0).all()))

blocking=Trueを付けた検査が失敗すると、その下流のアセットは作られません。付けない場合は、検査が失敗しても下流は動きます。品質の検査を、処理の流れの中で止める仕組みとして使えるのが特徴です。dbtのプロジェクトは部品として読み込め、dbtのモデルは1つずつのアセットに、dbtのテストはアセットの検査として表示されます。

使い方と運用の注意はDagsterとは：データアセット中心のオーケストレーターの使い方にまとめています。

Prefect：Pythonのスクリプトを、そのまま流れにしたいとき

Prefectは、Pythonの関数に@flowと@taskを付けるだけで、再試行や状態の記録がつきます。処理するファイルの数が日によって変わるような流れも、普通のforループで書けます。

from prefect import flow, task

@task(retries=2)
def process_one(path: str) -> int:
    return load_and_count(path)

@flow(name="daily-files")
def daily_files():
    futures = [process_one.submit(p) for p in list_pending_files()]
    total = sum(f.result() for f in futures)
    print(f"processed rows: {total}")

.submit()で投げたタスクは並行して動き、.result()で結果を受け取ります。本番で定期実行するときは、デプロイを作ってwork poolに割り当て、prefect worker start -p <プール名>でworkerを起動します。dbtはPrefectDbtRunner().invoke(["build"])で呼び出せ、dbtの各ノードの実行がPrefect側でタスクとして見えます。

運用の費用を、セルフホストとマネージドで比べる

3つともOSS版は無償です。しかし、セルフホストではアップデート、監視、障害対応に人の時間がかかります。マネージド版の料金は公式ページで次のとおりでした（2026年10月17日に確認）。

サービス料金の形小さく始める場合
Dagster+月額の基本料金に、クレジット（アセットの作成1回、または処理の実行1回で1クレジット）の従量課金が加わるSoloは月10ドル＋1クレジット0.040ドル（1ユーザー）。Starterは月100ドル＋1クレジット0.035ドル（3ユーザーまで）。どちらも30日の無料試用あり
Prefect Cloudプランごとの月額Hobbyは無料で、ユーザー2人、デプロイ5つ、実行履歴の保持7日まで。Starterは月100ドル、Teamは1ユーザー月100ドル
MWAA、Cloud Composer、Astronomer環境の規模と稼働時間に応じた課金金額はクラウドの料金計算ツールで、自社の構成を入れて見積もる

例で比べます。月給50万円のエンジニアがセルフホストのAirflowを保守するとします。会社の総コストは給与の約3倍で年1,800万円、年1,900時間で割ると時給は約9,500円です。保守に週4時間、年に約200時間使うと、約190万円になります。

同じ規模の処理をDagster+のStarterで動かし、1日に300回アセットを作るとします。月9,000クレジットで315ドル、基本料金と合わせて月415ドル、年に約5,000ドルです。円に直した額と、人の保守時間の約190万円を比べます。人の時間がかからないぶん、その時間を集計ロジックの改善に回せます。数字はどれも説明のための例です。

移行は、1つのジョブ群から始める

月やること終わったと言える目安
1か月目cronのジョブを一覧にし、どれがどれを待つべきかを表にする依存関係を、前任者に聞かなくても説明できる
2か月目経営向けダッシュボードにつながる1本の流れ（取り込み、dbt、更新）を移す取り込みが遅れた日に、dbtが待ってから動いた
3か月目失敗の通知と、失敗箇所からの再実行を、当番の手順書に書く当番が、メモを見ずに再実行できる
4か月目以降残りのジョブを、影響の大きい順に移すcronに残るジョブが、依存のない単発の処理だけになっている

変換の層の組み方はdbtの3層構造に、流れの途中で数字の異常に気づく仕組みはデータ品質ツールの選び方に書いています。

よくある質問（FAQ）

cronのままでよいか、ツールを入れるべきかの境目はどこですか?

前の処理の終了を待つ必要があるジョブが出てきたら、ツールを検討します。時刻だけで順番を組んでいると、どこかが遅れた日に後続が古いデータで走ります。失敗した箇所からの再実行や、日付を指定した再処理を頼まれるようになったときも、同じく境目です。

Airflowが定番なら、迷わずAirflowでよいですか?

10年以上の歴史があり、AWSとGoogle Cloudの両方にマネージド版があるので、外しにくい選択です。ただ、dbtが中心で、表ごとの更新状況や品質の検査結果を1つの画面で見たいならDagsterのほうが合います。Pythonのスクリプトを素直に流れにしたいならPrefectです。新しく作るなら、どれを選んでも3系や最新版の書き方で始めます。

Airflow 2系で動いているDAGは、3系でそのまま動きますか?

動かない場合があります。3系では、タスクの文脈からexecution_dateが削除され、SubDAGもなくなりました。読み込み元もairflow.sdkや標準プロバイダに移っています。過去分をまとめて実行する設定の既定もFalseに変わりました。移行前に公式の移行ガイドで、自社のDAGが使っている機能を1つずつ確かめます。

dbtの実行サービスのスケジューラがあれば、オーケストレーターは要りませんか?

処理がdbtだけで完結しているなら、そのスケジューラで足りることもあります。データの取り込み、品質の検査、外部システムへの書き戻しなど、dbt以外の処理と順番を組む必要が出てきたら、全体の流れを管理するオーケストレーターを置きます。

マネージド版とセルフホストは、どう選べばよいですか?

インフラを運用できる人がいるかどうかで決めます。セルフホストはソフトウェアの費用がかからない代わりに、アップデートや障害対応に人の時間がかかります。その時間を、給与の約3倍を年1,900時間で割った時給で金額にし、マネージド版の年額と比べます。運用する人が1人しかいないなら、マネージド版のほうが止まりにくくなります。

出典

前任者のメモを見ながらジョブを手で叩き直している状態なら、cronの依存関係を棚卸しするところから一緒に整理します。初回相談（30分・無料）で一緒に整理できます。