Apache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説

Apache Airflowは、データパイプラインのタスクをPythonのコードで定義し、依存関係の順序どおりに実行・監視するワークフローオーケストレーションツールです。2025年4月22日にメジャーアップデートのAirflow 3.0がGA（正式リリース）となり、DAGのバージョニングやReactで作り直した新UI、タスクをどんな環境でも実行できるTask Execution APIが加わりました。この記事では、DAG・Operator・Scheduler・Executor・XComといった中核概念から、TaskFlow APIでのDAGの書き方、Airflow 3の新機能、JenkinsやPrefectとの違い、pipでの導入までを最新版（3.3.0時点）を基準に整理します。

まとめ：Apache Airflowの要点

• 正体：ワークフローをPythonコードで定義し、スケジュール実行・依存関係の制御・失敗時のリトライ・監視を担うオーケストレーションツール。GUIでポチポチ組むのではなく「コードとしてのパイプライン（Pipeline as Code）」が思想の中心。
• 中核概念：DAG（実行順序を表す有向非巡回グラフ）／Operator・Task（1つ1つの処理）／Scheduler（実行タイミングの管理）／Executor（タスクをどこで動かすか）／XCom（タスク間のデータ受け渡し）。
• 最新動向：Airflow 3.0が2025年4月22日にGA、記事執筆時点の最新は3.3.0。対応Pythonは3.9〜3.12。2系から3系へは破壊的変更があり、SubDAGの廃止やタスクからのメタデータDB直アクセス禁止などに注意が必要。
• 向き・不向き：バッチ的なデータ処理・ETL・機械学習パイプラインの定期実行に強い。ソースコードのビルド／テスト／デプロイが主目的ならCI/CDツール（Jenkins等）のほうが適する。

以下、定義・仕組み・書き方・Airflow 3の新機能・他ツールとの比較・導入の順に見ていきます。オーケストレーション以外の層を含めたデータ処理基盤の全体像はデータパイプラインの構成要素と設計原則で整理しています。

Apache Airflowとは何か

Apache Airflowは、Airbnbが2014年に社内ツールとして開発し、その後Apache Software Foundationのトップレベルプロジェクトになったオープンソースソフトウェアです。ライセンスはApache License 2.0で、無償で利用・改変・商用利用ができます。「ワークフローをPythonで書き、スケジュールに従って実行し、Web UIで状態を見る」という一連の流れを1つのプラットフォームで完結させる点が特徴です。

cronや自作スクリプトとの違い

「定期実行ならcronでいいのでは」という疑問がまず出ます。cronは決まった時刻にコマンドを叩くだけで、タスク同士の依存関係（AとBが終わってからCを実行する）、失敗時のリトライ、途中から再実行、実行履歴の可視化といった仕組みを持ちません。処理が10個20個と増え、途中で失敗したタスクだけをやり直したい、前段の完了を待って後段を動かしたい、といった要求が出た時点でcronと自作のシェルスクリプトは破綻します。Airflowは依存関係・リトライ・スケジューリング・監視をまとめて引き受けるために存在します。

最新バージョンとリリースの動向

2025年4月22日にAirflow 3.0が正式リリースされ、これはプロジェクト史上でも大きなアーキテクチャ刷新となりました。記事執筆時点での最新安定版は3.3.0で、対応Pythonバージョンは3.9・3.10・3.11・3.12です。バージョンの進みが速く、機能名（DatasetがData Assetへ改称など）も変わるため、実装時は必ず自分が使う版の公式ドキュメントで確認してください。これから新規に採用するなら、2系ではなく3系を前提にするのが妥当です。

Apache Airflowの仕組みと中核概念

Airflowを理解する近道は、登場する部品の役割分担を押さえることです。読者が別々に検索する概念でもあるため、DAG・Operator/Task・Scheduler/Executor・XComに分けて説明します。

DAG（有向非巡回グラフ）

DAG（Directed Acyclic Graph）は、Airflowにおけるワークフローそのものを指します。「有向」は処理に向き（順序）があること、「非巡回」は一度通ったタスクへ戻るループがないことを意味します。1つのDAGファイル（Pythonスクリプト）が1つのワークフローに対応し、その中でタスクの実行順序と依存関係を定義します。「毎日0時に、抽出→変換→書き込みの順で走らせる」といった設計図がDAGです。

OperatorとTask

Operatorは「1つの処理の型」です。シェルコマンドを実行するBashOperator、Python関数を実行するPythonOperator、外部の状態が整うまで待つSensorなど、種類ごとにテンプレートが用意されています。Operatorをパラメータ付きでDAGの中にインスタンス化したものがTaskで、実際の実行単位になります。データベースやクラウドサービスと連携するOperatorは、後述するprovidersパッケージとして本体とは別に配布されています。なおAirflow 3では、よく使うBashOperatorやPythonOperatorが本体からapache-airflow-providers-standardへ分離された点に注意が必要です。

SchedulerとExecutor

Schedulerは、DAGに書かれたスケジュールを読み取り、「いま実行すべきタスクはどれか」を判断してキューに積む常駐プロセスです。実際にタスクを動かす場所を決めるのがExecutorで、主に4種類あります。

Executorは設定ファイルの[core].executorで指定します。Airflow 2.x系の途中から複数Executorの併用が可能になり、カンマ区切りで複数指定してタスクごとに実行先を振り分けることもできます。まずはLocalExecutorで動かし、負荷が増えたらCeleryやKubernetesへ移行するのが定番です。

XCom（タスク間のデータ受け渡し）

XCom（Cross-Communication）は、あるタスクの結果を後続タスクへ渡す仕組みです。前段が返した小さな値（ファイルパスや件数など）を後段が受け取れます。ただしXComはメタデータデータベースに保存されるため、大きなデータそのものを流すのには向きません。DataFrameやファイルの実体はS3やデータベースに置き、XComでは「その場所を指す参照（キーやパス）」だけを渡すのが実務の鉄則です。

DAGの書き方：TaskFlow APIと従来スタイル

Airflowには2つの記法があります。1つはOperatorを明示的にインスタンス化して>>で依存を結ぶ従来スタイル、もう1つがPython関数にデコレータを付けて自然に書くTaskFlow APIです。TaskFlow APIでは関数の戻り値が自動的にXComとして次のタスクへ渡るため、コードが読みやすくなります。Airflow 3では、DAG定義のインポート元がairflow.sdkに統一されました（従来のairflow.modelsやairflow.decoratorsからのインポートは非推奨で、将来削除予定）。

from airflow.sdk import dag, task
from datetime import datetime

@dag(schedule="@daily", start_date=datetime(2025, 1, 1), catchup=False)
def etl_pipeline():
    @task
    def extract():
        return {"records": 100}

    @task
    def transform(data):
        return {"value": data["records"] * 2}

    @task
    def load(payload):
        print(f"loaded: {payload['value']}")

    load(transform(extract()))

etl_pipeline()

この例ではextractの戻り値がtransformへ、その戻り値がloadへと自動で渡ります。関数の呼び出し関係を書くだけで依存関係が組み上がるのがTaskFlow APIの利点です。catchup=Falseは、start_dateから現在までの未実行分をまとめて走らせない設定で、初回起動時の意図しない大量実行を防ぐ定番の指定です。

Airflow 3で何が変わったか（2系からの新機能と破壊的変更）

ここが本記事の中心です。Airflow 3は単なる機能追加ではなくアーキテクチャの刷新で、2系の情報のまま実装すると動かない箇所があります。競合記事が機能紹介で止まりがちな「移行で詰まる破壊的変更」まで踏み込みます。

DAGバージョニング

2系までは、DAGの実行中にコードを差し替えると途中から新しい構造が混ざり、履歴の解釈が難しくなる問題がありました。Airflow 3では実行開始時点のバージョンで最後まで走り切るようになり、UIやAPIから各実行がどのバージョンのDAG（タスク構成・コード・ログ）で動いたかを遡れます。これはユーザー調査で最も要望が多かった機能で、バックフィル（過去分の再実行）の安全性向上にもつながっています。

新UIとTask Execution API

UIはReactとFastAPIで完全に作り直され、タスク中心の見方とアセット中心の見方を行き来しやすくなりました。加えてTask Execution API（AIP-72）が導入され、タスクをメタデータDBから切り離した状態で、任意の環境・任意の言語から実行できるようになりました。前述のEdgeExecutorはこの仕組みの上に成り立っており、IoTや地理的に分散したパイプラインなど、中央のデータセンター外でタスクを走らせる用途に道が開けています。

データアセットとイベント駆動スケジューリング

2系のDataset（データセット）はData Asset（データアセット）へ改称・再設計され、@assetデコレータで宣言できるようになりました。さらにWatcherにより、外部データシステムの更新やイベント到着をトリガーにワークフローを起動するイベント駆動スケジューリングが強化されています。「毎時実行」といった時刻ベースだけでなく「データが届いたら動く」設計が書きやすくなりました。ストリーミング基盤と組み合わせる場合は、メッセージ配信を担うApache Kafkaが選ばれる理由もあわせて押さえておくと構成を描きやすくなります。

2系からの破壊的変更（移行前に必ず確認）

Airflow 3はメジャーリリースであり、次のような破壊的変更を含みます。移行前にチェックすべき代表的な項目です。

• SubDAGの廃止：SubDagOperatorは無くなり、TaskGroupやData Aware Scheduling（アセット連携）で置き換えます。
• タスクからのメタデータDB直アクセス禁止：Operator内でDBセッションを開いてメタデータDBを直接触るコードは動きません。カスタムOperatorを持っている場合は要見直し。
• 標準Operatorの分離：BashOperator／PythonOperatorなどが本体からapache-airflow-providers-standardへ移動しました。
• Flask AppBuilderの分離：本体から外れ、別のprovider（FABプロバイダ）として提供されます。

移行の当たりを付けるには、公式が用意したDAGアップグレードチェックが有効です。これは静的解析ツールRuffのルールとして提供され、AIR301・AIR302が破壊的変更に該当する箇所を指摘します。手作業でDAGを1本ずつ読む前に、まずこのチェックで機械的に洗い出すのが移行コストを下げる近道です。本番を止めないためにも、いきなり全DAGを3系へ上げるのではなく、Ruffチェック→サンドボックスでの検証→段階移行の順を守るべきです。Airflow外でコードベースの分散実行を検討している場合は、別アプローチとしてTemporal Workflowの仕組みと比較しておくと選定の軸が増えます。

他のワークフロー・自動化ツールとの比較

「Airflow vs 〇〇」で迷う人が多いため、混同しやすいツールとの違いを整理します。最初の分かれ道は「ソフトウェアのCI/CD」なのか「データのオーケストレーション」なのかです。

Airflow vs Jenkins

JenkinsはCI/CDツールで、本来はソースコードのビルド・テスト・デプロイを自動化するためのものです。プラグインでデータ処理を回すこともできますが、タスク間の複雑な依存関係の管理、スケジューリング、再実行やバックフィルといったデータパイプライン特有の要件はAirflowのほうが得意です。逆に、Gitへのpushをトリガーにアプリをビルドしてデプロイする用途なら、Airflowを持ち出すよりJenkinsのほうが素直です。判断基準はシンプルで、動かす対象が「コード」ならJenkins、「データ」ならAirflowと考えると外しません。Jenkins側の具体像はDockerでのJenkins環境構築の記事が参考になります。

Airflow vs Prefect・Dagster・Luigi

同じデータオーケストレーション領域の競合です。PrefectはよりPythonネイティブで、通常の関数にデコレータを付ける感覚で書け、動的なワークフローや細かなエラーハンドリングに強みがあります。Dagsterは「データアセット」を中心に据え、開発時のテスタビリティやデータ品質の担保を重視する設計です。資産指向の設計思想と実装、Airflowからの段階移行の手順はDagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けで扱っています。LuigiはSpotify発の古参で、シンプルなバッチ依存管理に向きますが、スケジューラやリッチなUIは持たずAirflowより機能は限定的です。成熟したエコシステムと豊富なprovidersが要るならAirflow、コードの書き味と動的さを取るならPrefect、という住み分けが実感に近いところです。書き味の違いは実際のコードで見るのが早いので、Prefectのワークフロー管理と3系の使い方とあわせて比べてみてください。

主なユースケースとpipでの導入

代表的なユースケース

Airflowが最も使われるのは、次のような定期的・依存関係のあるバッチ処理です。

• ETL／ELT：複数のデータソースから抽出し、変換して、データウェアハウスへ書き込む日次・時次のパイプライン。
• 機械学習パイプライン：データ取得→前処理→学習→評価→デプロイの一連を定期実行し、モデルの再学習を自動化する。
• データ基盤の運用ジョブ：BIレポートの更新、集計テーブルの再構築、外部APIからの定期取り込みなど。

いずれも「順序があり、失敗を検知して途中から直したい」処理で、単発のリアルタイム処理よりもスケジュール駆動のバッチに本領があります。

pipでの導入（constraintsファイルが必須級）

Airflowは依存パッケージが非常に多く、素のpip install apache-airflowだと依存の解決が壊れやすいツールです。公式は、バージョンを固定したconstraintsファイルを併用する再現可能なインストールを推奨しています。

pip install "apache-airflow==3.3.0" \
  --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.3.0/constraints-3.10.txt"

URL中の3.3.0はAirflowのバージョン、3.10は使うPythonのバージョンに合わせて置き換えます。この一手間を省くと、環境によって入るパッケージのバージョンがばらつき「手元では動いたのに本番で壊れる」原因になります。検証段階からconstraints付きで入れるのが安全策です。導入後はairflow standaloneで単体起動して動作を確認し、そこからExecutorやデータベースを本番構成へ寄せていくのが一般的な流れです。

よくある質問（FAQ）

Apache Airflowは無料で使えますか？

はい。AirflowはApache Software Foundation管理のオープンソースソフトウェアで、ライセンスはApache License 2.0です。無償で商用利用・改変ができます。自前でサーバーを用意して運用するセルフホストが基本ですが、運用の手間を省きたい場合はAstronomerやGoogle Cloud Composer、Amazon MWAAといったマネージドサービス（有償）も選べます。AWS上でマネージドのAirflowを動かす場合の環境クラスの選び方と時間課金の構造は、リンク先で整理しています。

Airflow 3と2の違いは何ですか？

最大の違いはアーキテクチャの刷新です。DAGバージョニング、ReactとFastAPIによる新UI、任意環境でタスクを実行するTask Execution API、データアセットとイベント駆動スケジューリングが加わりました。一方でSubDAGの廃止、タスクからのメタデータDB直アクセス禁止、標準Operatorのapache-airflow-providers-standardへの分離といった破壊的変更があり、2系のDAGをそのまま3系で動かせないことがあります。

AirflowとJenkinsはどちらを使うべきですか？

動かす対象で決めます。ソースコードのビルド・テスト・デプロイ（CI/CD）が主目的ならJenkins、データの抽出・変換・書き込みや機械学習パイプラインなどデータ処理のオーケストレーションが主目的ならAirflowが適します。両者は競合というより役割が異なるツールで、CI/CDはJenkins、データパイプラインはAirflow、と併用する構成も一般的です。

AirflowとPrefectの違いは何ですか？

どちらもPythonでデータワークフローを書くオーケストレーションツールですが、Airflowは成熟したエコシステムと豊富なproviders、大規模運用の実績が強みです。Prefectは通常のPython関数にデコレータを付ける書き味と、動的なワークフローや柔軟なエラーハンドリングに強みがあります。堅牢さと連携の広さならAirflow、コードの手軽さと動的さならPrefectが目安です。

Airflowの最新バージョンは何ですか？

記事執筆時点の最新安定版は3.3.0です。Airflow 3.0は2025年4月22日にGAとなりました。対応Pythonは3.9〜3.12です。バージョンの更新が速いため、実際に導入する際はPyPIや公式ドキュメントで最新版と対応Pythonバージョンを確認してください。

関連記事

• Prefect（Python）とは？ワークフロー管理の使い方と3系の始め方
• Temporal Workflowとは？コードで書く分散ワークフローエンジンの仕組みと比較
• Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説
• Docker上でGitBucketとJenkinsの環境構築の目的と背景の説明