Partner CenterからEntra IDにサインインできないSMS認証エラーの解決策｜MFAブロック解除とAuthenticator設定

Partner CenterにはMicrosoftアカウントで入れるのに、ユーザー管理からEntra ID（旧Azure AD）へ進むとMFAのSMS認証が毎回エラーで止まる――。そんな「どこからも解決できない」状態を、Microsoftサポートのバックエンド解除で復旧した事例をもとに、必要情報の集め方、依頼の進め方、再発防止のMFA設計まで具体的に解説します。

現象の全体像：Partner Centerは入れるのにEntra IDだけ通らない

このトラブルは、Microsoft Storeでアプリを販売している開発者アカウントで起きやすいタイプのひとつです。とくに、Entra ID（テナント）側のユーザーが自分ひとりで、普段はほとんどログインせず「Store API用のアプリケーションキー（クライアントシークレット）を更新するときだけ使う」運用だと、発生した瞬間に詰みやすくなります。

状況を整理すると、次のような「入口の違い」がポイントになります。

操作	ログインできる/できない	使っているアカウントの系統	詰まりやすい理由
Partner Centerにサインイン	できる	Microsoftアカウント（個人用）	この入口ではMFAの方式が別経路になり、通れてしまうことがある
Partner Centerの「ユーザー管理」からEntra IDに進む	できない	組織アカウント（Entra ID）	テナント側のMFA・リスク判定・ブロックの影響を直に受ける
Azureポータル/Entra管理画面へ直接サインイン	できない	組織アカウント（Entra ID）	MFAの登録が崩れていると、別手段へ切り替えられずループしやすい

つまり、Partner Centerに入れること自体は「原因が軽い」ことを意味しません。問題は、Entra ID側のMFAフローが成立しない（または成立させないブロックがかかっている）ことです。

典型症状：SMS認証の下4桁は合っているのに「確認中に問題」で失敗する

今回のケースの核心は、SMS（テキストメッセージ）を選ぶと、表示される電話番号の下4桁は正しいのに、毎回エラーになって先へ進めない点です。加えて、Microsoft Authenticatorにも当該Entra IDが登録されておらず、登録しようとしても「Authenticatorでコードを確認してください」という堂々巡りに入ってしまう――この組み合わせが最悪です。

この状態では、ユーザー側でできる「よくある対処」（ブラウザー変更、キャッシュ削除、時間を置くなど）が効かないことも少なくありません。なぜなら、SMSの配送遅延ではなく、アカウント側でMFAがブロックされている（あるいは“悪い評価”のような扱いになっている）可能性があるからです。

見えている症状	よくある誤解	現実に起きていそうなこと	優先すべき動き
SMS認証で毎回エラー、下4桁は正しい	携帯キャリアの不調かも	SMS自体ではなく、MFAフロー/アカウントがブロックされている可能性	エラー画面のIDを控え、サポートへエスカレーション
Authenticatorが未登録、追加もできない	アプリを入れ直せば解決	「登録するためにサインインが必要」だが、そのサインインがMFAで止まるループ	ブロック解除→復旧後にAuthenticatorを複数手段で登録
Partner Centerのサポートチケットが見えない	自分が操作を間違えた	作成したアカウント/ディレクトリが違う、権限が不足、表示UIの問題なども起きうる	別ブラウザー/別端末で確認しつつ、最終的にMicrosoftサポートへ直行

最短で復旧した解決策：Microsoftサポートに「バックエンドでの解除」を依頼する

この手の「MFAが成立しない」「別の認証方法に切り替えられない」「管理者が自分だけ」という詰み状態は、管理画面上の操作で解除できないことがあります。実際に復旧できた決め手は、Microsoftサポートがバックエンドで次の状態を解除したことでした。

アカウントにかかっていたMFAのブロック
“bad reputation（悪い評価）”のような扱いで弾かれていた状態

解除後は、同じ電話番号・同じSMS認証でも正常にコードが届き、サインインが完了しました。ここがポイントで、「SMSが届かない」ではなく「SMS認証が通らない」場合、ユーザー側の努力で粘り続けるより、早めにサポートにログ調査を依頼したほうが結果的に早いケースがあります。

サポートに渡すべき情報：これが揃うと調査が進む

サポート側から「非公開で共有してほしい」と案内されやすい情報は、ほぼ決まっています。これはサポートが内部ログを追うための鍵になるためです。やり取りを短縮したいなら、最初からまとめて用意しておくのがおすすめです。

項目	なぜ必要か	メモのコツ
Correlation ID（相関ID）	サインイン処理の関連ログを結び付ける	エラー画面の「詳細」等に表示されることが多い。スクリーンショット推奨
Request ID（要求ID）	個別の要求を特定し、処理結果を追える	Correlation IDとセットで控える
エラー発生日時	ログの時間範囲を絞れる	タイムゾーンも一緒に（例：JST）
対象のメールアドレス	どのユーザーのサインインかを確定する	別名/別UPNがあるなら両方
電話番号	SMS先が正しいか、MFA側の状態を確認できる	国番号を含める/含めないはサポートの指示に従う
国名	SMSルーティングや規制・判定条件の切り分けに使うことがある	居住国/回線契約国が違う場合は両方書く

特にCorrelation ID / Request IDは、「その瞬間の失敗」を切り出せるので強力です。ブラウザーを閉じる前に必ず控えてください。

エラー画面で「何を控えるか」チェックリスト

うまくいかないときほど焦って画面を閉じがちですが、復旧の近道は“証拠”を揃えることです。次の項目は、可能な限り控えておくとサポートが動きやすくなります。

控えるもの	具体例	控え方
表示されたエラーメッセージ	「アカウントの確認中に問題が発生しました。もう一度お試しください。」	全文をコピー、またはスクリーンショット
エラーコード	英数字の短いコードが出る場合	間違いが怖いのでスクリーンショットが確実
Correlation ID / Request ID	GUIDのような形式で表示されることが多い	文字列をコピペできるならそのまま保管
発生日時	例：12:34:56	タイムゾーン（JSTなど）も付ける
試した認証方法	SMS/音声/Authenticator など	「SMSを選んだ」など行動ログとして残す

サポート依頼の伝え方テンプレ

サポートとのやり取りでは、状況説明が長くなるより「ログが追える情報が揃っている」ほうが解決に直結します。以下は、チャット/メールでそのまま使える形のテンプレです（個人情報は置き換えてください）。

件名：Entra ID サインイン時のSMS認証が失敗し、MFAが完了できない

状況：
- Partner Center には Microsoft アカウントでサインイン可能
- Partner Center の「ユーザー管理」等から Entra ID サインインに進むと MFA が要求される
- SMS を選択すると電話番号の下4桁は正しいが、毎回エラーで先に進めない
- Microsoft Authenticator は未登録で、登録もサインインループで完了できない
- テナントのユーザー（管理者）は自分のみのため、自力でMFAリセットできない

調査用情報（非公開で共有）：
- Correlation ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- Request ID：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
- 発生日時：YYYY/MM/DD HH:MM:SS （JST）
- 対象メールアドレス：[email protected]
- 電話番号：+xx-xxxx-xxxx（または国番号含む形式）
- 国名：Japan

依頼：
- バックエンド側でMFAブロックや判定（bad reputation 等）があれば解除をお願いします。

ポイントは「テナントの管理者が自分だけで、MFAの復旧経路がない」ことを明確に書くことです。これにより、サポート側も“通常の手順案内では解決しない”と判断しやすくなります。

復旧後にやること：目的の作業を済ませる前に「二度と詰まない」準備をする

ブロック解除でサインインできるようになったら、まず目的だった作業（Store APIアプリの新しいアプリケーションキー発行）に取りかかりたくなります。しかし、先に最低限のMFA冗長化を作っておくほうが安全です。復旧直後は、設定変更のウィンドウが開いていることも多く、登録もスムーズだからです。

おすすめの順番は次の通りです。

SMSでサインイン完了（まずは入れる状態を確認）
Microsoft Authenticatorを登録（メイン手段へ）
予備のサインイン方法を追加（複数用意）
Store APIアプリのキーを更新（運用の本題）
もう一度サインインテスト（SMSとAuthenticatorの両方）

なぜSMSは“メイン”にしない方がいいのか

SMS／音声通話は手軽ですが、攻撃者に狙われやすい経路でもあります。代表的なリスクとして、電話番号の乗っ取り（SIMスワップ）や、通話・SMSを悪用する詐欺（国際電話を絡めた不正課金など）が知られています。さらに、今回のように「SMSが使えないと何もできない」状態になりやすいのも運用上の弱点です。

そのため、日常運用ではMicrosoft Authenticator（プッシュ承認／ワンタイムコード）をメインにし、SMSはサブ（復旧用の選択肢）として残す、という設計が現実的です。

認証方法	安全性の考え方	使い勝手	おすすめの位置づけ
Microsoft Authenticator（プッシュ承認）	端末所持前提＋追加の保護が可能で比較的強い	通知を承認するだけで早い	メイン
Microsoft Authenticator（ワンタイムコード）	プッシュが受け取れない状況でも使える	コード入力が必要	メイン/サブ両対応
SMS（テキストメッセージ）	攻撃対象になりやすく、配送・判定で詰まることがある	届けば簡単	サブ（復旧用）
音声通話	環境によって受電できない/詐欺悪用の懸念	受け取れる環境なら簡単	サブ（状況次第）
セキュリティキー（FIDO2等）	強固。端末依存も少なく、管理者アカウントに特に有効	初期設定は手間だが運用は楽	メイン（管理者）、または強力な予備
バックアップコード/回復手段	最後の命綱。保管方法が安全性を左右する	必要な時だけ使う	緊急用

Authenticator登録を確実に成功させるコツ

復旧直後にAuthenticator登録をする際は、次のコツを意識すると失敗しにくくなります。

登録はPCのブラウザーで開始し、スマホでQRを読む：画面の行き来が減り、ループを避けやすい
登録後、必ず「サインインテスト」をする：登録しただけで安心しない（プッシュ承認とコードの両方を試す）
予備デバイスにも登録：機種変更や故障が現実に起きる。余裕があるなら2台目にも入れる
既定の認証方法を見直す：意図せずSMSが既定のままだと、次回またSMSに誘導されることがある

「Authenticatorでコードを確認してください」ループを踏んだ経験がある場合、復旧後はなおさら、登録→テスト→予備の追加までを一気に済ませるのが安全です。

一人テナント（管理者が自分だけ）での再発防止：やるべき最重要対策

今回のようなロックアウトが致命傷になりやすいのは、管理者が自分ひとりのテナントです。事業規模が小さいほど「面倒だから1アカウントで回す」運用になりがちですが、いざという時に復旧できず、APIキー更新もできなくなります。

現実的な落とし所として、次のような対策をおすすめします。

リスク	起きると何が困るか	実務的な対策
管理者が自分1人	MFAリセットもユーザー追加もできない	管理者をもう1つ用意（緊急用アカウント）。普段は使わず安全に保管
MFA手段がSMSのみ	SMSが通らないと即詰み	Authenticatorをメインにし、SMS/音声/キー/緊急用の複数手段を登録
ログイン頻度が低い	電話番号変更・端末故障に気づけない	年1回（できれば半年に1回）ログインテスト。社内メモに予定化
秘密情報の保管が属人的	キー更新時に混乱、復旧が遅れる	パスワードマネージャーで一元管理。緊急連絡手順も短くまとめて保存

“緊急用アカウント（いわゆるブレークグラス）”を用意する場合は、普段の利用から分離し、強固なパスワードと強い認証手段（セキュリティキー等）を検討してください。重要なのは「使うため」ではなく「最後に必ず戻ってこられるため」に存在させることです。

Store API用アプリケーションキー更新の安全な手順

今回の動機になっていた「2年ごとのアプリケーションキー作り直し」は、運用上よくあるタスクです。ここで焦って古いキーを消したり、更新順序を間違えると、アプリや自動化が止まります。復旧後は次の手順で落ち着いて回すのが安全です。

対象のアプリ登録（アプリケーション）を特定する
新しいクライアントシークレット（アプリケーションキー）を追加する
アプリ側（Store APIを呼ぶ側）の設定を新しいシークレットに差し替える
動作確認（実際にAPIが通ることを確認）
猶予期間を置いて古いシークレットを無効化/削除する

運用のコツは「旧キーを残したまま新キーを作り、切り替えたらテストしてから旧キーを片付ける」です。いきなり旧キーを消すのは、障害対応を自分で増やすだけになりがちです。

チェック項目	確認ポイント	失敗例
新旧キーの併存期間	切り替えのために短期間は両方を有効にする	作った直後に旧キーを削除し、稼働中の処理が落ちる
更新先の設定箇所	本番/検証/自動化スクリプトの全てに反映	本番だけ更新し、バッチだけ古いまま
期限の見える化	次回更新日をカレンダーに入れる	期限切れ当日に気づいて夜中に対応
最終テスト	実際のAPIコールが成功すること	管理画面で作っただけで安心し、実行時に失敗

Partner Centerのサポートが見えない/進めない時の現実的な切り分け

「サポートチケットがPartner Center上から参照できず、完全に行き詰まった」という状況も、ロックアウトを深刻化させます。ここでは、原因が一つに限定できない前提で、現実的な切り分けをまとめます。

サインインしているアカウントが一致しているか：チケットを作成したアカウントと、今見ているアカウントが違うと見えません（Microsoftアカウントと組織アカウントの混在が典型）
ディレクトリ（テナント）選択が一致しているか：同じメールに見えても、紐づくテナントが異なると権限や表示が変わります
ブラウザー/端末/セッションの問題を除外する：シークレットウィンドウ、別ブラウザー、別端末で再現するか確認
結論として「ログ調査が必要」ならサポートに直行：UIの問題を疑い続けるより、Correlation ID等を添えて調査依頼した方が早い

このケースでは、最終的にMicrosoftサポート側がバックエンドで解除できたため、表示や操作の問題に見えても「アカウントの状態」が根本原因になっていることがあります。

よくある質問

Partner Centerには入れるのに、なぜEntra IDだけMFAで止まるのですか？

Partner Centerに入れている経路がMicrosoftアカウント中心で、Entra ID側の認証・条件・ブロックを直接踏んでいない可能性があるためです。一方、ユーザー管理などEntra IDに紐づく操作では、テナント側のMFA状態がそのまま影響します。

SMSがエラーなら、SMSの電話番号を変えれば解決しますか？

番号が古い/失効している場合は有効ですが、今回のように「下4桁が正しく表示されているのに毎回失敗」する場合、番号の問題ではなくアカウント側のブロックや判定が絡むことがあります。番号変更だけで解決しないなら、エラー画面のIDを控えてサポートに調査を依頼するのが現実的です。

Authenticatorが未登録の状態で詰んだら、登録だけ先にできますか？

多くの場合、Authenticatorの登録自体にサインインが必要です。つまり、MFAが通らないと登録にも到達できず、ループになります。このループを断つには、管理者が別にいてMFAリセットできるか、サポート側のバックエンド解除が必要になることがあります。

ブロック解除後、最初に何をすべきですか？

まずサインインできることを確認し、次にAuthenticatorを登録して認証手段を複線化してください。目的の作業（キー更新）を急ぐ気持ちは分かりますが、復旧直後が一番「二度と詰まない」設定を作りやすいタイミングです。

復旧後の最終チェックリスト

「入れるようになった」で終わらせず、再発防止まで含めて締めるためのチェックリストです。

項目	完了条件	メモ
SMSでサインイン成功	同じ端末・同じ環境で再現性がある	復旧確認として1回だけでなく、最低2回は確認すると安心
Authenticator登録	プッシュ承認/コード入力の両方が使える	通知が届かない環境もあるのでコードも試す
予備の手段追加	少なくとも2〜3種類の手段が使える	SMS/音声/予備デバイス/セキュリティキー/緊急用などから選ぶ
Store APIキー更新	新キーでAPIが通る	旧キー削除はテスト後。併存期間を作る
次回の更新とログインテスト	カレンダーに予定化	「年1回ログイン」を決めておくと事故が減る

まとめ：解決の要点は「ログで追える情報」と「MFAの複線化」

Partner CenterからEntra IDにサインインできず、SMS認証が毎回エラーになる問題は、ユーザー側の操作で解けないブロックが絡むことがあります。復旧の近道は、エラー画面のCorrelation ID/Request IDと発生日時などを揃え、Microsoftサポートにバックエンド調査と解除を依頼することです。

そして、復旧できたら必ず「Authenticatorをメインにして、予備手段も複数登録する」運用に切り替えてください。特に管理者が自分ひとりのテナントでは、MFA手段が単一だと再発時に復旧できず、ビジネスに直撃します。今回の経験を「二度と詰まない設計」に変えることが、最終的に一番の時短になります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。