タイムアウトした自動化を再実行しても、CRMのタスクは重複しないか

キャンペーンの自動化が止まると、早く再開したくなるものです。ただ、もう一度動かした結果、CRMのフォローアップタスクやクーポン、顧客へのメッセージが二つできては困ります。技術的には新しい試行でも、業務として必要な操作は一回のまま、という状況を扱える設計が必要です。

マーケティング運用の責任者が実装担当者と合意すべきなのは、単なる再試行回数ではありません。何を同じ操作とみなし、どの記録で結果を確かめ、誰が再開を判断するのか。この三点を先に決めると、復旧を自動化できる範囲が見えてきます。

「失敗」と「結果が分からない」を分ける

タイムアウトとは、呼び出した側が応答を待つのをやめた状態です。呼び出された側まで処理をやめたとは限りません。操作開始前の失敗、確認済みの完了、結果不明の三つを分けて記録してください。最初は規定に従って再試行し、完了なら結果を再利用します。結果不明なら、影響のある操作を繰り返す前に処理先と照合します。

具体例として、Shopify Flowのカスタムアクション用エンドポイントでは、応答を最大10秒待った後に接続を閉じ、後で再送します。受信側はaction_run_idで同じアクション実行を識別できますが、その操作の重複を防ぐ仕組みは別途必要です。この10秒という条件は、すべてのWebhookやCRM、AIに共通するものではありません。

操作の識別子と、復旧に使う記録を決める

一つの業務操作には、個人情報を含まない、意味を持たせない固有の操作IDを付けます。再試行でも操作IDは変えず、それぞれの試行には別の試行IDを付けます。意図的にもう一件作る場合は、新しい操作IDと承認が必要です。重複を防ぐ一方で、正当な別の操作まで止めないための区別です。

Webhookは、出来事の発生をシステム間で自動通知する仕組みです。同じ通知が再び届くことがあります。Shopifyも重複配信への対応を求めています。また、同じ加盟店の操作でも、購読設定が別ならWebhookのIDが異なり、イベントIDは共通になる場合があります。配信の識別子をそのまま業務操作の識別子にできるとは限りません。通知と業務上の操作をどう対応させるか、実装担当者に説明してもらいましょう。

記録には、操作ID、発生元とイベント、予定する操作、承認済みの内容と版、状態、試行回数、処理先の結果を示す参照情報、時刻を残します。さらに責任者と次に必要な判断も記載します。この記録形式を検討するために、実在する顧客の機微な情報を入れる必要はありません。

保存済みの結果を使って、未完了の段階から進める

ここからは、実行していない架空の例です。承認されたキャンペーン依頼を受けて、CRMにフォローアップタスクを一件作り、その後メールを送るフローを考えます。CRMでは保存が済んだものの、応答が失われました。フロー全体を最初から動かすと、二件目のタスクを作るおそれがあります。

まず、関連付けに使える確かな情報で既存のタスクを照会します。作成済みと確認できたら、CRM側のタスクIDを記録し、まだ解決していない段階だけを再開します。タスク作成とメール送信は、それぞれ完了を確認します。片方の成功を、もう片方の成功とみなしてはいけません。また、送信サービスによるメールの受付と、受信者への到達は別です。

照会で確かな結論が得られず、処理先にも重複を防ぐ機能がなければ、あらかじめ指定した確認担当者に回します。見つからなかったというだけで未作成と判断し、自動で再送する設計にはしません。

ローカルの確認だけでは防げない重複がある

「実行済みなら何もしない」という確認は有用ですが、それだけでは不十分です。二つの実行プロセスが同時に確認すると、どちらも未実行と判断して進める可能性があります。また、外部で操作が完了した直後、手元の成功記録を書き込む前に止まることもあります。

実装担当者には、手元の記録に対するアトミックな処理による実行権の確保、または一意性制約を求めます。アトミックとは、途中に分けられない一回の確保として扱い、二つのプロセスが同じ操作の実行権を同時に取れないようにすることです。それに加え、処理先の重複防止機能か、実際の結果を照合する方法が必要です。IDを書くだけ、操作後に成功を記録するだけでは保証になりません。

処理先が対応していれば、冪等性を利用します。読み方は「べきとうせい」で、文書化された条件の範囲で同じ操作を繰り返しても、効果が一回分から増えない性質です。対応する操作、保持期間、エラー時の振る舞いまで確認する必要があります。

Stripeの対応するPOSTリクエストでは、同じ冪等性キーに対し、最初に保存したステータスと応答を、エラーも含めて返します。パラメーターを変えて同じキーを使うとエラーになります。キーは少なくとも24時間経過後に削除されることがあり、削除後の再利用は新しいリクエストになります。結果が保存されるのはエンドポイントで実行が始まってからなので、入力検証の失敗や同時実行の競合は別の扱いです。これはAPIの条件を確認するための例であり、決済の自動化を提案するものではありません。24時間という条件を他のサービスに当てはめないでください。文書で認められている場合は、有効な保持期間内に同じキーとパラメーターで再試行し、処理先の冪等性によって既存の結果を取得する方法もあります。結果確認のために、必ず別途手動で検索する必要があるわけではありません。

人の承認を挟んでも、内容と実行状態は引き継ぐ

人が承認したから、再開後も一度しか実行されないとは限りません。LangGraphでは、interrupt()による一時停止から再開すると、対象のノード（処理のステップ）は先頭から再実行されます。中断より前に外部システムを変更していれば、その変更が繰り返される可能性があります。外部への操作を分離・移動したり、冪等にしたりする必要がありますが、段階を分けただけで、その後のあらゆる障害に対応できるわけではありません。

承認済みの内容も保存して引き継ぎます。AIに再生成させると、文面が変わることがあるためです。同じ承認済み操作の再試行では、そのとき承認された内容を使い、内容の変更は改めて確認を受けます。代わりの操作を新たに承認する前には、元の操作の結果を確認し、未解決の状態を解消してください。AIは下書きやエラー分類を助けられますが、実際に影響を与える操作は、明確な実行ルールと責任者が管理します。プロンプトを改善するだけで外部操作の重複を防ぐことはできません。

導入前に共有する受入確認リスト

次の項目は、実装担当者と合意するための試験案です。実施済みの結果でも、システムを問わず重複ゼロを約束するものでもありません。各ケースで、判断の根拠と次の担当者を確認できるようにします。

1. 通常の成功：意図した操作が完了し、処理先の参照情報が保存される。
2. 同じイベントの再配信：保護の対象として合意した条件下で、外部への効果は一回分となり、後の試行は既存の証拠を使う。
3. 処理先で成功した後のタイムアウト：結果を照合し、確定できなければ確認待ちにする。
4. 二つの試行の同時実行：実行権の確保と処理先の保護により、対象条件下で二重実行を防ぐ。
5. 承認後の再開：完了済みの段階を保ち、承認された内容で未完了の段階を進める。
6. 処理先の保持期間を過ぎた再実行：以前のキーによる保護を前提とせず、照合するか担当者の確認を待つ。

再試行の上限と、試行間隔を徐々に延ばす方法も処理先の文書に沿って決めます。無限に繰り返したり、すべての接続先に同じ回数を設定したりするのは避けます。運用ではイベント数、試行数、確認済みの外部効果、未解決の件数、担当者が復旧に費やした時間を分けて把握します。試行の成功件数だけでは、顧客に同じメッセージが届いていないかは分かりません。

一つのフローに絞って復旧の条件を確かめる

MindVerveの自動化サービスでは、トリガー、入力、出力、責任者を整理し、データ不足や障害への対応、テストケース、運用手順をまとめます。AI Workflow Launchは、合意した一つのワークフローを対象に、ツール選定、代表的なケースと失敗時の試験、再利用できる要件整理資料とプロンプト、文書化、研修、引き継ぎを行います。ライセンス、API利用料、追加の連携は含まれず、継続的な保守は別途となります。