AIエージェントが一度回答して終わるなら、通常のHTTPリクエストでも動かせます。しかし、複数の文書を処理し、外部APIを呼び、人の確認を待ってから次の操作へ進む仕事では、画面を閉じた、ネットワークが切れた、実行基盤が再起動しただけで「どこまで終わったか」が曖昧になりがちです。
必要なのは、プロセスを長く生かし続けることではありません。途中で止まっても、完了済みの工程、次に待つイベント、再実行してよい境界を復元できることです。Cloudflare Workflowsは、複数ステップの状態を保持し、失敗したタスクの再試行や外部イベント・承認待ちを扱う用途を公式に示しています。Temporalも、クラッシュ、ネットワーク失敗、複数日にわたる人の承認待ちの後にAIワークフローを再開する設計を案内しています。
Queue、Durable Object、ワークフローは同じものではない
非同期化には、目的別に異なる部品があります。まず、Cloudflare QueuesでAIジョブを非同期化するで扱ったQueueは、重い仕事をリクエストから切り離して配送するのに向きます。Durable ObjectsでAIエージェントの同時実行を制御するで扱ったDurable Objectは、同じ利用者・案件・会話に対する更新を直列化するのに向きます。
対してワークフローが担当するのは、「抽出→モデル呼出し→人の承認→外部システム更新」のような、途中状態を持つ業務の進行です。Queueを読んだだけでは、承認待ちの案件をどの状態で保つかは決まりません。Durable Objectで同時実行を抑えても、数日後に来た承認イベントをどの工程へ戻すかは別の設計です。三つを同じ製品の代替候補として比較せず、配送、競合制御、業務進行を分けます。
残すべきは「会話」ではなく業務の状態
ワークフローごとに固有の実行IDを持ち、入力の版、完了したステップ、承認待ちか否か、外部操作の結果を結びます。モデルの自由文を丸ごと状態の正本にするのではなく、次に必要な構造化データを残します。例えば、承認待ちなら「対象、操作種別、入力版、承認期限、承認済みか」を保存し、承認そのものはその版に対してだけ有効にします。
Cloudflare Workflowsでは、ステップは個別に再試行可能です。そこで、検索、LLM呼出し、顧客データ更新、通知送信を一つのステップに混ぜないことが重要になります。前の三つが成功して最後の通知だけが失敗した場合、まとめて再試行すると、検索や更新まで重複し得るからです。処理単位を小さくし、何を再開するかを人が説明できる粒度にします。
再試行は「二度実行しない」保証ではない
ここが最も誤解されやすい点です。実行基盤が再試行できても、外部APIが受け取った更新・メール送信・支払いまで自動的に一回だけになるわけではありません。Cloudflareの設計ガイドも、再試行されるステップから呼ぶAPIやBindingは冪等にするよう求めています。
外部効果を起こすステップには、操作IDを渡し、受け手側で同じ操作を処理済みか照会できる形を優先します。照会できない相手なら、実行前後の記録、手動確認への切替、そもそも自動化の対象から外す判断が必要です。「失敗したらもう一度送る」は、顧客連絡や権限変更には安全な復旧手順ではありません。
人の承認はイベントとして戻す
高影響の操作は、画面を開き続けて待つのではなく、承認要求を作成してワークフローを待機状態にします。承認が届いたら、対象・入力版・期限・承認者を検証して次のステップへ進みます。不一致や期限切れなら停止し、再承認を要求します。承認の対象固定とfail-closeの考え方は、AIエージェントの承認ゲート設計も参照してください。
ただし、durable executionは無制限の状態保存を意味しません。Cloudflare WorkflowsにはステップのCPU時間、保存状態、実行数、完了済みインスタンスの保持期間などの制約があります。大きな成果物をステップの戻り値に抱え込まず、外部ストレージに置いた参照を状態として残す設計が必要です。
導入前の確認項目
- 一つの実行IDで、入力版・ステップ・承認・外部効果を追跡できるか
- 再試行されても安全な処理と、人の確認が必要な処理を分けたか
- 外部更新に冪等キーまたは処理済み照会を用意したか
- 承認の対象、期限、承認者を実行直前に再検証するか
- 単発で同期的な処理まで、運用負荷のあるワークフローへ載せていないか
TechWorkerでは、内製AIツールの業務フローを、Queue・状態管理・承認・復旧まで含めて設計します。エージェントに任せる仕事を増やす前に、「止まったときにどこから安全に戻れるか」を一緒に明確にします。
限界と確認範囲
ワークフローは、単発の要約や即時応答に必須ではありません。また、再試行・状態保持だけで外部効果の重複、誤った認可、誤ったモデル出力を防げるわけではありません。特に送信・削除・支払い・権限変更では、冪等性、認可、承認、監査を別々に設計してください。製品の制限や料金は更新されるため、導入時は公式ドキュメントを再確認します。
一次情報と確認範囲
確認日：2026年9月10日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。