Microsoft Entra の条件付きアクセスで表示される 「Office 365」アプリは、Word や Excel だけを指すものではありません。Exchange Online、SharePoint Online、Microsoft Teams、OneDrive、Office.com、Loop、Forms、Planner、Viva Engage、さらにバックエンドサービスまでまとめて制御するためのアプリスイートです。今回の「Office 365 App in Conditional Access reference – Microsoft Entra ID」で管理者が押さえるべき結論は、個別アプリを細かく指定するより、Microsoft 365 全体を一貫して保護したい場合は Office 365 グループを使う方が安全なケースが多いという点です。Microsoft は、Office 365 グループを使うことでサービス依存関係やポリシー不整合による問題を避けやすいと説明しています。(Microsoft Learn)
2026年7月1日の公式リポジトリ更新として確認できる内容は、関連リンク形式の修正です。一方、管理者への実務影響が大きいのは、直前の更新で行われたアプリ一覧の整合、追加・名称変更、アプリケーション ID の確認手順の追加です。つまり、今回の更新は「新機能をオンにする」話ではなく、既存の条件付きアクセスポリシーがどの Microsoft 365 サービスに効いているのかを再点検するためのリファレンス更新として捉えるのが適切です。(GitHub)
Microsoft Entra の「Office 365 App in Conditional Access reference」で確認すべきポイント
今回のリファレンスは、条件付きアクセスの対象リソースとして選べる Office 365 に、どのサービスやアプリケーションが含まれるかを示すものです。Microsoft Learn の公開ページでは、Office 365 アプリに含まれる一覧は Microsoft がサービスを追加・削除することで変更される可能性があり、テナント内の現在の一覧は Microsoft Entra 管理センターで確認するよう案内されています。(Microsoft Learn)
| 確認項目 | 更新・明確化された内容 | 管理者が取るべき対応 |
|---|---|---|
| 対象範囲 | Office 365 は Exchange、SharePoint、Teams などの単体アプリではなく、関連サービスをまとめたグループ | 既存ポリシーで個別アプリだけを対象にしていないか確認する |
| サービス依存関係 | Teams などは SharePoint や Exchange などに依存する | 「Teams だけに MFA」などの設計が想定外の動作にならないか検証する |
| アプリ一覧 | AI Hub Services、Office Notification Service、SharePoint Notification Services、Teams Device Management Services などの追加や、eSignature 関連名称の整理が確認できる | 社内の設計書・監査資料・運用手順を最新の名称に更新する |
| アプリケーション ID | 生の ID 一覧を固定的に使うのではなく、テナント内で確認する手順が追加された | サインインログ、Enterprise applications、Microsoft Graph PowerShell で確認する |
| 移行期限 | このリファレンス更新自体に強制移行期限は示されていない | ただし、関連する条件付きアクセス機能の廃止期限は別途確認する |
Office 365 アプリは「Office アプリだけ」ではない
条件付きアクセスの画面で Office 365 と表示されるため、管理者や現場担当者が「Word、Excel、PowerPoint、Outlook だけ」と誤解することがあります。しかし、Microsoft 365 のクラウドサービスは相互依存が強く、Microsoft Teams は SharePoint や Exchange などに依存します。Microsoft は、個別のクラウドアプリを対象にする代わりに Office 365 グループを使うことで、依存関係や不整合による問題を避けやすいと説明しています。(Microsoft Learn)
たとえば、ユーザーが Teams にサインインしているつもりでも、背後ではチャット、予定表、ファイル、会議、通知、検索など複数のリソースにアクセスします。SharePoint 上のファイル、Exchange Online の予定表、Planner のタスク、Whiteboard、Stream などが絡むため、「Teams は許可、SharePoint は厳格に制限」といった設計は、ユーザー体験とセキュリティの両方で想定外の結果を生みやすくなります。
条件付きアクセスで Office 365 を対象にすべきケース
Office 365 グループを対象にするのが向いているのは、次のようなケースです。
- 全社の Microsoft 365 利用に MFA を求めたい
- Exchange、SharePoint、Teams、OneDrive を同じ強度で保護したい
- Microsoft 365 のメタデータや検索経由の情報露出も含めて保護したい
- 個別アプリ指定によるポリシーの抜け漏れを減らしたい
- ユーザーに何度も条件付きアクセスの要求が出る状態を避けたい
特に、メール・ファイル・チャット・会議を同じ端末条件で守りたい場合は、個別アプリを積み上げるより Office 365 グループを使った方が設計が単純になります。Microsoft も、Exchange Online のメール、予定表、連絡先だけでなく、関連メタデータが検索など別リソースから公開される可能性に触れ、Office 365 アプリへのポリシー割り当てによって関連メタデータを保護しやすくなると説明しています。(Microsoft Learn)
含まれるサービスの代表例
公式リファレンスには、ユーザーが直接目にするアプリだけでなく、バックエンドサービスや内部サービス名も含まれます。Microsoft は、一覧にはユーザー向けアプリケーションとバックエンドサービスの両方が含まれ、一部はエンドユーザーに直接表示されない内部サービス名の可能性があると明記しています。(Microsoft Learn)
| 分類 | 代表的な含まれるサービス・アプリ | 実務上の見方 |
|---|---|---|
| コアワークロード | Office 365 Exchange Online、Office 365 SharePoint Online、OneDrive、Microsoft Teams、Office.com | メール、ファイル、チャット、ポータル利用の中心 |
| コラボレーション | Microsoft Planner、Microsoft Forms、Microsoft Stream、Microsoft Whiteboard、Viva Engage、Loop | Teams 連携や共同作業で間接的に使われる |
| 管理・監査系 | M365 Admin Services、Microsoft 365 Reporting Service、M365 Auditing Public Protected Web API app、Protection Center | 管理画面や監査・レポート関連のアクセスに影響 |
| Copilot・AI 関連 | AI Hub Services、Copilot Data Platform、Enterprise Copilot Platform、M365ChatClient | Copilot や AI 連携を使う環境では確認優先度が高い |
| Teams 関連 | Microsoft Teams、Teams And Channels Service、Teams Graph Service、Teams Device Management Services、Teams Walkie Talkie Service | Teams 単体ではなく周辺サービスも含めて評価する |
| 内部・バックエンド系 | IC3 Gateway、O365 Suite UX、Office Online SSO 系、Notification Service、Message Recall | サインインログで見慣れない名称として出ることがある |
ここで重要なのは、「一覧にある名前をすべて人間が使うアプリとして理解しよう」としないことです。実務では、ユーザーが何をしようとしていたか、どのリソースにトークンが要求されたか、どの条件付きアクセスポリシーが適用されたかをサインインログで確認する方が正確です。
影響範囲：どのポリシーを見直すべきか
今回のリファレンス更新で、既存テナントの条件付きアクセスポリシーが自動的に変更されるわけではありません。ただし、Office 365 グループに含まれるサービスの理解が古いままだと、意図しない許可、過剰なブロック、ユーザーへの追加認証要求が発生しやすくなります。特に、Office 365 アプリの一覧は変更される可能性があるため、現在のテナントで表示される対象を確認する運用が必要です。(Microsoft Learn)
優先的に確認すべきなのは、次のような条件付きアクセスポリシーです。
| 既存ポリシーの状態 | 起こりやすい問題 | 見直しの方向性 |
|---|---|---|
| Exchange Online、SharePoint Online、Teams を個別に指定している | 新しい関連サービスやバックエンドサービスが保護対象から漏れる | Microsoft 365 全体を守る目的なら Office 365 グループへの統合を検討する |
| Office 365 を対象に強いブロック条件を入れている | Teams、OneDrive、Office.com など広範囲に影響する | レポート専用モードや対象グループ限定で段階的に検証する |
| 特定アプリだけを除外している | 依存先サービスに別ポリシーが適用され、サインインが失敗する | サインインログで実際の対象リソースを確認する |
| モバイルアプリ向けに古い許可コントロールを使っている | 廃止済み・読み取り専用化された設定が残る可能性がある | Require app protection policy への移行状況を確認する |
| サインインログに見慣れない Microsoft アプリ名が出る | 誤って不審アプリと判断する、または逆に見逃す | Microsoft first-party アプリかどうかを確認する |
Microsoft のサービス依存関係の説明では、Teams は Exchange、Planner、Stream、SharePoint、Whiteboard などと関係し、Office.com も SharePoint にアクセスする例が示されています。つまり、Microsoft 365 の条件付きアクセスは「ユーザーがクリックしたアプリ名」だけでなく、「背後で呼び出されたリソース」まで意識して設計する必要があります。(Microsoft Learn)
設定変更が必要かどうかの判断基準
今回の更新を見たからといって、すぐに全ポリシーを Office 365 グループへ置き換える必要はありません。重要なのは、ポリシーの目的と対象範囲が一致しているかを確認することです。
Office 365 グループに寄せた方がよい場合
次の条件に当てはまるなら、Office 365 グループを中心にした設計を検討する価値があります。
- 「Microsoft 365 へのアクセス全体」に MFA を要求したい
- Teams、Exchange、SharePoint、OneDrive を同じデバイス条件で制御したい
- 部署別・拠点別の例外が少ない
- セキュリティ監査で「Microsoft 365 全体が条件付きアクセスの対象か」を説明したい
- 個別アプリ指定のポリシーが増えすぎて管理できなくなっている
この場合は、Office 365 を対象にした基本ポリシーを作り、例外が必要な場合だけ別ポリシーで調整する方が運用しやすくなります。
個別アプリ指定を残した方がよい場合
一方で、次のようなケースでは個別指定を残す判断もあります。
- SharePoint の一部用途だけを厳格に制御したい
- Exchange Online だけに特定のクライアント制御を適用したい
- 管理者向けポータルと一般ユーザー向け Microsoft 365 を分けたい
- 段階導入中で Teams だけ先に制御したい
- 特定サービスの障害時に影響範囲を限定したい
ただし、個別指定を使う場合は、依存関係による副作用を必ず確認してください。What If ツールはポリシー評価の理解に役立ちますが、Microsoft は What If ツールでは条件付きアクセスのサービス依存関係をテストしないと説明しています。Teams の検証では、What If だけに頼らず、実際のサインインログとレポート専用モードで確認することが重要です。(Microsoft Learn)
管理者が確認すべき設定手順
既存環境で確認するなら、次の順番で進めると抜け漏れを減らせます。
既存ポリシーの対象リソースを棚卸しする
Microsoft Entra 管理センターで、条件付きアクセスポリシーの Target resources を確認します。Office 365 を対象にしているポリシー、Exchange Online や SharePoint Online など個別アプリを対象にしているポリシー、All resources を対象にしているポリシーを分けて一覧化します。
最低限、次の列を持つ管理表を作ると判断しやすくなります。
| 記録する項目 | 例 |
|---|---|
| ポリシー名 | CA-M365-Require-MFA-AllUsers |
| 対象ユーザー | All users、特定部門、管理者グループ |
| 除外ユーザー | 緊急アクセス用アカウント、移行対象外グループ |
| 対象リソース | Office 365、Exchange Online、SharePoint Online |
| 条件 | 場所、デバイスプラットフォーム、クライアントアプリ、リスク |
| 許可コントロール | MFA、準拠デバイス、アプリ保護ポリシー |
| セッション制御 | サインイン頻度、永続ブラウザーセッションなど |
| 運用状態 | オン、レポート専用、無効 |
| 最終確認日 | 2026-07-xx |
テナント内の対象アプリを確認する
公式リファレンスでは、テナント内の現在のアプリケーション一覧を確認するには、Microsoft Entra 管理センターの Protection > Conditional Access > Policies から、ターゲットリソース構成で Office 365 クラウドアプリを選択するよう説明されています。環境によって表示やロールアウトが異なる可能性があるため、記事や社内資料の一覧だけで判断しないことが重要です。(Microsoft Learn)
サインインログでアプリケーション ID を確認する
公式リファレンスでは、アプリケーション ID はシークレットではなく公開識別子であり、テナント内の Microsoft アプリについて確認できると説明されています。確認方法として、Enterprise applications で Microsoft Applications に絞り込む方法、サインインログの Application と Application ID 列を見る方法、Microsoft Graph PowerShell でサービスプリンシパルを一覧化する方法が示されています。(Microsoft Learn)
Microsoft Graph PowerShell で確認する場合の基本形は次のとおりです。
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All |
Where-Object { $_.AppOwnerOrganizationId -eq 'f8cdef31-a31e-4b4a-93e4-5f571e91255a' } |
Select-Object DisplayName, AppId |
Sort-Object DisplayNameサインインログで見つけた特定のアプリケーション ID を調べる場合は、次のように絞り込みます。
Get-MgServicePrincipal -Filter "appId eq '<application-id>'" |
Select-Object DisplayName, AppId注意したいのは、この方法で返るのはテナント内に存在する Microsoft サービスプリンシパルであり、Office 365 アプリスイートと完全一致するとは限らない点です。公式リファレンスでも、このセットは Office 365 アプリスイートを近似するが完全には一致しない可能性があり、スイートを構成するアプリはリファレンスの一覧を基準にすると説明されています。(Microsoft Learn)
移行期限はあるのか
「Office 365 App in Conditional Access reference」の更新そのものには、管理者が特定日までに設定を移行しなければならないという期限は示されていません。今回の主目的は、Office 365 アプリスイートに含まれるサービスの確認と、アプリケーション ID の確認方法を明確にすることです。
ただし、同じ条件付きアクセス領域では、Require approved client app から Require app protection policy への移行期限が別途存在しました。Microsoft は、Require approved client app grant の退役日を 2026年6月30日へ延長し、2026年6月30日にこのコントロールと、それを含む条件付きアクセスポリシーが読み取り専用状態へ移行すると説明しています。新しい条件付きアクセスポリシーでは Require app protection policy grant の利用が案内されています。(Microsoft Learn)
2026年7月時点で確認すべきなのは、Office 365 を対象にしたモバイル向けポリシーや、iOS・Android 向けポリシーに古い Require approved client app が残っていないかです。残っている場合、既存ポリシーは有効な限りエンドユーザーに引き続き適用されるとされていますが、新規作成や編集ができないため、運用変更が必要になったタイミングで詰まりやすくなります。(Microsoft Learn)
失敗しやすいポイント
「Teams だけを制御している」と思い込む
Teams は単独で完結するサービスではありません。SharePoint、Exchange、Planner、Stream、Whiteboard などと連携するため、Teams だけを対象にしたつもりでも、実際には別リソースへのアクセスで条件付きアクセスが評価されます。Microsoft のサービス依存関係の説明でも、関連アプリやサービス間で共通ポリシーを設定することで、ユーザーに表示されるプロンプトを減らせるとされています。(Microsoft Learn)
見慣れないアプリ名をすぐ不審アプリ扱いする
サインインログには、ユーザーに見えない Microsoft のバックエンドサービス名が表示されることがあります。たとえば、公式リファレンスにも IC3 Gateway、O365 Suite UX、Office Online SSO 系、Teams Graph Service など、一般ユーザーには馴染みのない名称が並んでいます。まずはアプリケーション ID、所有者、サインイン元、条件付きアクセス結果を確認し、Microsoft first-party アプリかどうかを切り分けるべきです。(Microsoft Learn)
What If だけで本番影響を判断する
What If ツールは便利ですが、サービス依存関係をテストしないという制約があります。特に Office 365 グループや Teams のような依存関係が多いアプリでは、What If の結果だけで「影響なし」と判断しないでください。Microsoft は、ポリシー変更時にレポート専用モードやサインインログ、条件付きアクセスの分析情報とレポートブックを使って確認することも案内しています。(Microsoft Learn)
個別アプリ除外で穴を作る
「一時的に SharePoint を除外する」「Teams だけ許可する」といった変更は、短期的には障害回避に見えても、長期的にはセキュリティホールになりやすい設定です。除外を使う場合は、期限、対象グループ、理由、承認者、戻し手順を必ず記録してください。
管理者が今すぐ確認すべきチェックリスト
- Office 365 を対象にした条件付きアクセスポリシーを一覧化する
- Exchange、SharePoint、Teams、OneDrive を個別指定しているポリシーを洗い出す
- Office 365 グループで保護したい目的と、個別指定したい目的を分ける
- サインインログで見慣れない Microsoft アプリ名とアプリケーション ID を確認する
- Microsoft Graph PowerShell で Microsoft 所有のサービスプリンシパルを確認できるようにする
- 変更前にレポート専用モードで影響を確認する
- Teams のような依存関係が多いアプリでは、What If だけでなく実ログを確認する
- Require approved client app を使う古い条件付きアクセスポリシーが残っていないか確認する
- 社内設計書、監査資料、運用手順の Office 365 対象サービス一覧を更新する
まとめ：Office 365 グループは「広すぎる」のではなく、依存関係を前提にした保護単位
Microsoft Entra の条件付きアクセスにおける Office 365 アプリは、Microsoft 365 の実態に合わせた保護単位です。Exchange、SharePoint、Teams、OneDrive、Office.com、Loop、Forms、Planner、Viva Engage、Copilot 関連サービス、各種バックエンドサービスが連携する現在の Microsoft 365 では、個別アプリだけでポリシーを組むと、依存関係による抜け漏れや想定外の認証要求が起こりやすくなります。
今回の「Office 365 App in Conditional Access reference」更新で最初にやるべきことは、新しい設定を急いで有効化することではありません。まず、既存の条件付きアクセスポリシーを棚卸しし、Office 365 グループを使うべきポリシーと個別アプリ指定を残すべきポリシーを分けることです。そのうえで、サインインログ、アプリケーション ID、レポート専用モードを使って、本当に意図した範囲にポリシーが適用されているかを確認しましょう。
コメント