途中で止まった自動化を、誰がどう片付けるのか

Larry

フォームの送信をきっかけに顧客レコードを作成し、確認メールを送り、最後に支払い状況を更新する自動化を考えてみる。支払い状況の更新だけが失敗したとしても、それ以前の処理まで失敗したわけではない。顧客レコードはすでに作られ、メールも相手に届いている。

ここでフロー全体を最初から実行し直すと、同じ顧客が二重に登録されたり、確認メールが再送されたりする。問題は「もう一度動くか」ではなく、「何がすでに起きており、その影響を誰の判断で処理するか」である。

Cloudflare は2026年6月25日、Workflows に saga-style rollbacks を導入した。Cloudflare Workflows の各 step.do() に補償処理を対応させ、後続の失敗時に何を行うかを手順の定義とともに記述できる仕組みである。この機能は特定製品の実装例だが、示している設計原則は広く使える。外部へ影響を及ぼす多段階フローには、再実行の条件だけでなく、実行済みの事実を確かめる証拠、影響を抑える処理、安全に止める条件、次の判断を担う人が必要である。

まず「やり直せる処理」と「影響が残る処理」を分ける

通信の一時的な不調でデータを読み取れなかっただけなら、同じ処理を再実行しても外部の状態は増えない。この種の処理は再試行と相性がよい。

事情が異なるのは、成功した時点で別の人やシステムに変化を残す処理である。顧客レコード、タスク、注文、請求書の作成、メールやSMSの送信、支払い、返金、ポイント、在庫、CRM、権限の更新は、後続処理が止まっても取り消されない。外部のAIエージェントやツールを起動した場合も、ファイル編集、プルリクエスト作成、送信などが途中まで完了している可能性がある。

こうした影響に対して用意するのが補償処理である。ただし、時刻を巻き戻すように元の状態をそのまま復元するとは限らない。注文を取り消す、誤った状態を保留にする、訂正文を用意する、疑わしいデータを隔離する、担当者へ引き継ぐといった、現実に起きたことを踏まえた処理も含む。

Microservices.io の Saga パターンは、複数のローカルトランザクションを連携させ、後の処理が失敗したときに先行処理の変更を補償トランザクションで打ち消す考え方を示している。Microsoft の Compensating Transaction パターンも、同時に進んだ別の変更まで上書きしかねないため、単純な復元では不十分だと説明している。つまり、補償処理は業務内容と実行時の状況に応じて決める必要がある。

金額、在庫、権限、正式データ、外部送信を変更する復旧処理は、自動で続行させないほうがよい。まず現在の処理を止め、記録と差分を残し、その後で人が実行可否を判断する。AIエージェントへコード作業を任せる前にチェックポイントを置く方法と同様に、影響の大きい操作ほど実行直前の確認が重要になる。

復旧契約は手順ごとに書く

フロー単位で「失敗したら再試行する」とだけ決めても、どの処理が完了しているかは判別できない。設計時には各手順について、外部状態を変えるか、完了を示す証拠は何か、同じ要求を再度受けても結果を増やさないか、失敗時にどこで止めるかを確認する。

手順の種類	確認すべき証拠	失敗後の扱い
顧客レコード、タスク、注文、請求書を作る	フローID、外部ID、作成時刻、応答内容	既存データを照合し、存在する場合は新規作成せず、そのIDを引き継ぐ
メール、SMS、顧客通知を送る	送信ID、宛先、本文の版、配信状態	後続送信を止め、必要なら訂正文を作り、人の確認後に送る
支払い、返金、ポイント、在庫を変更する	取引ID、変更前後の値、処理状態、監査ログ	対象を保留し、自動で再実行せず、担当者が履歴と差分を確認する
CRMや権限を更新する	対象ID、変更項目、実行主体、更新結果	影響範囲を限定し、復元または訂正の内容を承認待ちにする
AIエージェントや外部ツールを呼び出す	実行ID、生成物、編集内容、送信や起動の記録	後続処理を止め、完了済みの操作を確認してから再開方法を選ぶ

同じ入力を複数回処理しても結果が増えない性質を、冪等性という。たとえば同じ注文番号でタスク作成を二度要求された場合、二件目を作らず、最初に作成したタスクを返す設計である。Cloudflare Workflows の公式文書も、手順は再試行される可能性があるため、可能な限り冪等にすべきだとしている。

もっとも、冪等性だけでは復旧方針は完成しない。重複を防げても、すでに送った通知をどう扱うか、保留中の返金を誰が確認するかまでは決まらないからである。そこで各手順に、観測できる証拠、冪等に再実行する方法または補償処理、停止条件、判断責任者を一組として割り当てる。この一組が、その手順の復旧契約となる。

ログには少なくとも、フローID、各処理の開始と完了、外部システムが返したID、エラー、停止時点の状態を残す。これらを見ても実行済みの操作を説明できないなら、再試行の可否も安全な補償方法も判断できない。

常時稼働する仕組みでは、通常処理を実行できる権限と、復旧処理まで自動で進める権限を分けて考える必要がある。常時動くAIアシスタントに権限と停止境界を設ける考え方を使うと、どの操作で止め、誰へ通知し、何を確認後に再開するかを明文化しやすい。

本番投入の前に一つだけ書いてみる

ファイル名の整形や公開情報の要約のように、失敗しても外部へ変更を残さない処理なら、再試行だけで足りる場合がある。すべての自動化に大掛かりな saga 設計を持ち込む必要はない。

一方、GitHub Actions、Zapier、n8n、社内スクリプト、Cloudflare Workflows のどれを使っていても、複数のシステムにまたがって正式データや外部状態を変えるなら判断基準は同じである。完了済みの処理を証拠から特定できるか。再実行しても重複しないか。残った影響に対する補償方法があるか。安全性を証明できないときに止まり、判断を引き受ける担当者が決まっているか。この四点が本番投入の境界になる。

最初から全フローを書き直す必要はない。現在動いている自動化を一つ選び、外部への影響が最も大きい手順について、復旧契約を一文にする。たとえば次のように書ける。

「注文作成後に通知が失敗した場合、注文は再作成しない。外部IDと送信履歴を担当者が確認し、重複しないと判断した後でのみ再送する。」

この一文を書けない間は、正式な送信や更新まで無人で進めず、草稿または承認待ちの状態で止めるべきである。安全な自動化とは、一度も止まらない仕組みではない。どこまで完了したかを説明でき、残った影響を封じ、次の判断を適切な人へ渡せる仕組みである。

AI整理カード

現在アクセスできるワークスペース、リポジトリ、プロジェクト設定、実行履歴を変更せず、まず読み取り専用で確認してほしい。多段階の自動化を一つ調べ、途中で失敗した場合に再試行だけでは安全に処理できない具体的な問題を一件、自ら特定すること。ワークフロー定義、ログ、外部ID、エラー記録、生成物を確認し、ファイル名、処理名、実行ID、ログ行など見つけた直接の証拠を示すこと。観測できた事実と推測は明確に分け、確認できない項目は「要確認」と記すこと。必要な環境へアクセスできない場合に限り、調査開始に必要な対象または権限について質問を一つだけ行い、利用者に資料一式の準備を求めないこと。

特定した問題について、外部状態を変えた処理、残っている影響、利用できる証拠、外部ID、再実行時の重複リスク、冪等性または補償処理、停止条件、判断責任者を整理すること。各処理の判定には「再試行可能」「補償処理が必要」「人による確認が必要」のいずれかを使うこと。

最後にフロー全体を「進める」「範囲を限定して試す」「停止する」のいずれかで判定し、その根拠と、今日実行できる最小の次の一手を一つ示すこと。ただし、ファイル変更、再実行、外部送信、課金、返金、在庫・権限・正式データの更新は実行しないこと。影響の大きい復旧処理は提案にとどめ、担当者が証拠と差分を確認して明示的に承認するまで進めないこと。