Azure AD B2Cで確認コードメールが届かないときの原因と対処法【2024年1月障害の解説】

2024年1月3日前後、「Azure AD B2Cのサインアップ画面で確認コードメールが届かない」「パスワード リセットのメールも来ない」という問い合わせが急増しました。本記事では、この事象の原因となったAzure AD B2C側の障害内容と、利用者として取れる対処方法、そして再発時の影響を最小化するための設計・運用のポイントを、実運用の観点から詳しく解説します。

Azure AD B2Cで確認コードメールが届かない現象とは

Azure AD B2Cは、SaaSや自社Webサービスの「外部ユーザー向けID基盤」として利用されることが多く、サインアップ時にはメールアドレス宛に確認コード（ワンタイムコード）を送信し、そのコードを入力することでメールアドレスの正当性を確認します。

ところが、2024年1月3日頃から以下のような症状が報告されました。

• 「確認コードを送信」ボタンを押しても、ユーザーの受信箱にメールが届かない
• 一部ユーザーでは届くが、多くのユーザーで届かない／届くまで極端に遅延する
• パスワード リセット フローでも同様にメールが来ないため、パスワード変更に進めない
• アプリ側のログには特にエラーは出ておらず、画面上も「確認コードを送信しました」と表示される

このような症状は、開発・検証環境だけでなく本番テナントでも発生し、SaaSの新規ユーザー登録が完全に止まってしまうケースもありました。特にB2Cをフロントにして、バックエンドでAzure ADや独自DBと連携している構成では、「サインアップできない＝ビジネスインパクトが直撃」という状況になりやすいため、すばやい切り分けと対処が重要です。

項目	内容
主な症状	サインアップ／パスワード リセット時の確認コードメールが届かない
影響する操作	新規ユーザー登録、パスワード リセット、メールアドレス確認を伴うフロー全般
影響範囲	Azure AD B2Cを利用している複数テナントで広く発生
ユーザー影響	アカウント作成ができない、パスワードを変更できないなど、サービス利用開始が遅延・停止

2024年1月3日に発生したAzure AD B2Cのメール送信障害の概要

発生日時と影響範囲

Microsoftが公開した情報によると、障害の発生日時と影響範囲はおおむね次のとおりです。

• 発生日時：2024年1月3日 08:45（UTC）頃から
• 対象サービス：Azure AD B2C（サインアップ／パスワード リセットなどの標準ユーザーフロー）
• 影響する機能：確認コードメール、パスワード リセットメール等、B2Cが内部的に利用しているメール送信機能

この時間帯以降、Azure AD B2Cが依存している内部のメール送信サービスの一部ノードで障害が発生し、確認コードやパスワード リセットのメール送信に失敗していました。テナントやリージョンによって「まったく届かない」「遅延しつつも時々届く」など、見え方が異なるのも特徴でした。

障害の原因（Microsoft公式発表の概要）

Microsoftの説明によると、障害の主因は Azure AD B2C が内部的に利用するメール送信サービスのノード障害です。具体的には、

• 内部メール送信サービスの一部ノードが異常な状態となり、正常にメールを送出できなくなった
• トラフィックが問題のあるノードにルーティングされ続けたことで、エラーやタイムアウトが増加
• その結果、B2Cからユーザーへ送る確認コードメールやパスワード リセットメールが送信失敗または大幅遅延

という状況が生じていました。重要なのは、この障害は「B2Cの構成やカスタムポリシーの設定ミスではなく、Microsoft側のインフラ障害」であったという点です。

復旧までの流れ

Microsoft側では、問題を認識した後、次のような対処を行っています。

• 障害を起こしているノードをメール送信サービスのプールから切り離し
• 安定しているノード側のリソースを増強し、トラフィックをそちらへ逃がす
• キューに溜まっていた送信待ちメールの処理を順次実施

この過程で、Azure Statusページや各サブスクリプションのService Healthへの障害情報の反映が遅れるタイムラグがあり、「現場では問題が起きているのに、ポータル上では正常に見える」というタイミングが存在しました。そのため、アプリ開発側・運用側では「自分たちの設定が悪いのか、Microsoft側の障害なのか」が切り分けしづらい状況になっていました。

ユーザー側で取れる当面の対処方法

まずはリトライを行う

今回の障害のように、メール送信基盤の一部ノードだけが不安定なケースでは、「全く届かない」ではなく「何度か送ると届く」状態になることがあります。そのため、ユーザー向けの案内としては、次のようなリトライを促す運用が現実的です。

• 確認コードが届かない場合は、数分待ってから「確認コードを再送信」を押してもらう
• 連続で10回以上など、極端に短時間での再送をさせない（スパム判定回避・ユーザー体験向上）
• それでも届かない場合はサポート窓口へ連絡してもらうフローを整備しておく

障害期間中でも、ノードの状態や負荷状況によっては再試行で成功するケースがあったため、単発の失敗で諦めず、一定間隔での再送を案内することに意味があります。

ユーザーへ状況を明示する（案内文の例）

サインアップフローが完全に停止してしまうと、ユーザーからの問い合わせが急増します。障害が把握できている段階では、「今何が起きているか」を画面上で案内したほうが、ユーザー体験としてもサポート負荷としても有利です。

たとえば、サインアップ画面やヘルプページに次のようなメッセージを一時的に掲示するとよいでしょう。

現在、認証基盤サービスの一部でメール送信に遅延・不達が発生しており、
「確認コードを送信」ボタンを押してもメールが届かない場合があります。
数分お待ちいただいたうえで再送信をお試しください。
何度かお試しいただいても届かない場合は、大変お手数ですがお問い合わせフォームよりご連絡ください。

「何が原因か」「ユーザーに何をしてほしいか」を明示することで、不要な不安や問い合わせを減らし、結果として運用側の負荷軽減にもつながります。

復旧完了後は特別な設定変更は不要

今回の障害は、Azure AD B2Cのメール送信インフラの問題であり、B2Cテナントの設定やカスタムポリシーに起因するものではありません。そのため、Microsoft側の復旧完了後は、基本的に「何もしなくても」再び正常に確認コードメールが送信される状態に戻ります。

よって、恒久的な設定変更や、テナントの全面的な作り直しなどは不要です。もし障害中に応急措置として設定を変更している場合は、「本来必要だったセキュリティ要件（メール確認の必須化など）を元に戻す」ことを忘れないようにしましょう。

アプリや設定が原因ではないかを切り分けるチェックリスト

今回のように「Microsoft側の障害」が原因だったケースでも、現場としてはまず自分たちの設定を疑ってしまいがちです。将来のトラブルシューティングのためにも、「最低限ここまで確認すればアプリ側の問題ではないと判断しやすい」というチェックポイントを整理しておきます。

観点	確認内容	問題の切り分け
B2Cユーザーフロー	標準のサインアップ／サインインフローで再現するか	標準フローでも同じなら、アプリやUIの問題ではない可能性が高い
カスタムポリシー	カスタムポリシーではなく、組み込みポリシーで事象が発生するか	組み込みでも再現するなら、ポリシー定義の不備ではないと判断しやすい
テストユーザー	自分の会社ドメインのメール、Gmail、Outlook.comなど複数の宛先でテスト	複数のメールサービスで一様に届かないなら、送信側の障害を疑う
スパム判定	迷惑メールフォルダ、セキュリティ製品でブロックされていないか	特定ドメインだけ届かない場合は、受信側の設定を疑う
ログ	アプリ側ログ・B2Cログにエラーが出ていないか	送信API自体は成功しているなら、その先（メール基盤）の問題の可能性が高い

これらを確認して「どう見ても自分たちの設定は問題なさそうだ」と判断できた場合は、Azure PortalのService Healthやサポートチケットを通じて、Microsoft側の障害有無を確認していく流れになります。

再発に備えた運用・設計のベストプラクティス

今回の障害はAzure AD B2C側のインフラ問題でしたが、同様のインシデントは今後もゼロにはなりません。そこで、サービス側であらかじめ取っておける対策を整理します。

項目	推奨アクション	期待できる効果
Service Healthアラート	Azureポータルの「Service Health」でAzure AD B2C関連のアラートをメール／Teamsで通知	障害発生を早期に検知し、ユーザーへの告知や社内連携を素早く実施できる
カスタムメール送信	B2Cカスタムポリシーを利用し、SendGridや独自SMTPなど外部メールサービスから送信	Microsoft側メール基盤の障害影響を回避しやすくなる
代替認証手段	電話番号認証（SMS／音声通話）やAuthenticatorアプリによる多要素認証を用意	メール障害時でも新規登録やサインイン手続きが継続可能になる
要件の一時緩和	長期障害時には、一時的に「メール確認必須」を緩和し、復旧後に再確認フローを実施	ユーザー流入を完全に止めず、ビジネスインパクトを抑えられる
ユーザー通知	アプリ内のお知らせ欄やサインアップ画面で障害情報・復旧見込みを表示	問い合わせの集中やユーザーの不信感を軽減し、サポート負荷を下げられる

とくに、Service Healthアラートの設定と、代替認証手段の用意の2つは、すぐにでも着手しておく価値があります。どちらも一度整備してしまえば、以後の障害対応速度が大きく変わります。

Service HealthアラートでAzure AD B2Cの障害を早期検知する

Azureポータルには、「Service Health」というサービスの状態を監視する仕組みが用意されています。ここでAzure AD B2Cに関するアラートを設定しておけば、障害やメンテナンスの情報をメールやTeamsで自動的に受け取ることができます。

運用としては、次のような形がおすすめです。

• Azure AD B2Cを利用しているサブスクリプション全てに対して、Service Healthアラートを設定
• 通知の宛先として、運用チームの共通メールグループ、Teamsチャンネルを指定
• 障害情報が届いたら、まずは社内向けの連絡テンプレート、次にユーザー向け告知テンプレートへ展開

これにより、「たまたまTwitterやコミュニティで騒がれ始めてから気付く」といった受け身の状況を避けることができます。

カスタムメール送信でAzure AD B2C依存を下げる

標準メール送信とカスタムメール送信の違い

Azure AD B2Cの標準機能では、確認コードメールやパスワード リセットメールはMicrosoftが用意したメール送信インフラから送信されます。構成がシンプルな一方で、今回のようにインフラ側で障害が起きると、アプリ側からは対処しづらいという弱点があります。

これに対して、カスタムポリシーを利用すると、外部のメールサービス（SendGridや自社SMTPサーバーなど）にREST API経由でメール送信を委譲する設計が可能になります。こうすることで、次のようなメリットが得られます。

• メール送信のログ・統計を自社で細かく把握・分析できる
• ドメイン認証（SPF/DKIM/DMARC）の制御をしやすく、到達率を高めやすい
• 今回のようなAzure AD B2C内部のメール基盤障害の影響を受けにくくなる

SendGridを利用した構成イメージ

具体例として、SendGridを利用した構成イメージを挙げます。

1. SendGridアカウントを作成し、専用のAPIキーを発行する
2. 送信元ドメインのDNSにSPF/DKIMレコードを追加し、ドメイン認証を完了させる
3. Azure Functionsなどで簡易的なメール送信APIを作成し、B2CからはこのAPIを呼び出す
4. B2CカスタムポリシーでREST API技術プロファイルを定義し、確認コード生成後にメール送信APIを呼び出すよう構成

こうすることで、B2C側は「メール送信APIを叩く」だけに役割を限定でき、実際のメール送信はSendGrid側に任せることができます。SendGridのダッシュボードでエラー率やブロック率を確認できるため、到達率改善のPDCAも回しやすくなります。

独自SMTPサーバーを利用する場合のポイント

自社運用のSMTPサーバーを利用する場合は、次のような点に注意が必要です。

• 送信元IPアドレスのレピュテーション管理（スパム扱いされていないか）
• 認証・暗号化（SMTP AUTH、STARTTLS/TLS）に対応しているか
• メールキューが溜まったときのモニタリングとアラート設計
• バウンスメール（配送失敗）のログ収集と再送ポリシー

インフラ運用コストとのトレードオフにはなりますが、B2Cのメール送信基盤に完全依存しない設計を取ることで、トータルの可用性を高めることができます。

メール以外の代替認証手段を用意する

メールは便利な一方で、「受信側のスパム判定」「メール基盤の障害」など、どうしても不安定要素を抱えています。そのため、Azure AD B2Cを利用するうえでは、メール以外の代替手段を用意しておくのが理想的です。

• SMSによる電話番号認証（ワンタイムコードをSMSで送信）
• 音声通話によるコード通知
• Microsoft Authenticatorなどの認証アプリを用いた多要素認証

たとえば「通常はメール＋パスワードでサインアップしつつ、メールが不安定なときは電話番号での登録も選べる」といったフローを設計しておくことで、メール障害時の影響をかなり軽減できます。

一時的な要件緩和：メール確認必須をどう緩めるか

障害が長期化し、ビジネス上どうしても新規登録を止められない場合は、「メール確認を一時的に必須ではなくする」という判断もありえます。ただし、これにはセキュリティリスクが伴うため、慎重な設計が必要です。

一例として、次のような方針が考えられます。

• 障害期間中のみ、メール確認前でもアカウントは仮有効とする
• 障害復旧後に、「メールアドレス未確認ユーザー」に対して一括で再確認メールを送信する
• 一定期間内に確認が完了しないアカウントは自動的に利用制限または削除対象とする

このように「緩めた分は後から必ず締め直す」運用を組み合わせることで、セキュリティとビジネス継続性のバランスを取りやすくなります。

障害時にユーザーへどう伝えるか：コミュニケーションの工夫

技術的な対策と同じくらい重要なのが、ユーザーとのコミュニケーションです。Azure AD B2Cのように「裏側のID基盤」で障害が発生すると、ユーザーからは「このサービスは大丈夫なのか？」という不安が高まりがちです。

そこで、次のような工夫をおすすめします。

• サインアップ画面に「現在、認証基盤の障害により〜」といった案内を表示する
• ステータスページ（自社運営）を持っている場合は、そこに障害情報を掲載する
• 問い合わせフォームの自動返信メールにも、既知の障害情報を明記する

「障害が起きていることを隠す」のではなく、「状況をきちんと共有している」ことが伝わるだけでも、ユーザーからの信頼は大きく変わります。

設計・運用チェックリスト：Azure AD B2Cサインアップを止めないために

最後に、Azure AD B2Cでサインアップフローを運用していくうえで、今回のような障害に備えるチェックリストをまとめます。新規構築時のレビューや既存システムの棚卸しに活用してください。

カテゴリ	チェック項目	備考
監視・アラート	Service HealthアラートでB2C関連イベントを監視しているか	メール／Teamsへの通知先を運用チーム全体で共有しておく
メール基盤	標準メール送信のみか、外部メールサービスとの二重化を検討しているか	重要度が高いサービスほど、カスタムメール送信の導入を検討
代替認証	メール以外の認証手段（SMS等）を用意しているか	少なくとも高重要度ユーザーには代替手段を提供すると安心
UI/UX	確認コード未達時の案内メッセージやヘルプページが用意されているか	「何度か再送を試してください」「届かないときの連絡先」などを明示
セキュリティポリシー	障害時の一時的な要件緩和ルールと復旧後の巻き取りルールが定義されているか	緩和したまま放置しないよう、手順書と責任者を明確化
ドキュメント	B2C設定やカスタムポリシーの変更履歴が残っているか	障害発生時に「最近何を変更したか」をすぐに確認できる状態にする

まとめ：今回のAzure AD B2Cメール障害から学べること

2024年1月3日頃に発生したAzure AD B2Cの「確認コードメールが届かない」問題は、Azure AD B2Cが依存する内部メール送信サービスのノード障害が原因でした。アプリケーションやB2Cテナントの設定が直接の原因ではなく、Microsoft側のインフラ障害だったという点が大きなポイントです。

一方で、現場の運用担当・開発者目線で見ると、「メールが届かない」という現象だけからは原因がすぐに分からず、ユーザー登録が止まってしまうという大きな影響が生じました。この経験から学べることは、次のようにまとめられます。

• Service Healthアラートなどを活用し、Azure AD B2Cの障害を早期に検知できるようにしておく
• カスタムメール送信や代替認証手段を整備し、メール基盤の障害に対する耐性を高める
• 障害時にユーザーへ速やかに状況を共有し、リトライや問い合わせの方針を明確に伝える
• 一時的なセキュリティ要件緩和のルールと、復旧後の巻き取り手順をあらかじめ決めておく

Azure AD B2Cは非常に強力なID基盤ですが、その上にビジネスを乗せる以上、「クラウド側で障害が発生することもある」という前提で設計・運用を行うことが欠かせません。本記事の内容を、自社サービスのサインアップ／認証フローの見直しに役立てていただければ幸いです。