Cloud Composer で Apache Airflow 3.1 を活用し、ワークフロー オーケストレーションを強化

※この投稿は米国時間 2026 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

データスタックが分断された世界では、革新的で、移植性と拡張性を備えたワークフロー オーケストレーションが求められます。フルマネージドのデータおよび AI / ML 向けワークフロー オーケストレーション サービスである Cloud Composer は、Apache Airflow を基盤として、ユニバーサルなコントロール プレーンを提供しています。そしてこのたび、Cloud Composer が Airflow 3.1 をプレビュー版としてサポートすることになりましたのでお知らせします。

11 月にリリースされたこのアップデートは、プラットフォームにとって大きな節目となるもので、ハイパースケーラーが Airflow 3.1 を提供するのは今回が初めてです。

Airflow 3 を基盤に進化

Airflow 3.1 の新機能は、Airflow 3.0 で導入された革新的なアーキテクチャを基盤として構築されています。

• 疎結合アーキテクチャ: スケジューラと実行レイヤを明確に分離することで、スケーラビリティとセキュリティを向上させます。

• DAG のバージョニング: DAG の自動バージョニングをネイティブにサポートし、タスクの削除やロジック変更後も、過去の構造と実行履歴を保持します。

• 強力なマネージド バックフィル: バックフィル機構を刷新し、スケジューラがフルマネージドで扱う第一級の機能として再設計しました。

• イベントドリブン スケジューリングとデータアセット: アセットに基づくトリガーに加え、メッセージ キューへの到着などの外部イベントに応じてワークフローを起動できる機能を強化しています。

このほかにも多数の改善が含まれています。

Airflow 3 のアーキテクチャ面の変更点をさらに詳しく知りたい場合は、過去の発表記事「Next Gen Data Pipelines: Airflow 3 Arrives on Google Cloud Composer（次世代データ パイプライン: Airflow 3 が Google Cloud Composer に登場）」をご覧ください。

Composer 上の Airflow 3.1 では何が新しくなったのか

Google Cloud 上で Airflow 3.1 の新機能を堅牢かつ信頼性の高い形で提供するため、Google は多大な投資を行ってきました。Airflow 3.1 では特に、可視性の向上、信頼性の強化、グローバル チームの支援を目的とした機能強化が追加されています。

1. 人間参加型（HITL）ワークフロー

AI エージェントや自動化パイプラインが複雑化するにつれ、人による監督の重要性はますます高まっています。Airflow 3.1 では、強力な人間参加型（HITL）機能が導入され、ワークフローの実行を deferred（遅延）状態で一時停止し、Airflow の UI または API 呼び出しを通じて、人が判断を下すまで待機できるようになりました。

HITL により、デプロイの承認、生成 AI モデルの出力のレビュー、パイプラインの挙動を調整するためのフィードバックなど、さまざまな場面で人が主導権を持てます。

このプロセスをさらに円滑にするため、HITL オペレータは Airflow Notifiers とネイティブに連携します。タスクが入力待ちで一時停止した瞬間に、Slack、メール、PagerDuty などを通じて自動通知を送信する Notifier を設定できます。これらのヘルパー メソッドを利用すれば、通知に該当する承認ページへの直接リンクを含めることができ、関係者は UI 内を探すことなく、即座に対応できます。

2. デッドライン アラート

Airflow におけるタスクの SLA 管理は進化しています。Airflow 3.1 では、従来の仕組みに代わり、よりスマートでプロアクティブなデッドライン アラートが導入されました。DAG やタスクについて、開始時刻や論理日付を基準とした具体的な時間ベースのしきい値を設定できるようになっています。

たとえば、長時間実行される ML トレーニング ジョブなどの重要なパイプラインが想定される実行時間を超過した場合、Airflow は標準の Notifier を通じて自動的に通知します。これにより、ダウンストリームの目標に影響が及ぶ前に、遅延の兆候を把握できます。

3. ネイティブな多言語対応（国際化）

多くのデータ エンジニアリング チームはグローバルに分散しており、メンバーはそれぞれ異なる言語を使用しています。Airflow 3.1 では、最新の React ベース UI 全体が完全にローカライズされ、スペイン語、フランス語、ポーランド語、ドイツ語、中国語（簡体字・繁体字）、日本語、ポルトガル語など、17 言語に対応しています。

4. 現代的な拡張性と開発者エクスペリエンス

中核となるオーケストレーション機能にとどまらず、Airflow 3.1 では開発者エクスペリエンスを向上させるための複数のアーキテクチャ改善が導入されています。これらのアップデートにより、チームはプラットフォームの UI を柔軟に拡張し、より応答性の高い同期型アプリケーションを構築できるようになります。

• React プラグイン システム: カスタム ダッシュボードや独自ビューを UI に直接組み込めます。

• 推論の実行: 同期 DAG の完了までを監視できる、新しいストリーミング API エンドポイントを提供します。

クローズドな囲い込み型ではなく、オープンなオーケストレーションが選ばれる理由

一部のオーケストレーション プラットフォームは、取り込みとオーケストレーションを独自の不透明な仕組みに包み込み、すべてを単一の「囲い込み型」に統合しようとします。しかし、プロプライエタリなツールでは、新たなユースケースへの対応をベンダーに依存するため、機能追加が遅れやすいという課題があります。その点、Airflow はオーケストレーションの業界標準として定着しており、ユーザーは市場の最前線に立ち続けることができます。

Google は、このエコシステムの育成に強くコミットしています。単なるプラットフォーム プロバイダにとどまらず、Airflow のコードベースに積極的に貢献する立場としても関与しています。Cloud Composer 3 は、マネージド オープンソースの成熟形といえる存在であり、堅牢化された境界によるセキュリティと、オープン標準がもたらすほぼ無限の拡張性を両立しています。このアプローチにより、次のメリットが得られます。

• コミュニティ主導のイノベーション: 機能の進化スピードは、単一企業の研究開発予算に左右されるべきものではありません。Airflow 3.1 では、世界中の数千人規模のコントリビューターによる集合的なイノベーションを活用でき、コミュニティによって構築された幅広い Provider エコシステムに迅速にアクセスできます。

• ベンダー ロックインからの解放: ロジックが特定ベンダーのエコシステムに強く結び付けられるプロプライエタリなプラットフォームとは異なり、Cloud Composer は標準の Apache Airflow 上で動作します。そのため、オーケストレーションのコードは、可搬性の高い Python のまま保たれます。

• 拡張性: エンタープライズ環境では、レガシーな連携やニッチなツールといった「ロングテール」の統合要件を抱えることが少なくありません。ベンダーがコネクタを提供するのを待つのではなく、Composer では、任意のシステムと連携するためのカスタム Python Operator を自ら実装できます。これにより、社内の独自 API からオンプレミスのハードウェアに至るまで、クローズドなツールにありがちな「ロードマップ上の制約」に縛られることなく、強力な接続性を確保できます。

使ってみる

上記で紹介した、人間参加型（HITL）ワークフローからプロアクティブなデッドライン アラートに至るまでの各機能は、Apache Airflow が持つイノベーションの結晶と言えます。Airflow 3.1 を搭載した Cloud Composer 3 は、現在プレビュー版として提供中です。新しい環境を作成し、これらの新機能を今すぐ体験してみてください。

-Google、シニア プロダクト マネージャー Piotr Wieczorek

-Dataplex Universal Catalog / データ共有 / データ統合担当プロダクト リード Chai Pydimukkala