このチェックリストの目的
サインアップ（新規登録）とOTP（ワンタイムパスコード）認証は、ユーザー体験とセキュリティが真正面からぶつかる領域です。いちど実装してしまうと、普段は「動いているように見える」ため、細かな不具合が長く放置されがちです。特に、メール配信の遅延や再送の挙動、入力ミス時の案内、期限切れの処理、レート制限などは、テストしない限り問題に気づきません。
このチェックリストは、使い捨てメール（Disposable Email）を活用して、サインアップ〜OTP完了までを“実運用に近い形”で検証するための項目をまとめたものです。QA担当者だけでなく、開発・運用・CSが共通言語として使えるように、観点ごとに整理しています。
事前準備：テスト設計の前に決めること
1）検証対象のフローを明確化
- メール入力 → 登録 → OTP送信 → OTP入力 → 認証完了（初回ログイン）までの一本道か
- 登録直後にプロフィール入力や利用規約同意などが挟まるか
- OTPはメールのみか、SMSや認証アプリとの併用があるか
- OTPが「リンク」なのか「コード」なのか（または両方）
2）テスト環境の前提
- ステージング／本番相当の配信基盤（メールプロバイダ、テンプレート、ドメイン設定）が同等か
- デバッグ用にOTPをログに出していないか（環境変数で完全に無効化できるか）
- レート制限・不正検知の設定が本番と同じか（もしくは差分を記録しているか）
3）使い捨てメール利用時の注意
使い捨てメールは、受信確認には便利ですが、サービス側の仕様（ドメイン拒否、到達率、表示の癖）で挙動が変わります。1つのサービスだけで判断せず、複数パターンを回すことで、フローの堅牢性を確認できます。また、テスト対象が金融・決済・医療など高い保証が必要な領域の場合、使い捨てメールを“あくまで異常系・境界条件の検証ツール”として扱い、最終確認は通常メールでも実施してください。
チェックリストA：UI/UX（入力・案内・エラー）
A-1 メールアドレス入力
- プレースホルダーが具体的で、入力例が過剰に誘導的でない
- メール形式のバリデーションが過剰に厳しすぎない（合法な形式を誤検出しない）
- 前後の空白、全角スペース、不可視文字が混入しても適切に処理される（自動トリムなど）
- 大文字小文字の扱いが一貫している（正規化方針が統一されている）
- 入力後に「確認メールを送信しました」など、次に何をするべきかが明確
A-2 OTP入力画面
- OTPの桁数が明確（例：6桁）で、入力欄が分かりやすい
- ワンタイムコードの有効期限が明確に示される（短すぎず、心理的に圧迫しすぎない）
- 入力欄の自動フォーカス、桁移動、貼り付け（ペースト）の挙動が自然
- 入力ミス時のエラー文言が具体的（「コードが違います」だけでなく次の行動を促す）
- 再送リンク（またはボタン）の位置が分かりやすく、誤タップしにくい
- 戻る操作をした場合、状態が壊れない（無限ループや送信済みフラグの不整合がない）
A-3 エラーメッセージ品質
- メール未入力、形式不正、ドメイン拒否、重複登録などが区別される
- セキュリティ上、アカウント存在有無を過度に露出していない（列挙耐性）
- OTP誤入力・期限切れ・回数超過・再送制限など、ユーザーが理解できる説明になっている
- サポート導線（問い合わせ/ヘルプ）が必要な箇所にある
チェックリストB：メール配信（到達・遅延・内容）
B-1 到達と遅延
- 送信後、受信までの体感時間が許容範囲（一般に数十秒〜数分）
- 遅延が起きた場合でも、UIが不安を煽らない（適切な待ち時間の案内がある）
- 同一操作の連打でメールが多重送信されない（冪等性）
- 再送を押したとき、古いOTPが無効化されるか（同時に複数OTPが有効にならない）
B-2 メール本文（テンプレート）
- 件名が用途を明確に示す（登録確認、ログイン確認など）
- 差出人名（From）が信頼できる表記で、ブランド名が統一されている
- 本文にOTPが読みやすく配置されている（改行、フォント、コピーしやすさ）
- リンク型の場合、URLが途中で改行されない、タップしやすい
- 言語がユーザーの選択に一致している（日本語UIなら日本語メールなど）
- フィッシング防止の基本要素（正しいドメイン、不要に煽らない文面）が満たされる
B-3 迷惑メール判定の兆候
- 使い捨てメールで受信できる場合でも、通常メールで迷惑判定されないかを別途確認
- HTML/テキスト両対応が崩れていない
- 画像だけのメールになっていない（テキストでOTPが確認できる）
チェックリストC：OTPロジック（期限・回数・再送・無効化）
C-1 有効期限
- 有効期限内は正しく通る
- 期限切れ後は確実に弾かれ、再送導線が提示される
- サーバー時刻と表示時刻の差で混乱が起きない（タイムゾーン/表示整合）
- 境界条件（期限ギリギリ入力）で不安定にならない
C-2 試行回数とロック
- 誤入力の許容回数が設定されている（過度に厳しすぎない）
- 回数超過時の動作（一定時間ロック、再送不可など）が仕様通り
- ロック解除の条件が明確（時間経過、再送、サポート対応など）
- 攻撃耐性としてのレート制限が、正当なユーザーを過剰に弾かない
C-3 再送の整合性
- 再送を押すたびに新しいOTPが発行され、古いOTPは無効になる
- 再送間隔（クールダウン）が存在し、連打で爆発しない
- 再送を繰り返した場合でも、最新のOTPのみが通る
- 異なる端末/ブラウザで同一メールを使ったときの挙動が一貫
チェックリストD：状態管理（セッション・遷移・多端末）
D-1 画面遷移の強さ
- OTP画面をリロードしても破綻しない（必要な状態が復元される）
- 戻る/進む操作で、送信済み状態が崩れない
- 複数タブで同時に操作したとき、想定外の矛盾が起きない
- ネットワークが不安定でも、わかりやすい再試行導線がある
D-2 多端末テスト
- 端末Aで登録、端末BでOTP入力というケースが成立するか（許可/不許可の仕様が明確か）
- 同一メールで複数回登録を試みたときの扱い（重複判定、再認証の流れ）が明確か
- ブラウザ差（Safari/Chrome/Firefox）で入力体験が崩れない
チェックリストE：セキュリティ観点（最低限押さえる）
E-1 アカウント列挙耐性
- 「このメールは登録済みです」など、露骨に存在確認できる表現になっていないか
- 登録済みの場合の案内が、ユーザーに優しいが情報は漏らしすぎない形か
E-2 OTPの扱い
- OTPがログや解析ツールに平文で残りにくい
- OTPの推測耐性（桁数、ランダム性）が仕様通り
- OTPを複数回送っても、過去のOTPが通らない（リプレイ耐性）
- OTPがURLに含まれる設計の場合、参照元や履歴に残るリスクが理解されている
E-3 レート制限と不正検知
- 送信・再送・認証試行の各ポイントに適切な制限がある
- 制限にかかったときのエラーが過剰に攻撃者へヒントにならない
- 誤検知で正当ユーザーが詰んだ場合の救済導線がある
チェックリストF：使い捨てメール特有の“落とし穴”
F-1 ドメインブロック
- 使い捨てメールのドメインを拒否する仕様なら、入力時点で明確に案内される
- 拒否する場合でも、ユーザー体験が荒れない（理由・代替案・ヘルプを提示）
- 拒否リストの更新や判定の根拠が運用で管理できる
F-2 受信タイミングのズレ
- メールが遅れて到着しても、古いOTPが通らない設計になっている
- 遅延時のUIが“放置されている感”を出さない（再送や確認の手順が明確）
F-3 使い捨てメールの受信箱表示の癖
- 件名が短すぎて識別しづらいと、受信箱で埋もれる可能性がある
- OTPが本文下部にあると、プレビューでは見えず取りこぼす可能性がある
- テキスト版がないと、表示崩れでコードが見えない可能性がある
チェックリストG：観測性（ログ・計測・再現性）
G-1 失敗の原因が追えるか
- OTP送信成功/失敗がサーバー側で追跡できる
- メールプロバイダのレスポンス（受理/拒否/遅延）が確認できる
- ユーザー側で「届かない」を自己解決できる情報（再送、迷惑箱案内）がある
G-2 計測（プロダクト改善に使える）
- 登録開始→OTP入力→完了までの離脱点が測れる
- 再送回数、誤入力回数、期限切れ率などが分析できる
- 改善施策（文言変更、UI変更）が数値で評価できる
実践シナリオ：最低限これだけは回す
- 正常系：登録→即受信→OTP入力→完了
- 遅延系：受信が遅れる想定で待機→再送→新OTPで完了
- 誤入力系：わざと間違える→エラー→正しいOTPで完了
- 期限切れ系：期限を跨ぐ→期限切れ表示→再送→完了
- 回数超過系：誤入力を繰り返す→制限→解除条件を確認
- 多タブ系：タブAで再送、タブBで古いOTP入力→弾かれることを確認
まとめ： “通るかどうか”より、“つまずいた時に戻れるか”
サインアップ＋OTPは、成功するときは一瞬です。でも、少しでも想定外が起きると、ユーザーは驚くほど簡単に離脱します。だからこそ、QAでは「通ること」よりも、「つまずいたときに迷わず戻れること」を重視するのが効果的です。
使い捨てメールは、遅延や再送、期限切れなどの“揺らぎ”を意図的に露出させるのに向いています。チェックリストを一度回して終わりではなく、テンプレや制限値を変えたとき、メール基盤を変更したとき、UIを更新したときに繰り返し使える形にしておくと、品質が安定していきます。
丁寧に検証すればするほど、ユーザーの不安は静かに減っていきます。派手な改善ではなくても、「迷わない」「やり直せる」「安心して進められる」導線が、プロダクトの信頼を積み上げてくれます。