Cloudflare Workflowsの保存期間が7日に短縮：実行履歴とコストの設計法

Cloudflare Workflowsで変わったのは既定値、上限ではありません

Cloudflare Workflowは、複数のステップで構成される永続的なジョブです。プラットフォームは、待機や再試行の後もジョブを再開できるだけの状態を保存し、完了またはエラー終了した後も一定の保存期間にわたってインスタンスを保持します。

そのインスタンスは、運用上の証跡になります。CloudflareのインスタンスAPIから取得できるのは、ステータス、パラメーター、出力、各ステップの詳細、試行履歴、実行時間、エラーです。過去の支払い照合、顧客データのインポート、公開処理などが失敗したとき、何が起きたのかをたどる手掛かりになります。

9月の変更が適用される範囲は、次の3点です。

• 9月10日以降に作成したWorkers PaidのWorkflowでは、完了またはエラーになったインスタンス状態の既定の保存期間が7日になります。
• 既存のWorkflowでは、現在の保存動作が維持されます。Cloudflareが過去に作成されたWorkflowの期間をさかのぼって短縮したわけではありません。
• Workers Freeは3日のままで、既定値と上限のどちらも変わりません。

Paidでは引き続き、状態を最長30日間保存できます。Cloudflareが引き下げたのは既定値であり、上限ではありません。

この違いを押さえると、ドキュメント間の食い違いも整理できます。料金ページは7月21日が最終更新日で、Paidの既定値を今も30日としています。Workers APIリファレンスは8月12日に更新され、保存期間の指定を省略するとアカウントの上限が使われると説明しています。どちらも9月10日の変更履歴より前の内容です。

優先すべきなのは、より新しく対象が明確なルールです。新規のPaid Workflowは既定で7日、既存のPaid Workflowは変更なし、Paidの上限は引き続き30日です。

7日間はインシデントを発見する期限になります

問うべきなのは、7日間が短く感じるかどうかではありません。重要な障害を7日目までにチームが把握できるかどうかです。

支払いや注文のジョブを運用するバックエンド責任者が不一致を知るのは、サポート部門や財務部門が記録を照合したときかもしれません。その時点でインスタンスが保存期間を過ぎていれば、外部の取引記録は残っていても、実行経路を説明するWorkflowのステップ試行、エラー詳細、出力は失われている可能性があります。

SREには別の落とし穴があります。CloudflareではWorkflowのメトリクスを31日間照会できますが、この分析期間と詳細なインスタンス状態の保存期間は同じではありません。メトリクスから障害イベントの発生は確認できます。しかし、古いインスタンスのパラメーター、出力、試行履歴、エラーが今も参照できる証拠にはなりません。

これはAIエージェントの障害分析ツールにも通じる運用原則です。証跡の保存期間は、障害が発生してから、それが重要だと誰かが気づくまでの遅れに合わせる必要があります。

制作会社の技術責任者にとっては、設定の不統一がリスクになります。変更前から長期間稼働している顧客向けWorkflowは従来の期間を維持する一方、変更後に作り直したWorkflowは黙って7日になる可能性があります。コード上の処理経路が同じに見えても、顧客向けのランブックが誤っていることはあり得ます。

成功履歴は短く、重要なエラー履歴は長く

Cloudflareが2つの設定項目を用意しているのには理由があります。

• successRetentionは、正常終了後に状態を残す期間です。
• errorRetentionは、エラーまたは強制終了後に状態を残す期間です。

成功した処理では、永続的な業務結果が別の場所に残ることがよくあります。注文レコード、オブジェクトキー、送信済みメッセージのID、完了済みインポートの記録などです。外部システムが正本であれば、成功履歴は、直後のサポート対応や再実行の確認に必要な短い期間だけでも足りる場合があります。

エラー終了した処理は事情が異なります。価値があるのは、完了しなかった経路そのものであることが多いからです。調査担当者が必要とするのは、失敗したステップ、それ以前の試行、入力パラメーター、中間出力かもしれません。障害の発覚が遅れる可能性があるなら、すべての成功履歴を同じ期間残すより、エラー履歴だけを長く保持する方が合理的です。

公式の変更例でも、両者を明確に分けています。

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

これは設定例であり、すべての環境に当てはまる推奨値ではありません。エラーの保存期間は、現実に起こり得る最長の発見・調査遅延を基準に決めます。成功の保存期間は、実際の結果が正本となるシステムに記録された後、運用担当者がWorkflowの記録をどれだけの間必要とするかで決めてください。

ストレージ料金の計算ではアクティブ状態を分ける必要があります

CloudflareはWorkflowのストレージをGB-month単位で課金します。Workers Paidでは最初の1 GB-monthが含まれ、超過分は1 GB-monthあたり$0.20です。Cloudflareは、30日間の請求期間について日ごとのピークストレージを平均して使用量を算出します。

ストレージの合計には、実行中、スリープ中、エラー終了、完了済みの各インスタンスが含まれます。終了後の保存期間を短くすれば完了済み状態のストレージは減らせますが、実行中またはスリープ中のジョブの状態まで消えるわけではありません。

現行の料金ページでは、Workflowsのステップとストレージへの課金は2026年8月10日から適用されるとしています。7月の古い課金告知が示していたのは、その日より前には課金を始めないという約束だけでした。現行ページにより公表上の開始日は確定しますが、個々のアカウントの次回請求書に何が記載されるかまで保証するものではありません。

以下は明示的な仮定に基づくモデルです。Cloudflareのベンチマークでも、削減額の保証でもありません。

一定の処理量のもと、成功した処理によって新たに保存される状態が毎日1 GB増えると仮定します。アクティブ、実行中、スリープ中のインスタンスは、どちらのシナリオでもさらに0.5 GB-monthを占めます。成功時の保存期間だけの影響を見るため、エラー状態のストレージは比較から除外します。errorRetentionを30日のままにする場合は、その状態を計測し、同じエラー履歴の行を両方に加えてください。

モデル上の差額は$4.60です。だからこそ、前提を明記する必要があります。ステップ出力が小さいチームでは、ほとんど節約にならないかもしれません。大量の処理を実行し、大きな結果を保存するWorkflowでは、成功履歴の保存量がはるかに大きくなる可能性があります。新しい既定値が変えるのは乗数であり、実際の請求額を決めるのは状態のサイズと完了頻度です。

押さえておくべき限界

Paidの上限は今も30日です。顧客、規制当局、月次照合によって、その期間を過ぎてから問題が発覚し得るなら、Workflowsのインスタンス状態だけをアーカイブにしてはいけません。必要最小限の証跡を、独自の保存・アクセス方針を持つシステムへ書き出してください。

エラーの保存期間を延ばせば、保存されるエラー状態も増えます。適切な方針は「エラーを永久保存する」ことではありません。インシデントの発見と再現に十分な期間を確保した後、インスタンスID、Workflowのバージョン、タイムスタンプ、ステータス、機密情報を除いたエラー、影響を受けた業務オブジェクトといった簡潔で永続的な記録を残すことです。

成功時の保存期間を短くするにも前提があります。正常終了の結果が、すでに信頼できる場所に存在していなければなりません。処理が行われたことを示す唯一の記録がWorkflowの出力なら、それを早く削除するほどストレージだけでなく証跡も減ります。

さらに、インスタンス単位の上書きはポリシーを分断しかねません。複数の作成経路を持つ制作会社では、ダッシュボードの既定値が正しくても、一部の呼び出し元だけが別の期間を要求することがあります。保存期間はダッシュボードの設定だけでなく、コードレビュー、ランブック、コストモデルにも組み込むべきです。

今すぐ取るべき対応

9月10日以降にPaid Workflowを作成した場合、障害が担当者に届くまで7日を超える可能性がある場合、または完了済み状態がストレージ使用量の目立つ部分を占める場合は、今週中に対応してください。成功時とエラー時の保存期間を分けて設定します。

Workflowがまだ処理量の少ない試験運用で、保存状態がプランに含まれる1 GB-monthに収まっているなら、コスト最適化は急がなくても構いません。ただし、超過料金がゼロでも調査可能な期間は重要なので、ポリシー自体は明示してください。

9月10日より前から存在するWorkflowは、この既定値変更の影響を受けません。Workers Freeも既定値・上限ともに3日のままです。ただし、プラットフォームの保存期間を超えて業務上の調査が必要なら、どちらの場合も外部記録は欠かせません。

月曜日に、新しいWorkflowを作成するすべての経路を監査してください。successRetentionとerrorRetentionを明示し、安全な障害を発生させて、詳細な状態を確認できる最終日を確かめます。実際のインシデントで試される前に、その日付をランブックへ記載してください。

実務に役立つ次のプラットフォーム変更をニュースレターで受け取る。