長めの問い合わせフォームや見積フォームでは、入力途中で画面を閉じてしまったり、送信前のエラーで内容が消えたりしたときに、不満が一気に強くなります。 入力項目が多いほど、この体験はそのまま離脱理由になりやすくなります。
とくに、BtoBの見積相談、学校のエントリー、予約フォームのように、入力に数分以上かかる画面では、「一度止めても戻れること」がかなり重要です。 送信完了まで一気に進んでもらう設計だけではなく、途中で中断しても致命傷になりにくい作りが求められます。
ここでは、入力内容を保持する代表的な実装パターンを、 サーバー側の一時保存 ブラウザ側の保持 ステップ分割＋中間送信 の3系統に分けて見ていきます。あわせて、UXとセキュリティの両立をどう考えるかも整理します。
入力保持の仕組みは細かく分けるといろいろありますが、考え方としてはかなり単純です。 保持先は、大きく分けると次の3つです。
どれが正解というより、フォームの性質によって向き不向きが変わります。 まずは「同じ端末での復元ができれば十分なのか」「別端末からの再開も必要なのか」「個人情報をどこまで持ってよいのか」を見ていく方が判断しやすくなります。
全体像 入力保持の考え方を3つに分ける
セッションや下書きとしてサーバーへ保存し、再表示時に復元します。別端末や再訪問にも対応しやすい方式です。
同じ端末・同じブラウザの中だけで入力内容を残します。実装は軽めですが、利用環境の影響を受けやすい方式です。
1ページ目や途中ステップの時点で登録を進め、後半は追記にします。長いフォームや予約導線と相性がよい構成です。
どこに保存するかで、復元できる範囲とセキュリティ上の注意点が変わります。
もっとも基本的なのは、サーバー側で入力内容を一時保存し、再表示時に復元する方法です。 エラー時の再表示だけならセッションで足りることもありますし、途中保存や後日再開まで考えるなら下書き保存の方が向いています。
BtoBの見積フォームや、不動産向け の物件問い合わせフォームのように、 入力項目が多く、すぐには送信しないケースでは、この方式がかなり使いやすくなります。 途中まで書いた内容を、あとであらためて開けるようにしておくと、入力負担の印象が大きく変わります。
UI例 サーバー側の下書き保存イメージ
別端末や後日再開まで考えるなら、サーバー側で持つ方が扱いやすくなります。
一方で、サーバー側で持つ以上、保存期間、保存対象項目、途中データの削除条件は決めておく必要があります。 「とりあえず全部残す」だと、運用側で扱いにくくなることもあります。
もう一つの方法は、ブラウザ側で入力内容を保持することです。 代表的には localStorage などを使い、同じ端末・同じブラウザの中でだけ前回入力を復元します。
この方式は、学校向け のエントリーフォームや、説明会申込フォームなど、 個人の端末からの利用が中心で、しかも同じブラウザで再開される前提が強い場面では使いやすくなります。
UI例 ブラウザ保存からの復元確認
実装は比較的軽めですが、共有端末やブラウザ変更には対応しにくい方式です。
ただし、この方法は共有端末や端末乗り換えが前提の業務フォームにはあまり向いていません。 また、個人情報を長くブラウザに残すことへの配慮も必要です。
フォームが長い場合は、入力保持そのものより、途中である程度登録してしまう設計の方が合うことがあります。 ステップ1完了時点で最低限の情報をサーバーへ送っておき、その後のステップは追記する形です。
ホテル・葬祭・医療など、葬祭向けシステム開発例 に見られるような、 事前情報が多い予約・相談フォームでは、この考え方がかなり実務的です。 途中まででも情報があれば、必要に応じてフォロー連絡が可能になることもあります。
フロー ステップ分割＋中間送信のイメージ
入力保持のためだけでなく、長いフォーム自体の負担を分散する意味でも有効です。
ただし、この方式では「どの時点で正式登録とみなすか」を決めておく必要があります。 仮受付のまま残るデータをどう扱うかも、先に決めておいた方が安全です。
実装方式は、技術の好みで選ぶより、「どこまで復元できれば十分か」で選ぶ方が判断しやすくなります。
比較 代表的な方式の違い
| 方式 | 復元できる範囲 | 向いているケース | 注意点 |
|---|---|---|---|
| セッション保持 | 同一セッション中の再表示 | 送信エラー後の再表示、短時間の離脱 | ブラウザを閉じると消えることが多い |
| 下書き保存 | 後日・別端末も含めて再開可能 | 見積相談、長い申込フォーム | 保存期間や削除条件の設計が必要 |
| ブラウザ保存 | 同じ端末・同じブラウザ | 個人端末中心のフォーム | 共有端末や端末変更に弱い |
| ステップ分割＋中間送信 | 途中段階から継続可能 | 長大な予約・相談・申込フォーム | 仮登録データの扱いを決める必要がある |
「エラー時の再表示だけでよい」のか、「翌日も続きから始めたい」のかで、必要な方式は変わります。
入力保持は便利ですが、保存する内容が個人情報を含む以上、UXだけで決めるわけにはいきません。 どこに、どのくらいの期間、何を残すかはかなり重要です。
確認 UXとセキュリティの両方を見る
便利さだけで決めると、あとから運用側で困ることがあります。保存対象と保存期間は先に決めておく方が安全です。
業種によって許容度はかなり違います。 一般的な問い合わせフォームと、医療・教育・士業などでは、扱う情報の重さが変わるため、社内ルールに合わせた判断が必要です。
実装に入る前に、少なくとも次の点は決めておいた方が後戻りしにくくなります。
ここが曖昧なまま実装を始めると、あとから「思ったより個人情報を持ちすぎている」「再開はできるが運用が煩雑」といった問題が出やすくなります。
入力内容を保持する仕組みは、「どの程度の期間・精度で復元したいか」と「どのくらいの個人情報を扱うか」で最適な方式が変わります。 送信エラー後の再表示だけならセッションで十分なこともありますし、長いフォームや再開ニーズがあるなら下書き保存やステップ分割の方が向いています。
一方で、便利さを優先しすぎると、保存範囲や保存期間が重くなりがちです。 サーバー側の一時保存、ブラウザ側のローカル保存、ステップ分割＋中間送信を使い分けながら、フォームの長さ、利用環境、社内のセキュリティ方針に合った形を選ぶことが大切です。
「入力途中で消えてしまうのがつらい」という不満に対応したい場合は、まず エラー時の再表示 途中保存 後日再開 のどこまで必要なのかを切り分けるところから始めると判断しやすくなります。