Microsoft 365のOfficeアプリで「Something went wrong. [657rx]」が出てサインインできない場合、同じアカウントでも“特定PCだけ”発生することがあります。多くは端末側の職場/学校アカウント登録や認証キャッシュの不整合が原因です。直し方を手順と注意点つきで解説します。
よくある症状と発生パターン
「Something went wrong. [657rx]」は、アカウント自体が壊れているというより、そのPCに残っている認証情報・デバイス登録情報のズレが引き金になって起きるケースが目立ちます。次のような状況に当てはまるなら、本記事の手順で改善する可能性が高いです。
- 仕事用（Microsoft 365 for business）の同じアカウントで、別PCはサインインできるのに、特定のPCだけOffice（Outlook/Word/Excel/Teamsなど）で失敗する
- BitLockerの回復キー入力を伴う復旧、TPMの交換・初期化、BIOS設定変更、PCの再セットアップ後から発生し始めた
- Officeアプリだけでなく、サインイン画面自体がループする／認証ウィンドウが一瞬で閉じる／資格情報を入力しても戻される
- 「職場または学校にアクセス（Access work or school）」の状態が怪しい（アカウントが重複して見える、切断できない、表示が消えた等）
| 現象 | 切り分けのポイント | よくある原因 |
|---|---|---|
| 同一アカウントで、AのPCだけOfficeにサインインできない | アカウントより端末側（キャッシュ/登録）の可能性が高い | WAM/AAD Broker Pluginのトークン破損、デバイス登録情報の不整合 |
| BitLocker復旧/TPM変更の直後から発生 | TPMに紐づく暗号鍵・資格情報が再生成され、古いトークンが使えなくなることがある | 端末内に残った古いトークンが失効し、再発行に失敗 |
| ブラウザーのWebサインインも失敗する | 端末要因だけでなく、拡張機能/ネットワーク/ポリシーの影響も疑う | Cookie破損、プロキシ/VPN、条件付きアクセスでブロック |
| 「切断（Disconnect）」がグレーアウト | ユーザー操作が組織ポリシーで制限されている可能性 | Intune/デバイス登録ポリシー、管理者設定により解除不可 |
なぜ「Something went wrong. [657rx]」が起きるのか
Officeのサインインは、単にメールアドレスとパスワードを確認して終わりではありません。WindowsではWAM（Web Account Manager）やAAD Broker Pluginが間に入り、Microsoft Entra ID（旧 Azure AD）との間でトークン（サインインの証明書のようなもの）を保管・更新します。
ところが、次のようなイベントが起きると、PCに保存された情報が古いまま残ったり、暗号化に使う鍵が変わったりして、「トークンはあるのに使えない」状態になりがちです。
- TPMの初期化・交換、ファームウェア更新、BitLocker回復などで、端末の暗号状態が変わる
- Windowsの再セットアップ/プロファイル再構築で、アカウントの登録だけが中途半端に残る
- 条件付きアクセス（準拠デバイス必須、ハイブリッド参加必須など）の要件が変わり、端末の登録状態が要件に合わなくなる
結果として、Office側は「サインインできない」しか表示せず、利用者からは原因が見えにくいのが厄介な点です。そこで、端末内のキャッシュとデバイス登録を“いったん整理して再登録”するのが、最も再現性の高い解決策になります。
まず最短で直す：Windows 10/11の基本手順
以下は、特定PCだけで[657rx]が出る場合に、最初に試してほしい王道手順です。目的はシンプルで、Officeのサインイン情報と「職場/学校アカウント」の登録をきれいに作り直すことです。
注意：作業後はOfficeやTeams、OneDriveなどで再サインインが必要になります。業務影響が出ないタイミングで実施してください。
手順の全体像
| 手順 | やること | 狙い |
|---|---|---|
| Officeからサインアウト | Outlook/Word/Excel/Teamsをサインアウトし完全終了 | 古いトークンを使い続けない状態にする |
| AAD Broker Pluginのキャッシュ削除 | フォルダー内の中身だけ削除 | WAM/トークンの再生成を促す |
| 職場/学校アカウントの再接続 | 「切断」→「接続」で再登録 | Entra IDへのデバイス登録を整える |
| 再起動 | Windowsを再起動 | 認証基盤のプロセス/キャッシュを確実に反映 |
| Officeで再サインイン | 任意のOfficeアプリでサインイン | 正常復帰の確認 |
Officeアプリからサインアウト & 完全終了
- Outlook、Word、Excel、PowerPoint、Teamsなど、開いているOffice関連アプリをすべて閉じます。
- 各アプリでサインアウトできる場合は、先にサインアウトします（例：Word右上のアカウントアイコンからサインアウト）。
- 念のため、タスクマネージャーでOffice/Teams関連プロセスが残っていないか確認し、残っていれば終了します。
AAD Broker Pluginのキャッシュ削除
次のフォルダーは、Windowsのサインイン仲介（WAM）で使われるキャッシュが保存される場所です。ここが壊れていると、正しい資格情報を入力しても「Something went wrong. [657rx]」につながることがあります。
| 項目 | 内容 |
|---|---|
| 対象パス | %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy |
| 操作 | フォルダー自体は削除せず、中身（ファイル/サブフォルダー）だけを削除 |
| 狙い | 破損・不整合のあるトークン/キャッシュを再生成させる |
- エクスプローラーを開き、アドレスバーに次を貼り付けてEnter：
%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy - 開いたフォルダーの中身をすべて削除します（アクセス拒否が出る場合は、Office/Teamsが残っていないか再確認）。
- 削除できないファイルが少数残る場合は、いったんスキップし、次の手順に進んでから再起動後に再度削除を試します。
「職場または学校にアクセス」でアカウントを再登録
Windows検索で「職場または学校にアクセス」（英語OSならAccess work or school）を開きます。ここに表示されるアカウントは、端末が組織（Entra ID/Intuneなど）にどのように登録されているかに直結します。
- アカウントが表示されていない場合：［接続（Connect）］から仕事用アカウントを追加し、サインインします。
- アカウントが表示されている場合：対象アカウントを選択し、可能なら［切断（Disconnect）］で一度解除→その後［接続］で同じアカウントを再登録します。
この操作は「Officeの再ログイン」ではなく、PCが組織に所属しているという情報（デバイス登録）を作り直すイメージです。条件付きアクセスで「準拠デバイスのみ許可」などが有効な環境では、ここがズレているとサインインが通りません。
再起動してからOfficeで再サインイン
- Windowsを再起動します。
- Wordなど任意のOfficeアプリを起動し、仕事用アカウントでサインインします。
- Outlookの場合は、プロファイルの読み込みに時間がかかることがあるため、数分待ってから判定します。
ここまでで改善するケースが非常に多いです。特に、「AAD Broker Pluginのキャッシュ削除」＋「職場/学校アカウントの切断→接続」がセットで効くことが多く、TPM関連の変化があった端末ほど効果が出やすい傾向があります。
「切断」ボタンがグレーアウトしている／押せない場合
「職場または学校にアクセス」で［切断］がグレーアウトしている場合、ユーザーの判断でデバイス登録を外せないように、組織の管理ポリシーがかかっている可能性があります。これはセキュリティ上よくある運用で、利用者側だけで完結しないことがあります。
まず確認したいこと
- 同じPCで、Windowsへのサインインはできているか（ローカル/ドメイン/Entra ID）
- 別ユーザーが同PCでサインインするとどうなるか（ユーザープロファイル依存か端末依存か）
- 会社支給PCで、Intune（MDM）やEDRが導入されているか
管理者に依頼すべき対応例
社内IT管理者（Microsoft 365/Entra ID/Intune管理者）に、次の観点で確認を依頼してください。
| 依頼内容 | 狙い | 管理者側で見る場所の例 |
|---|---|---|
| 該当端末のデバイス登録情報の確認/削除 | 古いDevice IDや重複登録を整理し再登録を促す | Entra IDのデバイス一覧、Intuneのデバイス一覧 |
| 条件付きアクセスの要件確認 | 「準拠デバイス必須」「ハイブリッド参加必須」などに合っているか | Entra IDのサインインログ/条件付きアクセス |
| 端末の準拠状態（Compliance）の確認 | 準拠でないためブロックされていないか | Intuneのコンプライアンスポリシー/状態 |
| TPM/Windows Hello for Businessの再登録 | 鍵の再作成が必要なケースを潰す | Windows Hello設定、Intuneの構成プロファイル |
依頼時は、次の情報を渡すと調査が早く進みます。
- エラー表示：Something went wrong. [657rx]
- 発生するアプリ（Outlook/Word/Teamsなど）と、発生するタイミング（起動直後/アカウント追加時など）
- 発生する端末名、OSバージョン（Windows 10/11/Server）、直前に行った変更（TPM/BitLocker/再セットアップ等）
- 同アカウントが別PCでサインインできる事実（アカウント障害ではない切り分け）
追加で効くことが多いクライアント側の切り分け
基本手順で改善しない場合、次の「端末に残る資格情報」を追加で整理すると改善することがあります。組織ポリシーにより操作が制限される場合もあるため、できる範囲で実施してください。
資格情報マネージャーでOffice関連の資格情報を整理
Windowsの資格情報マネージャーには、OfficeやWeb認証の情報が保存されることがあります。古い情報が残っていると、再サインイン時に誤った認証情報を参照する場合があります。
- Windows検索で「資格情報マネージャー」を開きます。
- 「Windows 資格情報」「汎用資格情報」の両方を確認します。
- Office/Microsoft/ADAL/OneAuth/Teamsなどに関係しそうな項目がある場合、慎重に削除します（削除後は再サインインが必要になります）。
注意：VPNや社内システムの資格情報まで消すと業務影響が出る場合があります。「何の資格情報か不明」なものは無理に削除せず、管理者に相談してください。
「メールとアカウント」「他のアプリで使用されるアカウント」を確認
Windowsのアカウント画面には、「職場/学校にアクセス」とは別に、他のアプリが使うアカウントが残っていることがあります。
- 設定 → アカウント → メールとアカウント
- 設定 → アカウント → 他のアプリで使用されるアカウント
ここに古い職場アカウントが残っている場合、Officeのサインインに影響することがあります。削除できる環境であれば整理し、再起動後に再サインインを試してください。
時刻・証明書・更新プログラムの基本チェック
頻度は高くありませんが、次のような「地味な基本設定」が原因でトークン取得に失敗することもあります。
| チェック項目 | 確認方法 | 問題があると起きやすいこと |
|---|---|---|
| 日時/タイムゾーンが正しい | 設定 → 時刻と言語 | 証明書検証やトークンの有効期限判定が失敗 |
| Windows Updateが適用されている | 設定 → Windows Update | 認証コンポーネントの不具合が残る |
| 社内プロキシ/SSL検査 | ネットワーク担当に確認 | 認証先への通信が改変され失敗 |
Windows Server 2019などサーバーOSでの注意点
Windows Serverでは、クライアントOS（Windows 10/11）とUIや想定用途が異なるため、「職場または学校にアクセス」が見つからない、または同等の画面構成になっていないことがあります。その場合は、コマンドでデバイス登録状態を確認し、管理者権限で対処する流れになります。
デバイス登録状態の確認（dsregcmd）
管理者権限のコマンドプロンプトまたはPowerShellで、次を実行します。
dsregcmd /status出力の見方（代表例）は次のとおりです。環境により表示項目は異なりますが、PRT（AzureAdPrt）やJoin状態が重要です。
| 見る項目 | 意味 | 問題のヒント |
|---|---|---|
| AzureAdJoined / DomainJoined | Entra ID参加、ドメイン参加の状態 | 要件（ハイブリッド参加必須など）と一致しないとブロックされる |
| WorkplaceJoined | 職場アカウントの登録状態 | 中途半端な登録/重複があると認証が不安定になることがある |
| AzureAdPrt | Primary Refresh Tokenが取得できているか | NOの場合、Officeのサインインが通りにくい |
| DeviceId / TenantId | 登録されているデバイスとテナントの識別子 | 別テナントの情報が残っている/古い登録が残っている可能性 |
サーバーでの再登録や離脱（leave/join）は運用影響が大きい場合があります。実施する場合は、必ずサーバー管理者と手順・影響範囲を確認してください。
ブラウザーからのサインインでも失敗する場合の対処
Officeアプリだけでなく、ブラウザーでMicrosoft 365にサインインしようとしても同様に失敗する場合、端末キャッシュ以外にブラウザー/ネットワークの要因が絡んでいることがあります。次の順で試すと、原因の切り分けがしやすくなります。
| 試すこと | 狙い | ポイント |
|---|---|---|
| シークレット/プライベートウィンドウで試す | Cookieや拡張機能の影響を最小化 | 成功するなら、通常ウィンドウ側のキャッシュが原因になりやすい |
| キャッシュとCookie削除 | 壊れたセッション情報のリセット | 「すべて削除」ではなく、影響を見ながら範囲を調整 |
| 拡張機能（広告ブロッカー等）を一時無効化 | リダイレクトやスクリプトのブロック回避 | 特に認証画面で別タブが開くタイプは影響が出やすい |
| 別ブラウザーで試す | ブラウザー固有の問題を切り分け | Edge/Chrome/Firefoxなどで比較 |
| VPN/プロキシ/フィルタリングの有無確認 | 通信ブロックやSSL検査を疑う | 社内ネットワークとテザリング等で差が出るか |
| DNSキャッシュのクリア | 名前解決の詰まりを解消 | ipconfig /flushdnsを実行 |
| サービス側障害の確認 | 広域障害の可能性を排除 | 管理センターのサービス正常性などを確認 |
管理者・運用担当向け：根本原因を詰める観点
利用者側のリセットで直る場合でも、再発を繰り返すなら、運用面での根本原因が残っている可能性があります。とくに条件付きアクセスや端末準拠の要件が厳しい環境では、次の観点を押さえるとトラブルが減ります。
サインインログで「ブロック理由」を確認
- 条件付きアクセスでブロックされていないか（準拠、アプリ制御、場所、リスクなど）
- デバイス情報が取得できているか（デバイスIDが空、または別端末として認識される）
- 同一ユーザーでも、成功する端末と失敗する端末の差分は何か
TPM変更後に起きやすい落とし穴
TPMに保護された資格情報やWindows Hello for Businessの鍵が変わると、端末に残る古い情報が整合しなくなります。次のような方針を持つと復旧が安定します。
- TPM初期化やマザーボード交換を伴う作業後は、端末のEntra ID/Intune再登録までを復旧手順に含める
- Windows Hello for Businessを使う場合、必要に応じて再登録（PIN再設定など）を案内する
- 端末再セットアップ時は、旧デバイス記録が残りすぎないよう、棚卸しと整理を行う
それでも直らないときの最終チェック
ここまで試して改善しない場合は、「どこで詰まっているか」を見える化して、社内ITまたはMicrosoftサポートに渡す材料を整えるのが近道です。
切り分けチェックリスト
| チェック | Yesなら | Noなら |
|---|---|---|
| 同アカウントが別PCでサインインできる | 端末側の問題が濃厚（本記事のリセット方針が有効） | アカウント/テナント側の障害やMFA/パスワード問題も疑う |
| Webでもサインインが失敗する | ブラウザー/ネットワーク/ポリシーの影響を追加で疑う | Officeアプリ/端末登録/WAM周辺が本命 |
| 同PCで別ユーザーはサインインできる | ユーザープロファイル依存の可能性（資格情報/プロファイル整理が有効） | 端末依存の可能性（デバイス登録やセキュリティソフトの影響） |
最後に試す現実的な選択肢
- 新しいWindowsユーザープロファイルで試す：既存プロファイルの認証周りだけ壊れている場合に有効
- Officeの修復/再インストール：Officeコンポーネント側の不整合が疑われる場合
- 端末の再登録（管理者対応含む）：条件付きアクセスや準拠要件が厳しい環境で効果が高い
なお、エラーが出る端末が複数に増えている、ある日を境に全員が失敗する、といった場合は、端末個別ではなく組織側の設定変更やサービス側の影響も考えられます。管理者はサインインログと変更履歴を優先的に確認してください。
コメント