Microsoft Teams RoomsにMicrosoft Entra Conditional Accessを適用している組織が、最初に確認すべきことは明確です。会議室用リソースアカウントを一般ユーザー向けポリシーから分離し、対話型MFA、認証方法の登録、サインイン頻度など、人の操作を前提とした制御を適用していないか確認してください。
Microsoftは2026年7月7日、Teams Rooms向けの条件付きアクセスとMicrosoft Intuneコンプライアンスに関するベストプラクティスを更新しました。更新版では、専用ポリシーの作成、対話型MFAを要求しないこと、Android端末のメーカー名・モデル情報を使ったデバイスフィルターなどが明確に示されています。(Microsoft Learn)
今回確認できるのは、管理者向け設定ガイダンスの更新です。テナントのポリシーが自動的に変更されるわけではありません。ただし、既存設定が最新のサポート範囲から外れている場合、Teams Roomsのサインアウト、再認証失敗、会議参加不能につながるため、早めの棚卸しが必要です。
「Microsoft updates Conditional Access and compliance best practices for Teams Rooms」とは
Microsoft Teams Roomsは、一般的なPCや個人用Teamsクライアントとは異なり、会議室専用のリソースアカウントで継続的にサインインします。
そのため、一般ユーザーを前提に設計した条件付きアクセスをそのまま適用すると、次のような問題が発生します。
- MFA承認画面で処理が止まる
- 認証方法やセルフサービスパスワードリセットの登録画面を完了できない
- サインイン頻度の設定によって定期的にサインアウトする
- デバイスコードフローのブロックによりAndroid端末をリモートサインインできない
- 非対応のIntuneコンプライアンス設定によって端末が非準拠になる
Microsoftの更新版ガイダンスは、こうした問題を避けながら、リソースアカウントと会議室端末を保護するための設計を整理したものです。
主なポイントは次のとおりです。
| 更新版で明確になったポイント | 管理者に求められる対応 |
|---|---|
| Teams Roomsのリソースアカウントを1つのグループにまとめる | 専用グループを作り、適用対象を明確にする |
| リソースアカウント専用の条件付きアクセスポリシーを作る | 一般ユーザー向けポリシーとの混在を避ける |
| 対話型MFAを要求しない | MFA承認や登録操作が必要なポリシーから除外する |
| Android端末のメーカー名・モデル情報を利用できる | デバイスフィルターで許可端末を絞り込む |
| Intuneの準拠状態をアクセス条件に利用する | WindowsとAndroidで別々のコンプライアンスポリシーを作る |
| サポートされないセッション制御がある | サインイン頻度やトークン保護などを見直す |
Microsoftは、ベストプラクティス本文に加えて、設定ごとのサポート可否を示す関連ページも2026年7月8日に更新しています。実際のポリシー設計では、概要ページだけでなく、このサポート一覧まで確認する必要があります。(Microsoft Learn)
影響範囲はリソースアカウント、端末、Microsoft 365へのサインイン
Microsoft Entra Conditional Accessが直接制御するのは、会議室の物理的な入退室や端末のローカルロックではありません。Teams RoomsのリソースアカウントがMicrosoft 365のクラウドリソースへサインインするときのアクセス可否です。
保護対象を整理すると、次のようになります。
| レイヤー | 主な対象 | 管理ポイント |
|---|---|---|
| ID | Teams Rooms用リソースアカウント | 専用グループ、命名規則、ポリシー分離 |
| 端末 | Teams Rooms on Windows、Teams Rooms on Android、Teamsパネル | プラットフォーム、デバイス属性、準拠状態 |
| クラウドリソース | Office 365、Exchange Online、Teams Services、SharePoint Online、Device Registration Service | 必要なサービスを誤ってブロックしない |
| デバイス状態 | ファイアウォール、暗号化、ルート化、セキュリティパッチなど | Intuneコンプライアンスポリシーで評価 |
| サインイン条件 | 場所、ネットワーク、ユーザーリスク、サインインリスク | 組織のライセンスと運用に合わせて設定 |
Teams Roomsで条件付きアクセスを利用するには、対象のTeams RoomsにMicrosoft Teams Rooms Proライセンスが必要です。Teams Rooms ProにはMicrosoft IntuneとMicrosoft Entra ID P1が含まれますが、Teams Rooms Basicには含まれません。Basicライセンスの端末をIntune準拠デバイスとして扱う設計は成立しないため、ライセンスの確認を最初に行う必要があります。(Microsoft Learn)
Teams Rooms用の条件付きアクセスポリシーを分離する
Microsoftは、Teams Roomsに関連付けられたリソースアカウントを1つのMicrosoft Entra IDユーザーグループにまとめ、既存の一般向け条件付きアクセスポリシーから除外したうえで、専用ポリシーを作成することを推奨しています。
例えば、リソースアカウントのUPNを次のように統一します。
[email protected]
[email protected]
[email protected]mtr-のような共通プレフィックスを付けておけば、Microsoft Entra IDの動的グループを利用し、新しい会議室アカウントを自動的に対象へ追加しやすくなります。(Microsoft Learn)
ただし、実務では既存ポリシーから先に除外しないよう注意してください。除外だけを先に実施すると、専用ポリシーが有効になるまでリソースアカウントが十分に保護されない時間が生まれます。
安全な移行順序は次のとおりです。
- Teams Rooms用リソースアカウントを一覧化する
- 専用グループを作成する
- 現在適用されている条件付きアクセスポリシーを確認する
- Teams Rooms専用ポリシーをレポート専用モードで作成する
- パイロット端末で動作を確認する
- 専用ポリシーを有効化する
- 一般ユーザー向けポリシーの除外を同じ変更作業内で反映する
対話型MFAと認証方法の登録を要求しない
Teams Roomsのリソースアカウントに、スマートフォンでの承認やセキュリティキーの操作を求めても、通常は応答する利用者がいません。
Microsoftは、Teams Roomsのリソースアカウントにユーザー対話型MFAを要求しないよう案内しています。また、セルフサービスパスワードリセットに伴う認証方法の追加など、サインイン中に操作が必要となるポリシーからも除外する必要があります。Teams端末は登録プロンプトを処理できず、サインインがブロックされるためです。(Microsoft Learn)
Microsoftのサポート一覧では、Android系Teams端末について「MFAを要求する」付与制御がサポート対象として表示されています。一方で、シームレスサインオンを維持する場合は適用せず、別のセカンダリ認証要素を使うよう注意書きがあります。
したがって、サポート表で「対応」と表示されていることを理由に、対話型MFAをそのまま有効化するべきではありません。 知識・所持・生体などのうち複数要素を満たす方法を検討しつつ、ユーザー操作を必要としないTeams Rooms向けの設計にする必要があります。(Microsoft Learn)
個人のユーザーアカウントでTeams端末へサインインさせる例外運用がある場合は、事前にPCやスマートフォンでMFAや認証方法の登録を完了させてください。端末上で初回登録を行う設計は避けます。
サポートされる条件付きアクセスと避けるべき設定
Teams Rooms向けの主なサポート状況を、実務上の判断に置き換えると次のようになります。(Microsoft Learn)
| 条件付きアクセス設定 | Windows | Android・Teams Phone・Teamsパネル | 運用上の判断 |
|---|---|---|---|
| デバイスを準拠としてマークする | 対応 | 対応 | Teams Rooms専用ポリシーの中心にしやすい |
| デバイスプラットフォーム | 対応 | 対応 | WindowsとAndroidを明示的に限定する |
| 場所・ネットワーク | 対応 | 対応 | 固定拠点など、実態に合う場合に使用する |
| デバイスフィルター | 対応 | 対応 | 許可端末や対象モデルの限定に使える |
| ユーザーリスク・サインインリスク | 対応 | 対応 | 必要なライセンスと誤検知時の運用を確認する |
| 認証フロー条件 | 対応 | 非対応 | Androidではデバイスコードフローを妨げない |
| MFAを要求する | 非対応 | 対応だが適用非推奨 | 対話型MFAは避ける |
| 認証強度・FIDO2要求 | 非対応 | 非対応 | Teams端末全体へ適用しない |
| Entraハイブリッド参加を要求する | 非対応 | 非対応 | 条件に含めない |
| 承認済みクライアントアプリを要求する | 非対応 | 非対応 | 一般モバイル向けポリシーから除外する |
| アプリ保護ポリシーを要求する | 非対応 | 非対応 | Teams Roomsには適用しない |
| パスワード変更を要求する | 非対応 | 非対応 | 自動サインインを妨げるため除外する |
| 利用規約への同意 | 非対応 | 非対応 | 利用者操作が必要なため適用しない |
| サインイン頻度 | 非対応 | 非対応 | 定期的なサインアウトの原因になる |
| 永続的ブラウザーセッション | 非対応 | 非対応 | 適用しない |
| 条件付きアクセスアプリ制御 | 非対応 | 非対応 | 適用しない |
| トークン保護 | 非対応 | 非対応 | プレビュー設定を含め適用しない |
継続的アクセス評価のカスタマイズもサポートされていません。設定項目を選択する場合は無効にしなければ、端末が不安定になる可能性があると案内されています。
必要なMicrosoft 365リソースをブロックしない
Teams Roomsは、Teams Servicesだけに接続しているわけではありません。会議予定の取得にはExchange Online、共有コンテンツにはSharePoint Online、端末登録にはDevice Registration Serviceなど、複数のMicrosoft 365リソースを利用します。
Microsoftのサポート一覧では、少なくとも次のリソースへのアクセスをブロックしないよう示されています。
- Office 365
- Office 365 SharePoint Online
- Microsoft Teams Services
- Device Registration Service
ベストプラクティスのポリシー例では、Office 365 Exchange Onlineも明示されています。対象リソースを細かく限定する場合は、Teamsだけを許可して完了とせず、実際のサインインログで依存先を確認してください。(Microsoft Learn)
デバイスコードフローの全面ブロックに注意する
デバイスコードフローは、ブラウザーや十分な入力機能を持たない端末をサインインさせるための認証フローです。一部のTeams端末では、初回登録、再プロビジョニング、再認証で利用されます。
一方、デバイスコードフローはフィッシングに悪用される可能性があるため、Microsoftは可能な範囲でブロックすることも推奨しています。
Teams Roomsがある組織では、単純にテナント全体で許可するのでも、全面的にブロックするのでもなく、次の構成が現実的です。
- デバイスコードフローを必要とするTeams端末用リソースアカウントを専用グループに入れる
- デバイスコードフローをブロックするポリシーから、そのグループを除外する
- Device Registration Serviceも対象リソースから除外する
- 例外グループのメンバーを定期的に監査する
- Teams端末以外のアカウントを同じ例外グループに入れない
例外はリソース単位ではなくアカウント単位で作用するため、対象アカウントはほかのアプリでもデバイスコードフローを利用できる状態になります。例外を恒久的に放置せず、所有者とレビュー周期を決めることが重要です。(Microsoft Learn)
Android端末はメーカー名とモデルで絞り込める
Teams Android端末では、初回ログイン時にメーカー名とデバイスモデルが表示名フィールドへ渡され、条件付きアクセスのデバイスフィルターに利用できます。
これにより、例えば次のような制御を検討できます。
- 承認済みメーカー・モデルだけを対象にする
- 廃止予定モデルを除外する
- パイロット用モデルだけに新しいポリシーを適用する
- 不明な端末名や登録されていない端末を検知する
ただし、デバイスフィルターはMicrosoft Entra IDに登録されたデバイス属性を評価します。未登録端末では属性が取得できないため、「一致する端末だけを許可する」のか、「一致しない端末をブロックする」のかで挙動が変わります。展開前にレポート専用モードと実機で確認してください。(Microsoft Learn)
IntuneコンプライアンスポリシーはWindowsとAndroidで分ける
Microsoft Teams Rooms on WindowsとTeams Rooms on Androidでは、利用できるIntuneコンプライアンス設定が異なります。1つの共通基準へ無理に合わせず、プラットフォーム別にポリシーを作成してください。
| プラットフォーム | 使用を検討できる設定 | 避けるべき設定 |
|---|---|---|
| Windows | BitLocker、セキュアブート、コード整合性、ファイアウォール、TPM、Defender、リアルタイム保護、Defender for Endpointのマシンリスク | OSの最小・最大バージョン、有効なOSビルド、パスワードポリシー、Defenderマルウェア対策の最小バージョン |
| Android AOSP | ルート化端末の検知、OSの最小・最大バージョン、最小セキュリティパッチレベル、ストレージ暗号化 | 端末ロック用パスワード、パスワードの種類、パスワード要求までの時間 |
BitLockerやストレージ暗号化をコンプライアンス条件にする場合は、先に端末側で暗号化を有効化しておく必要があります。設定されていない状態で「暗号化必須」を有効にすると、対象端末が一斉に非準拠になる可能性があります。(Microsoft Learn)
Windowsの最小OSバージョンは設定しない
ここには、公式情報を読むうえで注意すべき不整合があります。
2026年7月7日更新のベストプラクティス本文では、Windows向けコンプライアンスポリシーの例として「オペレーティングシステムの最小バージョン」が挙げられています。一方、7月8日更新の詳細なサポート一覧では、WindowsのOS最小・最大バージョンは非サポートです。
非サポートの理由は、Teams RoomsがWindowsを自動更新するため、固定したバージョン条件によってOS更新後のサインインが失敗する可能性があることです。(Microsoft Learn)
実際の設定では、概要ページの例をそのままコピーせず、設定単位のサポート可否を示す詳細一覧を優先し、WindowsのOSバージョン条件は使用しないのが安全です。
Android AOSP移行後の非準拠に注意する
Teams Android端末をAOSP Device Managementへ移行し、条件付きアクセスで準拠デバイスを必須にしている場合は、Android AOSP用のコンプライアンスポリシーが必要です。
Microsoftは、準拠状態を要求しているにもかかわらず、移行後の端末へコンプライアンスポリシーを割り当てていない場合、端末がサインアウトすると案内しています。また、Teams Rooms BasicライセンスにはIntuneが含まれないため、BasicライセンスのリソースアカウントではIntuneへ自動登録されません。(Microsoft Learn)
監査と検知で確認すべきポイント
専用グループと専用ポリシーを作成すると、サインインログ上でもTeams Roomsの挙動を切り分けやすくなります。
監査では、Microsoft Entra、Microsoft Intune、Teams端末の状態を別々に見るのではなく、同じリソースアカウントと端末IDを軸に関連付けて確認します。
| 確認場所 | 主な確認内容 | 異常の例 |
|---|---|---|
| Microsoft Entraサインインログ | 適用ポリシー、対象リソース、場所、端末情報、失敗理由 | MFA要求、非準拠、対象リソースのブロック |
| Microsoft Entra監査ログ | 条件付きアクセスポリシーの作成・更新・削除 | 意図しない除外追加、ポリシーの無効化 |
| Intuneコンプライアンス | 端末状態、設定単位の準拠結果、ポリシー未割り当て端末 | 暗号化、ルート化、Defender、パッチの違反 |
| デバイスコードフローのログ | 認証プロトコル、元の転送方法、利用アプリ、場所 | 特権ユーザーや未知のアプリによる利用 |
| Teams Roomsの運用監視 | サインイン状態、カレンダー同期、会議参加、周辺機器 | サインアウト、カレンダー取得失敗 |
Microsoft Entraサインインログ
Microsoft Entra管理センターで、次の順に開きます。
Entra ID
→ Monitoring & health
→ Sign-in logs対象のTeams Roomsリソースアカウントで絞り込み、サインインイベントの「Conditional Access」タブを確認します。
特に見るべき項目は次のとおりです。
- Conditional Accessの成功・失敗
- 適用されたポリシー名
- 対象リソース
- クライアントアプリ
- デバイス表示名
- IPアドレスと場所
- 準拠状態
- 失敗理由
条件付きアクセスの設定を変更した直後にサインイン障害が起きた場合は、対象イベントのポリシー評価結果を最初に確認します。(Microsoft Learn)
デバイスコードフローを監査するときは、現在の利用状況を調べるために「Authentication protocol = Device code flow」で絞り込みます。過去のデバイスコードフローに由来するセッションまで追う場合は、「Original transfer method = Device code flow」も確認してください。(Microsoft Learn)
Microsoft Entra監査ログ
ポリシー変更の追跡には、次のフィルターを使用します。
Entra ID
→ Monitoring & health
→ Audit logs設定例は次のとおりです。
| フィルター | 値 |
|---|---|
| Service | Conditional Access |
| Category | Policy |
| Activity | Update Conditional Access policy |
監査イベントの「Modified properties」を開くと、変更前と変更後の設定を比較できます。障害発生時に「誰が、いつ、どの除外や条件を変更したか」を確認するため、運用手順に組み込んでください。(Microsoft Learn)
Intuneコンプライアンスレポート
Microsoft Intune管理センターでは、次の場所を確認します。
Devices
→ Compliance
→ Monitor端末全体の準拠状態に加え、個別ポリシーのデバイス状態、設定単位の結果、コンプライアンスポリシーが割り当てられていない端末を確認できます。
Intuneのレポートには、端末がポリシーを受信してチェックインし、結果を報告するまで時間がかかる場合があります。オンライン端末でも反映に最大24時間かかる可能性があるため、ポリシー作成直後の「未評価」を即座に障害と判断しないようにします。(Microsoft Learn)
すぐに対応すべき組織を判断するチェック表
| 現在の状況 | 対応優先度 | 判断 |
|---|---|---|
| 全ユーザー対象のMFAポリシーにTeams Roomsが含まれる | 高 | 対話型MFAでサインインが停止する可能性がある |
| SSPRや認証方法登録をサインイン時に要求している | 高 | Teams端末では登録プロンプトを処理できない |
| デバイスコードフローを全面ブロックしている | 高 | Android端末の初回登録、リモートサインイン、再認証に影響する |
| サインイン頻度をTeams Roomsへ適用している | 高 | 定期的なサインアウトにつながる |
| Windows端末でOS最小・最大バージョンをコンプライアンス条件にしている | 高 | 現行サポート一覧では非サポート |
| Windows端末でパスワードポリシーを適用している | 高 | ローカルアカウントの自動サインインを妨げる |
| Teams Rooms BasicでIntune準拠を要求している | 高 | BasicにはIntuneと条件付きアクセスが含まれない |
| Android AOSP移行後にコンプライアンスポリシーがない | 高 | 準拠必須環境ではサインアウトする可能性がある |
| 専用ポリシーはあるが、サポート可否を確認していない | 中 | 非対応のセッション制御などが残っている可能性がある |
| レポート専用モードやサインインログを使っていない | 中 | 本番適用時の影響を事前に把握できない |
| Proライセンス、専用グループ、専用ポリシー、対応設定がそろっている | 低 | 定期監査と例外グループのレビューを継続する |
Microsoft EntraのSecurity Defaultsを使用している場合も注意が必要です。Microsoftは、Teams共有デバイスではSecurity Defaultsをサポートせず、条件付きアクセスを使用するよう案内しています。(Microsoft Learn)
管理者が優先して進める対応手順
リソースアカウントとライセンスを棚卸しする
次の情報を一覧化します。
- リソースアカウントのUPN
- 会議室名と設置場所
- Teams Rooms on WindowsまたはAndroid
- Teamsパネルの有無
- Teams Rooms ProまたはBasic
- Intune登録状態
- Microsoft EntraデバイスID
- 現在のコンプライアンス状態
- 適用されている条件付きアクセスポリシー
アカウントと端末の対応関係が不明なままでは、除外やグループ化を安全に実施できません。
一般ユーザー向けポリシーへの巻き込みを確認する
特に、次の条件付きアクセスポリシーを確認します。
- 全ユーザーを対象とするMFA
- 認証強度の要求
- 認証方法やセキュリティ情報の登録
- サインイン頻度
- パスワード変更
- 利用規約への同意
- 承認済みクライアントアプリ
- アプリ保護ポリシー
- ハイブリッド参加済みデバイス
- デバイスコードフローのブロック
- すべてのクラウドリソースを対象にしたブロック
Teams Roomsが除外されているかだけでなく、別のポリシーから同じ制御が適用されていないかも確認してください。条件付きアクセスは複数ポリシーが同時に評価されるため、1つのポリシーで除外しても、別のポリシーがサインインをブロックすることがあります。
プラットフォーム別のコンプライアンスポリシーを作る
WindowsとAndroidを同じポリシーで管理しようとせず、それぞれサポートされる設定だけを使います。
Windowsでは、ファイアウォール、Defender、セキュアブート、TPMなど、Teams Roomsの基盤要件を検証する設定を中心にします。Android AOSPでは、ルート化、セキュリティパッチ、暗号化、OSバージョンを中心にします。
既存端末へ暗号化必須などを追加する場合は、先に現状の準拠率を確認し、非準拠になったときの復旧手順を用意してください。
専用ポリシーをレポート専用モードで検証する
一般ユーザー向けポリシーを直接編集するのではなく、Teams Rooms専用ポリシーを作成し、最初はレポート専用モードにします。
レポート専用モードでは、通常はアクセスをブロックせずに評価結果を記録できます。Microsoftは、新しいポリシーを既存ポリシーと並行して評価し、サインインログやConditional Access Insightsで結果を比較してから有効化する方法を推奨しています。(Microsoft Learn)
ただし、準拠デバイスを要求するレポート専用ポリシーでは、Android端末にデバイス証明書の選択画面が表示される場合があります。レポート専用だから完全に無影響とは考えず、会議がない時間帯に実機で検証してください。
パイロット端末で利用シナリオを確認する
少なくとも次のテストを実施します。
| テスト項目 | 確認する結果 |
|---|---|
| 電源再投入 | 自動的にTeamsへサインインする |
| 手動サインアウト・再サインイン | MFAや登録画面で停止しない |
| Androidのリモートサインイン | デバイスコードフローが正常に完了する |
| 会議室カレンダーの表示 | Exchange Onlineへのアクセスが成功する |
| Teams会議への参加 | Teams Servicesへのアクセスが成功する |
| コンテンツ共有 | SharePoint Onlineへのアクセスが成功する |
| Intune準拠状態の変更 | 非準拠時だけ想定どおりアクセスが制限される |
| ネットワーク変更 | 信頼済み場所の条件が意図どおり評価される |
| Windows更新後の再起動 | OS更新後も自動サインインする |
| ポリシー変更後の再認証 | セッション更新や再認証で停止しない |
テスト中は、端末画面だけでなくMicrosoft EntraのサインインログとIntuneの設定単位レポートを同時に確認します。
段階的に有効化し、ロールバック手順を残す
最初からすべての会議室へ有効化せず、建物やフロア単位で段階的に展開します。
変更記録には、次の情報を残してください。
- ポリシー名とポリシーID
- 対象グループ
- 除外グループ
- 変更前後の設定
- パイロット端末
- 検証したサインインイベント
- 問題発生時に無効化するポリシー
- 一時的に戻す除外設定
- 変更承認者と実施者
Teams Roomsの障害は会議開始時に発覚しやすいため、復旧手順を調査しながら作るのではなく、ポリシー有効化前に用意しておくことが重要です。
まとめ
2026年7月7日の更新で、Microsoft Teams Roomsに対する条件付きアクセスの基本方針がより明確になりました。
重要なのは、Teams Roomsのセキュリティを弱めることではありません。一般ユーザーとは異なるサインイン特性を理解し、リソースアカウント専用のグループ、専用の条件付きアクセスポリシー、プラットフォーム別のIntuneコンプライアンスを組み合わせることです。
特に優先すべき対応は次の3点です。
- 対話型MFA、認証方法登録、サインイン頻度が適用されていないか確認する
- デバイスコードフローとDevice Registration Serviceを誤ってブロックしていないか確認する
- WindowsのOSバージョン条件など、サポート一覧で非対応となっている設定を外す
最初の一手として、実際に稼働しているTeams Roomsリソースアカウントを1つ選び、Microsoft Entraのサインインログから適用ポリシーを確認してください。そこで一般ユーザー向けMFAや非対応のセッション制御が見つかった場合は、専用グループとレポート専用ポリシーの作成を優先します。
コメント