問い合わせフォームや見積依頼フォームで時間をかけて入力した後、送信エラーや通信切断によって内容が消えてしまうと、利用者は最初から入力し直さなければなりません。項目数が多いフォームでは、そのまま送信を断念される可能性もあります。
入力内容が消える場面は、送信エラーだけではありません。入力中に別のページへ移動する、ブラウザを閉じる、一定時間操作せずセッションが切れる、スマートフォンで着信を受けて画面から離れるなど、さまざまな状況が考えられます。
必要な対策は、どの状況から入力を再開させたいかによって異なります。エラー画面から戻すだけでよいフォームと、翌日に別の端末から続きを入力できるようにしたいフォームでは、保存方法も本人確認の方法も同じではありません。
この記事では、フォームの入力内容を保持する代表的な方法を、 サーバー側での一時保持 データベースへの下書き保存 ブラウザ側での保存 ステップ分割と中間登録 に分けて解説します。保存期間、複数タブ、再開URL、個人情報、ファイル添付など、実装前に確認したい点も取り上げます。
入力保持の仕様を決める際は、保存方法より先に、どの場面で入力を復元する必要があるのかを確認します。
「入力内容を残したい」という要望には、少なくとも次のような異なる状況が含まれます。
送信エラー後の再表示だけであれば、送信された値をサーバー側で受け取り、エラーとともに入力画面へ返す方法で対応できます。ブラウザを閉じた後も残したい場合は、ブラウザ側の保存またはサーバー側の下書き保存が必要です。
別端末からの再開には、入力内容をサーバーへ保存したうえで、ログイン、メール認証、再開用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も利用できます。ただし、共有端末、機密情報、保存期限、送信後の削除について確認が必要です。
項目数が多いフォームでは、入力保持だけを追加するのではなく、ステップ分割と中間登録によって入力を複数回に分ける方法もあります。この場合は、下書きと正式送信を区別し、未完成のデータを通常の問い合わせと同じように扱わない設計が必要です。
実装を検討する際は、 エラー時の再表示 ブラウザを閉じた後の再開 後日・別端末からの再開 のどこまで必要なのかを最初に決めます。そのうえで、保存対象、保存期限、本人確認、削除条件をフォームの用途に合わせて選ぶことが重要です。