顧客がフォームを送信すると、顧客レコードを作成し、サポートチームのタスクを開き、確認メールを送る自動化を考えてみる。最後の支払い状況またはCRM状況の更新だけがタイムアウトした。

ダッシュボードには実行失敗と表示されるが、現実世界への三つの操作はすでに完了しているかもしれない。最初から実行し直すと、顧客の重複、二つ目のタスク、同じメールの再送が起こり得る。したがって、急いで答えるべき問いは、単にどう再起動するかではない。何が起きたのかを特定し、繰り返してはいけない影響を封じ、誰が次の試行を承認できるかを決めることである。

Cloudflare は2026年6月25日、長時間にわたる多段階アプリケーションフローのための基盤 Cloudflare Workflows に saga-style rollbacks を導入し、この問題を浮き彫りにした。step.do() で実行した作業には、後続手順が失敗したときに動く補償ロジックを対応させられる。この実装は新しいが、運用上の原則は一つの基盤に限られない。重大な影響を持つ各手順には、観測できる証拠、安全な再試行または補償方法、停止条件、復旧判断の責任者が必要である。

再試行は中断を直しても、その後始末までは直さない

外部への影響を残していない操作では、再試行が役立つ。一時的なネットワーク問題で読み取り専用APIリクエストが失敗しただけなら、再度試しても問題ない場合がある。その要求はメッセージを送らず、オブジェクトを作らず、残高も正式記録も変更していない。

ワークフローが外部で動作した後は計算が変わる。成功応答が返らなくても、アカウント、注文、請求書、チケット、社内タスクはすでに存在するかもしれない。顧客はメールやSMSを読んでいるかもしれず、支払い、返金、ポイント、在庫、CRMデータ、権限はすでに変わっているかもしれない。AIエージェントがファイルを編集し、プルリクエストを開き、別のツールに作業継続を指示している可能性もある。

盲目的な再実行では、操作が起きなかった場合と、成功したのに確認だけ返らなかった場合を区別できない。そのため復旧の試みが、注文の重複、通知の再送、記録の競合、二度目の金銭変更を引き起こす。

Saga に基づく復旧では、後続トランザクションが失敗したとき、完了済みの作業に補償操作を割り当てる。補償は必ずしも完全な巻き戻しではない。データベースの以前の値を復元すると、同時進行した正当な変更を上書きすることがあり、届いた顧客メッセージを未読には戻せない。適切な対応は、注文の取り消し、記録への印付け、訂正、疑わしい出力の隔離、担当者への引き継ぎかもしれない。

各手順について、チームが最も避けたい失敗から考える。

手順と外部への影響中断後に起こり得る問題事前に定める復旧契約
状態を変えずに読み取りまたは検証する一時的なサービスエラーで完了できない明記した上限までだけ再試行し、その後は停止してエラーを記録する
アカウント、タスク、チケット、注文、請求書を作るオブジェクトは存在するのに、応答喪失により別のものを作る外部IDを保存し、新しい作成要求の前に既存オブジェクトを検索する
メール、SMS、顧客通知を送る後続の失敗で同じメッセージを再送する以後の送信を止め、案件をレビュー状態にし、必要なら訂正を準備する
金銭、ポイント、在庫、CRMデータ、権限を変える再試行で変更が重複するか、正式データに不整合が残る対象レコードをロックし、所有者が証拠を照合するまで変更を重ねない
AIエージェントまたは外部ツールを呼び出すツールは完了したのに確認が失われ、後続作業が続く操作ログを保存し、不確かな出力を隔離し、依存する全操作を人間レビューまで保留する

この契約の目的は、すべての影響を消せると保証することではない。失敗した実行を即興の全再実行ではなく、既知の復旧状態へ移すことにある。

証拠に基づいて復旧を判断する

同じ要求を繰り返しても、最初の成功後に追加の影響が生じない手順は、冪等で復旧しやすい。たとえば、ある注文番号に配送タスクがすでに紐づいているなら、同じ注文番号を再送しても二つ目を作らず、既存タスクを返すべきである。永続実行では中断後に手順が繰り返されることがあるため、Cloudflare のワークフローガイダンスもこの性質を推奨している。

多くの外部サービスは、この保証を自動では提供しない。その場合、ワークフローは実行を再構成できるだけの証拠を保持する必要がある。実行ID、各手順の開始・完了状態、外部オブジェクトID、関連するエラーの詳細、現在の復旧状態である。赤い「失敗」ラベル一つだけでは、金銭が移動したか、顧客へ連絡したか、別システムが命令を受け付けたかを運用担当者は判断できない。

証拠にも所有者が必要である。アラートは、文書に名前が載っているだけの人ではなく、次の操作を承認、訂正、停止できる権限と背景知識を持つ人に届くべきである。AIエージェントがコードを編集したり開発ツールを呼び出したりする場合、AIエージェントへコード作業を任せる前にチェックポイントを置く方法は、次の重大な操作の前にレビューを置き、変更内容を確認できるようにする方法を示している。

権限設計でも同じ境界を強制すべきである。草稿を修正できることは、顧客へメールを送り、支払いを変え、アクセス権を変更する権限を意味しない。常時動くAIアシスタントに権限と停止境界を設ける考え方は、事故後に推測するのではなく、ツール権限と引き継ぎ条件を事前に明示すべき理由を説明している。

この基準は Cloudflare Workflows、GitHub Actions、Zapier、n8n、社内スクリプト、外部ツールにつながるAIエージェントに共通する。どの影響が起きたかを示せず、適切な補償を選べず、次の操作を承認できる人も特定できないなら、無人で変更を行う準備はできていない。草稿、保留、レビュータスクの状態で止めるべきである。

現在使っている自動化を一つ選び、状態を変える手順のうち最も重大なものを探す。その手順が実行されたかを証明する証拠、影響を封じるか訂正する操作、再試行を承認すべき人の三点を記録する。あらゆるエラーへの対応を後で約束するより、検証可能な復旧経路を今日一つ定義するほうが安全である。

広告

AI 整理カード

現在の環境ですでにアクセスできる自動化定義、リポジトリファイル、プロジェクト設定、実行ログ、運用記録から始める。まず読み取り専用で調査する。ワークフローの開始や再試行、ファイル編集、メッセージ送信、権限変更、外部記録の変更は行わない。

オブジェクト作成、顧客への連絡、金銭または在庫の変更、正式データの更新、外部エージェントまたはツールの呼び出しが可能な多段階フローを一つ選ぶ。最も重大な復旧上の弱点を自分で見つける。ファイルパス、設定キー、実行ID、ログ項目、外部レコード識別子など、判断を裏づける直接の証拠を引用し、観測した事実と推測を明確に分ける。

対象手順ですでに何が起きた可能性があるかを説明する。繰り返した要求が明らかに冪等かを判定し、そうでなければ、取り消す、レビュー対象として記録する、訂正する、隔離する、引き継ぐ、の中から適切な補償区分を選ぶ。復旧に必要な証拠、自動実行を止める条件、次の操作を承認すべき人間の役割も特定する。裏づけられない項目には「要確認」と記す。必須資料にアクセスできない場合は、入力一式の準備を求めず、不足する場所またはアクセス権について対象を絞った質問を一つだけ行う。

結論は「進める」「範囲を限定して試す」「停止する」のいずれか一つだけにする。証拠に基づく短い理由と、直ちに使える、読み取り専用で本番を変更しない次の一手を一つ示す。顧客への連絡、金銭または在庫の変更、権限、正式記録、外部ツールの操作は必ず人間のチェックポイントとする。明示的な承認と検証済みの復旧経路なしに実行も再試行もしない。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料