セッション切れのUX：入力途中のフォームへ迷わず戻る設計

フォームの入力途中でセッションが切れたとき、最も必要な案内は「ログアウトしました」だけではありません。入力内容は残っているのか、どう再開するのか、どこへ戻るのかを知る必要があります。再ログインすれば未完成のフォームまで送信される、と誤解させずに、この3点を伝えることが大切です。

ログイン画面の状態と復帰経路も重要ですが、今回はすでに作業中の画面から中断が始まります。サインイン画面と同じ丁寧さで、元の作業へ戻る流れを設計します。

未送信の依頼を、中断から再開まで追う

架空の取引先向け依頼アプリを考えます。業務担当者は依頼SR-208を編集中で、会社名、納品に関するメモ、添付文書を入力しました。依頼はまだ送信していません。このアプリでは、承認済みの下書き保存方針に基づいて内容を保存し、作業を続けるには認証が必要です。

担当者はフォームを確認している途中で離席します。戻ると認証済みセッションが切れていました。望ましい結果は、SR-208を再び開き、保持された下書きを確認して、送信するかどうかを決められることです。ホームページに戻され、記憶を頼りに入力し直すことではありません。

文言も見た目も、下書き保存、セッションの有効期限切れ、依頼送信を分けます。この3つは異なる時点で起こります。下書きを保存しても取引先に送信されたわけではなく、再認証に成功しても依頼が完成したわけではありません。

画面のタイマーが何を示しているか確認する

認証の担当者に、有効期限が切れる条件を確認します。無操作時間の上限、セッション全体の絶対的な有効期間、認証チャレンジの期限は異なります。入力を続けることが一方の条件には影響しても、別の条件には影響しない場合があります。実際の仕様でない限り、何か操作すればログイン状態を維持できると約束しないでください。

OWASPのセッション管理チートシート（英語）は、無操作によるタイムアウトと絶対的なタイムアウトを区別し、サーバー側で制御することを説明しています。カウントダウンはセッションの状態を利用者に伝える表示であり、有効性を決める仕組みそのものではありません。

この違いは複数タブでも重要です。別のタブでセッションが延長されることもあれば、セキュリティ上の出来事によってサーバーが早く終了させることもあります。今のページが案内を実際の状態とどう一致させるかを決めます。古いタイマーが残っているために、サーバーが拒否した後も編集権限があるように表示してはいけません。

すべての製品に共通する正しいタイムアウト時間はありません。適用する方針、延長に対応する場合の方法、再ログインが必要になる条件を記録します。その上で、アプリが実際に実行できる操作に合わせて案内を書きます。

復元を約束する前に、何を残してよいか決める

一部の項目しか保存されていないなら、「作業内容は保存されています」という一括した案内は広すぎます。取引先向け依頼では、何を、いつまで、誰のアカウントに保存し、認証後に何を再入力するかを、項目ごとに決める必要があります。

これは演習用に定めたルールであり、あらゆる製品で全項目を保存するよう勧めるものではありません。下書き自体が機密情報を含む場合もあります。保存先、アクセス、保持期限には、元のフォームと同じ配慮が必要です。復帰させるために、秘密情報や制限された内容を、保護されていないブラウザー内の保存領域へ黙って入れないでください。

まだ操作できるうちに、行動につながる警告を出す

延長に対応するなら、何が起こるかを伝え、「ログインを維持する」のように意味が分かる操作を用意します。反応しなかった場合の結果も説明します。SR-208なら、セッションがまもなく終了することと、保存を確認できた下書きはログイン後に開けることを伝えるのが実態に合います。

すべての警告に同じ安心させる文言を入れるのではなく、最後に確認できた保存状態を使います。最新の納品メモが保存中なら、その不確かさも反映します。延長リクエスト自体が失敗することもあるため、処理中と延長成功を区別します。

WCAG 2.2の達成基準2.2.1「タイミング調整可能」（英語）はレベルAで、時間制限を利用者が調整する方法と例外を定めています。その延長方式を適用する場合は、簡単な操作で延長するために少なくとも20秒を確保し、少なくとも10回延長できる必要があります。この基準を、どの場面でも「20秒のカウントダウンを表示する」というルールに縮めないでください。

操作はキーボードで到達でき、秒数の変化を見続けなくても案内を理解できるようにします。カウントダウンが役立つ人もいますが、毎秒の読み上げは警告を読む妨げになり得ます。ダイアログを使うなら、フォーカスがどう入り、どの操作を選び、延長後にどこへ戻るかを決めます。

「完了」ではなく、見覚えのある下書きに戻す

有効期限が切れた後は、再ログインが必要と伝えます。認証前に復元可能な下書きを示す場合も、その状態で開示してよい範囲に限ります。オーバーレイの背後に機密情報を残したまま、画面を覆えばアクセス制御になると考えないでください。

同じ利用者が再認証に成功し、権限も確認できたら、適切な手順のSR-208を開き直します。「下書き」と保持された値を表示し、添付の完了を確認できなかった場合は、その不足だけを明示します。最後の「依頼を送信」は、利用者が判断して行える操作として残し、自動で再実行しません。

達成基準2.2.5「再認証」（英語）は、再認証後に入力済みデータを失わず作業を続けることを扱います。レベルAAAであり、AAの要件ではありません。この復帰の考え方は参考になりますが、保存と権限確認の仕組みは、プロダクト担当者と開発者が別途定める必要があります。

戻り先も、信頼できるアプリ内の流れの一部として記録します。開発者は任意の外部リダイレクトを受け入れず、戻り先を検証する必要があります。デザイナーが指定するのは、単なる「戻る」ボタンではなく、戻る依頼、手順、作業の文脈です。

Pixsoで中断と復帰の流れを確認する

Pixsoのファイルに、SR-208の4画面を置きます。タイムアウト警告がある編集中の画面、期限切れ、ログイン後の復帰、復元された「下書きの確認」です。認証済みの前後の画面では会社名と納品メモを同じにします。変化させるのはアクセスと作業状態であり、都合よく項目を減らしたフォームにしないでください。

関連する画面をつないで操作の流れを確認します。同僚に依頼を再開してもらい、すでに送信されたかどうかを説明してもらいます。ログイン後の画面が完了画面に見えるなら、成功を示す文言を外し、下書きであることを明確にします。アップロードが完了していなかった添付の分岐も別に作り、標準の流れが未完了の作業を隠さないようにします。

Pixsoで下書きに戻る流れを試作する →

ログインに成功しても、正しく復帰できるとは限らない

別のアカウントでログインした場合、前の利用者の下書きを見せてはいけません。現在のアカウントでは対象の下書きを開けないことを説明し、適切なアカウント切り替えや安全な戻り先を用意します。その説明の中でも、非公開の会社名や添付名を表示しないようにします。

同じアカウントでも、離席中に権限を失った可能性があります。認証は定めた方法で身元を確認することであり、取り消された役割を戻す処理ではありません。権限に関する復帰フローは、この別の境界を扱っています。アクセス権のない人を「もう一度ログインしてください」の繰り返しに閉じ込めないでください。

下書きの保持期限と、セッションの有効期限も区別します。SR-208がすでに保持されていないなら、その事実と可能な次の操作を伝えます。「下書きを復元しました」の下に空のフォームを出してはいけません。

完成画面だけでなく、期限が切れる瞬間を試す

難しいケースは状態の間で起こります。入力中に警告が出る、延長の応答が遅れる、添付が未完了である、送信を押した直後にセッションが切れる、といった場面です。最後のケースでは、再送信を勧める前に最初の処理結果を確認する必要があります。「ログアウトした」ことだけでは、依頼の送信失敗を証明できません。

これらの遷移を、実装とアクセシビリティの担当者と確認します。何が残り、認証前に何が見え、どのアカウントで復元でき、最後の操作が期待した時点だけで実行されるかを確かめます。見栄えのよいタイムアウトダイアログも、戻る流れがその約束を守ってこそ役に立ちます。