2026.07.27 インフラ

Cloud Tasksとは？GCPの非同期タスクキューの仕組み・リトライと料金、Pub/Sub・Cloud Schedulerとの違いを実装者目線で解説

Cloud Tasksは、Webリクエストの中で処理すると遅くなる仕事を切り離し、キューに積んで別のエンドポイントへ非同期に配信するGoogle Cloudのフルマネージドなタスクキューです。この記事では、キューとタスクという基本モデル、任意のHTTPエンドポイントへ送るHTTPターゲットとApp Engineターゲット、ディスパッチ速度と同時実行数で流量を絞るフロー制御、失敗した処理を自動でやり直すリトライとバックオフ、将来時刻へ配信をずらす実行予約（scheduleTime）までを一次情報で整理します。似た立ち位置のPub/SubやCloud Schedulerとの違い、Cloud Tasksを採用すべき条件と見送るべき場面の判断基準まで、実装者が非同期処理の設計で迷う論点を具体的に示します。

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

Cloud Tasksは、時間のかかる処理をリクエストから切り離し、キューへ積んで指定したエンドポイントへ一定のレートで配信するサービスです。タスクは名前を付けて個別に予約・削除でき、失敗すればバックオフを挟んで自動でやり直されるため、下流の負荷を一定に保ちながら「確実に届ける」設計を組めます。メール送信や画像変換、外部API呼び出しといった重い後処理をWebサーバーから外に出し、応答を素早く返す用途で効きます。

配信先はCloud RunやCloud Functions、GKE、Compute Engine、オンプレのHTTPサービスまで幅広く指定でき、ディスパッチ速度と同時実行数で下流に流す量を調整できます。多数の購読者へイベントを広く配りたいならPub/Sub、決まった時刻に繰り返し走らせたいならCloud Schedulerが向き、個々のタスクを速度制御しながら確実に届けたいときにCloud Tasksが噛み合います。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめて選定してください。

Cloud Tasksの仕組みとキュー・タスクという基本モデルの整理

Cloud Tasksを設計へ落とし込むには、まず「キューにタスクを積み、キューが決めたレートでターゲットへ配る」という骨格を押さえます。ここが曖昧だと、Pub/SubやCloud Schedulerとの役割の境目を見誤り、非同期処理の作り込みを誤った基盤に寄せかねません。

キューとタスクの関係とプッシュ型でターゲットへ届ける配信モデル

Cloud Tasksの中心にあるのが、キューとタスクという2つの単位です。タスクは「メールを送る」「データを加工する」といった1つの処理を呼び出すリクエストで、キューはそのタスクを複数保持し、配信レートを管理する入れ物にあたります。アプリはやりたい処理をタスクとしてキューへ登録し、タスクは正常に実行されるまでキューに保持されます。キューは自分に設定されたレートに従って、タスクをターゲットへリクエストとして送り出す仕組みです。この「キュー側がターゲットへ能動的に送る」プッシュ型の配信が、購読者が取りに来る方式と対になる持ち味です。

HTTPターゲットとApp Engineターゲットという2つのタスク種別

タスクには、配信先の指定方法が異なる2つの種別があります。1つはHTTPターゲットのタスクで、任意のHTTPエンドポイントのURLを指定し、そこへリクエストをプッシュします。もう1つはApp Engineターゲットのタスクで、同一プロジェクトのApp Engine上のハンドラへルーティングされる形です。汎用的に使うのはHTTPターゲットで、Google Cloud内外のさまざまなサービスを配信先にできる柔軟さがあります。認証は、ターゲットに応じてサービスアカウントのトークンをリクエストに付与する形が用意されており、保護されたエンドポイントへも安全に届けられます。

ディスパッチ先にできるCloud RunやGKEなどのHTTPターゲット

HTTPターゲットのタスクは、HTTPで受けられるサービスであれば幅広くディスパッチ先にできます。具体的には、コンテナをそのまま動かすCloud Run（サーバーレスコンテナ実行基盤）、関数単位で処理を載せるCloud Functions（Cloud Run functions）、Kubernetesで運用するGoogle Kubernetes Engine（GKE）、仮想マシン上のサービスであるCompute Engine、さらにオンプレのHTTPサービスまでが受け口になります。タスクの実処理はこれらの配信先が担い、Cloud Tasksは「いつ・どのレートで・確実に届けるか」という配信の制御に徹する分業になっている点が設計の勘所です。

Cloud Tasksのレート制御・リトライ・スケジューリングの設計前提

次に押さえるのが、下流へ流す量を絞るフロー制御、失敗した処理をやり直すリトライ、配信を将来へずらすスケジューリングです。この3つの理解が、到達性と下流の安定を左右します。

ディスパッチ速度と同時実行数でターゲットへの流量を絞るフロー制御

キューには、ターゲットへ流す量を制御する設定があります。1つはディスパッチ速度（1秒あたりに送り出すタスク数の上限）で、もう1つは同時ディスパッチ数（同時に処理中にできるタスク数の上限）です。この2つを絞ると、キューにタスクが大量に積まれても、ターゲットへは一定のペースでしか届かないため、下流のデータベースや外部APIが急な負荷でつぶれる事態を避けられます。逆に、さばける下流であればこれらの上限を引き上げ、スループットを稼げます。アクセスのスパイクをキューでいったん受け止め、ターゲットへは平準化して流すバッファとしての使い方が、この流量制御の効きどころです。

自動リトライとバックオフで失敗したタスクの到達性を保証する設計

タスクの配信が失敗した場合、Cloud Tasksは自動でリトライします。リトライの挙動はキュー単位で設定でき、最大試行回数、リトライ間隔の最小値と最大値、間隔を倍にしていく回数（max_doublings）、リトライを打ち切るまでの最大期間といったパラメータで制御します。間隔を段階的に広げるバックオフを挟むことで、一時的な障害で下流が詰まっているときに追い打ちをかけず、回復を待ってから届け直せるのが持ち味です。この「失敗したら間隔を空けてやり直す」仕組みが、後処理を取りこぼさずに届けたいワークロードの土台になります。ハンドラ側は、同じタスクが複数回届いても二重処理にならないよう冪等に作るのが前提です。

実行予約（scheduleTime）と重複排除というタスク単位の制御

タスクは、登録した直後だけでなく将来の時刻へ配信を予約できます。scheduleTimeに未来の時刻を指定すると、その時刻までキューがタスクを保持し、到達後に配信する遅延実行が組めます。「登録から数時間後にリマインドを送る」といった時間差の処理を、外部のスケジューラを持たずに実装できる形です。加えて、タスクに名前（ID）を付けて登録すると、一定期間は同名のタスクが重複登録されない重複排除が働きます。これにより、二重投入されがちなイベントを1回の処理に収めやすくなります。予約可能な将来の範囲や重複排除の保持期間といった具体値は、Google Cloud公式のドキュメントで対象時点を実測して確定させてください。

Cloud Tasksの料金モデルとPub/Sub・Cloud Schedulerとの違い

基盤選定の決め手になるのが、料金の積み上がり方と、混同されやすいPub/Sub・Cloud Schedulerとの役割の差です。ここを条件で切り分けます。

操作数ベースで積み上がる料金の仕組みと無料枠という課金の考え方

Cloud Tasksの料金は、タスクの操作数（ディスパッチなどの操作回数）を基準に積み上がる構造です。月あたり一定量までの無料枠が用意されており、その範囲に収まる規模なら費用をかけずに使えます。無料枠を超えた分は操作数に対して課金される形のため、コストは「どれだけのタスクを流すか」にほぼ比例する構造です。少量の非同期処理から始めて、量が増えたら課金領域に入るという積み上がり方になるので、想定するタスク数から費用の見当を付けられます。具体的な無料枠の量と単価は公式ドキュメントで対象時点を確認し、月間のタスク数を掛け合わせて試算してください。

Pub/Subとの違いは「個別タスクの制御」か「イベント配信」か

Cloud TasksとPub/Subは、どちらもメッセージを非同期に扱う点で似ていますが、狙いが異なります。Cloud Tasksは、個々のタスクに名前を付けて予約・削除でき、配信レートやリトライをきめ細かく制御する「明示的な呼び出しの管理」に向きます。対してPub/Subは、1つのメッセージを多数の購読者へ広く配るファンアウトや、大量イベントの取り込みといった「疎結合なイベント配信」に向く仕組みです。特定の1つのエンドポイントへ、速度を絞りながら確実に届けたいならCloud Tasks、発行者と購読者を切り離して多対多でイベントを流したいならPub/Subという分岐で考えます。

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

Cloud Schedulerは、cron形式のスケジュールで「毎日9時」のように決まったタイミングで繰り返しジョブを起動するサービスです。一方Cloud Tasksは、その場その場で発生する大量の個別タスクを非同期に配信します。定期的に何かを起動したいならCloud Scheduler、リクエストごとに湧く後処理を積んで捌きたいならCloud Tasks、という役割の違いです。定期起動側の仕組みと採用判断はCloud Schedulerとは？GCPのフルマネージドcronの仕組みとCloud Tasksとの違いの記事で解説しています。両者は組み合わせても機能し、Cloud Schedulerで定時に処理を起動し、その中でCloud Tasksへ大量のタスクを投入して流量を絞りながら配信する、といった構成も取れます。

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

ここでは判断を言い切ります。Cloud Tasksは非同期の後処理を確実に届けることに強い反面、あらゆるメッセージングの受け皿ではありません。自社システムの非同期処理をどの基盤へ寄せるかを、条件付きで見極めてください。

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

採用が効くのは、Webリクエストの中で処理すると遅い仕事を切り離し、特定のエンドポイントへ速度を絞りながら確実に届けたい、という条件が重なるときです。具体例は、応答を待たせないためにメール送信や画像・データ変換を後回しにする後処理、呼び出し回数に上限のある外部APIへレートを守って投げる連携、アクセススパイクをいったん受け止めて下流へ平準化して流すバッファ、登録から時間を置いて動かす遅延実行が当てはまります。処理の実体をCloud RunやCloud Functionsに置き、その手前でCloud Tasksが配信を制御する構成が噛み合います。こうしたGoogle Cloud上の非同期処理基盤を自社に取り入れるなら、AWS・Google Cloudを含むクラウドインフラ構築の相談窓口で、キューのレート設定やリトライ方針、ディスパッチ先の切り分けの妥当性を相談するとよいでしょう。

Cloud Tasksでは向かない要件とPub/SubやWorkflowsへ寄せる場面

1つのイベントを多数の購読者へ同時に配りたい、あるいは大量のイベントストリームを高スループットで取り込みたい要件は、Cloud Tasksでは窮屈になります。この場合はPub/Subのファンアウトへ寄せるのが素直でしょう。また、複数のサービス呼び出しを順序立てて連結し、分岐や待ち合わせを含む一連の処理として組みたいなら、単発タスクの配信に徹するCloud TasksよりWorkflowsのようなオーケストレーションが向きます。逆に、決まった時刻の定期起動だけが要るならCloud Schedulerで足ります。届けたい相手が単一か多数か、処理が単発か多段か、起動が随時か定時かを軸に選定してください。

キュー作成からタスク登録・ターゲット受信までの実装フローの全体像

実装面では、まず配信レートやリトライを設定したキューを作成し、アプリからそのキューへタスクを登録する流れが基本です。HTTPターゲットのタスクなら、配信先URL・HTTPメソッド・ボディ・必要な認証トークンを指定して登録し、キューが設定レートに従ってそのURLへリクエストをプッシュします。受け取る側のCloud RunやCloud Functionsは、通常のHTTPリクエストとしてタスクを処理し、成功を示すステータスを返せば配信完了、失敗を返せばリトライ対象になります。受信側は同じタスクが再送されても壊れないよう冪等に実装し、処理時間がディスパッチのデッドラインに収まるよう設計するのが安定運用の勘所です。

よくある質問

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

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

特定の1つのエンドポイントへ、配信レートやリトライを制御しながら個々のタスクを確実に届けたいならCloud Tasks、1つのイベントを多数の購読者へ広く配るファンアウトや大量イベントの取り込みならPub/Subが基本の分岐です。Cloud Tasksはタスクを名前付きで予約・削除でき明示的に制御でき、Pub/Subは発行者と購読者を切り離して疎結合に配信します。相手が単一か多数かを軸に選びます。

Cloud Tasksのタスクはどこへ配信できますか？

HTTPターゲットのタスクなら、HTTPで受けられるサービスへ幅広く配信できます。Cloud Run、Cloud Functions、GKE、Compute Engine上のサービスに加え、オンプレのHTTPエンドポイントも指定できる形です。別にApp EngineのハンドラへルーティングするApp Engineターゲットもあります。実処理はこれらの配信先が担い、Cloud Tasksは配信の制御に徹します。

配信が失敗したタスクはどうなりますか？

自動でリトライされます。キュー単位で最大試行回数やリトライ間隔の最小・最大値、間隔を倍にしていく回数、打ち切りまでの最大期間を設定でき、間隔を段階的に広げるバックオフを挟んで届け直します。下流が一時的に詰まっても回復を待ってから再送できる仕組みです。受信側は再送に備えて冪等に実装しておきます。

Cloud Tasksで実行を遅らせることはできますか？

できます。タスク登録時にscheduleTimeへ未来の時刻を指定すると、その時刻までキューがタスクを保持し、到達後に配信する遅延実行になります。登録から時間を置いてリマインドや後追い処理を走らせたい場合に向く仕組みです。予約できる将来の範囲は公式ドキュメントで対象時点を確認してください。

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

タスクの操作数を基準に積み上がります。月あたり一定量までの無料枠があり、その範囲なら費用をかけずに使えます。超過分は操作数に対して課金されるため、コストは流すタスク数にほぼ比例する構造です。具体的な無料枠の量と単価は公式ドキュメントで対象時点を確認し、月間タスク数から試算してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る