Queues / Workflowsとは？非同期処理の仕組み（統合解説）

《 Cloudflare完全ガイド 目次へ 》

前ページのDurable Objectsは「同時に来る処理をひとつずつ正しく捌く」仕組みでした。このページで扱うQueues（キューズ）とWorkflows（ワークフローズ）は、視点を変えて「いま返さなくてよい処理を、確実に後で終わらせる」ための仕組みです。

Webアプリケーションを作っていると、必ず「重い処理」に突き当たります。画像の変換、メールの送信、外部APIの呼び出し、AIによる文章の生成。これらを利用者を待たせたまま実行すると、画面は固まり、途中でエラーが起きればやり直しになります。この問題への標準的な答えが非同期処理であり、CloudflareではQueuesとWorkflowsがその役割を担います。

このページで分かること

• 非同期処理とは何か、なぜ必要なのか
• Cloudflare Queuesの仕組み（送る側・受け取る側・リトライ・デッドレターキュー）
• Cloudflare Workflowsの仕組み（ステップに分けた耐久性のある実行）
• QueuesとWorkflowsの違いと使い分け
• 料金と主な制限

非同期処理とは

利用者がボタンを押してから結果が返るまでの間に、すべての処理を終わらせる方式を同期処理と呼びます。分かりやすい代わりに、処理が重いほど待ち時間が延びます。

非同期処理では、受け取った時点では「承りました」とだけ返し、実際の作業は裏で進めます。利用者は待たされず、作業の途中で失敗しても、その部分だけをやり直せます。

たとえば会員登録の場面を考えます。同期処理なら「登録する → ウェルカムメールを送る → 初期データを作る → 完了画面を出す」と一直線に進み、メール送信の外部サービスが数秒詰まれば、その分だけ利用者は待たされます。非同期処理なら、登録だけを済ませて即座に完了画面を返し、メール送信と初期データ作成は裏で進めればよいことになります。

この「裏で進める仕事」を預けておく場所がキューであり、その仕事が複数の手順にまたがる場合の進行管理をするのがワークフローです。

Cloudflare Queues：仕事を預けて順に処理する

Queuesは、Workersから送られたメッセージ（仕事の依頼書）を預かり、別のWorkerへ順に渡していく仕組みです。登場人物は2つだけです。

• プロデューサー（送る側）：処理してほしい内容をキューへ送るWorker
• コンシューマー（受け取る側）：キューからメッセージを受け取って実際に処理するWorker

送る側は、キューへ投げた時点で自分の仕事を終えられます。受け取る側は、自分のペースで処理を進めます。両者が直接つながっていないため、片方が混雑してももう片方は影響を受けません。

Queuesの実用上の要点は次の3つです。

バッチ処理：メッセージは1件ずつではなく、最大100件をまとめて受け取れます。1件ずつ処理するより効率が良く、実行回数も抑えられます。

自動リトライ：処理中にエラーが起きたメッセージは、キューへ戻されて再度配信されます。外部APIの一時的な不調のような、時間を置けば直る失敗に強い作りです。再試行は最大100回まで設定できます。

デッドレターキュー：何度やっても失敗するメッセージは、放っておくと無限に再試行を繰り返します。これを避けるため、規定回数を超えた分を別のキュー（デッドレターキュー）へ退避させられます。あとから中身を確認し、原因を調べて手当てできます。

このほか、指定した時間だけ配信を遅らせる遅延配信も利用できます。「30分後に確認メールを送る」といった処理が、タイマーを自作せずに書けます。

Cloudflare Workflows：途中で落ちても続きから

Queuesが「1件の仕事を確実に渡す」仕組みなのに対し、Workflowsは「複数の手順からなる一連の作業を、確実に最後まで完走させる」仕組みです。

Workflowsでは、処理をステップに分けて書きます。各ステップの結果は自動的に保存され、途中のステップで失敗しても、そのステップから再開されます。すでに終わったステップをやり直すことはありません。この性質を耐久性のある実行（Durable Execution）と呼びます。

たとえば「注文を受ける → 決済する → 在庫を引き当てる → 発送を依頼する → 完了メールを送る」という流れを考えます。もし在庫の引き当てで外部システムが落ちていた場合、Workflowsは決済からやり直したりせず、在庫の引き当てだけを繰り返し試みます。二重決済のような事故が起きません。

もうひとつの特徴が待機です。sleep を使って処理を止められ、その期間は最大365日に及びます。しかも待っている間はリソースを消費しません。「登録の3日後にフォローアップのメールを送る」「翌月1日に集計する」といった、時間をまたぐ処理をひとつのコードとして書けます。

Workflowsもコード上はWorkersの一種で、Wranglerで開発・デプロイします。

QueuesとWorkflowsの使い分け

両者は競合するものではなく、扱う対象が違います。

判断の目安は、「その仕事は1回で終わるか、それとも順番に進む複数の段階があるか」です。前者ならQueues、後者ならWorkflowsが向いています。両方を組み合わせ、キューで受け取った依頼をワークフローとして開始する、という構成も可能です。

料金と主な制限

Queuesは無料プランでも利用できます（2026年8月時点）。

• 有料プランでは月100万オペレーション込み、超過分は100万オペレーションあたり0.40ドル
• オペレーションはデータ64KBごとに1回と数えます。1件のメッセージは通常「書き込み・読み取り・削除」で3オペレーション必要です
• キュー数：1アカウント10,000まで
• メッセージサイズ：128KBまで／1回のバッチ：最大100件
• 保持期間：無料プランは24時間固定、有料プランは最大14日まで設定可能
• スループット：1キューあたり毎秒5,000メッセージ

Workflowsも無料プランで利用できます。

• ステップ数：Free 1,024／Paid 既定10,000（最大25,000）
• 同時実行インスタンス：Free 100／Paid 50,000（待機中のインスタンスは数に含まれません）
• 1日の実行回数：Free 10万回（Workersと共有）／Paid 無制限
• 保存状態：Free 1インスタンス100MB／Paid 1GB
• 完了後の記録の保持：Free 3日／Paid 30日
• 実行そのものの費用はWorkersと同じ体系（CPU時間）で計算されます

初心者が注意するポイント

• 「必ず1回だけ」ではありません：Queuesは配信を保証しますが、リトライの都合で同じメッセージが2回処理される可能性があります。二重に実行されても困らない作り（同じ処理を2回行っても結果が変わらない設計＝冪等性）にしておくのが安全です
• デッドレターキューは最初から設定する：失敗し続けるメッセージの退避先を決めておかないと、原因調査が難しくなります
• Workflowsのステップは細かく分ける：ステップ単位で再開されるため、大きな処理をひとつのステップに詰め込むと、やり直しの範囲が広がります
• ステップの結果は保存されます：各ステップの返り値は保存されるため、上限（1MiBまで）を超える大きなデータはR2などに置き、ステップ間ではその場所だけを受け渡してください
• 待たせない設計が目的です：非同期にすれば速くなるわけではなく、利用者を待たせない構造にするための仕組みです。処理そのものの総量は変わりません

関連サービス

• Workers：QueuesとWorkflowsの実行環境そのもの（第5章）
• Durable Objects：同時アクセスの調整役。非同期処理とは役割が異なる（前ページ）
• R2：大きなデータの受け渡し場所として併用する（第6章）
• Email Routing：Email Workersで受けたメールを、キューに流して処理する構成も取れる（第5章）
• Workers AI：時間のかかるAI処理を、Workflowsのステップとして組み込む（第7章）

まとめ

• 非同期処理とは、利用者を待たせずに重い処理を裏で確実に終わらせる考え方
• Queuesは、送る側と受け取る側の間に立って仕事を預かる仕組み。バッチ処理・自動リトライ・デッドレターキューを備える
• Workflowsは、複数のステップからなる処理を管理し、失敗したステップから再開できる（耐久性のある実行）
• Workflowsでは最大365日の待機を挟めるため、日をまたぐ処理もひとつのコードで書ける
• 1回で終わる大量の仕事はQueues、順番に進む長い作業はWorkflowsが向く
• どちらも無料プランから利用でき、Queuesの従量課金はオペレーション単位で計算される

第5章の最後は、Workersの実行環境そのものを拡張するContainersです。JavaScriptでは書けない処理や、既存のソフトウェアをそのまま動かしたい場合の選択肢になります。

次に読む

• Containersとは？Workersを超える実行環境
• Durable Objectsとは？状態を持つWorkers

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。