Apache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価

Apache Airflowの定義と歴史

Apache Airflow は、Airbnb が 2014 年に社内ツールとして開発し、2016 年に Apache Software Foundation の Incubator へ寄贈されたワークフロー管理ツールです。2019 年に Top-Level Project に昇格し、現在はApache Airflow 公式サイトで安定版が継続的にリリースされています。執筆時点（2026年6月）では Airflow 2 系の運用事例が中心ですが、メジャーバージョンや Provider パッケージは頻繁に更新されます。採用時は、利用中のクラウドサービスや Provider 互換性も含めて、公式リリースノートで対応状況を必ず確認してください。

「Workflow as Code」を中心思想に据えていることが大きな特徴で、ジョブ定義を YAML や GUI ではなく Python のコードとして書きます。Git でレビュー可能になる代わりに、データエンジニアにも一定のソフトウェアエンジニアリングスキルを求められる設計です。

DAG・タスク・オペレーターの基本

Airflow のジョブは DAG という単位で表現されます。DAG（Directed Acyclic Graph）は「依存関係に沿って一方向に進み、ループしないグラフ」のことです。

• DAG: 1つのワークフロー全体。スケジュール、開始日、リトライ方針などのメタ情報を持つ

• タスク: DAG を構成する1つの処理単位。S3 からのダウンロード、SQL 実行、Slack 通知などが該当する

• オペレーター: タスクの実装テンプレート。PythonOperator、BashOperator、PostgresOperator など処理の種類ごとに用意される

• タスクインスタンス: 特定の実行日付における具体的なタスクの記録（成功・失敗・スキップが記録される）

「PythonOperator で集計関数を呼び出し、その結果が出揃ったら S3Operator でアップロード」のように、オペレーターを組み合わせてフローを表現します。新しい書き方として TaskFlow API（@task デコレーター）も用意されており、関数を書く感覚で依存関係を組めるようになっています。

仕組み・アーキテクチャ

Airflow のコンポーネントは大きく4つに分かれます。役割を把握しておくと、トラブル時の切り分けが速くなります。

Scheduler / Webserver / Executor / Workerの役割

Metadata DB（PostgreSQL や MySQL が一般的）が DAG の状態・タスクの実行履歴・接続情報（Connection）・変数（Variable）を保存します。この Metadata DB が単一障害点になりやすいため、本番運用では可用性要件に応じて HA 構成やバックアップ・復旧設計を検討する必要があります。

実行モデル（Executor の種類）

Executor は処理規模に応じて選択します。

• SequentialExecutor: ローカル検証用。タスクを順番に1つずつ実行。SQLite と組み合わせる軽量構成

• LocalExecutor: 1台のマシン内で並列実行。小規模本番〜検証で採用例あり

• CeleryExecutor: Celery + Redis/RabbitMQ で分散実行。歴史が長く、参考事例が多い

• KubernetesExecutor: タスクごとに Kubernetes Pod を起動。リソース効率が高くスケールしやすい

• CeleryKubernetesExecutor: 両者のハイブリッド。バースト処理に Kubernetes、定常処理に Celery を使う

クラウドのマネージドサービス（AWS の MWAA、GCP の Cloud Composer など）では実行基盤の多くをサービス側が管理しますが、内部構成や選べる実行方式・運用上の制約はサービスごとに異なります。採用前に対応バージョンや料金体系を必ず確認してください。

できること（主要なユースケース）

Airflow は依存関係のある定期実行・バッチ処理の管理に特に向いています。実務で多いユースケースは次の3つです。

データパイプライン（ETL / ELT）

最も典型的な用途です。データソースから抽出し、変換し、DWH へ投入する流れを DAG として表現します。

• 業務 DB からBigQuery・Snowflake・ClickHouseなどの DWH へ日次同期する

• AWS S3 に届いた CSV を検知し、変換・ロードする

• Apache Spark や Databricks のジョブを Airflow から起動する

ELT 構成では、変換（T）部分を dbt に任せて Airflow は dbt の実行制御に専念する分担パターンも一般的です。

機械学習ワークフロー（MLOps）

学習データの作成 → 特徴量生成 → モデル学習 → 評価 → デプロイの一連を DAG で組みます。MLflow や SageMaker と組み合わせるパターンが多く、MLOps や MLOpsエンジニア 領域でも採用されることが多く、案件によっては評価されやすいスキルです。

ML 専用の Kubeflow Pipelines や Metaflow と比較されることもありますが、Airflow は「データ部門のスケジューラが既にあり、そこに ML を載せたい」という現場で選ばれる傾向があります。

業務システム連携・定期ジョブ

請求書発行、メール配信、外部 API 同期など、cron + シェルで運用していたバッチを移行する用途も実務では多いです。失敗時の再実行、SLA 監視、ログ集約が UI 上で完結する点が cron との大きな差です。

Airflowに関するミニFAQ

Q. Airflow でリアルタイム処理（ストリーミング）はできますか？

A. 設計思想はバッチ寄りで、秒単位のストリーミングには向きません。Kafka や Kinesis、Spark Streamingを別途用意し、Airflow はそれらのジョブ起動・補完バッチに使うのが現実的です。

Q. cron との一番の違いは何ですか？

A. cron は「いつ動かすか」だけを管理しますが、Airflow は依存関係・リトライ・タイムアウト・通知・履歴まで含めて1つのプラットフォームで扱える点です。ジョブ数が増えるほど差が大きくなります。

dbt / Dagster / Prefect / Step Functions との違い

Airflow と比較されやすい4ツールを並べると整理しやすくなります。

dbt は Airflow の「対抗」ではなく、Airflow から呼び出される側として共存するケースが多いです。一方 Dagster や Prefect は Airflow と置き換え可能なポジションで、新規構築では Dagster / Prefect が候補に挙がるケースもあります。判断軸としては「データアセットの可観測性を重視するなら Dagster、運用の手軽さや Python ファーストな書き心地なら Prefect、既存運用に乗せやすさや採用しやすさなら Airflow」という整理が実務に近いです。

違いに関するミニFAQ

Q. dbt が使えれば Airflow は不要ですか？

A. dbt は変換層の責務に絞られているため、抽出（E）やロード（L）、ML パイプライン、外部 API 連携まではカバーできません。dbt と Airflow を併用するか、dbt Cloud のスケジューラで小規模に済ませるかは、扱うワークロード次第です。

案件単価・市場動向

Airflow 単体での求人より、「データエンジニア」「データ基盤エンジニア」「MLOpsエンジニア」のスキル要件のひとつとして Airflow が記載されるパターンが多い傾向があります。

案件で求められるスキルセット

ここから紹介する単価感やスキルセットは、2026年6月時点で主要フリーランスエージェント数社の公開案件ページ（業務委託・週3〜5日相当）を目視確認した範囲を母集団としています。エージェント非公開案件や直案件は含まないため、あくまで一目安として読んでください。

公開案件の観測範囲では、Airflow 案件は単独スキルではなく以下と組み合わさるケースが目立ちました。

• SQL / Python：必須。データ加工とパイプライン実装の両方で使う

• クラウド：AWS（S3 / RDS / EMR / MWAA）または GCP（BigQuery / Cloud Composer）の運用経験

• DWH：BigQuery・Snowflake・Redshift・Databricks のいずれかでの構築経験

• CI/CD・IaC：Terraform、GitHub Actions、ArgoCD などでデプロイ自動化に絡んだ経験

• コンテナ：Docker、Kubernetesの基礎知識

単価の目安

同じく2026年6月時点で確認した公開案件では、Airflow を求めるデータ基盤系案件は月額60〜100万円前後の募集が中心でした。稼働日数・リモート可否・契約形態（業務委託／準委任）で大きく振れるため、以下はあくまで観測ベースの目安として読んでください。

• 月額60〜70万円台：Airflow で既存パイプラインの保守・改修・障害対応を任されるレンジ。データ基盤またはETL運用の実務1〜3年程度があり、既存DAGの改修・障害調査・SQL修正を一人称で進められる層が対象になりやすい印象

• 月額80〜100万円台：DWH 移行プロジェクトや MLOps 基盤の設計に踏み込めるレンジ。Airflow に加えて DWH（BigQuery／Snowflake／Redshift）の構築経験があり、設計やリードを任せられる人が対象

• 月額100万円超：上流設計や基盤刷新を含む高難度案件、または複数案件を並行するケースで見られます。Airflow に加え Spark・Kubernetes・データ基盤アーキテクチャ全体を任せられる経験（5年以上のデータ基盤経験＋クラウド設計の実績）を提示できる人が対象になりやすい印象

1案件で月額100万円超が一般的というわけではなく、条件と人物像がそろってはじめて到達するレンジである点に注意してください。年収や案件動向のより広い文脈はデータエンジニアとはやPythonの年収・キャリアも合わせて参照してください。

単価に関するミニFAQ

Q. Airflow だけ覚えれば案件は取れますか？

A. 公開案件を見る限りでは、Airflow 単独よりも SQL・Python・クラウド DWH とセットで要件化されることが多い傾向です。Airflow を軸足にしつつ、SQL／Python／DWH のいずれかを実務レベルで提示できる状態を目指すと案件選択肢が広がります。

学習ロードマップ

Airflow は「動かすだけ」と「本番で運用する」の難易度差が大きいツールです。段階を分けて進めるのが現実的です。

ステップ1: ローカルで触る（1〜2週間）

公式のQuick Startを参考に、Docker Compose でローカル起動するところから始めます。PythonOperator で簡単な DAG を書き、UI からの手動実行・ログ確認・リトライ設定を体験してください。

ステップ2: 実データで小さく組む（2〜4週間）

CSV → S3 → BigQuery／Snowflake などの小規模 ETL を実装します。Connection と Variable の使い方、Sensor（外部状態を待つ仕組み）、Branch（分岐）に触れておくと現場で困りにくくなります。

ステップ3: クラウドのマネージドサービスで運用する

MWAA、Cloud Composer、Astronomer のいずれかを触ります。自前で Airflow を立てる構成は学習コストが高いため、初手はマネージドで構築フローを体験しつつ、内部のコンポーネント構成を理解する流れが効率的です。

ステップ4: テスト・CI/CD・観測性

pytest による DAG のユニットテスト、CI で DAG 構文をチェックする仕組み、SLA Miss や失敗時の Slack / PagerDuty 通知などまで一通り組めると、案件で任される範囲が広がります。

よくある失敗と対策

実務で起きやすい失敗を3つ挙げます。

DAG ファイルが重くて Scheduler が遅延する

DAG ファイルのトップレベルで重い処理（DB クエリ・外部 API 呼び出し）を書いてしまうと、Scheduler が DAG を解析するたびに実行され、全体が遅延します。重い処理は必ずタスクの中に入れるのが鉄則です。

タスク間で巨大なデータを XCom で受け渡す

XCom（タスク間のデータ受け渡し機構）は Metadata DB に保存されるため、数 MB 以上のデータを流すと DB が肥大化します。大きなデータは S3 や GCS にファイルとして置き、パスだけ XCom に乗せる方式が無難です。

タイムゾーン設定を曖昧にする

Airflow ではタイムゾーン設定を明示しないと UTC 基準で解釈されやすく、ビジネス側は JST で会話することが多いためズレが事故になりがちです。schedule や start_date のタイムゾーンを明示しないと「想定の時刻に動かない」事故が起きます。pendulum ライブラリを使った明示的なタイムゾーン指定を最初から徹底するとよいです。

実践チェックリスト

新規プロジェクトで Airflow を導入する前に、以下を確認しておくと事故を減らせます。

• 構築は MWAA / Cloud Composer / Astronomer などマネージドを優先するか

• Metadata DB のバックアップとリストア手順は決まっているか

• DAG のデプロイは CI/CD 化されているか（手動アップロードを避ける）

• 失敗通知の経路（Slack・PagerDuty・メール）と SLA Miss の閾値は合意できているか

• DAG ファイル内で重い処理をトップレベルに書いていないか

• XCom に大きなオブジェクトを乗せていないか

• タイムゾーンは pendulum で明示しているか

• 機密情報は Connection / Variable / Secrets Backend のいずれで管理するか決めたか

まとめ

Apache Airflow は、データ基盤・MLOps・業務バッチを Python コードで一元管理できるワークフローオーケストレーターです。dbt と組み合わせれば現代的な ELT 構成が組め、Dagster や Prefect とは思想が異なる選択肢として共存しています。

• DAG・タスク・オペレーターの3要素を理解すれば、cron + シェル運用は段階的に置き換えられる

• Scheduler / Webserver / Executor / Worker の役割と Metadata DB の責務を押さえると運用設計が安定する

• ELT・MLOps・業務バッチが3大ユースケース。リアルタイム処理には向かない

• 単独スキルでは案件取得が難しく、SQL・Python・クラウド DWH との組み合わせで評価が伸びやすい

• 学習はローカル Docker → クラウドマネージド → CI/CD・観測性の順が現実的

• 設計段階で「DAG ファイルを軽く保つ」「XCom に大きなデータを載せない」「タイムゾーンを明示する」を徹底する

データ基盤キャリアで Airflow を軸にしたい方は、まずデータエンジニアとはで職種像を確認し、関連スキルのPython・Apache Spark・Databricks・MLOpsの記事もあわせて読むと案件選びの視野が広がります。

参考リンク：

• Apache Airflow 公式サイト

• Apache Airflow 公式ドキュメント

• Astronomer Registry（オペレーター・プロバイダの検索）