共有コンピューター認証が通らないときは、いきなりキャッシュ削除や再インストールに進むより、まず「ライセンスが対応しているか」「端末で Shared Computer Activation が有効か」「ユーザーが自分の Microsoft 365 アカウントでサインインしているか」「トークンを取得・更新できるネットワークと認証経路があるか」を確認するのが最短です。Microsoft 365 Apps の共有コンピューター認証は、共有 PC や RDS、共有仮想マシン向けの仕組みで、各ユーザーが自分のアカウントでサインインして個別のライセンス トークンを受け取る前提です。1つの共有アカウントを複数人で回す運用とは考え方が違います。 (Microsoft Learn)
この記事では、共有コンピューター認証が通らない原因を、症状の切り分け、設定確認、RDS/VDI/FSLogix 環境の注意点、復旧手順までまとめて整理します。結論を先に言うと、実務で多い原因は「SCA 非対応プラン」「SharedComputerLicensing 未設定」「ユーザーごとのライセンス割り当てやサインイン不整合」「トークン保存や BrokerPlugin を含む認証経路の不具合」のいずれかです。 (Microsoft Learn)
共有コンピューター認証が通らないときの30秒チェック
- Word などを開いて、[ファイル] → [アカウント] → [Word のバージョン情報] に Shared Computer Activation と表示されるか確認します。表示されなければ、端末側で共有コンピューター認証が有効になっていない可能性が高いです。レジストリでは
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\ConfigurationのSharedComputerLicensingが1であることが目安です。 (Microsoft Learn) - 共有端末で Office を起動したあと、
%localappdata%\Microsoft\Office\16.0\Licensingにテキストファイルが作成されているか確認します。ここに何もなければ、ライセンス トークンの取得に失敗していると考えられます。 (Microsoft Learn) - Microsoft 365 管理側で、各ユーザー に共有コンピューター認証を使えるプランが割り当てられているか確認します。共有コンピューター認証は、端末単位ではなくユーザー単位の権利確認が基本です。 (Microsoft Learn)
- 自宅回線では通るのに社内ネットワークだけ失敗するなら、プロキシ・VPN・ウイルス対策・ファイアウォールによる遮断を先に疑います。特に
Microsoft.AAD.BrokerPlugin_cw5n1h2txyewyがブロックされると、ブラウザーでは入れても Office デスクトップアプリ側だけ認証に失敗することがあります。 (Microsoft Learn)
まず理解しておきたい「共有コンピューター認証」の前提
ここでいう共有コンピューター認証は、Microsoft 365 Apps の 共有コンピューターのライセンス認証（Shared Computer Activation） を指します。想定されているのは、工場や病院の共有 PC、会議室端末、RDS セッション ホスト、共有仮想マシンのように、複数ユーザーが同じ端末や同じ Office 実行環境を使うケースです。個人専用 PC で使う通常のサインイン型ライセンスとは前提が違います。 (Microsoft Learn)
共有コンピューター認証が有効な端末では、ユーザーが自分のアカウントでサインインして Office を起動すると、インターネット上の Office ライセンス サービスに接続して、そのユーザー専用のライセンス トークンを取得します。トークンはユーザープロファイルに保存され、同じ端末を別ユーザーが使っても、その人のトークンが自動的に使われるわけではありません。つまり、「端末は共有でも、ライセンスの確認はユーザーごと」です。 (Microsoft Learn)
この前提を外していると、設定をどれだけいじっても安定しません。典型例は「Windows は共有アカウント 1 つ」「Office も共通アカウントで運用」「個々の利用者には Microsoft 365 Apps の権利がない」という構成です。共有コンピューター認証は、その運用を正当化するための仕組みではありません。各ユーザーに権利が必要です。 (Microsoft Learn)
共有コンピューター認証が通らない主な原因と対処
SCA に対応していないライセンスを使っている
もっとも多いのが、プラン自体が共有コンピューター認証に対応していないケースです。Microsoft Learn では、共有コンピューター認証が使える代表例として Microsoft 365 Apps for enterprise を含むプラン、Microsoft 365 Business Premium、および対象の Project/Visio サブスクリプション が案内されています。一方で、Microsoft 365 Business Premium だけが business 系で共有コンピューター認証をサポートすると明記されており、Business Standard などをそのまま共有端末に当てても通りません。 (Microsoft Learn)
エラーとしては、「共有コンピューターのシナリオでは、アカウントで見つかった製品を使用して Office をライセンス認証することはできません」 が出やすいです。この場合はキャッシュより先に、管理センターでユーザーに割り当てた SKU を確認してください。現場では「端末に Office が入っているから使えるはず」と思い込みがちですが、共有コンピューター認証では端末インストールだけでは足りません。 (Microsoft Learn)
端末側で SharedComputerLicensing が有効になっていない
SCA 対応プランでも、端末側の設定が通常のユーザーライセンスのままだと認証は通りません。確認方法はシンプルで、Office アプリのバージョン情報に Shared Computer Activation と出るか、レジストリの SharedComputerLicensing=1 を確認します。RDS で Office 展開ツールを使う場合も、この設定が必須です。 (Microsoft Learn)
Office 展開ツールの configuration.xml では、次の設定が基本です。
<Property Name="SharedComputerLicensing" Value="1" />この設定で共有コンピューター認証を有効にできます。既に Microsoft 365 Apps が入っている端末でも、再インストールなしで GPO、レジストリ、または Microsoft サポート/回復アシスタントで有効化できますが、反映には再起動が必要です。なお、SCA を有効にする前に通常モードで Office を認証済みだった端末は、ライセンス状態のリセットが必要になることがあります。 (Microsoft Learn)
補足すると、Microsoft 365 Apps for business では、GPO で共有コンピューター認証を有効にする方法はサポート外です。Business Premium 配下で Apps for business を使っている環境では、GPO ではなく ODT、レジストリ、または SaRA を使うほうが安全です。ここを知らずに「ポリシーを配ったのに効かない」とハマることがあります。 (Microsoft Learn)
ユーザーのライセンス割り当てやサインインアカウントがずれている
共有コンピューター認証は、共有端末であっても ユーザーが自分の Microsoft 365 アカウントでサインインすることが前提です。Office のライセンス認証ダイアログが出たときに、別テナントのアカウントや権利のないアカウントで入ってしまうと、「ライセンスのない製品」 や 「この製品に現在インストールされているライセンスは確認できません」 に繋がります。 (Microsoft Learn)
また、Windows 側に以前の職場アカウントが残っていると、Office が意図しない資格情報を拾って失敗することがあります。Microsoft は、すべての Microsoft 365 アプリからサインアウトして再サインインすること、さらに [設定] → [アカウント] → [職場または学校にアクセスする] に、Office で使うアカウントとは別の接続が残っていれば切断することを案内しています。共有端末では、退職者や異動者の痕跡が残っていないかも確認したいところです。 (Microsoft Learn)
ネットワークや認証経路がトークン取得を妨げている
共有コンピューター認証は、一度通れば終わりではありません。ライセンス トークンの取得・更新には、共有端末からインターネット上の Office ライセンス サービスへ安定して到達できることが必要です。トークンには有効期限があり、更新時に回線断や到達性の問題があると、後から突然「昨日まで使えていたのに今日は通らない」という状態になります。 (Microsoft Learn)
特に企業ネットワークでは、プロキシ・ファイアウォール・VPN・ウイルス対策製品が Office の認証経路を壊すことがあります。Microsoft の共有コンピューター認証トラブルシューティングでは、Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy がブロックされるケースに触れており、必要に応じて VPN やプロキシ、セキュリティソフトを一時的に無効化して切り分けるよう案内しています。加えて、MSOIDCRL を含む許可ルールや、NCSI Active Probing が無効化されていないかの確認も挙がっています。「Web 版は入れるが、Word/Excel だけ通らない」 なら、この系統を優先してください。 (Microsoft Learn)
RDS/VDI でトークンが保存されず、毎回認証を求められる
RDS、VDI、Citrix のような共有実行環境では、認証そのものより トークンの保持 で失敗することが少なくありません。Microsoft は、RDS/VDI で継続的に再アクティブ化を求められる場合、ライセンス トークン ローミングの有効化 を案内しています。非永続 VDI では特に重要です。 (Microsoft Learn)
トークンの既定保存先は %localappdata%\Microsoft\Office\16.0\Licensing ですが、必要に応じてローミング プロファイルや共有フォルダーに移す設計もできます。ODT なら SCLCacheOverride と SCLCacheOverrideDirectory、レジストリなら SCLCacheOverride=1 と保存先パス指定で構成できます。ただし、ネットワーク共有を保存先にすると遅延で Office 起動が重くなることがあるため、何でもローミングすればよいわけではありません。 (Microsoft Learn)
FSLogix を使っていて設定がかみ合っていない
FSLogix 環境では、Office 認証情報とプロファイルの扱いが少し特殊です。Microsoft のトラブルシューティングでは、FSLogix と SSO を併用している場合、HKEY_LOCAL_MACHINE\SOFTWARE\Policies\FSLogix\ODFC の IncludeOfficeActivation を 0 に設定する手順が示されています。ここが逆だと、毎回認証やトークン不整合の原因になりえます。 (Microsoft Learn)
さらに、FSLogix の Microsoft 365 コンテナーを別のプロファイルソリューションと併用している場合、M365 関連フォルダーを二重に処理しないことも重要です。要するに、「どの仕組みがどの認証情報・キャッシュ・ライセンスフォルダーを持つのか」を一意に決める必要があります。ここが曖昧だと、再起動やログオフのたびに状態が壊れます。 (Microsoft Learn)
製品や OS の組み合わせがそもそも非対応
RDS やターミナルサーバーで Office を使う場合、Click-to-Run 版 Office をサーバー上で動かすなら Shared Computer Activation が必要で、Microsoft は Shared Computer Activation は Microsoft 365 Apps でのみ利用可能 と案内しています。つまり、RDS なのに通常の Office 製品を入れていたり、そもそも別系統の Office を期待していると、構成自体が噛み合っていません。 (Microsoft Learn)
OS 側も見落としやすいポイントです。古い OS では TLS 1.2 の問題が表面化しますが、Windows 7 / Windows Server 2012 世代は、そもそも現在の Microsoft 365 Apps のサポート対象外です。Windows Server 側のサポート状況は時期で変わるため、特に RDS サーバーでは「通す方法」だけでなく「まだサポート対象か」も必ず確認してください。 (Microsoft Learn)
最短で復旧したいときの手順
手順1：SCA モードになっているか確認する
最初に、Office アプリのバージョン情報で Shared Computer Activation の表示を確認します。表示がなければ、SCA は有効化されていません。ODT、レジストリ、または SaRA で有効化し、再起動します。すでに通常認証済みだった端末は、あとでアクティベーション状態のリセットも視野に入れます。 (Microsoft Learn)
手順2：ライセンスを「端末」ではなく「ユーザー」で確認する
管理センターで、対象ユーザーに 共有コンピューター認証対応プラン が割り当てられているかを確認します。RDS/共有 VM でも、必要なのは「1台に1ライセンス」ではなく「利用する各ユーザーへの適切なライセンス付与」です。ここが誤っていると、以降の作業はすべて遠回りになります。 (Microsoft Learn)
手順3：Office と Windows 側のサインイン情報を整理する
Office アプリから一度サインアウトし、正しい仕事用または学校用アカウントで再サインインします。そのうえで Windows の [職場または学校にアクセスする] に不要な接続が残っていれば切断します。共有端末では「前の利用者の残骸」がそのまま原因になることが多いです。 (Microsoft Learn)
手順4：トークンが作られているかを見る
%localappdata%\Microsoft\Office\16.0\Licensing にトークンファイルができていれば、少なくとも一度は成功しています。逆に何もなければ、まだ認証まで到達していません。ネットワーク遮断、サインイン失敗、権利不足のいずれかを疑います。RDS/VDI では、トークンができても次回消えるならローミング設計を見直します。 (Microsoft Learn)
手順5：社内ネットワークやセキュリティ製品を切り分ける
社内だけで起きる、VPN 接続時だけ起きる、特定拠点だけ起きるなら、プロキシ・ファイアウォール・VPN・ウイルス対策を疑います。BrokerPlugin のブロックや MSOIDCRL の許可不足、NCSI アクティブプローブ無効化は、見た目よりよくある原因です。まずは一時的に制限を外した状態で再現するか確認してください。 (Microsoft Learn)
手順6：RDS/VDI/FSLogix はトークン ローミングまで含めて見る
RDS/VDI で認証が毎回出るなら、SCA を有効にしただけでは足りません。ライセンス トークン ローミングの有効化、FSLogix 環境なら IncludeOfficeActivation=0 の確認、プロファイルソリューションの二重管理解消まで見てください。ここを直すと、「通るが毎回求められる」がかなり減ります。 (Microsoft Learn)
手順7：最後は公式トラブルシューティングを使う
1台だけなら、Get Help の Microsoft 365 activation troubleshooter が早いです。Windows 10 以降の同じ端末上で実行できます。複数端末をまとめて直すなら、SaRA の OfficeSharedComputerScenario を使うと、SCA 有効化や切り分けを自動化できます。 (Microsoft Learn)
SaRAcmd.exe -S OfficeSharedComputerScenario -AcceptEula -CloseOfficeSCA を外して通常構成へ戻したいときは、次のスイッチです。 (Microsoft Learn)
SaRAcmd.exe -S OfficeSharedComputerScenario -AcceptEula -CloseOffice -RemoveSCAそれでも直らないときの復旧手段
ライセンスも設定も正しいのに、特定ユーザーだけ何度も失敗するなら、認証キャッシュや ID 情報が壊れている可能性があります。Microsoft は、レジストリの HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity 配下で Identities を削除し、必要に応じて NoDomainUser=1 を追加、SignedOutADUser を削除する手順を案内しています。さらに BrokerPlugin 側の TokenBroker アカウントデータ削除も紹介されています。 (Microsoft Learn)
ただし、ここは最後の手段です。レジストリ変更を誤ると別の障害を作るため、事前バックアップが前提です。実運用では、まず Get Help の activation/sign-in troubleshooter を使い、それでもだめならアクティベーション状態リセットへ進むほうが安全です。Microsoft は OLicenseCleanup.vbs、signoutofwamaccounts.ps1、必要に応じて WPJCleanUp.cmd を使った自動クリーンアップも案内しています。 (Microsoft Learn)
そもそも SCA が合っていないなら構成変更を検討する
共有コンピューター認証はあくまでユーザー単位の認証を共有端末で成立させる仕組みです。もし運用上、「誰でもその端末を開けば編集できればよい」「ユーザーごとに Microsoft 365 アカウントを持たせない」「キオスクに近い使い方をしたい」なら、SCA より デバイス ベース ライセンス のほうが向く場合があります。デバイス ベース ライセンスは、ユーザー単位のアクティブ化を必要とせず、端末に紐づく方式です。 (Microsoft Learn)
ただし、デバイス ベース ライセンスには別の要件があります。Microsoft 365 Apps for enterprise のデバイスライセンス、対応する Windows クライアント、Microsoft Entra 参加やグループへのライセンス割り当てなど、SCA とは違う準備が必要です。共有コンピューター認証が毎回破綻する環境では、復旧を繰り返すより「方式が合っているか」を見直したほうが早いことがあります。 (Microsoft Learn)
まとめ
共有コンピューター認証が通らない原因は多く見えますが、実際には切り分けの順番が重要です。まず ライセンス対応可否、次に SharedComputerLicensing の有効化、その次に ユーザーごとのサインインとライセンス割り当て、最後に トークン保存とネットワーク/BrokerPlugin/VDI 設計 の順に確認すれば、大半は無駄なく絞り込めます。 (Microsoft Learn)
次にやるべきことは、難しくありません。今問題が出ている端末で About Word の表示、SharedComputerLicensing、%localappdata%\Microsoft\Office\16.0\Licensing、ユーザーのライセンス割り当て、社内ネットワーク固有の遮断有無を確認してください。RDS/VDI/FSLogix 環境なら、トークン ローミングとプロファイル設計まで含めて見直すのが近道です。それでも改善しない場合は、Get Help や SaRA、アクティベーション状態リセットを使う段階です。 (Microsoft Learn)
コメント