LIFFフォームの二重送信を防ぐ｜再読み込みと受付番号の設計

LIFFで開いたフォームの二重送信は、送信ボタンを一度押したら無効にするだけでは防ぎきれません。通信が途切れたり、画面を開き直したりしたときに、サーバーで受付が済んでいる可能性があるためです。同じ申請を再送しても受付が増えず、本人が結果を確認できる仕組みを用意します。

ここでいうLIFFは、LINEと連携するWebアプリを作るための仕組みです。受付の重複防止や申請の状態管理が、自動的に備わるという意味ではありません。この記事の受付設計は、開発するサービス側で実装・検証する内容です。

応答が来ないことと、受け付けていないことを分ける

フォームの送信では、サーバーが申請を保存した後、成功の応答だけがスマートフォンへ届かないことがあります。このとき画面に「失敗しました。もう一度送信してください」とだけ表示すると、同じ予約や問い合わせが増える原因になります。

利用者に見せる状態は、少なくとも次のように分けます。

これは画面設計の例です。成功か失敗かを判断できない時間があることを、利用者へ分かる言葉で伝えます。何度も同じ内容を入力してもらう前に、保存した申請を見に行けることが大切です。

二重受付を防ぐには、本人の識別と、一回の申請の識別を分けます。同じ人が別の日に同じ商品を申し込むことはあり得るので、「同じ人・同じ本文」という条件だけで、すべての申請を重複として捨ててはいけません。

開発上の方法として、一回の申請に推測しにくい識別子を割り当て、通信上の再送では同じ識別子を使います。サーバーは本人と申請識別子の組を確認し、すでに受付済みなら同じ受付結果を返します。新しい申請を始める場合は、別の識別子にします。

同じ申請を重複受付しない設計例。申請を識別する番号を用意し、サーバーで本人と受付状態を確認する。受付済みなら同じ結果を返し、画面を開き直したら本人確認後に結果を照会する。

図：サービス側で実装する設計例です。LIFFの標準機能が申請を保存・重複排除するわけではありません。受付結果が不明な間は、新しい申請として送り直さない流れにします。

「最初に検索して、なければ保存する」だけでは、同時に二つの処理が走ったときに両方が保存されることがあります。保存先でも一意の制約やトランザクションを使い、受付の保存と重複判定が競合しないようにします。処理途中と受付完了の扱い、識別子の保持期間も業務に合わせて決めます。

受付番号を知っているだけで、誰でも申請内容を見られる設計にはしません。LIFFからサーバーへ送る表示名や、ブラウザーが自己申告したユーザーIDだけで本人を決めることも避けます。

LINEの公式資料では、サーバーでユーザー情報を使う場合、IDトークンやアクセストークンを送って検証する方法が案内されています。ブラウザーで取得したプロフィールの詳細を、そのままサーバーの本人確認に使わないことが前提です。

申請識別子は、本人確認の代わりになる秘密の鍵として扱わず、本人と申請を照合するために使います。トークン、申請内容、個人情報をURLやアクセス解析へ混ぜないようにします。LIFFの初期化とURLの扱いは、公式の開発手順も確認してください。

公開前は、架空の申請データで次の挙動を確認します。実際の予約や課金が発生するサービスでは、承認されたテスト環境・範囲を使ってください。

お客さんの操作画面を減らすには、入力画面を短くするだけでなく、結果が分からないときの行き先も決める必要があります。まずは「送信した直後に通信が切れたら、本人はどこで受付済みかを確認するか」を、画面とサーバーの両方で答えられる状態にしてください。

LIFFそのものの位置付けはLINEミニアプリとLIFFの違い、顧客IDのつなぎ方はLINEのID連携を参照してください。

一次資料確認：2026年10月7日。受付設計・テスト項目は編集上の提案であり、特定の製品の実装済み機能や導入成果ではありません。