顧客がフォームを送ると、システムはタスクを作り、確認のメールも送った。ところが支払いの状態を更新するところで失敗した。画面には「実行に失敗しました」としか出ず、当番の人は前の二つの操作が本当に終わったのかを確かめられない。ここで再実行を押すのは修復ではなく、タスクをもう一件作り、メールをもう一通送ることになるかもしれない。
2026 年 6 月、Cloudflare はワークフローのサービスに「ロールバック」の機能を加えた。開発者は手順ごとに、そのあと流れが失敗したときに行う埋め合わせの操作を書いておける。あとの手順が失敗すると、システムは終わった手順の埋め合わせを、手順を始めた順の逆に一つずつ行う。埋め合わせ自体が失敗すれば止まり、エラーとして記録する。
この機能が投げかける問いは、特定の基盤に限らない。決まった時間に動くスクリプトでも、ノーコードの自動化でも、外部のツールを操作する AI エージェントでも、流れが途中で止まったら、まず何がもう起きたのかを確かめ、それからやり直すか、埋め合わせるか、止めて人に渡すかを決める。
流し直す前に、何がもう起きたかを問う
データを読むときに接続がタイムアウトし、何も書き込んでいないなら、もう一度試しても普通は問題ない。だが注文や請求書の作成、通知の送信、支払いや返金の処理、顧客のデータや権限の更新は、どれも本物の結果を残す。AI エージェントがすでにファイルを直したり、メッセージを送ったりしたなら、何もしなかったことにはできない。
埋め合わせは、データを元の値に戻すことでもない。送ったメールは取り消せない。同じ記録をほかの人がもう書き換えているかもしれない。外部のサービスが作った記録を、そのまま消すのがふさわしいとも限らない。マイクロソフトの設計の手引きははっきり書いている。埋め合わせは、実際の業務の規則に沿って済んだ部分を処理するもので、システムを元の状態に戻せるとは限らない。たとえば旅行のサイトが航空券は取れたのにホテルを取れなかったなら、航空券をすべて取り消すより、別のホテルを勧めたほうがよいこともある。そしてその判断は、システムではなく客がするべきだ。
外部を変える手順ごとに三つのことを書く
いまある流れを一つ取り、外部の状態を変える手順に印を付け、それぞれについて書いておく。
何の記録を残すか: 流れの実行番号、外部のシステムが返した番号、要求の結果、完了の時刻。これがないと、「タイムアウト」と「失敗」が同じに見え、誰も次の一歩を判断できない。
失敗したらどう扱うか: タスクを作る前に、決まった番号ですでに作られたものがないかを調べ、二重作成を防ぐ。送信に失敗したら、それ以降の送信を止めて要確認にする。支払いや権限の変更は決して自動でやり直さず、記録を照らし合わせてから人が決める。
次の一歩を誰が決めるか: お金、正式な顧客のデータ、権限、外への連絡に関わる手順には担当者を一人決め、どの記録を見て、どの状態で続行を押すのかをはっきりさせる。
Cloudflare の公式の規則は、やり直されうる手順を「冪等」にすることも勧めている。同じ要求を何度実行しても、結果は一回分しか生まれないということだ。たとえば同じ注文番号でタスクを作るなら、二回めは既存のタスクを返し、もう一件作ってはいけない。ただし冪等にしても防げるのは重複だけで、一回めでもう間違えたことは直せない。
取り消せない手順は最後に回す
マイクロソフトの手引きには、もう一つとても実用的な勧めがある。外への送信や法的な効力を持つ操作のような「後戻りできない地点」をはっきり示し、重要な確認がすべて通ったあとにだけ実行するよう並べることだ。冒頭の例なら、先にタスクを作って支払いの状態を更新し、すべて確かめてから最後に確認のメールを送れば、失敗したときに片付けるものはずっと少なくなる。
流れに AI エージェントがいて、前の手順が成功したかどうかがはっきりしない、あるいは埋め合わせ自体が本番のデータをまた変えてしまうなら、まずそれ以降の操作を止める。常駐型 AI アシスタントは、止まることを覚えてから主要アカウントにつなぐも参考になる。コードを直す仕事に人の確認の地点を置く方法は、その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるを参考にしてほしい。
埋め合わせの手順も失敗しうる
埋め合わせ自体も失敗しうるので、それもやり直せて、記録が残るようにしておく。マイクロソフトの手引きは、人の手による介入が唯一の回復の方法になることもあり、そのときシステムは黙って止まるのではなく、失敗の理由を添えた警告を出すべきだとしている。
今日はまず、メールを送る、データを変える、外部のサービスを呼ぶ流れを一つ選び、いちばん影響の大きい手順だけを扱う。そのまま実行できる規則を一つ書く。たとえば「タスクを作ったあとでメールの送信に失敗したら、タスクを作り直さない。タスクの番号と送信の結果を残し、要確認に移し、決められた担当者が再送するかを決める」。何がもう起き、どう埋め合わせられ、誰が承認するのかを言えるようになるまでは、影響の大きい流れを自分で回復させるべきではない。
AI 整理カード
何段階もの自動化の流れ(決まった時間の処理、ノーコードのツール、AI エージェント)がある。途中で止まったとき、やり直して同じことを二度したり、取り消せない結果を残したりしないかを先に確かめたい。
判断方法はこの記事による:https://boosterminiclass.com/ja/posts/workflow-rollback-needs-compensating-steps/
記事の見方はこうだ。流れが途中で止まったら、まず何がもう起きたかを確かめ、それからやり直すか、埋め合わせるか、人に渡すかを決める。外部の状態を変える手順ごとに、たどれる番号を残し、失敗したときの扱いを書き、次の一歩を決める人を決め、取り消せない手順はすべての確認を通ったあとに置く。
私が許可した流れの設定と実行の記録だけを、読み取り専用で確認してほしい。やり直したり、直したり、消したりしないこと。
1. 流れのすべての手順を挙げ、外部の状態を変えるもの(記録の作成、メールの送信、支払い、権限の変更、AI エージェントの外への操作)に印を付ける;
2. それぞれの手順が終わったときに残す記録や番号を確かめ、ないものは「記録なし」とする;
3. それぞれの手順が失敗したときの扱いを提案する。やり直してよい、確かめてから埋め合わせる、止めて人に渡す、と理由;
4. 取り消せない手順がすべての確認のあとにあるかを確かめ、そうでなければ並べ替え方を提案する。
最後に、いちばん影響の大きい手順を一つ選び、そのまま実行できる扱いの規則を一つ書くこと。
参考資料
- Cloudflare 公式ブログ:How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/(2026-06-25)
- Cloudflare 公式ドキュメント:Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/ [accessed: 2026-10-11]
- Microsoft Learn(公式):Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction [accessed: 2026-10-11]



