Microsoft Intuneの公式ドキュメント更新「Update diagnostics upload endpoints and documentation」でまず確認すべきなのは、診断アップロード用エンドポイントにスイス向けFQDNが追加された点です。今回の更新は、Intune管理画面の大きな仕様変更というより、ファイアウォール、プロキシ、SSE、DNSフィルタリングなどで出口通信を厳格に制御している企業が見落としやすいネットワーク要件の更新です。
特に、Windows Autopilotの失敗時ログ収集、Intuneの「診断の収集」、ヘルプデスクによるリモートトラブルシュートを運用している組織では、lgmsapeswiss.blob.core.windows.net が許可リストに反映されているかを確認してください。MicrosoftDocs/memdocsのコミットでは、2026年4月29日に「Added swiss endpoint to the diagnostics upload endpoints and added a section on diagnostics collection」と説明されています。(GitHub)
Microsoft Intuneの公式ドキュメント更新で何が変わったか
今回の更新対象は、Microsoft Intuneのネットワークエンドポイントをまとめる intune/fundamentals/endpoints.md です。GitHub上の差分では、1ファイルに対して追加・修正が行われ、主な変更は診断アップロード先の追加と、診断収集に関する参照セクションの整理です。(GitHub)
変更点を運用目線で整理すると、次のようになります。
| 確認項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| Windows Autopilot – Diagnostics upload | lgmsapeswiss.blob.core.windows.net が追加 | 診断ログのアップロード先としてスイス向けFQDNを許可リストに追加する必要がある |
| 統合エンドポイント一覧 | 同じFQDNが一覧にも追加 | ファイアウォール、プロキシ、CMDB、運用手順書の更新対象になる |
| Diagnostics collectionセクション | 診断収集に必要なエンドポイントへの参照が追加 | ヘルプデスクや端末運用チームが確認すべきドキュメント導線が明確になった |
| Endpoint analytics関連の参照 | 診断収集ページへの参照が整理 | Endpoint analyticsやトラブルシュート時の確認先を誤りにくくなる |
Microsoft Learnの日本語ページでも、Windows Autopilotの「診断のアップロード」に lgmsapeswiss.blob.core.windows.net が含まれており、通信ポートはTCP 443とされています。(Microsoft Learn)
追加されたエンドポイントは何か
今回追加されたエンドポイントは、次のFQDNです。
lgmsapeswiss.blob.core.windows.netこれは既存の診断アップロード先を置き換えるものではなく、従来のヨーロッパ、アメリカ、東アジア、オーストラリア、インド向けのFQDNにスイス向けが追加された形です。Microsoft Learnの「デバイス アクション: 診断を収集する」でも、診断を正常にアップロードするには、利用リージョンのURLがネットワークでブロックされていないことを確認するよう説明されています。(Microsoft Learn)
| リージョン | 診断アップロード先FQDN |
|---|---|
| ヨーロッパ | lgmsapeweu.blob.core.windows.net |
| アメリカ | lgmsapewus2.blob.core.windows.net |
| 東アジア | lgmsapesea.blob.core.windows.net |
| オーストラリア | lgmsapeaus.blob.core.windows.net |
| インド | lgmsapeind.blob.core.windows.net |
| スイス | lgmsapeswiss.blob.core.windows.net |
日本企業でも「自社テナントは日本だから関係ない」とすぐに判断するのは避けた方が安全です。実際に使うリージョンやテナント所在地、ユーザー所在地、セキュリティ境界、グローバル拠点の有無によって確認優先度は変わります。少なくとも、Microsoft Intuneの公式統合エンドポイント一覧を基準に許可リストを管理している企業では、今回のFQDNを棚卸し対象に含めるべきです。
なぜ診断アップロードエンドポイントの更新が重要なのか
Microsoft Intuneの診断収集は、ユーザーの端末に直接触れずにトラブルシューティング用データを集めるための機能です。Microsoft Learnでは、デバイスのコンプライアンス、アプリのパフォーマンス、登録エラー、Windows Autopilotのプロビジョニング失敗などの調査に役立つ機能として説明されています。(Microsoft Learn)
この機能は、ネットワーク要件を満たしていないと十分に機能しません。端末がオンラインで、診断中にサービスと通信できる必要があるため、診断アップロード先FQDNがプロキシやファイアウォールで拒否されていると、ログが収集できない、アップロードが完了しない、調査に必要な情報が不足する、といった問題につながります。(Microsoft Learn)
特に影響が出やすいのは、次のような環境です。
| 環境 | 起きやすい問題 | 確認すべきこと |
|---|---|---|
| 出口通信をFQDN単位で制御している企業 | 新しいFQDNが未許可で診断アップロードに失敗する | ファイアウォール、プロキシ、SSEの許可リスト |
| Windows Autopilotを大規模展開している企業 | プロビジョニング失敗時のログ回収が遅れる | Autopilot用ネットワークセグメントからのTCP 443到達性 |
| グローバル拠点を持つ企業 | 拠点ごとに通信制御ルールが異なり、一部拠点だけ失敗する | 拠点別のプロキシ設定、VPN、DNS制御 |
| ヘルプデスクがIntune診断を使っている企業 | 端末調査の一次対応で必要なログが取れない | ヘルプデスク手順書とエスカレーション条件 |
| コンプライアンス部門が診断データを管理している企業 | 診断データの取り扱い説明が不足する | 収集データ、保存期間、アクセス権限の説明 |
セキュリティ管理者が確認すべきポイント
ファイアウォールとプロキシの許可リストを更新する
最初に行うべき作業は、既存のIntune関連通信許可リストに lgmsapeswiss.blob.core.windows.net が含まれているか確認することです。単に「Intuneを許可している」と考えるのではなく、実際の制御ポイントごとに確認してください。
確認対象は、少なくとも次の範囲です。
- 境界ファイアウォール
- プロキシサーバー
- SWGやSSEなどのクラウド型セキュリティゲートウェイ
- DNSフィルタリング
- VPN接続時の出口通信ルール
- Autopilotキッティング用ネットワーク
- 拠点別のローカルブレイクアウト設定
Microsoft LearnのIntuneネットワークエンドポイントページでは、過去に利用できたPowerShellスクリプトやOffice 365 Endpoint service由来の一覧では正確なデータが返らなくなっており、公式ページの統合リストを使用するよう注意喚起されています。古い自動取得スクリプトに依存している環境では、今回のような差分を取りこぼす可能性があります。(Microsoft Learn)
既存ルールがワイルドカード依存か個別FQDN依存かを確認する
企業によっては、*.blob.core.windows.net のような広い許可を避け、Microsoft Intuneに必要なFQDNだけを個別に許可している場合があります。この方式はセキュリティ上の説明がしやすい一方で、今回のようなFQDN追加に弱い構成です。
判断基準はシンプルです。
| 許可方式 | メリット | 注意点 |
|---|---|---|
| 個別FQDN許可 | 最小権限に近く、監査で説明しやすい | 公式更新の反映漏れが障害につながりやすい |
| ワイルドカード許可 | 運用負荷が低く、追加FQDNに追従しやすい | 許可範囲が広くなり、セキュリティ部門の承認が必要になりやすい |
| Microsoft公式統合リストを定期レビュー | 変更管理と運用のバランスを取りやすい | レビュー頻度と責任者を明確にしないと形骸化する |
厳格な環境では、いきなり広いワイルドカードを許可するより、今回追加されたFQDNを個別に追加し、将来の更新を検知する運用を整える方が現実的です。
Windows Autopilot運用で確認すべきポイント
今回の更新は、Windows Autopilotの「Diagnostics upload」に関係します。Autopilotのプロビジョニング失敗時に診断ログを自動収集する運用をしている場合、ログアップロード先への通信が失敗すると、障害調査の初動が遅れます。
Microsoft Learnでは、Windows Autopilot自動キャプチャ診断機能が有効な場合、障害発生時に診断が自動的にキャプチャされると説明されています。また、診断収集アクションは、Windows Autopilotエラー時にWindowsデバイスのログを自動収集してIntuneへアップロードするよう構成できます。(Microsoft Learn)
Autopilot運用担当者は、次の観点で確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| キッティング用ネットワーク | 初期セットアップ中の端末からTCP 443で外部通信できるか |
| プロキシ認証 | Autopilot中のデバイスが認証付きプロキシで詰まらないか |
| DNS解決 | lgmsapeswiss.blob.core.windows.net を名前解決できるか |
| エラー時のログ回収 | 失敗時にIntune管理センターから診断をダウンロードできるか |
| 拠点差 | 本社、支社、工場、委託先キッティング拠点で同じ結果になるか |
特に、ゼロタッチ展開や委託先での事前キッティングでは、管理者がその場で端末を触れないことが多くなります。診断ログの自動収集が失敗すると、現地作業者にスクリーンショットや手動ログ取得を依頼することになり、復旧時間が延びます。
ヘルプデスクと運用チームが確認すべきポイント
Intuneの「診断の収集」は、ヘルプデスクが端末トラブルを切り分ける際にも使われます。Microsoft Learnでは、Intune管理センターから対象デバイスを選び、「診断の収集」を実行し、完了後に診断データをダウンロードする流れが説明されています。(Microsoft Learn)
ただし、運用では次の制約も理解しておく必要があります。
| 制約 | 内容 | 運用上の注意 |
|---|---|---|
| ダウンロード上限 | 50診断または4MBを超える診断アップロードはIntuneポータルから直接ダウンロードできない | 大容量時はMicrosoft Intuneサポートへの相談を想定する |
| 反映時間 | 診断はエンドユーザーのデバイスから配信されるまで約30分かかる | 即時取得できない前提でSLAを設計する |
| 保存期間 | 診断コレクションは28日間保存後に削除される | 調査証跡が必要な場合は早めに保全する |
| 保存数 | 各デバイスは同時に最大10個のコレクションを保存できる | 繰り返し取得時は古い診断の扱いに注意する |
| 一括実行 | 最大25台のWindowsデバイスから一括で診断ログを収集できる | 大量障害時の初動手順に組み込める |
これらの条件は、ネットワーク許可リストの更新とセットで周知すべきです。エンドポイントが未許可のままでは、ヘルプデスクが正しい手順で操作しても診断データが届かず、「Intune側の不具合」と誤認される可能性があります。
コンプライアンスチームが確認すべきポイント
今回の更新はネットワーク担当だけで完結する話ではありません。診断データには、ユーザー名やデバイス名など、ユーザーを特定できる情報が含まれる場合があります。Microsoft Learnでも、個人データを収集する意図はないものの、診断にはユーザーやデバイス名などの識別情報が含まれる可能性があると説明されています。(Microsoft Learn)
また、Intune App ProtectionログやM365リモートアプリケーション診断に関して、データはMicrosoftサポートシステムに格納され、Intuneのデータ管理ポリシーや保護の対象にならない場合があることも説明されています。(Microsoft Learn)
コンプライアンスチームは、次の点を確認してください。
| 確認項目 | 確認する理由 |
|---|---|
| 診断収集の承認フロー | 管理者が任意にログ収集できる場合、内部統制上の説明が必要になる |
| 診断データの保存期間 | 28日保存後に削除されるため、調査証跡の保全ルールと整合させる |
| 個人情報の含有可能性 | ユーザー名、デバイス名、ログ情報が含まれる可能性がある |
| サポートアクセス | Microsoft担当者がトラブルシューティングのために診断へアクセスする場合がある |
| グローバル拠点のデータ所在地 | スイスを含むリージョン別エンドポイント追加が、社内ポリシーに影響するか確認する |
セキュリティ上は「通信を許可するか」だけでなく、「誰が、どの条件で、どの端末の診断を収集できるか」まで決めておくことが重要です。
実務で使える確認手順
今回のMicrosoft Intune公式ドキュメント更新を受けて、企業IT部門は次の順番で対応すると無駄が少なくなります。
| 手順 | 作業内容 | 担当の例 |
|---|---|---|
| 1 | Microsoft LearnとGitHubコミットで変更内容を確認する | Intune管理者 |
| 2 | 現在の許可リストに lgmsapeswiss.blob.core.windows.net があるか確認する | ネットワーク管理者 |
| 3 | ファイアウォール、プロキシ、SSE、DNSフィルタリングへ反映する | セキュリティ管理者 |
| 4 | Autopilot用ネットワークと通常業務ネットワークの両方で到達性を確認する | 端末運用チーム |
| 5 | テスト端末で「診断の収集」を実行し、取得可否を確認する | ヘルプデスク |
| 6 | 変更チケット、運用手順書、監査証跡を更新する | 情報システム部門 |
| 7 | 診断データの取り扱いを社内ポリシーと照合する | コンプライアンスチーム |
通信確認の初期チェックには、Windows端末から次のようなコマンドを使えます。
Resolve-DnsName lgmsapeswiss.blob.core.windows.net
Test-NetConnection lgmsapeswiss.blob.core.windows.net -Port 443プロキシ経由の確認では、次のようなコマンドも参考になります。
curl.exe -I https://lgmsapeswiss.blob.core.windows.netただし、これらはあくまで名前解決やTCP到達性の確認です。Intuneの診断アップロードが業務上問題なく完了するかは、Intune管理センターから実際にテスト端末へ「診断の収集」を実行して確認する必要があります。
失敗しやすいポイント
公式更新を「ドキュメントだけの変更」と見なしてしまう
今回の変更はMicrosoftDocs系のドキュメント更新ですが、内容は診断アップロード先のFQDN追加です。ファイアウォールやプロキシが厳しい環境では、ドキュメント変更がそのまま運用影響につながります。
Office 365 Endpoint service由来の古い一覧に頼り続ける
Intuneの公式ネットワークエンドポイントページでは、以前利用できたPowerShellスクリプトやOffice 365 Endpoint serviceの一覧では不十分になる可能性があると明記されています。許可リストを自動更新している場合でも、その取得元が現在のIntune公式統合リストに追従しているか確認が必要です。(Microsoft Learn)
Microsoft Graphで診断収集を自動化できると思い込む
Microsoft Learnでは、Microsoft Graphを直接呼び出して診断を収集またはダウンロードすることはできず、Intune管理センターを使う必要があると説明されています。運用自動化を設計している企業では、この点を誤解しないようにしてください。(Microsoft Learn)
「通信できる」だけで運用完了にしてしまう
FQDNへのTCP 443通信が成功しても、ヘルプデスクが診断を実行できるロールを持っていなければ運用は成立しません。Microsoft Learnでは、「診断の収集」を実行するにはヘルプデスクオペレーター、学校管理者、または必要な権限を含むカスタムロールが必要とされています。(Microsoft Learn)
この記事の結論
Microsoft Intuneの公式ドキュメント更新「Update diagnostics upload endpoints and documentation」は、Intuneの新機能発表というより、診断収集を確実に動かすためのネットワーク要件更新として扱うべき内容です。
次に取るべき行動は明確です。まず、lgmsapeswiss.blob.core.windows.net が自社の許可リストに含まれているか確認してください。次に、Autopilot用ネットワーク、通常業務ネットワーク、VPN、プロキシ、SSE、DNSフィルタリングの各経路で到達性を検証します。最後に、ヘルプデスク手順書とコンプライアンス上の診断データ取り扱いルールを更新すれば、今回の公式更新に対する実務対応としては十分に整理できます。
特に大規模展開やグローバル運用では、Intuneのエンドポイント更新を「あとで確認する」対象にしないことが重要です。診断ログは、障害が起きた後に必要になります。必要になった瞬間にアップロードできない状態を避けるため、平時のうちに通信許可、権限、手順、証跡をそろえておきましょう。
コメント