この技術でできること
- アカウント乗っ取りやデータ漏洩を防ぎ、プロダクトの社会的信用（利用継続の前提）を守る
- ソーシャルログインや生体認証（Passkeys：パスワード不要の端末生体認証など）を導入し、「安全だけど面倒なログイン」を「安全で快適な体験」に変える
- クロスサイトスクリプティング（XSS）等の悪意ある攻撃を防ぐことで、ユーザーが安全に文字入力できるUIを保証する
例: 「セッションの有効期限が切れた際、いきなりエラー画面を出して入力内容をすべて消す」のではなく、フロントエンドとバックエンドの認証設計を工夫し、「裏側でこっそりトークンを再発行（リフレッシュトークン）して入力を継続させる」か「ログイン済みの別タブを開かせて状態を復帰させる」ことで、ユーザーの作業喪失体験を防げます。
なぜ難しいか
「セキュリティの高さ」と「ユーザー体験（利便性）の高さ」は、常にトレードオフ（あちらを立てればこちらが立たずの関係）になるからです。
金庫の鍵を複雑にすれば泥棒は入れませんが、持ち主も開けるのが億劫になります。エンジニアは「毎回二要素認証（2FA）をさせたい」「ログアウト時間を短くしたい」と考えますが、デザイナーは「一度ログインしたら顔パスで入れるようにしたい」と考えます。両者のバランスを欠くと、脆弱なシステムになるか、ユーザーが誰も使いたがらない堅苦しいシステムになります。
実装でUXに効くポイント
1. 認証（ログイン）体験の摩擦を減らす
セキュリティの最初の関門であるログイン画面は、最大の離脱ポイントです。
- SNSアカウントログイン（OAuth）や、生体認証（Passkeys/WebAuthn：端末の指紋・顔認証を使う仕組み）を採用し、パスワードの記憶や入力を不要にする設計。
- パスワード入力フィールドでの「非表示 ⇔ 表示」切り替え（目のアイコン）実装による確実な入力補助。
2. XSS対策と文字入力の制限
悪意のあるスクリプト（JSコードなど）をフォームから入力される攻撃（XSS）を防ぐため、エンジニアは入力文字を無害化（サニタイズ）します。
- この影響で、ユーザーが使いたい特定の記号（
<や>など）が意図せず禁止（バリデーションエラー）になったり、表示時にエスケープ文字のまま壊れて表示されたりする問題を防ぐためのUI配慮が必要です。
3. セッション切れからの復帰UI（作業の保護）
もっともUXを損なうのは、「長い文章を書き終えて保存を押した瞬間、『ログインの有効期限が切れました』という無慈悲なシステムエラーが出て全て消える」ことです。
- 入力中のデータをローカル（ブラウザ側）に自動バックアップする実装や、ログイン用モーダルを画面に被せて表示し、ログイン後にそのまま送信させるシームレスな体験設計が求められます。
やりすぎ / 足りなすぎ（トレードオフ）
状況例: 二要素認証（2FA）の導入
Before（悪い例）: 「セキュリティを盤石にする」という理由で、社内用ツールのログイン時に毎回必ず「入力フォーム」＋「スマホのSMSコード入力」を強制する。 結果: 1日に何度もログインする社員の生産性が激減し、「手軽な非公式ツール（シャドーIT）」で情報共有されるようになり、かえってセキュリティリスクが跳ね上がる。
After（現実的な落とし所）: リスクベース認証を採用する。「普段と同じオフィスのIPアドレス・同じPC」からのアクセスなら二要素認証をスキップし、「新しいブラウザ」や「深夜の自宅からのアクセス時」のみSMS認証を要求する。
代替手段への配慮: セキュリティ要件を下げずに利便性を上げるため、システム側で環境（コンテキスト）を判定する機能（見えないセキュリティ）に投資する。
運用で崩れるポイントと衝突（デザイナー × エンジニア）
❌ 「XSSを防ぐため、プロフィール入力欄で記号は一切禁止にします」
デザイナーの視点: 「顔文字 (>_<) を入れたらエラーが出るなんてシステムとしておかしい。文字列なんだからそのまま表示できればUXがいいはずだ」。（品質＝入力の自由度と表現力）
エンジニアの視点: 「< や > のような記号を許可すると、悪意あるユーザーがHTMLタグやスクリプトを埋め込んで他ユーザーを攻撃できる。セキュリティを確保するために入力を根本から弾きたい」。（品質＝システムの絶対的な防御力）
なぜ衝突するか（品質の定義差）: デザイナーは「表示される文字の豊かさ」を求めますが、エンジニアは「データがコードとして実行されるリスクの排除」を最優先するためです。
どう合意するか:
- 入力時点での禁止はユーザーを不快にするため避け、「出力（画面表示）する瞬間に安全な記号に変換（エスケープ）する」という実装方針で合意する。
- ユーザーにとって必要な記号表現と、システムが許容できる文字集合の着地点を探る。
実践チェックリスト
最低ライン（Must）
[ ] パスワード入力時、マスク状態（黒丸）を見える状態に切り替えるトグル（目玉アイコン）をデザインしている [ ] 「パスワードを忘れた場合」の導線がログイン画面のすぐ近くに配置されている [ ] セッション（ログイン保持）が切れた際、なるべくユーザーの直前の操作を失わせない仕組みを議論している
理想ライン（Better）
[ ] 「利便性」と「セキュリティ要件」がぶつかった際、より摩擦の少ない認証手段（生体認証やマジックリンク）を提案できる [ ] エラー表示を設計する際、ハッカーにヒントを与えすぎない（「パスワードが違います」ではなく「メールアドレスまたはパスワードが違います」等にする）配慮ができている
関連技術
前提となる技術
- API設計 — 認証情報（トークンなど）を渡す経路
次に学ぶ技術
- テスト戦略 — セキュリティホールやバグが世に出る前に、自動で仕組みとして防ぐ
まとめ
- この技術の本質: ユーザーの資産（データとプライバシー）を守り、プロダクトの信用を失わないための絶対防壁
- UXへの影響: セキュリティが高すぎると離脱を生み、低すぎると利用自体を放棄される「透明だが巨大な体験要素」
- 実務での判断軸: 「その強固なルール設定は、ユーザーに強いるストレス（摩擦）に見合う価値があるか？」
- 次に学ぶべき技術: テスト戦略（セキュリティリスクや要件漏れを、人力ではなく仕組みで担保する方法）
目的別のおすすめ:
- セッション復帰や体感速度の向上なら → パフォーマンス最適化
- フロントエンドでの「エラー状態」の見せ方なら → 状態管理
- リスクをリリース前に検知する仕組みなら → テスト戦略
