2026.07.27 インフラ

Cloud Schedulerとは？GCPのフルマネージドcronの仕組み・3つのターゲットとリトライ・料金、Cloud Tasksとの違いを実装者目線で解説

Cloud Schedulerは、決まった時刻や一定間隔で処理を起動する仕事を、サーバーを持たずにGoogle Cloud側へ任せられるフルマネージドなcronジョブスケジューラです。この記事では、実行頻度・ターゲット・リトライを束ねるジョブという基本単位、unix-cron書式とタイムゾーンでのスケジュール指定、HTTP/S・Pub/Sub・App Engineという3つのターゲット種別、スケジュールごとに少なくとも1回起動するat-least-once配信、失敗時の自動リトライとバックオフ、そしてジョブ単位で積み上がる料金までを一次情報で整理します。似た立ち位置のCloud TasksやVM上のcron、AWSのEventBridge Schedulerとの違い、Cloud Schedulerを採用すべき条件と見送るべき場面の判断基準まで、定期実行の設計で実装者が迷う論点を具体的に示していきます。

まとめ：Cloud Schedulerの仕組みと採用判断の要点

Cloud Schedulerは、cron書式で定義したスケジュールに従って、指定したターゲットへ処理の起動を送るマネージドサービスです。ターゲットにはHTTP/Sエンドポイント、Pub/Subトピック、App EngineのHTTP/Sアプリを選べ、スケジュールごとに少なくとも1回はジョブが走るat-least-once配信を土台に、失敗すればバックオフを挟んで自動でやり直します。VMに自前のcronを立てて保守する必要がなく、リトライやCloud Loggingでの監視まで含めてクラウド側に任せられるのが持ち味といえます。

用途としては、日次のバッチ、レポート生成、データ同期、Cloud RunやCloud Functionsの定時起動、インフラの定期クリーンアップなどが噛み合います。決まった時刻に繰り返し起動したいならCloud Scheduler、リクエストごとに湧く大量の後処理を速度を絞って配信したいなら対になるCloud Tasks、という役割分担で考えるのが要点です。料金はジョブ単位で無料枠を超えると月あたりの課金が積み上がるため、必要なジョブ数から費用の見当を付けられます。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて選定してください。

Cloud Schedulerの仕組みとジョブ・スケジュール・ターゲットの基本モデル

Cloud Schedulerを設計へ落とし込むには、まず「ジョブにスケジュールとターゲットを結び付け、その時刻が来たらターゲットへ起動を送る」という骨格を押さえます。ここが曖昧だと、随時発生するタスクを配信するCloud Tasksとの役割の境目を見誤り、定期実行の作り込みを誤った基盤に寄せかねません。

ジョブという基本単位とunix-cron書式のスケジュール指定

Cloud Schedulerの中心にあるのがジョブという単位です。1つのジョブは、いつ動かすかを示すスケジュール、どこへ起動を送るかを示すターゲット、そして失敗時にどうやり直すかを示すリトライ設定をまとめて持ちます。スケジュールはunix-cron書式（分・時・日・月・曜日の5フィールド）で表し、「毎日9時」「5分ごと」「毎月1日」といった繰り返しを1行で指定する形です。加えてタイムゾーンを指定でき、日本時間に合わせた起動時刻をそのまま書けます。公式はジョブを「定義した頻度で実行される、スケジュールされた単一の作業単位」と説明しており、この頻度指定こそがCloud Schedulerの核にあたります。

HTTP/S・Pub/Sub・App Engineという3つのターゲット種別

ジョブが起動を送る先には、3種類のターゲットを選べます。1つ目はHTTP/Sエンドポイントで、任意のURLへHTTPリクエストを送って処理を呼び出します。2つ目はPub/Subトピックで、指定したトピックへメッセージを発行し、購読側の処理を起動する形です。3つ目はApp EngineのHTTP/Sアプリで、同一プロジェクトのApp Engineハンドラへ届けます。汎用的に使うのはHTTP/Sターゲットで、後述するCloud RunやCloud Functionsをはじめ、HTTPで受けられるサービスを幅広く起動先にできる柔軟さがあります。Pub/Subターゲットは、起動を一度メッセージとして受け止めてから複数の購読者へ配りたいときに向くでしょう。

定時起動の送り先になるCloud RunなどのHTTP/Sターゲット

HTTP/Sターゲットのジョブは、HTTPで受けられるサービスであれば幅広く起動先にできます。具体的には、コンテナをそのまま動かすCloud Run（サーバーレスコンテナ実行基盤）や、関数単位で処理を載せるCloud Functions（Cloud Run functions）を定時に叩く構成が代表例です。ジョブが定刻にこれらのエンドポイントへリクエストを送り、実処理はCloud RunやCloud Functions側が担う分業になります。Cloud Schedulerは「いつ・確実に起動を送るか」というスケジューリングに徹し、実行そのものは送り先のサービスに委ねる、という切り分けが設計の勘所です。認証は、送り先に応じてサービスアカウントのOIDC/OAuthトークンをリクエストに付与でき、保護されたエンドポイントへも安全に届けられます。

Cloud Schedulerのat-least-once配信とリトライの設計前提

次に押さえるのが、スケジュールごとに少なくとも1回起動する配信保証、失敗した起動をやり直すリトライ、そして時刻を扱うタイムゾーンです。この3つの理解が、起動の到達性と運用の見通しを左右します。

at-least-once配信と信頼性という起動保証の考え方

Cloud Schedulerは「at least once（少なくとも1回）」の配信を設計思想に掲げており、スケジュールされた各起動につきジョブは少なくとも1回は走ります。裏を返せば、まれに同一スケジュールで複数回起動される可能性がある前提で、受け取る側の処理は同じ起動が二度届いても壊れないよう冪等に組んでおくのが安全です。自前のcronをVMに立てる方式だと、そのVMが落ちればその時刻の起動ごと失われますが、Cloud Schedulerはマネージド基盤側で起動を担保するため、単一サーバーの障害で定期処理が丸ごと止まる事態を避けられます。この「起動を取りこぼしにくい」信頼性が、定期処理をクラウド側へ寄せる動機になります。

自動リトライと指数バックオフで失敗した起動をやり直す設計の勘所

ターゲットへの起動が失敗した場合、Cloud Schedulerはリトライポリシーに従って自動でリトライします。挙動はジョブ単位で設定でき、最大リトライ回数、リトライ間隔の最小値と最大値、間隔を倍にしていく回数、打ち切りまでの最大期間といったパラメータで制御する形です。リトライの間隔を段階的に広げる指数バックオフを挟むことで、一時的な障害で送り先が詰まっているときに追い打ちをかけず、回復を待ってから起動を送り直せます。HTTPターゲットには試行のデッドライン（応答を待つ時間）があり、デフォルトは概ね3分程度で、長い処理に合わせて延長する設定も用意されています。長時間かかる処理は、ジョブ側で待つより、起動を受けた側が非同期に処理を切り出す作りにするのが安定運用の勘所です。

タイムゾーンとcron書式で日本時間の繰り返しを表す実行制御

スケジュールはcron書式に加えてタイムゾーンを指定できるため、日本のビジネス時間に合わせた起動をそのまま定義できます。たとえば「Asia/Tokyoで毎営業日の朝8時」のように、時差の換算を自分で計算せずに書ける形です。サマータイムを持つ地域でも、タイムゾーンを指定しておけば切り替えに追随します。cron書式は5つのフィールドで繰り返しパターンを表し、分単位の細かい間隔から月次の実行まで1行で表現できます。まずは低頻度のジョブで挙動とログを確認し、そこから本番のスケジュールへ広げると、想定外の多重起動やタイムゾーンのずれに早く気付けるでしょう。

Cloud Schedulerの料金モデルとCloud Tasks・cronとの違い

基盤選定の決め手になるのが、料金の積み上がり方と、混同されやすいCloud Tasks・VMのcron・AWSのスケジューラとの役割の差です。ここを条件で切り分けます。

ジョブ単位で積み上がる料金の仕組みと無料枠という課金の考え方

Cloud Schedulerの料金は、ジョブの数を基準に積み上がる構造です。2026年7月時点の公式では、課金アカウントあたり月に3ジョブまでが無料枠で、それを超えた分は1ジョブあたり月0.10ドル（日割りでおよそ0.003ドル/日）が目安とされています。ここで注意したいのは、課金がジョブ単位であってジョブの実行回数では課金されない点です。5分ごとに走るジョブでも、月1回のジョブでも、1ジョブとしての料金は同じ考え方になります。加えて、無料枠は課金アカウント単位（プロジェクト横断）で数える形で、一時停止中のジョブも課金対象として数えられます。ジョブ数から費用の見当は付けやすい構造ですが、無料枠の数や単価は公式ドキュメントで対象時点を確認し、必要なジョブ数を掛け合わせて試算してください。

Cloud Tasksとの違いは「定期実行」か「大量の個別タスク」か

Cloud SchedulerとCloud Tasksは、どちらも処理の起動を扱う点で似ていますが、狙いが異なります。Cloud Schedulerは、cronで定義した少数の繰り返しジョブを定刻に起動する「スケジュール駆動」に向きます。対してCloud Tasks（GCPの非同期タスクキュー）は、リクエストごとに随時発生する大量の個別タスクを、レートを絞りながら非同期に配信する仕組みです。決まった時刻に何かを起動したいならCloud Scheduler、その場その場で湧く後処理を積んで確実に捌きたいならCloud Tasks、という役割の違いになります。両者は組み合わせても機能し、Cloud Schedulerで定時にトリガーを引き、その先でCloud Tasksへ大量のタスクを投入して流量を絞りながら配信する、といった構成も取れます。

VMのcronやEventBridge Schedulerとの違いの整理

従来はVMを立ててそこにcronを仕込む方式が定番でしたが、この方式はサーバーの保守・監視・冗長化を自分で抱える負担があり、そのVMが落ちればその時刻の起動が失われます。Cloud Schedulerはこれらをマネージド基盤へ寄せ、リトライやCloud Loggingでの監視まで込みで扱える点が違いです。なお以前はプロジェクトにApp Engineアプリが必要でしたが、現在はApp Engineをターゲットに使わない限りその用意は要りません。AWSで同じことをするなら、Amazon EventBridge Schedulerが対応するスケジューラにあたり、cron/rate式でのスケジュール起動という発想は共通します。マルチクラウドやAWS側での実装を検討する際は、この対応関係を押さえておくと設計の見通しが立ちます。

Cloud Schedulerを採用すべき条件と見送るべき場面の判断基準

ここでは判断を言い切ります。Cloud Schedulerは定期的な起動を確実に届けることに強い反面、あらゆる処理起動の受け皿ではありません。自社システムの定期実行や非同期処理をどの基盤へ寄せるかを、条件付きで見極めてください。

Cloud Schedulerの採用が効くワークロードと要件の見極め

採用が効くのは、決まった時刻や一定間隔で処理を起動したい、そのためだけにサーバーを立てて保守したくない、という条件が重なるときです。具体例は、日次・時間次のバッチ処理、定期レポートの生成、システム間のデータ同期、Cloud RunやCloud Functionsに載せた処理の定時起動、不要リソースの定期クリーンアップ、Pub/Sub経由での定時ワークフロー起動などが当てはまります。処理の実体はCloud RunやCloud Functionsに置き、その起動タイミングだけをCloud Schedulerに任せる構成が噛み合います。こうしたGoogle Cloud上の定期実行・非同期処理基盤を自社に取り入れるなら、AWS・Google Cloudを含むクラウドインフラ構築の相談窓口で、スケジュール設計やリトライ方針、起動先の切り分けの妥当性を相談するとよいでしょう。

Cloud Schedulerが向かない要件とCloud Tasksへ寄せる場面

リクエストごとに随時発生する大量の後処理を、レートを絞りながら1件ずつ確実に届けたい要件は、定期起動に徹するCloud Schedulerでは窮屈になります。この場合はCloud Tasksの非同期タスクキューへ寄せるのが素直でしょう。また、複数のサービス呼び出しを順序立てて連結し、分岐や待ち合わせを含む一連の処理として組みたいなら、単発の起動を送るCloud SchedulerよりWorkflowsのようなオーケストレーションが向きます。さらに、ミリ秒単位の即時性や、外部イベントに反応して動く仕組みが要るなら、時刻駆動のCloud Schedulerではなくイベント駆動の構成が適します。起動が定時か随時か、処理が単発か多段か、駆動がスケジュールかイベントかを軸に選定してください。

ジョブの作成からターゲット受信までの実装フローの全体像の把握

実装面では、まずスケジュール（cron書式とタイムゾーン）・ターゲット・リトライ設定を指定したジョブを作成する流れが基本です。HTTP/Sターゲットのジョブなら、起動先URL・HTTPメソッド・ボディ・必要な認証トークン（サービスアカウントのOIDC/OAuth）を指定して登録し、定刻になるとCloud SchedulerがそのURLへリクエストを送ります。受け取る側のCloud RunやCloud Functionsは、通常のHTTPリクエストとして処理し、成功ステータスを返せば起動完了、失敗を返せばリトライ対象になります。受信側はat-least-once配信を前提に、同じ起動が再送されても壊れないよう冪等に実装し、処理時間が試行デッドラインに収まるよう設計するのが安定運用の勘所です。作成後は、まず手動実行で疎通を確かめ、Cloud Loggingで起動と結果を追える状態にしてから本番のスケジュールへ広げると安全に立ち上げられます。

よくある質問

Cloud Schedulerの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Cloud SchedulerとCloud Tasksはどう使い分ければよいですか？

決まった時刻や一定間隔で少数のジョブを定期起動したいならCloud Scheduler、リクエストごとに随時発生する大量の個別タスクを非同期に配信したいならCloud Tasksが基本の分岐です。Schedulerはcron書式でスケジュールを表し、Cloud Tasksはタスクを名前付きで予約・削除して配信レートを制御します。両者は併用でき、Schedulerで定時に起動し、その先でCloud Tasksへタスクを投入する構成も取れます。

Cloud Schedulerはどこへ起動を送れますか？

ターゲットは3種類あります。任意のURLへリクエストを送るHTTP/Sエンドポイント、メッセージを発行するPub/Subトピック、同一プロジェクトのApp EngineのHTTP/Sアプリです。HTTP/SターゲットではCloud RunやCloud Functionsをはじめ、HTTPで受けられるサービスを幅広く定時起動でき、サービスアカウントのトークンで保護されたエンドポイントへも届けられます。

起動が失敗したジョブはどうなりますか？

リトライポリシーに従って自動でリトライされます。ジョブ単位で最大リトライ回数やリトライ間隔の最小・最大値、打ち切りまでの最大期間を設定でき、間隔を段階的に広げる指数バックオフを挟んで起動し直す仕組みです。またCloud Schedulerはat-least-once配信のため、受け取る側は再送に備えて冪等に実装しておくのが前提になります。

Cloud SchedulerにApp Engineアプリは必要ですか？

現在は、App Engineをターゲットに使う場合を除いて必要ありません。以前はプロジェクトにApp Engineアプリの用意が求められていましたが、HTTP/SやPub/Subをターゲットにするだけなら、App Engineアプリを用意せずに利用でき、既存のApp Engineアプリを無効化することもできます。

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

ジョブの数を基準に積み上がります。2026年7月時点では課金アカウントあたり月3ジョブまでが無料枠で、超過分は1ジョブあたり月0.10ドルが目安です。課金はジョブ単位でありジョブの実行回数では課金されず、一時停止中のジョブも数えられます。具体的な無料枠と単価は公式ドキュメントで対象時点を確認し、必要なジョブ数から試算してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る