FDEで問い合わせと顧客管理を連携するときは、「失敗したらもう一度実行する」だけでなく、同じ受付を再実行しても登録や通知が重複しない仕組みを設計します。受付番号、工程ごとの処理状況、結果が分からない場合の確認方法を先に決めることが要点です。
本記事では、問い合わせの転記を例に、再試行と二重登録防止を解説します。図解と画面は86研究所が制作した説明用の例です。顧客への導入実績や、特定サービスの完成した連携機能を示すものではありません。
なぜ「もう一度実行」で二重登録が起きるのか
たとえば、問い合わせを顧客管理ツールへ登録した直後に通信が切れると、連携元には「応答がない」と表示されても、連携先では登録が終わっている場合があります。そこで最初から登録し直すと、同じ問い合わせが2件になる可能性があります。
FDE(Forward Deployed Engineer)は、こうした業務とシステムの境目も含めて設計・実装・運用をつなぐ役割です。AIで内容を要約する工程に加えて、受付番号を維持し、結果を記録し、判断できない処理を担当者へ戻す流れを整えます。役割の全体像はFDEの基本解説をご覧ください。
図解:受付番号と処理結果で再実行を制御する

同じ操作を繰り返しても追加の影響が生じないようにする考え方を「冪等性(べきとうせい)」と呼びます。実務では、何を同じ操作とみなし、どこで重複を止めるかを具体的に決める必要があります。
一次情報の例として、StripeのAPIは、同じ冪等キーを使った再試行に保存済みの結果を返す仕組みを説明しています。ただし、保存期間や対象となる処理には仕様があり、別のサービスへそのまま当てはめられるわけではありません。出典:Stripe公式「Idempotent requests」。以下はその考え方を参考にした、86研究所の業務連携の設計案です。
FDEへの依頼前に決めたい4つのルール
1.「同じ問い合わせ」を受付番号で識別する
再試行のたびに新しい番号を作ると、前回と同じ処理だと判定できません。受付時に決めた番号を、その問い合わせの再試行でも使います。複数の受付窓口がある場合は、受付元と番号を組み合わせ、番号の衝突を避けます。
メールアドレスだけで重複判定すると、同じ人からの別の問い合わせまで止めるおそれがあります。顧客の同一性と、問い合わせの同一性は分けて扱います。また、同じ受付番号で内容が変わった場合は、確認待ちにするか変更用の処理に分け、黙って上書きしないルールを決めます。
2.顧客登録と通知を別々に記録する
「顧客登録は成功、担当者通知は失敗」という状態で全工程を再実行すると、登録が重複する可能性があります。受付番号に対して、登録先のレコード番号、登録状態、通知状態、最終実行時刻を残し、どの工程を再開するか判断できるようにします。
3.結果不明を「失敗」と決めつけない
応答が途切れた処理は、連携先の登録番号や受付番号で照合します。照合する手段がなければ、確認待ちとして担当者へ戻します。連携先が冪等キーに対応している場合も、有効期間、同じキーで内容を変更した場合の挙動、エラー時の扱いを確認します。
4.同時実行でも重複を止める
「登録済みか検索し、なければ登録する」だけでは、2つの処理が同時に検索して両方とも未登録と判断する場合があります。本番では、保存先の一意制約や、同じ受付番号の処理権を一度に1つだけ確保する仕組みなどが必要です。外部ツールへの登録がある場合は、そのツール側の重複防止方法も合わせて設計します。
実画面:2回操作しても登録件数は1件のまま
説明用のデモをブラウザーで実行しました。架空の受付番号「DEMO-001」を1回目に処理すると登録件数は1件になります。2回目には「登録済みのため追加しません」と表示し、件数を増やしません。

この画面は、ブラウザー内の一時的な記録だけを使う最小限のデモです。再読み込みすると記録は消えます。AI処理、外部ツールへの登録、通知、複数端末の同時実行への対応は実装していません。本番では、前節のように記録を永続化し、同時実行や連携先の状態まで扱う必要があります。
導入前に使える受入チェック表
| 確認する場面 | 期待する動き |
|---|---|
| 同じ番号・同じ内容を2回実行 | 登録を増やさず、処理済みの結果を確認できる |
| 同じ番号で内容を変更 | 確認待ち、または合意済みの変更処理へ進む |
| 登録成功後、通知に失敗 | 登録済みの記録を保持し、通知工程を切り分ける |
| 登録直後に通信が切れる | 連携先を照合し、確認できなければ保留する |
| 同じ受付を同時に実行 | 並行処理でも重複登録を防げる |
| 停止・再起動後に再実行 | 保存された結果から判断できる |
| 古い受付を再実行 | 記録の保持期間を超えた場合の対応が決まっている |
通知の再試行も、相手に届いているか不明な場合は重複送信の可能性があります。「一度だけ送れる」と想定せず、通知サービスの仕様と確認手段を確かめます。停止・復旧時の担当者の動きは、AI自動化で人に戻す設計と合わせて整理できます。
問い合わせ連携を小さく始める進め方
最初は1つの受付窓口と1つの登録先に範囲を絞り、現在の転記手順、登録済みかどうかの確認方法、例外の担当者を整理します。AIの要約精度だけでなく、重複件数、確認待ちの件数、復旧にかかる手間も記録すると、運用上の課題を見つけやすくなります。
運用担当者には、何度でも押せる再実行ボタンだけを渡すのではなく、処理結果の見方と、押してよい条件を伝えます。引き継ぎ内容はFDE支援後の引き継ぎチェックリストも参考になります。
よくある質問
AIが重複かどうかを判定すれば十分ですか?
似た文章を探す補助には使えても、処理の再試行を識別する受付番号や保存先の重複制御の代わりにはしません。内容が同じでも別件の場合があるため、業務上の識別ルールを先に決めます。
ノーコードの連携ツールでも確認が必要ですか?
必要です。再試行の設定、処理履歴の保持期間、同時実行、連携先の重複防止機能を確認します。実現できる範囲は製品と契約・設定によって異なります。
86研究所には何を相談できますか?
86研究所のFDE伴走支援では、業務整理からAI活用設計、ツール連携、実装、運用改善までを支援しています。問い合わせの転記や担当者への引き継ぎも、現行の仕組みを確認して対象範囲を決めます。現在の受付窓口、登録先、困っている場面を整理し、AI業務診断でご相談ください。
執筆・図解・デモ制作:86研究所|公開日:2026年10月8日。本文の手順は説明用の設計案です。参照先の仕様と自社の業務条件に合わせて確認してください。