Microsoft Intuneの公式ドキュメント更新「Remove Substrate implementation detail from sovereign cloud note」は、Quiet TimeポリシーのSovereign Cloud向け注意書きから、内部実装を示す「Substrate」への言及を削除した更新です。
結論から言うと、この更新はSovereign CloudでQuiet Timeポリシーが利用可能になったことを意味しません。US Government Community Cloud、GCC High、DoD、Microsoft Azure operated by 21Vianetでは、Quiet Timeポリシーは引き続きサポート対象外です。確認すべきなのは、機能設定そのものよりも、社内ドキュメント、運用手順、監査説明、移行計画で「なぜ非対応なのか」を古い実装名に依存して説明していないかです。
Microsoft Intuneの公式ドキュメント更新「Remove Substrate implementation detail from sovereign cloud note」で何が変わったか
今回の更新は、MicrosoftDocs/memdocsリポジトリのコミットとして公開されています。対象ファイルは intune/app-management/protection/configure-quiet-time.md で、Microsoft IntuneのQuiet Timeポリシーに関するドキュメントです。差分上は1ファイルのみが変更され、ms.date は2026年4月29日に更新されています。(GitHub)
変更の中心は、Sovereign Cloud環境に関する重要な注意書きです。以前の記述では、Quiet TimeポリシーがSovereign Cloudでサポートされない理由として「Substrate」というサービスへの依存が説明されていました。更新後は、その実装詳細が削除され、Sovereign Cloud環境ではQuiet Timeポリシーがサポートされない、というサポート可否の記述だけが残っています。(GitHub)
| 確認項目 | 更新前 | 更新後 | 実務上の解釈 |
|---|---|---|---|
| 対象ドキュメント | Quiet Time Policies for iOS/iPadOS and Android Apps | 同じ | 機能ページ自体は同じ |
| 更新日 | 2026年4月25日 | 2026年4月29日 | ドキュメント更新として扱う |
| Sovereign Cloudの扱い | 非サポートに加え、Substrateに依存する旨を説明 | 非サポートのみを記載 | 内部実装名を使った説明が削除された |
| サポート範囲 | GCC、GCC High、DoD、21Vianetで非サポート | 同じ | 対象クラウドのサポート可否は変わっていない |
| 管理者が取るべき対応 | 実装名を前提に説明しがち | 公式のサポート可否を根拠にする | 監査・設計資料の表現を見直す |
ここで重要なのは、「Substrate」という語が削除されたことを、アーキテクチャ変更や機能解放の証拠として扱わないことです。公式ドキュメントの現在の本文でも、Quiet TimeポリシーはSovereign Cloud環境ではサポートされないと明記されています。(Microsoft Learn)
Quiet Timeポリシーとは何か
Quiet Timeポリシーは、Microsoft Intuneでエンドユーザー向けに通知を抑制する時間帯をスケジュールする機能です。Microsoft Learnでは、iOS/iPadOSおよびAndroid上のMicrosoft OutlookメールとMicrosoft Teams通知を自動的にミュートし、勤務時間外の通知を制限する用途で説明されています。(Microsoft Learn)
ただし、Quiet Timeはセキュリティ制御そのものではありません。たとえば、条件付きアクセスのようにアプリ利用をブロックする機能ではなく、業務時間外の通知負荷を下げるための運用機能です。情報漏えい対策、デバイス準拠性、アプリ保護ポリシーの代替として扱うと、設計上の誤解につながります。
Quiet Timeポリシーには、主に次の種類があります。
| ポリシー種類 | 主な用途 | 注意点 |
|---|---|---|
| Date Range | 年末年始、祝日、全社休業日など、特定期間だけ通知を抑制する | 毎年繰り返す休日管理には向かない場合がある |
| Days of the week | 平日夜間、週末など、曜日と時間帯で通知を抑制する | 部門ごとに勤務時間が違う場合は割り当て設計が重要 |
| Non-working time | フロントラインワーカーの非勤務時間にTeams通知を抑制する | Working Time APIとの連携が前提。未連携で設定すると通知欠落のリスクがある |
Microsoft Learnでも、Non-working timeはWorking Time APIと統合されているテナントでのみ構成すべき設定として説明されており、統合なしに構成すると、管理対象アカウントの勤務状態を判断できずTeams通知が欠落する可能性があるとされています。(Microsoft Learn)
今回の更新で運用影響が出やすい組織
今回のドキュメント更新は、Intune管理画面の新機能追加や設定値変更というより、公式説明の表現変更として見るべきです。ただし、次の組織では実務上の確認が必要です。
| 対象組織・担当者 | 確認すべき点 | 推奨アクション |
|---|---|---|
| Sovereign Cloudを利用する政府・公共系組織 | Quiet Timeポリシーを導入予定に入れていないか | サポート対象外として設計書から除外する |
| GCC、GCC High、DoD、21Vianet向けに提案・運用しているSIer | 提案書や運用手順にQuiet Timeを含めていないか | 公式ドキュメントに合わせて記述を修正する |
| コンプライアンスチーム | 監査資料で「Substrateが利用できないため」と説明していないか | 「Microsoft公式ドキュメント上、Sovereign Cloudでは非サポート」と表現を統一する |
| グローバル企業のIT部門 | Commercial CloudとSovereign Cloudで同じIntune運用を前提にしていないか | クラウド環境ごとに機能利用可否表を分ける |
| セキュリティ管理者 | Quiet Timeをセキュリティ制御として扱っていないか | 通知制御とアクセス制御を分けて整理する |
特に注意したいのは、内部実装名が消えたことで「制約が解消された」と早合点するケースです。今回の更新後も、公式ドキュメント上のサポート対象外環境は変わっていません。
まず確認すべきポイント
自社テナントがどのクラウド環境か確認する
最初に確認すべきなのは、自社または顧客のIntuneテナントがCommercial Cloudなのか、Sovereign Cloudなのかです。
Quiet Timeポリシーの非サポート対象として公式ドキュメントに挙げられているのは、次の環境です。
| 環境 | Quiet Timeポリシーの扱い |
|---|---|
| US Government Community Cloud | 非サポート |
| GCC High | 非サポート |
| Department of Defense | 非サポート |
| Microsoft Azure operated by 21Vianet | 非サポート |
この分類に該当する場合、Quiet Timeポリシーを前提にした運用設計や移行計画は見直しが必要です。Commercial CloudでQuiet Timeを利用している組織が、将来的にSovereign Cloudへ移行する場合も、同じ設定をそのまま移せる前提で計画しないほうが安全です。
Quiet Timeポリシーを利用しているか確認する
Commercial CloudのIntune環境では、現在Quiet Timeポリシーを利用しているかを確認します。Microsoft Learnでは、Intune管理センターで Apps > Quiet Time > Policies からポリシーを作成する手順が示されています。(Microsoft Learn)
確認時は、単にポリシーの有無を見るだけでは不十分です。次の項目まで確認すると、運用影響を判断しやすくなります。
| 確認項目 | 見るべき内容 |
|---|---|
| ポリシー名 | 全社向け、部門向け、フロントライン向けなど用途が分かるか |
| ポリシー種類 | Date Range、Days of the week、Non-working timeのどれか |
| 対象グループ | 全社員、特定部門、シフト勤務者など割り当て範囲は適切か |
| 除外グループ | 緊急対応部門、管理職、オンコール担当などが必要に応じて除外されているか |
| エンドユーザー上書き | ユーザー側で変更を許可する設計か |
| Working Time API連携 | Non-working timeを使う場合に連携が成立しているか |
| 社内説明 | 「通知を止める機能」なのか「アクセスを制御する機能」なのかが明確か |
Quiet Timeポリシーを変更する場合、既存ポリシーの変更がユーザーに反映されるまで最大24時間程度かかる可能性がある点も考慮してください。Microsoft Learnでも、既存のQuiet Timeポリシーを変更した場合、ユーザーが変更を確認できるまで24時間表示されないことがあると説明されています。(Microsoft Learn)
Security Adminsが確認すべき点
セキュリティ管理者は、Quiet Timeを「通知制御」として正しく位置付けることが重要です。
Quiet Timeポリシーは、OutlookやTeamsの通知を抑制するための仕組みです。ユーザーがアプリを開いた場合の閲覧、アクセス、データ保護まで一括で制御するものではありません。そのため、次のような要件をQuiet Timeだけで満たそうとすると、設計ミスになります。
| 要件 | Quiet Timeで満たせるか | 適切な検討先 |
|---|---|---|
| 勤務時間外の通知を減らしたい | 対応可能 | Quiet Timeポリシー |
| 勤務時間外にTeams利用を制限したい | 単体では不十分 | Working Time、Teams、条件付きアクセスなどの設計確認 |
| 管理対象外デバイスからのアクセスを防ぎたい | 不可 | 条件付きアクセス、デバイス準拠性 |
| アプリ内データのコピーを制御したい | 不可 | Intuneアプリ保護ポリシー |
| 監査ログをもとに違反を検出したい | 不可 | Microsoft Purview、Entra IDログ、Teams監査など |
フロントラインワーカーの勤務時間外アクセス制御まで含める場合は、Microsoft 365側のWorking Time機能との関係も確認が必要です。Working Timeは、AndroidおよびiOSのTeamsでシフト勤務者が勤務中か勤務外かを判定し、勤務外にTeamsを開いた際にブロック画面または警告画面を表示できる機能として説明されています。(Microsoft Learn)
一方、Quiet TimeはそのWorking Timeと組み合わせて、勤務時間外のTeams通知を自動的にミュートする用途で推奨されています。アクセス制御と通知制御を混同しないことが、セキュリティ設計上のポイントです。(Microsoft Learn)
Compliance Teamsが確認すべき点
コンプライアンスチームが今回の更新で見るべきなのは、機能の設定値よりも説明責任の表現です。
以前の社内資料で、Sovereign CloudにおけるQuiet Time非対応の理由を「Substrateが利用できないため」と説明していた場合、今回の公式ドキュメント更新後は、その説明をそのまま使い続けるべきではありません。内部実装名は公式本文から削除されているため、監査資料やFAQでは次のように表現を改めると安全です。
| 古い表現 | 推奨する表現 |
|---|---|
| SubstrateがSovereign Cloudで使えないため、Quiet Timeは非対応 | Microsoft公式ドキュメント上、対象のSovereign Cloud環境ではQuiet Timeポリシーはサポートされていない |
| バックエンド依存により利用不可 | 現時点の公式サポート範囲外 |
| 将来的にSubstrateが対応すれば使える可能性がある | 将来の可否は公式ドキュメントとMicrosoftの案内で確認する |
この修正は小さく見えますが、監査対応では重要です。内部実装を根拠にした説明は、後から実装名や構成が変わった場合に陳腐化します。公式ドキュメントのサポート可否を根拠にした説明であれば、監査人やリスク管理部門にも説明しやすくなります。
Enterprise ITが確認すべき点
エンタープライズIT部門では、Quiet Timeポリシーを単独機能として見るのではなく、働き方、地域、クラウド環境、部門運用を含めて整理する必要があります。
特にグローバル企業では、Commercial Cloudを使う本社部門と、政府・公共系プロジェクト向けのSovereign Cloud環境が混在することがあります。この場合、Intuneの機能一覧を1つにまとめると誤解が生まれます。
おすすめは、次のような「クラウド環境別の利用可否表」を作ることです。
| 機能・運用項目 | Commercial Cloud | GCC/GCC High/DoD/21Vianet | 備考 |
|---|---|---|---|
| Quiet Time: Date Range | 利用可否をテナントで確認 | 非サポート | 公式ドキュメントのサポート範囲を確認 |
| Quiet Time: Days of the week | 利用可否をテナントで確認 | 非サポート | 部門ごとの勤務時間に注意 |
| Quiet Time: Non-working time | Working Time API連携が必要 | 非サポート | 未連携での設定は避ける |
| Teams勤務時間外アクセス制御 | Working Timeなど別機能を確認 | 環境別に確認 | Quiet Timeとは役割が異なる |
| 社内周知 | 必要 | 必要 | 通知抑制の範囲を明確化 |
この表を作ると、移行プロジェクトや統合管理の場で「Commercial Cloudでは使っていたが、Sovereign Cloudでは同じ設計にできない」という差分を早期に発見できます。
移行準備で見落としやすいポイント
Commercial CloudからSovereign Cloudへ移行する、または政府・公共系顧客向けにIntune設計を作る場合、Quiet Timeポリシーは早い段階で棚卸ししてください。
移行前にやるべき棚卸し
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現行ポリシーを一覧化する | Quiet Timeポリシー名、種類、割り当てグループを記録する | どの部門が依存しているか分かる状態にする |
| 利用目的を確認する | 通知削減、休業日対応、シフト勤務対応などに分類する | 代替策を検討しやすくする |
| Sovereign Cloudでの可否を確認する | 公式ドキュメントのサポート範囲と照合する | 非サポートなら移行対象から外す |
| 代替運用を決める | 社内ルール、Teams運用、Outlook運用、オンコール体制で補完する | 技術機能だけに依存しない |
| 利用者へ周知する | 移行後に通知挙動が変わる可能性を説明する | 問い合わせ増加を防ぐ |
| 監査資料を更新する | 非対応理由を公式サポート範囲ベースで記載する | 内部実装名への依存を避ける |
移行準備でありがちな失敗は、「Intuneだから同じ機能が使える」と考えてしまうことです。Microsoft Intuneは同じ名称でも、クラウド環境やリージョン、政府機関向け環境によって提供状況が異なる場合があります。Sovereign Cloudを扱う場合は、機能単位で公式ドキュメントを確認する運用を標準化しておくべきです。
今回の更新を受けた社内ドキュメント修正例
今回の更新で最も実務的な対応は、社内ドキュメントの表現修正です。特に、設計書、運用手順書、FAQ、監査回答テンプレートに次のような記述が残っていないか確認してください。
修正前の例
Quiet TimeポリシーはSubstrateに依存しており、Sovereign CloudではSubstrateが提供されないため利用できません。
修正後の例
Microsoft IntuneのQuiet Timeポリシーは、Microsoft公式ドキュメント上、US Government Community Cloud、GCC High、Department of Defense、Microsoft Azure operated by 21Vianetではサポートされていません。そのため、該当環境ではQuiet Timeポリシーを前提とした通知抑制設計は採用しません。
修正後の文では、内部実装名ではなく、公式のサポート可否を根拠にしています。これにより、ドキュメント更新や内部構成の変化があっても、説明が破綻しにくくなります。
よくある誤解と正しい判断
| 誤解 | 正しい判断 |
|---|---|
| Substrateという語が消えたので、Sovereign CloudでQuiet Timeが使えるようになった | 使えるようになったとは判断できない。非サポートの記述は残っている |
| 今回の更新はIntuneの新機能リリースである | 差分を見る限り、公式ドキュメントの表現更新として扱うべき |
| Quiet Timeを設定すれば勤務時間外アクセスを禁止できる | Quiet Timeは通知抑制が主目的。アクセス制御とは分けて設計する |
| Non-working timeは設定するだけで使える | Working Time API連携が前提。未連携での設定は通知欠落につながる可能性がある |
| 既存ポリシーを変更すればすぐ全ユーザーに反映される | 反映には最大24時間程度かかる可能性がある |
| Commercial Cloudで使える設定はSovereign Cloudでも同じ | クラウド環境ごとのサポート範囲を確認する必要がある |
今回の更新は、管理画面の操作を急いで変更するタイプの情報ではありません。しかし、運用資料や監査資料に古い説明が残っている場合、後から問い合わせや解釈違いの原因になります。
管理者向けの実務チェックリスト
今回の更新を受けて、Intune管理者、セキュリティ管理者、コンプライアンス担当者は次の順番で確認すると効率的です。
| 優先度 | チェック内容 | 完了の目安 |
|---|---|---|
| 高 | 自社または顧客環境がSovereign Cloudに該当するか確認する | クラウド環境別に判断できる |
| 高 | Quiet Timeポリシーを導入済み、または導入予定か確認する | 対象ポリシーと割り当てが分かる |
| 高 | 社内資料に「Substrate」を根拠にした説明がないか確認する | 該当箇所を公式サポート範囲ベースに修正する |
| 中 | Non-working timeを使っている場合、Working Time API連携を確認する | 連携有無と責任部門が明確になる |
| 中 | ポリシー変更時の反映タイミングを運用手順に入れる | 24時間程度の反映遅延を前提にできる |
| 中 | ヘルプデスク向けFAQを更新する | 「通知抑制」と「アクセス制御」の違いを説明できる |
| 低 | 利用者向け周知文を見直す | Quiet Timeの範囲を誤解なく伝えられる |
次に取るべきアクション
今回のMicrosoft Intune公式ドキュメント更新で最も重要なのは、Sovereign CloudにおけるQuiet Timeポリシーのサポート状況を誤解しないことです。Substrateという内部実装名が削除されても、GCC、GCC High、DoD、Microsoft Azure operated by 21Vianetで非サポートという実務上の判断は変わりません。
まずは、自社または顧客のクラウド環境を確認し、Quiet Timeポリシーの利用有無を棚卸ししてください。そのうえで、設計書、監査資料、FAQ、移行計画に古い実装名ベースの説明が残っていれば、公式ドキュメントのサポート範囲を根拠にした表現へ修正します。
Quiet Timeは、働き方を支える便利な通知制御機能です。ただし、セキュリティ制御やアクセス制御とは役割が違います。今回の更新をきっかけに、Intuneの機能を「何を制御する機能なのか」「どのクラウド環境で使えるのか」「監査でどう説明するのか」という3つの視点で整理しておくと、今後の運用変更やクラウド移行にも対応しやすくなります。
コメント