Cloudflare Queues: エッジでのバックグラウンド処理

Cloudflare Queues は、サーバーレスアプリケーションが遅かれ早かれ必ず突き当たる問題を解決します。すなわち、ユーザーを待たせるべきではない処理を引き起こすリクエストが届く、という問題です。確認メールの送信、アップロードされた画像のリサイズ、レコードを外部サービスへ同期する処理。従来型のサーバーであれば、そうした仕事はバックグラウンドのワーカープロセスに渡せば済みます。ところが Workers には、渡す相手となるプロセスそのものが存在しません。

よく使われる回避策は、見た目よりもたちが悪いものばかりです。処理をリクエストの中でそのまま実行すれば、ユーザーはメール配信事業者の応答を待たされることになります。別の Worker にリクエストを投げっぱなしにして待たない方式は、呼び出し元の実行が先に終わった瞬間にジョブを失います。どちらの方法も、外部プロバイダーの障害を乗り切ることはできません。

キューが与えてくれるもの: 速度ではなく、耐久性と再試行です。プロデューサーはメッセージを書き込んだ時点ですぐに戻り、別のコンシューマー Worker がそれを受け取ります。コンシューマーが失敗した場合でも、メッセージは闇に消えるのではなくキューへ戻されます。価値はそれがすべてです。もしバックグラウンドの処理が再実行に耐えられない性質のものであれば、キューを入れても救われません。

各パーツはどう噛み合うのか

キューには両端があり、その両方が Workers です。

プロデューサーは、キューのバインディングを持つ任意の Worker です。メッセージ本文を添えて send を呼び出すと、その呼び出しはメッセージが永続的に保存された時点で戻ります。ユーザーのリクエストは、実際の処理の完了を待つことなく終了します。

コンシューマーは、キューハンドラーを持つ Worker です。Cloudflare はメッセージのバッチを渡してこれを呼び出し、ハンドラーは正常に処理できたメッセージを一件ずつ確認応答します。確認応答されなかったものは、すべて再配信されます。

設計上いちばん意識すべきなのは、この再配信の挙動です。メッセージは二回以上届くことがあり、つまりコンシューマーは冪等でなければなりません。冪等キーを持たないまま、キューのコンシューマーの中でカードに課金する実装は、いずれ返金作業を生みます。メールが二通届くのは煩わしいだけですが、二重に決済されるのは立派なサポート案件です。

デッドレターキューは、繰り返し失敗するメッセージを受け止める場所です。これがないと、恒久的に壊れたメッセージは試行回数を使い切るまで再試行され、そのあと跡形もなく消えてしまいます。用意しておけば、あとから中身を確認できる場所に落ちてくれます。必要になってから慌てるのではなく、必要になる前に設定してください。

オペレーション一件の本当のコスト

料金モデルは人を戸惑わせるほど独特です。というのも、課金の単位がメッセージの件数ではないからです。

オペレーションは書き込み、読み取り、削除されたデータ 64 KB ごとに一件として数えられます 。64 KB 未満のメッセージが問題なく配信された場合、書き込み一回、読み取り一回、削除一回で合計三オペレーションになります。127 KB のメッセージなら各アクションが二オペレーションずつになるため、同じ一回の配信でも合計六オペレーションかかります。

再試行は計算を変えます。再配信のたびに読み取りが一件増え、デッドレターキューへの書き込みも書き込み一件として加算されます。あるメッセージで五回失敗してから成功するコンシューマーは、三オペレーションどころでは済みません。再試行回数を引き上げるのではなく、不安定なコンシューマーそのものを直すべき理由がここにあります。

安いと決めつける前に、自分たちのトラフィックで計算してみてください。月間100万メッセージで一件あたり三オペレーションなら300万オペレーションとなり、有料プランに含まれる枠を超えて、およそ80ペンスの請求になります。これは確かに安いといえる水準です。しかし1日あたり1000万メッセージとなると、まったく別の話になります。

適合するかどうかを決める上限値

Cloudflare の Queues の制限に関するドキュメント より、2026年8月時点で確認した値です。

このうち二つが、ほかよりもはるかに重要です。メッセージあたり 128 KB という上限は、ファイルそのものをキューに載せないという設計を意味します。キューにはポインタだけを置き、実体は R2 に置く。どのみちそれが正しい形です。25 GB のバックログは、静かに進行する大事故からあなたを守ってくれる仕組みです。金曜日にコンシューマーが壊れて誰も気づかなかった場合、キューは満杯になり、新しいメッセージをストレージエラーで拒否します。黙って捨てられるより、はるかにましな挙動です。

1秒あたり 5,000 メッセージというスループットは十分に大きい数字ですが、あくまでキュー単位の値です。一本のキューに負荷が集中すればそこがボトルネックになりますが、複数のキューへシャーディングする設計にしておけば、先回りして避けられます。

Cloudflare Queues が答えにならない場面

処理が本当に同期的である場合。 ユーザーが画面上で結果を必要としているなら、キューに載せても往復が一つ増え、ポーリングの問題が加わるだけです。その場で実行し、速くすることに集中してください。

順序保証と厳密に一度きりの処理が必要な場合。 Queues が提供するのは最低一回の配信です。厳密な順序や exactly-once のセマンティクスを求めるなら、キューが提供しない調整の仕組みが必要になり、Cloudflare 上ではたいてい Durable Object がその役割を担います。

トリガー起動ではなく、スケジュール実行のジョブである場合。 夜間のクリーンアップにキューは要りません。Worker を直接呼び出す cron トリガーのほうが単純で、可動部品も少なくて済みます。

処理が 15 分を超える場合。 実行時間の上限を超えたコンシューマーは、ジョブの途中で強制終了されます。複数ステップにまたがる長い処理に必要なのは、ステップをまたいだ永続的な実行のために作られた Cloudflare Workflows であって、15 分ものあいだ状態を抱え込もうとするキューのコンシューマーではありません。

Cloudflare Workers でサーバーレス API を構築する方法 を扱った記事では、こうしたジョブを生み出すリクエスト経路そのものを解説しています。またCloudflare Workers と AWS Lambda の比較 では、多くのチームが前提として持ち込む SQS と Lambda の組み合わせに対して、実行モデルがどう違うのかを説明しています。

どこから始めるか

リクエストハンドラーの中から、ユーザーが待つ必要のない処理を一つだけ選び、それだけを外へ出してください。初日からデッドレターキューを用意し、コンシューマーを冪等にし、バックログのメトリクスは空だと思い込まずに実際に監視してください。

Mecanik はソフトウェア開発 チームを通じて、エッジアーキテクチャの設計とレビューを行っています。そこには、そのジョブに本当にキューが必要なのかを誰かが問い直す工程も含まれます。たいていのシステムに必要なキューは一本か二本であって、機能ごとに一本ではありません。

関連記事: Cloudflare Hyperdrive - エッジから Postgres に接続する 、2026年にウェブアプリを構築する方法 - 英国開発者ガイド 、Cloudflare D1 - エッジでサーバーレスSQLデータベースを構築する 、Cloudflare Workers AI - 2026年にエッジでAIモデルを実行する 。

よくある質問

Cloudflare Queues の料金はいくらですか？ Workers Free プランには1日あたり 10,000 オペレーションが含まれ、Paid プランには1か月あたり100万オペレーションが含まれます。超過分は100万オペレーションあたり 0.40ドルで、下り転送量の料金はかかりません。オペレーションは書き込み、読み取り、削除されたデータ 64 KB ごとに一件として数えられるため、64 KB 未満の通常のメッセージは書き込み一回、読み取り一回、削除一回の合計三オペレーションで済みます。

Cloudflare Queues では何がオペレーションとして数えられますか？ 書き込み、読み取り、削除されたデータ 64 KB ごとに一件です。64 KB 未満のメッセージは各アクションにつき一オペレーション、127 KB のメッセージは各アクションにつき二オペレーションかかります。再試行のたびに読み取りが一件増え、デッドレターキューへの書き込みでさらに書き込みが一件増えるため、不安定なコンシューマーはメッセージあたり三オペレーションという基本値をはるかに超えるコストになります。

Cloudflare Queues のメッセージ最大サイズはどれくらいですか？ メッセージあたり 128 KB で、バッチ送信は 100 件または合計 256 KB までに制限されています。この上限があるため、実データは R2 などのオブジェクトストレージに置き、キューにはポインタだけを載せます。これは上限の有無にかかわらず、そもそも優れた設計です。

Cloudflare Queues は exactly-once の配信を保証しますか？ いいえ。配信は最低一回であり、メッセージが二回以上届くことがあるため、コンシューマーは冪等でなければなりません。冪等キーなしでコンシューマー内から決済を行ったり与信を発行したりすれば、いずれ必ず二重処理が起きます。厳密な順序や exactly-once のセマンティクスが必要な場合は、代わりに Durable Object を使ってください。

Cloudflare Queues を使うべきでないのはどんなときですか？ ユーザーが結果を待っているとき、厳密な順序や exactly-once の処理が必要なとき、ジョブがトリガー起動ではなくスケジュール実行で cron トリガーがあれば足りるとき、あるいは処理がコンシューマーの 15 分という実行時間上限を超えるときです。最後のケースのためにこそ Cloudflare Workflows が存在します。