Makeの重複防止と再処理｜受付IDで安全に復旧する設計

Makeのシナリオは、通信失敗や手動再実行によって同じデータを二度扱うことがあります。大切なのは「失敗したらもう一度動かす」ではなく、何を一回として数えるかを先に決めることです。問い合わせなら受付ID、受注なら注文番号、請求なら請求対象月と取引先IDを処理キーにします。

まず処理台帳を用意する

項目	意味	更新者
処理キー	一件を識別する不変値	受信時にMake
状態	受付・処理中・成功・要確認	Makeと担当者
実行ID／時刻	調査の手掛かり	Make
次の担当	例外を受け取る人	運用責任者
再処理理由	なぜもう一度動かすか	担当者

シナリオの最初に台帳を検索し、成功済みの処理キーなら何も書き込まず終了します。処理中のまま一定時間を超えたものは、自動で再送せず「要確認」に送ります。これだけで、メールの二重送信やCRMの二重登録を大幅に減らせます。

再処理は一件ずつ、結果を残す

状況	自動化の動作	人が決めること
一時的な接続失敗	一回だけ待って再試行	それでも失敗した時の担当
宛先・入力値の不備	要確認にする	修正内容と再実行可否
外部側の登録済み応答	成功扱いにせず照合	相手側の実データ
シナリオ変更直後の失敗	停止して影響を記録	ロールバックか修正か

再処理ボタンや管理用Webhookを作る場合も、対象の処理キーを必須にし、全件再処理は用意しません。再実行者、理由、前回の状態、結果を残せば、後から「なぜ二度動いたか」を説明できます。

運用チェック

• 新しいシナリオはテスト用の受付IDで一回ずつ確認する
• 台帳の成功済みデータを使って、二回実行しても変化しないことを試す
• 失敗通知には個人情報・認証情報を含めない
• 週次で要確認件数、再処理件数、重複検知件数を確認する

重複防止はMakeの特定モジュールの設定だけでは完成しません。業務側で一件を識別するキー、例外を判断する担当、復旧の記録をそろえることで、自動化を止めずに安全に育てられます。

設計例：注文確認メールを二重に送らない

注文番号を処理キーにし、台帳に「通知予定」「送信中」「送信済み」「要確認」を保存します。Makeは最初に注文番号を検索します。送信済みなら終了、送信中なら一定時間を超えた場合だけ要確認、通知予定なら送信処理へ進みます。メールの送信成功を受けてから送信済みに更新し、送信前に状態を確定しないことが重要です。

状態	画面上の意味	Makeがしてよいこと	人の対応
通知予定	まだ送っていない	宛先と内容を生成	不備があれば保留
送信中	成否が未確定	同じキーを処理しない	一定時間後に確認
送信済み	成功を確認した	処理を終了	問合せ時に履歴参照
要確認	例外がある	追加送信しない	宛先・注文・ログを照合

変更管理を再処理と分ける

重複事故は、シナリオを直した直後にも起きます。フィルタ、検索条件、接続先の列名を変える時は、変更前のシナリオを複製し、テスト用データで入力から台帳までの流れを確認します。本番変更では、変更者、変更内容、開始時刻、戻す方法を記録します。エラーを直すための再処理と、仕様を変えるための再実行を同じ操作にしないことで、影響範囲を限定できます。

毎週見る数字

指標	見る理由	悪化した時の確認先
重複検知件数	起点や再送の増加を知る	フォーム・Webhook・手動実行
要確認の滞留時間	担当不足を知る	担当割当と通知先
再処理成功率	復旧手順の妥当性を知る	エラー分類とデータ品質
同じキーの連続失敗	設計不備を早く見つける	接続先・変更履歴

数字は責任追及ではなく、次に自動化を直す場所を知るために使います。安全な再処理は、成功を急ぐ仕組みではなく、止める・調べる・一件ずつ戻すための業務設計です。