Cloudflare 25：Workflows と Cron Triggers ― 最後までやり遂げる、決まった時刻に動かす

Workflows：段ごとに結果を記録しながら進む

Workflows は、何段もある処理を、途中で失敗しても確実に最後まで実行するための仕組みです。こうした仕組みを一般に永続実行（durable execution）と呼びます。2025年に一般提供（GA）になりました。

考え方はシンプルです。処理を段（ステップ）に分けて書きます。1つの段が終わるたびに、その段の結果を Cloudflare が保存します。図の下にある「状態の記録」がそれです。

途中で何かが起きて止まっても、再開するときは記録を見ます。記録がある段は、もう一度実行せず、記録から結果を取り出すだけにします。記録の無い段から、続きを実行します。

Workflow を1回起動したものをインスタンスと呼びます。注文1件ごとに1つのインスタンスを起動する、という使い方をします。

step.do：1段ずつ実行し、結果を保存する

段を書くいちばん基本の道具が step.do() です。

const order = await step.do("注文を確認", async () => {
  const res = await fetch(`https://api.example.com/orders/${event.payload.id}`);
  return await res.json(); // この値が記録される
});

1つめの引数は段の名前、2つめが実際に行う処理です。処理が返した値が、状態の記録に保存されます。次の段では、その値（ここでは order）をふつうの変数として使えます。

段の名前は、記録の目印になります。再開したとき、Workflows は「この名前の段は、もう記録がある」と判断して、処理を実行せずに記録の値を返します。だから、段の名前は毎回同じになるように付けます。日時や乱数を名前に入れてはいけません。

段の中で返す値は、JSON にできる値にします。大きなデータ（画像や大量の行）をそのまま返すと記録の上限に当たるので、R2（22号）や D1（23号）に置いて、段はそのキーだけを返すのが定番です。

段が失敗したら、その段だけをやり直す

段の中の処理が例外を投げると、Workflows はその段だけをやり直します。前の段の処理は、もう一度は実行されません。

await step.do(
  "支払いを確定",
  { retries: { limit: 5, delay: "10 seconds", backoff: "exponential" }, timeout: "5 minutes" },
  async () => {
    await chargePayment(order);
  },
);

retries で、やり直す回数と間隔を決めます。backoff: "exponential" にすると、10秒、20秒、40秒…と、だんだん間隔が長くなります。相手のサービスが混んでいるときに、すぐに何度も叩かないためです。timeout は、1回の挑戦にかけてよい時間です。

回数を使い切っても失敗したら、そのインスタンスは「失敗」の状態で止まります。管理画面や wrangler で、どの段で止まったかを確かめられます。

大事なのは、Worker そのものが落ちても同じだということです。Cloudflare の拠点で障害が起きても、記録は残っているので、別の場所で「2段目の途中」として再開されます。

step.sleep：3日でも、眠って待てる

「3日後にメールを送る」を、Workflows ではそのまま書けます。

await step.sleep("3日待つ", "3 days");

// 決まった日時まで待つこともできる
await step.sleepUntil("発売日まで待つ", new Date("2026-12-01T00:00:00Z"));

眠っている間、コードは動いていません。どこかのサーバーが3日間このインスタンスのために待機しているわけではなく、「3日後に起こす」という記録が残っているだけです。時間が来ると、Workflows が続きから再開します。

これが、ふつうの setTimeout との決定的な違いです。

眠っているインスタンスは、同時に動いているインスタンスの数にも数えられません。何万件もの注文が「3日待ち」の状態で眠っていても、動いている数の上限を圧迫しないということです。

step.waitForEvent：人の承認や外の知らせを待つ

処理の途中で、外からの知らせを待ちたいことがあります。上司の承認、決済サービスからの入金通知、利用者のメール認証などです。これを書くのが step.waitForEvent() です。

const approval = await step.waitForEvent("上司の承認を待つ", {
  type: "approval",
  timeout: "7 days",
});
// approval.payload に、知らせと一緒に送られた中身が入っている

知らせを送る側（たとえば承認ボタンの API を持つ Worker）は、インスタンスの ID でインスタンスを取り出し、イベントを送ります。

const instance = await env.ORDER_FLOW.get(instanceId);
await instance.sendEvent({ type: "approval", payload: { approvedBy: "sato" } });

timeout までに知らせが来なければ、その段は失敗として扱われます。「7日たっても承認されなければ、注文を取り消す」のような処理も書けます。

待っている間は、眠っているときと同じく、コードは動いていません。

コード：WorkflowEntrypoint の run() に段を並べる

Workflow は、WorkflowEntrypoint を継承したクラスとして書きます。run() の中に、段を上から順に並べます。

import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep } from "cloudflare:workers";

type Params = { id: string };

export class OrderFlow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const order = await step.do("注文を確認", async () => loadOrder(this.env, event.payload.id));

    await step.do("支払いを確定", { retries: { limit: 5, delay: "10 seconds" } }, async () => {
      await charge(order);
    });

    await step.sleep("3日待つ", "3 days");

    await step.do("レビュー依頼", async () => {
      await sendReviewMail(order);
    });
  }
}

ふつうの async 関数と同じように書けるのが Workflows の良さです。if で分岐したり、for で回したりもできます。

ひとつだけ強く意識してほしいのは、段の外に副作用を書かないことです。再開するたびに run() は頭から実行され直し、記録のある段は結果を返すだけになります。段の外に書いたメール送信やデータベースの書き込みは、再開のたびに何度も走ります。外に影響する処理は、必ず step.do の中に入れます。

始め方：設定に書き、Worker から create() で起動する

Workflow を使うには、設定ファイルに Workflow を登録します。

{
  "workflows": [
    { "name": "order-flow", "binding": "ORDER_FLOW", "class_name": "OrderFlow" }
  ]
}

class_name はコードのクラス名、binding はコードから呼ぶときの名前です。起動は、ふつうの Worker の fetch() などから行います。

const instance = await env.ORDER_FLOW.create({ params: { id: orderId } });
return Response.json({ instanceId: instance.id });

create() は、インスタンスを起動したらすぐ返ります。Workflow の完了は待ちません。返ってきた ID を保存しておけば、後で状態を確かめたり、イベントを送ったりできます。

管理画面でも、インスタンスごとに「どの段まで進んだか」「どの段で何回失敗したか」が見られます。Workflows は Workers の無料プランでも試せます。

Cron Triggers：決まった時刻に Worker を動かす

ここからは、もう1つの機能 Cron Triggers です。これは、決まった時刻に Worker を動かす仕組みです。

Worker は、ふつうはリクエストが来たときに動きます。でも、「毎晩0時に売上を集計する」「1時間ごとに古いデータを消す」「15分ごとに外のサービスが生きているか確かめる」のように、誰も呼ばなくても、時間になったら動いてほしい仕事があります。

Cron Triggers を設定すると、Cloudflare の時計が決まった時刻に Worker の scheduled() ハンドラを呼びます。

export default {
  async scheduled(controller: ScheduledController, env: Env, ctx: ExecutionContext) {
    if (controller.cron === "0 0 * * *") {
      ctx.waitUntil(aggregateDailySales(env));
    }
    if (controller.cron === "*/15 * * * *") {
      ctx.waitUntil(checkHealth(env));
    }
  },
};

1つの Worker に複数の時刻を設定できます。どの時刻で呼ばれたかは controller.cron で分かります。

Cron Triggers は、Workflows とも相性が良い組み合わせです。重くて何段もある夜間処理は、scheduled() の中で Workflow を create() するだけにして、実際の処理は Workflow に任せます。すると、夜間処理にも段ごとの記録と再挑戦が効くようになります。

書き方：cron 式は UTC。日本時間から9時間引く

時刻は、設定ファイルに cron 式で書きます。

{
  "triggers": {
    "crons": ["0 0 * * *", "*/15 * * * *"]
  }
}

cron 式は、空白で区切った5つの欄でできています。

いちばん大事なのは、時刻が UTC（世界標準時）で解釈されることです。タイムゾーンは指定できません。日本時間は UTC より9時間進んでいるので、日本時間から9時間引いて書きます。

日付や曜日をまたぐときは、曜日の欄もずらす必要があります。最短の間隔は1分ごとです。手元では wrangler dev --test-scheduled で起動すると、決まった URL を叩いて scheduled() を試せます。

料金と制限：Workers と同じ数え方＋記録の保存

Workflows の料金は、基本的に Workers と同じ数え方（リクエストと CPU 時間）に、状態の記録を保存している量が加わります。さらに、2026年に料金の見直しがあり、有料プランでは実行した段の数でも数えられるようになりました。無料プランには込みの量があります。数え方が変わったばかりなので、使う前に最新の料金ページを必ず確かめてください。

Cron Triggers 自体には追加料金はかかりません。呼ばれた Worker の実行が、ふつうの Workers の料金で数えられます。ただし、1つの Worker に設定できる本数や、アカウント全体の本数には上限があり、無料プランでは少なめです。無料プランでは、1回の実行で使える CPU 時間もリクエストのときと同じく短いので、重い集計は Workflow に任せましょう。

※2026年9月時点の情報です。料金・上限は変わるので、公式の Pricing と Limits のページで確かめてください。

よくある落とし穴

Workflows と Cron Triggers でつまずきやすい点です。

段の中の処理は「少なくとも1回」実行されます。支払いのように二重にしたくない処理は、決済サービスの冪等キー（同じキーの依頼は1回しか処理しない仕組み）を使いましょう。

Queues・Workflows・Cron の使い分け

「後でやる仕事」を扱う機能が3つそろいました。役割は次のように分かれます。

3つは組み合わせて使うことが多いです。たとえば、Cron Triggers が毎晩0時に Workflow を起動し、Workflow の1段目で集計対象を洗い出し、2段目でたくさんの小さな仕事を Queues に入れる、という形です。

ほかの号とのつながりも見ておきます。段の結果の置き場には D1（23号）や R2（22号）、1つの対象の状態を順番に更新したいなら Durable Objects（21号）、コマンドでのデプロイや状態の確認は Wrangler（34号）、失敗の見張りには分析とログ（32号）を使います。Workflows は、内部では Durable Objects の上に作られています。