2026年4月30日のGitHub公式ドキュメント更新「Uploaded file: office-365-france-endpoints.md – 2026-04-30 12:44:39.4980」でまず押さえるべき結論は、GitHub本体の機能変更ではなく、GitHub上のMicrosoftDocs公式リポジトリでMicrosoft 365 France向けエンドポイント定義が更新されたという点です。対象ファイルは microsoft-365/includes/office-365-france-endpoints.md で、ネットワーク許可リスト、プロキシ、PACファイル、ファイアウォール、ExpressRoute前提の設計に影響がないか確認する価値があります。コミットでは1ファイルに対して9行追加・7行削除が行われています。(GitHub)
特に見るべきなのは、*.sovcloud-sharepoint.fr のカテゴリ変更、明示IPレンジの削除、*.identity-sovcloud.fr から *.sovcloud-identity.fr へのドメイン変更、さらに *.sovcloud-usercontent.fr と *.sovcloud-static.fr が個別行として整理された点です。これらは、Microsoft 365 France環境を扱う開発者、クラウド管理者、ソリューションアーキテクトにとって、通信要件の棚卸し対象になります。(GitHub)
GitHubの公式ドキュメント更新で何が変わったか
今回の更新は、MicrosoftDocsの microsoft-365-docs リポジトリにある自動生成ファイルの差分です。コミットメッセージは「Uploaded file: office-365-france-endpoints.md – 2026-04-30 12:44:39.4980」で、ファイル内のFrance endpoints versionは 2026033100 から 2026043000 に更新されています。生成日時も 2026-04-27 18:37:29.3380 から 2026-04-30 12:44:39.2526 に変わっています。(GitHub)
この更新は、GitHub Actions、GitHub Enterprise、GitHub CopilotなどのGitHubサービス仕様変更ではありません。実態は、GitHubでホストされているMicrosoft公式ドキュメントの更新です。そのため、確認すべき対象は「GitHubの設定」ではなく、Microsoft 365 France向け通信先を利用しているシステムやネットワーク機器の設定です。
変更点の比較
| 項目 | 更新前 | 更新後 | 確認すべきポイント |
|---|---|---|---|
| France endpoints version | 2026033100 | 2026043000 | 2026年4月30日版として管理台帳を更新する |
| SharePoint Online / OneDrive for Business ID 2 | Optimize / Required | Default / Required | Optimize前提の直接通信・優先制御をしていないか確認する |
| SharePoint系アドレス | *.sovcloud-sharepoint.fr + 86.232.96.0/19, 2a01:dfff:580::/41 | *.sovcloud-sharepoint.fr | IPレンジを明示許可している場合は削除判断を急がず通信ログと照合する |
| Common / Office Online ID 1 | *.sovcloud-static.fr, *.sovcloud-usercontent.fr, *.sovcloud.fr | *.sovcloud.fr | 旧行をまとめて参照しているスクリプトがないか確認する |
| Common / Office Online ID 3 | *.identity-sovcloud.fr | *.sovcloud-identity.fr | 認証系通信の許可リストに旧ドメインが残っていないか確認する |
| Common / Office Online ID 4 | なし | *.sovcloud-usercontent.fr | 新しい個別エントリとして管理対象に加える |
| Common / Office Online ID 5 | なし | *.sovcloud-static.fr | 静的コンテンツ系通信の許可ルールを分離して確認する |
差分を見る限り、今回の主な変更は「ポート番号の大幅な変更」ではなく、カテゴリ、アドレス表記、エンドポイント行の整理です。たとえば、*.sovcloud-sharepoint.fr は引き続きTCP 443/80とUDP 443が記載されています。一方で、以前同じ行に含まれていたIPv4/IPv6レンジは更新後の行から外れています。(GitHub)
まず確認すべき影響範囲
このGitHub公式ドキュメント更新を見たときに、最初に確認すべきなのは「自社がMicrosoft 365 France向けのエンドポイント定義をどこで使っているか」です。影響が出やすいのは、次のような環境です。
| 確認対象 | 具体例 | 見落としやすい点 |
|---|---|---|
| ファイアウォール | FQDN許可、IPレンジ許可、アプリケーション制御 | IPレンジだけを許可していてFQDN側が未整備 |
| プロキシ | 認証除外、SSLインスペクション除外、カテゴリ制御 | Optimize 前提でバイパスしていた通信の扱い |
| PACファイル | SharePoint/OneDrive向けの直接接続ルール | 古いドメイン名が条件式に残る |
| DNS/名前解決 | ワイルドカードドメインの解決、分割DNS | *.identity-sovcloud.fr と *.sovcloud-identity.fr の取り違え |
| 監視・SIEM | 許可済み通信先の検知除外 | 新しいID 4/5を未知の通信として誤検知 |
| IaC/自動化スクリプト | Terraform、Ansible、PowerShell、GitHub Actions | 1行に複数ドメインがある前提のパーサーが壊れる |
Microsoftの説明では、Microsoft 365エンドポイントはインターネット上のMicrosoft 365トラフィックの宛先IPアドレス、DNSドメイン名、URLのセットです。また、ファイアウォール、TLS検査、パケット検査、DLPなどのネットワーク境界機器で特別な処理が必要になる場合があります。(Microsoft Learn)
「Optimize」から「Default」への変更をどう判断するか
今回、SharePoint Online and OneDrive for BusinessのID 2は、カテゴリが Optimize Required から Default Required に変わっています。Microsoft 365のエンドポイントカテゴリは、対象エンドポイントが「最適化」「許可」「既定」のどれに分類されるかを示すもので、同時にネットワーク接続に必要なエンドポイントかどうかも示します。(Microsoft Learn)
実務上は、ここを軽く見ないほうがよいです。Optimize 扱いだった通信をプロキシバイパス、SSLインスペクション除外、SD-WANの優先経路、低遅延パスに載せている環境では、Default への変更によって設計意図を見直す必要があります。
ただし、カテゴリ変更を見てすぐに通信を遮断したり、バイパス設定を削除したりするのは危険です。Required は維持されています。つまり、Microsoft 365 France利用環境では、該当通信が不要になったと単純に判断すべきではありません。
実務での判断基準
| 状況 | 推奨対応 |
|---|---|
Optimize カテゴリだけを条件に自動でプロキシバイパスしている | Default 変更後も業務影響がないか、段階的に検証する |
*.sovcloud-sharepoint.fr をFQDNで許可している | ルールは維持し、ログ上の通信先とポートを確認する |
86.232.96.0/19 や 2a01:dfff:580::/41 を明示許可している | すぐ削除せず、公式データ、通信ログ、変更管理の承認をそろえる |
| SharePoint/OneDriveの遅延対策として専用経路を設計している | Default 化が経路制御に与える影響をネットワーク設計書に反映する |
ポイントは、「カテゴリ変更」と「接続不要」は別物として扱うことです。今回の差分では Required が残っているため、許可リストから機械的に外すのではなく、通信経路とセキュリティ処理の見直しとして扱うのが安全です。
ドメイン変更で特に注意すべき点
今回の更新で目立つのが、認証系に見えるドメイン表記の変更です。更新前は *.identity-sovcloud.fr、更新後は *.sovcloud-identity.fr になっています。(GitHub)
このような変更で失敗しやすいのは、「似た名前だから同じもの」と考えてしまうことです。実際には、ドメインの語順が変わると完全に別のワイルドカード条件になります。プロキシ、CASB、DNSフィルタリング、EDRのネットワーク制御で旧ドメインだけを許可している場合、新しいドメインへの通信がブロックされる可能性があります。
確認すべき設定例
旧: *.identity-sovcloud.fr
新: *.sovcloud-identity.fr確認するときは、単純な文字列検索だけでは不十分です。設定ファイルによっては、ワイルドカードを正規表現、サフィックス一致、URLカテゴリ、カスタムオブジェクト名で管理していることがあります。
たとえば、以下のような場所を確認します。
- プロキシの宛先FQDNオブジェクト
- ファイアウォールのURL/FQDN許可ルール
- PACファイルの
dnsDomainIs()やshExpMatch()条件 - ZTNA/SASE製品のMicrosoft 365向け例外ルール
- 監視ツールの許可済みドメインリスト
- IaCリポジトリ内の変数ファイル
- GitHub Actionsなどで生成しているネットワーク設定テンプレート
特に、identity を含むドメインは認証やサインインまわりの通信と関連して扱われやすいため、ブロックされた場合に「ログインできない」「Officeアプリが認証を繰り返す」「OneDrive同期が不安定になる」といった症状として現れる可能性があります。断定はできませんが、障害調査では優先的に確認したいポイントです。
sovcloud-static と sovcloud-usercontent が分離された意味
更新前のID 1では、*.sovcloud-static.fr、*.sovcloud-usercontent.fr、*.sovcloud.fr が同じ行にまとめて記載されていました。更新後は、ID 1が *.sovcloud.fr、ID 4が *.sovcloud-usercontent.fr、ID 5が *.sovcloud-static.fr として個別に分かれています。(GitHub)
これは、運用面では「同じ許可ルールで済むか」よりも、「自社の管理ロジックが行IDや配列構造に依存していないか」を確認するきっかけになります。
たとえば、次のような実装は注意が必要です。
ID 1のAddressesを取得し、Common and Office Onlineの許可リストとして一括登録するこのような自動化をしている場合、更新後はID 1だけを見ても *.sovcloud-usercontent.fr と *.sovcloud-static.fr を取り逃がします。結果として、静的ファイルやユーザー生成コンテンツに関係する通信が意図せずブロックされる可能性があります。
自動化スクリプトで見直すべき条件
| 危険な実装 | 改善案 |
|---|---|
| 特定のIDだけを固定で取得する | サービスエリア、カテゴリ、Required、ドメイン全体を条件にする |
| Addresses列をカンマ区切りだけで分解する | Markdown、CSV、JSONなど取得形式に応じてパーサーを分ける |
| 旧ドメインを手動でハードコードする | 公式更新を取り込む変数ファイルに集約する |
| 削除されたIPを即時削除する | 一定期間ログを確認し、変更管理プロセスで削除する |
| ドメイン追加を監視対象外にする | 新規FQDNをSIEMやプロキシログの確認対象に入れる |
Microsoft 365 IPアドレスとURL Webサービスは、Microsoft 365ネットワークトラフィックの識別、変更評価、構成更新、最新状態の維持に使えるRESTベースのサービスとして説明されています。標準的なMicrosoft 365エンドポイント管理では、手作業でドキュメントを追うだけでなく、Webサービスや自動化の仕組みも併用するのが現実的です。(Microsoft Learn)
運用チームが取るべき確認手順
このGitHub公式ドキュメント更新を見つけたら、以下の順序で確認すると手戻りを減らせます。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | GitHubのコミット差分を確認する | 変更対象のファイル、行、ドメイン、カテゴリを把握する |
| 2 | 自社環境で該当ドメインを検索する | 旧設定・手動許可・ハードコードを見つける |
| 3 | 通信ログを確認する | 実際に該当FQDN/IPへ通信している端末や拠点を把握する |
| 4 | 影響範囲を分類する | 本番、検証、管理端末、VDI、拠点ネットワークを分ける |
| 5 | 変更案を作成する | 追加、維持、削除、保留を明確にする |
| 6 | 検証環境または限定拠点で反映する | 認証、SharePoint、OneDrive、Office Onlineの動作を見る |
| 7 | 本番反映後に監視する | プロキシ拒否ログ、認証失敗、同期エラーを確認する |
変更時に重要なのは、「追加」と「削除」を同時に雑に行わないことです。新しいFQDNを追加する作業と、古いIPレンジや旧ドメインを削除する作業は、リスクの性質が異なります。
新しいFQDNの追加は、通信断を避けるために早めに検討します。一方、削除はログ、利用状況、ロールバック手順を確認してから行うべきです。Microsoftの変更Webメソッドの説明でも、追加されたIPやURLは境界デバイス側の変更が必要になり、使用開始前に追加しないと停止が発生する可能性があるとされています。(Microsoft Learn)
開発者が確認すべきポイント
開発者の場合、「ネットワーク機器の設定はインフラ担当の仕事」と考えがちです。しかし、GitHubで管理しているIaC、CI/CD、設定生成スクリプトがMicrosoft 365エンドポイントを参照している場合、開発側にも影響があります。
特に確認したいのは次の3点です。
設定ファイルに旧ドメインが残っていないか
リポジトリ全体で、次の文字列を検索します。
identity-sovcloud.fr
sovcloud-identity.fr
sovcloud-sharepoint.fr
sovcloud-usercontent.fr
sovcloud-static.fr
86.232.96.0/19
2a01:dfff:580::/41旧ドメインや削除されたIPレンジが残っていたとしても、すぐに消すのではなく、その設定が何に使われているかを確認します。テスト用、過去のコメント、廃止済み環境の設定であれば影響は限定的です。一方、本番用テンプレート、共通変数、プロキシ設定生成ロジックに含まれている場合は、変更管理の対象になります。
Markdown差分をパースしている処理が壊れないか
今回のように、1つの行に複数ドメインが含まれていたものが複数行に分割されると、単純なパーサーは取りこぼしを起こします。
たとえば、以下のようなロジックは危険です。
「Microsoft 365 Common and Office Online」の最初の行だけを読むより安全なのは、セクション内の全行を対象にし、Required、ポート、FQDNをそれぞれ構造化して扱う方法です。可能であれば、Markdownの見た目ではなく、公式のWebサービスや機械処理に向いた形式を使う設計に寄せるべきです。
GitHub Actionsで自動反映している場合は承認フローを入れる
GitHub Actionsで公式ドキュメントを定期取得し、ファイアウォールやプロキシの設定を生成している場合、完全自動反映は便利ですが危険です。
おすすめは、次のような流れです。
公式更新を検知
↓
差分レポートを生成
↓
Pull Requestを自動作成
↓
ネットワーク管理者がレビュー
↓
検証環境へ反映
↓
本番反映エンドポイント変更は、アプリケーションコードの更新と違い、失敗すると広範囲の業務通信に影響します。自動化するほど、レビューとロールバックの設計が重要になります。
クラウド管理者・アーキテクトが見るべき設計論点
クラウド管理者やソリューションアーキテクトは、単に「新しいドメインを許可するか」だけでなく、ネットワーク設計全体との整合性を見ます。
プロキシ経由と直接接続の整理
Optimize から Default への変更は、プロキシバイパス設計に関係します。すべてのMicrosoft 365通信を一律に直接接続している環境では影響が小さいかもしれませんが、カテゴリごとに経路を分けている環境では確認が必要です。
たとえば、次のような設計です。
| 通信カテゴリ | 従来の扱い例 | 今回の確認 |
|---|---|---|
| Optimize | 直接接続、SSL検査除外、低遅延経路 | ID 2がDefaultになった後も同じ扱いにするか |
| Default | プロキシ経由、通常監査、標準経路 | SharePoint系通信をDefault扱いに寄せるか |
| Required | ブロック不可の業務必須通信 | Requiredが維持されている通信を誤って遮断しないか |
「カテゴリが変わったからセキュリティを強める」という判断自体はあり得ます。ただし、その結果としてOneDrive同期、SharePointアクセス、Office Online編集、認証処理に影響が出ないかを事前に検証する必要があります。
ExpressRoute前提の誤解を避ける
今回の差分では、該当行のER列はいずれも No です。Microsoftの説明では、ERが「いいえ」の場合、そのエンドポイントセットではExpressRouteがサポートされないことを意味します。(Microsoft Learn)
そのため、ExpressRouteを使っている企業でも、「Microsoft 365関連だからすべて閉域側で処理できる」と考えるのは危険です。ER列がNoの通信は、インターネット向けの制御、プロキシ、DNS、監査ログを含めて設計する必要があります。
監視ルールを更新する
新しいFQDNが追加・分離されたとき、セキュリティ監視側では未知の外部通信として検知されることがあります。SOCやCSIRTがある組織では、変更内容を事前に共有し、少なくとも以下を確認します。
- 新しいFQDNがブロックログに出ていないか
- 認証失敗やOfficeアプリの再ログインが増えていないか
- OneDrive同期エラーが増えていないか
- SharePointアクセスの遅延が出ていないか
- 旧IPレンジへの通信が継続していないか
運用で使える判断軸は、「設定を変えたか」ではなく「業務通信が成功しているか」です。変更後24〜72時間程度は、拠点別・端末種別・プロキシ別にログを見ると問題を早期に見つけやすくなります。
失敗しやすいポイント
今回のような公式ドキュメント更新では、内容そのものよりも、組織側の受け止め方で失敗が起きます。
| 失敗例 | なぜ危険か | 防ぎ方 |
|---|---|---|
| GitHubの更新なので開発部門だけで処理する | 実際の影響はネットワーク・Microsoft 365運用に出る | インフラ、セキュリティ、M365管理者に共有する |
| 削除されたIPレンジを即日削除する | 既存通信やキャッシュ、段階展開の影響を見落とす | ログ確認後に段階的に削除する |
| 新旧ドメインを見間違える | identity-sovcloud と sovcloud-identity は別条件 | 完全一致検索とワイルドカード確認を行う |
| ID 1だけを見てCommon系を更新する | ID 4/5に分離されたドメインを取り逃がす | セクション全体を確認する |
| 本番だけ更新する | 問題発生時に検証・比較ができない | 検証環境、限定拠点、本番の順で進める |
| 変更履歴を残さない | 障害発生時に原因を追跡できない | コミットID、反映日時、変更者、判断理由を記録する |
特に重要なのは、旧設定を「古いから悪」と決めつけないことです。公式ドキュメント上の削除と、自社環境で安全に削除できるタイミングは同じではありません。変更には、業務影響、セキュリティ、監査、ロールバックの観点を入れるべきです。
今回の更新を社内で共有する文面例
社内の変更管理や運用チャンネルに共有するなら、次のように簡潔にまとめると伝わりやすくなります。
MicrosoftDocs/microsoft-365-docs の GitHubコミット 622c9d5 にて、
office-365-france-endpoints.md が 2026-04-30版に更新されました。
主な確認点:
- France endpoints version が 2026043000 に更新
- SharePoint/OneDrive ID 2 が Optimize Required から Default Required に変更
- *.sovcloud-sharepoint.fr の行から 86.232.96.0/19 と 2a01:dfff:580::/41 が外れた
- *.identity-sovcloud.fr が *.sovcloud-identity.fr に変更
- *.sovcloud-usercontent.fr と *.sovcloud-static.fr が個別IDとして追加
対応方針:
- Microsoft 365 France関連のFQDN/IP許可リストを棚卸し
- プロキシ、PAC、Firewall、監視ルール、IaC内の旧ドメインを検索
- 新FQDNは検証後に追加
- 削除候補のIP/旧ドメインはログ確認後に判断この文面のポイントは、事実、影響範囲、対応方針を分けていることです。単に「更新がありました」だけでは、受け取った側が何をすべきか分かりません。
すぐにやるべきこと
今回のGitHub公式ドキュメント更新で取るべき次の行動は、次の3つです。
まず、*.identity-sovcloud.fr、*.sovcloud-identity.fr、*.sovcloud-sharepoint.fr、*.sovcloud-usercontent.fr、*.sovcloud-static.fr を、自社の設定ファイル、ネットワーク機器、監視ルール、IaCリポジトリで検索します。
次に、86.232.96.0/19 と 2a01:dfff:580::/41 を明示許可している場所がないか確認します。見つかった場合は、すぐ削除するのではなく、通信ログと利用サービスを確認してから変更計画に入れます。
最後に、IDや行番号に依存した自動化をしていないか見直します。今回のように、同じサービス領域内でエンドポイントが分割されると、固定ID前提のスクリプトは取りこぼしを起こします。
この更新は、見た目には小さなMarkdownファイルの差分です。しかし、Microsoft 365 France環境を利用する組織にとっては、認証、SharePoint、OneDrive、Office Onlineの通信安定性に関わる確認ポイントを含んでいます。GitHub上の公式更新をきっかけに、許可リスト、プロキシ設計、自動化スクリプト、監視ルールをセットで見直すことが、最も実務的な対応です。
コメント