Apache Airflow 2025-12-12 リリースノート解説: Airflow 3.1.5

Apache Airflow の公式リリースノートから、3.1.5 の実務上の意味を整理します。

要点

• Airflow 3.1.5 は 2025-12-12 公開の versioned release
• 変更の中心は 不具合 fix、UI/API 改善、scheduler や task 実行の安定性向上
• 本番 DAG、権限、ログ、provider compatibility に影響しないか確認したい
• Airflow 3 系では Task SDK、アセット、HITL、UI の細かな挙動差にも注意が必要

今回の更新で何が変わるのか

Airflow 3.1.5 は、Airflow を本番運用しているチームが version 単位で確認すべきリリースです。公式上は significant changes なしの patch release ですが、不具合 fix と UI/API/性能改善の積み上げが中心です。 patch release でも、DAG parse、scheduler、task 再実行、remote logging、アセット、HITL、API エンドポイント、UI 表示のような周辺挙動が変わることがあります。

対象になりそうなユーザー・チーム

• Airflow を self-managed または managed サービス 上で運用しているデータ基盤チーム
• DAG authoring、scheduler、executor、provider package の互換性を管理している platform team
• backfill、remote logging、secrets backend、アセット、HITL、API 連携を本番で使っているチーム

実務でまず確認したいこと

今回のリリースノートでは、Handle invalid token in JWTRefreshMiddleware (、Fix inconsistent Dag hashes when template fields contain unordered dicts (、Fix assets used only as inlets being incorrectly orphaned (、Fix exception when logging stdout with a custom %-format string (、Fix backfill max_active_runs race condition with concurrent schedulers (、Fix LocalExecutor memory spike by applying gc など、日々の運用で踏みやすい細かな不具合の修正が並んでいます。Airflow の patch release は見た目より影響範囲が広く、UI だけの修正に見えても権限不足ユーザーの表示、API の query、serialized DAG、scheduler の負荷、remote logging の接続再利用などに関わることがあります。特に複数 scheduler、large DAG、dynamic task mapping、secrets backend、remote ログ、アセット-aware scheduling を使っている環境では、代表 DAG の parse、manual 起動、再実行、backfill、ログ閲覧を一通り確認してから上げるのが安全です。

アップデート前の確認観点

1. 現在の Airflow core、provider packages、Python version、executor、Helm chart または managed environment の version を並べて確認する
2. staging 環境で DAG parse、manual 起動、再実行、backfill、ログ 閲覧、権限別 UI/API 表示を確認する
3. 変更内容が secrets backend、remote logging、metrics、アセット、HITL、dynamic task mapping に触れていないかをリリースノートで再確認する

どう読むべきか

Airflow は ワークフロー 基盤なので、patch release でも影響は DAG 実行だけに閉じません。今回の更新は、該当 version を使っているか、近い minor 系へ上げる予定がある場合に、upgrade checklist へ入れておきたい内容です。特に Airflow 3 系へ移行中の組織では、core と providers と deployment surface を分けて読み、障害時に戻せる手順まで含めて検証するのがよさそうです。