ログイン後にメールコードを求められない、または試験用受信先にコードが見当たらない状況ですか。
最短の進め方は、隔離環境でEmail OTPの設定とログイン動作を先に確かめ、その後、管理された試験用受信先でメール到着とログイン完了を確認することです。 GitLab.comのMFA展開方針をSelf-Managedの既定動作とみなしてはいけません。臨時メールアドレスは本番や重要アカウントには使わないでください。
GitLab Self-Managedの管理者：インスタンスでEmail OTPが利用できる状態かを確認したい方。
QAエンジニア：自社インスタンスの隔離アカウントで受信からログインまで検証したい方。
開発者：メール捕捉、アプリケーションの認証結果、実際の受信を区別したい方。
最終更新：2026年10月26日。内容はGitLabのEmail OTP開発文書、二要素認証の利用者向け文書、関連するアカウントのメール検証説明を基に確認しています。設定や挙動はインスタンスの種類とバージョンに応じて、対応する公式資料で再確認してください。
まず、何を合格とする試験かを分けます
GitLab Email OTP テストでは、コードが生成されたこと、メールとして受け取れたこと、コード送信後にログインできたことを別々に判定します。メール捕捉先に本文が現れたとしても、実際の外部メール配送やログインセッションの成立までは証明できません。
対象も区別が必要です。GitLab.comでは、公式開発文書が2026年からのEmail OTP段階的展開について説明しています。また、公式利用者向け文書は、2026年4月以降のユーザー名とパスワードによるログインでMFAが必須となる扱いと、他の要素を設定していない場合のEmail OTPについて案内しています。GitLab.comの二要素認証に関する説明を参照してください。
この情報だけで、GitLab Self-ManagedやGDKでも同じ展開状況、初期値、ユーザー動作になるとは判断できません。試験対象のインスタンス自体を調べ、確認結果にバージョンと設定を添えて残します。
| 試験対象 | 先に確認すること | その確認だけでは証明できないこと |
|---|---|---|
| GitLab.com | 公式文書に記載された展開・MFAの適用条件 | Self-ManagedやGDKの設定 |
| GitLab Self-Managed | 対象バージョンの設定、ログイン制限、試験アカウントの状態 | 他のインスタンスにも同じ設定があること |
| GDK | ローカル環境の設定とメールの出力先 | 外部メールサービスへの実配送 |
管理者：設定の境界を確かめる
管理者は、対象環境のバージョンに対応するGitLabの二要素認証設定とログイン制限の説明を確認します。設定名や利用可能な機能を別バージョンから流用せず、実インスタンスの設定値を記録してください。設定の取得にAPIを使う場合も、アプリケーション設定APIの仕様を確認し、応答値をそのまま試験対象の証拠として保存します。
とくに、Email OTPの利用可否、最低要件に関わる設定、アカウントのメール検証、サインイン制限を別項目として扱います。メール検証の設定があることだけを理由に、ログイン用OTPが有効だと推測することはできません。
開発者：コード生成とログイン状態を分けて検証する
開発者は、自社の隔離インスタンスにある試験アカウントで通常のパスワードログインを開始し、OTP入力の段階に進むかを確認します。テストアカウント、リクエスト、受信メールを対応付けられるよう、記録には識別可能な試験情報を用い、実在する個人情報を含めないようにします。
次に、認証画面の遷移、コード送信後の応答、ログイン後のセッション成立を個別に確認します。ローカルのメール捕捉機能にメッセージが表示されても、そこで確認できるのは捕捉先までの処理です。外部配送の成功を主張する場合は、実際の受信を確認できる管理下の試験用受信先が別途必要です。
QA：受信からログイン完了までを判定する
QAは、隔離アカウントに紐づく制御可能な試験用受信先を用意し、送信されたメールが今回のログイン試験に対応しているかを確認します。受信した事実だけでなく、そのコードを対象アカウントで送信し、認証が受理されてログイン後の状態へ移ったことまで確認してください。
再送操作を行った場合は、古いコードの扱いを推測で仕様化せず、対象バージョンの公式資料と実際の挙動を記録します。コードの有効期間、到着時間、すべての受信先との互換性について、確認できていない保証を試験結果に書かないことが重要です。挙動に差がある場合は、利用者向けの二要素認証トラブルシューティングも照合してください。
試験結果は、少なくとも「OTP入力画面に進む」「メールが対応する試験受信先に到着する」「コードが受理されログイン状態になる」の判定が追える形にします。最初の条件を満たしても、後続のメール到着やログイン成功まで合格とみなさないでください。
条件に合わせて試験方法を選びます
- 隔離したSelf-ManagedまたはGDKでアプリケーションのメール生成を確かめたい場合は、ローカル捕捉先を使います。ただし、外部メール配送の証拠としては扱いません。
- 受信とログイン完了まで確かめたい場合は、試験アカウントに対応する管理下の受信先を使い、到着とコード送信後の状態を記録します。
- 確認対象がGitLab.comの展開状況や本番アカウントの場合は、自社インスタンスの結果から推定せず、公式の利用者向け案内を確認します。重要なアカウントで臨時アドレスを試すのではなく、適切な認証手段を維持してください。
- 受信先が管理できず、誰が内容を見られるかも不明な場合は、その受信先を使わず、チーム管理下の試験アドレスへ切り替えます。
試験アドレスを選ぶ際は、受信内容の扱いと用途の適合性も確認します。たとえば臨時メールと予備メールの違いを理解し、試験用と長期保管用を区別してください。試験データに実在の個人情報を含めない考え方は、メールのプライバシーに関する案内も参考になります。
セキュリティ担当・リリース責任者：証拠と適用範囲を残す
記録には、インスタンスの種類とバージョン、関連設定、試験アカウントの識別情報、メールを確認した場所、コード送信後の認証結果をまとめます。メール本文を保存する場合は、認証コードや個人情報を必要以上に残さず、閲覧権限と削除方法も定めてください。
この結果が証明するのは、記録した環境とアカウントで確認した挙動です。GitLab.comの展開状態や、別のSelf-Managedインスタンスの設定・挙動まで示すものではありません。試験終了後は試験資格情報とメールデータを整理し、GitLabがEmail OTP、設定、MFA展開、試験方法に関する公式文書を更新した際に、該当箇所を再確認します。
よくある質問
GitLabの隔離試験環境では何を準備しますか？
本番から分離した自社インスタンスと試験専用アカウントを用意し、対象バージョン、関連設定、メールの出力先を記録します。受信だけを確認するのか、認証後のログインまで確認するのかも先に決めます。
Self-ManagedでEmail OTPをどう確認しますか？
GitLab.comの展開方針を前提にせず、対象バージョンに対応する公式資料とインスタンスの設定を照合します。試験アカウントでログイン経路を実行し、OTP画面、メール受信、認証後の状態を分けて記録します。
捕捉先にコードが表示されたら合格ですか？
捕捉先に表示されたことは、メール内容がその捕捉先へ渡った証拠に限られます。試験用アカウントでコードを送信し、アプリケーションの受理とログインセッションの成立を別に確認してください。
試験用の受信先にコードが届かないときは？
まずアカウント、インスタンス、ログイン経路、設定されたメール出力先を確認し、捕捉先や管理下の受信箱に誤りがないか照合します。外部受信の場合は迷惑メール判定なども調べ、原因を確認できるまでは到着時間やコードの有効期間を決めつけないでください。
自社の隔離環境で受信部分まで確認する場合は、試験用アドレスの機能と制約を確認してから、管理された受信先の選択肢として採用するか判断できます。CloneInboxを使う場合も、重要アカウントや本番用途には使わず、用途に合うかを利用案内で確かめてください。
よくある質問
隔離したGitLabの試験環境は、何を先に整えればよいですか？
Self-ManagedでメールOTPを有効化したか、どう確認できますか？
メール捕捉ツールにコードが見えれば、ログイン試験は合格ですか？
試験用受信先にGitLabのコードが届かない場合、どこから調べますか？
ショッピング通知専用の受け取り先を作る
CloneInboxの転送エイリアスで一般的な通知を継続して受信できます。短期間の認証に一度だけ使うなら、一時メールを選びましょう。