認証機能のテスト観点｜会員登録・ログインの確認項目

会員登録やログインといった認証まわりの機能は、ほとんどのシステムに存在します。それだけに「毎回テストしているから大丈夫」と油断しがちな領域でもあります。

しかし認証は、一度事故が起きるとアカウント乗っ取り・個人情報の漏洩・全ユーザーのログイン不能に直結します。影響範囲が広く、クライアントからの信頼を一気に失いかねない機能です。

認証機能のテスト観点を体系的に押さえておくことは、リリース後の重大事故を防ぐ最短ルートです。この記事では、会員登録からログイン、パスワード、認証の安全性、権限境界までを、受託開発のPMやテスト担当が観点漏れなく確認できる形で整理します。表とチェックリストをそのまま実務に転用できるようにまとめました。

なぜ認証機能のテスト観点は漏れやすいのか

認証機能は「メールアドレスとパスワードを入れてログインできればOK」と捉えられがちです。この正常系だけを見てしまうことが、観点漏れの最大の原因です。

実際には、認証には「登録」「ログイン」「セッション維持」「パスワード変更」「ログアウト」といった複数の状態と流れが絡みます。さらに攻撃者は正常系ではなく、失敗系や異常系を突いてきます。ここに正常系中心のテストと、事故が起きる現実とのギャップが生まれます。

認証は「正しく通ること」より「不正には通さないこと」の確認が本質です。

認証機能で観点が漏れる典型パターン

認証のテストで抜けやすいのは、次のような領域です。正常系の裏側にある観点をリスト化しておきましょう。

• 失敗系の網羅不足: パスワード誤り・存在しないアカウント・ロック中など、失敗の分岐を試していない
• 状態遷移の見落とし: ログイン中に再ログイン、ログアウト後に戻るボタンで再アクセスなど、状態をまたぐ操作が未検証
• セキュリティ観点の欠落: 総当たり・列挙攻撃・セッション固定など、機能テストと切り離されて誰も見ていない
• 境界・国際化の未検証: 長大な入力・特殊文字・国際化ドメインのメールアドレスなど、異常系の入力が漏れる
• エラーメッセージの情報漏洩: 「このメールアドレスは登録されていません」のように、攻撃者に手がかりを与える文言

機能テストとセキュリティテストの境界

認証は、機能テストとセキュリティテストの両方が交差する領域です。両者の役割を切り分けておくと、抜け漏れの責任範囲が明確になります。

区分	主な確認内容	本記事での扱い
機能テスト	登録・ログイン・パスワード変更が仕様どおり動くか	中心的に扱う
セキュリティ観点（機能側）	総当たり対策・列挙対策・セッション管理など仕様として組み込む点	本記事で扱う
専門的な脆弱性診断	診断ツールや専門家による網羅的な脆弱性検出	外部の専門診断に委ねる領域

専門的な脆弱性の網羅的検出は、機能テストとは別枠で計画すべき領域です。その判断基準は脆弱性診断の依頼前に知っておきたい種類と流れで補完できます。本記事は「認証という機能の観点」に絞って解説します。

会員登録のテスト観点｜入力・重複・確認メール・規約同意

会員登録は、ユーザーがサービスに触れる最初の関門です。ここでの不備は、そのまま不正アカウントの温床や、登録できないという離脱に直結します。

登録フォームは入力項目が多く、バリデーションの分岐も複雑になりがちです。項目単位ではなく、フローとして観点を洗い出すことが重要です。

会員登録は「登録できること」と「不正・重複を登録させないこと」を同じ比重で確認します。

入力バリデーションの観点

各入力項目について、正常値・境界値・異常値を体系的に確認します。とくにメールアドレスとパスワードは分岐が多いため、表で整理すると漏れを防げます。

項目	確認する観点	代表的な失敗系
メールアドレス	形式チェック・大文字小文字・前後の空白	@なし・二重ドット・全角混入
パスワード	最小/最大長・文字種要件・確認用との一致	短すぎる・長大入力・不一致
氏名/ニックネーム	必須・文字数上限・特殊文字	空欄・絵文字・HTMLタグ混入
必須項目全般	未入力時のエラー表示・入力保持	送信後に入力内容が消える

入力値の境界をどう設計するかは、境界値分析のやり方とテストケースの作り方が参考になります。最小長・最大長の前後は、認証でもバグが集中しやすい箇所です。

重複登録と確認メールの観点

同じメールアドレスでの重複登録は、アカウントの二重発行やなりすましの起点になります。登録処理では、重複チェックのタイミングと排他制御を確認します。

• 重複登録: 既存アドレスでの登録拒否、大文字小文字を区別しない一致判定
• 同時登録: 同一アドレスでほぼ同時に2回送信した場合の二重作成防止
• 確認メール: 送信内容・リンクの有効期限・期限切れ後の再送導線
• 本登録前の状態: 確認メール未クリックのアカウントでログインできないこと
• 規約同意: 未同意では登録を進められない、同意日時が記録される

確認メールのリンクは、有効期限切れ・使用済み・改ざんの3ケースを必ず試します。仮登録のまま放置されたアカウントを本登録扱いしないことも、なりすまし防止の要点です。

確認メールまわりでは、送信先の取り違えにも注意が必要です。登録時に入力したアドレスへ確実に届くか、入力ミスで別人へ送られないかを確認します。また、確認前のアドレスを他人が再登録できてしまうと、アカウントの奪い合いが起きます。仮登録データの有効期限と、期限切れ後の再登録可否を仕様として定めておきましょう。

送信されるメール本文も観点に含めます。リンクにトークンだけでなく個人情報が含まれていないか、HTMLメールでの表示崩れがないか、迷惑メール判定されにくい差出人設定かといった点は、地味ですが登録完了率に直結します。テスト環境では実際にメールを受信し、リンクを踏むところまで通しで確認することをおすすめします。

ログインとログアウトのテスト観点

ログインは認証の中心です。正常にログインできることはもちろん、失敗時の挙動とセッションの扱いを丁寧に確認する必要があります。

ここでの観点漏れは、ロックアウトの不備による総当たり許容や、ログアウトしたのにセッションが生きているといった事故につながります。

正常系と失敗系の分岐

ログインの失敗系は分岐が多く、抜けやすい領域です。組み合わせを表で洗い出しておきましょう。

ケース	期待する挙動	確認ポイント
正しいID・パスワード	ログイン成功	遷移先・セッション発行
パスワード誤り	汎用エラーで拒否	存在有無を漏らさない文言
未登録アカウント	汎用エラーで拒否	パスワード誤りと同一文言
連続失敗	一定回数でロック	ロック閾値・解除条件
ロック中に正しい入力	ログイン不可	解除まで拒否されること

失敗回数によるロックアウトは、閾値・ロック時間・解除方法（時間経過か管理者解除か）をセットで確認します。ロックの通知が正規ユーザーに届くかも観点に含めます。

例えば「5回連続で失敗したら15分ロックする」という仕様なら、4回目までは通常のエラー、5回目でロック、ロック中は正しいパスワードでも拒否、という一連の流れを実際に試します。数値はあくまで一例で、案件のリスク許容度に応じて設計されます。ここで大切なのは、境界となる回数の前後（この例なら4回目と5回目）で挙動が切り替わることを確認する点です。

ロックアウトには、正規ユーザーを締め出してしまうという副作用もあります。攻撃者が他人のIDで意図的に失敗を繰り返し、そのアカウントをロックさせる嫌がらせが成立しないか、という視点も持っておくと安心です。ロック解除の導線が正規ユーザーにとって過度な負担にならないかも、あわせて確認します。

セッション管理と多重ログインの観点

ログイン成功後のセッションは、事故が起きやすい領域です。次の観点を確認します。

• ログアウト: ログアウト後にセッションが無効化され、戻るボタンで再アクセスできない
• タイムアウト: 無操作での自動ログアウト、絶対的な有効期限
• 多重ログイン: 複数端末での同時ログインの可否と、仕様どおりの制御
• Cookie属性: セッションCookieに Secure・HttpOnly が付与されている
• パスワード変更時: 変更後に他端末のセッションを無効化するか

ログインのように「状態を記憶して振る舞いが変わる」機能では、状態遷移の観点が有効です。Copeland『はじめて学ぶソフトウェアのテスト技法』では、状態遷移について「すべての遷移を少なくとも1回実行するような1組のテストケース」を作ることが基本方針とされています。未ログイン・ログイン中・ロック中といった状態と、その間の遷移をすべて試すことで、飛ばされがちな経路を洗い出せます。

ログアウトやパスワード変更の後にセッションが残らないことは、必ず実機で確認します。

パスワードのテスト観点｜強度・リセット・有効期限・保存

パスワードは認証の要であり、扱いを誤ると全ユーザーの資格情報が危険にさらされます。強度・リセットフロー・保存方法の3つを軸に観点を整理します。

パスワード強度とポリシーの観点

パスワードポリシーは、弱すぎても厳しすぎても問題になります。仕様どおりに機能するかを確認します。

• 最小長・文字種: 定めた要件を満たさないパスワードを拒否する
• よくあるパスワード: 単純な文字列や使い回しを弾く仕組みがあるか
• 強度表示: 入力中の強度メーターが仕様どおり動くか（ある場合）
• 確認入力との一致: 新規・確認欄の不一致を検出する

なお、近年のガイドラインでは、定期的な強制変更よりも、十分な長さと漏洩済みパスワードの排除が重視される傾向があります。要件は案件のポリシーに従い、テストでは仕様どおりの挙動を確認します。

パスワードリセットと再設定フローの観点

パスワードリセットは、攻撃者に狙われやすい導線です。リセット用リンクやトークンの扱いを重点的に確認します。

観点	確認内容	失敗系の例
リセット申請	登録有無で挙動を変えない	未登録で「存在しません」と表示
トークン有効期限	期限切れで無効化される	期限後も再設定できてしまう
トークンの使い回し	一度使ったら無効化される	同じリンクで複数回変更できる
再設定後の挙動	旧パスワードでログイン不可	旧パスワードが有効なまま
セッション無効化	再設定後に既存セッションを無効化	他端末のログインが継続する

パスワードリセットの申請画面では、登録済みか否かを画面に出さないことが、アカウント列挙攻撃を防ぐ基本です。「登録があればメールを送信しました」のような、存在を漏らさない文言を確認します。

リセットフローは、正常系を1度通しただけで安心しがちな領域です。実際には、リンクを2回クリックしたら2回目は無効になるか、リンクの有効期限が切れた後に再申請できるか、複数回申請したときに古いトークンが無効化されるか、といった分岐を1つずつ確認する必要があります。これらは攻撃者が狙う「時間差」の穴になりやすい箇所です。

再設定が完了した後の後始末も重要です。パスワードを変更したのに、以前ログインしていた別端末のセッションがそのまま生き続けていては、乗っ取られたアカウントを取り戻す手段としてのリセットが機能しません。再設定と同時に既存セッションを無効化する仕様になっているかを、実機で確認しましょう。

パスワード保存の考え方

パスワードの保存方法は、テスト計画時に開発と合意しておくべき観点です。テスト担当が直接確認しにくい領域ですが、設計レビューで押さえます。

• 平文保存の禁止: データベースに平文で保存されていないこと
• ハッシュ化: 適切なハッシュ関数を用い、ソルトを付与していること
• 専用アルゴリズム: パスワード保存用に設計された方式を用いること
• ログ出力: パスワードがログやエラー画面に出力されないこと

具体的な安全策は、IPA「安全なウェブサイトの作り方」や、OWASPのAuthentication Cheat Sheetが参考になります。うろ覚えで実装判断をせず、これらの一次情報を根拠にしましょう。

認証の安全性を守るテスト観点

認証機能のテスト観点で見落とされやすいのが、攻撃を前提とした安全性の確認です。機能としては動いていても、攻撃に弱い実装は事故のもとです。

ここでは、総当たり・列挙・セッション固定・CSRF・多要素認証の観点を整理します。専門的な脆弱性診断とは別に、機能仕様として組み込むべき点を確認します。

総当たり・列挙攻撃への対策観点

攻撃者はIDとパスワードを機械的に試したり、アカウントの存在を推測したりします。これらを防ぐ仕組みが仕様どおり働くかを確認します。

攻撃	対策の観点	確認ポイント
総当たり（ブルートフォース）	回数制限・ロック・遅延	短時間の連続試行を抑止できるか
リスト型攻撃	通知・多要素認証	大量ログイン試行を検知できるか
アカウント列挙	汎用エラー文言	存在有無を推測させないか

ログイン・登録・パスワードリセットの3画面で、エラー文言を統一して存在を漏らさないことが重要です。いずれか1画面でも「登録されていません」と返すと、そこから列挙されてしまいます。

セッション固定・CSRFの観点

セッションまわりの攻撃は見えにくく、機能テストでは飛ばされがちです。次の観点を確認します。

• セッション固定対策: ログイン成功時にセッションIDを再発行しているか
• CSRF対策: パスワード変更など状態を変える操作でトークン検証があるか
• 重要操作の再認証: メールアドレス変更や退会で、パスワード再入力を求めるか
• Cookieの属性: Secure・HttpOnly に加え、SameSite の設定を確認する

これらは実装依存の観点です。設計段階で対策方針を確認し、実装後に動作を検証する二段構えが有効です。

セッション固定攻撃は、攻撃者が用意したセッションIDをユーザーに使わせ、ログイン後もそのIDが引き継がれることを悪用します。対策はシンプルで、ログイン成功のタイミングでセッションIDを必ず再発行することです。テストでは、ログイン前後でセッションIDが変わっているかを確認します。フレームワーク任せになりやすい処理なので、実際に値が変化することを目で見て確かめると確実です。

CSRFは、ログイン中のユーザーに意図しない操作を実行させる攻撃です。パスワード変更・メールアドレス変更・退会といった重要操作で、トークン検証が働いているかを確認します。あわせて、これらの重要操作では現在のパスワードの再入力を求める設計になっていると、より安全性が高まります。

多要素認証（2要素認証）の観点

多要素認証を導入する場合、認証フローが複雑になり、テスト観点も増えます。導入している案件では次を確認します。

• 正常系: 正しいコードで認証が通る
• 失敗系: 誤ったコード・期限切れコードを拒否する
• バックアップ手段: 端末紛失時のリカバリー導線が機能する
• バイパス防止: 2要素をスキップして本処理に到達できない

多要素認証は強力ですが、リカバリー導線の不備が新たな抜け穴になりがちです。導入したら安心ではなく、迂回経路を必ず試します。

たとえば、パスワードだけで通る旧来のログイン画面が別URLに残っていないか、コード入力を省略できるAPIが存在しないかといった点です。認証の強化は、最も弱い経路の強度で決まります。新しい仕組みを足したときほど、古い経路が残っていないかを合わせて棚卸ししましょう。

権限境界と異常系のテスト観点

認証が正しく機能しても、認可（権限）との境界が曖昧だと事故が起きます。ここでは権限境界と、境界値・国際化を含む異常系の観点を扱います。

未ログインアクセスとなりすましの観点

ログインしていないユーザーや、他人のアカウントになりすました操作を防げるかを確認します。URLの直接入力やIDの書き換えを試すのが基本です。

観点	確認内容	失敗系の例
未ログインアクセス	保護ページへ直接URLで到達できない	ログイン画面へ誘導されない
権限昇格	一般ユーザーが管理機能に到達できない	URL直打ちで管理画面が開く
水平権限	他ユーザーのデータを閲覧・操作できない	IDを書き換えて他人の情報が見える
ログアウト後	保護リソースへ再アクセスできない	戻る操作で情報が残る

URLの直接入力とパラメータ書き換えは、認証・認可テストで必ず試す2大手口です。画面上にリンクがなくても、直接アクセスされる前提で確認します。

とくに見落とされやすいのが、水平方向の権限（同じ役割の他ユーザー間）の境界です。自分のマイページのURLに含まれるIDを、他人のIDに書き換えたときに他人の情報が見えてしまう不具合は、認可の代表的な事故です。API経由でも同じで、画面には出ていないパラメータをリクエストで直接指定した場合の挙動まで含めて確認します。ログイン状態と操作対象の所有者が一致しているかを、サーバー側で必ず判定しているかがポイントです。

境界値・特殊文字・国際化の異常系

異常系の入力は、認証機能でも見落とされがちです。次のような入力を体系的に試します。

• 大量入力: 極端に長いメールアドレス・パスワードでの挙動
• 特殊文字: 記号・絵文字・制御文字・空白のみの入力
• 国際化メール: 国際化ドメインや非ASCII文字を含むアドレス
• エンコード: 全角・半角の混在、前後の空白の扱い
• 連続送信: 送信ボタンの連打による二重処理

異常系の入力設計やエラー時の挙動確認は、エラーハンドリングテストの設計と実践の考え方が応用できます。認証は入力の起点であるだけに、異常系の網羅が品質を左右します。

エラーメッセージの出し方（情報を漏らさない）

エラーメッセージは、親切さとセキュリティのバランスが問われる観点です。ユーザーには分かりやすく、攻撃者には手がかりを与えない文言が理想です。

場面	避けたい文言	望ましい文言の方向性
ログイン失敗	「パスワードが違います」	「IDまたはパスワードが正しくありません」
登録済み確認	「登録済みのメールです」	「登録があればメールを送信します」
リセット申請	「未登録のアドレスです」	「該当があればメールを送信します」

エラー文言は「どちらが間違っているか」を特定させないことが原則です。ユーザー体験を損なわない範囲で、情報の出し方を統一します。

認証機能のテスト観点を実務に落とし込むチェックリスト

ここまでの観点を、そのまま実務で使えるチェックリストにまとめます。会員登録からログインまでの観点を機能ごとに整理し、レビューや進捗管理の基準として活用してください。

機能別チェックリスト

各機能について、正常系・失敗系・安全性の3側面を確認します。以下を観点表のベースにすると、抜け漏れを可視化できます。

• 会員登録: 入力バリデーション・重複登録・確認メール・規約同意・仮登録の扱い
• ログイン/ログアウト: 正常/失敗の分岐・ロックアウト・セッション無効化・多重ログイン
• パスワード: 強度ポリシー・リセットフロー・トークン有効期限・保存方法
• 認証の安全性: 総当たり対策・列挙対策・セッション固定・CSRF・多要素認証
• 権限境界: 未ログインアクセス・権限昇格・水平権限・URL直打ち
• 異常系/UX: 境界値・特殊文字・国際化メール・エラーメッセージの文言

観点を体系的に洗い出す進め方そのものは、テスト観点の洗い出し手順と抜け漏れ防止で詳しく解説しています。認証以外の機能にも同じ手順を展開できます。

優先順位のつけ方

すべてを同じ熱量でテストする時間はないのが実情です。事故時の影響度で優先順位をつけます。

優先度	対象	理由
高	ログイン失敗系・権限境界・列挙対策	乗っ取り・情報漏洩に直結
中	パスワードリセット・セッション管理	悪用の起点になりやすい
低	強度メーター表示・UX文言の統一	事故より体験の質に影響

限られた工数では、影響度の高い失敗系と権限境界から着手するのが定石です。他システムの観点整理も、決済システムのテスト観点と確認項目のように領域別にまとめると横展開しやすくなります。

上長やクライアントへの説明

認証のテスト範囲は、上長やクライアントへの説明が求められる場面が多い領域です。「なぜそこまでやるのか」を影響度で語れると合意を得やすくなります。

• 事故の影響を先に示す: 乗っ取り・漏洩・ログイン不能という結果から逆算する
• 観点表で網羅性を見せる: 何を確認し、何を範囲外にするかを表で共有する
• 範囲外は別枠と明示: 専門的な脆弱性診断は別途計画すると線引きする

こうした説明では、テストの網羅度を「何件のケースを実施したか」だけで語ると、かえって本質が伝わりません。件数ではなく、どの観点をカバーし、どのリスクを潰したのかを語ると、費用対効果の判断材料になります。認証のように事故の影響が大きい機能ほど、範囲を明示した合意形成が後々のトラブルを防ぎます。

範囲外とする領域についても、放置ではなく「別途どう手当てするか」まで示せると、クライアントの安心感につながります。専門的な脆弱性診断や、負荷をかけたときの認証の挙動などは、機能テストとは別枠で計画する前提を共有しておきましょう。

まとめ｜認証機能のテスト観点で重大事故を防ぐ

認証機能は多くのシステムに存在し、事故れば影響が甚大です。だからこそ、正常系だけでなく失敗系・安全性・権限境界まで含めた観点の網羅が欠かせません。

本記事で整理した次の6領域を、機能別チェックリストとして手元に置いてください。観点を表とチェックリストで可視化することが、抜け漏れと属人化を同時に防ぐ第一歩です。

• 会員登録: 入力バリデーション・重複・確認メール・規約同意・仮登録の扱い
• ログイン/ログアウト: 失敗系の分岐・ロックアウト・セッション無効化
• パスワード: 強度ポリシー・リセットフロー・トークン管理・保存方法
• 認証の安全性: 総当たり・列挙・セッション固定・CSRF・多要素認証
• 権限境界: 未ログインアクセス・権限昇格・水平権限の分離
• 異常系/UX: 境界値・特殊文字・国際化メール・エラーメッセージの文言

いずれも、正常系だけでなく失敗系と安全性をセットで見ることが、認証機能では欠かせません。

まずは自社の認証機能に、本記事のチェックリストを当ててみることから始めましょう。抜けが見つかれば、それがそのまま次の改善テーマになります。

テスト体制の見直しや、認証まわりの品質担保に不安がある方は、テスト代行サービスへの相談窓口からお気軽にお問い合わせください。現状の課題整理からご一緒します。

次に読むならこの記事

• SaaSのテスト観点｜事故る7領域の確認項目
• 日付・時刻のテスト観点｜見落としがちな境界と時差
• ECサイトのテスト観点｜事故りやすい9領域の確認項目

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する