長いフォームを入力し終えた直前にエラーが出て、最初からやり直しになれば、多くの人は送信をためらいます。入力内容が消えないようにする方法は一つではなく、エラー後に値を再表示するだけでよい場合と、途中保存や後日の再開が必要な場合があります。
短い問い合わせフォームなら、入力エラー後や確認画面から戻った後に値を復元できれば十分です。見積依頼、申請、問診など、資料を確認しながら入力するフォームでは、ブラウザを閉じても続きから再開できる仕組みが求められます。どこまで復元するかを先に決めれば、必要以上に複雑な保存機能を作らずに済みます。
この記事では、入力内容を保持する方法を、 サーバー側での一時保持 データベースへの下書き保存 ブラウザ側での保存 ステップ分割と中間登録 に分け、用途ごとの選び方を解説します。保存期間、再開時の本人確認、複数タブでの上書き、個人情報、添付ファイルなど、公開前に決めておきたい内容も確認できます。
保存先の技術を選ぶ前に、利用者がどの操作をした後まで入力を戻せる必要があるのかを確認します。
入力内容が失われる場面として、次のような操作が考えられます。
送信エラー後の再表示だけであれば、送信された値をサーバー側で受け取り、エラーとともに入力画面へ返す方法で対応できます。ブラウザを閉じた後も残したい場合は、ブラウザ側の保存またはサーバー側の下書き保存が必要です。
別端末からの再開には、入力内容をサーバーへ保存したうえで、ログイン、メール認証、再開用URLなどによって本人を確認する仕組みが必要になります。
全体像 入力内容を保持する主な方法
送信値をセッションや下書きデータとして保存します。エラー時の再表示から、後日の再開まで対応できます。
同じ端末とブラウザに入力内容を保存します。サーバーへ送信する前の内容も保持できますが、保存対象には注意が必要です。
入力を複数画面に分け、各ステップの完了時にサーバーへ保存します。項目数が多い申込や予約に適しています。
同じ画面内の再表示、ブラウザを閉じた後の再開、別端末からの再開では、必要な仕組みが異なります。
必須項目の未入力や形式エラーがあった場合、正しく入力されていた項目まで消してしまう設計は避けるべきです。
サーバー側で入力値を検証する場合は、エラーのある項目と理由を表示しながら、受け取った入力値を同じ画面へ再表示します。
文字入力欄だけでなく、ラジオボタン、チェックボックス、プルダウン、日付、複数選択項目も復元対象です。一部の項目だけが初期状態へ戻ると、利用者が変更に気付かないまま送信する可能性があります。
ブラウザのセキュリティ上、ファイル選択欄へ以前選んだファイルを自動で再設定することはできません。そのため、エラー後に画面を再表示すると、添付ファイルだけは選び直しが必要になることがあります。
大きなファイルを扱うフォームや入力項目が多いフォームでは、ファイルを先に一時アップロードし、発行された一時ファイルIDをフォームへ紐付ける方法があります。
この場合は、未送信の一時ファイルをいつ削除するか、他の利用者から参照されないか、実行可能なファイルを受け付けないかなども確認します。
サーバー側のセッションへ入力内容を保存する方法は、確認画面から戻る処理や、複数ページに分かれたフォームでよく使われます。
一般的には、ブラウザ側にはセッションを識別するためのIDだけをCookieとして保存し、実際の入力値はサーバー側で管理します。
実装しやすい方法ですが、セッションには有効期限があります。一定時間操作しなかった場合やブラウザを閉じた場合、サーバーの設定によっては入力内容を復元できません。
「翌日も再開できる」と案内する場合、一般的なセッション保持だけでは要件を満たさない可能性があります。保存期間を明確にした下書き保存を検討します。
同じフォームを複数のタブで開くと、両方の画面が同じセッションデータを更新することがあります。後から保存したタブの内容で、先に入力していた内容が上書きされる可能性があります。
複数の見積依頼を同時に作成する業務フォームでは、セッション全体にひとつの入力値を保存するのではなく、フォームごとに識別IDを発行し、別の下書きとして管理する方法が適しています。
入力を翌日以降に再開する、PCとスマートフォンを切り替える、複数人で内容を確認するといった要件がある場合は、入力内容を下書きデータとしてサーバーへ保存します。
BtoBの見積依頼、補助金申請、会員登録、物件問い合わせなど、入力時に社内確認や資料準備が必要になるフォームでは、途中保存によって作業を中断できるようになります。
たとえば、不動産向けシステムの物件相談フォームで、希望条件や売却物件の情報を複数入力する場合、下書き保存があれば必要な資料を確認してから入力を再開できます。
UI例 サーバー側の下書き保存
保存日時と期限を表示し、利用者が保存できたことを確認できるようにします。
下書き保存には、利用者がボタンを押して保存する方法と、入力中に自動保存する方法があります。
自動保存では、文字を入力するたびに通信するのではなく、入力が止まってから一定時間後に保存するなど、通信回数を抑える処理が一般的です。
画面上には、現在の状態と最後に保存できた時刻を表示します。実際には保存に失敗しているのに「自動保存されます」とだけ表示すると、利用者は保存できていると思って画面を閉じてしまいます。
重要なフォームでは、自動保存に加えて「下書きを保存」ボタンも用意し、利用者が明示的に保存できるようにする方法があります。
メールで再開URLを送る場合、連番の下書きIDをURLへそのまま掲載すると、別の番号へ変更することで他人の下書きへアクセスできる危険があります。
再開URLには十分に推測しにくい識別情報を使用し、有効期限、利用回数、本人確認の方法を決めます。
どの方法が必要かは、保存する情報の内容によって異なります。一般的な問い合わせ内容と、契約情報、医療情報、本人確認書類を含む申請では、同じ認証方法が適切とは限りません。
同じ下書きをPCとスマートフォンで同時に開いた場合、後から保存した内容が先の変更を上書きする可能性があります。
更新日時や版番号を使って、古い画面からの保存を検知し、「別の画面で更新されています」と表示する方法があります。複数人で編集する業務フォームでは、編集中の担当者や最終更新者を表示することも検討します。
サーバーへ送信する前の入力内容を、ブラウザ内へ保存する方法もあります。代表的な保存先はsessionStorageとlocalStorageです。
sessionStorageは、ページを再読み込みした場合や同じタブ内で画面を移動した場合の復元に利用できます。localStorageは、ブラウザを閉じた後でも同じ端末とブラウザで内容を復元できます。
学校向けシステムの説明会申込やエントリーフォームなど、個人の端末から入力することが多く、別端末での再開を必要としない場合には選択肢になります。
UI例 ブラウザに残っている入力内容の復元
自動的に表示するのではなく、保存日時を示したうえで復元するか選べる方法もあります。
localStorageに保存したデータは、同じブラウザを利用できる人から見られる可能性があります。共有PCや店舗端末では、前の利用者の入力内容が次の利用者に表示されることも考えられます。
また、Webサイトにスクリプトを挿入される脆弱性がある場合、localStorageの内容を読み取られる可能性があります。
次のような情報は、必要性と保護方法を確認せずにブラウザへ保存すべきではありません。
氏名や連絡先についても、フォームの目的、利用環境、保存期間を踏まえて保存の可否を判断します。保存する場合は、「この端末に入力内容を保存する」ことを画面上で説明し、利用者が削除できる方法を用意します。
localStorage自体には、自動的に期限切れとなる仕組みがありません。そのため、保存日時や期限をデータと一緒に記録し、期限を過ぎた内容は読み込まずに削除する処理が必要です。
フォームの項目を変更した後に古い保存データを復元すると、項目の意味や選択肢が合わなくなる場合もあります。保存データにはフォームの版情報を持たせ、互換性がない場合は復元しない方法があります。
フォームを正式に送信した後もブラウザ内に入力内容が残っていると、次回アクセス時に送信済みの内容が表示されることがあります。
送信完了を確認した後、該当フォームの保存データを削除します。ただし、通信エラーによって送信が完了していない状態で削除しないよう、サーバー側の受付完了を確認してから処理します。
入力項目が多いフォームでは、ひとつの画面にすべての項目を並べるよりも、内容ごとにステップを分けた方が入力しやすい場合があります。
ステップの完了時に内容をサーバーへ保存すれば、後半の入力中に画面を閉じても、前のステップから再開できます。
予約、葬祭相談、医療機関の事前問診、法人向けの見積依頼など、入力項目が多いフォームに適しています。葬祭向けシステム開発例のように、相談者がすぐに回答できない項目を含む場合にも利用できます。
フロー ステップ分割と中間登録
仮登録と正式送信を別の状態にし、未完成の内容が通常の問い合わせとして処理されないようにします。
途中保存されたデータを、正式な問い合わせや申込と同じ一覧へ表示すると、対応担当者が連絡してよい案件なのか判断できません。
データの状態を分けて管理します。
下書き段階で連絡先が保存されていても、利用目的を明示せず、正式送信前の利用者へ営業連絡を行うことが適切とは限りません。途中データをどの業務に利用するのかは、画面上の説明や同意内容と一致させる必要があります。
ステップ数を増やせば入力しやすくなるとは限りません。短い項目を細かく分けすぎると、画面移動が増え、入力全体の見通しが悪くなります。
会社情報、相談内容、添付資料、確認といった意味のまとまりで分け、現在位置と残りのステップが分かるようにします。
入力保持の方式は、開発のしやすさだけでなく、どこまで復元する必要があるか、どのような情報を保存するかを基準に選びます。
比較 入力保持方式の違い
| 方式 | 主な復元範囲 | 適した用途 | 確認が必要な点 |
|---|---|---|---|
| エラー時の再表示 | 送信後、同じ画面を再表示 | ほぼすべてのフォーム | 選択項目や添付ファイルの扱い |
| セッション保持 | 同じブラウザでの短時間の継続 | 確認画面、複数ページのフォーム | 有効期限、複数タブ、ブラウザ終了時の動作 |
| 下書き保存 | 後日または別端末から再開 | 見積、申請、長い申込フォーム | 本人確認、保存期間、上書き競合 |
| ブラウザ保存 | 同じ端末と同じブラウザ | 個人端末から利用する一般的なフォーム | 共有端末、機密情報、期限、送信後の削除 |
| ステップ分割＋中間登録 | 完了したステップから再開 | 項目数が多い予約、相談、申請 | 仮登録の状態、利用目的、期限切れデータ |
複数の方式を組み合わせることもできます。たとえば、エラー時の再表示に加え、ログイン利用者だけ下書き保存を提供する方法があります。
自動保存機能があっても、利用者から見て保存状態が分からなければ、安心して画面を閉じることはできません。
画面には、次のような状態を明確に表示します。
保存に失敗した場合は、再試行できるボタンや、入力内容を別の場所へ控えるための案内を表示します。
画面を閉じる直前に未保存の変更がある場合は、ブラウザの確認表示を利用できることもあります。ただし、すべてのブラウザや操作で必ず表示できるわけではないため、これだけに依存した設計にはできません。
下書きに保存された値が、そのまま現在も有効とは限りません。商品、料金、予約枠、選択肢などは、保存後に変更されている可能性があります。復元した内容も正式送信時にサーバー側で検証し、利用できなくなった項目は再選択を求めます。
同じ下書きを複数端末で開ける場合は、更新日時や版番号を確認し、古い画面から新しい内容を上書きしない処理も必要です。入力を再表示できることと、現在の条件で受け付けられることは別に判定します。
入力保持機能を追加すると、正式送信前の個人情報も保存対象になります。保存方法を決める際は、利便性だけでなく、情報管理の条件も確認します。
確認 利便性と情報管理の両面で確認する
フォームの種類によって、保存できる情報と必要な本人確認の強さは異なります。
すべての入力項目を同じ方法で保存する必要はありません。住所や相談内容は下書き対象とし、パスワードや決済情報は保存しないなど、項目ごとに扱いを分けます。
ブラウザ保存は一般情報だけに限定し、機密性の高い項目はサーバー側で認証後に保存する構成も考えられます。
未送信の下書きを期限なしで保存すると、利用されない個人情報が残り続けます。フォームの利用目的に応じて、7日、30日、90日などの期限を決め、期限後に削除または匿名化します。
利用者には、保存完了時や下書き一覧で保存期限を表示します。期限が近い場合にメールで案内する場合は、その通知についても事前に説明します。
サーバー側へ入力内容を保存する場合は、HTTPSによる通信、閲覧権限、管理画面の認証、操作履歴、バックアップなども確認します。
保存データを暗号化する必要があるかは、情報の種類、利用している基盤、社内規程などによって判断します。暗号化していることだけで安全になるわけではなく、誰が復号して閲覧できるか、鍵をどのように管理するかも必要な検討事項です。
入力保持機能を実装する前に、少なくとも次の内容を確定します。
これらが決まっていないと、「入力内容を保持する」という同じ要望でも、実装後に期待していた動作との違いが生じます。
特に、セッションが切れた後も復元できるのか、再開URLを転送された場合に誰でも見られるのか、下書きが管理画面へ表示されるのかは、利用者と運用担当者の双方に影響する仕様です。
通常の入力と送信だけでなく、途中で操作を中断した場合も確認します。
スマートフォンでは、アプリの切り替え、着信、画面ロック、通信回線の変更なども発生します。実際の利用環境に近い条件で確認する必要があります。
対応できます。ただし、ブラウザ任せの表示にするのではなく、確認画面から戻る処理と、履歴から戻る操作の両方で値が復元されるかを確認します。フォームの送信方法やキャッシュ設定によって動作が変わるため、実際の画面での検証が必要です。
sessionStorageは原則としてタブ単位の一時保存に向き、タブを閉じた後の再開には使えません。localStorageは同じサイトとブラウザにデータを残せますが、利用者による削除、プライベートブラウズ、端末変更には対応できません。どちらもサーバー側の下書き保存とは用途が異なります。
同じ端末だけでよければ、ブラウザ内へ保存する方法があります。別端末からも再開させる場合は、推測されにくい期限付きURLと追加確認を組み合わせる方法などがあります。扱う情報の機密性によっては、ログインを必須にする方が適切です。
通常の文字項目と同じ方法では復元できません。サーバーへ一時アップロードする場合は、ファイルの閲覧権限、保存期限、ウイルス検査、正式送信されなかったファイルの削除まで設計します。ファイルを保存しない場合は、再選択が必要なことを画面へ表示します。
一律には判断できません。共有端末で別の利用者に見られる可能性、保存期間を自動管理しにくいこと、ブラウザ上のスクリプトから参照されることを考慮する必要があります。氏名や連絡先、健康情報、申請情報などを扱う場合は、保存項目を限定するか、本人確認を伴うサーバー側保存を検討します。
フォームの入力内容を保持する方法は、どこまで再開できる必要があるかで決まります。入力エラー後の再表示には送信値の復元、確認画面や短時間の画面移動にはセッション、翌日や別端末からの再開にはサーバー側の下書き保存が候補になります。
同じ端末とブラウザでの再開にはsessionStorageやlocalStorageも利用できますが、共有端末、保存する情報、保存期限、正式送信後の削除を先に決める必要があります。パスワード、決済情報、医療情報などを安易にブラウザへ保存すべきではありません。
項目数が多いフォームでは、ステップ分割と中間登録も有効です。その場合は、下書きと正式送信を別の状態として扱い、未完成のデータを通常の問い合わせとして処理しないようにします。保存方法だけでなく、保存状態の表示、本人確認、期限切れ後の削除まで含めて決めることで、実際の利用場面に合った入力保持機能になります。