顧客ID・受付ID・操作IDを分ける
顧客IDは相手、受付IDは今回の依頼を表します。さらに一つの受付で保存と通知を分けて管理するなら、操作IDも分けます。たとえばformA|response123|saveとformA|response123|notifyです。受信時刻や毎回生成する乱数だけをキーにすると、同じ受付の再送を同一だと判断できません。
処理状態を成功・失敗だけにしない
状態の例はreceived、saved、notified、needs_reviewです。保存先が返したレコードID、通知先が返したメッセージIDも記録します。台帳への保存後に通知だけ失敗した場合はsavedから再開できます。完了という一つの値だけでは、何が終わっていて何をやり直せばよいか分からなくなります。
Data storeでキーと状態を管理する
MakeのData storesから専用の保存先を作り、キーに操作ID、値に状態や外部レコードIDを持たせます。Check the Existence of a Recordなどで確認し、対象の状態に応じて次の操作を決めます。Add/Replace a Recordを無条件で使えば、同じキーの上書きで履歴を失う場合があります。既存レコードがあるときの挙動を明示してテストしてください。
確認してから追加するだけでは競合が残る
二つの実行が同時に「未登録」を確認すると、両方が書き込めます。同じシナリオを順番に動かす設定は競合を減らしますが、別シナリオや外部アプリからの書き込みまでは直列化しません。厳密な一意性が必要なら、保存先の一意制約、原子的なキー取得、送信先APIの冪等性キーなどを使います。
通知済みか分からない場合は照合する
送信は成功したが応答を受け取れなかった場合、Makeからは成功を確認できないことがあります。この状態で全体を再実行する前に、受付IDやメッセージIDで送信先を確認します。見つかったなら状態を修正し、判断できなければ確認待ちにします。金銭や重要通知では、無条件の再試行より照合の手順を優先します。
五つの入力で重複防止を確認する
同じ受付の二回送信、同じ顧客の別受付、同時に届いた同じ受付、保存後に失敗した受付、通知後の状態更新だけ失敗した受付を確認します。期待する行数だけでなく、受付IDと外部IDの対応を見てください。同じ顧客の二件目を消してしまう場合は、重複防止が強すぎて正しい入力を失っています。
よくある疑問：処理前に完了キーを残せば安全か
処理前に完了として保存すると、その後に失敗した受付まで処理済みになり、再配達でも回復できなくなります。逆に処理後だけ保存するなら、外部の更新成功とキー保存の間に失敗する余地が残ります。どちらかの順番だけで完全に解決しようとせず、処理中の状態、期限、照合方法を設計してください。
重要な操作では、送信先が提供する冪等性キーや一意制約を優先します。保存と通知が別サービスなら、それぞれの成功を独立に記録し、長時間処理中のキーを担当者が確認できるようにします。
キーの保存期間と担当者を決める
キーを削除すると、古い受付の再送が新規に見える可能性があります。想定する再配達や手動復旧の期間を決め、その間は必要なキーを保持します。個人情報の本文を無期限に残す必要はありません。キー、状態、時刻、外部IDなど調査に必要な項目へ絞り、保留を確認する担当者も決めてください。
Makeで小さな自動化から始める
まず練習用データで必要な処理を確認し、利用量と機能に合うプランを選んでください。登録時の料金・特典・適用条件は公式画面で確認できます。
Make公式サイトで登録する広告リンク利用量から費用を確かめる
月の処理件数、課金対象のステップ数、再試行を入力し、サービスごとに異なる課金単位を確認できます。
費用を試算する参照した公式情報
料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。
- Make Data stores and record operations情報確認日: 2026-10-29
- Make scenario settings情報確認日: 2026-10-26
- Make error handling overview情報確認日: 2026-10-29
- Make pricing — Core at 10,000 monthly credits情報確認日: 2026-10-28
- Make credits情報確認日: 2026-10-26