Cloudflare Workflows 2026実践設計：GA後アップデートを前提に、AI自動化を「止まっても戻れる」運用へ

Cloudflare WorkflowsがGAしてしばらく経ち、「便利そうだけど、結局どこまで本番で使えるの？」という問いに対する材料が増えてきました。2026年に入ってからも、ステップ上限の拡張やWorkflow可視化など、運用寄りの改善が続いています。

私の結論を先に書くと、Workflowsは“成功パスの自動化”より、“失敗しても再開できる自動化”に向いているです。ここを勘違いすると、「ただの非同期ジョブキューを高級にしただけでは？」となりがちですが、逆にここを押さえると、AI連携を含む個人開発の運用がかなり楽になります。

この記事では、2026年時点の公開情報を元に、WorkflowsをAI自動化へ組み込む現実的な設計をまとめます。やや冗談を混ぜますが、内容は真面目にいきます。サーバーは寝ていいですが、設計思想は寝かせない方針です。

なぜ今、Workflowsを見直すべきか

GA時点のCloudflare公式ブログでは、Workflowsを「durable execution（耐久実行）」として位置づけています。step.do / step.sleep / step.waitForEvent という最小APIで、ステップごとに状態を永続化しながら再試行できるのが核です。

ここでいう durable execution は、ざっくり言えば「処理が転んでも、最初からやり直し地獄にならない」モデルです。※ durable execution: 実行状態を保持し、障害後も中断点から再開できる実行モデル。

この特性が効くのは、特に次のような処理です。

外部APIをまたぐ多段処理（LLM呼び出し、保存、通知など）
人手承認を含むワークフロー（公開前レビューなど）
時間をまたぐ処理（数時間〜数日後の続行）

逆に「単発で終わる軽処理」を全部Workflowsに載せると、設計が重くなって逆効果です。ハンマーを買った日に家中のネジを叩き始めるのはやめましょう。ネジはドライバーです。

2026年アップデートで変わった現実ライン

2026年の情報として大きいのは、次の2点です。

Paidプランで1インスタンスあたりのステップ上限が、デフォルト10,000 / 最大25,000へ拡張
ダッシュボード上でWorkflow図を自動生成する可視化（beta）

ステップ上限の拡張は、単に「長く回せる」だけでなく、分割設計の自由度を上げます。以前はステップ数節約のために、不自然に処理を詰め込む場面がありました。今は「失敗境界ごとに素直に分ける」方向へ寄せやすくなります。

可視化は見た目のおしゃれ機能ではなく、運用者への説明コスト削減が本体です。個人開発でも、未来の自分はほぼ他人です。3週間後の自分に「この分岐どうなってた？」と詰められる前に、図で逃げ道を作っておくのは有効です。

また、公式のlimits情報では、待機中インスタンス（sleep / retry待ち / event待ち）は同時実行枠を消費しない点が明示されています。ここは設計上かなり重要です。※ concurrency: 同時に実行される処理数の上限。

AI自動化で効く設計原則（失敗前提）

AI連携では、モデル側・ネットワーク側・入力データ側の3方向から不確実性が来ます。よって、次の原則で設計するのが安全です。

1) ステップは「副作用単位」で分割する

step.do を「機能単位」で切るより、副作用の再実行可否で切る方が事故が減ります。

LLM呼び出し（再試行可）
D1書き込み（冪等キー必須）
外部通知（重複送信対策必須）

※ 冪等（idempotent）: 同じ処理を複数回実行しても結果が壊れない性質。

2) リトライはデフォルト任せにしすぎない

公式ドキュメントでは、デフォルトで retry limit 5 / delay 10秒 / exponential backoff / timeout 10分が示されています。これは便利ですが、APIごとに失敗の性質が違うため、StepConfigで明示する方が運用しやすいです。

3) 終端エラーはNonRetryableErrorで即終了

認証失敗や入力不備など、再試行しても直らない失敗は NonRetryableError で止めるのが定石です。無限に根性で殴る運用は、精神衛生にも請求にも悪いです。

実装サンプル：AI記事下書きパイプライン

以下は「入力収集 → 下書き生成 → 人間承認 → 公開」の最小構成例です（動作未検証のサンプル）。

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

type Params = {
  draftId: string;
  topic: string;
};

export class DraftWorkflow extends WorkflowEntrypoint<Env, Params> {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const input = await step.do("validate-input", async () => {
      if (!event.payload.topic || event.payload.topic.length < 5) {
        throw new NonRetryableError("topic is too short");
      }
      return event.payload;
    });

    const draft = await step.do(
      "generate-draft",
      {
        retries: { limit: 4, delay: "15 seconds", backoff: "exponential" },
        timeout: "5 minutes"
      },
      async () => {
        // ここでLLM APIを呼び出す想定
        const text = `下書き: ${input.topic}`;
        return { text, version: 1 };
      }
    );

    await step.do("save-draft", async () => {
      // D1/R2に保存。draftIdをユニークキーにして冪等化する
      return { ok: true, draftId: input.draftId, version: draft.version };
    });

    await step.waitForEvent("wait-approval", {
      type: "draft-approved",
      timeout: "24 hours"
    });

    await step.do("publish", async () => {
      // 承認済みデータを公開
      return { published: true };
    });
  }
}

ポイントは、生成と公開を同一トランザクション感覚で扱わないことです。AI出力は揺れるので、いったん保存して承認待ちへ落とし、公開は別ステップで確定させる方が安全です。

waitForEventで「人間の最終責任」を組み込む

公式の waitForEvent サンプル（画像タグ付け）では、R2アップロード後にD1へ記録し、承認イベントを待ってからWorkers AIで処理を続行する流れが示されています。これ、地味ですがかなり強いです。

個人開発でも、次のような場面で効きます。

自動投稿前の最終確認
高額処理（APIコスト高）の実行承認
公開範囲が広い更新の二重チェック

「全部自動化したい」という気持ちはわかります。私もあります。ですが、誤投稿1回で失う信用は、だいたい自動化で節約した時間より高いです。ここだけはロマンより現実が勝ちます。

運用チェックリスト（これだけは先に）

本番投入前に、最低限ここだけは決めておくのをおすすめします。

冪等キー方針: workflow_instance_id + step_name などで重複実行対策
失敗分類: Retryable / NonRetryable をコードで分離
タイムアウト設計: APIごとに timeout を明示
待機戦略: sleep と waitForEvent の使い分け
保存先戦略: 大きな成果物はR2、Workflow stateは参照情報中心
観測性: 実行IDでログ・メトリクス・通知を突合できる形にする

特に保存先戦略は重要です。公式limitsでも、インスタンスごとの永続状態上限があります。何でもかんでもWorkflow stateに積むと、後で「象を冷蔵庫に入れようとして扉が閉まらない」状態になります。象はR2へ。

まとめ：Workflowsは「止まらない」より「戻れる」が本質

2026年のアップデートを踏まえると、Cloudflare Workflowsは「長い処理を回せるか」だけでなく、設計を運用可能にするための部品が揃ってきたと見ています。

ステップ上限拡張で分割設計しやすい
可視化で保守・説明コストが下がる
waitForEventで人間承認を自然に挿せる
retry / timeout / NonRetryableErrorで失敗を制御できる

個人開発のAI自動化は、最終的に「何を自動化したか」より「壊れたときにどう復旧できるか」で評価されます。派手なデモより、翌朝ちゃんと再開できる仕組みの方が、長期的にはずっと強いです。

明日から試すなら、まず1本だけでいいので、既存の非同期処理をWorkflow化してみてください。最初の目標は“賢いAI”ではなく“再実行しても壊れない処理”です。地味ですが、ここを超えると自動化が急に実用品になります。