これはCloudflare上でAI関連プロダクトを運用する記録シリーズの1本である。自社プロダクト「カンタン補助金」は同期処理の一部をCloudflare Workflowsに切り替えた。前回の記事ではWorkerがパスを覆い隠した問題を扱った。今回はWorkflowの実行状態そのものが「無かった」という記録をまとめる。
この記事で分かること
- 完走時だけ記録行を作る設計で何が起きたか
- なぜ小さなデータでの検証では気づけなかったか
- 起動時に行を作りUPDATEする対処法
この記事で分からないこと(正直に書く)
- 二重起動が実際に外部APIへ何回余分なリクエストを送っていたかの正確な回数
- 対処後、さらに長時間のWorkflowでも同じ設計で問題が出ないかの網羅的な検証結果
何をしたか
これまでリクエストを受けてから処理が終わるまで応答を待たせる形で動いていた同期処理を、Workflowを起動して202を返す形に切り替えた(出所: 自社の運用記録、確認日2026-09-06)。Workflow自体は、完走した時点で記録テーブルに1行INSERTするという、それまでの実装をそのまま踏襲した。
何が起きたか
処理件数が少なく数秒で完了する小さなデータで検証したところ、正常に完走し余計な行も残らなかった。しかし実際の処理は数分から十数分かかるため、本番で動かすと3つの問題が出た(出所: 自社の運用記録、確認日2026-09-06)。画面のポーリングは「最新行がrunningでなければ完了」と判定していたため、実行中に見ると前回の完了行を掴み、前回の結果を「完了」として表示した。二重起動を防ぐ「runningなら弾く」判定も、running行自体が存在せず一度も真にならず、同じ処理が重ねて起動できた。E2Eテストの「実行中ならスキップする」条件も、同じ理由で成立しなかった。
なぜ気づけなかったか
検証に使ったデータは起動から完走までがポーリングの間隔よりも短く終わっていたため、実行中の状態を一度も観測しないまま「完走した・行が残らない」という判定を下していた(出所: 自社の運用記録、確認日2026-09-06)。数分から十数分かかる本番相当の処理で確かめて初めて、実行中の状態が欠けていることが表面化した。
どう直したか
起動した時点でrunning状態の行を作り、完走した時点で同じ行をUPDATEする形に直した(出所: 自社の運用記録、確認日2026-09-06)。手動起動は202を返す前に行を作ってからWorkflowへ渡し、起動直後のポーリングでも見つけられるようにした。定期起動はWorkflow最初のステップで行を作る。画面側も「最新行」ではなく、起動時に受け取った行のIDを追跡する形に変えた。途中で失敗した場合は例外を投げ直す前に該当行をfailedへ更新し、想定より長いrunning行は次回起動時に自動でfailedへ切り替えている。対応は2026年9月に完了している。
再発防止
「速く終わる小さなデータで検証し、長く走る本番の状態を見ないまま良しとしてしまった」ことが根本の原因だった。以後、ライフサイクルに関わる検証は、最も時間のかかる経路を選び、実行中の状態を実際に観測してから良否を判定することにしている。Cloudflareの公式ドキュメントでも、Workflowsは複数ステップを束ねて数分から数週間にわたり状態を保持できる仕組みとして説明されており、実行の途中経過を扱う前提の機能であることが示されている(出所: Cloudflare公式ドキュメント「Workflows Overview」、https://developers.cloudflare.com/workflows/、確認日2026-09-06)。
実行中の状態が欠けるという構造は、Workerがパスを覆い隠した記事の「見えているはずの状態が実は見えていない」という点と共通する。本番で小さく起こしてから確かめる考え方はLLMを呼ぶWorkflowの記事でも扱っている。ストレージ・コストの全体像は姉妹記事「コストとストレージの記事」を参照してほしい。
自社プロダクトのCloudflare Workflows設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 完走時に1行INSERTするだけの設計で何が問題だったのか
実行中であることを示す行がどこにも存在しないため、画面のポーリングが前回の完了行を掴んで誤った結果を表示し、二重起動防止も一度も効かなかった。
Q2. なぜ検証で気づけなかったのか
検証に使ったデータは起動から完走までがポーリングの間隔よりも短く終わっていたため、実行中の状態を一度も観測しないまま良しと判定していた。
Q3. どうやって直したのか
起動した時点でrunning状態の行を作り、完走した時点で同じ行をUPDATEする形に変えた。画面側も最新行ではなく、起動時に受け取った行のIDを追跡してポーリングするようにした。
Q4. Cloudflare Workflowsはそもそもどのような仕組みか
Cloudflareの公式ドキュメントによれば、Workflowsは複数のステップを束ねて自動的にリトライしながら、数分から数週間にわたり状態を保持できる仕組みとして提供されている。