2026年7月7日に国内で確認されたMicrosoftの公式情報更新により、Microsoft Teams Roomsで利用できるMicrosoft Entra Conditional AccessとMicrosoft Intuneデバイスコンプライアンスポリシーの対応範囲が整理されました。
結論として、管理者が最優先で確認すべきなのは、Teams Roomsのリソースアカウントが一般ユーザー向けの条件付きアクセスポリシーに巻き込まれていないか、Windows端末に非サポートのOSバージョン・パスワード要件を適用していないか、Android端末のDevice Code Flowを遮断していないかの3点です。
今回更新されたのは、ポリシーの自動適用機能ではなく、Microsoftがサポートする設定の一覧です。既存環境の設定が自動的に変更されるわけではありませんが、非サポート設定を使用している環境では、サインアウトやサインイン不能につながる可能性があります。Microsoft Learn上の最終更新日は2026年7月6日と表示されており、本記事では国内で7月7日に確認された更新として扱います。(Microsoft Learn)
Microsoft Teams Roomsの条件付きアクセス対応情報とは
今回更新された公式情報は、Microsoft Teams RoomsやTeams Androidデバイスに対して、どのMicrosoft Entra Conditional Access設定とMicrosoft Intuneコンプライアンス設定を利用できるかを示すサポートマトリックスです。
対象には、次のような共有デバイスが含まれます。
- Teams Rooms on Windows
- Teams Rooms on Android
- Teams電話
- Teamsパネル
- Teamsディスプレイ
条件付きアクセスの一覧では、主にTeams Rooms on Windowsと、AndroidベースのTeams Rooms・電話・パネルが整理されています。Intuneのコンプライアンス設定では、AOSP Device Managementで管理されるTeams電話、ディスプレイ、パネルについても設定可否が示されています。(Microsoft Learn)
保護対象はリソースアカウントのサインインと端末状態
Teams Roomsでは、通常の社員アカウントではなく、Microsoft EntraアカウントとExchangeのリソースメールボックスを組み合わせた会議室用リソースアカウントを使用します。
Conditional Accessは、このリソースアカウントがMicrosoft 365へサインインするときのアクセス可否を判断します。Intuneは、端末が暗号化、ファイアウォール、セキュリティパッチなどの要件を満たしているかを評価し、その結果をConditional Accessへ渡します。(Microsoft Learn)
つまり、今回の情報が対象としているのは、会議の録画、チャット、保持期間などのコンテンツ管理ではありません。主な対象は次の2点です。
- Teams Roomsのリソースアカウントが安全な条件でサインインしているか
- サインイン元のTeams Rooms端末が組織のセキュリティ要件を満たしているか
影響を受ける環境と対応要否
次の表を使うと、自社環境でどの程度の対応が必要かを判断できます。
| 現在の環境 | 対応要否 | 優先度 |
|---|---|---|
| 「すべてのユーザー」向けConditional AccessにTeams Roomsのリソースアカウントが含まれている | 専用グループと専用ポリシーへの分離が必要 | 最優先 |
| Teams Rooms on WindowsにOSの最小・最大バージョンを要求している | 現在のサポート一覧と照合し、原則として解除または再設計 | 最優先 |
| Windows端末にパスワード複雑性や有効期限を要求している | 自動サインインを妨げる可能性があるため見直し | 最優先 |
| Android端末でDevice Code Flowをブロックしている | リモートサインインができなくなるため見直し | 最優先 |
| Teams Roomsに対して対話型MFAを強制している | サインイン方式と非互換になる可能性があるため見直し | 最優先 |
| Teams Rooms専用ポリシーを作成し、準拠デバイスと信頼済み場所を要求している | 更新後のサポート一覧との再照合と監視を実施 | 中 |
| Intuneを使用せず、Conditional Accessも適用していない | 直ちに障害は発生しないが、セキュリティ設計を検討 | 中 |
| Teams RoomsやTeams共有デバイスを利用していない | 原則として対応不要 | 低 |
Microsoftは、Teams Roomsのリソースアカウントを1つのMicrosoft Entraグループにまとめ、一般ユーザー向けポリシーから除外したうえで、専用のConditional Accessポリシーを作成することを推奨しています。(Microsoft Learn)
Conditional Accessでサポートされる主な設定
以下は、2026年7月更新時点の公式サポート一覧を、管理者向けに要約したものです。(Microsoft Learn)
| 設定領域 | サポートされる主な設定 | 避けるべき設定 |
|---|---|---|
| 割り当て | ユーザー、対象リソース、ネットワーク | 必要なMicrosoft 365サービスの一律ブロック |
| 条件 | ユーザーリスク、サインインリスク、デバイスプラットフォーム、場所、クライアントアプリ、デバイスフィルター | Insider Risk、Android端末への認証フロー制御 |
| アクセス制御 | アクセスのブロック、アクセスの許可、準拠デバイスの要求 | 認証強度、ハイブリッド参加済みデバイス、承認済みクライアントアプリ、アプリ保護ポリシー |
| ユーザー操作 | Android側ではMFAがサポート表に掲載 | Windowsへの対話型MFA、パスワード変更、利用規約への同意 |
| セッション | 原則として積極的に設定しない | サインイン頻度、永続的ブラウザーセッション、Conditional Access App Control、トークン保護 |
「準拠デバイスを要求する」はWindowsとAndroidの両方で利用可能
Teams Rooms向けのConditional Accessで中心となるのが、アクセス許可の条件として「デバイスは準拠としてマーク済みである必要があります」を設定する方法です。
この設定により、Intuneで非準拠と判定された端末から、Teams RoomsのリソースアカウントがMicrosoft 365へアクセスすることを防げます。
ただし、次の前提が必要です。
- Teams Rooms端末がIntuneへ正しく登録されている
- 端末の種類に合ったコンプライアンスポリシーが割り当てられている
- IntuneからMicrosoft Entraへ準拠状態が返されている
- リソースアカウントに必要なライセンスが割り当てられている
Teams Rooms on Windowsでは、端末レベルのConditional Accessを適用するためにIntune登録が必要です。登録後、Teams Roomsアプリは端末の準拠状態をConditional Accessの評価へ送信します。(Microsoft Learn)
一般ユーザーと同じ対話型MFAを要求しない
Teams Rooms on Windowsは、通常のPC版Teamsとは異なり、利用者の操作を必要としない認証を前提としています。そのため、スマートフォンへの承認通知、FIDO2セキュリティキー、証明書の選択など、利用者による操作が必要な認証方式をそのまま適用できません。
公式のサポート一覧では、Windows版に対する「多要素認証を要求する」は非サポートです。Android側はサポート表に掲載されていますが、シームレスなサインインを維持する場合は強制しないよう注意書きがあります。
Microsoftのベストプラクティスでも、共有スペースのリソースアカウントに対話型MFAを要求せず、代わりに次のような条件を組み合わせることが推奨されています。
- Intuneで準拠した端末
- 信頼済みネットワークまたは名前付き場所
- 専用のリソースアカウント
- デバイスプラットフォーム
- 必要なMicrosoft 365リソースだけへのアクセス
認証強度を使ったFIDO2セキュリティキーなどの要求も、Teamsデバイス全体を対象にするConditional Accessではサポートされていません。(Microsoft Learn)
AndroidではDevice Code Flowをブロックしない
Teams Androidデバイスでは、Webブラウザーを利用したリモートサインインにDevice Code Flowが使われます。
Conditional AccessでDevice Code Flowをブロックすると、管理者が別のPCやスマートフォンから端末へサインインできなくなります。認証フロー条件自体も、AndroidのTeams Rooms、Teams電話、Teamsパネルでは非サポートとされています。(Microsoft Learn)
全社的にDevice Code Flowを禁止するポリシーを設定している場合は、Teams Androidデバイス用のリソースアカウントを除外するか、専用ポリシーへ分離する必要があります。
必要なMicrosoft 365リソースをブロックしない
Teams Roomsが正常に動作するには、少なくとも次のサービスへのアクセスが必要です。
- Office 365
- Exchange Online
- SharePoint Online
- Microsoft Teams Services
- Device Registration Service
「すべてのクラウドアプリをブロックし、一部だけを除外する」設計では、Device Registration ServiceやSharePoint Onlineの除外漏れが起きやすくなります。
除外漏れがあると、Teamsへのサインインだけでなく、予定表の取得、会議情報の同期、端末登録、ファイル関連機能にも影響する可能性があります。対象リソースを限定する場合は、実機検証を行ってください。(Microsoft Learn)
Intuneコンプライアンスポリシーの対応範囲
Teams Rooms on WindowsとAndroidベースのTeamsデバイスでは、利用できるコンプライアンス設定が異なります。PCやスマートフォン向けの一般的なIntuneテンプレートを、そのまま共有会議室端末へ割り当てるべきではありません。(Microsoft Learn)
| プラットフォーム | サポートされる主な設定 | 非サポートまたは注意が必要な設定 |
|---|---|---|
| Teams Rooms on Windows | BitLocker、Secure Boot、コード整合性、ストレージ暗号化、ファイアウォール、TPM、Microsoft Defender、リアルタイム保護、Defender for Endpointのマシンリスク | OSの最小・最大バージョン、有効なOSビルド、すべてのパスワードポリシー、Defenderの最小バージョン |
| Teams Rooms on Android | ルート化端末の検出、OSの最小・最大バージョン、最小セキュリティパッチレベル、ストレージ暗号化 | 画面ロック用パスワード、パスワード種類、非操作時のパスワード要求時間 |
| Teams電話・ディスプレイ・パネル | AOSP管理ではAndroid版と同様の設定 | Android端末用のパスワード・画面ロック要件 |
WindowsではOSバージョン制限を設定しない
Teams Rooms on Windowsは、OSを自動更新する仕組みを持っています。
Intuneで最小または最大OSバージョンを固定すると、Windows更新後に端末が条件から外れ、非準拠と判定される可能性があります。Conditional Accessで準拠デバイスを必須にしている場合、そのままTeams Roomsがサインインできなくなるおそれがあります。
2026年7月時点のサポート一覧では、次の設定が非サポートです。
- OSの最小バージョン
- OSの最大バージョン
- 有効なOSビルド
- Microsoft Defenderマルウェア対策の最小バージョン
OSやDefenderの更新状況は、コンプライアンスポリシーで固定値を要求するのではなく、Teams Roomsの更新管理、端末インベントリ、脆弱性管理などで監視するほうが安全です。(Microsoft Learn)
Windowsのパスワードポリシーは自動サインインを妨げる
Teams Rooms on Windowsでは、ローカルのSkypeユーザーを使った自動サインイン処理が行われます。
一般PC向けのパスワード複雑性、有効期限、ロック画面などのコンプライアンス設定を割り当てると、この自動サインインが妨げられる可能性があります。そのため、公式一覧ではすべてのパスワードポリシーが非サポートです。(Microsoft Learn)
BitLockerは有効化してから準拠条件にする
「BitLockerを要求する」と「データストレージの暗号化を要求する」はサポートされていますが、先に端末側でBitLockerを有効化する必要があります。
暗号化されていない端末へ、いきなりコンプライアンス要件だけを適用すると、端末は非準拠になります。その状態でConditional Accessを有効化すれば、Teams Roomsのサインインが遮断されます。
安全な順序は次のとおりです。
- 端末でBitLockerが有効になっていることを確認する
- 回復キーが管理されていることを確認する
- Intuneコンプライアンスポリシーをレポートで確認する
- 端末が準拠になったことを確認する
- Conditional Accessで準拠デバイスを要求する
AndroidではAOSP用ポリシーを作成する
AOSP Device Managementで管理されるTeams Androidデバイスでは、次の設定が利用できます。
- ルート化されたデバイスをブロック
- OSの最小・最大バージョン
- 最小セキュリティパッチレベル
- データストレージの暗号化
一方、Teamsデバイスは一般的なスマートフォンのような画面ロック用パスワードを前提としていません。パスワード種類や、非操作時間後のパスワード要求を設定しないようにします。(Microsoft Learn)
公式ドキュメント間のOSバージョン記述に注意
2026年7月時点では、Microsoftの公式ドキュメント間に注意すべき記述の違いがあります。
更新されたサポート一覧では、Teams Rooms on WindowsのOS最小・最大バージョンは非サポートです。一方、同日に更新されたベストプラクティス記事の設定例には、「最小OSバージョンを要求する」という記述が残っています。(Microsoft Learn)
現時点では、具体的なサポート可否を示しているサポート一覧を優先し、Windows版にOSバージョン条件を新規設定しないのが安全です。既に設定している場合は、直ちに全解除するのではなく、レポート専用ポリシーやパイロット端末で影響を確認してください。
管理者が実施すべき設定手順
Teams Roomsの端末とアカウントを一覧化する
最初に、次の情報を一覧にします。
| 確認項目 | 内容 |
|---|---|
| リソースアカウント | UPN、表示名、所属グループ |
| 端末 | デバイス名、OS、メーカー、モデル |
| 管理方式 | Intune登録済みか、AOSP管理か |
| コンプライアンス | 準拠、非準拠、未評価 |
| ライセンス | Teams Rooms Pro、Intune、Microsoft Entra ID P1の利用状況 |
| Conditional Access | 現在適用されているポリシーと除外設定 |
| ネットワーク | 設置拠点、送信元IP、名前付き場所 |
Microsoftのベストプラクティスでは、Teams RoomsでConditional AccessとIntuneコンプライアンスを利用する前提として、Teams Rooms Proライセンスとリソースアカウントを挙げています。Conditional AccessにはMicrosoft Entra ID P1が必要です。(Microsoft Learn)
リソースアカウントを専用グループへ分離する
例えば、次のようなグループを作成します。
MTR-Resource-Accounts
このグループに、すべてのTeams Rooms用リソースアカウントを登録します。アカウント名を一定の接頭辞で統一している場合は、動的グループも検討できます。
そのうえで、次の構成にします。
- 一般ユーザー向けConditional AccessからTeams Roomsグループを除外
- Teams Rooms専用のConditional Accessを作成
- Windows用とAndroid用のIntuneコンプライアンスポリシーを分離
- ポリシー名に対象プラットフォームと目的を含める
一般ユーザーと共有デバイスを同じポリシーで管理すると、対話型MFA、認証方法登録、パスワード変更などがTeams Roomsにも要求され、サインインが停止する可能性があります。(Microsoft Learn)
専用Conditional Accessをレポート専用で作成する
実務上の基本構成は次のとおりです。
| 項目 | 推奨設定例 |
|---|---|
| 対象ユーザー | Teams Roomsリソースアカウント用グループ |
| 対象リソース | Teams Roomsに必要なMicrosoft 365サービス |
| デバイスプラットフォーム | Windows、Android |
| 場所 | 会議室を設置している信頼済み拠点 |
| アクセス許可 | 準拠としてマークされたデバイスを要求 |
| MFA | 対話型MFAは要求しない |
| セッション制御 | 原則として未設定 |
| ポリシー状態 | 最初はレポート専用 |
レポート専用モードでは、Conditional Accessの条件は評価されますが、アクセスのブロックやMFA要求は実際には強制されません。結果はサインインログのConditional Accessタブとレポート専用タブに記録されます。(Microsoft Learn)
端末ごとにパイロット検証する
全端末へ一斉適用せず、少なくとも次の単位でパイロット端末を選びます。
- Teams Rooms on Windowsを1台以上
- Teams Rooms on Androidを1台以上
- メーカーやモデルが異なる端末
- ネットワーク拠点が異なる端末
- Teams電話やパネルを利用している場合は各種類
検証では、単に現在サインインできるかだけでなく、次の操作まで確認します。
- 端末再起動後の自動サインイン
- 予定表と会議情報の同期
- 会議への参加と発信
- ソフトウェア更新後の再サインイン
- Android端末のリモートサインイン
- Intuneの準拠状態更新
- トークン更新後の継続利用
Conditional Accessのレポート専用結果で失敗がなく、Intuneで端末が準拠と表示されてから、対象グループを段階的に拡大します。
監査ログと検知への影響
今回の対応では、ポリシーを設定するだけでなく、変更履歴、サインイン結果、端末の準拠状態を別々に監視する必要があります。
| 確認したい内容 | 確認場所 | 主な確認項目 |
|---|---|---|
| Conditional Accessの変更履歴 | Microsoft Entra監査ログ | ポリシーの追加、更新、削除、名前付き場所の変更 |
| 実際のアクセス判定 | Microsoft Entraサインインログ | 成功、失敗、適用ポリシー、対象リソース、端末情報 |
| レポート専用ポリシーの影響 | サインインログのレポート専用結果 | 成功、失敗、ユーザー操作が必要、未適用 |
| Intuneポリシーの変更履歴 | Intune監査ログ | 作成、編集、削除、割り当て変更 |
| 端末の準拠状態 | Intuneのデバイスコンプライアンスレポート | 準拠、非準拠、猶予期間、未評価 |
| 個別設定の失敗 | Intuneの設定別レポート | 暗号化、Secure Boot、パッチレベルなど |
| 長期的な傾向 | Conditional Access Insights and Reporting | ポリシー別の成功・失敗傾向 |
Microsoft Entraの監査ログでは、Conditional Accessポリシーの追加、更新、削除や、名前付き場所の変更を追跡できます。(Microsoft Learn)
Intuneの監査ログには、ポリシーの作成、更新、削除、割り当て、リモート操作など、変更を伴う管理操作が記録されます。Intuneの監査機能はすべての顧客で有効化されており、無効化できません。(Microsoft Learn)
サインインログは対話型だけでなく非対話型も確認する
Teams Roomsは、利用者が画面上で操作しなくても、バックグラウンドでMicrosoft 365サービスへアクセスします。
そのため、Microsoft Entraのサインインログでは、対話型ユーザーサインインだけでなく、非対話型ユーザーサインインも確認します。サインインログでは、誰が、どのクライアントから、どのリソースへアクセスしたかを確認できます。(Microsoft Learn)
特に監視したいのは、次の変化です。
- Teams Roomsリソースアカウントの失敗件数が急増した
- レポート専用ポリシーで失敗が継続している
- 「準拠デバイスを要求する」でブロックされた
- 必要なMicrosoft 365リソースへのアクセスが拒否された
- Android端末のリモートサインインが失敗し始めた
- ポリシー変更直後から複数の会議室がサインアウトした
Intuneの表示には時間差がある
Intuneのコンプライアンス状態は継続的に評価されますが、管理センターのレポートは端末がIntuneへチェックインした時点で更新されます。
そのため、ポリシーを変更した直後に「未評価」や「保留中」と表示されても、直ちに設定ミスとは限りません。端末がオンラインでも、ポリシーの受信、評価、状態報告が完了してレポートへ現れるまで最大24時間かかる場合があります。(Microsoft Learn)
共有デバイスでは、最後にチェックインしたユーザーの状態が表示されたり、システムアカウントとユーザーの複数レコードが表示されたりすることもあります。次の情報を合わせて確認してください。
- 最終チェックイン日時
- IntuneデバイスID
- Microsoft EntraデバイスID
- リソースアカウントのUPN
- ポリシー別の準拠状態
- 設定別の準拠状態
失敗しやすいポイント
全社員向けポリシーから除外しただけで終わらせる
Teams Roomsを一般ユーザー向けポリシーから除外することは必要ですが、除外しただけでは保護されません。
専用ポリシーを作成し、準拠デバイス、デバイスプラットフォーム、信頼済み場所など、Teams Roomsでサポートされる条件を組み合わせる必要があります。
サポートされる設定をすべて有効化する
「サポートされる」と「推奨される」は同じではありません。
Microsoftは、サポートされる設定でも、サインアウトや望ましくない動作を引き起こす可能性があるため、大規模展開前のテストを求めています。特にサインイン頻度は定期的なサインアウトを発生させ、Microsoft 365サービス単位で設定するとTeamsデバイスのサインイン処理を中断する可能性があります。(Microsoft Learn)
IntuneポリシーとConditional Accessを同時に本番適用する
暗号化やセキュリティ設定が整っていない状態で、IntuneコンプライアンスポリシーとConditional Accessを同時に強制すると、原因の切り分けが難しくなります。
次の順序で進めると安全です。
- 端末側のセキュリティ設定を整える
- Intuneコンプライアンスポリシーを割り当てる
- 端末が準拠になったことを確認する
- Conditional Accessをレポート専用で評価する
- パイロットグループで有効化する
- 対象端末を段階的に増やす
管理画面の「準拠」だけを信頼する
端末が全体として「準拠」と表示されても、特定のポリシーや設定が正しく評価されているとは限りません。
Intuneでは、次の3段階で確認します。
- デバイス全体の準拠状態
- ポリシー単位の準拠状態
- 設定単位の準拠状態
さらに、Microsoft Entraのサインインログで、Conditional Accessが実際に端末を準拠として認識しているかを確認する必要があります。
優先すべき対応
最初に実施すべきなのは、新しいポリシーの作成ではなく、現在Teams Roomsのリソースアカウントへ適用されているConditional Accessを一覧化することです。
次の順序で確認してください。
- Teams Roomsのリソースアカウントを抽出する
- 各アカウントへ適用されるConditional Accessを確認する
- 対話型MFA、認証強度、サインイン頻度、Device Code Flowのブロックがないか確認する
- Windows端末のIntuneポリシーにOSバージョンやパスワード要件がないか確認する
- Android端末がAOSP用コンプライアンスポリシーを受けているか確認する
- 専用ポリシーをレポート専用で作成する
- サインインログとIntuneレポートで影響を確認する
- 端末種類ごとにパイロット展開する
Teams Roomsの条件付きアクセスでは、セキュリティ設定を増やすことよりも、共有デバイスの認証方式と互換性のある設定だけを選ぶことが重要です。一般ユーザー向けポリシーを流用せず、WindowsとAndroidの違いを分けて設計することで、サインイン障害を避けながら端末とリソースアカウントを保護できます。
コメント