Microsoft Intuneの公式ドキュメント更新「29219451 – settings catalog info」でまず押さえるべき結論は、既存のSettings catalogポリシーを急いで作り直す必要はないものの、Appleデバイス管理、RBAC、既定値、ユーザー/デバイススコープ、競合レポートの運用手順は見直す価値があるという点です。今回の更新は破壊的変更の告知ではなく、Microsoft IntuneのSettings catalogを使う管理者が、仕様確認と移行準備をしやすくするための情報整理に近い内容です。特にsecurity admins、compliance teams、enterprise IT readersは、社内Runbookや監査証跡の説明が現在の公式ドキュメントとずれていないか確認しておきましょう。
Microsoft Intuneの公式ドキュメント更新「29219451 – settings catalog info」で何が変わったか
2026年4月30日の更新では、MicrosoftDocsのmemdocsリポジトリにあるSettings catalog関連ドキュメントが更新されました。GitHub上のコミットでは、対象ファイルがintune/device-configuration/settings-catalog/index.mdで、1ファイルに対して46行追加・38行削除の差分が入っています。コミットメッセージは「29219451 – settings catalog info」です。(GitHub)
公開中のMicrosoft Learn記事も「Last updated on 2026-04-30」となっており、Settings catalogを使ったポリシー作成、検索とフィルター、Copilot、競合確認、ユーザー/デバイススコープなどの説明が整理されています。(Microsoft Learn)
今回の更新で実務上注目したいのは、単なる文章修正ではなく、次のような運用に関わる説明が明確になった点です。
| 確認ポイント | 何が整理されたか | 管理者が見るべきこと |
|---|---|---|
| Appleデバイス管理 | Appleの項目としてiOS/iPadOS、macOS、tvOS、visionOSが整理された | Apple端末の管理対象範囲を社内資料に反映する |
| DDM | Apple Declarative Device ManagementがSettings catalogに組み込まれている旨が明記された | iOS/iPadOSやmacOSの更新管理・制限設定の設計を再確認する |
| ポリシー作成手順 | プラットフォーム選択にtvOS、visionOSが含まれる | テナント上で表示される選択肢と実運用の対応範囲を確認する |
| RBAC | 最低限必要なロールとしてPolicy and Profile Managerが示されている | Global AdministratorやIntune Administratorを日常運用に使っていないか見直す |
| 既定値と未構成 | 追加した設定の既定値、マイナス記号によるNot configuredの扱いが整理された | 「追加しただけで意図せず構成済み」になるリスクを確認する |
| 競合とレポート | per-setting statusやAssignment failuresでの確認が案内されている | 競合、エラー、適用失敗をポリシー単位だけで見ないようにする |
| スコープ | User/Deviceタグと割り当て時の挙動が説明されている | ユーザー割り当て・デバイス割り当ての影響範囲を再確認する |
今回の更新は「機能追加」よりも「運用確認」の合図として見る
Microsoft IntuneのSettings catalogは、Windows、Android、Appleデバイスなどに対して細かい構成プロファイルを作成するための仕組みです。Microsoft Learnでは、Settings catalogを「構成可能な設定を一か所にまとめる機能」と説明しており、BitLockerのような設定もSettings catalogから扱える例として示しています。(Microsoft Learn)
そのため、今回のドキュメント更新を見たときに重要なのは、「新しい設定が追加されたからすぐ本番へ展開する」ことではありません。まず確認すべきなのは、現在の運用手順、権限設計、監査用ドキュメント、移行計画が、公式ドキュメントの表現とずれていないかです。
特に次のような環境では、更新内容をレビューする優先度が高くなります。
- Settings catalogでWindowsのセキュリティ設定、BitLocker、Microsoft Edge、Office、OneDrive関連設定を管理している
- GPOからIntune管理へ移行中、または移行を計画している
- macOSやiOS/iPadOSだけでなく、tvOSやvisionOSの管理も検討している
- コンプライアンス監査で「どのポリシーが、どの端末に、どの値で適用されたか」を説明する必要がある
- Intuneの管理権限を複数チームに委任している
Appleデバイス管理ではtvOSとvisionOSの扱いを確認する
今回の更新で目立つのは、Apple関連の説明が整理され、iOS/iPadOS、macOS、tvOS、visionOSがAppleデバイス向けSettings catalogの文脈で明示されている点です。Microsoft Learnでは、AppleのProfile-Specific Payload Keysから直接生成される設定が含まれ、Apple Declarative Device Management、いわゆるDDMもSettings catalogに組み込まれていると説明されています。(Microsoft Learn)
ただし、ここで注意したいのは、公式ドキュメントにプラットフォーム名が出たからといって、自社テナント、自社ライセンス、登録方式、端末モデル、OSバージョン、既存のApple Business Manager連携がすべて即座に本番利用可能とは限らない点です。
実務では、次の順序で確認すると安全です。
| 確認順 | 確認内容 | 見落とすと起きやすい問題 |
|---|---|---|
| 端末棚卸し | 管理対象にtvOS、visionOS端末があるか | 存在しない端末向けに設計だけ進む |
| 登録方式 | 自動デバイス登録、ユーザー登録、手動登録のどれか | DDMやポリシー適用の前提を誤る |
| ポリシー表示 | Intune管理センターで対象プラットフォームが選べるか | ドキュメント上の説明とテナントの実表示がずれる |
| パイロット | 少数端末で設定、同期、レポートを確認する | 本番展開後に未適用・競合・エラーが見つかる |
| 監査資料 | Apple管理の対象範囲を更新する | 監査時に「管理している端末範囲」の説明が古くなる |
tvOSとvisionOSについては、Apple ConfiguratorやApple Profile Managerで作成したファイルをインポートできる説明も追加されています。一方で、変数やプレースホルダーはサポートされず、プロファイル内に残っている場合は適用されないと説明されています。(Microsoft Learn)
つまり、%SERIAL%のようなプレースホルダーを前提にした古い構成プロファイルをそのまま移行すると、期待どおりに反映されない可能性があります。移行前に、プロファイル内の変数、証明書、識別子、対象OS、設定値を必ず確認してください。
RBACは「作業できる人」ではなく「作業してよい人」で設計する
Settings catalogのポリシー作成手順では、Intune管理センターにサインインするアカウントに少なくともPolicy and Profile Managerの組み込みロールが必要とされています。(Microsoft Learn)
ここで重要なのは、「権限が足りないからGlobal Administratorを付ける」という運用を避けることです。MicrosoftのRBACドキュメントでは、Intune RBACにより管理者へ細かい権限を付与でき、最小権限の原則に従うことで、管理者が必要なユーザーやデバイスだけを管理できると説明されています。(Microsoft Learn)
また、Microsoftは日常的なIntune管理でGlobal AdministratorやIntune Administratorを使うことを推奨しておらず、組み込みIntuneロールやカスタムロールの利用を案内しています。(Microsoft Learn)
実務では、次のように分けると権限の過不足を抑えやすくなります。
| 役割 | 推奨される考え方 |
|---|---|
| セキュリティ管理者 | セキュリティベースライン、コンプライアンスポリシー、構成プロファイルの変更権限を限定的に付与する |
| ヘルプデスク | 読み取り、デバイス状態確認、必要なリモート操作に限定する |
| コンプライアンス担当 | レポート閲覧、監査証跡確認を中心にする |
| グローバル管理者 | 例外的な作業時のみ使用し、日常的なSettings catalog変更には使わない |
| 外部委託・地域IT | Scope tagsとRBAC割り当てで対象デバイスを絞る |
設定を変更できる人数が多いほど、競合、意図しない上書き、監査時の説明不足が起きやすくなります。Settings catalogの更新レビューとあわせて、誰がどのプロファイルを作成・編集・割り当てできるのかを確認しておきましょう。
既定値とNot configuredの扱いは展開前に必ず確認する
Settings catalogでは、設定を追加するとBlockやAllowのような既定値が表示されることがあります。Microsoft Learnでは、これらの既定値はOS側の既定値と同じであり、設定を構成したくない場合はマイナス記号を選ぶと説明されています。(Microsoft Learn)
ここは運用ミスが起きやすいポイントです。
たとえば、設定ピッカーで「Select all these settings」を使って大量の設定を追加した場合、管理者が明示的に意図していない項目までプロファイル上に並びます。値がOS既定と同じでも、「ポリシーに含める」こと自体が管理対象として扱われるため、後続の確認や監査で混乱しやすくなります。
マイナス記号を選んだ場合の扱いも重要です。Microsoft Learnでは、マイナスはNot configuredと同じで、Intuneはその設定を変更・更新せず、次回ポリシーを開いたときにその設定は表示されず、次回デバイスチェックイン時にはデバイス上でロックされなくなると説明されています。(Microsoft Learn)
展開前のレビューでは、次の3点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 設定を追加する理由 | 「監査上必要」「セキュリティ要件に対応」「移行元GPOと一致」など理由が明確か |
| 既定値の意味 | OS既定値なのか、管理者が意図して設定した値なのかを説明できるか |
| 未構成に戻す影響 | 端末ユーザーや別ポリシーが値を変更できる状態になっても問題ないか |
特にセキュリティ設定では、「Not configured」は「安全な値に設定する」と同じではありません。未構成に戻す前に、別のポリシー、セキュリティベースライン、GPO、ローカル設定、ユーザー操作の影響を確認しましょう。
複数値の設定は1行ずつ入力する
Settings catalogには、複数の値を入力できる設定があります。Microsoft Learnでは、たとえばBluetooth > Services Allowed Listのような設定で、複数値を入力する場合は各値を別々の行に追加することが案内されています。単一フィールドにまとめて入力することもできますが、文字数制限に遭遇する可能性があります。(Microsoft Learn)
これは地味ですが、運用トラブルにつながりやすい点です。
たとえば、許可リストやブロックリストをCSV風に1行へ詰め込むと、意図した区切りとして認識されない、文字数制限に引っかかる、後から差分確認しづらいといった問題が起きます。
複数値を扱う場合は、次のルールを社内手順に入れておくとよいでしょう。
- 1値1行で入力する
- 追加・削除した値が分かるように変更履歴を残す
- 本番展開前にテスト端末で反映結果を確認する
- エクスポートしたJSONでも値の並びと区切りを確認する
- 許可リスト系の設定は、削除時の業務影響も確認する
ユーザースコープとデバイススコープは割り当て先だけで判断しない
Settings catalogで特に混乱しやすいのが、ユーザースコープとデバイススコープです。Microsoft Learnでは、設定名に(User)または(Device)タグが含まれる場合があり、そのタグはポリシーがユーザースコープまたはデバイススコープにのみ影響することを示すと説明されています。(Microsoft Learn)
WindowsのPolicy CSPでも、ポリシーにはユーザースコープとデバイススコープがあり、ユーザースコープは./User/Vendor/MSFT/Policy/...、デバイススコープは./Device/Vendor/MSFT/Policy/...のようなパスで扱われると説明されています。(Microsoft Learn)
実務で重要なのは、「ユーザーグループに割り当てたからユーザーだけに効く」「デバイスグループに割り当てたからデバイスだけに効く」と単純に考えないことです。
Microsoft Learnでは、次のような挙動が説明されています。デバイススコープのポリシーをデバイスへ割り当てると、そのデバイス上のすべてのユーザーに設定が適用されます。デバイススコープのポリシーをユーザーへ割り当てた場合も、そのユーザーがサインインしてIntune同期が行われると、デバイススコープ設定はそのデバイス上のすべてのユーザーに適用されます。ユーザースコープとデバイススコープの両方に同じ設定がある場合、ユーザースコープがデバイススコープより優先されるとも説明されています。(Microsoft Learn)
| 設定の種類 | 割り当て先 | 実務上の注意点 |
|---|---|---|
| Device設定 | デバイスグループ | 共有端末では全ユーザーに影響する |
| Device設定 | ユーザーグループ | サインイン後、その端末の全ユーザーに影響する可能性がある |
| User設定 | ユーザーグループ | 対象ユーザーだけに効くため、個別制御に向く |
| User設定 | デバイスグループ | 端末上の全ユーザーに適用されるような挙動になる場合がある |
| User/Device両方にある設定 | 両方に割り当て | User側が優先される可能性を前提に設計する |
共有PC、教育機関、コールセンター端末、キオスク端末、開発用端末では、このスコープ設計が特に重要です。割り当て先だけでなく、設定そのもののスコープタグを見てから展開してください。
競合確認はポリシー単位ではなく設定単位で見る
Settings catalogの運用では、同じ設定を異なる値で更新すると競合が発生します。Microsoft Learnでは、Intune管理センターで既存ポリシーの状態を確認でき、データはほぼリアルタイムに更新されると説明されています。また、per-setting statusにより、各設定ごとに成功、競合、エラーの台数を確認できます。(Microsoft Learn)
これはコンプライアンス運用で非常に重要です。
ポリシー全体が「適用済み」に見えても、一部の設定だけが競合している場合があります。逆に、端末単位のエラーを見ただけでは、どの設定が失敗しているのか判断しにくいこともあります。
運用では、次の順で確認すると原因を切り分けやすくなります。
| 確認順 | 見る場所 | 目的 |
|---|---|---|
| ポリシー状態 | Devices > Manage devices > Configuration | 対象ポリシー全体の状態を把握する |
| View report | ポリシー詳細レポート | 端末名、ユーザー、適用状態を確認する |
| Per-setting status | 設定ごとの状態 | どの設定が成功・競合・エラーか確認する |
| Assignment failures | Devices > Monitor | 展開失敗や競合を横断的に確認する |
| 対象端末詳細 | 端末ごとのエラー | エラーコードや端末固有の条件を確認する |
監査対応では、「ポリシーを作成した」だけでは不十分です。どの端末に、どの設定が、どの状態で適用されたかまで説明できるように、レポート出力やCSVエクスポートの手順もRunbookに含めておきましょう。
GPOやテンプレートからSettings catalogへ移行する際の判断基準
Microsoft Learnでは、オンプレミスのGPOのように細かく設定したい場合、Settings catalogはクラウドベースのポリシーへ移行する自然な選択肢だと説明されています。(Microsoft Learn)
ただし、すべての設定を一律にSettings catalogへ移すのが正解とは限りません。Microsoft Learnでは、テンプレートはキオスク、VPN、Wi-Fiなどの論理的な設定グループを含み、Settings catalogは利用可能な設定を一覧し、特定の設定を探す場合に使うものとして整理されています。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Settings catalog | BitLocker、Edge、Office、CSP、ADMXなどを細かく制御したい | 設定数が多く、命名・説明・監査設計が重要 |
| Templates | VPN、Wi-Fi、キオスクなど用途別にまとまった構成を作りたい | 詳細な個別設定はSettings catalogのほうが探しやすい場合がある |
| 既存GPO継続 | まだクラウド管理へ移行できない端末が多い | ハイブリッド期間中は競合と重複管理に注意 |
| カスタムプロファイル | Settings catalogにない設定を扱う必要がある | 将来Settings catalogに追加された場合の重複確認が必要 |
移行時は、既存GPOやplist、テンプレートの設定をそのままコピーするのではなく、「今後も管理する必要がある設定」と「過去の事情で残っている設定」を分けて棚卸ししましょう。
Settings catalogポリシーの移行準備でやるべき手順
Settings catalogポリシーはJSONとしてエクスポートし、別ポリシーとしてインポートできます。Microsoft Learnでは、既存ポリシーに似た新しいポリシーを作成したい場合に、このエクスポート・インポート機能が有用だと説明されています。(Microsoft Learn)
移行や見直しでは、次の手順で進めると失敗しにくくなります。
| 手順 | 作業内容 | ポイント |
|---|---|---|
| 現状把握 | 既存のSettings catalogポリシーを一覧化する | 名前、対象、割り当て、Scope tags、更新日を記録する |
| 影響分類 | セキュリティ、コンプライアンス、利便性、移行用に分類する | 重要度の高いものからレビューする |
| エクスポート | 既存ポリシーをJSONで保管する | 変更前の証跡として残す |
| 重複確認 | GPO、セキュリティベースライン、テンプレートと重複しないか見る | 競合の原因を減らす |
| パイロット | 少数のデバイス・ユーザーへ段階展開する | 共有端末と通常端末を分けて検証する |
| レポート確認 | per-setting statusとAssignment failuresを見る | ポリシー単位だけで成功判断しない |
| 本番反映 | 対象グループを広げる | 変更日時、承認者、ロールを記録する |
| Runbook更新 | 操作手順と判断基準を文書化する | 監査と引き継ぎに使える形にする |
ポリシーを複製する場合、Microsoft LearnではDuplicate機能により既存プロファイルのコピーを作成でき、コピーには同じ設定構成とScope tagsが含まれる一方、割り当ては付かないと説明されています。(Microsoft Learn)
これは安全な検証に役立ちます。既存ポリシーを直接編集するのではなく、複製してテストグループにだけ割り当て、結果を確認してから本番へ反映すると、誤展開のリスクを下げられます。
セキュリティ管理者とコンプライアンスチーム向けの実務チェックリスト
今回のMicrosoft Intune公式ドキュメント更新を受けて、まずは次のチェックリストを使うとよいでしょう。
セキュリティ管理者が確認すること
- 重要なSettings catalogポリシーに不要な設定が含まれていないか
Block、Allowなどの値が意図したセキュリティ要件と一致しているか- Not configuredに戻した設定が、別ポリシーやユーザー操作で変更可能になっても問題ないか
- Microsoft Edge、Office、OneDrive、BitLocker関連設定が重複していないか
- User/Deviceスコープの優先関係を理解したうえで割り当てているか
- 競合やエラーがper-setting statusで確認されているか
コンプライアンスチームが確認すること
- 監査対象の設定がどのポリシーに含まれているか説明できるか
- レポートやCSV出力の手順が文書化されているか
- 変更承認、変更日時、変更者、対象グループが記録されているか
- Global AdministratorやIntune Administratorの常用がないか
- Appleデバイス管理の対象範囲が最新の公式説明と一致しているか
- tvOS、visionOSを管理対象に含める場合の責任範囲が決まっているか
エンタープライズITが確認すること
- Settings catalog、Templates、GPO、カスタムプロファイルの使い分けが明文化されているか
- GPO移行時に「古い設定をそのまま移す」運用になっていないか
- Apple ConfiguratorやApple Profile Manager由来のプロファイルに変数が残っていないか
- 複数値設定を1行ずつ入力するルールがあるか
- テストグループ、段階展開、ロールバック手順が決まっているか
よくある失敗と回避策
ドキュメント更新を「強制移行」と誤解する
今回の更新は、公式ドキュメント上の説明整理が中心です。既存ポリシーを即日削除したり、全設定を作り直したりする必要は通常ありません。
やるべきことは、既存ポリシーの棚卸し、Appleプラットフォーム対応の確認、RBACとレポート手順の見直しです。
既定値を「未構成」と勘違いする
Settings catalogに追加された設定は、画面上に既定値が表示されることがあります。未構成にしたい場合は、設定をポリシーから外す操作が必要です。
レビュー時は、「値がOS既定と同じか」ではなく、「その設定をIntuneで管理する必要があるか」を基準に判断してください。
ユーザーグループ割り当てなら安全だと思い込む
Deviceスコープの設定をユーザーに割り当てると、そのユーザーがサインインした端末上の全ユーザーに影響する可能性があります。共有端末やVDI風の運用では特に注意が必要です。
割り当て先だけではなく、設定名にある(User)、(Device)タグを確認しましょう。
Appleのカスタムプロファイルをそのまま移行する
tvOSやvisionOS向けにApple ConfiguratorやApple Profile Managerで作成したファイルを使う場合、変数やプレースホルダーが残っていると期待通りに適用されません。
本番展開前に、プロファイルの中身を確認し、少数端末で同期・適用・レポートを確認してください。
競合をポリシー一覧だけで判断する
ポリシー一覧の状態だけでは、設定単位の競合やエラーを見落とすことがあります。per-setting status、View report、Assignment failuresを組み合わせて確認する運用にしましょう。
まず取るべき次のアクション
Microsoft Intuneの公式ドキュメント更新「29219451 – settings catalog info」は、Settings catalogを使う企業にとって、運用手順を点検するよいタイミングです。最初にやるべきことは、新しいポリシーを作ることではありません。
まず、既存のSettings catalogポリシーを一覧化し、セキュリティやコンプライアンスに関わるものから順に、設定値、割り当て、スコープ、競合、RBAC、レポート手順を確認してください。Appleデバイス管理を進めている組織では、tvOSとvisionOSを含めた対象範囲、DDM、プロファイルインポート時の制約も見直しましょう。
最終的には、次の3つを完了できれば十分です。
- 重要ポリシーの設定値と競合状態を確認する
- RBACとScope tagsを最小権限の考え方で見直す
- 社内Runbookに、既定値、Not configured、User/Deviceスコープ、per-setting statusの確認手順を追記する
この更新は小さく見えますが、Settings catalogを安全に運用するための確認項目が詰まっています。ドキュメント更新をきっかけに、Intune管理を「作成できる状態」から「説明できる状態」へ引き上げておくことが、セキュリティと監査の両面で重要です。
コメント