2026年4月30日のGitHub公式ドキュメント更新「Uploaded file: office-365-worldwide-endpoints.md – 2026-04-30 12:44:42.0870」は、GitHubというサービス自体の仕様変更ではなく、MicrosoftDocsリポジトリ上で公開されている Microsoft 365 / Office 365 の worldwide エンドポイント情報 の更新です。まず確認すべき結論は、SharePoint Online / OneDrive for Business のエンドポイント一覧から ID 33のSharePoint Hybrid Search関連エントリが削除された 点です。あわせて、エンドポイントデータのバージョンが 2026033100 から 2026043000 に更新されています。ネットワーク管理者、クラウド管理者、ソリューションアーキテクトは、ファイアウォール、プロキシ、PACファイル、SD-WAN、ExpressRoute設計に影響がないかを確認してください。(GitHub)
GitHubの公式ドキュメント更新で何が変わったか
今回の更新は、GitHub上の MicrosoftDocs/microsoft-365-docs リポジトリに対するコミットです。対象ファイルは microsoft-365/includes/office-365-worldwide-endpoints.md で、コミット内容には「1 file changed」「3 additions & 4 deletions」と表示されています。つまり、大規模なドキュメント改訂ではなく、Microsoft 365 worldwide エンドポイント一覧の自動生成データが差し替えられた更新と見るのが適切です。(GitHub)
変更点を実務視点で整理すると、次の3点です。
| 確認項目 | 変更内容 | 実務上の見方 |
|---|---|---|
| エンドポイントバージョン | 2026033100 から 2026043000 に更新 | 2026年4月分のworldwideエンドポイントデータとして扱う |
| 生成日時 | 2026-04-30 12:44:41.7054 に更新 | 自動生成ファイルの更新タイミングを確認する材料になる |
| SharePoint / OneDriveの表 | ID 33の行が削除 | Hybrid Search関連の許可リストや監視設定に残っていないか確認する |
特に重要なのは、削除されたID 33です。差分上では、SharePoint Hybrid Search - Endpoint to SearchContentService where the hybrid crawler feeds documents という説明を持つエントリが削除されています。対象アドレスは *.search.production.emea.trafficmanager.net と *.search.production.us.trafficmanager.net、ポートは TCP 443 でした。(GitHub)
これはGitHubの仕様変更ではなくMicrosoft 365エンドポイント更新
記事テーマに「GitHubの公式ドキュメント更新」とあるため誤解しやすいですが、今回のポイントはGitHub Actions、GitHub Enterprise、GitHub Copilotなどの仕様変更ではありません。
GitHubは、MicrosoftDocsがドキュメントを公開・管理している場所です。今回のコミットで更新されたのは、Microsoft 365の接続先URL、IPアドレス範囲、カテゴリ、ポートをまとめたドキュメントの一部です。Microsoft LearnのMicrosoft 365 URL/IPアドレス範囲ページでも、表示されているデータはRESTベースのWebサービスから生成されると説明されています。(Microsoft Learn)
したがって、開発者や管理者が取るべき行動は「GitHub側の設定を変える」ことではありません。確認すべきなのは、自社のネットワーク機器や運用スクリプトがMicrosoft 365エンドポイント更新に追随できているかです。
影響を受けやすい運用領域
今回の差分は小さいものの、Microsoft 365エンドポイントはファイアウォールやプロキシの許可リストに直結します。特に、手作業でURLやFQDNを登録している環境では、削除済みエンドポイントが残り続けることがあります。
影響を確認すべき主な領域は次のとおりです。
| 領域 | 確認すべき内容 | 放置した場合のリスク |
|---|---|---|
| ファイアウォール | 削除されたFQDNを許可リストに残していないか | 不要な許可ルールが残り、棚卸し時に判断しにくくなる |
| プロキシ | Microsoft 365向けのバイパス設定に旧エンドポイントが含まれていないか | ルール肥大化、誤判定、トラブル時の切り分け遅延 |
| PAC / WPAD | 直接接続またはプロキシ振り分けの条件に旧FQDNがないか | 想定外の経路選択や運用ルールの不整合 |
| SD-WAN | Microsoft 365カテゴリベースの自動設定が最新化されているか | 拠点ごとに異なる経路制御が発生する可能性 |
| 監視・SIEM | 旧エンドポイントへの通信を異常として扱う条件がないか | アラートノイズや調査工数の増加 |
| ExpressRoute関連設計 | ER列の扱いを自社設計と照合しているか | Internet接続が必要な通信を誤って閉じる可能性 |
Microsoftは、Microsoft 365ネットワークトラフィックを適切に識別し、必要に応じてファイアウォール、プロキシ、ブラウザーのプロキシ設定、ネットワーク検査のバイパスなどを組み合わせて最適化する考え方を示しています。(Microsoft Learn)
削除されたID 33をどう判断すべきか
今回の更新で最も実務的に見るべき点は、SharePoint Online and OneDrive for Business セクションからID 33が削除されたことです。現在のMicrosoft Learn上のSharePoint / OneDriveセクションでは、ID 31、32、35、36、37、39などが確認できますが、ID 33は表示されていません。(Microsoft Learn)
ただし、削除されたからといって、すぐに全環境で該当FQDNを遮断してよいとは限りません。次の順序で判断するのが安全です。
まず利用実態を確認する
*.search.production.emea.trafficmanager.net や *.search.production.us.trafficmanager.net に対する通信ログがあるかを確認します。特に、SharePoint Hybrid Search、オンプレミスSharePoint、Microsoft 365連携検索を利用している環境では慎重に見てください。
確認対象は次のログです。
- ファイアウォールの許可ログ、拒否ログ
- プロキシログ
- DNSクエリログ
- SD-WANのアプリケーション識別ログ
- Microsoft 365関連の接続監視ログ
- オンプレミスSharePointサーバーや検索関連サーバーの通信ログ
過去30日から90日程度のログを見て、実際に通信が発生していないかを確認します。月次処理や四半期処理でしか発生しない通信がある場合は、確認期間を短くしすぎないことが重要です。
次に「削除」か「即時遮断」かを分けて考える
ドキュメントから削除されたエンドポイントは、ネットワーク設定からも見直す対象です。しかし、運用では「許可リストから即削除」ではなく、段階的に扱う方が安全です。
| 状況 | 推奨対応 |
|---|---|
| 通信ログがなく、関連機能も使っていない | 次回のルール棚卸しで削除候補に入れる |
| 通信ログはないが、Hybrid Search構成が残っている | 構成管理台帳と実機設定を確認してから判断する |
| 通信ログがある | 送信元、頻度、用途を特定するまで遮断しない |
| ベンダー製品が自動で許可リストを管理している | 手動修正せず、製品側の更新反映状況を確認する |
| 監査上、許可ルールの根拠が必要 | GitHubコミットとMicrosoft Learnの現行一覧を証跡として残す |
削除済みエンドポイントを長期間残すと、セキュリティ監査やゼロトラスト移行時に「なぜ許可しているのか」を説明しにくくなります。一方で、業務影響を確認せずに遮断すると、古い構成や一部のハイブリッド機能で障害を起こす可能性があります。
Microsoft 365エンドポイントのカテゴリを確認する
Microsoft 365エンドポイントは、主に Optimize、Allow、Default のカテゴリで整理されています。Microsoft Learnでは、Category列がこの分類を示し、必須かどうかや、任意のエンドポイントをブロックした場合に失われる機能の注記も示されると説明されています。(Microsoft Learn)
カテゴリの見方は、運用判断に直結します。
| カテゴリ | 基本的な意味 | 運用上の扱い |
|---|---|---|
| Optimize | 高トラフィックまたは遅延に敏感な主要通信 | 可能であれば直接接続、VPN分割トンネル、検査バイパスの候補 |
| Allow | Microsoft 365利用に必要な通信 | 許可しつつ、必要に応じてプロキシやファイアウォールで適切に扱う |
| Default | 一般的な依存サービスや補助的な通信 | 通常のインターネット向け制御と整合させて管理する |
今回削除されたID 33は、差分上では Default、Optional、ERは No でした。つまり、Optimize系の主要トラフィックではなく、SharePoint Hybrid Searchに関する任意のエンドポイントとして扱われていた行です。(GitHub)
この性質から、今回の変更は「Microsoft 365全体の接続方式を大きく変える更新」というより、「特定用途の古い、または不要になった可能性のあるエンドポイントを棚卸しする更新」と捉えるのが現実的です。
ExpressRoute利用環境での確認ポイント
Microsoft 365エンドポイント表の ER 列は、Azure ExpressRoute for Microsoft 365でサポートされるエンドポイントセットかどうかを示します。Microsoft Learnでは、ERが No の場合、そのエンドポイントセットはExpressRouteでサポートされないと説明されています。(Microsoft Learn)
今回削除されたID 33はERが No だったため、ExpressRoute経由で処理すべきエンドポイントとして扱うものではありませんでした。ExpressRouteを使っている組織では、次の点を確認してください。
- Microsoft 365向けのルートフィルターに旧FQDNを前提とした例外がないか
- インターネット経由で到達すべき通信をExpressRoute側に寄せていないか
- ファイアウォールとプロキシの設定で、ER列を無視した包括的な許可ルールを作っていないか
- ネットワーク設計書に、削除済みID 33を根拠とする記述が残っていないか
ExpressRoute環境では、通信が通るかどうかだけでなく「どの経路を通すべき通信なのか」を明確にする必要があります。古いドキュメントの記述をもとに例外ルールを残していると、障害対応時に原因切り分けが難しくなります。
自動更新している環境と手動管理している環境の違い
Microsoftは、Microsoft 365 IP Address and URL Web Serviceを使って、Microsoft 365ネットワークトラフィックを識別し、変更を評価・構成・最新化しやすくする方法を提供しています。このWebサービスはRESTベースで、エンドポイント一覧や変更情報を取得できます。(Microsoft Learn)
このため、今回のような更新への対応は、自社がどの方式でエンドポイントを管理しているかによって変わります。
自動更新している場合
SD-WAN、SASE、プロキシ製品、ファイアウォール製品などがMicrosoft 365エンドポイント情報を自動取得している場合、まず製品側で最新バージョンが反映されているかを確認します。
確認すべきポイントは次のとおりです。
- 製品がMicrosoft 365 worldwideインスタンスを参照しているか
- エンドポイントバージョンが
2026043000相当になっているか - 旧ID 33のFQDNが自動ルールから削除されているか
- 例外設定として手動追加された旧FQDNがないか
- 変更反映後にSharePoint / OneDriveの利用でエラーが出ていないか
自動更新環境でありがちな失敗は、「製品の自動ルールは更新されたが、過去に作った手動例外だけが残る」ケースです。自動化しているから安心、ではなく、自動ルールと手動ルールの差分を確認してください。
手動管理している場合
手動でURLやFQDNを登録している環境では、今回の更新をルール棚卸しのきっかけにするべきです。Microsoftは、エンドポイント変更が定期的に発生するため、変更管理プロセスを採用することが重要だと説明しています。変更を管理しないと、新しいIPアドレスやURLの追加後にユーザーがブロックされたり、パフォーマンス低下が発生したりする可能性があります。(Microsoft Learn)
手動管理では、次の手順で進めると安全です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現行ルールを出力 | ファイアウォール、プロキシ、PAC、DNS制御の設定を一覧化 | 現行許可リスト |
| 公式差分と照合 | GitHubコミットとMicrosoft Learnの現行一覧を比較 | 削除候補・維持候補 |
| 通信ログを確認 | 旧FQDNへの実通信の有無を確認 | 利用実態メモ |
| 関係者に確認 | SharePoint、検索、Microsoft 365管理者に用途を確認 | 影響確認結果 |
| 段階的に反映 | 監視、テスト、削除の順で変更 | 変更記録 |
| 変更後に監視 | SharePoint / OneDrive / 検索関連のエラーを確認 | 事後確認ログ |
手動管理のポイントは、「公式から削除された」ことと「自社で不要になった」ことを分けて判断することです。公式差分は判断材料であり、実際の変更は自社環境の利用実態と合わせて決めます。
開発者が確認すべき点
今回の更新はネットワーク管理者向けに見えますが、開発者にも関係します。特に、SharePoint Online、OneDrive for Business、Microsoft Graph、社内ポータル、検索連携、ハイブリッド構成を扱う開発チームは、接続エラーをアプリケーション側の不具合と誤解しないように注意が必要です。
開発者が見るべきポイントは次のとおりです。
- SharePoint / OneDrive連携アプリで、特定FQDNを固定的に参照していないか
- 社内ネットワークからのみ失敗するAPI呼び出しがないか
- CI/CDや検証環境のネットワーク制御が本番と異なっていないか
- プロキシ設定やPACファイルの差で、開発端末と本番利用者の挙動が変わっていないか
- 障害調査時に、アプリログだけでなくネットワークログも確認できる体制があるか
Microsoft 365の接続問題は、コード、認証、DNS、プロキシ、ファイアウォール、経路制御が絡みます。開発チームだけで完結させず、クラウド管理者やネットワーク管理者と同じ変更情報を見て判断することが重要です。
ソリューションアーキテクトが見るべき設計上の論点
ソリューションアーキテクトは、今回の更新を単発のFQDN削除として見るだけでなく、Microsoft 365接続設計の成熟度を確認する材料として扱うべきです。
特に確認したいのは次の3点です。
エンドポイント変更を前提にした設計になっているか
Microsoft 365はSaaSであり、接続先は固定的なオンプレミスシステムとは異なります。Microsoft Learnでも、Microsoft 365はグローバルに分散したSaaSであり、最適なユーザー体験のためには近いMicrosoft 365サービス入口に接続できることが重要だと説明されています。(Microsoft Learn)
つまり、設計書にFQDNやIPアドレスを静的に書き込んで終わりにする運用は、長期的には破綻しやすくなります。Webサービス、ベンダー製品の自動連携、定期レビューを組み合わせた設計にするべきです。
セキュリティ検査とパフォーマンスのバランスを取れているか
Microsoftは、Microsoft 365向け通信に対してTLS復号、パケット検査、コンテンツフィルタリングなどを過度に適用すると、パフォーマンスやユーザー体験に影響する可能性があると説明しています。Requiredエンドポイントでは、Microsoft 365ドメインを明示的に許可し、TLS復号や深い検査を避ける考え方も示されています。(Microsoft Learn)
すべての通信を一律に検査する設計は分かりやすい一方で、Teams、SharePoint、OneDriveの体感品質を悪化させることがあります。カテゴリ別に、直接接続、検査バイパス、通常プロキシ経由を分ける設計が現実的です。
「古い許可ルール」を技術的負債として管理しているか
削除されたエンドポイントを残しても、すぐに障害が起きない場合があります。しかし、不要な許可ルールはセキュリティレビュー、監査、ゼロトラスト移行、SASE導入のたびに問題になります。
古い許可ルールは、次のような形で技術的負債になります。
- 許可理由を説明できない
- どの業務システムが使っているか分からない
- 削除してよいか誰も判断できない
- 監査時に例外扱いが増える
- 新しいセキュリティ製品への移行時に設定が膨らむ
今回のような公式ドキュメント更新は、単なるニュースではなく、こうした負債を減らすきっかけとして使えます。
Microsoft 365 IP Address and URL Web Serviceで確認する
公式ドキュメントの差分だけを見るのではなく、実際の運用ではMicrosoft 365 IP Address and URL Web Serviceを使うのが基本です。Microsoftは、ネットワーク機器やスクリプトでこのデータにアクセスする場合、Webサービスを直接参照するよう案内しています。(Microsoft Learn)
代表的な確認方法は次のとおりです。
| 目的 | 確認方法 |
|---|---|
| 現在のエンドポイント一覧を取得する | /endpoints/worldwide を参照する |
| 変更履歴を確認する | /changes/worldwide/{version} を参照する |
| 最新バージョンを確認する | /version/worldwide を参照する |
| CSV形式で扱う | format=CSV パラメータを使う |
| スクリプトで管理する | PowerShellなどで定期取得する |
Microsoft Learnでは、Webサービスの共通パラメータとして format=<JSON | CSV> や ClientRequestId=<guid> が説明されています。また、バージョン確認は頻繁に行いすぎず、最新バージョン確認は1時間に1回を超えないことが推奨されています。(Microsoft Learn)
運用では、GitHubコミットを「更新に気づく入口」として使い、最終的な設定反映はWebサービスから取得したデータに基づいて行うのが安全です。
変更管理で失敗しやすいポイント
Microsoft 365エンドポイント更新でよくある失敗は、差分の読み落としよりも、組織内の反映プロセスにあります。
旧ルールを削除できない
「念のため残す」が繰り返されると、許可リストが肥大化します。削除判断が難しい場合は、いきなり遮断するのではなく、ログ監視、影響確認、変更申請、段階削除の順で進めます。
本番だけ設定が古い
検証環境や一部拠点では最新化されていても、本番ネットワークや海外拠点だけ古い設定が残ることがあります。特にグローバル企業では、リージョンごとのネットワーク運用チームが別々に管理しているケースに注意が必要です。
PACファイルとファイアウォールの整合性が取れていない
PACファイルで直接接続にしていても、ファイアウォール側で許可されていなければ通信は失敗します。逆に、ファイアウォールで許可していても、PACファイルがプロキシ経由にしていると、期待した最適化効果が出ません。
Microsoftは、PACファイルを使う場合も、同じMicrosoft 365エンドポイントカテゴリのIPアドレスを取得し、ネットワーク境界ファイアウォールで許可する必要があると説明しています。(Microsoft Learn)
FQDNだけでVPN分割トンネルを設計する
VPN分割トンネルでは、Microsoft 365の文書化された専用IP範囲を中心に設計することが推奨されています。FQDNやAppIDベースの分割トンネルは、一部のVPNクライアントでは可能でも、主要シナリオを完全にカバーできない場合があるため、MicrosoftはMicrosoft 365 FQDNをVPN分割トンネル設定に使うことを推奨していません。(Microsoft Learn)
この点は、リモートワーク環境やSASE移行時に特に重要です。
今回の更新後に取るべきアクション
今回のGitHub公式ドキュメント更新を確認したら、次の順で対応してください。
| 優先度 | アクション | 対象者 |
|---|---|---|
| 高 | office-365-worldwide-endpoints.md の差分を確認し、ID 33削除を把握する | クラウド管理者、ネットワーク管理者 |
| 高 | Microsoft LearnまたはWeb Serviceで現行のworldwideエンドポイント一覧を確認する | クラウド管理者 |
| 高 | ファイアウォール、プロキシ、PAC、SD-WANの旧FQDN設定を棚卸しする | ネットワーク管理者 |
| 中 | SharePoint Hybrid Searchやオンプレミス連携の利用有無を確認する | SharePoint管理者 |
| 中 | 旧FQDNへの通信ログを確認する | セキュリティ運用、ネットワーク運用 |
| 中 | 削除候補ルールを変更管理プロセスに載せる | IT運用責任者 |
| 低 | 設計書、運用手順書、監査用資料を更新する | アーキテクト、技術リード |
特に、グローバル拠点を持つ企業では「日本本社の設定だけ更新済み」という状態を避ける必要があります。Microsoft 365 worldwideエンドポイントは、利用者の場所、拠点の出口、DNS解決、プロキシ経路によって体感品質が変わります。更新確認は本社ネットワークだけでなく、主要拠点やリモートアクセス環境も含めて行ってください。
まとめ：今回の更新は小さいが、運用棚卸しの価値は大きい
2026年4月30日のGitHub公式ドキュメント更新「Uploaded file: office-365-worldwide-endpoints.md – 2026-04-30 12:44:42.0870」は、Microsoft 365 worldwideエンドポイント情報の更新です。主な変更は、バージョンが 2026043000 に更新されたことと、SharePoint Online / OneDrive for Business のID 33、つまりSharePoint Hybrid Search関連エンドポイントが削除されたことです。(GitHub)
すぐに大規模な移行作業が必要とは限りません。しかし、ファイアウォール、プロキシ、PACファイル、SD-WAN、ExpressRoute、監視ルールに古い設定が残っていないかを確認する価値はあります。
次に取るべき行動は明確です。まず公式差分と現行のMicrosoft 365エンドポイント一覧を確認し、旧ID 33に関係するFQDNが自社環境に残っていないかを棚卸ししてください。そのうえで、通信ログと利用機能を確認し、不要なルールは変更管理プロセスに沿って段階的に削除します。これにより、Microsoft 365の接続品質を保ちながら、古い許可ルールを減らし、将来のセキュリティ運用や監査対応を軽くできます。
コメント