Cloud Workflowsとは、Google Cloudのサービスや外部APIの呼び出しを「ステップ」として並べ、順序・分岐・リトライ・並列実行をYAMLで宣言的に束ねるサーバーレスのオーケストレーションサービスです。この記事では、仕組みと主要ステップの書き方に加えて、gcloudでデプロイしてCloud Runを呼び出すまでの手順を実際のYAMLとコマンドで示し、内部/外部ステップの料金、Cloud ComposerやAWS Step Functionsとの使い分け、採用を見送るべき場面まで実装者の目線で整理します。数値は2026年9月時点の公式ドキュメントに基づきます。
まとめ：Cloud Workflowsの要点とサーバーレスオーケストレーションの位置づけ
Cloud Workflowsの本体は、処理の各段階を「ステップ」として並べ、遷移をYAML（またはJSON）で宣言的に書く仕組みです。HTTPエンドポイントの呼び出し、Google Cloudサービスへのコネクタ経由の呼び出し、変数への代入、条件分岐、繰り返し、並列実行を、アプリのコードではなく外側の定義に追い出せます。常駐サーバーを持たず、実行したステップ数だけ課金される点が、自前のジョブ制御にはない持ち味です。
使いどころは明快です。Cloud FunctionsやCloud Run、外部APIをまたぐ軽量なサービス連携を、順序・分岐・リトライ込みで束ねたいときに効きます。公式の料金ページでは、月あたり内部ステップ5,000回・外部ステップ2,000回まで無料で、それ以降も内部ステップは1,000回0.01ドルと安価です。逆に、Pythonで書く重厚なデータパイプラインを日次で回すならCloud Composer、単一処理を発火させるだけならCloud Schedulerで足り、Workflowsを挟む必要はありません。GCPを含む基盤の設計・構築はクラウドインフラ構築で相談を受け付けています。
Cloud Workflowsとは何か：YAML/JSONのステップ定義と実行モデル
Cloud Workflowsを理解する起点は、ワークフロー全体を「ステップの列」として捉えることです。各ステップが処理を1つ担い、次のステップへ制御と値を渡しながら、先頭から終端まで実行されます。
ステップを順にたどるワークフロー実行の基本モデルと実行履歴の追跡
1つのワークフローは、複数のステップを上から順にたどって進みます。各ステップは前段の結果を受け取り、自分の処理結果を変数に残して次へ渡します。このデータの受け渡しが実行の背骨です。分岐や繰り返しがあっても、最終的にはreturnで値を返すか終端に達するまで遷移が続きます。実行のたびに一意の実行IDが割り当てられ、各ステップの入出力や所要時間をコンソールやCloud Loggingから追跡できる点も持ち味です。2025年2月には、反復回数やスコープ内変数まで記録する詳細な実行履歴がプレビューで加わりました（リリースノート）。
YAML・JSONによる宣言的なステップ記述とバージョン管理
ワークフローの定義は、YAMLまたはJSONで記述します。実務ではコメントや可読性の面からYAMLが選ばれることが多く、同じ内容をJSONでも表現できます。各ステップに名前を付け、その中に処理の種類（代入・呼び出し・分岐など）を書く構造です。定義はテキストファイルとしてバージョン管理下に置き、差分レビューやIaCでの配布に載せられます。実処理のコードとフローの制御を分離できる点が、宣言的に書く狙いです。構文の全体は公式の構文リファレンスにまとまっています。
assign・call・switch・for・parallelなど主要ステップの役割
ステップには用途ごとの書き方があります。変数へ値を入れるassign、HTTP呼び出しやコネクタ・サブワークフローを呼ぶcall、条件分岐のswitch、配列や範囲を反復するfor、複数の分岐や反復を同時に走らせるparallelが中心です。中でもcallが主役で、http.get／http.postによる任意のエンドポイント呼び出しや、後述のコネクタ呼び出しをここで表します。
並列処理では、親スコープの変数へ書き込むときにsharedで変数名を列挙する必要があり、逐次実行とは扱いが変わります。並列ステップの構文ではconcurrency_limitで同時実行数を絞れ、未処理の例外が出ても他の分岐は走り続けるcontinueAllが現状唯一の例外ポリシーです。
1実行1年・10万ステップ・変数512KBという設計時の実行上限
設計前に押さえたいのが上限値です。公式のクォータと上限によると、1回の実行の最大時間は1年、1実行あたりの最大ステップ数は100,000、全変数の合計メモリは512KB、HTTPレスポンスの最大サイズは2MB、定義ソースは128KBまでです。同時実行数はリージョンあたり10,000（2024年9月に7,500から引き上げ）、並列ステップは1つあたり分岐10本・同時実行20までとなっています。
実務で先に当たるのは512KBの変数上限です。BigQueryの結果やファイルの中身をそのまま変数に載せると上限に届くため、大きなデータはCloud Storageに置いてパスだけを受け渡す設計にしておきます。Workflowsは「データを運ぶ」道具ではなく「段取りを運ぶ」道具だと割り切ると、上限で詰まりにくくなります。
Cloud WorkflowsのgcloudデプロイとCloud Run呼び出し検証
ここからは手を動かして挙動を確かめます。Cloud Runに置いた前処理サービスを呼び、応答コードで分岐し、失敗時は既定のリトライを掛ける最小構成を題材にします。プロジェクトIDやサービスURLは自分の環境に置き換えてください。
APIの有効化とワークフロー用サービスアカウントへのロール付与
まずWorkflowsのAPIを有効化し、ワークフローの実行主体となるサービスアカウントを作ります。付与するロールは、Cloud Runを認証付きで呼ぶ場合がroles/run.invoker、sys.logでログを書く場合がroles/logging.logWriterです。既定のCompute Engineサービスアカウントを流用すると権限が広すぎるため、ワークフローごとに専用のアカウントを用意するほうが監査しやすくなります。
gcloud services enable workflows.googleapis.com workflowexecutions.googleapis.com
gcloud iam service-accounts create wf-runner --display-name="workflows runner"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wf-runner@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/run.invoker"
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:wf-runner@PROJECT_ID.iam.gserviceaccount.com" \
--role="roles/logging.logWriter"Cloud Run呼び出し・switch分岐・リトライを1本のYAMLに書く
次の定義は、引数で受けたファイルパスをCloud Runの前処理サービスへPOSTし、応答の件数が0なら早期に終了、1件以上なら後処理サービスを呼びます。auth: type: OIDCを指定すると、サービスアカウントのIDトークンが自動で付与されます（http.postのリファレンス）。
main:
params: [args]
steps:
- init:
assign:
- preUrl: "https://preprocess-xxxxx-an.a.run.app/run"
- postUrl: "https://postprocess-xxxxx-an.a.run.app/run"
- preprocess:
try:
call: http.post
args:
url: ${preUrl}
auth:
type: OIDC
body:
path: ${args.path}
result: preRes
retry: ${http.default_retry}
- checkCount:
switch:
- condition: ${preRes.body.count == 0}
next: noData
- postprocess:
call: http.post
args:
url: ${postUrl}
auth:
type: OIDC
body:
items: ${preRes.body.items}
result: postRes
- done:
return: ${postRes.body}
- noData:
steps:
- logSkip:
call: sys.log
args:
text: ${"no data for " + args.path}
severity: INFO
- endEmpty:
return: "skipped"ポイントは、前処理にだけretryを掛けている点です。前処理が同じ入力で何度呼ばれても結果が変わらない（冪等な）作りなら既定のリトライを任せられ、後処理のように副作用を持つ呼び出しは、後述する非冪等向けのポリシーか独自の条件に切り替えます。Cloud Run（*.run.app）の呼び出しは料金上「内部ステップ」に数えられる点も、構成を決める材料になります。
gcloud workflows deployとrunで実行し、結果と実行履歴を確認する
定義ファイルをpipeline.yamlとして保存し、gcloud workflows deployでデプロイします。--call-log-levelを付けると各呼び出しの引数と結果がCloud Loggingに残り、動作確認の段階で呼び出しを追跡しやすくするための設定です。実行はgcloud workflows runで、完了まで待ってから結果を表示します。
gcloud workflows deploy pipeline \
--source=pipeline.yaml \
--location=asia-northeast1 \
--service-account=wf-runner@PROJECT_ID.iam.gserviceaccount.com \
--call-log-level=log-errors-only
gcloud workflows run pipeline \
--location=asia-northeast1 \
--data='{"path":"gs://my-bucket/in/2026-09-29.csv"}'
gcloud workflows executions list pipeline --location=asia-northeast1 --limit=5--call-log-levelにはlog-all-calls・log-errors-only・log-noneを指定できます。本番でlog-all-callsのままにすると、引数に含めた個人情報や認証情報までログに出るため、確認が済んだらlog-errors-onlyへ絞るのが安全側の運用です。非同期で起動だけしたいときはgcloud workflows executeを使い、実行IDで後から状態を引きます。
コネクタとトリガーによるGoogle Cloudサービス連携の構成
Cloud Workflowsの主戦場は、Google Cloudの各サービスを1つの流れとしてつなぐことです。呼び出しにはコネクタが用意され、起動にはCloud SchedulerやEventarcを組み合わせます。
コネクタによるサービス呼び出しとリトライ・長時間処理の待受け
コネクタは、Cloud StorageやBigQuery、Pub/Sub、Compute Engineなど個々のGoogle CloudサービスをWorkflowsから呼ぶための定型です。自分でエンドポイントURLや認証を組み立てる代わりに、googleapis.bigquery.v2.tables.getのようなコネクタ名とパラメータを渡すだけで呼び出せます。コネクタはエラー時のリトライを内蔵し、完了までに時間がかかる長時間処理（Long-running operation）はポーリングして終了を待ち受けます。2025年3月にはKubernetes APIコネクタがGAとなり、GKEクラスタ内のオブジェクトも操作できるようになりました。
コネクタのリファレンスでは、呼び出しの既定タイムアウトは1,800秒（30分）で、長時間処理に限ってconnector_params.timeoutで最大31,536,000秒（1年）まで延ばせます。ポーリング間隔は初期1秒・倍率1.25・上限60秒が既定です。BigQueryのジョブ完了を待つ例は次のとおりです。
- runQuery:
call: googleapis.bigquery.v2.jobs.insert
args:
projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
body:
configuration:
query:
query: "SELECT COUNT(*) AS n FROM `my_dataset.orders`"
useLegacySql: false
connector_params:
timeout: 7200
polling_policy:
initial_delay: 5
multiplier: 1.5
max_delay: 120
result: jobポーリングの試行は内部ステップとして課金されるため、数時間かかるジョブを1秒間隔で待つと試行回数が膨らみます。長いジョブほどinitial_delayとmax_delayを広げておくと、料金と待ち時間の釣り合いが取れます。
Cloud Scheduler・Eventarc・APIによるワークフローの起動
ワークフローの起動経路は複数あります。定時実行ならCloud Schedulerからcron式でキックし、イベント起点ならEventarc経由でCloud StorageへのファイルアップロードやPub/Subメッセージを受けて発火させます。手動やアプリからの起動は、gcloudコマンドやExecutions APIを直接叩く形です。起動の「きっかけ」はこれらに任せ、起動後の「段取り」をWorkflowsが担う分担になります。
似た道具との境界も押さえておきます。1件ずつのタスクを遅延実行・流量制御したいならCloud Tasks、多数の購読者へイベントを配るならCloud Pub/Subが本職です。Workflowsは「1つの業務の手順を最後まで見届ける」役割で、キューやメッセージングの代わりにはなりません。
Cloud Functions・Cloud Runなど呼び出し先の連携パターン
最も多い構成は、複数のCloud FunctionsやCloud Runのサービスを順に呼び、途中の結果で分岐させるパターンです。前処理・本処理・後処理をそれぞれ別のサービスに分け、callで順に呼び出します。独立した処理はparallelでまとめて走らせ、全体の待ち時間を縮める構成も定番です。呼ばれる側は自分の仕事だけに集中し、順序と分岐の制御はワークフロー定義が担うため、各サービスを疎結合に保ったまま全体の流れを組み替えられます。
Cloud Workflowsのエラー処理とリトライ・コールバックによる制御
Cloud Workflowsの実利は、失敗時の制御を定義側に書ける点にあります。例外の捕捉、再試行の方針、外部の応答待ちを、アプリのコードに散らさずフロー定義へ寄せられます。
try・retry・exceptによる例外捕捉と既定リトライポリシーの中身
tryブロックで対象のステップを囲み、retryで再試行回数やバックオフの間隔・倍率を指定し、exceptで失敗時の遷移先を書きます。リトライ構文の公式ページには2つの既定ポリシーがあり、どちらも最大5回・初期1秒・上限60秒・倍率1.25のバックオフです。
| 既定ポリシー | 再試行するHTTPコード | 向く呼び出し |
|---|---|---|
| http.default_retry | 429・502・503・504と接続/タイムアウト | 冪等なGETや参照 |
| 非冪等向けの既定ポリシー | 429・503と接続失敗 | 副作用のある更新 |
表の非冪等向けの既定ポリシーはhttp.default_retry_non_idempotentです。独自の条件で絞りたいときは、predicateにサブワークフローを渡して判定を書きます。リトライし切っても失敗したら通知ステップへ分岐させる形が基本です。
- charge:
try:
call: http.post
args:
url: https://api.example.com/v1/charges
headers:
Idempotency-Key: ${args.orderId}
body:
amount: ${args.amount}
result: chargeRes
retry:
predicate: ${http.default_retry_predicate_non_idempotent}
max_retries: 3
backoff:
initial_delay: 2
max_delay: 30
multiplier: 2
except:
as: e
steps:
- notify:
call: sys.log
args:
json: ${e}
severity: ERROR
- fail:
raise: ${e}リトライで同じ処理が複数回走りうるため、呼ばれる側は同じ入力なら同じ結果になる冪等性を確保しておく設計が前提です。複数サービスをまたぐ更新で途中失敗したときの取り消し方は、Sagaパターンの補償トランザクションの考え方をそのままWorkflowsのexcept節に落とし込めます。
コールバックによる外部応答と人手承認の待ち合わせと課金の扱い
人による承認や外部システムの応答を挟むフローでは、コールバック機構でワークフローを一時停止し、発行したURLへHTTPリクエストが届くまで待てます。events.create_callback_endpointでURLを払い出し、events.await_callbackで待機する2ステップ構成で、待機の既定タイムアウトは43,200秒（12時間）です。
- createCallback:
call: events.create_callback_endpoint
args:
http_callback_method: "POST"
result: cb
- sendApprovalMail:
call: sys.log
args:
text: ${"approve here: " + cb.url}
- awaitApproval:
call: events.await_callback
args:
callback: ${cb}
timeout: 86400
result: approval承認側はアクセストークンを付けてcurl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json" -d '{"ok":true}' CALLBACK_URLのように呼び返します。承認待ちのように「いつ返ってくるか分からない」処理を、ポーリングのループを自作せずに表現できるのが持ち味です。なおevents.await_callbackによる待機は料金上「外部ステップ」に数えられます。長時間の待ち合わせを自前の状態管理で書くより、フロー定義に寄せたほうが破綻しにくい構成です。
Cloud Workflowsの料金体系と内部/外部ステップの課金・無料枠を踏まえた試算
料金の考え方は、実行したステップ数を「内部ステップ」と「外部ステップ」に分けて数える方式です。以下は2026年9月時点の公式料金ページの単価をもとにした概算で、実際の請求はリージョンや契約条件で変わりえます。
内部ステップと外部ステップの区分・単価と無料枠の課金の考え方
Google Cloud内のAPI呼び出し（*.googleapis.com）、Compute EngineやGKE上のAPI（*.cloud.goog）、App Engine（*.appspot.com）、Cloud Runの呼び出し、変数代入・条件評価・サブワークフロー呼び出し・標準ライブラリとコネクタ関数・コネクタのポーリングは「内部ステップ」に数えます。Google Cloudの外部APIへのリクエスト、カスタムドメインを付けたGoogle Cloudリソースへのリクエスト、コールバック待ちは「外部ステップ」です。
無料枠は月あたり内部ステップ5,000回・外部ステップ2,000回。超過分は内部ステップが1,000回あたり0.01ドル、外部ステップが1,000回あたり0.025ドルで、1億ステップを超える分は営業窓口での個別見積もりとされています。課金は1,000回単位で切り上げで、公式の計算例では内部6,500回・外部3,999回の月は、超過分がそれぞれ2単位となり合計0.07ドルです。Cloud Runをカスタムドメイン経由で呼ぶと外部ステップ扱いになり単価が2.5倍になるため、Workflowsからは*.run.appのURLで呼ぶのが料金面の定石です。
月あたりの実行回数とステップ数から見たコスト試算の考え方と目安
コストはステップ総数にほぼ比例します。無料枠を踏まえた概算は次のとおりで、あくまで単価からの目安です。
| 月間ステップ数 | 内部ステップの課金目安 | 外部ステップの課金目安 |
|---|---|---|
| 無料枠内 | 0ドル（5,000回まで） | 0ドル（2,000回まで） |
| 100万回 | 約10ドル | 約25ドル |
| 1,000万回 | 約100ドル | 約250ドル |
1回の実行でステップが10回なら、月10万実行で約100万ステップという換算です。先ほどのCloud Run呼び出しのYAMLなら、代入・呼び出し・分岐・returnで1実行あたり5〜6ステップ、リトライが発生した回だけ増えます。分岐やリトライで発生した評価・再試行もステップとして数えるため、ステップ数の見積もりが料金の勘所になります。外部API呼び出しが多いフローは、外部ステップ単価で膨らみやすい点を織り込んでください。
Cloud ComposerやStep Functionsとの違いと使い分けの判断基準
オーケストレーションの選択肢はCloud Workflowsだけではありません。用途の重なる周辺サービスと比べると、Workflowsが向く領域がはっきりします。
Cloud Workflowsとマネージドオーケストレーションの位置づけの比較
同じ「処理をつなぐ」でも、道具ごとに狙う領域が異なります。軽量なサービス連携はWorkflows、重厚なデータパイプラインはComposer、発火のきっかけはSchedulerやEventarc、という切り分けが実務の基準です。
| 観点 | Cloud Workflows | Cloud Composer（Airflow） |
|---|---|---|
| 定義方法 | YAML／JSON | Python（DAG） |
| 実行基盤 | サーバーレス（常駐なし） | 常駐クラスタ（GKE等） |
| 課金 | ステップ従量 | 環境の稼働時間 |
| 向く用途 | 軽量なサービス連携・API連携 | 大規模データパイプライン |
| 起動 | Scheduler／Eventarc／API | スケジュール／センサー |
Cloud WorkflowsとCloud Composer（Airflow）の使い分け
両者の分かれ目は「常駐コストを払ってでもPythonの表現力とエコシステムが要るか」です。日次のETLや複雑な依存関係を持つデータ処理、豊富なオペレーターやプラグインを使いたいならCloud Composerが向きます。Composerは常駐クラスタを持つため、実行が無くても環境の稼働費がかかる代わりに、大規模なDAGを安定して回せます。一方、数個のサービスをイベント起点でつなぐだけなら、常駐コストのないWorkflowsのほうが軽く、無料枠の範囲で収まることも珍しくありません。「毎日決まった重いパイプライン」ならComposer、「イベントで軽く連携」ならWorkflows、と読み分けてください。
AWS Step FunctionsとのYAML/JSON対ASLの違いと移行観点
Cloud Workflowsは、AWSのStep Functionsに対応するGoogle Cloud側のサービスです。定義言語が異なり、WorkflowsはYAML/JSON、Step FunctionsはASL（Amazon States Language）というJSONベースの言語で書きます。Step Functionsが標準型とExpress型で実行モデルを分けるのに対し、Workflowsは単一の実行モデルで、内部/外部ステップの区分で課金を分ける設計です。マルチクラウドで両者を併用する場合、フローの考え方（順序・分岐・リトライ・並列）は共通するため、概念は流用できても定義ファイルはそれぞれの構文で書き分ける必要があります。
クラウドをまたいで同じ定義を動かしたい、あるいは分岐が複雑でYAMLでは書き切れないという場合は、Temporalのようにコードでワークフローを書くエンジンが候補に入ります。その代わり実行基盤の運用は自分で持つことになり、サーバーレスで済むWorkflowsとは運用負荷の桁が変わります。
Cloud Workflowsを採用すべき要件と自前実装・他サービスで足りる見送り場面
ここは判断を言い切ります。Cloud Workflowsは万能ではなく、挟むほど得をする条件があるツールです。複数サービスをまたぐ順序・分岐・リトライ・並列のどれかが効くフローでこそ価値が出ます。
Cloud Workflowsを採用すべきワークフロー要件の判断基準
採用が効くのは、Cloud FunctionsやCloud Run、外部APIをまたいで、条件分岐やリトライ、並列実行を含む処理を組むときです。とくに「どのステップで失敗したかを実行履歴から追いたい」「外部の承認応答を挟みたい」「コネクタのリトライを自作せず任せたい」という要件があるなら、Workflowsの実行履歴とコネクタが直接効きます。常駐基盤を持たずに済むため、実行頻度が低く波のあるワークロードほど、無料枠と従量課金の相性がよい構成です。処理の途中経過を運用担当がコンソールで追える点も、障害対応の速さに直結します。
自前実装やSchedulerで足りるケースと過剰投資となる見送り場面
逆に見送るべき場面もあります。サービスを2〜3個順に呼ぶだけで分岐もリトライも要らないなら、呼び出し側のコードで直接つなぐか、Pub/Subとサブスクライバで足ります。単一のジョブを定時に起動するだけならCloud Scheduler単体で十分で、Workflowsを挟むと定義とステップ課金の管理が増えるだけです。Pythonで書く重厚なデータパイプラインや、豊富なオペレーターが要るETLはCloud Composerのほうが向きます。1実行で数十MBのデータを受け渡す処理も、512KBの変数上限に当たるため設計を見直す合図です。「フローが1本道で、失敗しても手動で流し直せばよい」規模なら、Workflowsは過剰投資です。設計から迷う場合は、要件の切り分け自体をGoogle Cloudを含むインフラ構築で相談できます。
よくある質問
Cloud Workflowsの検討でよく挙がる疑問を、実装者の視点で簡潔に答えます。
Cloud WorkflowsとCloud Functionsの違いは何ですか？
Cloud Functionsは1つの処理（関数）を実行するサービス、Cloud Workflowsはその関数や他サービスを「どの順で、どう分岐・リトライして呼ぶか」を指揮するサービスです。役割が重ならないため、実務では両者を組み合わせ、Functionsが個々の仕事を担い、Workflowsが全体の段取りを担います。単一の処理だけならWorkflowsは不要です。
Cloud WorkflowsとCloud Composerはどちらを選ぶべきですか？
数個のサービスをイベント起点で軽くつなぐならWorkflows、Pythonで書く大規模なデータパイプラインを安定して回すならCloud Composerが向きます。Composerは常駐クラスタの稼働費がかかる代わりに表現力とエコシステムが厚く、Workflowsはサーバーレスで無料枠内に収まることも多い、という違いで選び分けます。
Cloud Workflowsの料金はどのくらいかかりますか？
月あたり内部ステップ5,000回・外部ステップ2,000回までは無料です。超過分は2026年9月時点で内部ステップが1,000回あたり0.01ドル、外部ステップが1,000回あたり0.025ドルで、1,000回単位の切り上げで課金されます。分岐評価やリトライ、コネクタのポーリングもステップとして数えるため、ステップ数の見積もりが料金を左右します。
Cloud WorkflowsはYAMLとJSONのどちらで書きますか？
どちらでも記述できます。同じ定義をYAMLでもJSONでも表現でき、実務ではコメントが書けて可読性の高いYAMLが選ばれることが多いです。定義はテキストファイルとしてバージョン管理下に置き、gcloud workflows deploy --sourceでCI/CDから配布できます。
Cloud Workflowsの最大実行時間や上限はどのくらいですか？
1回のワークフロー実行の最大時間は1年、1実行あたりのステップは100,000まで、変数の合計メモリは512KBまでです。コネクタ呼び出しの既定タイムアウトは1,800秒で、長時間処理に限りconnector_paramsで最長1年まで延長できます。コールバック待ちの既定タイムアウトは12時間です。
関連記事
- Cloud Composerとは：Pythonで書く大規模データパイプライン向けの選択肢とWorkflowsとの使い分け
- AWS Step Functionsとは：AWS側の対応サービス。ASLとの構文の違いと実行モデルの比較
- Cloud Runとは：Workflowsが呼び出す先のサーバーレスコンテナの仕組みと料金
- Google Cloud Functionsとは：Workflowsが順序制御する個々の関数の仕組みと採用判断
- Cloud Schedulerとは：Workflowsを定時起動するcronトリガーの仕組みと使い分け
- Eventarcとは：ファイル到着やPub/Subメッセージを起点にWorkflowsを起動するイベントルーティング
- Cloud Tasksとは：1件ずつのタスクを遅延実行・流量制御する非同期キューとの役割分担
