Microsoft 365 のデスクトップアプリ（Outlook／Teams／Office）だけサインインが終わらず、認証画面が何度も表示されて先に進まない――この症状は、OS やテナント全体の障害ではなく「その Windows ユーザー プロファイル内」に残った認証キャッシュの不整合が原因で起きることがあります。本記事では Microsoft.AAD.BrokerPlugin.exe エラーを伴う“認証ループ”の考え方と、効果が出やすい順の対処手順、最終手段としてのユーザー プロファイル再作成までを具体的にまとめます。
Microsoft 365 デスクトップアプリが認証ループするとは
典型的な症状は次のようなものです。
- Outlook／Teams／Word／Excel などのデスクトップアプリでサインインを求められる
- メールアドレス・パスワード・MFA までは通るのに、完了せず再びサインイン画面に戻る（ループ）
- 同じアカウントでも ブラウザー（office.com 等）では正常
- 同じ PC でも 別の Windows セッション（別ユーザー）だと正常
- イベント ビューアーに Microsoft.AAD.BrokerPlugin.exe に関連するエラーが記録されている
この組み合わせは、「アプリ自体の故障」や「アカウントのパスワード間違い」というより、WAM（Web Account Manager）／AAD Broker Plugin が参照するユーザー単位のトークン／資格情報が破損・矛盾している可能性を強く示します。
まず押さえる結論：直らない場合はユーザー プロファイル再作成が最も確実
先に結論だけ整理します。
- 優先度の高い対処は、「職場または学校アカウントの切断」→「資格情報の削除」→「WAM/Broker キャッシュ削除」→再起動です。
- それでも改善しない場合、最終的な解決策として Windows のユーザー プロファイルを再作成すると復旧するケースが多いです。
実務的には、同一アカウントがブラウザーや別セッションで正常＝テナント側の条件付きアクセスやアカウント状態が主因ではない可能性が高く、“当該プロファイル内の認証材料だけ”が壊れているパターンに一致します。ここを割り切って、段階的にキャッシュを整理し、最後はプロファイルを作り直すのが最短ルートになりやすいです。
なぜ起きるのか：WAM と AAD Broker Plugin の仕組みを知る
Microsoft 365 のデスクトップアプリは、近年の “モダン認証” では次の要素でサインインを成立させます。
| 要素 | 役割 | ポイント |
|---|---|---|
| WAM（Web Account Manager） | Windows 側のアカウント連携・トークン取得を仲介 | アプリごとではなく OS の仕組みとして動く |
| AAD Broker Plugin（Microsoft.AAD.BrokerPlugin.exe） | Entra ID（旧 Azure AD）向けサインインとトークンのブローカー | ユーザー プロファイル配下のキャッシュに依存 |
| MSAL / OneAuth / TokenBroker 系キャッシュ | 取得したトークンや関連情報を保持 | 残留・破損すると “正しい認証ができているのに完了しない” が起きやすい |
そして、次の条件が揃うと “認証ループ” が起きやすくなります。
- オンプレ AD → Entra ID のハイブリッド（ハイブリッド参加／移行）を経たユーザー
- 過去の ADAL（旧式）や旧 Teams／旧 Office 由来の資格情報がプロファイル内に残留
- ユーザーだけが使うキャッシュ（OneAuth／TokenBroker／BrokerPlugin パッケージ）が不整合
このとき、アプリは “サインインを完了するための最後のトークン受け渡し” で失敗し、再びサインインを求める挙動になりがちです。ブラウザーが正常なのは、ブラウザーが別の認証経路（Cookie/セッション・Web のフロー）で成立しているためで、デスクトップアプリ側の WAM/ブローカーが壊れていることと矛盾しません。
状況別の見立て（早い段階で判断するための表）
原因の見立てを誤ると、Office の再インストールや Teams の再セットアップを何度繰り返しても時間だけ溶けがちです。まずは次の表で、どこに焦点を当てるべきか整理します。
| 観察できる事実 | 示唆 | 狙うべき対処 |
|---|---|---|
| 同一アカウントがブラウザーでは正常 | アカウント停止やパスワード誤りの線は薄い | デスクトップの WAM/キャッシュを疑う |
| 同一 PC の別 Windows ユーザーでは正常 | PC 全体の破損より “当該ユーザー プロファイル” が怪しい | 資格情報／TokenBroker／OneAuth／BrokerPlugin を整理 |
| イベント ビューアーに Microsoft.AAD.BrokerPlugin.exe エラー | ブローカーがトークン処理で落ちている可能性 | BrokerPlugin パッケージ配下のキャッシュ削除 |
| 端末が Intune 管理・条件付きアクセスあり | 準拠・デバイス条件でブロックされることも | Entra 側のサインインログ／CA を確認（本記事は未登録前提） |
実施前の注意点（必ずバックアップするもの）
認証ループ対策は、ユーザー プロファイル内のキャッシュや資格情報を削除するため、作業前に最低限のバックアップを推奨します。特に「最終手段：ユーザー プロファイル再作成」を視野に入れるなら、先にチェックリスト化しておくと安全です。
| 項目 | バックアップ推奨 | 代表的な場所（例） | 補足 |
|---|---|---|---|
| Outlook の PST | 必須 | ユーザーが保存した場所（例：ドキュメント配下など） | OST は再生成されることが多いが、PST は手動移行が必要 |
| Outlook 署名 | 推奨 | %AppData%\Microsoft\Signatures | プロファイル再作成時に消えやすい |
| Office テンプレート | 必要に応じて | %AppData%\Microsoft\Templates | 社内テンプレートや個人の定型がある場合 |
| デスクトップ/ドキュメント | 推奨 | C:\Users\ユーザー名\Desktop / Documents | OneDrive 同期でも念のため確認 |
| ブラウザーのお気に入り | 必要に応じて | Edge/Chrome の同期状況に依存 | 同期が切れている端末では手動移行が必要 |
重要：認証ループの原因になりやすいのは AppData 配下の認証キャッシュです。プロファイル再作成の際に、古い AppData を丸ごとコピーすると “壊れているキャッシュ” まで引き継いで再発することがあるため、移行対象は慎重に選びます（後述）。
推奨フロー（効果が出やすい順）
ここからは、実際に現場で効果が出やすい順に並べた手順です。途中で改善したら先へ進む必要はありません。作業の前に、Outlook／Teams／Office アプリをすべて終了し、可能であれば OneDrive など同期系も一時停止しておくと削除がスムーズです。
職場または学校にアクセスする からアカウントを切断する
まずは Windows 側にぶら下がっている “組織アカウント” の接続情報をいったん外します。ここが中途半端に残っていると、後工程でキャッシュを消しても復旧が不完全になることがあります。
- 設定 → アカウント → 職場または学校にアクセスする（ブリーフケースのアイコン）
- 組織アカウントを選択 → 切断
切断後、念のため同画面に “想定外のアカウント” が残っていないか確認します。複数のテナントに接続していた履歴がある端末では、古い接続が残っていることがあります。
資格情報マネージャーを徹底的にクリアする
次に、Windows が保持している資格情報（Credential Manager）を整理します。ここに古いトークン情報や誤ったエントリが残ると、WAM の流れが歪んでループしやすくなります。
- コントロール パネル → 資格情報マネージャー
- Windows 資格情報 と 汎用資格情報 を確認
削除対象の目安（組織アカウントに紐づくもの）を挙げます。環境により名称は異なりますが、次のキーワードが含まれるものは候補になりがちです。
| よくあるキーワード | 関連 | 削除の判断基準 |
|---|---|---|
MicrosoftOffice16_ | Office の資格情報 | 組織アカウントのメールアドレス/ドメインに紐づくもの |
ADAL | 旧式の認証（移行時に残りやすい） | ハイブリッド移行を経ている場合は特に整理対象 |
MSAL | 現行の認証ライブラリ | ループが出ているなら一度消して再生成させる |
OneAuth | 統合認証コンポーネント | Microsoft 365 系の残留が疑わしい場合に整理 |
Teams / msteams | Teams のサインイン情報 | Teams だけでなく Office 全体のループでも影響する場合あり |
削除のコツは、「とにかく全部消す」ではなく、組織アカウントに関連するものを漏れなく消すことです。個人の別サービスや業務に関係ない資格情報まで消すと、別のアプリの再サインインが必要になるため、影響範囲を理解しながら進めてください。
Broker / WAM キャッシュ（ユーザー プロファイル配下）を削除する
認証ループで最も効きやすいのがここです。デスクトップ版 Office/Teams は WAM と AAD Broker Plugin を介してトークンを持つため、ユーザー プロファイル配下のキャッシュが壊れていると “正しい手順で認証しているのに完了しない” という現象になりがちです。
以下のフォルダを順に開き、中身を削除します。削除できない場合は、いったんサブフォルダ内から削除していくか、フォルダ名を _old などにリネームして退避しても構いません（復旧検証後に完全削除）。
%LocalAppData%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
%LocalAppData%\Microsoft\OneAuth
%LocalAppData%\Microsoft\TokenBroker
%LocalAppData%\Microsoft\IdentityCacheそれぞれの役割イメージを簡単にまとめます。
| パス | 何が入っているか | 削除の狙い |
|---|---|---|
...\Microsoft.AAD.BrokerPlugin_... | AAD ブローカーのアプリ パッケージデータ | Broker が参照する状態を初期化して矛盾を解消 |
...\Microsoft\OneAuth | 認証コンポーネント関連のキャッシュ | 古いトークン/状態の残留を消す |
...\Microsoft\TokenBroker | WAM/ブローカーが扱うトークンのキャッシュ | ループの温床になりやすい領域をクリア |
...\Microsoft\IdentityCache | ID 関連のキャッシュ | 不整合があるとサインイン完了時に失敗しやすい |
削除後は、アプリ側から見ると “初めてサインインする端末” に近い状態になります。つまり、ここで直るなら原因はほぼキャッシュです。逆に直らない場合、キャッシュ以外（プロファイルの破損、アカウント接続のねじれ、端末参加状態の不整合など）を疑う段階に進みます。
PC を再起動し、Office/Teams でサインインをやり直す
キャッシュ・資格情報削除の直後は、バックグラウンドに残っているプロセスが古い状態を掴んでいることがあります。ここは “再起動が効く場面” なので、作業後は必ず再起動します。
再起動後のサインインは、次の順序を推奨します。
- まずは Office（Word/Excel など） でサインイン
- 次に Outlook のプロファイル／アカウント設定
- 最後に Teams（サインインと組織切り替え）
理由は、Office のサインインが WAM の土台を作り、Outlook/Teams がその上に乗る形になりやすいからです。Teams から先に触ると、WebView2 を介した挙動が絡み、切り分けが複雑化することがあります。
改善しない場合の最終手段：Windows ユーザー プロファイルを再作成する
ここまでで直らない場合、当該ユーザー プロファイル全体に “見えない破損” が残っている可能性が上がります。イベントビューアーに Microsoft.AAD.BrokerPlugin.exe が出続け、他のユーザーだと正常、ブラウザーも正常という状況では、プロファイル再作成が最短で確実になることが多いです。
代表的な再作成パターンは 2 つあります。現場の制約（ドメイン環境の権限、PC の管理方針）に合わせて選んでください。
| 方法 | 概要 | メリット | 注意点 |
|---|---|---|---|
| 新規ユーザーで運用開始 | 新しいローカル/ドメインユーザーでログオンして移行 | 切り分けが明確で速い | ユーザー名変更や権限設計が必要な場合がある |
| 既存ユーザーのプロファイルを作り直す | 既存プロファイルを削除し、同じユーザーで再ログオン | 同じユーザー（同じ SID）で戻せる | 削除手順を誤るとデータを失う。バックアップ必須 |
既存ユーザーのプロファイルを作り直す場合の流れ（安全寄りの例）を示します。手順は組織の標準運用に従ってください。
- 必要データをバックアップ
デスクトップ、ドキュメント、ダウンロード、PST、署名、テンプレートなど（前述の表を参照）。 - 別の管理者アカウントでログオン
当該ユーザーでログオンしたままではプロファイルの削除ができないため、管理者で作業します。 - 古いプロファイルを退避（リネーム）
例：C:\Users\ユーザー名をC:\Users\ユーザー名_oldに変更。
退避しておけば、移行漏れがあっても取り戻せます。 - ユーザー プロファイルを削除
OS の GUI（ユーザー プロファイル管理）から削除する方法が一般的です。環境により操作箇所は異なりますが、目的は “プロファイル参照を消して、次回ログオンで新規生成させる” ことです。 - 対象ユーザーでログオンして新規プロファイルを生成
初回ログオン時にプロファイルが作られます。 - 必要データのみ移行
ここが重要です。AppData を丸ごと戻さない（特に LocalAppData の TokenBroker/OneAuth/BrokerPlugin は戻さない）。
移行の「おすすめ」と「避けたいもの」を表にしておきます。プロファイル再作成で直ったのに、古いキャッシュを戻して再発…は現場あるあるです。
| 移行対象 | 推奨度 | 理由 |
|---|---|---|
| Desktop / Documents / Downloads | 高 | ユーザーデータの本体。認証ループの原因になりにくい |
| Outlook 署名（Signatures） | 中 | 再作成が面倒。必要ならフォルダ単位で移行 |
| PST（手動で保存している場合） | 高 | ローカル資産。戻さないと参照できない |
| AppData\Local\Microsoft\TokenBroker | 不可 | 認証キャッシュの中心。戻すと再発しやすい |
| AppData\Local\Microsoft\OneAuth | 不可 | 統合認証キャッシュ。壊れている可能性が高い |
| AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_… | 不可 | ブローカーの状態が戻ってしまう |
プロファイルを作り直すと、認証基盤（WAM/Broker）がまっさらになり、サインインが通るようになることが多いです。今回のように、レジストリ削除・アプリリセット・キャッシュ削除で改善しないケースでも、プロファイル再作成で一撃で復旧するのが典型です。
追加の切り分け：dsregcmd /status で参加状態を確認する
ハイブリッド（オンプレ AD + Entra ID）環境では、端末の参加状態がねじれていると認証が不安定になります。必ずしも今回の主因とは限りませんが、プロファイル再作成まで進む前に確認しておくと “後戻り” が減ります。
管理者権限のコマンドプロンプトで次を実行します。
dsregcmd /status注目したいのは次の項目です。
| 項目 | 意味 | 見方の例 |
|---|---|---|
| DomainJoined | オンプレ AD ドメイン参加 | ドメイン環境なら YES が一般的 |
| AzureAdJoined | Entra ID 参加（Azure AD Join） | ハイブリッド参加なら YES になることが多い |
| WorkplaceJoined | 職場/学校アカウントの登録（Azure AD Registered） | 状況により YES/NO。想定とズレがないか確認 |
ここで “想定外の組み合わせ” が見える場合は、端末参加やアカウント登録の状態が崩れている可能性があります。例えば、運用としてハイブリッド参加のはずなのに AzureAdJoined が NO のまま、または WorkplaceJoined が複数アカウントに引きずられている、などです。こうした場合は、端末側の切断・再参加（組織の標準手順）を検討します。
注意：端末の参加状態を変える操作は、業務アプリやセキュリティ要件に影響します。やみくもに参加解除コマンドを打つのではなく、組織の手順（GPO、Entra の構成、証明書配布、SSO 設計）に沿って実施してください。
「レジストリの継承 Disable Inheritance」は原因になり得る？
切り分け中に「権限の継承が無効（Disable Inheritance）になっている」ことが気になって手が止まることがあります。しかし、この表示自体は環境の設計や過去の変更によって見え方が変わるため、それ単体で認証ループの直接原因と断定しにくいです。
もちろん、極端に権限が壊れていて BrokerPlugin のフォルダにアクセスできない、TokenBroker の書き込みが拒否される、といった状況なら影響しますが、その場合は削除や再生成の段階で “アクセス拒否が頻発する” など、より明確な兆候が出ます。今回のように、キャッシュ削除やリセットをしても改善せず、別セッションでは正常という状況では、まずは ユーザー単位の認証キャッシュ／プロファイル不整合を優先して疑うのが合理的です。
Intune 未登録でも起きる？ 条件付きアクセスとの関係
本記事の前提は「オンプレ AD + Entra ID のハイブリッドで、端末は Intune 未登録」です。この条件でも認証ループは十分起きます。なぜなら、問題の中心が “ユーザー プロファイル内の WAM/Broker キャッシュ” であり、Intune 登録の有無とは独立して発生するからです。
一方で、端末が Intune 管理下だったり、条件付きアクセスで “準拠デバイス必須” のポリシーが強い場合は、デスクトップアプリのサインインがブロックされることがあります。ただしその場合、ブラウザーでもブロックされる・サインインログに明確な失敗理由が出るなど、症状の出方が変わるのが一般的です。
現場で効く：作業を成功させるコツ
同じ手順でも、実施の仕方で成功率が変わることがあります。再発やハマりを防ぐためのコツをまとめます。
削除前に “完全にアプリを閉じる” を徹底する
- Outlook を閉じるだけでなく、タスク トレイに残る常駐（Teams、OneDrive、Office 関連）も終了
- 消せないフォルダがある場合は、いったん再起動して直後に削除を試す
キャッシュは「削除」より「退避（リネーム）」でもよい
手順に慣れていない場合や、影響範囲が不安な場合は、フォルダ削除の代わりにリネームが安全です。例：
%LocalAppData%\Microsoft\TokenBroker
→ TokenBroker_oldこうしておけば、万一別の業務アプリに影響が出た場合でも、戻して比較できます（ただし認証ループが再発する可能性もあるため、復旧後は不要な退避フォルダは整理します）。
再ログインの順番で切り分けを楽にする
Office → Outlook → Teams の順でサインインすると、どの段階で詰まるかが分かりやすくなります。Teams は WebView2 を使った挙動や組織切り替えが絡みやすいので、最後に回すほうがトラブルシュートがシンプルです。
よくある質問
Office の再インストールをしても直らないのはなぜ？
認証ループの主因が “Office 本体” ではなく、Windows 側の WAM / AAD Broker Plugin と、そのユーザー プロファイルにあるキャッシュである場合、Office を再インストールしてもキャッシュが残っていれば症状は変わりません。だからこそ、資格情報と TokenBroker/OneAuth/BrokerPlugin の整理が先になります。
Teams だけがおかしいように見えるが、Office 側の作業も必要？
必要になることがあります。Teams と Office は同じ認証基盤を共有する場面が多く、片方だけ直してもループが再燃することがあります。特に「Outlook も Teams も同じようにループする」ケースは、共通基盤（WAM/Broker）の初期化が効果的です。
プロファイル再作成は大げさでは？
確かに “最後の手段” ではありますが、別セッションで正常という条件が揃っている場合、原因がユーザー プロファイルに局在している可能性が高いので、合理的な打ち手です。ポイントは、再作成後に AppData の認証キャッシュを戻さないこと。ここを守れば再発率は下がります。
再発防止のヒント（ハイブリッド移行・端末入れ替え時の運用に組み込む）
認証ループは “ある日突然” 起きることもありますが、背景に移行・端末入れ替え・アカウント切り替えがあることが多いです。再発を減らす運用上のヒントをまとめます。
- オンプレ → ハイブリッド移行直後は、WAM/OneAuth/TokenBroker 系の残留が出やすい。トラブル時は早い段階でキャッシュ整理を検討する。
- 端末共有・ユーザー切替がある環境では、「職場/学校アカウントの切断」→資格情報削除→再起動を標準手順としてドキュメント化する。
- Outlook は OST が再生成される前提でも、PST/署名/テンプレートは手動移行が必要。バックアップ箇所をチェックリスト化する。
- トラブルシュート時は「ブラウザーで正常か」「別 Windows ユーザーで正常か」を最初に確認し、原因をユーザー プロファイル側に寄せて考える。
まとめ
- Microsoft 365 デスクトップアプリの認証ループは、WAM + AAD Broker Plugin が参照するユーザー単位のキャッシュ不整合で起きやすい。
- 対処は、職場/学校アカウント切断 → 資格情報削除 → Broker/Token 系キャッシュ削除 → 再起動が基本。
- 直らない場合は、Windows ユーザー プロファイル再作成が最も確実な解決策になりやすい（特に別セッションで正常な場合）。
コメント