Office 365 エンドポイントを管理するManaging Office 365 endpoints

複数の異なる場所にオフィスを構えて WAN 接続を使用しているエンタープライズ組織のほとんどでは、Office 365 ネットワーク接続用の構成が必要です。Most enterprise organizations that have multiple office locations and a connecting WAN will need to need configuration for Office 365 network connectivity. 信頼できるすべての Office 365 ネットワーク要求をファイアウォール経由で直接送信し、追加的なパケット レベルの検査や処理をすべてバイパスすることで、ご使用のネットワークを最適化できます。You can optimize your network by sending all trusted Office 365 network requests directly through your firewall, bypassing all additional packet level inspection or processing. これにより、待機時間と境界の容量要件が削減されます。This reduces latency and your perimeter capacity requirements. Office 365 ネットワーク トラフィックを識別することは、ユーザーに最適なパフォーマンスを提供するための第一歩です。Identifying Office 365 network traffic is the first step in providing optimal performance for your users. Office 365 ネットワーク接続の詳細については、「Office 365 ネットワーク接続の原則」を参照してください。For more information about Office 365 network connectivity, see Office 365 Network Connectivity Principles.

Office 365 IP アドレスと URL の Web サービスを使用して、Office 365 ネットワーク エンドポイントおよびそれらに対する変更にアクセスすることを Microsoft ではお勧めします。Microsoft recommends you access the Office 365 network endpoints and changes to them using the Office 365 IP Address and URL Web Service.

重要な Office 365 ネットワーク トラフィックをどのように管理するかにかかわらず、Office 365 ではインターネット接続が必要です。Regardless of how you manage vital Office 365 network traffic, Office 365 requires Internet connectivity. 接続が必要なその他のネットワーク エンドポイントは、「Office 365 IP アドレスと URL Web サービスに含まれないその他のエンドポイント」に記載されています。Other network endpoints where connectivity is required are listed at Additional endpoints not included in the Office 365 IP Address and URL Web service.

Office 365 ネットワーク エンドポイントの使用方法は、エンタープライズ組織のネットワーク アーキテクチャによって決まります。この記事では、エンタープライズ ネットワーク アーキテクチャを Office 365 IP アドレスおよび URL と統合するためのいくつかの方法を概説しています。信頼できるネットワーク要求を選択するための最も簡単な方法は、各オフィスの所在地で Office 365 の自動構成をサポートする SDWAN デバイスを使用することです。How you use the Office 365 network endpoints will depend on your enterprise organization network architecture. This article outlines several ways that enterprise network architectures can integrate with Office 365 IP addresses and URLs. The easiest way to choose which network requests to trust is to use SDWAN devices that support automated Office 365 configuration at each of your office locations.

重要な Office 365 ネットワーク トラフィックのローカル ブランチ送信用 SDWANSDWAN for local branch egress of vital Office 365 network traffic

各ブランチ オフィスの所在地で、Office 365 の最適化カテゴリのエンドポイント、または最適化および許可カテゴリのエンドポイントへのトラフィックを直接 Microsoft のネットワークにルーティングするように構成されている SDWAN デバイスを提供できます。その他のネットワーク トラフィック (オンプレミス データセンター トラフィック、一般的なインターネット Web サイトのトラフィック、および Office 365 の既定カテゴリのエンドポイントに対するトラフィックなど) は、より強固なネットワーク境界を持つ別の場所に送信されます。At each branch office location, you can provide an SDWAN device that is configured to route traffic for Office 365 Optimize category of endpoints, or Optimize and Allow categories, directly to Microsoft's network. Other network traffic including on-premises datacenter traffic, general Internet web sites traffic, and traffic to Office 365 Default category endpoints is sent to another location where you have a more substantial network perimeter.

Microsoft は SDWAN のプロバイダーと協力し、自動構成を可能にしています。詳細については、「Office 365 ネットワーク パートナー プログラム」を参照してください。Microsoft is working with SDWAN providers to enable automated configuration. For more information, see Office 365 Networking Partner Program.

重要な Office 365 トラフィックの直接ルーティング用 PAC ファイルの使用Use a PAC file for direct routing of vital Office 365 traffic

PAC または WPAD ファイルを使用して、Office 365 と関連付けられているが、IP アドレスを持たないネットワーク要求を管理します。プロキシまたは境界デバイスを介して送信される一般的なネットワーク要求は、待機時間を増大させます。SSL の中断と検査によって待機時間が最長になる一方、プロキシ認証や評価の検索などのその他のサービスは、パフォーマンスとユーザー エクスペリエンスを低下させます。また、これらの境界ネットワーク デバイスには、すべてのネットワーク接続要求を処理するために十分な容量が必要です。直接の Office 365 ネットワーク要求のために、プロキシまたは検査デバイスをバイパスすることをお勧めします。Use PAC or WPAD files to manage network requests that are associated with Office 365 but don't have an IP address. Typical network requests that are sent through a proxy or perimeter device increase latency. While SSL Break and Inspect creates the largest latency, other services such as proxy authentication and reputation lookup can cause poor performance and a bad user experience. Additionally, these perimeter network devices need enough capacity to process all of the network connection requests. We recommend bypassing your proxy or inspection devices for direct Office 365 network requests.

PowerShell Gallery の Get-PacFile は、Office 365 IP アドレスと URL Web サービスから最新のネットワーク エンドポイントを読み取り、サンプル PAC ファイルを作成する PowerShell スクリプトです。このスクリプトを変更して、既存の PAC ファイル管理と統合させることができます。PowerShell Gallery Get-PacFile is a PowerShell script that reads the latest network endpoints from the Office 365 IP Address and URL Web service and creates a sample PAC file. You can modify the script so that it integrates with your existing PAC file management.

ファイアウォールとプロキシ経由で Office 365 に接続する。

図 1 - 単純なエンタープライズ ネットワーク境界Figure 1 - Simple enterprise network perimeter

PAC ファイルは、図 1 のポイント 1 で Web ブラウザーに展開されます。重要な Office 365 ネットワーク トラフィックの直接送信に PAC ファイルを使用する場合は、ご使用のネットワーク境界ファイアウォールでこれらの URL の背後にある IP アドレスへの接続も許可する必要があります。これには、PAC ファイルで指定されているものと同じ Office 365 エンドポイント カテゴリの IP アドレスを取得し、これらのアドレスに基づくファイアウォール ACL を作成します。ファイアウォールは、図 1 のポイント 3 です。The PAC file is deployed to web browsers at point 1 in Figure 1. When using a PAC file for direct egress of vital Office 365 network traffic, you also need to allow connectivity to the IP addresses behind these URLs on your network perimeter firewall. This is done by fetching the IP addresses for the same Office 365 endpoint categories as specified in the PAC file and creating firewall ACLs based on those addresses. The firewall is point 3 in Figure 1.

それとは別に、最適化カテゴリのエンドポイントの直接ルーティングのみを行う場合は、それ以降の処理をバイパスするために、プロキシ サーバーに送信する必要なすべての許可カテゴリのエンドポイントをプロキシ サーバーにリストする必要があります。たとえば、SSL の中断と検査およびプロキシ認証は、最適化および許可いずれのカテゴリのエンドポイントとも互換性がありません。プロキシ サーバーは、図 1 のポイント 2 です。Separately if you choose to only do direct routing for the Optimize category endpoints, any required Allow category endpoints that you send to the proxy server will need to be listed in the proxy server to bypass further processing. For example, SSL break and Inspect and Proxy Authentication are incompatible with both the Optimize and Allow category endpoints. The proxy server is point 2 in Figure 1.

一般的な構成は、プロキシ サーバーからの送信トラフィックをまったく処理せずに、プロキシ サーバーに到達する Office 365 ネットワーク トラフィックの宛先 IP アドレスを許可するというものです。SSL の中断と検査に関する問題の詳細については、「Office 365 トラフィックに対するサード パーティ製のネットワーク デバイスまたはソリューションの使用」を参照してください。The common configuration is to permit without processing all outbound traffic from the proxy server for the destination IP addresses for Office 365 network traffic that hits the proxy server. For information about issues with SSL Break and Inspect, see Using third-party network devices or solutions on Office 365 traffic.

Get-PacFile スクリプトでは、次の 2 つの型のPAC ファイルが生成されます。There are two types of PAC files that the Get-PacFile script will generate.

Type 説明Description
11
最適化エンドポイント トラフィックを直接送信し、その他すべてのトラフィックはプロキシ サーバーに送信します。Send Optimize endpoint traffic direct and everything else to the proxy server.
22
最適化および許可エンドポイント トラフィックを直接送信し、その他すべてのトラフィックはプロキシ サーバーに送信します。この型のファイルは、サポートされているすべての ExpressRoute for Office 365 トラフィックを ExpressRoute ネットワーク セグメントに送信し、その他すべてのトラフィックをプロキシ サーバーに送信するためにも使用できます。Send Optimize and Allow endpoint traffic direct and everything else to the proxy server. This type can also be used to send all supported ExpressRoute for Office 365 traffic to ExpressRoute network segments and everything else to the proxy server.

PowerShell スクリプトを呼び出す簡単な例を次に示します。Here's a simple example of calling the PowerShell script:

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

スクリプトに渡すことができるいくつかのパラメーターがあります。There are a number of parameters you can pass to the script:

パラメーターParameter 説明Description
ClientRequestIdClientRequestId
このパラメーターは必須です。呼び出しを行うクライアント マシンを表す GUID で、Web サービスに渡されます。This is required and is a GUID passed to the web service that represents the client machine making the call.
InstanceInstance
既定で Worldwide に設定される Office 365 サービス インスタンスです。これも Web サービスに渡されます。The Office 365 service instance which defaults to Worldwide. Also passed to the web service.
TenantNameTenantName
ご使用の Office 365 テナント名。Web サービスに渡され、一部の Office 365 URL で置換可能なパラメーターとして使用されます。Your Office 365 tenant name. Passed to the web service and used as a replaceable parameter in some Office 365 URLs.
TypeType
生成するプロキシ PAC ファイルの型。The type of the proxy PAC file that you want to generate.

追加のパラメーターを指定して PowerShell スクリプトを呼び出す別の例を、次に示します。Here's another example of calling the PowerShell script with additional parameters:

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

プロキシ サーバーによる Office 365 ネットワーク トラフィック処理のバイパスProxy server bypass processing of Office 365 network traffic

PAC ファイルを直接送信トラフィックに使用しない場合でも、プロキシ サーバーを構成して、ネットワーク境界での処理をバイパスすることをお勧めします。一部のプロキシ サーバー ベンダーでは、Office 365 ネットワーク パートナー プログラムで説明されているように、これが自動構成されています。Where PAC files are not used for direct outbound traffic, you still want to bypass processing on your network perimeter by configuring your proxy server. Some proxy server vendors have enabled automated configuration of this as described in the Office 365 Networking Partner Program.

この構成を手動で行う場合は、Office 365 IP アドレスと URL の Web サービスから最適化および許可カテゴリのエンドポイント データを取得して、これらの処理をバイパスするようにプロキシ サーバーを構成する必要があります。最適化および許可カテゴリのエンドポイントに対しては、SSL 中断と検査およびプロキシ認証を行わないようにすることが重要です。If you are doing this manually you will need to get the Optimize and Allow endpoint category data from the Office 365 IP Address and URL Web Service and configure your proxy server to bypass processing for these. It is important to avoid SSL Break and Inspect and Proxy Authentication for the Optimize and Allow category endpoints.

Office 365 IP アドレスと URL の変更管理Change management for Office 365 IP addresses and URLs

ご使用のネットワーク境界に適切な構成を選択することに加え、Office 365 エンドポイントの変更管理プロセスを採用することも重要です。これらのエンドポイントは定期的に変更され、変更を管理しない場合、新しい IP アドレスや URL の追加後に、ユーザーのブロックやパフォーマンスの低下が引き起こされる可能性があります。In addition to selecting appropriate configuration for your network perimeter, it is critical that you adopt a change management process for Office 365 endpoints. These endpoints change regularly and if you do not manage the changes, you can end up with users blocked or with poor performance after a new IP address or URL is added.

Office 365 IP アドレスと URL の変更は通常、各月の末日近くに公開されます。場合によっては、運用、サポート、またはセキュリティ上の必要により、このスケジュール外に変更が公開されることもあります。Changes to the Office 365 IP addresses and URLs are usually published near the last day of each month. Sometimes a change will be published outside of that schedule due to operational, support, or security requirements.

IP アドレスまたは URL が追加されたために、ユーザーによる対応が必要な変更が公開された場合は、30 日前 (変更が公開された時点から、そのエンドポイントで Office 365 サービスが有効になるまでの期間) の通知がユーザーに送信されます。Microsoft ではこの通知期間を確保するよう努めていますが、運用、サポート、またはセキュリティ上の必要性によって、常に確保できるとは限りません。接続を保持するために即時の対応が不要な変更 (IP アドレスまたは URL の削除や、重要度の低い変更など) の場合、事前通知はありません。提供する通知の型にかかわらず、各変更がサービスで有効になる予定日を記載します。When a change is published that requires you to act because an IP address or URL was added, you should expect to receive 30 days notice from the time we publish the change until there is an Office 365 service on that endpoint. Although we aim for this notification period, it may not always be possible due to operational, support, or security requirements. Changes that do not require immediate action to maintain connectivity, such as removed IP addresses or URLs or less significant changes, do not include advance notification. Regardless of what notification is provided, we list the expected service active date for each change.

Web サービスを使用した変更通知Change notification using the Web Service

Office 365 IP アドレスと URL Web サービスを使用して、変更通知を取得できます。1 時間に 1 回 /version Web メソッドを呼び出して、Office 365 に接続するために使用しているエンドポイントのバージョンを確認することをお勧めします。使用中のバージョンと比べて、このバージョンが変更されている場合は、/endpoints Web メソッドから最新のエンドポイント データを取得する必要があります。また、必要に応じて、/changes Web メソッドから差分も取得します。検出されたバージョンに変更がない場合は、/endpoints および /changes Web メソッドを呼び出す必要はありません。You can use the Office 365 IP Address and URL Web Service to get change notification. We recommend you call the /version web method once an hour to check the version of the endpoints that you are using to connect to Office 365. If this version changes when compared to the version that you have in use, then you should get the latest endpoint data from the /endpoints web method and optionally get the differences from the /changes web method. It is not necessary to call the /endpoints or /changes web methods if there has not been any change to the version you found.

詳細については、「Office 365 IP アドレスと URL の Web サービス」を参照してください。For more information, see Office 365 IP Address and URL Web Service.

RSS フィードを使用した変更通知Change notification using RSS feeds

Office 365 IP アドレスと URL の Web サービスでは、Outlook で登録できる RSS フィードが提供されます。Office 365 サービス インスタンス固有の各ページに、IP アドレスと URL の RSS URL へのリンクがあります。詳細については、「Office 365 IP アドレスと URL の Web サービス」を参照してください。The Office 365 IP Address and URL Web Service provides an RSS feed that you can subscribe to in Outlook. There are links to the RSS URLs on each of the Office 365 service instance-specific pages for the IP addresses and URLs. For more information, see Office 365 IP Address and URL Web Service.

Microsoft Flow を使用した変更通知および承認確認Change notification and approval review using Microsoft Flow

毎月行われるネットワーク エンドポイントの変更を手動で処理する必要がある方もいらっしゃるでしょう。Microsoft Flow を使用すれば、Office 365 のネットワーク エンドポイントに変更があったときに、電子メールで通知し、必要に応じて、変更の承認プロセスを実行するフローを作成できます。確認が完了したら、ファイアウォールとプロキシ サーバーの管理チームに、自動的に電子メールで変更を通知するように設定できます。We understand that you might still require manual processing for network endpoint changes that come through each month. You can use Microsoft Flow to create a flow that notifies you by email and optionally runs an approval process for changes when Office 365 network endpoints have changes. Once review is completed, you can have the flow automatically email the changes to your firewall and proxy server management team.

Microsoft Flow のサンプルおよびテンプレートの詳細については、「Microsoft Flow を使用して、Office 365 IP アドレスや URL への変更のメール通知を受け取る」を参照してください。For information about a Microsoft Flow sample and template, see Use Microsoft Flow to receive an email for changes to Office 365 IP addresses and URLs.

Office 365 のネットワーク エンドポイントについてよく寄せられる質問Office 365 network endpoints FAQ

Office 365 の接続についてよく寄せられる管理者の質問です。Frequently-asked administrator questions about Office 365 connectivity:

質問を送信するにはどうすればよいですか?How do I submit a question?

下部のリンクをクリックして、記事が役に立ったかどうかを示し、追加の質問を送信してください。Microsoft は皆様からのフィードバックを確認し、よく寄せられる質問でここの質問を更新しています。Click the link at the bottom to indicate if the article was helpful or not and submit any additional questions. We monitor the feedback and update the questions here with the most frequently asked.

テナントの場所を確認するにはどうすればよいですか?How do I determine the location of my tenant?

テナントの場所は、Microsoft のデータセンター マップを使用して最適な場所が決定されます。Tenant location is best determined using our datacenter map.

私は Microsoft と適切にピアリングされていますか?Am I peering appropriately with Microsoft?

ピアリング場所の詳細については、Microsoft とのピアリングのページを参照してください。Peering locations are described in more detail in peering with Microsoft.

世界中に 2,500 を超える ISP ピアリング リレーションシップと 70 を超えるポイントがあるため、ユーザーのネットワークから Microsoft のネットワークへの接続はシームレスであるはずです。数分あれば、ISP のピアリング リレーションシップが最適であることを確認することができます。Microsoft ネットワークとのピアリング手順のよい例と悪い例については、こちらを参照してください。With over 2500 ISP peering relationships globally and 70 points of presence, getting from your network to ours should be seamless. It can't hurt to spend a few minutes making sure your ISP's peering relationship is the most optimal, here's a few examples of good and not so good peering hand-offs to our network.

公開済みの一覧に掲載されていない IP アドレスに対してネットワーク要求を受け取ります。それらの IP アドレスに対してアクセス権を付与する必要はありますか?I see network requests to IP addresses not on the published list, do I need to provide access to them?

Microsoft では、直接ルーティングする必要がある Office 365 サーバーの IP アドレスのみを公開しています。公開されている一覧には、ネットワーク要求が示されるすべての IP アドレスが記載されているわけではありません。ユーザーは、Microsoft とサード パーティが所有している未公開の IP アドレスに対するネットワーク要求も受け取ります。このような IP アドレスは、動的に生成または管理されているため、変更されたときに適時の通知を行うことができません。ご使用のファイアウォールで、これらのネットワーク要求の FQDN に基づいてアクセスを許可できない場合は、PAC または WPAD ファイルを使用して要求を管理してください。We only provide IP addresses for the Office 365 servers you should route directly to. This isn't a comprehensive list of all IP addresses you'll see network requests for. You will see network requests to Microsoft and third-party owned, unpublished, IP addresses. These IP addresses are dynamically generated or managed in a way that prevents timely notice when they change. If your firewall can't allow access based on the FQDNs for these network requests, use a PAC or WPAD file to manage the requests.

Office 365 と関連付けられた IP の詳細を確認するには、以下の手順を実行してください。See an IP associated with Office 365 that you want more information on?

  1. CIDR 計算ツールを使用して、より広く公開されている範囲に IP アドレスが含まれているかどうかを確認します。Check if the IP address is included in a larger published range using a CIDR calculator.
  2. whois クエリを使用して、パートナーが IP を所有しているかどうかを確認します。Microsoft 所有の場合は、内部パートナーの可能性があります。See if a partner owns the IP with a whois query. If it's Microsoft owned, it may be an internal partner.
  3. 証明書を確認し、ブラウザーで HTTPS://<IP_ADDRESS> を使用して IP アドレスに接続し、証明書に表示されるドメインを確認して、IP アドレスに関連付けられているドメインを把握します。Microsoft 所有の IP アドレスで、Office 365 の IP アドレス一覧に掲載されていない場合、その IP アドレスは、MSOCDN.NET や IP 情報が公開されていない他の Microsoft ドメインなど、Microsoft CDN に関連付けられている可能性があります。証明書のドメインが、Microsoft が IP アドレスの登録を主張しているドメインの場合は、お知らせください。Check the certificate, in a browser connect to the IP address using HTTPS://<IP_ADDRESS> , check the domains listed on the certificate to understand what domains are associated with the IP address. If it's a Microsoft owned IP address and not on the list of Office 365 IP addresses, it's likely the IP address is associated with a Microsoft CDN such as MSOCDN.NET or another Microsoft domain without published IP information. If you do find the domain on the certificate is one where we claim to list the IP address, please let us know.

一部の Office 365 URL が、DNS 内の A レコードではなく CNAME レコードを指しています。CNAME レコードはどのように扱えばよいでしょうか?Some Office 365 URLs point to CNAME records instead of A records in the DNS. What do I have to do with the CNAME records?

クライアント コンピューターがクラウド サービスに接続するには、1 つ以上の IP アドレスが含まれる DNS A レコードまたは AAAA レコードが必要です。Office 365 に含まれる一部の URL は、A レコードまたは AAAA レコードではなく CNAME レコードを示します。こうした CNAME レコードは中間レコードで、一連の処理の途中であるものもあります。最終的には、特定の IP アドレスの A レコードまたは AAAA レコードに必ず解決されます。たとえば、最終的に IP アドレス IP_1 に解決される以下の一連の DNS レコードについて考慮してみましょう。Client computers need a DNS A or AAAA record that includes one or more IP Address(s) to connect to a cloud service. Some URLs included in Office 365 show CNAME records instead of A or AAAA records. These CNAME records are intermediary and there may be several in a chain. They will always eventually resolve to an A or AAAA record for an IP Address. For example, consider the following series of DNS records, which ultimately resolves to the IP address IP_1:

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

これらの CNAME リダイレクトは DNS の通常の一部分であり、クライアント コンピューターとプロキシ サーバーに対して透過的です。負荷分散、コンテンツ配信ネットワーク、高可用性、サービス インシデントの軽減に使用されます。Microsoft はこうした中間 CNAME レコードを公開せず、任意の時点で変更する可能性があります。そのため、ご使用のプロキシ サーバーで許可されている方法で構成する必要はありません。These CNAME redirects are a normal part of the DNS and are transparent to the client computer and transparent to proxy servers. They are used for load balancing, content delivery networks, high availability, and service incident mitigation. Microsoft does not publish the intermediary CNAME records, they are subject to change at any time, and you should not need to configure them as allowed in your proxy server.

プロキシ サーバーは最初の URL (前述の例の場合、serviceA.office.com) を検証し、この URL が Office 365 の発行に含まれるようになります。プロキシ サーバーはこの URL の DNS を解決して特定の IP アドレスになるように要求し、IP_1 が戻されることになります。中間の CNAME リダイレクト レコードの検証は行いません。A proxy server validates the initial URL which in the above example is serviceA.office.com and this URL would be included in Office 365 publishing. The proxy server requests DNS resolution of that URL to an IP Address and will receive back IP_1. It does not validate the intermediary CNAME redirection records.

ハードコーディングされた構成や、間接 Office 365 FQDN に基づくホワイトリストの使用は推奨されておらず、Microsoft もサポートしていませんし、ユーザー接続の問題が生じる原因となることが分かっています。CNAME リダイレクトをブロックしたり、Office 365 DNS エントリを不適切に解決したりする DNS ソリューションは、DNS 再帰が有効な状態の DNS 条件付き転送 (直接使用される Office 365 FQDN がスコープ対象) を介して解決できます。多くのサード パーティのネットワーク境界製品では、Office 365 IP アドレスと URL の Web サービスを使用して、推奨されている Office 365 エンドポイント ホワイトリストを自社の構成にネイティブに統合しています。Hard-coded configurations or whitelisting based on indirect Office 365 FQDNs is not recommended, not supported by Microsoft, and is known to cause customer connectivity issues. DNS solutions that block on CNAME redirection, or that otherwise incorrectly resolve Office 365 DNS entries, can be solved via DNS conditional forwarding (scoped to directly used Office 365 FQDNs) with DNS recursion enabled. Many third party network perimeter products natively integrate recommended Office 365 endpoint whitelisting in their configuration using the Office 365 IP Address and URL Web service.

Microsoft ドメイン名に nsatc.net や akadns.net などの名前が表示されるのはなぜですか?Why do I see names such as nsatc.net or akadns.net in the Microsoft domain names?

Office 365 と他の Microsoft サービスは、Akamai や MarkMonitor などのいくつかのサードパーティ サービスを使用し、Office 365 の操作性を高めています。お客様の操作性を可能な限り高めるために、将来これらのサービスを変更する可能性があります。サード パーティ ドメインは、CDN などのコンテンツをホストする場合があります。また、地理的なトラフィック管理サービスなどのサービスをホストする場合があります。現在、次のようなサービスが使用されています:Office 365 and other Microsoft services use several third-party services such as Akamai and MarkMonitor to improve your Office 365 experience. To keep giving you the best experience possible, we may change these services in the future. Third party domains may host content, such as a CDN, or they may host a service, such as a geographical traffic management service. Some of the services currently in use include:

*.nsatc.net を含む要求が表示される場合、MarkMonitor が使用されています。このサービスは、ドメイン名の保護と、悪意のある動作に対して保護するための監視サービスを提供しています。MarkMonitor is in use when you see requests that include *.nsatc.net . This service provides domain name protection and monitoring to protect against malicious behavior.

*.exacttarget.com に対する要求が表示される場合、ExactTarget が使用されています。このサービスは、メール リンク管理と悪意のある動作に対する監視サービスを提供しています。ExactTarget is in use when you see requests to *.exacttarget.com . This service provides email link management and monitoring against malicious behavior.

次のいずれかの FQDN を含む要求が表示される場合、Akamai が使用されています。このサービスは、geo-DNS サービスとコンテンツ配信ネットワーク サービスを提供しています。Akamai is in use when you see requests that include one of the following FQDNs. This service offers geo-DNS and content delivery network services.

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

Office 365 への接続を最小限にする必要がありますI have to have the minimum connectivity possible for Office 365

Office 365 はインターネット上で機能するように構築された一連のサービスですから、信頼性と可用性が保証されるかどうかは、多数の標準インターネット サービスの可用性に基づいています。As Office 365 is a suite of services built to function over the internet, the reliability and availability promises are based on many standard internet services being available. 最新のインターネット サービスを使用するには DNS、CRL、CDN などの標準インターネット サービスに到達可能である必要がありますが、これとまったく同様に Office 365 を使用するにも標準インターネット サービスに到達可能である必要があります。For example, standard internet services such as DNS, CRL, and CDNs must be reachable to use Office 365 just as they must be reachable to use most modern internet services.

Office 365 スイートは、複数の主なサービス分野から構成されています。これらのサービス分野への接続は、選択的に有効にすることができます。また、すべてのサービス分野が依存し、常に必須である共通分野があります。The Office 365 suite is broken down into major service areas. These can be selectively enabled for connectivity and there is a Common area which is a dependency for all and is always required.

サービス分野Service Area 説明Description
ExchangeExchange
Exchange Online および Exchange Online ProtectionExchange Online and Exchange Online Protection
SharePointSharePoint
SharePoint Online と OneDrive for BusinessSharePoint Online and OneDrive for Business
Skype for Business Online および Microsoft TeamsSkype for Business Online and Microsoft Teams
Skype for Business および Microsoft TeamsSkype for Business and Microsoft Teams
共通Common
Office 365 Pro Plus、ブラウザー内の Office、Azure AD、その他の一般的なネットワークエンドポイントOffice 365 Pro Plus, Office in a browser, Azure AD, and other common network endpoints

基本的なインターネット サービスに加え、機能を統合するためにのみ使用されるサード パーティ サービスがあります。これらは統合のために必要ですが、Office 365 エンドポイントの記事ではオプションと示されています。オプションとは、エンドポイントにアクセスできなくても、サービスのコア機能は動作することを意味します。必須であるすべてのネットワーク エンドポイントでは、必須属性が true に設定されます。オプションのネットワーク エンドポイントでは、必須属性が false に設定され、通知属性によって、接続がブロックされた場合に失われる機能の詳細が示されます。In addition to basic internet services, there are third-party services that are only used to integrate functionality. While these are needed for integration, they're marked as optional in the Office 365 endpoints article which means core functionality of the service will continue to function if the endpoint isn't accessible. Any network endpoint which is required will have the required attribute set to true. Any network endpoint which is optional will have the required attribute set to false and the notes attribute will detail the missing functionality you should expect if connectivity is blocked.

Office 365 を使用しようとして、サードパーティ サービスにアクセスできなかった場合、この記事で必須またはオプションと記載されているすべての FQDN がプロキシとファイアウォールで許可されていることを確認しますIf you're trying to use Office 365 and are finding third party services aren't accessible you'll want to ensure all FQDNs marked required or optional in this article are allowed through the proxy and firewall.

Microsoft のコンシューマー サービスへのアクセスをブロックするにはどうすればよいですか?How do I block access to Microsoft's consumer services?

コンシューマー サービスへのアクセス制限はお客様の責任で行っていただく必要があります。Restricting access to our consumer services should be done at your own risk. コンシューマー サービスを確実にブロックする唯一の方法は、login.live.com FQDN へのアクセスを制限することです。The only reliable way to block consumer services is to restrict access to the login.live.com FQDN. この FQDN は、MSDN、TechNet などの非コンシューマー サービスを含む幅広いサービスに使用されます。This FQDN is used by a broad set of services including non-consumer services such as MSDN, TechNet, and others. また、この FQDN は Microsoft サポートの Secure File Exchange プログラムによっても使用され、Microsoft 製品のトラブルシューティングに役立つファイルを転送するために必要です。This FQDN is also used by Microsoft Support's Secure File Exchange program and is necessary to transfer files to facilitate troubleshooting for Microsoft products. この FQDN へのアクセスを制限すると、これらのサービスに関連するネットワーク要求に関するルールの例外を含める必要が生じる場合があります。Restricting access to this FQDN may result in the need to also include exceptions to the rule for network requests associated with these services.

ただし、Microsoft コンシューマー サービスへのアクセスをブロックするだけでは、ネットワーク上の誰かが Office 365 テナントや他のサービスを使用して情報を入手することを防ぐことはできません。Keep in mind that blocking access to the Microsoft consumer services alone won't prevent the ability for someone on your network to exfiltrate information using an Office 365 tenant or other service.

Office 365 IP アドレスと URL の Web サービスOffice 365 IP Address and URL Web service

Microsoft Azure データ センターの IP 範囲Microsoft Azure Datacenter IP Ranges

Microsoft パブリック IP スペースMicrosoft Public IP Space

Microsoft Intune のネットワーク インフラストラクチャの要件Network infrastructure requirements for Microsoft Intune

ExpressRoute と Power BIExpressRoute and Power BI

Office 365 の URL と IP アドレスの範囲Office 365 URLs and IP address ranges

Office 365 向け ExpressRoute の管理Managing ExpressRoute for Office 365 connectivity

Office 365 ネットワーク接続の原則Office 365 Network Connectivity Principles