公開更新 11 人が閲覧（直近 30 日） データ分析・BI

Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順

Apache Airflowとは？Jenkinsとの違い・DAGの書き方と3.3の導入手順

Apache Airflowは、データ処理の手順をPythonのコード（DAG）で書き、決まった時刻や前段の完了をきっかけに実行し、失敗したタスクのリトライと実行履歴の確認までを1つの仕組みで担うオープンソースのワークフローオーケストレーションツールです。現行版は2026年9月17日公開の3.3.2で、2系は2026年4月22日にサポートが終了しました。この記事では、部品の役割、公式イメージ apache/airflow:3.3.2 で実際に動かしたDAG、pipとDocker Composeでの導入、2系から消えた機能、Jenkinsとの使い分けを順に説明します。

まとめ：Apache Airflowの要点

  • 何をするツールか：処理の順序と依存関係をPythonで定義し、スケジュール実行・リトライ・途中からの再実行・監視をまとめて引き受ける。動かす対象は「データ処理の手順」。
  • 現行版：3.3.2（2026年9月17日）。対応Pythonは3.10〜3.14。2系は2026年4月22日にEOLで、これから使うなら3系一択。
  • 部品：DAG（ワークフロー）、Task（処理の単位）、Scheduler（実行の判断）、Executor（実行場所）、XCom（タスク間の小さな値の受け渡し）。既定のExecutorはLocalExecutor。
  • 導入：pipならconstraintsファイルの指定が必須級。手元で全コンポーネントを試すならDocker Composeが早く、Dockerには4GB以上のメモリを割り当てる。
  • 2系の解説に注意：SequentialExecutor、SubDAG、SLA、execution_date は3系で削除済み。これらを前提にした手順はそのままでは動かない。
  • Jenkinsとの違い：Jenkinsはコードのビルド・テスト・デプロイ（CI/CD）、Airflowはデータの抽出・変換・書き込みの定期実行。両方を役割で分けて併用できる。

Apache Airflowの役割とcronとの違い

Airflowは2014年10月にAirbnbのMaxime Beauchemin氏が始めたプロジェクトで、2016年3月にApache Software Foundationのインキュベーターへ入り、2019年1月にトップレベルプロジェクトになりました（公式のProject沿革）。ライセンスはApache License 2.0で、商用利用も改変も無償です。

「定期実行ならcronで足りるのでは」という疑問への答えは、処理同士の関係を扱えるかどうかです。cronは時刻になったらコマンドを1本起動するだけで、「AとBが両方終わってからCを動かす」「Cだけ失敗したのでCから再実行する」「先週火曜の分だけやり直す」を表現できません。Airflowはこの依存関係・リトライ・再実行・実行履歴の画面をまとめて持っています。処理が2〜3本で依存も無いならcronのままで十分です。Airflowはメタデータ用のDBとScheduler・API serverを常駐させるため、その運用に見合うのは依存のある処理が増えてからです。

よく使われるのは、複数のデータソースから抽出してDWHへ書き込むETL／ELT、データ取得から再学習・評価までを回す機械学習パイプライン、BI用の集計テーブルの夜間再構築です。オーケストレーション以外の層も含めた設計はデータパイプラインの種類・構成要素と冪等性から考える設計判断で整理しています。

Airflowを構成する部品：DAG・Task・Scheduler・Executor・XCom

DAGとTask・Operator

DAG（Directed Acyclic Graph、有向非巡回グラフ）はワークフロー1本分の定義です。「有向」は処理に順序があること、「非巡回」は一度通ったタスクへ戻るループを作れないことを指します。DAGの中の1つ1つの処理がTaskで、Taskの型がOperatorです。シェルを実行するBashOperator、Python関数を実行するPythonOperator、外部の状態が整うまで待つSensorなどがあります。Airflow 3ではBashOperatorやPythonOperatorが本体から apache-airflow-providers-standard パッケージへ移りました。

Airflow 3のコンポーネント構成

Airflow 3は役割ごとに別プロセスで動きます。公式の docker-compose.yaml（3.3.2） に並ぶサービスがそのまま構成図になります。

  • API server：Web画面とREST API（/api/v2）、タスクがメタデータにアクセスするためのExecution APIを提供する。2系のwebserverに当たる。
  • Scheduler：DAGのスケジュールと依存関係を見て、いま実行すべきタスクをExecutorへ渡す。
  • Dag processor：DAGファイルを読み込んで解析する。3系では開発環境でも別プロセスとして起動する必要がある（airflow dag-processor）。
  • Triggerer：deferrable（遅延可能）なOperator・Sensorの「待ち」を非同期にまとめて処理し、ワーカーの枠を空ける。通常のSensorは待っている間もワーカーの枠を1つ占有する。
  • メタデータDB：実行履歴と状態の保存先。本番はPostgreSQL 14〜18かMySQL 8.0／8.4／Innovationで、SQLiteは開発用（公式の前提条件）。MariaDBは非対応。

Executorの選び方

Executorは「タスクをどこで動かすか」を決めます。公式のExecutor解説によると既定はLocalExecutorで、それ以外は各プロバイダパッケージから入れます。公式イメージ apache/airflow:3.3.2 には celery・cncf-kubernetes・amazon のプロバイダが同梱されており、edge3は入っていませんでした。

Executor 配布元 タスクの実行場所 向く場面
LocalExecutor 本体（既定） Schedulerと同じマシン 検証・小規模の本番
CeleryExecutor celeryプロバイダ Celeryワーカー群 常時多数のタスクを流す
KubernetesExecutor cncf-kubernetesプロバイダ タスクごとのPod 依存ライブラリの分離
EdgeExecutor edge3プロバイダ HTTPでつなぐ遠隔ワーカー 別拠点・エッジで実行
BatchExecutor／EcsExecutor amazonプロバイダ AWS Batch／ECS AWSの計算資源で実行

設定は [core] executor で、カンマ区切りで複数並べるとリストの先頭が既定になり、タスクやDAGごとに実行先を振り分けられます。2系にあったCeleryKubernetesExecutorとLocalKubernetesExecutorは、この複数Executor設定に置き換えられ、3.0.0以降は使えなくなりました。最初はLocalExecutorで始め、1台でタスクが詰まり始めてからCeleryかKubernetesへ移すのが無駄のない順番です。

XComで渡してよいもの

XCom（Cross-Communication）は前段タスクの戻り値を後段へ渡す仕組みで、値はメタデータDBに保存されます。渡すのは件数・ファイルパス・テーブル名のような小さな値に限り、DataFrameやファイルの中身はS3やDWHに置いて、その場所だけをXComで渡します。公式も、XComは少量のデータ向けでDataFrameのような大きな値の受け渡しに使わないよう明記しています（公式のXCom解説）。

DAGを書いて動かす：TaskFlow APIとdags test

DAGの書き方は、Python関数に @task を付けるTaskFlow APIと、Operatorをインスタンス化して >> で依存をつなぐ従来の書き方の2つで、1本のDAGに混在させられます。次のコードは両方を使った例で、Airflow 3の書き方どおり airflow.sdk からインポートしています。

from datetime import datetime, timedelta

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


@dag(
    schedule="@daily",
    start_date=datetime(2026, 10, 1),
    catchup=False,
    default_args={"retries": 2, "retry_delay": timedelta(minutes=5)},
    tags=["example"],
)
def etl_pipeline():
    @task
    def extract() -> dict:
        return {"records": 100}

    @task
    def transform(data: dict) -> int:
        return data["records"] * 2

    @task
    def load(value: int) -> None:
        print(f"loaded: {value}")

    notify = BashOperator(task_id="notify", bash_command="echo done")

    load(transform(extract())) >> notify


etl_pipeline()

extract の戻り値がXCom経由で transform へ、その戻り値が load へ渡ります。関数の呼び出しを入れ子にするだけで依存関係が組み上がり、最後の >> notify で従来型のOperatorを後ろにつないでいます。default_args の retries は全タスクに効き、失敗したタスクだけが5分後に最大2回やり直されます。

スケジューラを立てずに1回だけ通しで実行するには airflow dags test を使います。2026年10月11日に公式イメージ apache/airflow:3.3.2（Python 3.13.15）でこのDAGを実行したところ、4タスクが依存の順に成功しました。

airflow db migrate
airflow dags test etl_pipeline 2026-10-10

# 出力（抜粋）
[DAG TEST] running task <TaskInstance: etl_pipeline.extract ...>
Pushing xcom ... task_id='extract'
[DAG TEST] running task <TaskInstance: etl_pipeline.transform ...>
[DAG TEST] running task <TaskInstance: etl_pipeline.load ...>
loaded: 200
Running command: ['/usr/bin/bash', '-c', 'echo done']
DagRun Finished: dag_id=etl_pipeline, ... state=success

catchup=False は、start_dateから今日までの未実行分をまとめて走らせない指定です。Airflow 3では catchup の既定値自体がFalseに変わりましたが、既定値は設定の [scheduler] catchup_by_default で環境ごとに変えられるため、DAG側で明示しておくほうが安全です。また、2系の書き方 from airflow.operators.bash import BashOperator は3.3.2でもまだ動き、DeprecatedImportWarning を出すだけでした。警告が出ているうちに書き換えておくべき箇所です。

Airflowをインストールする：pip＋constraintsとDocker Compose

pip＋constraintsでの導入とairflow standaloneの起動

Airflowは依存パッケージが多く、素の pip install apache-airflow では依存の解決結果が環境ごとにずれます。公式のQuick Startは、版を固定したconstraintsファイルを指定する入れ方を案内しています。

python3.12 -m venv .venv
source .venv/bin/activate
AIRFLOW_VERSION=3.3.2
PYTHON_VERSION="$(python -c 'import sys; print(f"{sys.version_info.major}.{sys.version_info.minor}")')"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
airflow standalone

airflow standalone はメタデータDBの初期化、ユーザー作成、全コンポーネントの起動を1コマンドで行い、画面は http://localhost:8080 で開きます。3系では管理者パスワードが端末に出ないことがあり、その場合は $AIRFLOW_HOME/simple_auth_manager_passwords.json.generated（既定は ~/airflow）に書かれています。

注意点がもう1つあります。2026年10月11日にIntel（x86_64）のMacで uv pip install "apache-airflow==3.3.2" をconstraints-3.12付きで実行したところ、依存の libcst 1.9.0 のビルドでRustコンパイラを要求されて止まりました。PyPIにある同版のmacOS向けホイールがarm64用だけのためです。Intel Macでは次のDocker Composeか公式イメージを使うほうが早く進みます。

Docker Composeでの全コンポーネント起動

CeleryExecutor・PostgreSQL 16・Redisを含む全コンポーネントの構成を手元で試すなら、公式のDocker Compose手順が最短です。

mkdir airflow-local && cd airflow-local
curl -LfO 'https://airflow.apache.org/docs/apache-airflow/3.3.2/docker-compose.yaml'
mkdir -p ./dags ./logs ./plugins ./config
echo -e "AIRFLOW_UID=$(id -u)" > .env
docker compose up airflow-init
docker compose up -d

起動後は http://localhost:8080 にユーザー名・パスワードとも airflow でログインできます。dags フォルダに置いたPythonファイルがDAGとして読み込まれます。公式はDockerに最低4GB、できれば8GBのメモリを割り当てるよう求めており、macOSのDocker既定値では足りずAPI serverが再起動を繰り返すことがあります。Docker Desktopの代わりにColimaを使う場合は、既定で共有されるのがホームディレクトリ配下だけなので、作業フォルダを /tmp に置くとコンテナから dags が空に見えます（設定はColimaでDocker Desktopを外す導入手順と設定の落とし穴を参照）。なお公式はこのDocker Compose構成を学習・検証用とし、本番にはKubernetesと公式Helm Chartを勧めています。

Airflow 3で変わった点と2系からの移行

3.0〜3.3で入った主な機能

Airflow 3.0は2025年4月22日に公開され、その後は3〜7か月の間隔でマイナー版が出ています。各版の内容は公式リリースノートから主要項目を拾いました。

版 公開日 主な追加
3.0.0 2025-04-22 DAGバージョニング、新UI、Task Execution API、Asset
3.1.0 2025-09-25 Human-in-the-Loop、Deadline Alerts、UIの多言語化
3.2.0 2026-04-07 Asset Partitioning、Multi-Team Deployments（実験的）
3.3.0 2026-07-06 Task and Asset State Store、Pluggable Retry Policies
3.3.2 2026-09-17 現行のパッチ版

運用で効くのは3.0のDAGバージョニングです。DAGの構造の変更がメタデータDBに版として記録され、画面からどの実行がどの版で動いたかを遡れます。ただし実行開始時点のコードで最後まで走るのは、GitDagBundleのように版管理に対応したDAG bundleを使った場合だけです。既定のdagsフォルダ（LocalDagBundle）は非対応で、2系と同じく常にディスク上の最新コードで動きます（公式のDAG bundles解説）。Task Execution APIはタスクとメタデータDBを切り離す仕組みで、EdgeExecutorや、3.3.0で加わったJava・Go向けのTask SDK（実験的）はこの上に載っています。2系のDatasetはAssetに改称され、「データが更新されたら下流のDAGを動かす」というデータ駆動のスケジュールが書けます。メッセージ基盤のイベントを起点にする構成ならKafka 4系のKRaft構成とあわせて設計します。

2系のDAGで動かなくなる箇所

公式のAirflow 3移行ガイドが挙げる削除項目のうち、既存DAGで当たりやすいものは次のとおりです。

  • SubDAG：削除。TaskGroupかAssetで書き直す。
  • SLA：削除。3.1で入ったDeadline Alerts（3.3.2時点でも実験的機能）へ移す。
  • コンテキスト変数：execution_date、next_ds、prev_ds、yesterday_ds などが無くなり、参照するとDAGがエラーになる。logical_date と data_interval_start／data_interval_end に置き換える。
  • メタデータDBへの直接アクセス：タスクのコードからDBセッションやモデルを直接使えない。自作Operatorでやっていれば、REST APIかTask SDKへ書き換える。
  • REST API：/api/v1 は /api/v2 に置き換え。外部から叩くスクリプトがあれば修正が要る。
  • CLIの --subdir：DAG bundlesに置き換え。

DAGの洗い出しは手で読む前に、静的解析ツールRuffのAirflow用ルールで機械的にかけます（公式の移行ガイドはRuff 0.13.1以上を求めています）。AIR301・AIR302が3系で壊れる箇所、AIR311・AIR312が今は動くが書き換えを強く勧める箇所です。

ruff check dags/ --select AIR301,AIR302
ruff check dags/ --select AIR301 --fix

2系は2025年10月22日に限定保守へ入り、2026年4月22日にEOLとなりました（最終版2.11.2、公式のバージョンライフサイクル）。セキュリティ修正も出ないため、2系のまま本番を続ける理由はありません。いきなり全DAGを移すのではなく、Ruffでの洗い出し、検証環境での airflow dags test、DAG単位の段階移行の順に進めます。

2系前提の解説を見分ける目印

Airflowの日本語の解説は2系時代のものが多く、検索上位にも残っています。次の語が「現役の機能」として出てきたら、その解説は2系時代のもので、3系ではそのまま動かないか、非推奨の書き方だと判断してください。

  • Executorの選択肢に SequentialExecutor や CeleryKubernetesExecutor がある（どちらも3系では使えない。公式イメージ3.3.2で airflow.executors.sequential_executor をインポートすると ModuleNotFoundError）
  • Web画面を airflow webserver で起動している（3.3.2で実行すると Command `airflow webserver` has been removed. Please use `airflow api-server` で止まる）
  • テンプレートで {{ execution_date }} を使っている
  • from airflow.models import DAG や from airflow.decorators import task でインポートしている（3.3.2では DeprecatedImportWarning 付きで動くが、3系の正式な書き方は airflow.sdk で、将来の版で削除予定）
  • 対応Pythonに3.9以下が含まれている（3.3系は3.10〜3.14）

AirflowとJenkinsの違い

「airflow vs jenkins」で迷うのは、どちらも「ジョブを順番に自動実行する」ように見えるからです。違いは動かす対象にあります。

観点 Apache Airflow Jenkins
主な用途 データの抽出・変換・書き込み ビルド・テスト・デプロイ
主な起動のきっかけ 時刻・前段DAG・データ更新 Gitへのpush・プルリクエスト
定義の書き方 Python（DAG） Groovy（Jenkinsfile）
過去分の再実行 日付を指定して再実行できる 日付の軸は無い（パラメータで自作）
ライセンス Apache License 2.0 MIT License（本体）

Airflowには「2026年10月3日分のデータだけ集計し直す」というように、処理対象の日付（logical_date）を指定して過去分を再実行する考え方があります。Jenkinsのジョブは「今のコードをビルドする」ためのもので、この日付の軸を持ちません。逆に、プルリクエストごとにテストを走らせて結果をGitHubへ返すような処理をAirflowで組むのは筋が悪く、CI/CDツールの領分です。

判断は単純で、パイプラインが扱うのが「ソースコード」ならJenkins、「データ」ならAirflowです。データ基盤のチームでも、DAGファイル自体のテストと配置はJenkinsやGitHub Actionsで行い、配置されたDAGの定期実行をAirflowが担う、という分担にできます。Jenkins自体の機能と導入はJenkinsのできること・無料の範囲とインストール手順、CI/CD側の考え方はDevOpsとCI/CDの違い、Kubernetes上でパイプラインを組むCI/CDならTektonの仕組みと採用判断で扱っています。

Prefect・Dagster・Temporalとの使い分けとマネージドサービス

Prefect・Dagster・Temporalと比べる

同じデータオーケストレーションの領域で比べると、Airflowの強みはプロバイダの数と運用事例の厚さ、弱みは常駐コンポーネントが多く手元で試すまでが重いことです。

  • Prefect（3系）：普通のPython関数にデコレータを付けるだけで動き、実行時に分岐が変わる動的なフローを書きやすい。小さく始めるならPrefectのほうが軽い（Prefectの使い方と3系の始め方）。
  • Dagster：タスクではなく「作られるデータ（アセット）」を単位に設計し、テストとデータ品質の確認を組み込みやすい。プロジェクトの作成と実行は dg CLIで行う。Airflowからの段階移行の手順はDagsterのアセット指向の仕組みとAirflow移行にまとめています。
  • Temporal：注文処理や決済のように、アプリケーションの中で数日単位の状態を持つ処理を落とさずに完走させる用途。時刻起点のバッチではAirflowが、アプリ起点の長い処理ではTemporalが合う（Temporal Workflowの仕組み）。

Airflowを選ばないほうがよい場面もはっきりしています。公式はAirflowを「バッチワークフローのオーケストレーション基盤」と位置づけ、開始と終了がはっきりした定期処理に向くとしています（公式ドキュメントの概要）。秒単位の遅延で処理し続けるストリーミングは守備範囲外です。AWSの中で完結する数ステップの処理なら、サーバーを持たないAWS Step Functionsのほうが運用の手間が小さく済みます。機械学習の学習ジョブをKubernetes上で回すことが中心ならKubeflow Pipelines v2も候補です。Kubernetesネイティブの代替としては、各ステップをPodとして走らせCRDでDAGを宣言するArgo Workflowsがあり、クラスターを既に運用しているチームではAirflowのSchedulerやExecutorを別に保守せずに済みます。

マネージドサービスで使う：MWAAとManaged Service for Apache Airflow

Airflow本体は無料ですが、メタデータDB・Scheduler・ワーカーを自前で運用し、版を上げ続ける手間がかかります。この運用を任せるのがマネージドサービスで、利用料は環境の規模と稼働時間に応じてかかります。たとえばAmazon MWAAは東京リージョンの最小のmicro環境が1時間0.29ドルからで、常時稼働なら月約212ドル（730時間）になります（AWS Price List APIの東京リージョン単価）。

マネージド版は本家の最新版より少し遅れて対応します。3.3.2の新機能を前提にDAGを書く場合は、使うサービスの対応表に載っているかを先に確認します。Airflowを含むデータ基盤の設計から構築までを外部に任せたい場合は、データ分析基盤構築・MLOps構築支援でも相談を受けています。

よくある質問

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

本体はApache License 2.0のオープンソースで、商用でも無料です。費用がかかるのはサーバーとメタデータDBの運用費、またはAmazon MWAAやGoogle CloudのManaged Service for Apache Airflowを使う場合の利用料です。

Airflowの最新バージョンと対応Pythonは？

2026年10月時点の最新は2026年9月17日公開の3.3.2で、対応Pythonは3.10〜3.14です。公式Dockerイメージ apache/airflow:3.3.2 の既定はPython 3.13でした。版の更新が速いため、導入時はPyPIのapache-airflowで確認してください。

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

3系ではDAGバージョニング、ReactとFastAPIで作り直した画面、Task Execution API、Assetによるデータ駆動のスケジュールが入りました。一方でSubDAG、SLA、SequentialExecutor、execution_date などが削除されています。2系は2026年4月22日にEOLです。

AirflowはWindowsで動きますか？

Windowsには直接インストールできません。公式の前提条件ではPOSIX準拠のOSが対象で、WindowsではWSL2かLinuxコンテナ（Docker）で動かすよう案内されています。

airflow standaloneは本番で使えますか？

使わないでください。公式のQuick Startは、本番ではstandaloneをやめてAPI server・Scheduler・Dag processor・Triggererを個別に起動するよう案内しています。メタデータDBもSQLiteではなく、PostgreSQLかMySQLに替えます。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

ほか 6 件の記事からもリンクされています。

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.15　テックブログ リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  2. 2025.09.03　コラム ストループ効果とは？原典1935年の実測値と年齢別の平均・テストのやり方
  3. 2026.01.20　テックブログ PineDramaとは？TikTokショートドラマアプリの料金・安全性とTikTok内ミニドラマの課金
  4. 2026.04.13　コラム ゴルフ賞金の税金はいくら？1,000万円で源泉194万円・確定申告での精算と副賞の車、海外賞金【令和8年分】
  5. 2026.10.16　テックブログ バーガーキング情報漏洩どうしたらいい？約1,118万件の対象確認・補償・退会とメールの真偽

RELATED POSTS 関連記事

一覧へ戻る

目次