Microsoft 365 Copilot Coworkだけが起動しない、処理を開始できない、またはアクセス拒否になる一方で、TeamsやOutlook、SharePointは正常に使える場合、最初に確認したいのがMicrosoft Entra IDの条件付きアクセスです。
Copilot Coworkは、サービス要求のトークン発行先として「Weave／M365 Host App」を使用します。対象のアプリケーションIDは6ab48b67-cd74-4ad4-81af-5932984589beです。そのため、一般的なMicrosoft 365アプリへのアクセスが許可されていても、このアプリが別の条件付きアクセスポリシーに含まれていると、Coworkだけが失敗することがあります。(Microsoft Learn)
対処では、条件付きアクセスを一括で無効化するのではなく、サインインログから「どのポリシーが」「どのリソースへのアクセスを」「なぜ遮断したか」を特定することが重要です。
条件付きアクセスでCopilot Coworkだけ失敗する場合のアプリID確認
Copilot Coworkに関係するMicrosoft Entraアプリケーションは次のとおりです。
| 確認項目 | 値 |
|---|---|
| 表示名 | Weave／M365 Host App |
| 別表記 | Microsoft 365 Host App |
| アプリケーション（クライアント）ID | 6ab48b67-cd74-4ad4-81af-5932984589be |
| Coworkでの役割 | Coworkサービス要求のトークン対象リソース |
| 主な確認場所 | Microsoft Entra IDのサインインログ、条件付きアクセスポリシー、エンタープライズアプリケーション |
Microsoftのドキュメントでは、Coworkを利用するための条件として、このアプリケーションIDを条件付きアクセスで遮断しないことが示されています。表示名は環境や管理画面によって見え方が異なる可能性があるため、名前だけで判断せず、GUID形式のアプリケーションIDで照合してください。(Microsoft Learn)
他のMicrosoft 365アプリが使えても原因を否定できない理由
条件付きアクセスは、ユーザーが開いた画面やクライアントアプリの名前だけではなく、アクセストークンの発行先となる「リソース」を基準に評価されます。
Coworkを利用する処理は、概念的には次のように進みます。
ユーザー
↓
Microsoft 365 Copilotの画面
↓
Microsoft Entra IDへトークンを要求
↓
Weave／M365 Host App
↓
Copilot Coworkの実行環境ユーザーからはMicrosoft 365 Copilotの画面を開いているように見えても、バックエンドではWeave／M365 Host App向けのトークンが必要です。
したがって、次の状態は同時に発生し得ます。
- Outlookにサインインできる
- Teamsを利用できる
- SharePointのファイルを開ける
- Copilot Chatを表示できる
- Coworkの開始時だけ条件付きアクセスで遮断される
Microsoft Entraの条件付きアクセスは、クライアントではなく、そのクライアントがアクセスするリソースに対して適用されます。また、1つのMicrosoft 365アプリが複数のバックエンドサービスへアクセスすることもあるため、サインインログでは「アプリケーション」と「リソース」の両方を確認する必要があります。(Microsoft Learn)
症状から条件付きアクセスの可能性を切り分ける
次の表は、原因を絞り込む際の目安です。
| 症状 | 可能性が高い原因 | 最初に確認する場所 |
|---|---|---|
| Coworkの開始直後にアクセス拒否になる | 条件付きアクセス | Microsoft Entraのサインインログ |
AADSTS53003が表示される | 条件付きアクセスによるブロック | 失敗イベントの「条件付きアクセス」タブ |
| 特定の利用者だけ失敗する | ユーザー・グループ、デバイス準拠、ライセンス | ポリシーの対象ユーザーとデバイス情報 |
| 社外ネットワークからだけ失敗する | 場所条件、名前付き場所、プロキシ | ポリシーのネットワーク条件 |
| Coworkは開くが処理を開始できない | 通信先、サービスプリンシパル、同意設定 | ネットワークログ、エンタープライズアプリ |
| 一定時間後にリアルタイム更新が止まる | プロキシの接続時間制限 | ストリーミング接続のタイムアウト |
| 全利用者で同時に失敗する | 全リソース対象のポリシー、テナント共通設定 | 条件付きアクセスとネットワーク設定 |
AADSTS53003は、条件付きアクセスによってアクセスが遮断された場合に確認される代表的なエラーです。ただし、画面上にエラーコードが表示されない場合もあるため、最終判断はサインインログで行います。(Microsoft Learn)
Microsoft Entraのサインインログで遮断ポリシーを特定する
失敗を再現して時刻を記録する
最初に、影響を受けている利用者にCoworkの操作を再現してもらいます。次の情報を記録してください。
- 利用者のユーザープリンシパル名
- 操作した日時
- 利用した端末とブラウザー
- 表示されたエラーコード
- 要求ID
- 相関ID
- 「詳細情報」に表示された内容
要求IDや相関IDが分かる場合は、サインインログから該当イベントを見つけやすくなります。Microsoftへ問い合わせる場合にも、要求ID、発生日時、失敗理由が重要な調査情報になります。(Microsoft Learn)
サインインログを絞り込む
Microsoft Entra管理センターで、次の順に開きます。
Entra ID
→ 監視と正常性
→ サインイン ログサインインログの確認には、少なくともレポート閲覧者相当の権限が必要です。次の条件でログを絞り込みます。
| フィルター | 設定内容 |
|---|---|
| 日付 | Coworkの失敗を再現した時間帯 |
| ユーザー | 影響を受けた利用者 |
| 条件付きアクセス | 失敗 |
| 状態 | 失敗 |
| リソース | Weave、M365 Host App、または該当する表示名 |
| 相関ID | エラー画面から取得できた場合に指定 |
管理画面のリソース検索でアプリケーションIDを直接指定できない場合は、先にエンタープライズアプリケーションで6ab48b67-cd74-4ad4-81af-5932984589beを検索し、テナント内の表示名を確認します。
対話型ユーザーサインインに記録が見つからない場合は、非対話型ユーザーサインインも確認してください。バックグラウンドでのトークン更新や代理アクセスでは、利用者が操作した時刻の近くに非対話型イベントが記録されることがあります。
Microsoft Entraのサインインログでは、ユーザー、日時、リソース、条件付きアクセスの結果などを使って、失敗イベントを絞り込めます。(Microsoft Learn)
基本情報でリソースを照合する
該当するサインインイベントを開き、基本情報で次の項目を確認します。
- アプリケーション
- アプリケーションID
- リソース
- リソースID
- クライアントアプリ
- サインインエラーコード
- 失敗の理由
- IPアドレス
- デバイス情報
特に重要なのは「アプリケーション」だけでなく「リソース」です。
Coworkの画面を提供しているアプリケーション名と、実際にトークンを要求しているリソース名が異なることがあります。リソース側のIDが次の値と一致するか確認してください。
6ab48b67-cd74-4ad4-81af-5932984589be条件付きアクセスタブを確認する
続いて、イベント詳細の「条件付きアクセス」タブを開きます。
ここでは、該当するサインインに対して評価されたポリシーと、その結果を確認できます。
| 表示される結果 | 意味 |
|---|---|
| 成功 | ポリシーの要求を満たした |
| 失敗 | ポリシーが適用され、要求を満たせなかった |
| 適用されていません | ユーザー、リソース、条件などが対象外だった |
| レポート専用 | 有効化した場合の結果をシミュレーションした |
失敗になっているポリシーを選択し、次の点を確認します。
- どのポリシーがアクセスを遮断したか
- Weave／M365 Host Appが対象リソースに含まれているか
- 「アクセスのブロック」が設定されているか
- 多要素認証が不足していないか
- 認証強度の要件を満たしているか
- デバイスが準拠済みとして認識されているか
- Microsoft Entraハイブリッド参加が要求されていないか
- 利用場所が許可された範囲に含まれているか
- クライアントアプリ条件に一致しているか
サインインログの条件付きアクセスタブには、評価されたポリシーと適用結果が表示されます。詳細情報だけでは判断できない場合は、サインイン診断やWhat Ifツールも利用できます。(Microsoft Learn)
遮断している条件付きアクセスポリシーの確認ポイント
対象リソースを確認する
ポリシーの「対象リソース」で、次のどちらが指定されているか確認します。
- すべてのリソース
- リソースの選択
「すべてのリソース」を対象にしたブロックポリシーでは、新しいMicrosoftクラウドアプリや個別に選択していないバックエンドサービスも対象になります。
Microsoft 365またはOffice 365を別ポリシーで許可しているように見えても、それだけでWeave／M365 Host Appがブロック対象から外れるとは限りません。推測で判断せず、該当サインインイベントのリソースとAudience情報で、実際にどのポリシーの対象になったかを確認してください。(Microsoft Learn)
複数のポリシーを確認する
条件付きアクセスでは、1回のサインインに複数のポリシーが適用されることがあります。
例えば、次の3つのポリシーが同時に適用されるケースです。
ポリシーA：多要素認証を要求
ポリシーB：準拠済みデバイスを要求
ポリシーC：信頼済みネットワーク以外をブロックポリシーAに成功していても、ポリシーCのブロック条件に一致すればアクセスは拒否されます。適用されるすべてのポリシーを満たす必要があり、ブロックポリシーが1つでも適用されると、その時点でアクセスは遮断されます。(Microsoft Learn)
よくある設定ミスを確認する
| 設定箇所 | よくある問題 |
|---|---|
| ユーザーとグループ | Coworkの検証利用者がブロック対象グループに含まれている |
| 対象リソース | すべてのリソースを対象とするポリシーにCoworkが含まれている |
| 除外リソース | Microsoft 365だけを除外し、Coworkのリソースが除外されていない |
| ネットワーク | プロキシやVPN経由のIPアドレスが信頼済み場所として認識されていない |
| デバイス | Intuneでは準拠済みでも、サインインログでは非準拠になっている |
| クライアントアプリ | ブラウザーやモバイル・デスクトップクライアントの条件が想定と異なる |
| 許可制御 | 認証強度、準拠デバイス、承認済みクライアントアプリなどをCoworkが満たせない |
| 除外ユーザー | 一時的な検証用除外が恒久運用になっている |
条件付きアクセスポリシーを修正する方法
広範囲のブロックポリシーに意図せず含まれている場合
サインインログで、Weave／M365 Host Appが意図しないブロックポリシーの対象になっていることを確認できた場合は、次のいずれかで修正します。
- 対象リソースの範囲を見直す
- 該当するブロックポリシーからWeave／M365 Host Appを除外する
- Cowork利用者を対象とした別のセキュリティ要件へ再設計する
- 多要素認証や準拠済みデバイスなど、Coworkで満たせる制御へ変更する
重要なのは、条件付きアクセスには、別ポリシーのブロックを上書きする「無条件の許可ポリシー」がないことです。
Cowork用に「アクセスを許可する」ポリシーを追加しても、別のブロックポリシーが適用されていればアクセスできません。遮断しているポリシーの対象範囲を修正するか、そのポリシーの要求を満たす必要があります。(Microsoft Learn)
セキュリティ要件を満たしていない場合
ブロック対象への誤追加ではなく、利用者や端末がポリシー要件を満たしていない場合は、アプリを除外する前に原因を修正します。
例えば、準拠済みデバイスが要求されている場合は、サインインログのデバイス情報で次を確認します。
- デバイスIDが取得できているか
- 管理対象として認識されているか
- 準拠状態が「はい」になっているか
- Microsoft Entraへの参加状態が想定どおりか
- 別ブラウザープロファイルや個人アカウントで開いていないか
場所条件で遮断されている場合は、利用者の端末IPではなく、Microsoft Entraから見える送信元IPを確認します。社内プロキシ、VPN、SASE製品を経由すると、管理者が想定していたIPアドレスとは異なる値で評価されることがあります。
アプリを除外する場合の注意点
Weave／M365 Host Appをポリシーから除外する場合は、次の運用を推奨します。
- 失敗した特定のポリシーだけを見直す
- すべての条件付きアクセスポリシーから一括除外しない
- Cowork利用者全員ではなく、検証グループから開始する
- 別のポリシーで多要素認証などの基礎的な保護を維持する
- 変更理由と対象アプリIDを管理記録に残す
- 緊急アクセス用アカウントが確保されていることを確認する
Microsoftは、条件付きアクセスの変更をレポート専用モードやパイロットグループで検証してから、全体へ展開することを推奨しています。(Microsoft Learn)
エンタープライズアプリケーションをアプリIDで確認する
Microsoft Entra管理センターで次の順に開きます。
Entra ID
→ エンタープライズ アプリケーション
→ すべてのアプリケーションフィルターや検索条件にアプリケーションIDを指定し、次の値を検索します。
6ab48b67-cd74-4ad4-81af-5932984589be確認する項目は次のとおりです。
- 表示名
- アプリケーションID
- オブジェクトID
- 有効状態
- サインインログ
- アクセス許可
- 割り当ての要否
アプリケーションIDとオブジェクトIDは別の値です。
| ID | 意味 |
|---|---|
| アプリケーションID | Microsoftアプリを識別する共通のID |
| オブジェクトID | 各テナント内のサービスプリンシパルを識別するID |
条件付きアクセスやMicrosoftの資料と照合する際は、まずアプリケーションID6ab48b67-cd74-4ad4-81af-5932984589beを基準にしてください。サービスプリンシパルのオブジェクトIDはテナントごとに異なります。(Microsoft Learn)
Microsoft Graph PowerShellで確認する
管理画面で見つけにくい場合は、Microsoft Graph PowerShellを使って読み取り専用で確認できます。
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal `
-Filter "appId eq '6ab48b67-cd74-4ad4-81af-5932984589be'" `
-Property "id","displayName","appId","accountEnabled" |
Select-Object DisplayName, AppId, Id, AccountEnabled結果の見方は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| DisplayName | WeaveまたはM365 Host Appに相当する表示名 |
| AppId | 6ab48b67-cd74-4ad4-81af-5932984589be |
| Id | テナント内のサービスプリンシパルのオブジェクトID |
| AccountEnabled | サービスプリンシパルが有効か |
Get-MgServicePrincipalは、テナント内のサービスプリンシパルを取得するMicrosoft Graph PowerShellのコマンドです。アプリケーションの参照にはApplication.Read.Allなどのアクセス許可が必要です。(Microsoft Learn)
結果が返らない場合でも、独自のアプリ登録を同じ名前で作成してはいけません。まず、Coworkの利用資格、テナントへの展開状況、利用者ライセンス、実際のサインインログを確認します。サービスプリンシパルの新規作成が必要かどうかは、Microsoftの正式な案内またはサポートの指示に従って判断してください。
サービスプリンシパルのサインインも確認する
ユーザーサインインログに条件付きアクセスの失敗が見つからない場合は、次のログも確認します。
Entra ID
→ 監視と正常性
→ サインイン ログ
→ サービス プリンシパルのサインインMicrosoftのCowork要件では、テナント内のサービスプリンシパルが対象アプリケーション向けのトークンを取得できることも確認項目に含まれています。
ワークロードIDを対象とする条件付きアクセスポリシーを使用している場合は、サービスプリンシパルのサインインイベントを開き、「条件付きアクセス」タブで評価結果を確認します。ユーザーを対象とする条件付きアクセスと、ワークロードIDを対象とする条件付きアクセスは、分けて調査する必要があります。(Microsoft Learn)
変更後はレポート専用モードと検証ユーザーで確認する
条件付きアクセスポリシーを修正したら、次の順序で検証します。
- 変更前のポリシー設定を記録する
- 検証用ユーザーまたはパイロットグループに限定する
- What Ifツールで適用予定のポリシーを確認する
- 新規・再設計したポリシーはレポート専用モードで評価する
- ブラウザーの新しいプロファイルやプライベートウィンドウでCoworkを再実行する
- サインインログでリソースIDを確認する
- 条件付きアクセスの結果が成功になったことを確認する
- 想定外の利用者やアプリへの影響がないことを確認する
- 段階的に対象を拡大する
既存のアクセストークンが残っていると、変更後すぐに条件付きアクセスが再評価されない場合があります。検証では新しいブラウザーセッションを使用し、失敗前と変更後のサインインイベントを比較すると判断しやすくなります。
条件付きアクセスが原因でない場合の確認項目
サインインログにWeave／M365 Host Appへの条件付きアクセス失敗が記録されていない場合は、ネットワーク要件とCoworkの前提条件を確認します。
必要な通信先を確認する
| 宛先 | ポート | 用途 |
|---|---|---|
*.gateway.prod.island.powerapps.com | 443 | Coworkのルーティングおよび実行環境 |
m365.cloud.microsoft.com | 443 | Copilot Chatの画面 |
login.microsoftonline.com | 443 | Microsoft Entra ID認証 |
graph.microsoft.com | 443 | メール、ファイル、予定表などのMicrosoft 365サービス |
*.gateway.prod.island.powerapps.comでは、利用者やテナントに応じて接続先が動的に決まります。特定のリージョン名やクラスター名を固定して許可するのではなく、ワイルドカード形式で許可する必要があります。(Microsoft Learn)
プロキシのストリーミング接続制限を確認する
Coworkはリアルタイム更新のため、長時間維持されるストリーミング接続を使用します。
対象となる主なパスは次のとおりです。
/v1/subscribe
/v1/mru/subscribeプロキシやセキュリティゲートウェイが接続の絶対有効時間を短く設定していると、通信が継続していても接続が切断されます。
*.gateway.prod.island.powerapps.comについては、絶対時間による切断を無効にするか、少なくとも30分以上に設定します。Coworkを開くことはできるものの、一定時間後に更新が止まる場合は、この設定を優先して確認してください。(Microsoft Learn)
ライセンスと同意状態を確認する
ネットワークと条件付きアクセスに問題がない場合は、次の項目を確認します。
- 利用者にMicrosoft 365 Copilotライセンスが割り当てられている
- Weave／M365 Host Appのサービスプリンシパルが利用可能である
- 必要なMicrosoft 365サービスへの代理アクセス同意が完了している
- サービスプリンシパルがトークンを取得できる
- Microsoft Graph、SharePoint、Exchangeなどの依存サービスが遮断されていない
Coworkの公式要件には、利用者ライセンス、対象アプリケーションの条件付きアクセス許可、サービスプリンシパルのトークン取得、必要なOn-Behalf-Of同意が含まれています。(Microsoft Learn)
調査時に避けたい対応
条件付きアクセスをすべて無効にする
原因調査のためであっても、テナント全体の条件付きアクセスを一括で無効にすると、セキュリティ上の影響が大きくなります。まず、サインインログで失敗したポリシーを特定してください。
利用者だけを恒久的に除外する
利用者をポリシーから外すとCoworkが使えるようになることがありますが、他のMicrosoft 365サービスへの保護も失われる可能性があります。恒久対応では、対象リソースと失敗条件を明確にして、必要最小限の範囲を修正します。
表示名だけでアプリを選ぶ
「Weave」「M365 Host App」などの表示名だけで選択すると、類似名のアプリや別のサービスプリンシパルと取り違える可能性があります。必ずアプリケーションIDで照合します。
アプリケーションだけを見てリソースを確認しない
Coworkを開いたクライアントアプリと、条件付きアクセスが評価した対象リソースは同じとは限りません。サインインログでは、リソース、リソースID、Audienceを確認してください。
1つのポリシーが成功しただけで解決と判断する
条件付きアクセスは複数のポリシーを同時に評価します。1つが成功でも、別のポリシーがブロックしていればCoworkは利用できません。適用されたポリシーをすべて確認する必要があります。
Copilot Coworkの条件付きアクセス確認手順まとめ
他のMicrosoft 365アプリは使えるのにCopilot Coworkだけが失敗する場合は、次の順序で調査します。
- 影響を受けた利用者で失敗を再現し、日時と相関IDを記録する
- Microsoft Entraのサインインログを利用者、時刻、条件付きアクセス失敗で絞り込む
- リソースまたはAudienceが
6ab48b67-cd74-4ad4-81af-5932984589beか確認する - 条件付きアクセスタブで、失敗したポリシーと満たせなかった条件を特定する
- 複数の適用ポリシーをすべて確認する
- ブロックポリシーの対象範囲または要求条件を必要最小限で修正する
- レポート専用モードやパイロットユーザーで検証する
- 条件付きアクセスの失敗がなければ、通信先、プロキシ、ライセンス、サービスプリンシパル、代理アクセス同意を確認する
調査の中心は、Coworkという画面名ではなく、実際のトークン対象リソースです。Weave／M365 Host AppのアプリケーションIDを基準にサインインログを追うことで、Microsoft 365全体のポリシーを不用意に緩めることなく、Coworkだけが失敗する原因を切り分けられます。
コメント