2026.07.23 インフラ

Cloud Composerとは？マネージドApache Airflowの仕組み・料金と採用判断を実装者目線で解説

Cloud Composerは、オープンソースのApache Airflowを、Google Cloud上でフルマネージドに動かすワークフローオーケストレーションのサービスです。依存関係のある複数のジョブをPythonのコードでDAGとして定義し、決めた順序とスケジュールで実行・監視します。Airflow本体のインストールやスケジューラの冗長化、メタデータベースの運用をサービス側に任せられる点が、自前構築との違いです。この記事では、Apache Airflowとの関係、DAGと環境の構成、Composer 1/2/3系のバージョン差、DCUベースの料金、そしてDataflowやDataprocとの連携と採用の判断基準までを、実装者の視点で整理します。

まとめ：Cloud Composerの要点と採用判断

Cloud Composerは、Apache AirflowをGoogle Cloudのマネージド環境として提供するオーケストレーション基盤です。BigQueryへのクエリ、Dataflowジョブの起動、外部APIの呼び出しといった処理を、依存関係を持つDAGとして束ね、日次や時間単位で回します。Airflowの運用で重荷になるスケジューラの可用性やワーカーのスケール、バージョン管理をサービスが引き受けるため、DAGの中身の設計に集中できます。

採用の勘所は「依存関係のある定時バッチを、Airflowの運用負荷を負わずに回したいか」です。複数のGCPサービスにまたがるデータパイプラインを日次で順番に動かすなら噛み合います。一方で、単発のイベントに反応する軽い処理や、常時起動のコストを許容できない小規模用途では、Airflowのスケジューラが常駐するぶん割高になりやすく、Cloud RunやWorkflowsなど軽量な選択のほうが素直です。Composerは「ワークフローの管理層」であり、重い処理そのものはDataflowやDataprocに任せる、というレイヤ分担で捉えると設計を誤りません。

Cloud ComposerとApache Airflowの関係と基本構造

まず「Composerが何を担うサービスなのか」を、Apache Airflowとの関係から押さえます。Composerは独自のワークフローエンジンを持たず、Airflowをそのままマネージドで動かす設計です。

マネージドApache AirflowとしてのCloud Composerの定義

Cloud Composerは、Apache Airflow上に構築されたフルマネージドのワークフローオーケストレーションサービスで、Google Cloudでは「Managed Service for Apache Airflow」とも位置づけられています。利用者はAirflow環境（Composer環境）を作成するだけで、スケジューラ・ワーカー・Web UI・メタデータベースといった構成要素がまとめて用意されます。Airflowをそのまま採用しているため、既存のAirflow資産やAirflowの知識をほぼ書き換えずに持ち込めるのが特徴です。Airflow本体の仕組みや基本操作はApache Airflowとは？仕組み・使い方とAirflow 3の新機能を解説で詳しく扱っているため、Airflowそのものを先に固めたい場合はあわせて参照してください。

DAGでワークフローを定義するAirflowの実行モデルとデプロイの流れ

Airflowでは、処理の流れを有向非巡回グラフ（DAG）として記述します。DAGの実体はPythonのコードで、個々の処理を表すタスクと、その依存関係（どのタスクの後にどのタスクを動かすか）を宣言する形です。各タスクは、BigQueryにクエリを投げる、Dataflowジョブを起動する、外部コマンドを実行するといった役割ごとの部品（オペレータ）として書き、GCP各サービス向けのオペレータがあらかじめ揃っています。Composerでは、このDAGファイルを環境に紐づくCloud Storageバケットへ置くと、スケジューラが読み取ってスケジュールどおりに実行する仕組みです。実装者はインフラの用意ではなくDAGの記述に手を動かせばよく、コードで管理できるためGit運用やレビューにも乗せられます。

Composer環境を構成するスケジューラ・ワーカー・メタデータベース

Composer環境は、Airflowの主要コンポーネントをGoogle Cloudのリソースへ写した構成です。スケジューラがDAGの実行タイミングを判断してタスクをキューへ送り、ワーカーが実際の処理を担います。実行状態や履歴はメタデータベースに保持され、Web UIからDAGの実行状況やログの確認、失敗タスクの再実行を操作できます。DAGファイルの置き場はCloud Storageバケットで、ここへの配置がデプロイに相当する仕組みです。これらの構成要素の可用性やスケール、バージョンのメンテナンスをサービス側が受け持つため、利用者はAirflowクラスタの構築や冗長化を自前で組む必要がありません。ワークフロー管理という役割そのものの整理はオーケストレーションとは？自動化との違いと種類・企業の導入判断を解説で体系立てているので、概念の前提を固めたい場合に役立ちます。

Cloud Composerのバージョンと主要機能を実装者視点で整理

次に、Composerを運用するうえで避けて通れないバージョン系統の違いと、GCP各サービスとの連携機能を見ていきます。ここが料金と運用の前提を左右します。

Composer 1・2・3系の違いとバージョン選択の考え方

Composerには世代があり、基盤とするAirflowのバージョンと課金・ネットワークの仕組みが異なります。Composer 2系はAirflow 2.x系をベースに、環境のクラスタが利用者のプロジェクト内にGKEとしてデプロイされ、環境フィーの時間課金に加えてGKEやデータベースの費用が積み上がる構成でした。Composer 3系（2026年時点の新しい世代）はAirflow 3.x系をベースに、GKEクラスタを利用者プロジェクトに公開せずサービス側で抱える形へ変わり、ネットワーク設定が簡素化され、課金はDCU（Data Compute Unit）を単位とする方式へ移りました。なお旧世代のうちComposer 1と2.0.xは2026年9月15日にサポート終了（EOL）が予定されており、既存環境はComposer 3系や2.1.x以降への移行が前提になります。新規に構築するなら、原則としてComposer 3系を起点に検討するのが実務的です（バージョンの詳細と提供状況は時点で変わるため、公式のリリースノートで最新を確認してください）。

世代 ベースAirflow クラスタとネットワーク 課金の単位
Composer 2系 Airflow 2.x系 利用者プロジェクト内のGKE 環境フィーの時間課金＋GKE等
Composer 3系 Airflow 3.x系 サービス側管理・設定簡素化 DCUベース

BigQueryやDataflow・Dataprocを起動するGCP連携オペレータ

Composerが価値を発揮するのは、複数のGoogle Cloudサービスをまたぐ処理を1本のDAGで束ねる場面です。Airflowには各サービス向けのオペレータが用意されており、BigQueryへのクエリ実行、Cloud Storageのファイル操作、Dataflowジョブの起動、Dataprocクラスタの作成とジョブ投入などをタスクとして書けます。たとえば「Cloud Storageに届いたファイルを検知し、Dataflowで変換し、結果をBigQueryへロードし、完了を通知する」という一連の流れも、依存関係付きのDAGとして表現できる形です。ここでComposerはあくまで各ジョブを順番に起動して結果を待つ指揮者であり、重いデータ処理の実体はDataflowやDataprocが担う、という役割分担です。処理エンジン側の詳細はCloud Dataflowとは？Apache Beamの実行基盤とストリーミング処理を実装者目線で解説とCloud Dataprocとは？マネージドSpark／Hadoopの仕組みと採用判断を実装者目線で解説で確認できます。

スケーリング・監視・ワーカー管理などComposerの運用機能

運用面では、ワーカー数の増減や、DAGの実行状況の監視をサービスが支えます。Airflow Web UIでは、DAGごとの実行履歴や各タスクのログを追え、失敗したタスクだけを選んで再実行する運用がそのまま行える点も利点です。ワーカーは負荷に応じて増減させる設定が可能で、同時実行するタスク数の上限などもパラメータで制御します。監視の指標はCloud MonitoringやCloud Loggingへ流れるため、GCPの他サービスと同じ運用ダッシュボードに載る構成です。Airflowの設定（airflow.cfg相当の項目）も環境の構成として調整でき、接続情報や変数はAirflowのConnectionsとVariablesで一元管理する形が基本です。運用者は、クラスタの面倒を見る代わりに、DAGの並列度やワーカー規模といった論理的なチューニングに注力できます。

Cloud Composerの料金体系と他サービスとの使い分け・採用判断

ここからは費用の構造と、自前Airflowや他のオーケストレーションサービスとの線引き、そして見送るべき場面を実務の判断として言い切ります。

常時起動を前提とするComposerの料金構造とコストを抑える勘所

Composerの費用は、Composer 3系ではDCU（Data Compute Unit）を軸に、スケジューラやワーカーが確保するコンピューティングとストレージへ課金されます。Composer 2系では環境フィーの時間課金に、基盤となるGKEやデータベースの費用が加わる構造でした。いずれの世代でも押さえるべきは、Airflowのスケジューラが常駐する前提のサービスであり、DAGを何も動かしていない待機時間にも一定の費用が発生する点です。小規模な環境でも月額でまとまった固定的コストがかかるため、費用対効果は「Composerで束ねるべき定時ワークフローがどれだけあるか」で決まります。コストを抑える勘所は、環境を用途ごとに乱立させず、関連するDAGを1環境へ集約して常駐コストを分散させること、そしてワーカー規模を実際の並列度に合わせて絞ることにあります。金額の目安は世代・リージョン・環境サイズで変わるため、見積もりは想定するDAG構成での試験環境から起こすのが確実です（2026年7月時点の課金要素）。

自前Airflowや他オーケストレーションサービスとの使い分け

オーケストレーションの選択肢は、運用負荷とワークフローの性質で棲み分けます。Composerが向くのは、依存関係のある定時バッチをGCP中心で回し、Airflowの運用は任せたい場合です。同じAirflowを自前で立てる選択は、Composerの常駐コストを避けたい、あるいはバージョンや構成を完全に自分で握りたい場合に検討しますが、スケジューラの冗長化やアップグレードの手間を引き受ける覚悟が要ります。イベント駆動で軽い処理を安価に動かしたいなら、常駐しないサーバーレスのオーケストレーションが噛み合い、AWS環境ならAWS Step Functionsとは？ステートマシンの仕組み・料金と2種のワークフロー・採用判断を実装者目線で解説のようなステートマシン型が対比になります。判断軸は「Airflowという表現力とエコシステムが要るか」「常駐コストを許容できる規模か」の2点です。

選択肢 性質 向く場面
Cloud Composer マネージドAirflow GCP中心の定時ワークフロー
自前Airflow 自己運用 常駐コスト回避・構成の完全制御
サーバーレス型 イベント駆動 軽量・低頻度の処理連携

Cloud Composerを採用すべき条件と見送るべき場面の切り分け

採用してよいのは、複数のGCPサービスにまたがる依存関係のあるジョブを、定時で確実に回したい場合です。日次のデータパイプライン、ETLの一連の流れ、機械学習の前処理から学習・評価までの手順を、DAGで可視化して再実行や監視まで含めて運用したいなら、Airflowの表現力とComposerのマネージド性が噛み合います。既存のAirflow資産があり、運用だけ軽くしたい移行先としても素直です。一方で、見送ってよい場面も明確です。動かすワークフローが単発かごく少数で、常時起動のスケジューラを抱える固定費に見合わないなら、Composerは重く割高になります。単一のイベントに反応して1つの処理を起動するだけなら、サーバーレスのトリガーやWorkflowsで足り、DAGを組む価値が出ません。GCPをほとんど使わず、特定クラウドに寄せた軽量な連携が主目的の場合も、そのクラウドのネイティブなオーケストレーションのほうが噛み合います。Composerは「GCP中心・依存関係あり・定時・継続運用」が重なる領域で選ぶと外しません。こうしたGCP上のデータ基盤やワークフロー基盤の設計・実装・運用の相談先をお探しの場合は、インフラ構築（AWS・Google Cloud・Azure）で対応しています。

よくある質問

Cloud Composerの導入検討でよく挙がる論点を、実装と費用の観点から簡潔に整理します。

Cloud ComposerとApache Airflowは何が違うのですか？

Apache Airflowはワークフローを定義・実行するオープンソースのソフトウェアで、Cloud Composerはそれをフルマネージドで提供するサービスです。DAGの書き方やオペレータはAirflowのままで、スケジューラやワーカー、メタデータベースの構築と運用をComposerが引き受けます。役割は「Airflow＝ワークフローの仕組み」「Composer＝それを運用する基盤」と分けて捉えると分かりやすくなります。

Cloud ComposerとCloud Dataflowはどちらを使うべきですか？

両者は競合ではなくレイヤが違います。Composerは複数ジョブの依存関係とスケジュールを管理するオーケストレーション層で、Dataflowは実データを変換・集計する処理エンジンです。実務では、Composerが日次でDAGを起動し、その中の重い変換をDataflowが担う、という併用が一般的な形になります。順序管理はComposer、処理の実体はDataflow、と役割で分けて考えます。

Cloud Composerの料金はどのように決まりますか？

Composer 3系はDCU（Data Compute Unit）を軸に、スケジューラやワーカーが確保するコンピューティングとストレージへ課金されます。Airflowのスケジューラが常駐する前提のため、DAGを動かしていない待機時間にも費用が発生し、小規模でも固定的なコストがかかります。金額は世代・リージョン・環境サイズで変わるため、想定するDAG構成の試験環境で見積もるのが確実です。

Composer 2系と3系はどちらを選べばよいですか？

新規構築なら、原則としてComposer 3系を起点に検討します。3系はAirflow 3.x系ベースで、GKEクラスタをサービス側が抱えネットワーク設定が簡素化され、DCUベースの課金に変わりました。旧世代のうちComposer 1と2.0.xは2026年9月15日にサポート終了が予定されており、既存環境は3系や2.1.x以降への移行が前提になります。

既存のオンプレAirflowからCloud Composerへ移行できますか？

Composerは同じApache Airflowを採用しているため、DAGのコード資産やオペレータの多くをそのまま持ち込めます。移行時は、Airflowのバージョン差による記法の変更、ConnectionsやVariablesの移し替え、DAGファイルのCloud Storageバケットへの配置といった作業が中心です。運用面ではスケジューラの冗長化やアップグレードをサービスに任せられるため、自己運用の負荷を下げる移行先として選べます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る