ux-login-signup

ログイン・サインアップ画面スキル

このスキルの動作（最初にお読みください）

これは生成型のスキルであるため、すべてのベストプラクティスを盲目的に適用するわけではありません。ログイン・サインアップにはコンテキスト依存の調整項目（ソーシャルログイン、「ログイン状態を保持」、ユーザー名かメールアドレスか、2FA）があり、すべてを適用することが一部のプロダクトでは誤りで、別のプロダクトでは正しいということが起こります。それらすべてを自動適用すると、肥大化し、安全でなく、プライバシーに配慮しない画面が出来上がってしまいます。

そこで、このスキルは次の3つの手順で動作します。

1. コンテキストを確立する（まだ判明していない場合は、簡単な質問を1つ行います）。
2. 常に正しいコアを適用する — 実質的にすべての認証画面で正しいパターンです。
3. コンテキスト依存の判断事項を、トレードオフと推奨案とともに提示し、ユーザーに選ばせます — 黙って選んではいけません。

その後、検証のために結果を監査スキルに引き渡します。生成された画面に対して、ヒューリスティック監査（ux-heuristics-audit）とアクセシビリティ監査（ux-accessibility-audit）を呼び出します。このスキルは、コントラスト・キーボード・スクリーンリーダーのルールを意図的に再導出しません — それはアクセシビリティスキルの役割です。

---

ステップ 0 — 設計前にコンテキストを確立する

認証の設計は、以下の項目によって大きく変わります。それらが判明していない場合は、質問してください。

• プラットフォーム — モバイル（水平方向のスペースが狭い → 上部揃えまたはフローティングラベル、文脈に応じたキーパッド、38px 以上のタッチターゲット）か、デスクトップか。
• セキュリティの重要性 — カジュアルなコンシューマーアプリか、銀行・医療・エンタープライズか。これが以下のゲート判断において最大の要因となります。
• 対象ユーザー — 一般的なコンシューマー（ソーシャルログインを推奨、摩擦を低減）か、セキュリティを重視するユーザーや規制対象のユーザーか。

回答を得ずに進める場合は、前提を明示してください（例:「Web 上の標準的なコンシューマー向け SaaS を想定」）。

---

常に適用すべきコア（ほぼすべての認証画面で正しい）

構造

• ログインとサインアップを分離し、それぞれ別のページ／ビューにします。統合しないでください — ユーザーは間違った方を試して、いらいらしてしまいます。
• 切り替えをわかりやすく: 明確なタイトルでどのページにいるかを示し、「アカウントをお持ちでない方はこちら: サインアップ」（またはその逆）のリンクを、ユーザーが見る入力欄の上に配置します。ソーシャルボタンは両方のページに表示します。
• サインアップは1つの短い画面に収めます。 必須事項（識別子＋パスワード）だけを尋ねます。それ以外はすべて後で、文脈に応じて、ユーザーが価値を体験した後に収集します。

CTA

• 視覚的に区別できるラベル。 「Sign in」／「Sign up」の紛らわしさは避けましょう — 「ログイン」 対 「サインアップ」 または 「登録」 を推奨します。
• ボタンの階層: 主アクションにはブランド／プライマリカラーと太さを与え、副アクションは控えめにするかテキストボタンにします。1画面につき主導的なアクションは1つです。
• CTAはスクロールせずに見えるようにし、長いモバイルフォームでは下部に固定します。

パスワードフィールド

• 表示／非表示の切り替え（目のアイコン）は双方向に機能させます — タイプミス防止、特にモバイルで重要です。これにより「パスワード確認」フィールドを省略できます。
• パスワード要件は入力中に表示（リアルタイムのチェックリスト）し、エラー時だけ表示するのは避けます。

パスワードの復旧（最も離脱が多い経路 — リンクだけでなくフロー全体を設計します）

1. パスワードフィールドの下にリセットリンクを、ユーザーが期待する位置に、明確なラベルで配置します（これは「緊急脱出口」です — ニールセンの「ユーザーの制御と自由」）。
2. 本人確認のために1〜2項目だけ（メールまたは電話番号）を尋ねます。
3. 次に何が起こるかをユーザーに伝える確認ページ（「受信トレイをご確認ください」）。
4. メール／SMS内の明確な次のステップの手順 — 目立つリンクまたはコード、最小限のテキスト。
5. 新しいパスワードの入力欄と要件を表示したリセットページ。
6. 成功の確認、その後ログイン（または本来の目的のページ）へリダイレクトします。

バリデーションと送信状態

• インラインバリデーションを各フィールドから離れるときに実行します — 送信するまで待ってすべてのエラーを表示するのは避けます。結果はフィールドの隣に表示し、成功は緑のチェック、失敗は赤で示します。
• 送信時にはローディング状態を表示し、その後成功メッセージまたは明確なエラーを表示します。
• エラー時のセキュリティ上の注意: どちらが間違っているかを明かさず、一般的な「ユーザー名またはパスワードが正しくありません」を使用します。
• エラーの文言は簡潔で、丁寧で、具体的に — 何が問題で＋どう修正するか。専門用語なし、全大文字なし、責める表現なし。

フォームの仕組み（モバイルに配慮）

• 上部揃えまたはフローティングラベル — プレースホルダーのみは避けます（プレースホルダーはフォーカス時に消え、思い出すことを強います）。
• 必要なフィールドの下にヘルパーテキスト（例: 電話番号が必要な理由）。
• 文脈に応じたキーパッド（電話番号／コード用の数値パッド）と、書式付きデータ用の入力マスク。
• タッチターゲットは約38px以上、入力欄は高さ32〜40px、プライマリボタンの幅はバランスを取るため入力欄に合わせます。

---

状況依存の判断（表に出す。自動適用しない）

それぞれについて、トレードオフとステップ0の状況に結び付いた推奨を提示し、ユーザーに決めてもらいます。これらすべてをデフォルトで適用するのは誤りです。

判断	適用する場合	避ける／適応させる場合	デフォルトの推奨
ソーシャルログイン（Google/Apple など）	主流のコンシューマー向けアプリ — ユーザーの約80%が好み、摩擦を減らし、メール確認も代行してくれる	プライバシーに敏感な対象、エンタープライズ SSO の文脈、データ管理が必要な場合	コンシューマー向けアプリには提供する。メールの選択肢も併せて用意する。追加する前に確認する。
識別子：メール／電話番号 vs. ユーザー名	ソーシャルアイデンティティやハンドルが製品にとって重要ならユーザー名のみ	ユーザー名を必須にする — 思い出しにくく、ログイン失敗が増える	デフォルトはメールまたは電話番号。ユーザー名はオプションとしてのみ提供する
「ログイン状態を保持」／「ログイン情報を記憶」	再入力が煩わしい低リスクのアプリ	バンキング／ヘルスケア／エンタープライズ — 一定時間で自動ログアウト。記憶するのはユーザー名のみで、セッションは記憶しない	機微度に依存 — これがステップ0が重要な理由です
2FA／生体認証	高リスクまたは規制対象のデータ。モバイルでの素早く安全なログインには生体認証	不要な摩擦を加えるだけのカジュアルで低リスクなアプリ	機微なデータには推奨。それ以外ではオプション
単一画面 vs. 段階的なプロファイリング	ほぼ常に最小限から始める	—	今は最小限にして、後で状況に応じてより多くを尋ねる

製品が高セキュリティ（バンキング、ヘルスケア）の場合、利便性のレバー（ログイン状態の保持、ソーシャル）は安全な選択へと傾き、2FA／生体認証はオプションではなく推奨になります。

---

結果を検証する（オーケストレーション）

引き継ぎでは、各レンズをインストール可能なスキルの name で示します。そのスキルがインストールされている場合のみ呼び出してください。インストールされていない場合でも、このスキル自体の中核がすでにこれらのルールを備えているため、ブロックせずにそのまま進めてください。

生成または修正した後は、完了と宣言するのではなく、結果を監査レンズに引き継ぎます。これらは候補のレンズです — 姿勢は docs/orchestration-policy.md で設定するか、すべてを ux-design-review 経由でルーティングします。ここでは、heuristics と dark-patterns が Tier A（自動実行）、accessibility と aesthetics が Tier B（提案） です — 既存のデザインシステムがある場合、aesthetics は抑制され、accessibility は用途に絞られます。ユーザーが特定の目的でこのスキルを呼び出した場合は、その範囲を尊重してください。

• ux-heuristics-audit (Tier A) — 送信時のフィードバック／ステータス、エラー回復、一貫性、認識（例：目に見えるパスワード要件）を確認します。
• ux-accessibility-audit (Tier B — 提案。デザインシステムがある場合は絞る) — ラベル／コントラスト／キーボード／フォーカスの詳細で、このスキルが意図的に先送りするものです。
• ux-aesthetics-audit (Tier B — 提案。デザインシステムがある場合は抑制) — 視覚的階層と過剰デザインのチェック：ゲートされたレバー（ソーシャルボタン、2FA、パスワードルール）が画面を散らかしたり、主要なアクションを埋もれさせたりしていないか？
• ux-dark-patterns-audit (Tier A) — サインアップがマーケティングのオプトイン、強制的なソーシャル連携、過度に広範な権限を追加する場合：事前選択、強制アクション、確認の強要（confirmshaming）をチェックします。

監査で衝突が表面化した場合（例：ソーシャルログイン、「ログイン情報を記憶」、2FA プロンプト、さらに長いパスワードポリシーを追加して、ミニマリズムが損なわれた）、主要タスクである「ユーザーをログインさせること」に向けて解決します。

---

よくある do/don't パターン

❌ しない	✅ する
ログインとサインアップを1つの曖昧なフォームにまとめる	明確なタイトルとフォーム上部の切り替えリンクを備えた別々のページにする
「Sign in」の隣に「Sign up」	「ログイン」と「サインアップ」/「登録」— 視覚的に区別する
サインアップ時に多くの項目を求める	識別子 + パスワードのみ。残りは後で文脈に応じて収集する
プレースホルダーだけのフィールド	上部揃えまたはフローティングの、常に表示されるラベル
送信後にすべてのエラーを表示する	ユーザーが各フィールドを離れた時点でインライン検証する
「Error: invalid input」/ すべて大文字	フィールドの隣に、平易で丁寧かつ具体的なメッセージ
ユーザー名 または パスワードのどちらが間違っているかを明かす	一般的な「ユーザー名またはパスワードが正しくありません」
表示オプションなしでパスワードを隠す	表示/非表示を切り替える目のアイコン。「パスワードの確認」は不要
フローのない「パスワードをお忘れですか？」リンクだけ	成功とリダイレクトまで含めた完全な回復フローを設計する
ソーシャルログイン + 常時ログインをどこでも自動適用する	トレードオフを伴う、文脈に応じた選択肢として提示する
バンキングアプリでユーザーを無期限にログイン状態に保つ	無操作時に自動ログアウト。ユーザー名のみ記憶する
確認せずに出荷する	ヒューリスティック + アクセシビリティ監査に引き継ぐ

---

出典レッスン (Uxcel)

• Best Practices for Designing Login & Signup Flows
• Designing Mobile Logins, Signups, & Other Forms
• Resetting Password
• Best Practices for Designing Forms
• Submitting a Form