Microsoft Intuneの公式ドキュメント更新「Merge remote-tracking branch ‘upstream/release-intune-2604’ into 29219451_2604_1」は、コミット名だけを見ると内容が分かりにくい更新です。結論から言うと、確認すべき中心は「App inventory」「Microsoft Edge v139セキュリティベースライン」「Windowsドライバー更新ポリシー」「Android Enterpriseの資格情報プロバイダー」「macOS Platform SSO」「Multi Admin Approval」「レポート・スキーマ変更」です。
この更新は、単一機能のリリース名ではなく、Microsoft IntuneのService release 2604周辺のドキュメント差分をまとめたMicrosoftDocs系の更新として読む必要があります。該当コミットは55ファイルにわたる大型差分で、557件の追加と2742件の削除が含まれています。つまり、管理者は「何が新しくなったか」だけでなく、「既存ポリシー、監査、移行計画、運用手順に影響があるか」を確認することが重要です。(GitHub)
今回の更新は「コミット名」ではなく差分の中身を見る
「Merge remote-tracking branch ‘upstream/release-intune-2604’ into 29219451_2604_1」という名前は、GitHub上のマージコミット名です。Microsoft Intuneの管理画面に同名の機能が追加されたわけではありません。
実務で見るべきポイントは、次の3つです。
| 確認観点 | 見るべき内容 | 管理者が取るべき行動 |
|---|---|---|
| 仕様確認 | Microsoft Learn上の説明、前提条件、制限事項 | 既存ポリシーや社内標準と差分を比較する |
| 運用影響 | 既存デバイス、アプリ、承認フロー、レポートへの影響 | パイロットグループで検証する |
| 移行準備 | 旧機能から新機能への置き換え、スキーマ変更、手順書更新 | ダッシュボード、Runbook、監査項目を見直す |
また、Intuneの新機能や更新は、Microsoft Learnで公開されてもすぐにすべてのテナントで利用できるとは限りません。Microsoftは、月次更新が完了するまで最大3日かかる場合があり、機能によっては数週間かけて段階的に展開されることがあると説明しています。(Microsoft Learn)
まず確認すべき変更点
今回の公式ドキュメント更新で、security admins、compliance teams、enterprise IT readersが優先して確認すべき領域は次の通りです。
| 領域 | 確認すべき変更 | 主な影響範囲 | すぐに行うこと |
|---|---|---|---|
| App inventory | Windows向けの詳細なアプリ棚卸し機能 | 資産管理、脆弱性管理、監査 | パイロット用の収集ポリシーを作成する |
| Edge v139セキュリティベースライン | Microsoft Edge version 139向けベースライン | ブラウザセキュリティ、拡張機能、認証方式 | 既存ベースラインとの差分を比較する |
| Windowsドライバー更新ポリシー | CHIDターゲティングに関する注意 | OEM固有ドライバー、更新リング | 自動承認の対象を見直す |
| Android Enterprise資格情報プロバイダー | パスキー、自動入力、Credential Manager | Android 14以降、BYOD、COPE | AM API移行前に構成ポリシーを準備する |
| macOS Platform SSO | 一部設定変更時の再登録 | macOS、Microsoft Entra ID登録 | 変更ウィンドウとユーザー通知を用意する |
| Multi Admin Approval | Change Review Agentの提案表示 | PowerShellスクリプト承認、監査 | 承認者の判断基準を更新する |
| データスキーマ・診断 | 一部列の削除、診断エンドポイント追加 | BI、SIEM、プロキシ、ファイアウォール | クエリと許可リストを点検する |
| Protected apps | 保護対象アプリ一覧の更新 | MAM、アプリ保護ポリシー | 利用アプリが対象に含まれるか確認する |
ポイントは、すべてを一度に本番反映しないことです。Intuneはポリシー、端末、アプリ、ID、ネットワークが密接に連動します。特にセキュリティベースラインやドライバー更新は、少数の検証グループで動作を確認してから段階展開するのが安全です。
App inventoryはDiscovered appsからの移行準備として最重要
今回の更新で特に確認優先度が高いのは、Windows向けのApp inventoryです。Microsoft Learnでは、App inventoryはアプリの可視性を高める機能であり、従来のDiscovered appsの長期的な置き換えとして位置付けられています。ただし、現時点では両方が並行して存在します。(Microsoft Learn)
App inventoryは、単に「アプリ一覧を見られるようになる機能」ではありません。構成ポリシーで収集項目を指定し、デバイスごとのアプリ情報をより詳細に把握する仕組みです。ソフトウェア資産管理、未許可アプリの検出、脆弱なバージョンの把握、監査対応に直結します。
App inventoryで確認すべき実務ポイント
| 項目 | 確認内容 |
|---|---|
| 対象 | Microsoft Intuneに登録され、Microsoft Entraに参加しているWindows 10/11デバイス |
| 有効化方法 | デバイス構成ポリシーでApplicationPropertiesを選択する |
| 表示場所 | デバイス詳細のAll Apps内にあるApp Inventoryタブ |
| 更新頻度 | デバイスのチェックインなどにより1日に複数回更新される |
| 収集方式 | 初回はフルアップロード、その後は差分アップロード |
| 注意点 | ポリシー削除後も約3日間は収集が続く可能性がある |
App inventoryは自動で全デバイスに有効化される機能ではありません。Microsoft Learnでは、Devices > Manage devices > Configuration > Create > New policyから、Windows 10 and later向けのProperties catalogを使って構成する手順が示されています。(Microsoft Learn)
App inventoryで最初に収集すべき項目
初期導入では、いきなりすべての項目を収集するよりも、目的に合わせて最小限から始めるのが現実的です。
| 目的 | 優先して収集する項目 | 活用例 |
|---|---|---|
| ライセンス管理 | App Name、Version、Publisher | 未許可ソフトや重複導入の把握 |
| 脆弱性管理 | App Name、Version、Install Date | 古いバージョンの検出 |
| 監査対応 | Publisher、Install Scope、Install Location | ユーザー単位・端末単位の導入状況確認 |
| インシデント調査 | Install Date、Uninstall String、Platform Specific App ID | 不審アプリの導入時期や削除手順の確認 |
ただし、Install LocationやUninstall Stringのような項目は、社内パスやインストール構成を含む可能性があります。コンプライアンスチームは、収集目的、保存期間、アクセス権限を事前に整理しておくべきです。
Discovered appsとの違い
App inventoryとDiscovered appsは似ていますが、運用上の意味は異なります。
| 比較項目 | Discovered apps | App inventory |
|---|---|---|
| 有効化 | 基本的に管理者の詳細設定なしで利用 | 構成ポリシーが必要 |
| 情報の粒度 | 比較的限定的 | 収集プロパティを選べる |
| 更新頻度 | 7日単位、Win32はIntune Management Extension経由で24時間程度 | 1日に複数回更新される場合がある |
| 利用目的 | 大まかなアプリ検出 | 資産管理、監査、セキュリティ調査 |
| 移行の考え方 | 従来機能 | 長期的な置き換え候補 |
App inventoryでは、複数のポリシーが競合した場合に「収集する」設定が優先されます。意図せず広範囲の情報を収集しないように、同じデバイスに複数のインベントリ系ポリシーを割り当てる場合は注意が必要です。(Microsoft Learn)
Microsoft Edge v139セキュリティベースラインは既存プロファイルへ自動反映されない
Microsoft Intuneでは、Microsoft Edge version 139向けのセキュリティベースラインが追加されています。重要なのは、新しいベースラインが公開されても、既存のベースラインプロファイルが自動的に更新されるわけではない点です。Microsoftは、既存プロファイルを新しいベースラインに移行する前に、設定内容を確認するよう案内しています。(Microsoft Learn)
Edge v139のベースラインには、SmartScreen、拡張機能のブロック、基本認証、サイト分離、Application Bound Encryption、IEモード関連など、企業環境で影響が出やすい設定が含まれています。(Microsoft Learn)
Edge v139ベースライン移行時の確認手順
| 手順 | 作業内容 | 見落としやすい点 |
|---|---|---|
| 現状確認 | 既存のEdgeベースラインとカスタム構成プロファイルを棚卸しする | 同じ設定が複数プロファイルで重複している場合がある |
| 差分確認 | v139の既定値と現行設定を比較する | 既定値が強化され、業務アプリに影響することがある |
| 例外整理 | 拡張機能、社内Web、認証方式の例外を確認する | レガシーなBasic認証やネイティブメッセージングが止まる可能性 |
| パイロット展開 | IT部門、業務代表、セキュリティ部門に限定して適用する | ブラウザ起動時ではなく、特定業務で初めて問題が出ることがある |
| 本番展開 | リング展開で段階的に広げる | 問い合わせ窓口とロールバック手順を用意する |
特に注意したいのは、拡張機能の制御です。業務で使っているSaaS連携ツール、Web会議補助ツール、電子契約ツールなどがブラウザ拡張に依存している場合、ベースラインの強化によって突然使えなくなることがあります。
セキュリティを優先する場合でも、許可済み拡張機能リスト、ブロックリスト、例外申請フローをセットで整備してから展開するのが現実的です。
Windowsドライバー更新ポリシーではCHIDターゲティングを過信しない
Windowsドライバー更新ポリシーでは、Computer Hardware ID、いわゆるCHIDに関する注意が追加されています。Microsoft Learnでは、IntuneのWindowsドライバー更新ポリシーはOEMが定義したCHIDターゲティングを強制せず、管理対象デバイスがより新しい推奨ドライバーを受け取る可能性があると説明されています。(Microsoft Learn)
これは、標準的なオフィスPCだけを管理している環境では大きな問題にならない場合もあります。しかし、次のような環境では運用影響が出やすくなります。
- 特定OEMの認定イメージを使っている
- 工場、店舗、医療、研究用途などで専用周辺機器を使っている
- GPU、カメラ、ICカードリーダー、バーコードリーダーなどのドライバー互換性が重要
- ドライバー更新後の検証に時間がかかる
- Autopatchや自動承認を広範囲に使っている
ドライバー更新ポリシーの判断基準
| 環境 | 推奨される運用 |
|---|---|
| 一般的な事務用PC | 自動承認を使いつつ、少数の先行リングで確認 |
| OEM指定構成のPC | 手動承認を基本にし、OEM推奨バージョンと比較 |
| 専用周辺機器が多い端末 | 更新対象を限定し、業務部門の検証を必須にする |
| トラブル時の復旧が難しい端末 | ドライバー更新を本番前に長めに検証する |
| Autopatch管理端末 | リスク可視化レポートと更新リングを併用する |
ドライバー更新は、OS更新よりも影響が見えにくいことがあります。たとえば、更新直後は正常に見えても、Web会議、印刷、VPN、外部ディスプレイ、特定業務アプリの起動時に問題が出るケースがあります。自動承認を使う場合でも、少なくとも1つのパイロットリングを置き、問題発生時の停止・除外・ロールバック手順を決めておくべきです。
Android Enterpriseの資格情報プロバイダーはAM API移行前に確認する
Android Enterpriseでは、Credential Managerや資格情報プロバイダーに関する設定が重要になっています。Microsoftの更新では、Android 14以降の資格情報プロバイダー、パスキー、信頼済みソース、管理方式ごとの適用範囲が説明されています。(Microsoft Learn)
特に注意が必要なのは、BYOD work profileのAM API移行です。Microsoft Learnでは、AM API移行前にサードパーティの資格情報プロバイダー向けアプリ構成ポリシーを作成する必要があると説明しています。必要なポリシーがない場合、Android 14以降で自動入力やパスキーが期待どおり動作しない可能性があります。また、AM APIへの移行は元に戻せないとされています。(Microsoft Learn)
Android Enterpriseで確認すべきこと
| 確認項目 | 実務での見方 |
|---|---|
| 利用中の資格情報プロバイダー | Microsoft Authenticator、1Password、LastPass、Okta、Bitwardenなどを棚卸しする |
| 管理方式 | COBO、COSU、COPE、BYOD work profileのどれに該当するか確認する |
| Androidバージョン | Android 14以降の端末を優先して検証する |
| アプリ構成ポリシー | サードパーティ製プロバイダーを許可する設定を事前に作成する |
| パスキー利用 | サインイン、業務アプリ、IdP連携の動作を実機で確認する |
Microsoft Authenticatorは既定で許可される扱いですが、サードパーティのパスワードマネージャーやID管理製品を使っている場合は、事前検証が必須です。
また、Google Password Managerは一部の管理方式で利用できない制限があります。全社員に「Androidの標準機能だから使える」と案内してしまうと、BYODやCOPE端末で問い合わせが増える可能性があります。ヘルプデスク向けFAQには、利用可能な資格情報プロバイダーと対象端末を明記しておくとよいでしょう。
macOS Platform SSOは設定変更による再登録に注意する
macOSのPlatform SSOは、Microsoft Entra IDとの連携やパスワードレス運用を進めるうえで重要な機能です。今回の更新では、既存のPlatform SSOポリシーが割り当てられているデバイスで、Authentication MethodやUse Shared Device Keysなどの設定を変更した場合、Microsoft Entraへの再登録が発生する点が示されています。(Microsoft Learn)
再登録は、単なる設定反映とは異なります。ユーザー体験、サインイン、条件付きアクセス、デバイス準拠状態に影響する可能性があります。
Platform SSO変更前のチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 対象デバイス数 | 一括変更ではなく、部門単位・リング単位で展開する |
| 変更内容 | Authentication MethodやShared Device Keysに関係するか確認する |
| ユーザー影響 | 再認証、再登録、サインインプロンプトの発生可能性を通知する |
| 条件付きアクセス | 準拠状態やデバイス登録状態が一時的に変わる影響を確認する |
| ロールバック | 元のプロファイルと設定値を保存しておく |
macOSはWindowsに比べて、ユーザー自身が端末を長期間カスタマイズしているケースが多く、認証周りの変更に敏感です。Platform SSOの設定変更は、OS更新や証明書更新と同じように、事前告知と検証期間を設けて進めるべきです。
Multi Admin ApprovalとChange Review Agentは「承認の補助」として扱う
Multi Admin Approvalでは、Change Review Agentによる提案を承認ワークフロー内で確認できるようになっています。Microsoftの更新では、Windows PowerShellスクリプトの要求に対して、My requestsやAll requestsのAgent Response列で提案を確認できることが説明されています。(Microsoft Learn)
これは便利な機能ですが、承認判断を自動化するものとして扱うべきではありません。特にPowerShellスクリプトは、端末設定、セキュリティ設定、データ取得、アプリ展開に直接影響します。
承認者は、次の観点で確認すると判断しやすくなります。
| 確認観点 | 具体的に見るポイント |
|---|---|
| 実行対象 | 全社展開か、限定グループか |
| 権限 | ローカル管理者権限やシステム権限で動くか |
| 変更内容 | レジストリ、ファイル、サービス、セキュリティ設定を変更するか |
| 監査性 | 実行ログ、失敗時ログ、変更前後の状態が追えるか |
| 復旧性 | 元に戻すスクリプトや手順があるか |
Change Review Agentのコメントは、承認者の見落としを減らす補助情報として有用です。一方で、最終判断は社内の変更管理ルール、リスク分類、監査要件に基づいて行う必要があります。
Autopatchのリスク可視化は更新リングの見直しに使う
Windows Autopatchでは、更新リスクの可視化に関する情報も追加されています。Microsoftは、更新リングの状態をCurrent、Exposed、Criticalなどで分類し、リスクに寄与しているポリシーを確認できるレポートを案内しています。(Microsoft Learn)
この情報は、単なるレポート確認ではなく、更新リング設計の見直しに使うべきです。
たとえば、次のような状態が続いている場合は、ポリシー設計に問題がある可能性があります。
- 特定リングだけ更新遅延が常態化している
- 除外グループが増え続けている
- パイロットリングの意味がなく、本番リングと同じ構成になっている
- ドライバー更新、品質更新、機能更新の責任者が分かれていない
- 更新失敗の原因がレポートだけでは追跡できない
Autopatchを導入していても、すべてを自動化に任せるのではなく、リングごとの目的を明確にする必要があります。パイロットリングは「問題を早く見つけるためのリング」であり、「影響が少ない端末を置く場所」ではありません。業務アプリ、VPN、プリンター、周辺機器を代表する端末を含めることで、実際のリスクを早く検出できます。
レポート、スキーマ、ネットワーク関連の変更も見落とさない
今回の更新は、Intune管理画面で目立つ新機能だけではありません。レポートやスキーマ、診断関連の変更も含まれています。
MicrosoftDocsの差分では、Advanced Analytics系の参照スキーマからSubnetAddressV4、ConfiguredBy、Imsiが削除されています。これらの列を使ってPower BI、SIEM、独自レポートを組んでいる場合は、クエリ失敗や空データの原因になります。(GitHub)
また、デバイス診断の収集に関連して、スイス向けのBlobエンドポイントとしてlgmsapeswiss.blob.core.windows.netが追加されています。プロキシ、ファイアウォール、CASBで送信先を厳格に制御している環境では、診断ログ収集が失敗しないよう許可リストを点検してください。(GitHub)
レポート・ネットワークで確認すること
| 対象 | 確認内容 |
|---|---|
| Power BIレポート | 削除された列を参照していないか |
| SIEM連携 | 取り込みスキーマやパーサーが古くないか |
| 独自スクリプト | Intuneデータ取得時に存在しない列を指定していないか |
| ファイアウォール | 新しい診断エンドポイントがブロックされていないか |
| Runbook | 古いMicrosoft Learn URLやConfigMgr関連リンクが残っていないか |
特にグローバル企業では、リージョンごとのネットワーク制御が異なります。日本本社では問題がなくても、欧州拠点やスイス拠点で診断収集だけ失敗することがあります。Intuneの機能確認は、管理センターだけでなく、ネットワーク経路とログ出力まで含めて確認するのが実務的です。
Protected appsの更新はMAM対象アプリの棚卸しにつなげる
今回の更新では、保護対象アプリの一覧にも変更があります。Microsoftは、Harvey AIとContinia Expense Appが新たに保護対象アプリとして利用可能になったことを案内しています。(Microsoft Learn)
アプリ保護ポリシーを運用している組織では、単に「新しいアプリが増えた」と見るのではなく、次の観点で確認するとよいでしょう。
| 確認項目 | 理由 |
|---|---|
| 社内で該当アプリを利用しているか | 未管理のまま業務データを扱っている可能性がある |
| MAM対象に含めるべきか | 個人端末利用やBYODでデータ保護が必要になる |
| 条件付きアクセスと整合しているか | アプリ保護ポリシーだけでは制御が不十分な場合がある |
| DLPや監査要件に関係するか | AI、経費、法務系アプリは機密データを扱いやすい |
特にAI系アプリや経費精算アプリは、個人情報、契約情報、財務情報を扱う可能性があります。対象アプリの追加は、セキュリティ部門だけでなく、法務、経理、業務部門と連携して判断するのが安全です。
変更確認の進め方
今回のようなMicrosoftDocs系の更新は、差分が広いため、担当者ごとに確認範囲を分けると効率的です。
| フェーズ | 担当 | 作業内容 |
|---|---|---|
| 初日〜48時間 | Intune管理者 | コミット差分、What’s new、Microsoft Learnの更新箇所を確認する |
| 1週間以内 | セキュリティ管理者 | Edgeベースライン、MAM、MAA、Android資格情報プロバイダーを確認する |
| 1週間以内 | エンドポイント管理者 | App inventory、ドライバー更新、Platform SSOをパイロットで検証する |
| 2〜4週間 | コンプライアンスチーム | 収集データ、監査証跡、レポート項目を見直す |
| 本番展開前 | 変更管理担当 | 影響範囲、承認、ロールバック、ユーザー通知を確認する |
最初に実施すべき5つのアクション
- App inventoryのパイロットポリシーを作成し、収集項目を最小限から検証する
- Edge v139セキュリティベースラインを既存設定と比較する
- Windowsドライバー更新ポリシーで自動承認している対象を見直す
- Android 14以降の端末で資格情報プロバイダーとパスキーの動作を確認する
- レポート、SIEM、Power BIで削除済みスキーマを参照していないか確認する
よくある誤解と注意点
コミット名とIntune機能名を混同しない
今回の「Merge remote-tracking branch…」は、GitHub上のマージコミット名です。この名称の新機能がIntune管理センターに追加されたわけではありません。実際に見るべきなのは、差分に含まれるMicrosoft Learnページ、What’s new、対象機能の説明です。
App inventoryは自動でDiscovered appsを置き換えない
App inventoryは長期的にDiscovered appsの置き換え候補とされていますが、現時点では並行して扱う必要があります。構成ポリシーを作成しなければ、意図した情報は収集されません。
Edgeベースラインは「公開されたら安全」ではない
セキュリティベースラインは強力ですが、業務要件に合わない設定が含まれる場合があります。特に拡張機能、Basic認証、IEモード、社内Webアプリとの相性は必ず確認してください。
ドライバー更新はOEM指定どおりになるとは限らない
CHIDターゲティングがIntuneポリシーで強制されない点は、専用端末や認定構成の多い企業では重要です。自動承認だけに頼らず、検証リングと手動承認を組み合わせるべきです。
Androidの資格情報プロバイダーは移行後に慌てると遅い
BYOD work profileのAM API移行は元に戻せないため、移行後にパスキーや自動入力が使えないと業務影響が大きくなります。移行前に対象アプリ、対象端末、対象ユーザーを確認してください。
今回の更新で取るべき結論
Microsoft Intuneの公式ドキュメント更新「Merge remote-tracking branch ‘upstream/release-intune-2604’ into 29219451_2604_1」は、コミット名よりも実務影響を読むべき更新です。
最優先で確認するのは、WindowsのApp inventory、Edge v139セキュリティベースライン、ドライバー更新ポリシー、Android Enterpriseの資格情報プロバイダーです。加えて、Platform SSO、Multi Admin Approval、Autopatch、レポートスキーマ、診断エンドポイント、Protected appsの更新も、担当チームごとに確認する必要があります。
次に取るべき行動は明確です。まず小さな検証グループでApp inventoryとEdge v139ベースラインを確認し、ドライバー更新とAndroid資格情報プロバイダーの影響範囲を洗い出してください。そのうえで、レポート、Runbook、承認フロー、ユーザー通知を更新すれば、Service release 2604周辺の変更を安全に運用へ反映できます。
コメント