月末の請求処理や、AIエージェントが外部のAPIを何度も呼ぶ処理を、途中で落ちても続きから再開できるように組みたい。そのためにワークフローの実行基盤（Temporal）を使うと、今度はタスクを取りに行くワーカーを、仕事がない時間も含めて動かし続ける必要が出てきます。Google Cloudの公式ブログも、ワーカーはリクエストを受けるのではなくタスクを取りに行くため、リクエストで動くサーバーレスとは相性が悪く、KubernetesやVMで常に動かして費用を払い続けることになりやすい、と書いています。
2026年10月15日（日本時間16日）、Google Cloudは「Temporal Serverless Workers on Cloud Run」をプレビューとして紹介しました。Temporalの更新履歴では、8月6日にプレリリース、10月5日にパブリックプレビューとなっています。マネージド版のTemporal Cloudが、Cloud Runの「ワーカープール」の台数を、タスクのキューの状況に合わせて決め、仕事がなければ0台まで減らします。プレビューなのはこのTemporalの機能で、ワーカープール自体は2026年4月14日に一般提供になっています。この記事では、ブログとTemporalのドキュメントから仕組みと条件を整理し、導入の前に確かめる点を提案します。
誰が台数を決め、何が利用者の側に残るか
ブログによると、役割の分担は次のとおりです。
- ワーカー: Cloud Runのワーカープールのインスタンスとして、利用者のプロジェクトで動き、Temporal Cloudにタスクを取りに行く。利用者のサービスアカウント、利用者のネットワークで動く
- Temporal Cloud: タスクのキューを見て、Cloud Run Admin APIでワーカープールのインスタンス数を設定する。利用者が与えたIAMの権限を使う。Temporalからインスタンスへ接続することはないため、ポートを開けたりファイアウォールのルールを足したりする必要はない
- ワーカープール: Cloud Runの、常時のバックグラウンドの処理のためのリソース。公開のエンドポイントを持たず、各インスタンスには動いている間ずっとCPUが割り当てられる。Cloud Runのドキュメントのとおり、ワーカープール自体に自動伸縮はなく、その役目をTemporalが担う
ブログは、ワーカーのコードは変えずに済み、クラスタや自動伸縮の仕組みを自分で動かす必要はないとしています。Temporalのドキュメントも、Cloud Run専用の処理は要らず、どのTemporal SDKでも動くと説明しています。ただし、後で触れるWorker Versioningは必須で、すべてのワークフローに版の動きの宣言が要ります。Worker Versioningをまだ使っていないワーカーは、その分の変更が必要です。
台数はどう決まるか
ブログとドキュメントが説明する伸縮の仕組みは次のとおりです。ドキュメントでは、台数を管理する部品をWorker Controller Instance（WCI）と呼びます。
- 増やす合図: ブログは、タスクがキューに積まれてからワーカーが取るまでの遅れを、主な合図として説明しています。ドキュメントはもう少し具体的で、空いているワーカーがないタスクが来たときにすぐ増やす動きと、タスクの到着の速さと1台の処理の速さから台数を定期的に計算し直す動きの、2つを組み合わせると書いています
- 先回り: 新しいインスタンスは起動と接続に時間がかかるため、Temporalは予備の台数を持ち、タスクが溜まる前に増やす。ドキュメントによると、ワーカーの稼働率の目標（既定で80%）に合わせて台数を決めることで、余力を残す
- 減らすときは慎重に: タスクが空きのワーカーを見つけられなかった最後の時点から、安定のための待ち時間（既定で90秒）を置き、減らす操作の間にも間隔を空ける。待ち時間は
--gcp-cloud-run-scale-down-stabilization-durationで変えられる（Temporal CLI v1.8.3以降） - 上限と下限: 台数は、利用者が決めた最小と最大の間に収まる（既定は最小0、最大30）。最大を超えるタスクは捨てられず、キューで待つ
停止のときの猶予（graceful shutdown）は、Cloud Runの設定で10秒から10分まで延ばせるとブログは書いています。この設定はプレビューで、ブログは申し込みの案内を載せています。Cloud Runのドキュメントの現在の説明では、SIGTERMの通知から強制終了までは10秒です。
Cloud Runのサービスで動かす場合との違い
ブログは、これまでCloud Runの「サービス」でTemporalのワーカーを動かすには、HTTPを待ち受ける処理を足す、リクエストの合間もCPUを保つためにインスタンス単位の課金にする、0台に減らないよう最小インスタンスを置く、といった回避策が必要だったと書いています。
ワーカープールでは、公開のURLやロードバランサー、ヘルスチェックのポートが要りません。台数を変えても新しいリビジョンが作られないため、Temporalが負荷に合わせて何度でも台数を変えられます。料金について、ブログは、ワーカープールの定価がインスタンス単位の課金のCloud Runのサービスより、vCPU時間とGB時間あたり40%近く低いとしています。料金のページのus-central1の定価を比べると、vCPU秒あたり0.000011244ドルと0.000018ドル、GiB秒あたり0.000001235ドルと0.000002ドルで、どちらも約38%低い値でした。実際の費用は、台数・時間・リージョンで変わります。編集部では見積もりをしていません。
版の切り替えには、Worker Versioningが必須
Temporalのワークフローは、状態を持ち、決定的に動く前提です。実行の途中でコードを差し替えると、非決定性のエラーになります。ブログとドキュメントによると、Serverless Workers on Cloud Runでは、TemporalのWorker Versioningを使うことが必須です。
- ビルドの版（Worker Deployment Version）ごとに、別のワーカープールを作る。版は
deploymentNameとbuildIdで区別する - 古い版のワークフローが終わっていくと、そのワーカープールは自動で0台まで減る。
PINNEDのワークフローが残っている間は、0台のままでよいのでプールを消さない - 動いている版を指すプールに新しいイメージを入れない。新しいリビジョンがすべてのインスタンスに行き渡り、版の番号は同じまま中身のコードが変わるため、
PINNEDのワークフローでも非決定性のエラーになり得るとドキュメントは注意している - 計算資源の設定を持つ版の数は、Namespaceごとに既定で100まで。ワークフローが終わった版も数えるため、不要な版は消す
ワークフローの種類ごと（またはワーカーの既定）に、次のどちらかを選びます。
| 設定 | 動き | ブログが挙げる向き先 |
|---|---|---|
PINNED | 始めたときの版で最後まで動く | 短いワークフロー、注文の処理、多段のAPI |
AUTO_UPGRADE | 新しい版を出すと、そちらへ移る | 長く動くワークフロー（定期課金、数週間かかる処理） |
ブログは、版を分ければ条件分岐でコードを直さずに済むと説明しています。ただしドキュメントは、AUTO_UPGRADE のワークフローは1つの版に固定されないため、パッチなどで再実行に耐える状態を手で保つ必要があるとしています。
導入の前に確かめること
ブログが示す手順は、ワーカーをコンテナにしてワーカープールとしてデプロイし（プール名にビルドIDを入れ、TemporalのAPIキーはSecret Managerに置く）、Temporal Cloudにワーカープールを管理する権限を与え、Temporalでワーカープールのプロジェクト・リージョン・名前を指すWorker Deployment Versionを作る、という3つです。Temporalの手順書では、さらに作った版を現在の版に設定します。これをしないと、タスクがその版に流れず、インスタンスも起動しません。ここに、編集部の提案として次の確認を加えます。
- Temporalがどこで動いているか: ドキュメントの前提は、GCP上のNamespaceを持つTemporal Cloudか、v1.31.0以降の自前運用のTemporal Serviceです。Namespaceのクラウドは計算資源の提供元と同じである必要があるため、Temporal Cloudの場合、別のクラウドのNamespaceのままでは使えません。自前運用では、サーバーの設定でWCIを有効にするなどの追加の準備が要ります
- 0台からの初回の遅れを許せるか: 0台から起動するまでの時間は、ブログにもドキュメントにも数値がありません。ブログは、待てない処理では最小の台数を0より大きくするよう書いています
- IAMの権限の範囲: Temporal Cloudは、利用者が作る呼び出し用のサービスアカウントになり代わって、ワーカープールを操作します。Temporalが配るTerraformのモジュールの既定では、このアカウントにプロジェクト単位の
roles/run.developerが付きます。台数の変更より広い権限なので、絞るならrun.workerPools.getとrun.workerPools.updateを含むロールをdeploy_rolesに指定します。ワーカー自身が動くサービスアカウントとは別のものです。Temporal Cloudの画面の「Validate Connection」は読み取りの確認だけで、台数を変える権限までは確かめません - 停止の猶予と、処理の途中での再試行: ドキュメントによると、台数を減らす判断は、インスタンスが処理の途中かどうかを見ません。ブログは、ワーカーが途中で消えても、処理（アクティビティ）は別のワーカーで再試行されると書いています。長い処理はハートビートで進み具合を記録し、外部への書き込みを伴う処理は、二重に実行されても困らない作りにしておきます
- 常駐のワーカーとタスクキューを分ける: ドキュメントは、ワーカープールと常駐のワーカーで同じタスクキューを共有しないよう書いています。常駐のワーカーが処理している分も含めて台数を計算するため、余分なインスタンスの費用がかかります。移行の途中も、タスクキューの分け方を決めておきます
- プレビューであること: ブログとドキュメントは、安定版までにAPIや設定が変わる可能性があるとしています。Multi-cloud Replicationには対応しておらず、ドキュメントはプレビューの間の一時的な制限と説明しています
ワークフローの実行基盤を自前で作るか、製品を使うかの判断は、業務の自動処理が増えたら — ワークフロー基盤を作るか買うかで整理しました。長いバッチをどこに置くかの考え方は、Lambdaの90分は全部には効かない — バッチの置き場所も参考になります。
確認した範囲
2026年11月6日に、Google Cloud公式ブログの「Temporal Serverless Workers on Cloud Run: Scale workers ahead of demand」（公開日の情報は2026年10月15日、ページの表示は10月16日）、Temporalのドキュメントと更新履歴、Cloud Runのリリースノート、ドキュメント、料金のページを開いて確認しました（資料調査）。Temporal Cloudの料金のページはServerless Workerへの対応を機能として挙げていますが、台数の管理そのものが料金にどう数えられるかは確かめられていません。ワーカープールを作っての検証もしていません。導入の前の確認は、編集部の提案です。
夜間の処理やAIエージェントの多段の処理を、止まっても再開できる形で組み直す設計は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Temporal Serverless Workers on Cloud Run: Scale workers ahead of demand（Google Cloud Blog、2026年10月15日）
- Serverless Workers on GCP Cloud Run（Temporal Documentation）
- Deploy a Serverless Worker on GCP Cloud Run（Temporal Documentation）
- Serverless Workers（Temporal Documentation）
- Cloud Changelog（Temporal）
- Cloud Run release notes（Google Cloud）
- Cloud Run pricing（Google Cloud）
