Microsoft 365の認証が繰り返され、Microsoft.AAD.BrokerPlugin.exeやMicrosoft.AAD.BrokerPlugin_cw5n1h2txyewyがログに出る場合は、まずエラー全文と対象ユーザーを確認します。WAMの登録不備は調査対象ですが、アカウント切断・認証フォルダー削除・Windowsプロファイル再作成を一律に行う前に、ブラウザーとの比較と登録状態、組織の認証ログを照合します。
Microsoft.AAD.BrokerPluginの名前がログにあるだけで認証キャッシュの破損と決めず、問題が起きるWindowsユーザーの登録状態と、失敗時のサインインログを照合します。
Microsoft.AAD.BrokerPluginとは何か
MicrosoftのWAM説明では、Web Account ManagerはWindowsに含まれる認証仲介のコンポーネントです。Windowsが認識しているアカウントとアプリを連携させ、認証とトークンの維持に関わります。Microsoft.AAD.BrokerPluginは、職場・学校アカウント向けのWindows認証を調べるときに確認するパッケージです。
| 名前・場所 | 確認するときの意味 |
|---|---|
| Microsoft.AAD.BrokerPlugin | Get-AppxPackageで調べるパッケージ名 |
| Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy | パッケージの識別名。ログやユーザー側のPackagesフォルダー等に表示される |
| Microsoft.AAD.BrokerPlugin.exe | ブローカーの実行ファイル名。失敗ログでは障害モジュールや時刻も確認 |
| Microsoft.Windows.CloudExperienceHost | 個人用Microsoftアカウント側の認証で確認する別パッケージ |
名前が見つかったこと自体は、感染や削除対象を示すものではありません。また、SystemApps側のプログラムと、ユーザーのLocalAppData側の状態は別です。後者のフォルダーが存在するだけでは、パッケージが正常に登録・実行できることまで証明しません。
サインイン画面と発生範囲を先に記録する
- Outlook、Teams、Word等のどのアプリで、起動・アカウント追加・ライセンス認証のどの操作が失敗するかを控えます。アプリの版とWindowsのビルドも記録します。
- メッセージ、Code、Tag、Timestamp、Correlation ID、Request ID等、画面に表示される項目をそのまま保存します。
- 同じアカウントで正式なウェブ版へ入れるかを比較します。組織の端末・ネットワークの利用条件に沿って試します。
- 同じPCの別Windowsユーザーや、別の許可されたPCでも起きるかを管理者と確認します。比較時は同じアカウント・アプリ等の条件を揃えます。
| 結果 | 次に確認する範囲 |
|---|---|
| ウェブ版にもサインインできない | アカウント、MFA、利用権、サービスの障害、組織のアクセス条件 |
| Outlookだけが失敗する | Outlookの種類・設定・接続先。Office全体の認証失敗と分ける |
| 複数のデスクトップアプリで失敗する | Windowsの認証パッケージ、通信、セキュリティ製品、サインインログ |
| 同じPCの別ユーザーでは成功する | ユーザー単位の登録・状態・適用設定を比較する |
別ユーザーで成功することは調査範囲を絞る材料です。「必ずキャッシュ破損」「プロファイル再作成が最も確実」とは判断しません。ウェブ版とデスクトップ版では認証経路や評価条件が違うため、ウェブ版が成功しても条件付きアクセスを除外できません。
Get Helpでサインインの診断を実行する
Microsoft 365の現行トラブルシューティングでは、Get Help（問い合わせ）アプリの検索欄へ「sign in to Microsoft Office」と入力するサインイン診断を案内しています。問題が起きるPCで画面に従い、検出された項目と提案を記録してください。サブスクリプションの有効化の問題なら、同ページのライセンス認証診断を選びます。
提案は一つずつ実施して再現するかを確認します。文書や送信中の作業を保存し、対象アプリを終了して再起動する比較も行えます。診断で原因が見つからない場合は、その結果を以降のWAM確認へ引き継ぎます。
問題が起きるWindowsユーザーでWAMの登録を確認する
問題のあるWindowsユーザーでサインインした状態で、Windows PowerShellから次の読み取りコマンドを実行します。別の管理者アカウントの結果ではなく、影響を受けるユーザーの状態を確認してください。コマンドは登録情報の表示で、アカウント・データを削除しません。
Get-AppxPackage Microsoft.AAD.BrokerPlugin
Get-AppxPackage Microsoft.Windows.CloudExperienceHost結果が空の場合は、対象パッケージの登録が見つからない状態です。エラーが出た場合は、エラー全文を記録します。表示がある場合も、サインインウィンドウが正常に動くかは別に調べます。
Microsoftの自動認証失敗の公式手順は、パッケージ情報の欠落を扱い、職場・学校アカウントのMicrosoft Entra WAMと、個人用アカウントのLive IDを分けて確認・再登録しています。Microsoft.AAD.BrokerPluginのフォルダー全体を消す手順と同じではありません。
登録が見つからない職場・学校アカウントの修復
対象アカウント・症状を公式文書と照合し、職場・学校アカウントのパッケージ登録がない場合は、文書に従って再登録を検討します。管理者Windows PowerShellの起動が案内されていますが、問題ユーザーと別の資格情報で実行していないかも管理担当に確認してください。ForceApplicationShutdownを使うため、未保存の作業を保存して関係するアプリを閉じます。
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) {
Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown
}
Get-AppxPackage Microsoft.AAD.BrokerPluginこれは登録がない場合だけAdd-AppxPackageを行い、最後に登録状態を表示する例です。処理がエラーになったら、削除や強制変更を重ねず、メッセージと実行したユーザーを確認してください。登録があり認証もできる場合には、この例を繰り返す必要はありません。個人用アカウントは同じAADパッケージを一律に修復せず、公式文書のLive ID側の手順を参照します。
イベントログでブローカーの障害を照合する
イベントビューアー→Windowsログ→Applicationで、失敗した時刻付近のイベントを確認します。アプリ名だけでなくSource、イベントID、エラーコード、障害モジュール、パッケージ名等を控えてください。AppModel-StateとApplication Errorは、同じ意味のイベントではありません。
Microsoft LearnのデスクトップアプリのWAM障害の資料（現在は旧バージョン資料として公開）は、AppModel-StateにAAD BrokerPluginの設定読み込み・状態修復エラーが出る症状と、セキュリティソフト等がWAMへ影響するケースを説明しています。該当する場合は、登録確認と同じユーザー・時刻でログを突き合わせ、管理者と製品ベンダーへ原因を調べてもらいます。
サインインが一度直っても、再起動・再サインイン後や定期処理の後に再発するかを確認します。繰り返しパッケージを修復して終わりにせず、通信やファイル・レジストリへのアクセスを妨げる要因が残っていないかを調査します。
dsregcmd /statusは参加状態とユーザー状態を分ける
Microsoft Entraのdsregcmd説明に従い、問題ユーザーの通常のコマンドプロンプトで次を実行します。ユーザー状態の確認では、管理者として起動するとWamDefaultSetにエラーが表示される場合があるため、最初から昇格結果だけで判断しません。
dsregcmd /status| 項目 | 確認すること |
|---|---|
| AzureAdJoined / DomainJoined | 端末の参加状態。ハイブリッド参加では両方YES |
| WorkplaceJoined | 現在のユーザーにEntra登録アカウントがあるか |
| WamDefaultSet | 現在のユーザーの既定WAMアカウントが作成されているか |
| AzureAdPrt | 現在のユーザーのPRTの有無。該当する参加方式で確認 |
NOが一つあるだけで異常とは限らず、組織が想定している参加方式と照合します。事前参加診断など昇格が必要な調査は別にあります。出力を見て直ちにdsregcmd /leaveを実行したり、端末を再参加させたりせず、管理者へ結果を渡してください。
ウェブ版が使えても条件付きアクセスは確認する
条件付きアクセスのクライアント条件は、BrowserとMobile apps and desktop clientsを分けて扱えます。アプリ・端末・リソース等で評価が違うため、「ブラウザーが正常ならテナント側は正常」「Intune未登録ならポリシーと無関係」とは言えません。
- 管理者がMicrosoft Entra管理センターのEntra ID→Monitoring & health→Sign-in logsを開きます。閲覧にはReports Reader等の適切な権限が必要です。
- ユーザー、発生時刻、対象アプリ・リソース、Correlation ID等で該当イベントを絞ります。
- 失敗理由とConditional Accessタブの適用ポリシー、端末や認証の詳細を照合します。
手順は条件付きアクセスの失敗調査を参照してください。ブローカーのローカルエラーと、サービス側の失敗記録を分けて調べます。ポリシーが関係する場合は、実際の不一致を管理者が修正します。認証ループだけを理由にMFA等を無効化する必要はありません。
アカウント切断・キャッシュ削除を選ぶ前に
「職場または学校にアクセスする」の接続には、組織の端末参加・登録・管理に関わるものがあります。切断の目的と再接続方法、Windowsへのサインインや業務アクセスへの影響を管理者と確認してください。ブラウザーで成功したという理由だけで、組織接続を先に切断する必要はありません。
資格情報マネージャーでOffice、MSAL、OneAuth等の文字を含む項目をすべて削除したり、LocalAppDataのPackages・TokenBroker・OneAuth・IdentityCacheを一括削除したりする操作は、原因未確認の共通手順にはしません。診断で必要なリセットが特定された場合に、対象アカウント、再サインイン手段、他アプリへの影響を確認して該当の公式手順を使います。
MicrosoftのADAL・WAM無効化に関する資料も、サインインやライセンス認証問題の解決策として無効化することはサポートされないと説明しています。無効化レジストリを追加したり、継承設定の表示だけでアクセス権を一括変更したりする前に、実際のアクセス拒否やエラーと照合します。
Windowsプロファイル再作成を検討する場合
登録修復やログ調査をしてもユーザー単位の問題が続き、プロファイルの破損が疑われる場合は、管理者やサポートと新しいプロファイルでの比較を検討します。旧ユーザーをすぐ削除したり、C:\Usersの名前だけを変更したりせず、必要なデータと移行方法を確認します。
| 移行前に確認するデータ | 確認内容 |
|---|---|
| デスクトップ・ドキュメント・ダウンロード | 実際の保存先とバックアップ。OneDriveの同期完了も確認 |
| Outlookのローカルデータ | PSTの場所と保存、同期されていないメール等の有無 |
| 署名・テンプレート・アプリ設定 | 利用方式と必要な再設定、保存されている場所 |
| 認証情報・隠しシステムファイル | 旧状態を丸ごと新プロファイルへ戻さず、移行対象を確認 |
Microsoftの破損プロファイル修復は、新しいユーザーを作成して必要なファイルをコピーする流れを説明しています。隠しファイルや保護されたOSファイルを表示してコピーしないこと、メールデータ等の別途移行、アプリの再設定が必要になる場合も明記されています。会社のドメイン・Entraユーザーでは、組織の方法と権限に合わせて管理者が判断します。
新しいプロファイルで成功した後も、アプリ・メール・ファイルが使えるかと、次のサインインで再発しないかを確認します。プロファイル作成は、すべての認証ループを確実に解消する方法ではありません。
解決しない場合に渡す情報
- Windowsとアプリの版、アカウント種別、端末の管理・参加方式
- 画面のエラー全文、発生時刻、Correlation ID等と実施した操作
- ウェブ版・他アプリ・別Windowsユーザーでの比較結果
- Get Helpの結果、問題ユーザーでのGet-AppxPackageとdsregcmdの結果
- 同時刻のイベントログと、管理者が確認したEntraサインインログ
これらを組織の管理担当または契約先の窓口へ伝えると、ローカルのパッケージ、通信・セキュリティ製品、サービス側の認証条件のどこを調査すべきか判断しやすくなります。設定を一度に変えず、実施した項目と変化を残してください。
コメント