機械学習のパイプライン基盤として Airflow（Cloud Composer）を使っていて、Vertex AI Pipelines への移行を検討している——という状況を想定して書きます。

結論から言うと、移行して良かったケースと、しなくてよかったケースの両方があります。判断基準を先に書きます。

移行すべきかの判断基準

移行が効くケース

  • パイプラインの大半がML固有の処理（学習・評価・モデル登録・バッチ推論）
  • Composer のクラスタ維持費が、実行頻度に対して割高になっている
  • 実行環境をタスクごとに分けたい（学習だけGPU、前処理はCPU、など）
  • 実験の再現性と系譜（lineage）の追跡を重視している

移行しなくてよいケース

  • パイプラインの大半がデータ処理のオーケストレーション（外部システム連携、SFTP、複雑な条件分岐、他部署ジョブとの依存）
  • 既存の Airflow Operator に強く依存している
  • 運用チームが Airflow に習熟しており、切り替えコストが便益を上回る

ひとことで言えば、「MLのための基盤」と「全社のジョブスケジューラ」を分けられるかどうかが判断軸になります。両者を一つの Airflow に同居させている組織は多く、その場合は分離そのものが移行の主目的になります。

設計思想の違いが効いてくる場所

常駐 vs 実行時起動

Composer は Airflow のスケジューラとワーカーが常に動いています。つまり、パイプラインを一度も実行しなくても課金が発生する。

Vertex AI Pipelines は実行時にリソースが立ち上がり、終わると消えます。日次で数回しか回さないパイプラインであれば、この差は無視できない大きさになります。

一方で、起動のオーバーヘッドは Vertex AI Pipelines のほうが大きい。数秒で終わる軽いタスクを大量に並べる構成だと、実処理より起動時間のほうが長くなります。この場合は1コンポーネントにまとめる設計変更が必要になります。

タスク間のデータ受け渡し

ここが最も設計変更を要求される部分です。

Airflow では XCom で小さな値を受け渡し、大きなデータは各タスクが GCS や BigQuery を直接読み書きするのが一般的です。パイプラインの外側に状態があります。

KFP（Vertex AI Pipelines）では、成果物（Artifact）が第一級の概念として扱われます。コンポーネントの入出力を型付きで宣言し、その依存関係からDAGが構成される。この違いを理解せずに Airflow のDAGをそのまま移植しようとすると、KFP の利点が何も得られないまま複雑さだけが増えます。

移行時は、DAGを移植するのではなく、成果物の流れとして書き直すというのが実感です。手間はかかりますが、結果として系譜の追跡ができるようになり、「このモデルはどのデータとどのコードから生まれたか」に即答できるようになります。これは監査対応が求められる領域では大きな価値があります。

条件分岐とループ

Airflow の柔軟な分岐（BranchOperator、動的タスク生成）に慣れていると、KFP の dsl.If / dsl.ParallelFor は制約が強く感じられます。

ここは正直に言って、Airflow のほうが表現力が高い。複雑な制御フローが本質的に必要なパイプラインなら、無理に移行しないほうがよいと思います。

実際に踏んだ落とし穴

1. コンポーネントの粒度を細かくしすぎた

最初、Airflow のタスク単位をそのままコンポーネントにしました。結果、起動オーバーヘッドが積み上がり、全体の実行時間が移行前より長くなりました。

まとめられる処理はまとめる。KFP のコンポーネントは Airflow のタスクより粗い粒度が適切です。

2. BigQuery の課金がパイプライン移行で変わらないことを見落とした

当然ですが、パイプライン基盤を変えても、BigQuery のスキャン量は一切変わりません。

コスト削減が目的なら、まず見るべきはクエリのほうです。数億レコード規模の特徴量生成では、パーティション・クラスタリングの設計とクエリの書き方でコストが桁で変わります。基盤移行のコスト効果は、それに比べれば小さい。移行の目的をコスト削減に置くなら、この順序を間違えないほうがいいです。

3. ローカルでの動作確認が難しくなった

Airflow は手元で動かせますが、KFP のコンポーネントはコンテナ前提のため、開発中の試行錯誤のループが遅くなりがちです。

対策として、コンポーネントの中身を純粋な Python 関数として切り出し、そちらに単体テストを書く構成にしました。KFP コンポーネントは薄いラッパーに留める。これで手元での検証速度が戻りました。

4. 移行期間中の二重運用を設計していなかった

一括切り替えはリスクが高いので並行稼働させたのですが、両方が同じテーブルに書き込む構成にしてしまい、どちらの出力か分からなくなりました。

出力先を分け、差分を自動比較する仕組みを先に作るべきでした。これはレガシーシステムの移行とまったく同じ教訓です。新旧の出力を機械的に突き合わせられる状態を先に作る。移行の種類を問わず、これが最も効きます。

まとめ

  • 判断軸は「MLのための基盤」と「全社ジョブスケジューラ」を分けたいかどうか
  • Composer は常駐課金、Vertex AI Pipelines は起動オーバーヘッド。実行頻度で有利不利が変わる
  • DAGを移植するのではなく、成果物の流れとして書き直す
  • コンポーネントは Airflow のタスクより粗い粒度が適切
  • コスト削減が目的なら、基盤移行よりまずクエリを見る
  • 並行稼働時は出力先を分けて自動比較する

MLOps基盤の現状について、どこから手を付けるべきかの整理からご相談いただけます。全面刷新よりも、監視の追加やパイプラインの一部整備で事故率と工数の大半が改善するケースは多いです。