Cloudflare Workflows の既定保持期間が30日から7日へ — 対象は 2026-09-10 以降に作る新規 Workflow だけ

要約

Cloudflare は 2026-09-10 以降に Workers Paid プランで作成される Workflows について、完了・エラー状態のインスタンスの既定保持期間を30日から7日へ短縮しました。公式が挙げる理由は既定のストレージコスト削減です。

この変更には、境界が2つあります。両方を正確に把握しないと、想定と違う挙動になります。

1つ目は作成日です。 対象は 2026-09-10 以降に作成される Workflow だけで、既存の Workflow の保持期間は変更されません。 昨日まで作ったものは30日のままです。

2つ目はプランです。 Workers Free は従来どおり既定・上限ともに3日で、変更ありません。

そして、上限は変わっていません。 最大保持期間は30日のままです。つまり、短くなったのは「何も指定しなかったときの値」だけで、明示的に指定すれば従来どおり30日まで伸ばせます。

指定は create() の retention で行います。successRetention と errorRetention を別々に設定できるのが実用上の要点です。

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

成功と失敗で保持期間を分けられるという点が効きます。成功したインスタンスの記録は、後から見返す機会がほとんどありません。一方、失敗したインスタンスは調査のために必要です。 上の例のように「成功は2日、失敗は30日」と組めば、調査に必要な情報を残しながらストレージコストを抑えられます。

Cloudflare ダッシュボードからは、Workflow 単位・インスタンス単位でも設定できます。

何が変わったか

• 2026-09-10 以降に Workers Paid で作成する新規 Workflow の既定保持期間が 30日 → 7日
• 既存の Workflow は変更なし（30日のまま）
• Workers Free は3日のまま（既定・上限とも変更なし）
• 最大保持期間は30日のまま。明示指定すれば伸ばせる
• successRetention / errorRetention で成功・失敗を分けて指定できる
• ダッシュボードから Workflow 単位・インスタンス単位でも設定可能

業務インパクト（一般企業向け）

この変更の怖さは、「動かなくなる」ではなく「静かに情報が消える」ことにあります。

保持期間が短くなっても、Workflow は普通に動きます。エラーも出ません。気づくのは、障害が起きて「先月も同じことがあったはずだ」と調べに行ったときです。 そのときには、もう記録がありません。変更から1か月後に、初めて影響が分かる種類の変更です。

そして、今回の変更は「これから作るもの」にだけ効きます。 ここに落とし穴があります。既存システムを運用している人は、自分には関係ないと判断しがちです。 ところが、新しいバッチを追加したとき、新しい環境を構築したとき、Workflow を作り直したときに、静かに7日の世界へ入ります。「既存は変わらない」は「今後も変わらない」ではありません。

やるべきことは1つです。既定に任せるのをやめ、明示的に指定してください。

具体的には、errorRetention を業務の調査サイクルに合わせて指定することです。月次で振り返る運用なら30日、週次なら14日程度。成功インスタンスは短くてかまいません。 「成功は2日、失敗は30日」という組み方は、多くの現場でそのまま使える出発点です。

コスト面からの見方も添えておきます。 Cloudflare がこの変更を入れた理由は既定のストレージコスト削減です。裏を返せば、**これまで多くの利用者が「使わない成功インスタンスの記録を30日持ち続けて課金されていた」**ということです。成功と失敗を分けて指定する運用へ切り替えると、コストは下がり、調査可能期間は延びます。 既定値の変更に受け身で対応するのではなく、この機会に設計として決めてしまうのが得です。

新規に Workflow を作るときの手順に、保持期間の指定を組み込んでください。 テンプレートやスキャフォールドに最初から書いておけば、指定漏れは起きません。「毎回忘れずに指定する」という人の運用に頼ると、いつか抜けます。

副業・個人活用視点

個人で Cloudflare Workers / Workflows を使っている場合、この変更は素直に「調査できる期間が短くなる」という形で効きます。

一人で運用していると、エラーに気づくのが遅れます。 業務時間外に動くバッチが失敗していて、気づくのは数日後の定例作業のとき、ということは普通に起きます。7日という既定は、「週末を挟んで気づく」までは持つが、「月次作業のときに気づく」には足りない長さです。

最初にやるべきことは、失敗時の保持期間を伸ばすことです。 成功インスタンスは短くてよいので、errorRetention だけ長めに取っておけば、コストはほとんど増えません。個人利用の規模なら、失敗インスタンスを30日持っても大した金額にはなりません。

受託で顧客の Workflow を作っている場合は、これは引き継ぎ資料に書くべき項目です。

納品後に運用するのは顧客です。保持期間を指定していない状態で納品すると、顧客が障害調査をしようとしたときに記録が無いという事態になります。しかも、その時点で作ったのは自分です。「なぜ短いのか」を説明する立場になります。

納品時に明示指定しておき、その値と理由を引き継ぎ資料に1行書く。 これだけで防げます。逆に、この種の運用面の配慮ができているかどうかは、継続発注の判断に効きます。 動くものを作れる人は多くても、運用開始後に困らない形で渡せる人は多くありません。

既存案件の扱いにも触れておきます。 過去に納品した Workflow は30日のままなので、緊急の対応は不要です。ただし、その顧客に新しい Workflow を追加するときには7日が既定になります。 同じ環境の中で保持期間が違う Workflow が混在することになるので、追加時には必ず明示指定して揃えてください。混在は、後から調査するときに最も混乱する状態です。