Microsoftは2026年6月15日の週の「What’s New」更新で、ほとんど見過ごされていた3つの重要な発表を投稿しました: Win32アプリ配信のHTTPS強制、Apple ADEの登録時グループ化のGA化、そしてAndroid個人所有ワークプロファイルのAMAPIへの移行の開始です。

どれも派手ではありませんが、ITチームにとってそれぞれ実質的な運用上の影響を持ちます。知っておくべきことを説明します。

管理対象Win32アプリでHTTPS配信が必須に — Connected Cacheの期限が到来

何が変更されたか

2026年6月16日以降、Intuneはすべての管理対象Win32アプリコンテンツについてHTTPS配信を強制します。Microsoft Connected Cache(MCC) for Enterprise and Educationを実行していてキャッシュノードでHTTPSを構成していない場合、クライアントはIntune Win32アプリの配信にCDNへフォールバックします。

コンテンツ配信自体は引き続き機能します — しかしキャッシュなしでは、MCCを展開する価値があった帯域幅の節約、プロビジョニング速度の向上、ローカライズされた配信を失います。Windows Autopilotを大規模に実行している組織では、プロビジョニング時間の遅延とインターネットegressコストの増加を意味します。

対象範囲

この変更でHTTPSが強制されるのはIntune Win32アプリのみです。他のコンテンツタイプ — Windowsの機能更新と品質更新、Microsoft 365 Apps、Office Click-to-Run、Defenderの定義更新 — は引き続きMCCを通じてHTTPで配信されます。

ただし、Microsoft TeamsコンテンツはすでにHTTPSを必須としており、HTTPのみのMCCノードではキャッシュされません。したがって実際には影響を受けるコンテンツファミリーは2つあります。

必要な要件

各MCCノードには有効なTLS証明書を構成する必要があります。主な要件:

  • ソフトウェアバージョン: キャッシュノードソフトウェアが2.0.0.2112以降であること
  • ポート443: ホスト上で空きであり利用可能であること
  • 証明書フォーマット: 暗号化されていない.crtファイルのみがサポートされます。パスワード保護された.pfxや.p12フォーマットはまだインポートできません
  • Subject/SAN: クライアントデバイスがノードに到達する方法(FQDNまたはIP)と正確に一致すること
  • TLSインスペクション: TLSインスペクションを実行するネットワークではMCCトラフィックを除外する必要があります。さもなければクライアントは証明書を拒否します

セットアッププロセス

  1. 提供されたスクリプトを使用してMCCホスト上でCSRを生成
  2. 内部CAまたは信頼できる認証局で署名
  3. importCertスクリプトを使用して**.crtをインポート**
  4. 検証 — まずMCCサーバー自身で、次にクライアントデバイスから

SCCM統合MCC(Configuration Manager配布ポイントにConnected Cacheを統合したもの)については、2026年2月の更新でHTTPSサポートが追加されました。プロセスにはIISでのTLS有効化、更新されたDoincInstall.exeのダウンロード、MCCチェックボックスをオフにしてから再度オンにする操作が必要です。

ITチームが今取るべき対応

  • インベントリ: すべてのMCCノードのソフトウェアバージョンを確認(≥ 2.0.0.2112であること)
  • 優先順位: MCCでHTTPSを構成していない場合、これを優先的に進めてください。HTTPSなしの1日ごとにWin32アプリとTeamsコンテンツのキャッシュを失います
  • テスト: 本番ノードに展開する前に非本番環境で検証
  • 文書化: MCCの運用手順とヘルプデスクドキュメントを更新
  • 監視: 構成後、Win32アプリコンテンツのキャッシュヒット率が回復したことを確認

すでにMCC用にHTTPSを構成済み(またはMCCをまったく使用していない)の場合、対応は不要です。

Apple ADEの登録時グループ化 — 一般提供開始

何が変更されたか

Appleの自動デバイス登録(ADE)でiOS/iPadOSとmacOS向けの登録時グループ化が**一般提供(GA)**されました。以前はWindows AutopilotとAndroid Enterpriseでのみ利用可能だったこの機能により、管理者は登録ポリシー内でデバイスのMicrosoft Entra IDセキュリティグループを直接タグ付けできます。

デバイスが登録されると、登録プロセス自体の中で — バックグラウンド同期が完了する数分や数時間後ではなく — 指定されたセキュリティグループのメンバーになります。これにより、そのグループをターゲットとするアプリ、構成ポリシー、コンプライアンス設定が、ユーザーがホーム画面に到達した後ではなく、Setup Assistant中に展開を開始できます。

なぜ重要か

ゼロタッチ展開ワークフローにおいて、「デバイスが登録された」状態と「デバイスが完全に構成された」状態の間のギャップは、最大の摩擦ポイントの一つでした。登録時グループ化がないと、動的または静的グループに割り当てられたポリシーは、デバイスがEntra IDへメンバーシップを同期した後にのみ適用されます — ユーザーを苛立たせ、生産性を遅らせる可能性のあるレイテンシウィンドウが生じます。

このGAにより、Appleデバイス展開はWindows AutopilotやAndroid Enterprise展開が長年享受してきた同じ高速プロビジョニングの恩恵を受けるようになります。

セットアップ要件

  • 静的なMicrosoft Entraセキュリティグループを作成
  • Intune Provisioning Clientサービスプリンシパルを所有者として追加(AppId: f1346770-5b25-470b-88bd-d5744ab7952c)
  • 新規Apple ADE登録ポリシーでグループを構成(既存プロファイルは影響なし)
  • 登録プロファイルごとに1つの静的グループのみ

ITチームが取るべき対応

  • 今すぐセキュリティグループを作成: 登録プロファイルに割り当てる静的グループを事前に作成
  • サービスプリンシパルを確認: Entra IDテナントにIntune Provisioning Clientが存在することを確認
  • 小規模でテスト: 登録時グループ化を有効にした新規ADE登録ポリシーを作成し、テストデバイスで検証
  • 2606リリースに備える: Apple ADE登録ポリシーは今後の2606サービスリリースで新インフラに移行します。登録時グループ化はこのより広範な近代化の一部です — 今慣れておけば後に役立ちます

Android個人所有ワークプロファイルがAMAPIに移行 — Web登録が開始

何が変更されたか

これは3つのうち最大の運用上の変化です。Microsoftは個人所有ワークプロファイル(BYOD Android)管理を従来のカスタムDPC / Google Play EMM API実装からGoogleの**Android Management API(AMAPI)**に移行しています。

2つのものが展開されています:

1. Webベースの登録 — ユーザーは個人用Androidデバイスを登録するためにCompany Portalアプリをインストールする必要がなくなります。ブラウザ(ChromeまたはEdge)から登録を開始できます:

  • 直接URL: aka.ms/enrollmyandroid
  • Conditional Accessが登録を要求する際、生産性アプリ(Teams、Outlook)からのリダイレクト
  • Company Portalアプリ経由(エントリポイントとして引き続き機能)

登録が完了すると、IntuneアプリとAndroid Device Policyアプリ(非表示)が自動的にインストールされます。

2. AMAPIベースのポリシー配信 — 個人所有ワークプロファイルデバイスのポリシー管理は、企業所有デバイス(COPE、COBO、COSU)がすでに使用しているものと同じモダンAPIを使用するようになります。これにより新機能の迅速なリリース、Android Enterprise管理オプション全体で一貫した動作、従来のカスタムDPCでは利用できなかった機能のサポートが実現します。

有効化方法

新規登録について — 現在テナントレベルでオプトイン(任意)です:

  • 移動先: デバイス > Androidタブ > デバイスオンボーディング > 登録 > 個人所有デバイスとワークプロファイル
  • チェック: Android個人所有ワークプロファイル管理に登録するすべてのユーザーにWeb登録を使用
  • ⚠️ この変更は元に戻せません

既存の登録済みデバイスについて — 「Move to Android Management API」デバイス構成プロファイルを作成:

  • デバイス > デバイスの管理 > 構成 > 作成 > 新しいポリシー
  • プラットフォーム: Android Enterprise
  • プロファイルタイプ: テンプレート > Move to Android Management API
  • 段階的に移行するためデバイスグループに割り当て

タイムライン:

  • 現在(2026年Q2後半): Web登録と移行ポリシーのオプトインが利用可能
  • 2026年後半: 残りのすべてのデバイスの自動移行

重要な注意点

テナントでパスキーのみを許可される認証方法として使用している場合、Web登録をまだ有効にしないでください。Web登録のパスキーサポートは将来の更新で提供されます。

ITチームが取るべき対応

  • まずテスト: 本番の前にテストテナントでWeb登録を有効化
  • 段階的移行: AMAPI構成ポリシーを使用して、対象を絞った波で既存の登録済みデバイスを移行
  • ドキュメントを更新: ユーザー登録エクスペリエンスが変更されます — 登録ガイドとヘルプデスクスクリプトを更新
  • ユーザーに連絡: BYOD Androidユーザーに登録プロセスがシンプルになる(アプリダウンロード不要)ことを通知
  • Conditional Accessを見直し: 登録を要求するCAポリシーがWebベースフローと互換性があることを確認

これはIntuneがBYOD Androidを管理する方法の基盤的な変更です。Googleの従来のカスタムDPC API廃止と合致し、次世代のAndroidプラットフォーム機能に向けたHCL管理を位置付けます。

まとめ

変更影響レベル必要な対応
Win32アプリコンテンツがMCCでHTTPSを必須化高(MCCを使用の場合)MCCノードでHTTPSを構成
Apple ADE登録時グループ化GA中(Apple環境)Entraグループを事前作成、ADEポリシーを更新
Android BYODがAMAPIに移行高(Android環境)Web登録を有効化、段階的移行を計画

いずれも破壊的変更ではありません — しかしMCCのHTTPS期限を無視し、登録時グループ化の採用を飛ばし、AMAPI移行を遅らせれば、数時間の計画で回避できたはずの運用上の摩擦が生じます。

いつものように、まず非本番でテストし、ドキュメントを更新し、ヘルプデスクに周知してください。これらの移行計画でサポートが必要な場合はご連絡ください — 私たちは複数の組織でこれらの移行を複数回経験しており、落とし穴がどこにあるか把握しています。

— Kevin