問い合わせフォームが重複して届くとき｜操作・受付・通知を分けて調べる

同じ問い合わせが二通届いたとき、すぐに「利用者が二回押した」と決めないでください。一回の受付から通知が二通出た場合と、実際に二件の受付が作られた場合では、調べる場所が違います。利用者が画面の反応を待てずに再送したケースも、送信後の案内まで含めて確認します。

企業の受付・Web担当者と、フォームを実装する制作会社向けに、操作、通信、受付データ、通知、外部連携を切り分ける手順を整理します。問い合わせの件数とGA4のイベント数は別です。解析の重複だけを調べたい場合はGA4の二重計測の確認へ進んでください。

1. 重複している記録と、一件の受付を定義する

公開ページのURL、発生時刻、フォームの種類、確認できた受付記録と通知を残します。同じ文章のメールが二通あることだけで、利用者の操作回数や受付件数は分かりません。入力の一部を転載する前に、調査担当と共有する必要な範囲を決めます。

メール通数と受付IDを対応させる

保存型のフォームなら、同じ受付IDへの複数通知なのか、別の受付IDが作られたのかを確認します。受付データを保存しない仕組みなら、そのことを記録し、確認できる配信履歴や処理時刻から範囲を絞ります。記録がない状態を「一件だった」と補わないでください。

同じ人が条件を変えて再度相談することもあります。氏名や本文が同じという理由だけで、必要な問い合わせを自動削除しません。担当者が同じ相談の再送か、内容を更新した連絡か判断できる材料を残します。

2. 操作・通信・受付・通知の経路を並べる

利用者の送信操作から、ブラウザーの通信、サーバーの受付、通知、自動返信、外部サービスへの登録までを対応させます。独自のJavaScriptとフォームの追加機能が、同じ操作で別々の送信処理を動かしていないかも実装担当が確認します。

これは調査の分類で、すべてのフォームに同じ保存機能や記録があるという説明ではありません。利用中のフォーム、メール配信、連携サービスと独自処理を確認し、調べられない箇所は未確認として残します。

3. 再送を安全だと決めつけず、処理結果を確認する

MDNの冪等性の説明では、POSTなどの方法は、同じ要求を繰り返しても結果が同じになると保証されないことを説明しています。フォームがどの方法を使い、サーバーが再送をどう扱うかは実装で確認します。POSTなら必ず重複する、という断定でもありません。

タイムアウトと、受付失敗を分ける

利用者の画面が待ち状態のままでも、サーバー側では受付が終わっている可能性があります。「完了画面が出ない＝受付されていない」と考えて無条件に再送する設計にしません。処理結果が不明なとき、受付状況を確認する方法と担当を決めます。

自動再試行や外部サービスの再実行がある場合は、同じ受付の識別と処理済みの記録が必要です。通信成功、保存成功、メール配信、担当者の閲覧は別々の結果として確認してください。

4. 送信中・完了・失敗・結果不明の案内を揃える

利用者が何も反応を得られなければ、もう一度押したくなることがあります。送信中であること、操作を待つ理由、完了後の予定、失敗時の修正、結果不明時の確認先を、実際の処理に合わせて案内します。画面上の表示だけで、受付成功を保証しないようにします。

W3Cのステータスメッセージの解説では、処理中や結果の情報を、フォーカスを移さず支援技術へ伝える考え方を説明しています。見た目の色や回転表示だけでなく、状態が言葉で理解できることも確認します。

完了画面、自動返信、実際の受付状況で案内を揃えてください。回答の目安や営業時間は会社の実体制を確認して書きます。文面全体は自動返信メールの作り方へ分け、未確認の返信期限を作りません。

5. ボタンの連打防止と、受付側の重複対策を分ける

送信中にボタンを使えなくする方法は、画面側の対策の一つです。MDNのdisabled属性も参照し、送信ボタンと入力欄への指定を混同しないようにします。必要な入力欄を無効化すると、送る値の扱いにも影響します。

画面の制御だけで、全ての再送を防げるとは考えない

別タブ、再読み込み、通信の再試行、外部連携の再実行は、ボタンの一回の制御だけで同じように止まるとは限りません。サーバーや連携側で、受付の識別、処理済みの確認、同じ要求が来た場合の扱いを設計します。具体的な方法は利用する仕組みに合わせます。

一定時間内の同じ文章を全部拒否する方法も、内容を追加した正式な相談まで止めないかを確認します。重複と判断する条件、既存受付を表示するか、担当者が確認するかを合意します。重複対策のために受付の記録を失わないことが必要です。

6. 試験の条件と通知先を決めてから再現する

可能なら検証環境と合意した試験用データを使います。テストサイトでも本番のメールや外部連携が残っている場合があるため、送信先、受付担当、自動返信、通知、集計からの除外を先に確認してください。実顧客の問い合わせを無断で再送しません。

一回のクリック、Enter、すぐ二回押す、遅い応答、入力エラー後の再送、完了後の再表示などを、対象の実装に合わせて試します。各操作で通信・受付・通知が何件になり、利用者には何が出るかを対応させます。代表の一操作が通った結果と全条件の確認を分けます。

添付ファイルを使う場合は、再送時の資料と保存の扱いも添付フォームの確認表へつなぎます。試験では実際の保存・受信まで確認できた範囲を残し、メールが未確認なら受付検収を完了としません。

7. 原因に合わせて限定修正し、受付担当へ引き継ぐ

一件から通知が二通出るなら通知経路へ、複数の受付が作られるなら要求と受付処理へ、解析だけが重複するなら計測へ、修正対象を分けます。原因が分からないまま全追加機能を止めたり、フォームを別製品へ置き換えたりしないでください。

検収票に、期待する件数と案内を残す

操作条件、期待する受付と通知、実際の結果、利用者の案内、担当者の対応、修正前の状態と戻し方を記録します。変更後は正常な問い合わせも送れるかを確認します。重複を止めた代わりに、必要な受付が欠ける状態は解決ではありません。

本番で同じ受付に再送があった場合の見分け方と、担当者の次の対応を引き継ぎます。受付件数、重複扱い、実相談、受注は別々に集計します。修正直後の問い合わせ増加や利益改善を、確認せず成果としません。

8. Acquaへ、確認できた経路と完成条件を渡す

企業の担当者はWeb制作・運用の案内へ、対象フォーム、困る操作、重複して見える記録、受付担当を伝えられます。認証情報や顧客の本文を初回の相談へ貼り付けず、必要な調査権限と情報の受け渡しを別に決めます。

制作会社は実装支援へ、フォームと独自処理、保存・配信・連携の構成、再送時の仕様、検証環境、合格条件と公開担当を共有してください。必要な調査、限定修正、受付と表示の検収、引継ぎを作業範囲として相談できます。

解決状態は、正常な相談を失わず、再送が合意した扱いになり、利用者が状況を判断でき、担当者が受付と通知を区別して対応できることです。相談窓口には分かる範囲の条件を伝えてください。利用している仕組みを確認せず、完全防止や固定の修正費用を約束しません。