「毎朝6時にETL処理を実行し、失敗したらSlackに通知して自動でリトライしてほしい」「上流のジョブが終わってから下流のジョブを実行する依存関係を管理したい」——データパイプラインがある程度の規模になると、こうした要件が必ず出てきます。
これを解決するのがオーケストレーションツールです。代表的な3つ——Apache Airflow・Dagster・Prefect——はどれも「DAG（有向非巡回グラフ）でパイプラインを定義してスケジュール実行する」という基本機能は同じですが、設計思想が根本的に異なります。
データパイプラインのオーケストレーションツールは、以下を担います。
ETLツール（trocco・Fivetran等）との違いを整理しておきます。ETLツールは「データをAからBへ運ぶ処理」に特化しており、オーケストレーションツールは「どのタイミングで・どの順番で・何が失敗したらどうするか」を管理する「指揮者」の役割です。両者は補完関係にあり、「troccoでデータを転送するジョブをAirflowでスケジュール管理する」という使い方が一般的です。データパイプライン全体の構成についてはデータパイプラインとは？ETLとの違いと仕組みを図解で解説で解説しています。
Apache Airflowは2014年にAirbnbが開発し、2019年にApacheのトップレベルプロジェクトになったOSSです。現在も最も広く使われているオーケストレーションツールで、GitHubスター数は3.6万超（2025年時点）。求人検索でも「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は2019年に登場した比較的新しいOSSで、Airflowの課題を解決することを明示的に目標として設計されました。GitHubスター数は1.2万超（2024年時点）。
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は2019年に登場し、「Airflowの複雑さなしに同等の機能を提供する」をコンセプトとして設計されました。GitHubスター数は1.7万超（2024年時点）。
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も同様の規模感です。一方、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パイプラインとの違い（対立ではなく包含関係）、バッチ・ストリーミングなどの主要パターン、Airflowに代表されるオーケストレーション、監視・リトライ・冪等性という運用の要点までを図解つきで整理します。データ連携の自動化を検討し始めた担当者向けの入門記事です。
SalesforceやkintoneなどのSaaSと社内DBを自動統合するETL/ELTツールを、運用体制・コスト体系・コネクタ要件の3軸で解説します。スモールスタートに向くtrocco、非エンジニア運用に強いASTERIA Warp、クラウドDWH連携重視のFivetranなど主要10ツールの選定ポイントを、Evastの現場経験をもとにまとめました。
DWH（データウェアハウス）とは、分析専用に設計されたデータの集約場所です。通常のDB・データレイク・データマートとの違い、列指向ストレージの仕組み、BigQuery・Snowflake・Redshiftの選定ポイント、スタースキーマ・パーティション設計の基本、導入でよくある失敗まで、データ基盤の構築を検討している担当者向けに現場の視点でまとめました。
ETLとELTの違いを、変換のタイミングと場所・処理性能・コスト構造・柔軟性・セキュリティの5つの軸で比較表つきで整理します。クラウドDWHとdbtの普及によりELTがModern Data Stackの主流になった背景、自社に合う方式を選ぶ判断基準、raw・staging・martのレイヤー設計などELT導入時の注意点まで、データ基盤の方式選定に悩む担当者向けに解説します。