受付IDと顧客IDを分ける：二重登録と顧客の取り違えを避ける設計

受付のIDと、顧客のIDを分ける

一人の顧客が二回問い合わせた場合、顧客は同じでも受付は別です。顧客IDだけを重複判定に使うと、正しい二回目の依頼を消してしまいます。反対に毎回新しい受付IDを作ると、同じ送信の再試行を見分けられません。

入力元の一意な回答IDなど、何を継続して使えるか確認します。利用できない場合は採番方法と照合条件を決めます。時刻だけに頼る、氏名だけで決める、といった曖昧な対応は避けます。

顧客が一人に決まらない時は保留する

架空の例で、名前「佐藤」に一致する顧客が二人いたとします。先に見つかった人へ自動でひも付けず、照合できない受付として止めます。IDが空なら新規顧客として作る、という動きも、意図した仕様かを確認してください。

再実行で何を省くかを先に決める

同じ受付IDが再び来たら、記録を追加する前に処理状態を確認する設計にします。保存済みで通知未確認なら、保存を繰り返す必要があるかを分けて判断します。全体を最初から流すことを標準の復旧手順にはしません。

通知先や登録先が一意な外部キー、重複拒否、更新操作に対応するかも調べます。単に表を検索してから行を追加するだけでは、二つの処理が同時に検索して両方が追加する競合を防ぎきれないことがあります。

順番に動かす設定にも範囲がある

Make公式「Scenario settings」には実行を順番に処理する設定が説明されています。重なりを減らす選択肢ですが、別シナリオや手動編集まで一括して重複を防ぐ仕組みと考えないでください。

保存先が持つ一意性の制約を使えるか、受付IDを保存できるか、重複時にどう返されるかを確認します。表だけで運用する場合は、同時書込をどこまで制限できるかと、定期的に重複を見つける手順を残します。

正常例より、ぶつかる例を試す

二回送信して件数が増えないことだけで、すべての重複を防げたとは言えません。入力と出力の関係を変えた例も用意します。試験は架空データと確認用保存先に限定し、件数だけでなく対象顧客IDも比較します。

• 同じ受付ID・同じ内容を二回渡す
• 同じ顧客ID・異なる受付IDを渡す
• 受付IDが同じで内容が違う場合を保留する
• 保存成功後に通知だけ失敗した状態を確認する

迷った時に消さずに調べられる記録へ

重複候補の元データを消すと、何が起きたかを追えません。受付ID、実行した時刻、保存先のID、判定理由を残し、個人情報を必要以上に複製せずに調査できる形を目指します。

Make公式の未完了実行の説明は、失敗した処理を確認する入口になります。ただし実行履歴と業務上の重複台帳は役割が違います。処理が成功表示でも、同じ受付を二回処理していないかは、別に確認してください。

ここまで確認できたら、次へ

• 受付と顧客のIDを分けたか
• 候補が複数なら保留するか
• 同時書込の競合を考えたか

確認できない項目は理由と確認先を残します。説明例の結果を、自分の環境で確かめた結果へ置き換えないでください。