Airflowとは：業界標準オーケストレーターの基本と運用設計

データオーケストレーターを選ぶとき、いちばん最初に名前が挙がるのがApache Airflowだ。2014年にAirbnbがオープンソース化して以来、世界中で採用が広がり、事実上の業界標準になっている。求人や情報の流通量、コミュニティの厚さで他を圧倒する。「迷ったらまずAirflow」が安全な選択だ。

その分、独自の概念と用語が多く、最初の学習コストはやや高めです。基本構造、モダンな書き方、dbtとの統合、運用上の注意点を順に押さえます。

基本概念：DAG・Task・Operator

Airflowは「DAGを定義し、Schedulerが起動し、Executorが実行する」というアーキテクチャです。OperatorはTaskの「種類」を表すテンプレで、データベース接続・クラウドAPI・dbt・Sparkなど、用途別に数百種類が用意されています。

最小のDAG

# dags/daily_orders.py
from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

with DAG(
    dag_id="daily_orders",
    start_date=datetime(2026, 1, 1),
    schedule="@daily",
    catchup=False,
) as dag:

    extract = BashOperator(
        task_id="extract_orders",
        bash_command="python /opt/airflow/scripts/extract_orders.py",
    )

    transform = BashOperator(
        task_id="run_dbt",
        bash_command="cd /opt/dbt && dbt run --select orders+",
    )

    test = BashOperator(
        task_id="dbt_test",
        bash_command="cd /opt/dbt && dbt test --select orders+",
    )

    extract >> transform >> test

`extract >> transform >> test`が依存関係の宣言で、左から右に直列に実行されます。これだけで「毎日、抽出→dbt run→dbt test」のパイプラインが動きます。

TaskFlow API：モダンな書き方

Airflow 2.0以降、Pythonの関数をデコレータで装飾するだけでTaskにできる「TaskFlow API」が導入されました。Operatorを直接書くより、はるかに読みやすくなります。

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

@dag(
    schedule="@daily",
    start_date=datetime(2026, 1, 1),
    catchup=False,
)
def daily_orders():

    @task
    def extract():
        # 抽出処理
        return {"row_count": 1000}

    @task
    def transform(meta: dict):
        # 変換処理
        return meta["row_count"] * 2

    @task
    def notify(total: int):
        print(f"処理した行数: {total}")

    notify(transform(extract()))

daily_orders()

関数の戻り値が次のTaskに自動で渡され、XComの明示的な操作も不要です。新規プロジェクトではTaskFlow APIを優先するのが、現在の定石です。

dbtとの統合

dbtを動かす方法は3パターンあります。

小さなプロジェクトならBashOperatorで十分です。規模が大きくなり、モデル単位の失敗・再実行を細かく制御したくなったら、Cosmosのようなパッケージを検討します。dbtでの実装の基本はdbt実装ガイドを参照してください。

運用上のハマりどころ

• catchup=Trueの罠：start_dateと現在日付の間のすべての日付分を一気に実行してしまう。新規DAGは`catchup=False`を明示するのが安全。
• scheduleとexecution_dateのズレ：`@daily`は「翌日の0時に前日分を処理」する形で動く。直感とズレるのでドキュメントを確認。
• XComの誤用：大きなデータをXComで受け渡そうとすると、メタデータDBが膨らむ。データはストレージに置き、XComはパスだけ渡す。
• Schedulerのリソース不足：DAGが増えるとSchedulerが重くなり、起動遅延が出る。リソース・並列度・DAGファイルの数を継続監視する。

マネージド版の選択肢

セルフホストはOSSで無料だが、運用工数（アップデート・スケール・モニタリング）が発生する。3〜10名のデータ組織なら、本質的な設計に時間を使うためにマネージドを選ぶケースが増えている。

向く・向かない場面

• 向く：既存のAirflow資産がある、求人・情報量を重視、エコシステムの厚さが必要、複雑な依存関係を持つ大規模パイプライン
• 向かない：dbt中心でデータ資産思考の運用にしたい（→Dagster）、Pythonで動的に書きたい・シンプル運用（→Prefect）

まとめ

• Airflowはデータオーケストレーターの業界標準。エコシステムと求人で優位。
• DAG・Task・Operator・Scheduler・Executorが基本概念。
• 新規プロジェクトはTaskFlow APIで素直に書く。
• dbt統合はBashOperator→Cosmosと段階的に高度化できる。
• マネージド版（Astronomer/MWAA/Composer）で運用負荷を下げられる。

全体像はオーケストレーター選び方ガイド、隣接の選択肢はDagster とは・Prefect とはにあります。導入や移行の壁打ちは、DE-STKの初回相談（30分・無料）もご利用ください。

よくある質問（FAQ）

Q. Airflow 1系から2系への移行は重いですか？

A. 2020年末のAirflow 2.0以降、構造が大きく変わった。1系で書いたDAGは多くが2系でも動くが、TaskFlow APIや新しいSchedulerアーキテクチャの恩恵を受けるには書き直しが必要だ。1系を使い続けているなら、計画的に2系へ移行する時期は来ている。新規導入なら最新版（執筆時点で2系後半）を選ぶ。

Q. Schedulerが重くなったら何を見ますか？

A. まず、DAGファイル数・Task数・並列度（max_active_runs、parallelism）を確認します。次に、SchedulerのCPU・メモリ使用率と、メタデータDBの負荷。多いのは「DAGファイルの解析時間が伸びる」「メタDBへの書き込みが詰まる」パターンです。DAG数を分割する、Schedulerを複数起動する（HA構成）、メタDBをチューニングする、で対処します。マネージド版ならスケール設定だけで済むことが多いです。

Q. Astronomer Cosmosは何が嬉しいのですか？

A. dbtの各モデルを、AirflowのTaskとして自動展開してくれます。これにより、モデルごとの失敗を独立してリトライ・再実行でき、観測性も上がります。BashOperatorで`dbt run`を一括で叩く運用だと「どのモデルが失敗したのか」「失敗したモデルだけを再実行する」がやりにくく、大規模dbtで実用上の壁になります。Cosmosはこの壁を超えるための定番選択肢です。

Q. AWSとGCPのマネージド、どちらを選ぶ？

A. すでに使っているクラウドに合わせるのが素直です。データソースや他のサービスとの連携が滑らかになります。Airflow開発元主導という意味ではAstronomerが最も尖っていますが、クラウドのIAMやネットワーク統合を優先するなら各クラウドのマネージド版が現実的です。クラウドDWHの選び方はクラウドDWH入門もあわせて参考にしてください。