G-gen の本間です。Google Cloud のネットワーク機能である ハイブリッドサブネット について解説します。ハイブリッドサブネット機能を使うと、オンプレミスネットワークと VPC ネットワーク間で、同じ IP アドレス範囲を共有できます。 概要 ハイブリッドサブネットとは 料金 仕様 ルーティング ルートのアドバタイズ プロキシ ARP の使用 ハイブリッドサブネットを使用した VM 移行 制約事項と注意点 概要 IP アドレスの管理 使用できない環境・サービス オンプレミスネットワーク ルーティング 使用できない通信 概要 ハイブリッドサブネットとは ハイブリッドサブネット とは、Google Cloud の Virtual Private Cloud ネットワーク（以下、VPC ネットワーク）とオンプレミスネットワーク間で、同じ IP アドレス範囲を共有できる機能です。 通常、VPC ネットワークとオンプレミスネットワークを Cloud VPN（IPsec-VPN）や Cloud Interconnect（専用線）で接続する場合、IP アドレス範囲を重複させることはできません。しかし、ハイブリッドサブネットを使用することで、両環境にまたがる単一の論理的なサブネットを構成できます。 この機能は主に、オンプレミスのサーバーを Google Cloud へ移行する際、IP アドレスを変更せずに段階的に移行する目的で使用されます。 一般的に、クラウドへサーバーを移行する際には、サーバーの IP アドレスの変更を視野に入れるケースがあります。この場合、DNS レコードの更新、ファイアウォールルールの修正、依存するアプリケーションの設定変更なども付随して必要となります。 しかし、ハイブリッドサブネットを使用することで、オンプレミス環境と Google Cloud 環境を接続した状態でも同じ IP アドレス範囲をもつサブネットを Google Cloud に用意できるため、IP アドレスの変更が不要です。周辺システムの設定変更を最小限に抑え、Google Cloud 移行時のダウンタイムやリスクを低減できます。 参考 : About migrating to Google Cloud with Hybrid Subnets 料金 ハイブリッドサブネット機能自体の使用には、追加料金は発生しません。 VPC ネットワークのリソースや、送受信されるトラフィックに対する標準的な Google Cloud の料金のみが適用されます。 参考 : Virtual Private Cloud の料金 仕様 ルーティング ハイブリッドサブネットが有効になっているサブネットでは、パケットの転送動作が通常のサブネットとは異なります。 通常のサブネットでは、パケットの宛先がローカルまたはピアリングのサブネットルートと一致する場合、そのリソースへパケットを転送します。また、パケットの宛先が、実行中の Compute Engine VM（以下、VM）や内部転送ルールに関連付けられていなければ、パケットは破棄されます。一方、ハイブリッドサブネットでは以下のように処理されます。 パケットの宛先が一致する場合 パケットの宛先が、サブネット内で実行中の VM のネットワークインターフェースや内部転送ルールと一致する場合、通常のサブネット同様にそのリソースへパケットを配信します。 パケットの宛先が一致しない場合 パケットの宛先が、サブネット内の実行中の VM のネットワークインターフェースや内部転送ルールに一致しない場合でも、パケットは破棄されません。代わりに、ローカルまたはピアリングの静的ルート・動的ルートのネクストホップにパケットが転送されます。この動作により、クラウド上に存在しない宛先へのトラフィックを、オンプレミスネットワークへ正しく転送するための経路が確保されます。 参考 : About migrating to Google Cloud with Hybrid Subnets - Routing in the VPC network ルートのアドバタイズ Google Cloud へ移行されたサーバーへトラフィックを正しく引き込むため、Cloud Router からオンプレミスのルーターに対し、移行された個別の IP アドレスの /32 ルートをアドバタイズする必要があります。このルートは、Cloud Router にカスタムルートとして手動で設定する必要があります。 Border Gateway Protocol（以下、BGP）の最長一致の原則（Longest Prefix Match）により、オンプレミス側のより広い範囲のルート（ /24 など）よりも、Google Cloud 側からアドバタイズされた /32 ルートが優先されます。これにより、通信が正しく Google Cloud 上のサーバーに到達します。 プロキシ ARP の使用 サーバーが Google Cloud に移行された後も、オンプレミス側の他のクライアントは、対象サーバーが同じサブネット内にいると認識して ARP リクエストを送信します。このとき、オンプレミス側のルーターがプロキシ ARP で代理応答し、トラフィックを Cloud Router 経由で Google Cloud へ転送します。 このように、ハイブリッドサブネットを使用するには、オンプレミス側のネットワーク機器（ルーターなど）でプロキシ ARP を有効にする必要があります。 ハイブリッドサブネットを使用した VM 移行 ハイブリッドサブネットを使用して、オンプレミスから Google Cloud へサーバーの移行を行う際の、手順の概要は以下のとおりです。 オンプレミスのルーターが BGP をサポートし、プロキシ ARP を有効にできることを確認する Google Cloud 側で、オンプレミスと同じ IP アドレス範囲を持つ VPC サブネットを作成し、ハイブリッドサブネットルーティングを有効にする Cloud VPN や Cloud Interconnect を構成し、Cloud Router でオンプレミス環境との BGP セッションを確立する Migrate to Virtual Machines などの移行ツールを使用して、サーバーを Google Cloud に移行する 移行したサーバーの IP アドレス（ /32 ）を Cloud Router のカスタムアドバタイズルートに追加する VM の動作確認・試験を行う すべての移行が完了したら、ハイブリッドサブネットルーティングを無効にし、通常の VPC ルーティングに戻す ハイブリッドサブネット機能の有効化自体は簡単で、手順2のサブネット作成時に合わせて設定できます。またサブネットの新規作成時だけでなく、既存のサブネットに対しても、ハイブリッドサブネットを有効化できます。詳細な手順は以下のドキュメントを参照してください。 参考 : Prepare for Hybrid Subnets connectivity 参考 : Migrate workloads to Google Cloud with Hybrid Subnets 参考 : Disable hybrid subnet routing 制約事項と注意点 概要 当記事では、ハイブリッドサブネットの主要な制限を記載します。制限の詳細と、最新情報は公式ドキュメントを参照してください。 参考 : About migrating to Google Cloud with Hybrid Subnets - Limitations IP アドレスの管理 ハイブリッドサブネットには、IP アドレスの重複を自動的に防ぐ仕組みがありません。 そのため、オンプレミス環境と Google Cloud 環境で同じ IP アドレスが同時に使用されないよう、管理者が手動で厳密に IP アドレスを管理する必要があります。具体的には、Google Cloud 側への移行が完了したオンプレミスサーバーは速やかに停止するといった考慮が求められます。 使用できない環境・サービス ハイブリッドサブネットは、Google Cloud VMware Engine をサポートしていません。よってサーバーの移行先が Google Cloud VMware Engine の場合は、前述の移行手順を用いることはできません。 また Microsoft Azure や Amazon Web Services（AWS）とのプライベート接続で、ハイブリッドサブネットを用いることはできません。 オンプレミスネットワーク ハイブリッドサブネットで接続するオンプレミス側の対向機器となるルーターでは、プロキシ ARP の有効化と /32 ルートのアドバタイズの許容が求められます。 事前に使用する機器の仕様や設定を確認してください。 ルーティング ネットワークタグによる静的ルーティングの使用不可 Google Cloud の VPC ネットワークでは本来、Compute Engine VM のネットワークタグ機能を用いて静的ルートを設定可能です。しかし、ハイブリッドサブネットを使用している場合、ネットワークタグを使った静的ルーティングは使用できません。ハイブリッドサブネットでネットワークタグによる静的ルーティングを行っている場合、トラフィックが急増した際にパケットロスを引き起こす原因となります。 リージョンまたぎの通信は不可 ハイブリッドサブネット内のルーティングで宛先に通信を送る際、経路のネクストホップは、サブネットと同じリージョン内に存在する必要があります。異なるリージョンをネクストホップに指定した場合、パケットが破棄され、通信ができません。本来、Google Cloud の VPC ネットワークでは、本来であれば「東京リージョンのサブネットから、大阪リージョンの VPN ゲートウェイへ経路を向ける」といったルーティングも可能です。しかし、ハイブリッドサブネットでは仕様上、そのような設定はできないため注意してください。 使用できない通信 ハイブリッドサブネット環境では、IPv6 トラフィック、ブロードキャストトラフィック、マルチキャストトラフィックはサポートされていません。 また、Network Connectivity Center、ハイブリッド接続 NEG、ハイブリッド NAT とハイブリッドサブネットを併用することはできません。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

はじめに こんにちは！データ推進室 2026年度新卒の島田・山尾です。 株式会社リクルートのデータ推進室では、配属前に約2ヶ月

G-gen の佐々木です。当記事では、実行開始を最大12時間遅らせる代わりに安価に Cloud Run jobs を実行できる機能、 遅延ジョブ（delayed job） について解説します。 概要 Cloud Run jobs とは 遅延ジョブとは ユースケース 遅延ジョブの基本 仕組み トリガーの選び方 タスクのタイムアウト上限 料金比較 単価の比較 月額の試算 注意点 設定手順 遅延ジョブの作成 通常ジョブを遅延実行する 動作確認 待機中の実行の状態 タスクのタイムアウト上限の確認 Cloud Scheduler による平日と週末の使い分けの例 構成 設計上の注意 必要なロール Scheduler ジョブの作成例 概要 Cloud Run jobs とは Cloud Run jobs は、Google Cloud のサーバーレスなコンテナ実行サービスである Cloud Run の提供形態の1つです。HTTP リクエストを待ち受けるのではなく、コンテナで処理を実行して終了するバッチ型のワークロードに使用します。 Cloud Run jobs は、以下の3つのリソースで構成されます。当記事でもこの呼び方を使用します。 ジョブ（job） は、コンテナイメージや CPU・メモリ、タスク数などの設定を保持するリソースです。 実行（execution） は、ジョブを1回実行したときに作られるリソースです。 タスク（task） は、実行の中で起動する個々のコンテナインスタンスであり、1タスク=1インスタンスの関係になっています。 Cloud Run jobs のリソースモデル Cloud Run jobs の基本については、以下の記事を参照してください。 blog.g-gen.co.jp 遅延ジョブとは 遅延ジョブ（delayed job） は、ジョブの実行開始を最大12時間まで Cloud Run 側に委ねる代わりに、通常より低い料金でジョブを実行できる Cloud Run jobs の機能です。2026年9月現在、CPU・メモリの単価はいずれも通常ジョブの70%に設定されています。 遅延実行としてトリガーされた実行は、Cloud Run の利用率が低い時間帯にプロビジョニングされます。ユーザーが開始時刻を指定するものではなく、「12時間以内のいつか」に開始される点が特徴です。 2026年9月現在、遅延ジョブは Preview 公開の機能です。Preview 段階の機能は、サポートが限定される場合や、GA までに仕様が変わる可能性があるため、本番環境での使用は推奨されません。 参考 : Delay execution of a job ユースケース 遅延ジョブは、開始が半日遅れても問題のない処理をコストを抑えて実行する用途に向いています。公式ドキュメントでは、以下のようなユースケースが挙げられています。 緊急でないバッチ処理 夜間に実行する分析処理 大量データに対する AI 推論のバッチ実行 逆に、開始時刻に意味がある処理や、CI/CD の一部として即時に完了させたい処理には向きません。そのような処理は、従来どおりの通常ジョブとして実行します。 参考 : Execute jobs 遅延ジョブの基本 仕組み すべてのジョブは、 通常ジョブ（regular job） か 遅延ジョブ（delayed job） のどちらかとして作成されます。通常ジョブの実行は可能な限り早く開始されます。一方、遅延ジョブの実行はキューに入り、Cloud Run 側の空き容量に応じて12時間以内に開始されます。 遅延実行の指定は、ジョブ定義（作成・更新時）と、1回の実行（実行時）の2つの単位で行えます。ジョブが通常ジョブとして作成されていても実行時に遅延実行として実行でき、その逆も可能です。 設定の単位 効果 ジョブ定義 以降の実行がすべて遅延実行になる 1回の実行 その実行だけが遅延実行になる。ジョブ定義は変更されない 遅延ジョブの最大遅延時間は12時間です。遅延ジョブの実行が24時間以内に完了することを保証するため、タスクのタイムアウトは最大12時間に制限されています。 実行がこの上限に達した場合、実行はシステムによってキャンセルされます。待機中の実行は、通常の実行と同様に gcloud run jobs executions cancel コマンドやコンソール上からユーザーが任意にキャンセルすることもできます。 一方で、待機中の実行を即時実行に切り替えることはできません。ジョブ定義を通常ジョブに更新しても、待機中の実行には影響しません。急ぎで実行したい場合は、待機中の実行をキャンセルし、通常実行として実行し直します。 トリガーの選び方 Cloud Run jobs は、gcloud CLI やコンソールからの手動実行のほか、Cloud Scheduler、Workflows、Cloud Run Admin API の直接呼び出しなど、さまざまな方法でトリガーできます。ジョブ定義を遅延ジョブにしておけば、どのトリガーから実行しても遅延実行になります。 ただし、開始が最大12時間遅れる性質上、トリガーの種類によって向き不向きがあります。 トリガー 向き不向き 理由 Cloud Scheduler 向いている 夜間バッチや日次集計など「当日中に終わればよい」処理と相性が良い。設定次第では平日と週末で通常実行と遅延実行を使い分けるような構成も可能（当記事末尾で解説） Cloud Run Admin API の直接呼び出し 向いている リクエストボディの overrides.delayExecution で実行単位に切り替えられるため、呼び出し側のロジックで通常実行と遅延実行を選べる Eventarc などのイベント駆動 向いていない ファイルのアップロードなどを契機に処理する構成では、最大12時間の待機がそのままイベント処理の遅延になる Workflows の途中ステップ 向いていない 後続のステップがジョブの完了を待つ設計では、ワークフロー全体が最大24時間停止する。完了を待たずに実行だけをトリガーする使い方であれば成立する タスクのタイムアウト上限 2026年9月現在、遅延ジョブのタスクのタイムアウトは最大12時間です。通常ジョブの最大168時間（7日間）より短く制限されています。 タスクのタイムアウトの上限は、ジョブの作成・更新時だけでなく、通常ジョブを実行単位で遅延実行に切り替える場合にも適用されます。 タイムアウトを12時間より長く設定している既存の通常ジョブを遅延実行に切り替えるには、先にタイムアウトを12時間以下に変更する必要があります。 参考 : Cloud Run の割り当てと上限 参考 : ジョブのタスク タイムアウトを設定する 料金比較 単価の比較 遅延ジョブの料金は、通常ジョブと同じく、タスクの実行時間中に割り当てた vCPU とメモリに対する従量課金です。待機中は課金されません。 2026年9月現在、料金ページに掲載されている東京リージョンの単価は以下のとおりです。 リソース 通常ジョブ 遅延ジョブ 比率 CPU（vCPU 秒あたり） $0.000018 $0.0000126 70% メモリ（GiB 秒あたり） $0.000002 $0.0000014 70% CPU・メモリとも、通常ジョブの30%引きの単価です。実行開始を最大12時間遅らせることを許容できるジョブであれば、コードや設定を変えることなく、実行時のフラグ1つでこの割引を受けられます。 参考 : Cloud Run pricing - Delayed Jobs 月額の試算 東京リージョンの割引なしの単価で、無料枠を適用する前の月額を試算します。金額は小数第3位を四捨五入しています。 以下の料金例は、4 vCPU / 16 GiB のタスクを1日2時間、30日間実行した場合（CPU 864,000 vCPU 秒、メモリ 3,456,000 GiB 秒）です。 区分 CPU メモリ 月額（CPU + メモリ） 通常ジョブ $15.55 $6.91 $22.46 遅延ジョブ $10.89 $4.84 $15.72 以下の料金例は、1 vCPU / 2 GiB のタスクを1日30分、30日間実行した場合（CPU 54,000 vCPU 秒、メモリ 108,000 GiB 秒）です。 区分 CPU メモリ 月額（CPU + メモリ） 通常ジョブ $0.97 $0.22 $1.19 遅延ジョブ $0.68 $0.15 $0.83 割引率は一定であるため、ジョブの規模が大きいほど月額の差も大きくなります。2つ目の例の規模であれば、次節の無料枠に収まるため実際の請求は発生しません。 注意点 料金について、以下の点に注意してください。 遅延ジョブの単価は動的であり、最大30日に1回の頻度で変更される可能性があると料金ページに明記されている。当記事の試算は2026年9月現在の単価に基づく 割引オプションは Compute Flexible 確約利用割引（CUD）のみで、Cloud Run CUD は遅延ジョブに適用されない 料金ページの遅延ジョブの表には GPU の行がなく、2026年9月現在、GPU を使用する遅延ジョブの GPU 分の単価は不明 設定手順 遅延ジョブの作成 以降では、gcloud CLI で遅延ジョブを作成・実行し、待機中の実行の状態を確認します。コンソールでも同等の操作が可能で、ジョブの作成フォームの「実行の遅延」チェックボックスで遅延実行を指定できます。 コンソールから遅延ジョブを作成する 検証は東京リージョン（asia-northeast1）で行いました。gcloud CLI のバージョンは以下のとおりです。 # gcloud CLI のバージョンを確認 $ gcloud version ----- 出力例 ----- Google Cloud SDK 583 . 0 . 0 beta 2026 . 08 . 31 // 省略 core 2026 . 08 . 31 // 省略 コンテナイメージには、Google が提供するサンプルのジョブ用イメージ us-docker.pkg.dev/cloudrun/container/job:latest を使用しました。 2026年9月現在、遅延実行の指定には gcloud beta run コマンドを使用します。 gcloud beta run jobs create に --delay-execution を指定して、遅延ジョブを作成します。ジョブの作成に必要なロールは通常ジョブと同じです。 # 遅延ジョブを作成 $ gcloud beta run jobs create delayed-job-a --image us-docker.pkg.dev/cloudrun/container/job:latest --delay-execution --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Creating Cloud Run job [ delayed-job -a] in project [< プロジェクトID >] region [ asia-northeast1 ] Creating job... Done. Job [ delayed-job -a] has successfully been created. To execute this job, use: gcloud beta run jobs execute delayed-job-a # ジョブ定義の遅延実行の設定を確認 $ gcloud run jobs describe delayed-job-a --region = asia-northeast1 --project =< プロジェクトID > --format =' yaml(spec.template.spec.delayExecution) ' ----- 出力例 ----- spec: template: spec: delayExecution: true 既存のジョブを遅延ジョブに変更する、または遅延ジョブを通常ジョブに戻すには、 gcloud beta run jobs update に --delay-execution / --no-delay-execution を指定します。 --execute-now を併用すると、作成・更新と同時に遅延実行をトリガーできます。 参考 : gcloud beta run jobs create 参考 : ジョブを作成する 通常ジョブを遅延実行する 既存の通常ジョブを、ジョブ定義を変更せずに1回だけ遅延実行するには、 gcloud beta run jobs execute に --delay-execution を指定します。コストを抑えたいときにだけ遅延実行を選ぶ、という使い方ができます。 # 通常ジョブを遅延実行として実行 $ gcloud beta run jobs execute regular-job-a --delay-execution --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Creating execution... Provisioning resources.....Done. Delayed execution [ regular-job-a-g95bk ] is queued to start in next 12 hours. View details about this execution by running: gcloud beta run jobs executions describe regular-job-a-g95bk Or visit https://console.cloud.google.com/run/ jobs /executions/details/asia-northeast1/regular-job-a-g95bk? project = < プロジェクト番号 > コマンドは実行の開始を待たず、実行がキューに入った時点で終了します。 --wait を付けた場合は遅延実行が開始・完了するまで終了しないため注意してください。 Cloud Scheduler や Workflows などから Cloud Run Admin API 経由で実行する場合は、 jobs.run メソッドのリクエストボディで overrides.delayExecution に true を指定すると、同じように実行単位で遅延実行になります。 参考 : gcloud beta run jobs execute 動作確認 待機中の実行の状態 作成した遅延ジョブを実行します。遅延ジョブとして作成されているため、実行時には --delay-execution を付ける必要はありません。「queued to start in next 12 hours」と表示され、コマンドは約1秒で終了します。 # 遅延ジョブを実行 $ gcloud beta run jobs execute delayed-job-a --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Creating execution... Provisioning resources.....Done. Delayed execution [ delayed-job-a-r4qhz ] is queued to start in next 12 hours. View details about this execution by running: gcloud beta run jobs executions describe delayed-job-a-r4qhz Or visit https://console.cloud.google.com/run/ jobs /executions/details/asia-northeast1/delayed-job-a-r4qhz? project = < プロジェクト番号 > 待機中の実行の状態を確認すると、 Started 条件の reason が DelayedStartPending になっており、開始を待っていることが分かります。通常の実行では開始と同時に設定される status.startTime は、待機中は存在しません。 # 実行の状態を確認 $ gcloud run jobs executions describe delayed-job-a-r4qhz --region = asia-northeast1 --project =< プロジェクトID > --format =' yaml(spec.delayExecution,status.conditions) ' ----- 出力例 ----- spec: delayExecution: true status: conditions: - lastTransitionTime: ' 2026-09-09T14:29:08.059484Z ' status: Unknown type: Completed - lastTransitionTime: ' 2026-09-09T14:29:08.059484Z ' message: Waiting up to 12 hours for delayed start execution. reason: DelayedStartPending status: Unknown type: Started - lastTransitionTime: ' 2026-09-09T14:29:08.059484Z ' message: System will retry after 02:54:06 from lastTransitionTime for attempt 0 . reason: PostponedRetry severity: Info status: ' True ' type: Retry Retry 条件には「System will retry after ...」として時間が表示されます。この値は実行ごとに最大12時間の範囲で設定されます。 今回の検証では、2026年9月9日の23時30分頃（日本時間）に東京リージョンで遅延実行を7回トリガーしたところ、開始までの待ち時間は以下のとおりでした。 トリガー時刻（日本時間） 開始時刻（日本時間） 待ち時間 23:29:07 翌2:23:18 2時間54分11秒 23:30:48 翌0:17:58 47分10秒 23:31:17 23:46:36 15分19秒 23:31:37 翌1:47:50 2時間16分13秒 23:31:45 翌1:21:02 1時間49分17秒 23:32:50 翌10:48:56 11時間16分06秒 23:33:32 翌1:15:54 1時間42分22秒 待ち時間は実行ごとに異なり、同じ時間帯にトリガーした実行でも15分から11時間程度の幅がありました。 開始後の実行の状態とログは通常の実行と同じで、 Started 条件が True に変わり、 status.startTime が設定されます。遅延実行に固有のログは出力されません。完了後に実行が遅延実行だったことを確認するには、実行の spec.delayExecution を参照します。 タスクのタイムアウト上限の確認 前述のとおり、遅延ジョブは最大遅延時間の12時間とタスクのタイムアウトの合計が24時間を超えないよう設計されています。そのため、遅延ジョブのタスクのタイムアウトに12時間を超える値を指定すると、ジョブの作成・更新・実行のいずれもエラーになります。 # タイムアウト 13 時間の遅延ジョブを作成しようとした場合 $ gcloud beta run jobs create delayed-job-13h --image us-docker.pkg.dev/cloudrun/container/job:latest --delay-execution --task-timeout = 13h --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Creating Cloud Run job [ delayed-job-13h ] in project [< プロジェクトID >] region [ asia-northeast1 ] Creating job... failed Job failed to deploy ERROR: ( gcloud.beta.run. jobs .create ) spec.template.spec.task_spec.timeout: must be between 0 and 43200 seconds ( 12 hours ) , inclusive. また、タイムアウトを24時間に設定した通常ジョブを --delay-execution で遅延実行しようとした場合は INVALID_ARGUMENT としてエラーになります。 # タイムアウト 24 時間の通常ジョブを遅延実行しようとした場合 $ gcloud beta run jobs execute regular-job-24h --delay-execution --region = asia-northeast1 --project =< プロジェクトID > ----- 出力例 ----- Creating execution... failed Executing job failed ERROR: ( gcloud.beta.run. jobs .execute ) INVALID_ARGUMENT: spec.template.spec.task_spec.timeout: must be between 0 and 43200 seconds ( 12 hours ) , inclusive. - ' @type ' : type .googleapis.com/google.rpc.BadRequest fieldViolations: - description: must be between 0 and 43200 seconds ( 12 hours ) , inclusive. field: spec.template.spec.task_spec.timeout このような12時間を超えるタイムアウトを設定した既存の通常ジョブを遅延実行に切り替える場合は、 gcloud beta run jobs execute の --task-timeout で実行単位にタイムアウトを12時間以下に上書きするか、ジョブ定義のタイムアウトを先に変更してください。 なお、ちょうど12時間（ --task-timeout=12h ）は上限の範囲内として受け付けられます。 Cloud Scheduler による平日と週末の使い分けの例 構成 トリガーの選び方の節で触れたとおり、Cloud Scheduler の HTTP ターゲットから Cloud Run Admin API の jobs.run を呼ぶ構成では、リクエストボディの overrides.delayExecution で実行単位に遅延実行を指定できます。 この仕組みを使うと、同じジョブを平日は通常実行、週末は遅延実行で動かす、といった使い分けができます。 ジョブ定義は通常ジョブのままにし、Scheduler ジョブを平日用と週末用の2つ作成します。2つの Scheduler ジョブは呼び出す URL も認証も同じで、スケジュールとリクエストボディだけが異なります。 Scheduler ジョブ スケジュール（Asia/Tokyo） リクエストボディ 実行の種別 平日用 0 22 * * 1-5 {} 通常実行 週末用 0 22 * * 0,6 {"overrides": {"delayExecution": true}} 遅延実行 参考 : スケジュールに従ってジョブを実行する 参考 : Method: projects.locations.jobs.run 設計上の注意 Cloud Scheduler から遅延実行をトリガーする場合は、以下の点を考慮して設計します。 実行は「トリガーから12時間以内のいつか」に開始され、実行時間も最大12時間である。処理の締め切りから逆算し、締め切りの12時間前から想定実行時間をさらに差し引いた時刻より前にトリガーする トリガーの間隔を12時間より短くすると、待機中の実行が積み上がる。1つのジョブは複数の待機中の実行を同時に持てるため、意図しない多重実行につながる 実行時刻が読めないため、入力データはトリガーの時点で揃えておく。実行の直前に生成されるデータに依存する処理は避けるか、ジョブ側でデータの存在を確認してから処理する作りにする なお、 jobs.run は実行が待機中でも即座に応答するため、Scheduler の試行期限（既定で180秒）を気にする必要はありません。 必要なロール Scheduler が認証に使用するサービスアカウントには、Cloud Run のジョブに対してジョブレベルで オーバーライドを使用する Cloud Run ジョブ エグゼキュータ （ roles/run.jobsExecutorWithOverrides ）を付与します。 overrides 付きの jobs.run には、通常の実行に必要な run.jobs.run 権限に加えて run.jobs.runWithOverrides 権限が必要です。 この権限は Cloud Run 起動元（ roles/run.invoker ）や Cloud Run ジョブ エグゼキュータ（ roles/run.jobsExecutor ）には含まれていません。 参考 : Cloud Run roles and permissions Scheduler ジョブの作成例 平日用（通常実行）と週末用（遅延実行）の Scheduler ジョブは以下のように作成します。 # 平日用の Scheduler ジョブを作成（通常実行） $ gcloud scheduler jobs create http regular-job-weekday \ --location = asia-northeast1 \ --schedule =' 0 22 * * 1-5 ' \ --time-zone =' Asia/Tokyo ' \ --uri =' https://run.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/jobs/regular-job-a:run ' \ --http-method = POST \ --oauth-service-account-email =< サービスアカウントのメールアドレス > \ --headers =' Content-Type=application/json ' \ --message-body =' {} ' \ --project =< プロジェクトID > # 週末用の Scheduler ジョブを作成（遅延実行） $ gcloud scheduler jobs create http regular-job-weekend \ --location = asia-northeast1 \ --schedule =' 0 22 * * 0,6 ' \ --time-zone =' Asia/Tokyo ' \ --uri =' https://run.googleapis.com/v2/projects/<プロジェクトID>/locations/asia-northeast1/jobs/regular-job-a:run ' \ --http-method = POST \ --oauth-service-account-email =< サービスアカウントのメールアドレス > \ --headers =' Content-Type=application/json ' \ --message-body =' {"overrides": {"delayExecution": true}} ' \ --project =< プロジェクトID > 佐々木 駿太 (記事一覧) クラウドソリューション部 クラウドエンジニアリング1課 北海道在住 大学院まで社会心理学を専攻し、AI に興味を持ち IT 業界へ。2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。最近は時計がマイブーム Follow @sasashun0805