多くの自動化フローは、最初は単純だ。フォームを受け取り、タスクを作り、確認メールを送り、スプレッドシートを更新し、チームに通知する。最初に成功したときは、時間を節約できたように感じる。
本当に厄介なのは、十回目、百回目、あるいは外部サービスがたまたま失敗した日に起きる。
たとえば、フローがすでに顧客データを作成し、通知メールも送ったあと、最後の支払いステータス更新で失敗したとする。このとき「もう一度走らせる」だけでは足りない。再実行すると、二通目のメールを送ったり、二つ目のレコードを作ったり、半端な状態をさらに分かりにくくしたりするかもしれない。
Cloudflare は 2026-06-25 に、Workflows の saga-style rollbacks を紹介した。Workflows は複数手順の長めのアプリケーションフローを実行するための Cloudflare の仕組みで、saga-style rollback は各 step.do() に対応する補償動作を書けるようにするものだ。平たく言えば、「この手順で何をするか」だけでなく、「後の手順が失敗したら、この手順をどう補うか」も書いておくということだ。
このミニ講座で持ち帰るべきことは、Cloudflare の使い方そのものではない。大事なのは、多段階の自動化は再試行できるだけでは安全ではなく、失敗後にどう片付けるかも必要だという通用する考え方だ。
まず、再試行と復旧を分ける
「再試行」は同じことをもう一度することだ。たとえば API が一時的につながらないとき、数秒後にもう一度送る。
「ロールバック／復旧」は、すでに起きた影響を処理することだ。予約を取り消す、注文を人間確認に回す、訂正通知を送る、データ状態を再処理可能な状態へ戻す、といった対応がある。
どちらもエラー処理に見えるが、使う場面は違う。
ある手順がデータを読むだけなら、再試行はたいてい妥当だ。短いネットワーク不安定、混雑したデータベース、外部サービスの一時的なタイムアウトは、再試行で解決できることが多い。
しかし、ある手順が実際に「世界を変える」なら、再試行は新しい問題を作ることがある。たとえば次のような手順だ。
- 顧客へメールや SMS を送る。
- アカウント、チケット、注文、請求書を作る。
- 課金、返金、ポイント付与、在庫変更を行う。
- CRM、つまり顧客情報や接触履歴を変更する。
- 外部ツールを呼び出し、別のシステムで作業を始めさせる。
これらの手順が起きた時点で、世界はすでに変わっている。後で失敗したときに必要なのは、単なる再実行ではなく、後始末の計画だ。
補償動作は「失敗後の次の手順」であって、魔法の巻き戻しではない
分散システムでは、saga は一連のローカルトランザクションを扱うためによく使われる。Microservices.io は、途中のトランザクションが失敗したら、システムは補償トランザクションを実行して前の影響を明示的に取り消す必要があると説明している。Microsoft Azure の compensating transaction pattern も、復旧は単純なデータの巻き戻しではなく、予約取消や一部返金のように業務ルールに従う必要があると述べている。
一般的なワークフローでも、「補償動作」は失敗後に責任を持って実行する次の手順だと考えればよい。
それは必ずしも完全な復元ではない。多くのことは本当に巻き戻せない。メールは送られ、顧客は誤った通知を見ており、外部サービスには削除できないレコードが作られているかもしれない。
そのため補償動作は、たいてい次の形になる。
- 取消：予約、タスク、注文、一時データを取り消す。
- 標記：状態を「人間確認が必要」に変え、後続の自動化を止める。
- 訂正：訂正通知を送る、説明を補う、誤ったデータを更新する。
- 隔離：疑わしいデータを正式なレポートや顧客フローに入れない。
- 引き継ぎ：完了済み手順、失敗点、選べる対応を添えて担当者に知らせる。
ここでいう「担当者」は、文書上の名前だけでは足りない。誰がアラートを見るのか、誰が続行可否を判断するのか、誰が顧客や内部への影響を処理するのかが、本当に決まっている必要がある。
各手順が自動実行できるかを表で確認する
自動化を書く前に、フローを手順に分け、各手順が失敗したときどう補うかを確認する。
| フロー手順 | 失敗時に怖いこと | 先に書いておく補償動作 |
|---|---|---|
| 内部タスクを作成する | タスクが半端に作られ、チームが手動でもう一つ作る | 外部 ID を記録する。再試行前に存在確認し、見つからない場合だけ新規作成する |
| 顧客通知を送る | 後続データが失敗したのに、顧客は不完全な通知を受け取る | 後続の自動送信を止める。人間確認に回す。必要なら訂正通知を送る |
| 支払い、ポイント、在庫を更新する | 金額や数量を誤って変更し、再実行でさらに変える | 影響の大きい手順は自動再実行しない。記録をロックし、担当者が差分を確認する |
| 外部 AI やエージェントを呼ぶ | AI がすでにファイル編集、PR 作成、送信、別ツール起動をしている | 各動作の記録を必須にする。失敗後はレビュー待ちで止め、次のツールに続けさせない |
この表は出発点にすぎない。目的はフローを複雑にすることではなく、「第 3 手順が失敗したら、第 1 手順と第 2 手順の痕跡をどう扱うのか」を先に答えさせることだ。
もう一つ、一般原則を覚えておきたい。実際に「何かをする」手順は、できるだけ idempotent に設計する。これは「同じことを何度しても、副作用が複数できない」という意味で読めばよい。たとえば同じ注文番号でタスクを作るなら、二度目の呼び出しは新しいタスクを作るのではなく、既存タスクを返すべきだ。Cloudflare を含む多くのワークフロープラットフォームの公式文書も、この点を強調している。
もし自分のフローがそれを満たせないなら、再試行だけを保護策にしてはいけない。
どのフローから復旧手順を書くべきか
すべての自動化に完全な saga、つまり各手順に失敗後の補修動作をあらかじめ書く設計が必要なわけではない。ファイル名を整える、データを固定形式に変換する、公開情報から要約を作る、といった処理は比較的低リスクだ。
しかし、次の種類のフローを日常業務に入れるなら、先に復旧手順を書くべきだ。
- 外部にメッセージを送るフロー：メール、SMS、SNS 投稿、サポート返信、顧客通知。
- 正式データを変更するフロー：CRM、注文、支払い、在庫、会員状態、権限。
- 複数システムをつなぐフロー：フォーム、スプレッドシート、プロジェクト管理ツール、財務システム、外部 API。
- AI に複数手順を連続実行させるフロー：データを読む、ファイルを編集する、ツールを呼ぶ、PR を開く、人に通知する。ここでいう AI agent は、一文を返すチャットボットではなく、複数の動作を続けて実行する AI のことだ。
これらに共通するのは、失敗が一つの画面だけで終わらないことだ。外部の痕跡、誤ったデータ、後続の連鎖動作を残す可能性がある。
補い方をまだ説明できないなら、フローは「草稿を作る」または「レビュー待ちタスクを作る」で止め、正式動作まで自動で進めない方がよい。
小さなチームがまずできる三つの変更
第一に、各自動化フローへ「すでに何をしたか」の記録を加える。少なくとも、フロー ID、各手順の開始・完了時刻、外部システムから返った ID、エラーメッセージ、次の状態を残す。記録がなければ、復旧は推測になる。
第二に、影響の大きい手順を人間の承認ゲートの後ろに置く。顧客へ送る、金額を変える、権限を変える、正式データを編集する動作は、AI や自動化スクリプトだけに判断させない。
第三に、影響の大きい手順ごとに一文の補償ルールを書く。たとえば「タスク作成後にメール送信が失敗したら、タスクは再作成せず、担当者に再送を通知する」。この一文だけでも、「失敗したら考える」から「失敗にも次の手順がある」へ変わる。
このミニ講座の結論
自動化が本当に成熟しているかは、普段どれだけ滑らかに走るかでは決まらない。失敗したときに、理解でき、止められ、補えるかで決まる。
Cloudflare Workflows の saga-style rollbacks は、この考え方を思い出させる新しいきっかけにすぎない。Cloudflare、GitHub Actions、Zapier、n8n、社内スクリプト、複数ツールをつなぐ AI agent のどれを使う場合でも、同じ問いを立てる。
- どの手順は再試行だけでよいのか。
- どの手順は、一度実行したら補償動作が必要なのか。
- どの失敗は自動処理せず、担当者の確認で止めるべきか。
- 復旧時に何の記録を見れば、すでに起きたことが分かるのか。
これらの答えを先に書いておけば、自動化は壊れたとき誰も触れない高速なブラックボックスではなくなる。前に進む方法だけでなく、止まって後始末する方法も知っているワークフローになる。
生活四コマ
- 多段階の自動化フローが順調に進み、各手順が自分で完了できるように見える。
- 途中の手順が失敗し、チームはすぐ全体を再実行せず、いったん止める。
- 事前に書いた補償動作を使い、前の手順が残した影響を整理する。
- 担当者が記録を確認し、再試行できるものと手動対応が必要なものを判断する。
AI 整理カード
この記事の状況に合わせて、AI に整理してもらう
自分の AI チャットツールに貼り付けると、このミニクラスを自分用のチェックリストにできます。BMC は、あなたが AI に貼り付けた内容を見ることはありません。
参考資料
- Cloudflare Blog: How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/
- Cloudflare Docs: Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/
- Microservices.io: Pattern: Saga — https://microservices.io/patterns/data/saga.html
- Microsoft Learn: Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
