「申請フォームを半分書いたところで電話が入って、戻ったら最初からやり直しだった」——会員サイトや社内システムを運用している企業から、こういう不満は驚くほどよく出ます。原因はたいていセッションタイムアウト、つまり一定時間操作がないと自動でログアウトする仕組みです。セキュリティのために入れた機能が、ユーザーの作業を黙って消し、「使いにくいシステム」という評価に直結している。作った側にとっては正しく動いているつもりでも、使う側からすれば理不尽な事故です。
Smashing Magazine の Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design は、このセッションタイムアウトを「見落とされがちなアクセシビリティの壁」と位置づけています。雑に実装されたタイムアウトは単なる技術的な不便ではなく、とくに障害のある人にとって、必要な手続きを途中で断ち切る深刻な障壁になる、という指摘です。受託で認証まわりを設計する立場では、これは「セキュリティと使いやすさのどちらを取るか」ではなく、両立させるための設計の問題だと考えています。
「急にログアウトされた」が起きる仕組み
ログイン状態は無期限ではありません。サーバーはログインごとにセッションを発行し、そこに有効期限を持たせます。一定時間アクセスがなければそのセッションを無効にする——これがタイムアウトです。仕組み自体は正当で、共有 PC で離席したまま放置されたアカウントを乗っ取りから守るために欠かせません。
問題は、その「一定時間」の設計が雑なことにあります。多くのシステムが、何の予告もなく・短すぎる時間で・入力中かどうかも見ずにセッションを切ります。フォームに長文を入力している最中でも、サーバーから見れば「ページ遷移していない＝無操作」と判定され、送信ボタンを押した瞬間に「セッションが切れました。再度ログインしてください」と突き返される。書いた内容は戻ってきません。認証情報の保持の仕方そのものに穴があるケースも多く、その観点は JWT を localStorage に置くな問題（GH Media） でも扱っています。
タイムアウトは「速さ」を前提にしている
ここが本質です。短いタイムアウトは、全員が同じ速さで操作できるという暗黙の前提に立っています。けれど現実はそうではありません。
入力に時間がかかる人がいます。スクリーンリーダーで読み上げを聞きながら一項目ずつ進める人、運動機能の制約でキー入力に時間を要する人、文章を読んで理解するのにゆっくり時間が必要な人。こうした人にとって、5 分・10 分のタイムアウトは操作の遅さそのものを理由に締め出す仕組みになります。これは Web コンテンツアクセシビリティガイドライン（WCAG）の達成基準 2.2.1「調整可能な時間制限」が求めるところでもあり、時間制限を設けるなら延長・解除・事前の十分な猶予を用意することが要件です。多様な利用者を取りこぼさない設計の考え方は 認知特性に配慮したインクルーシブ UX 設計の受託（GH Media） も参考になります。
セキュリティと使いやすさは両立できる
「では、タイムアウトを長くすればいいのか」というと、それは別のリスクを招きます。共有端末で何時間もログイン状態が残れば、乗っ取りの危険が上がります。大事なのは、長くするか短くするかの二択ではなく、場面に応じて設計を分けることです。
| 場面 | 推奨する考え方 |
|---|---|
| 入力途中のフォーム | 入力操作も「活動」とみなし、不用意に切らない |
| 切れる直前 | 予告を出し、ワンクリックで延長できるようにする |
| 強制ログアウト時 | 入力内容を保持し、再ログイン後に復元する |
| 金融・機微情報 | 短めに保ちつつ、延長手段を明示する |
ポイントは、「無操作」の定義を見直すことです。ページ遷移だけを活動とみなすのではなく、フォームへの入力やスクロールも活動として扱えば、「書いている最中に切れる」という最悪のケースは防げます。そのうえで、本当に放置されたセッションだけを安全に切ります。認証方式そのものの刷新を検討するなら パスキー時代の認証刷新の受託（GH Media） も併読してください。
受託でどう設計するか
弊社の受託では、セッションタイムアウトを「とりあえず 30 分」のような決め打ちにせず、業務の性質から逆算します。
まず、扱う情報の機微度でベースの長さを決めます。次に、切れる前の予告を必ず入れます。残り時間が少なくなったら画面上に通知し、「ログインを継続しますか」とワンクリックで延長できるようにする。黙って切るのと、一声かけてから切るのとでは、ユーザーの体験はまったく別物です。
さらに重要なのが、入力内容の保持です。やむを得ずセッションが切れても、書きかけの内容を一時的に保存しておき、再ログイン後に復元できれば、「やり直し」という最悪の事故はなくなります。ある自治体向け申請システムの案件では、長い入力フォームでタイムアウト後にゼロからやり直す苦情が頻発していました。入力の途中保存と、切れる前の延長確認を入れたことで、「途中で消えた」という問い合わせがほぼなくなりました。セキュリティの強度は落とさずに、体験だけを大きく改善できたわけです。
ハマりやすい落とし穴
第一に、予告なしで切ること。技術的には正しくても、ユーザーから見れば理不尽です。最低限、切れる前の一声は必須です。第二に、延長手段を用意せずに時間だけ延ばすこと。長くしてもセキュリティを犠牲にするだけで、根本解決にはなりません。延長・継続の手段とセットにすべきです。第三に、タイムアウトのテストを正常系だけで済ませること。実際の事故は「入力中に切れる」「複数タブで状態がずれる」といった境界で起きるので、そこを意図的に試す必要があります。
まとめ — 「黙って切る」をやめる
セッションタイムアウトは、セキュリティのために必要な仕組みであると同時に、雑に実装すればゆっくり操作する人を締め出し、入力を消し去る障壁にもなります。両者は対立しません。無操作の定義を見直し、切れる前に予告して延長させ、やむを得ず切れても入力を保持する——この三つを設計に組み込むだけで、安全性を保ったまま「気づいたら消えていた」をなくせます。受託では、業務の性質から逆算したセッション設計で、守りと使いやすさを同時に成立させます。
「ログインがすぐ切れると言われる」「申請の途中で内容が消える苦情がある」というご相談は お問い合わせフォーム からお気軽にどうぞ。現状のセッション設計の診断から始められます。
