「毎朝6時にETL処理を回して、失敗したらSlackに通知して、自動でリトライしてほしい」「上流のジョブが終わってから下流のジョブを走らせる依存関係を管理したい」。
データパイプラインが少し育ってくると、この手の要件が必ず出てきます。cronで組んでいたころは想像しなかったところで、順番の管理や失敗のリカバリが日々の運用を重くしていきます。
正直に言うと、Airflow・Dagster・Prefectの違いは、公式ドキュメントを読み比べただけではなかなかピンときません。3つとも「DAGでパイプラインを定義してスケジュール実行する」という説明が並ぶので、選ぶ側からすると差がぼやけてしまうのです。
現場で感じるのは、この3つの違いは機能表ではなく「どの世界観に体重を預けているか」に出るということ。この記事では、Airflow・Dagster・Prefectの設計思想を4軸で並べ、チームの規模や技術スタックからどう選ぶかを、Evastの現場感覚を交えて見ていきます。
データパイプラインのオーケストレーションツールは、以下を担います。
ETLツール（trocco・Fivetran等）との違いも整理しておきましょう。ETLツールは「データをAからBへ運ぶ処理」そのものに特化しています。一方のオーケストレーションツールは、その処理を「どのタイミングで・どの順番で・何が失敗したらどうするか」という観点で管理する指揮者の役割を担います。
両者は補完関係にあり、たとえば「troccoでデータを転送するジョブをAirflowでスケジュール管理する」という使い方が一般的です。転送を担うETLツールそのものの選び方はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較で、データパイプライン全体の構成についてはデータパイプラインとは？ETLとの違いと仕組みを図解で解説で解説しています。
Apache Airflowは2014年にAirbnbで開発が始まり、2015年にOSSとして公開、2019年にApache Software Foundationのトップレベルプロジェクトに昇格したツールです。現在も最も広く使われているオーケストレーションツールで、コミュニティとコネクタの数は3つの中で群を抜いています。求人検索でも「Airflow経験者」の需要が圧倒的に多く、エンジニアの採用・育成の観点では有利です。
なお、Airflow 2.0（2020年12月リリース）でスケジューラーが大幅に刷新され、並列実行の安定性とパフォーマンスが改善されています。1.x時代の「スケジューラーが単一障害点になる」という弱点は2.x系では解消されており、現行の評価は2.x前提で行うことが重要です。
AirflowはパイプラインをDAG（Directed Acyclic Graph、有向非巡回グラフ）としてPythonコードで定義します。タスク間の依存関係を>>演算子で繋ぎ、実行スケジュールをcron式で指定します。
with DAG("daily_etl", schedule_interval="0 2 * * *") as dag:
extract = PythonOperator(task_id="extract", python_callable=run_extract)
transform = PythonOperator(task_id="transform", python_callable=run_transform)
extract >> transformコードで管理できるため、Gitでバージョン管理でき、PRレビューのフローに乗せられます。
強み：
弱点：
Evastの現場でも、Airflowの「スケジューラーが重くなる問題」は何度か遭遇しています。タスク数が1,000を超えてきた段階でKubernetesエグゼキューターへの移行を検討することが多いです。
Dagsterは2018年に開発が始まり2019年にOSSとして公開された比較的新しいツールで、開発元はDagster Labs（旧Elementl）です。Airflowの課題を解決することを明示的に目標として設計されました。
AirflowがTaskを中心に考えるのに対し、DagsterはSoftware-Defined Assets（SDA）という概念が核心です。「このJobを実行する」ではなく「このデータ資産（テーブル・ファイル・MLモデル等）を最新状態に保つ」という考え方でパイプラインを定義します。
@asset
def raw_orders(context):
return fetch_from_salesforce()
@asset
def mart_orders(raw_orders):
return transform(raw_orders)この設計の利点は、データリネージ（データの流れの可視化）が自動で生成されることです。「mart_ordersはraw_ordersから生成され、raw_ordersはSalesforceから来る」という関係が、コードから自動的にグラフとして可視化されます。
強み：
弱点：
dbt + Dagsterの組み合わせは、モダンデータスタックで採用が増えています。dbtで変換・Dagsterでオーケストレーションという分業が自然に機能します。dbtそのものの仕組みについてはdbtとは？SQLでデータ変換を行うツールの基本と導入メリットで解説しています。
Prefectは2018年創業のPrefect Technologiesが開発したツールで、「Airflowの複雑さなしに同等の機能を提供する」をコンセプトとして設計されました。
Airflowが専用のDAG定義構文を必要とするのに対し、Prefectは既存のPythonコードに@flowと@taskデコレータを追加するだけでオーケストレーションが機能します。
@task
def extract():
return fetch_data()
@task
def transform(data):
return process(data)
@flow
def etl_pipeline():
data = extract()
transform(data)既存のPythonスクリプトをほぼそのままPrefectに移行できるため、学習コストと移行コストが3つの中で最も低いです。
強み：
flow.run()でローカルでもそのまま実行できる弱点：
| 比較軸 | Airflow | Dagster | Prefect |
|---|---|---|---|
| 学習コスト | 高（独自概念多い） | 中〜高（SDA概念） | 低（Pythonそのまま） |
| スケーラビリティ | △（大規模は要設定） | ◎ | ○ |
| データリネージ | △（別途設定） | ◎（自動生成） | △ |
| dbt連携 | ○（BashOperator等） | ◎（ネイティブ統合） | ○ |
| マネージドサービス | Cloud Composer / MWAA | Dagster Cloud | Prefect Cloud |
| マネージド費用感 | 高（Composer: 月3〜10万円〜） | 中（OSS無料、Cloudは従量） | 中（OSS無料、Cloudは従量） |
| エコシステム | ◎（最大） | ○ | ○ |
| 採用・求人 | ◎ | △ | △ |
| 向いている環境 | 大規模・長期運用 | モダンデータスタック | スモールスタート・小規模チーム |
費用についても補足しておきましょう。AirflowのマネージドサービスであるCloud Composer（GCP）は、最小構成でも月3〜10万円程度のインフラ費用がかかります。Amazon MWAA（AWS）も同様の規模感です。
一方、DagsterとPrefectはOSS版をセルフホストすれば初期費用を抑えられます。Prefect CloudはFreeプラン（月間クレジット制限あり）で試験導入も可能です。セルフホストが難しい、あるいはインフラ管理を最小化したいという場合は、DagsterやPrefectのマネージドサービスの方がコスト予測がしやすいでしょう。
既存チームの規模が大きく、長期運用を前提とするなら → Airflow
求人・学習リソース・エコシステムの成熟度でAirflowが最も安全な選択です。複雑な要件にも対応でき、将来的に担当者が変わっても知見が受け継がれやすいです。ただしKubernetes等のインフラ管理コストは覚悟が必要です。
dbt + モダンデータスタックで構築するなら → Dagster
dbtとの統合、データリネージの自動可視化、テストの書きやすさ。これらを重視するなら、Dagsterはモダンデータスタックのオーケストレーションとして最も適した選択です。「どのデータがどこから来るか」を常に把握したい組織に向いています。
小さなチームでスピード重視・シンプルに始めたいなら → Prefect
Pythonのコードにデコレータを追加するだけで動き始めるシンプルさは、Prefectの最大の強みです。データエンジニアが1〜2名のスタートアップや、まずスモールスタートで試したい場合に最適です。
Evastでは規模と目的に応じて3つを使い分けています。小規模PoC段階でPrefectを使い、本番移行時にAirflowへ切り替えた事例もありますが、移行コストが発生するため、最初から想定スケールを考慮してツールを選ぶことをお勧めします。
ETLツールとオーケストレーションの組み合わせ方についてはETLとは？データ統合の基礎と選定ポイントを解説も参照してください。
株式会社Evastでは、Airflow・Dagster・Prefectすべてのオーケストレーションツールでのデータパイプライン構築実績があります。チームの規模や技術スタックを踏まえたツール選定から、実際の構築・移行までご相談いただけます。
データパイプラインとは何か、ETLとの違い（包含関係）はどこにあるのか、そして2026年時点でどう設計するのが定石か。処理タイミング（バッチ／ストリーミング）・変換の場所（ETL／ELT）・責任分担（マネージド／自作）の3軸で設計判断を整理し、Airflowによるオーケストレーション、監視・リトライ・冪等性の運用要点、AI連携で変わる新常識、Evastの現場で見た落とし穴3つまでを図解でまとめます。手作業のデータ集計を自動化したい情シス・データ担当者向け。
ETLとELTの違いと、自社に合う方式の選び方が分かります。変換のタイミングと場所・処理性能・コスト・柔軟性・セキュリティの5軸で比較表つきに整理し、ELTがModern Data Stackの主流になった背景や、raw・staging・martのレイヤー設計など導入時の注意点まで解説します。
dbtとは何かを、散らばった変換SQLの管理に悩むデータ担当者向けに解説します。ELTの「T」を担う役割、Modelファイル・ref関数・テスト・ドキュメント自動生成の4機能、BigQueryとの親和性、3ステップの導入プロセスまで整理します。
毎月の売上集計にExcelで30〜60時間かかる、共有ファイルが壊れる、関数エラーで会議が延びる。100〜1000名規模の企業でよく起こる「表計算の限界」を、構造・共同編集・自動化・信頼性の4方向から整理し、データ基盤（DWH）への移行アプローチ3種類、3〜6か月のステップ、費用の目安、よくある落とし穴までまとめました。ラーメンチェーン・ディスカウントストア・ブランドリユースの実案件で、集計時間をほぼゼロにした数値も掲載。情シス・DX推進・経営企画のマネージャーが、次の一歩を判断するための実務記事です。