結論から言うと、2026年4月30日の「Uploaded file: office-365-germany-endpoints.md – 2026-04-30 12:44:43.8199」は、GitHubそのものの機能変更ではなく、GitHub上の MicrosoftDocs リポジトリで公開された Microsoft 365／Office 365 Germany 系エンドポイント情報の更新です。特に確認すべき点は、SharePoint Online／OneDrive for Business のカテゴリ変更、公開IPレンジの削除、認証系ドメイン名の変更、Common／Office Online ドメインの分割です。
この更新を見落とすと、ファイアウォール、プロキシ、PACファイル、SD-WAN、SASE／SWG製品の許可リストで不整合が起き、ドイツ向け Microsoft 365 環境を利用するユーザーや拠点で接続不良が発生する可能性があります。一方で、日本国内の一般的な Microsoft 365 Worldwide テナントだけを運用している場合は、直接影響しないケースもあります。重要なのは「自社の対象クラウド」「参照しているエンドポイント情報」「ネットワーク機器への反映方法」を切り分けて確認することです。
GitHubの公式ドキュメント更新「office-365-germany-endpoints.md」で何が変わったか
今回の更新は、MicrosoftDocs の microsoft-365-docs リポジトリにある microsoft-365/includes/office-365-germany-endpoints.md の差分です。コミットでは、対象ファイル1件に対して9行追加、7行削除が行われ、Germany endpoints version は 2026033100 から 2026043000 に更新されています。ファイル生成日時も 2026-04-30 12:44:43.6264 に変わっています。(GitHub)
| 確認項目 | 変更前 | 変更後 | 実務上の見方 |
|---|---|---|---|
| Germany endpoints version | 2026033100 | 2026043000 | 2026年4月30日時点の新しいエンドポイント定義として扱う |
| SharePoint Online／OneDrive for Business ID 37 | Optimize / Required | Default / Required | ローカルブレイクアウト、PAC、プロキシバイパス条件に影響する可能性 |
| ID 37 の Addresses | *.sovcloud-sharepoint.de と 142.221.96.0/19, 2a07:3040:580::/41 | *.sovcloud-sharepoint.de のみ | IPレンジベースの許可リストを使っている場合は要確認 |
| Microsoft 365 Common／Office Online ID 36 | *.sovcloud-static.de, *.sovcloud-usercontent.de, *.sovcloud.de | *.sovcloud.de | 1行にまとまっていたドメインが分割された |
| 追加された行 | なし | ID 39 *.sovcloud-usercontent.de、ID 40 *.sovcloud-static.de | ID単位で取り込む自動処理では追加行の取りこぼしに注意 |
| ID 38 | *.identity-sovcloud.de | *.sovcloud-identity.de | 認証系ドメインの許可リスト、ログ監視、DNSポリシーの確認が必要 |
見た目は小さな差分ですが、ネットワーク運用では影響が大きくなる可能性があります。特に、エンドポイントのカテゴリやIPレンジは、ファイアウォールACL、プロキシ例外、TLSインスペクション除外、SD-WANのルーティングポリシーに直結します。
まず誤解しやすい点：GitHubの仕様変更ではない
この更新は「GitHub documentation update」という文脈で見つかるため、GitHub Actions、GitHub Enterprise、GitHub API、GitHub Copilot などの仕様変更だと誤解しやすいです。しかし、実体は GitHub 上で管理されている MicrosoftDocs 系ドキュメントの更新です。
つまり、開発者が確認すべき観点は「GitHubの使い方が変わったか」ではなく、次のようになります。
- 自社が Office 365 Germany／Microsoft 365 Germany 系のエンドポイントを参照しているか
- Microsoft 365 のネットワーク許可リストを GitHub上のドキュメント差分から監視しているか
- ファイアウォール、プロキシ、PACファイル、SASE製品に古いドメインやIPレンジが残っていないか
- エンドポイントIDやカテゴリを条件にした自動反映スクリプトが、新しい行を正しく取り込めるか
特にグローバル企業では、国内本社は Worldwide テナントでも、ドイツ拠点や買収企業、特定規制下の環境で別クラウドを利用している場合があります。自社の契約、テナント、ネットワーク経路を確認せずに「日本企業だから関係ない」と判断するのは避けるべきです。
運用影響が出やすいポイント
SharePoint／OneDrive のカテゴリが Optimize から Default に変わった
もっとも注意したいのは、ID 37 のカテゴリが Optimize から Default に変わった点です。Microsoft 365 のエンドポイントカテゴリには Optimize、Allow、Default があり、Optimize と Allow はネットワーク遅延やパフォーマンスに敏感な通信として扱われることがあります。一方、Default カテゴリは性質上動的で、IPアドレスが時間とともに変わるため、IPアドレスが関連付けられないと説明されています。(Microsoft Learn)
この変更により、以下のような運用差分が出る可能性があります。
| 利用している仕組み | 確認すべきこと |
|---|---|
| PACファイル | Optimize のみを直接接続にしている場合、ID 37 が対象外になるか |
| SD-WAN | Microsoft 365 Optimizeカテゴリをローカルブレイクアウトしている場合、ルールが変わるか |
| プロキシバイパス | *.sovcloud-sharepoint.de が現在どの経路を通っているか |
| TLSインスペクション | カテゴリ変更後も検査除外すべきか、社内基準と照合する |
| 監視ルール | 旧カテゴリ前提のアラートやダッシュボードが残っていないか |
注意したいのは、「Default になったから検査してよい」「Optimize ではなくなったから重要ではない」と短絡的に判断しないことです。今回の行は引き続き Required です。接続が必要なエンドポイントであることは変わっていないため、カテゴリ変更と到達性要件は分けて考える必要があります。
IPレンジが削除され、FQDN中心の確認が必要になった
変更前の ID 37 には 142.221.96.0/19 と 2a07:3040:580::/41 が含まれていましたが、変更後は *.sovcloud-sharepoint.de のみになっています。(GitHub)
これは、IPアドレスベースで SharePoint／OneDrive の通信を許可している環境では重要です。たとえば、以下のような構成では影響確認が必要です。
- ファイアウォールで Microsoft 365 通信をIPレンジ単位で許可している
- IPv6の許可リストを個別に管理している
- SASE／SWG製品でFQDNではなくIPオブジェクトを使っている
- 古いMicrosoft 365エンドポイント情報をもとに静的ACLを作成している
- IaCや構成管理ツールで古いIPレンジをテンプレート化している
ただし、削除されたIPレンジを即座に遮断するのは危険です。既存セッション、DNS解決結果、ネットワーク機器のキャッシュ、ベンダー製品の自動更新タイミングに差が出ることがあります。まずは通信ログで実利用の有無を確認し、段階的にルールを整理するのが安全です。
*.identity-sovcloud.de から *.sovcloud-identity.de への変更を見落としやすい
ID 38 では、認証系と見られるドメインが *.identity-sovcloud.de から *.sovcloud-identity.de に変わっています。文字列が似ているため、レビュー時に見落としやすい差分です。(GitHub)
この変更は、次のような障害につながる可能性があります。
- サインイン画面に遷移できない
- SharePoint／OneDrive は開けるが認証後に失敗する
- 一部ユーザーだけセッション更新に失敗する
- プロキシログで
sovcloud-identity.deがブロックされる - DNSフィルタやCASBで未分類ドメインとして扱われる
運用では、旧ドメインを削除する前に新ドメインを許可し、認証フローのログを確認してください。特に、ゼロトラスト製品やセキュアWebゲートウェイで「新規ドメイン」「未分類ドメイン」を厳しく制御している環境では、事前登録が必要になる場合があります。
Common／Office Online のドメインが分割された
変更前は ID 36 に *.sovcloud-static.de、*.sovcloud-usercontent.de、*.sovcloud.de がまとまっていました。変更後は ID 36 が *.sovcloud.de のみになり、ID 39 と ID 40 として *.sovcloud-usercontent.de、*.sovcloud-static.de が分かれて追加されています。(GitHub)
このタイプの変更で失敗しやすいのは、FQDNではなくエンドポイントIDをキーにして設定を取り込んでいるケースです。たとえば「ID 36だけを許可している」「既存IDの変更だけを差分反映し、新規IDの追加を承認待ちにしている」といった運用では、ID 39とID 40が抜ける可能性があります。
Office Onlineや共通コンテンツ配信系のドメインがブロックされると、文書のプレビュー、静的ファイルの読み込み、Web UIの一部表示など、ユーザーから見ると「画面が崩れる」「一部だけ読み込まれない」という曖昧な症状になりがちです。障害調査では、アプリケーションログだけでなく、プロキシの拒否ログ、DNSログ、ブラウザの開発者ツールも確認してください。
管理者が今すぐ確認すべきチェックリスト
| 対象 | 確認内容 | 判断基準 |
|---|---|---|
| テナント／クラウド種別 | 自社が Germany 系エンドポイントを使う環境を持っているか | ドイツ拠点、規制対象環境、統合済み子会社を含めて確認 |
| ファイアウォール | 旧IPレンジ 142.221.96.0/19、2a07:3040:580::/41 に依存していないか | FQDNベース、公式データ連携、段階的削除の方針を決める |
| プロキシ／SWG | *.sovcloud-sharepoint.de、*.sovcloud-identity.de、*.sovcloud-usercontent.de、*.sovcloud-static.de が許可されているか | 拒否ログや未分類ドメイン扱いがないか確認 |
| PAC／WPAD | Optimize 前提の条件分岐でID 37を処理していないか | カテゴリ変更後の経路が意図通りか確認 |
| SD-WAN／SASE | Microsoft 365カテゴリ別ルーティングに今回の差分が反映されるか | ベンダーの自動連携結果と社内ポリシーを突き合わせる |
| 監視 | 新旧ドメインの通信ログを比較できるか | 認証失敗、HTTP 403/407、DNSブロックを重点確認 |
| 変更管理 | 2026043000 への更新として記録しているか | 影響範囲、承認者、反映日時、ロールバック方針を残す |
開発者・アーキテクトが見るべき観点
開発者やソリューションアーキテクトにとって、この更新は単なるネットワーク担当者向けの話ではありません。SharePoint Online、OneDrive for Business、Office Online と連携するアプリケーションを設計している場合、通信先ドメインや認証エンドポイントの変更は、アプリケーションの可用性に影響します。
特に次の設計は見直す価値があります。
- アプリケーション内に特定ドメインをハードコードしていないか
- リバースプロキシやAPIゲートウェイでドメイン単位の許可制御をしていないか
- CI/CDのテスト環境が本番と同じプロキシルールを使っているか
- 監視ツールで旧ドメインだけを正常性チェック対象にしていないか
- Terraform、Ansible、Intune、MDMなどで古いネットワーク設定を配布していないか
設計上のおすすめは、個別ドメインやIPレンジをアプリケーションコードに埋め込まないことです。ネットワーク許可リストは、公式エンドポイント情報を取得する仕組み、構成管理、変更承認フローに寄せるべきです。Microsoft 365 のエンドポイントは継続的に変わるため、手作業で一度設定して終わりにする運用は障害の原因になります。
公式情報の確認と反映は「GitHub差分だけ」で終わらせない
GitHubのコミット差分は、変更点を素早く把握するには便利です。しかし、実際の運用反映では、GitHub上のincludeファイルだけを直接コピーしてネットワーク機器へ投入するのは避けるべきです。
Microsoftは、Microsoft 365 IP アドレスと URL Web サービスを使って、エンドポイント情報の取得、変更評価、構成の最新化を行えると説明しています。このWebサービスでは、バージョン確認、最新エンドポイント取得、変更差分取得などが可能です。(Microsoft Learn)
実務では、次の順序で確認すると安全です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | GitHubの差分で変更点を把握する | 何が変わったかを短時間で確認する |
| 2 | 公式ドキュメント／Webサービス側の最新情報と突き合わせる | GitHub差分だけに依存しない |
| 3 | 自社の対象クラウドと対象拠点を確認する | 影響範囲を限定する |
| 4 | 現在のファイアウォール、プロキシ、PAC、SASE設定を棚卸しする | 古いIP・旧ドメイン・ID固定運用を見つける |
| 5 | 検証環境または限定拠点で反映する | 認証、SharePoint閲覧、Office Online表示を確認する |
| 6 | 本番反映後に拒否ログとユーザー影響を監視する | 小さな表示崩れや認証失敗を早期に検知する |
Microsoft 365 のエンドポイント変更では、新しいURLやIPアドレスの追加がネットワーク境界環境に影響し、事前に反映しないとユーザー停止につながる可能性があると説明されています。また、変更通知やバージョン確認の仕組みを使うことで、手作業に頼らない運用ができます。(Microsoft Learn)
失敗しやすいポイントと回避策
旧IPレンジをすぐ削除してしまう
今回の差分ではIPレンジが消えていますが、ネットワーク機器の反映タイミングやDNS解決の状態によっては、すぐ削除すると切り分けが難しくなります。まずはログで実通信を確認し、不要と判断できる段階で削除してください。
新しい *.sovcloud-identity.de を追加し忘れる
identity-sovcloud と sovcloud-identity は見た目が似ています。レビューでは目視だけに頼らず、差分比較ツールや構成管理のテストを使いましょう。認証系ドメインは、ブロックされるとアプリ全体の障害に見えやすいため優先度高めで確認するべきです。
ID 36の変更だけを反映し、ID 39／40を取り込まない
ドメインが分割されたため、新規IDを無視するスクリプトでは取りこぼしが発生します。差分処理では「既存IDの変更」だけでなく、「新規IDの追加」「既存IDからのドメイン分離」も検出できるようにしてください。
Defaultカテゴリを一般Webと同じ扱いにしてしまう
Defaultカテゴリになったからといって、Microsoft 365に必要な通信であることまで変わったわけではありません。ID 37は引き続き Required です。セキュリティ検査、プロキシ認証、DLP、TLS復号の扱いは、カテゴリ名だけで決めず、Microsoft 365通信全体の設計方針と照らし合わせる必要があります。
GitHub監視だけで変更管理が完結している
GitHubのコミット監視は有効ですが、最終的な反映判断は公式のエンドポイント情報、対象クラウド、社内ネットワーク構成に基づいて行うべきです。通知を受けるだけでなく、「誰が確認するか」「どの環境に反映するか」「障害時に戻せるか」まで手順化してください。
影響がありそうな環境の判断基準
今回の更新は、すべての企業に同じ影響が出るわけではありません。次の条件に当てはまるほど、優先度を上げて確認してください。
| 優先度 | 条件 | 対応 |
|---|---|---|
| 高 | Office 365 Germany／Microsoft 365 Germany系の環境を利用している | すぐにネットワーク設定とログを確認 |
| 高 | ドイツ拠点、ドイツ子会社、規制対応環境がある | 対象テナントと経路を棚卸し |
| 高 | Microsoft 365エンドポイントをIPレンジ中心で許可している | FQDNベースの設計へ移行を検討 |
| 中 | GitHubのMicrosoftDocs差分を監視して運用反映している | 自動処理が新規IDとカテゴリ変更を扱えるか確認 |
| 中 | SD-WANやSASEでMicrosoft 365カテゴリ別ルーティングをしている | ベンダー連携結果と社内ルールを比較 |
| 低 | Worldwideテナントのみで、Germany系通信がない | 直接影響は限定的。ただし運用プロセスの点検材料にする |
次に取るべき行動
まず、自社が office-365-germany-endpoints.md の対象となる環境を持っているか確認してください。対象がある場合は、*.sovcloud-sharepoint.de、*.sovcloud-identity.de、*.sovcloud-usercontent.de、*.sovcloud-static.de の許可状況を確認し、旧IPレンジや旧ドメインに依存した設定がないか洗い出します。
次に、PACファイル、プロキシ、ファイアウォール、SD-WAN、SASE製品で「Optimizeカテゴリ前提」「エンドポイントID固定」「IPレンジ固定」のルールが残っていないか確認してください。今回の変更は、カテゴリ変更、IP削除、ドメイン変更、ドメイン分割が同時に含まれているため、単純な文字列追加だけでは不十分です。
最後に、Microsoft 365エンドポイントの変更管理を定期運用に組み込みましょう。GitHubの差分確認は入口として有効ですが、実際の反映では公式エンドポイント情報、社内の対象クラウド、ネットワークログ、段階的な本番反映を組み合わせることが重要です。今回の更新をきっかけに、Microsoft 365のネットワーク許可リストを「手作業の静的設定」から「変更を前提にした運用」へ見直すべきです。
コメント