ベースラインとパフォーマンス履歴を使用して、Office 365 のパフォーマンスをチューニングする

接続の大まかな基礎になるビジネス システムと Office 365 との接続パフォーマンスを確認する簡単な方法をいくつか説明します。 クライアント コンピューターの接続のパフォーマンス履歴を調べることで、新たに発生する問題を事前に検出することができ、障害の予測と特定も行うことができます。

パフォーマンスの問題に対処しないユーザーでも、現在発生している問題が Office 365 のサービス インシデントではなく、パフォーマンスの問題であることをどのように把握するのか、などの一般的な質問の回答として、この記事を参考にすることができます。 長期的に優れたパフォーマンスを得るにはどのように計画すればよいでしょうか。 パフォーマンスをどのように監視すればよいでしょうか。 Office 365 の使用中にチームまたはクライアントでパフォーマンスが低下し、前述のいずれかの疑問を感じた場合は、この記事を参考にしてください。

重要: お客様のクライアントと Office 365 で現在、パフォーマンスの問題が発生していますか?パフォーマンスのトラブルシューティング Office 365 のプラン」で説明されている手順に従ってください。

Office 365 のパフォーマンスについて知っておく必要があること

Office 365 は、大容量の専用 Microsoft ネットワーク内で動作しています。このネットワークは自動機能だけでなく、実際の人間によって常時監視されています。 Office 365 クラウドを保守する役割の一部は、可能な場合、パフォーマンスの調整と合理化機能に組み込まれています。 Office 365 クラウドのクライアントはインターネット経由で接続する必要があるため、Office 365 サービスでもパフォーマンスを継続的に微調整する必要があります。 パフォーマンスの向上は実際にはクラウド内に留まりません。クラウドが正常かつ俊敏に動作するように維持するには、多くの経験の積み重ねが必要です。 お客様の場所から Office 365 に接続するときにパフォーマンスの問題が発生している場合は、起動せずにサポート ケースを待つことをお勧めします。 起動する代わりに、「裏返し」で問題の調査を開始してください。 つまりネットワークの内側から Office 365 まで到達するという方法です。 Office 365 サポートのケースを開く前に、データを集めて、問題を調査するアクションを実行します。このような操作を行うと、問題を解決できる可能性があります。

重要: Office 365 の容量計画と容量の制限に注意してください。この情報がわかれば、パフォーマンスの問題を解決する近道になります。Office 365 サービスの説明は、このリンクから参照することができます。Office 365 サービスの説明を中心に考えて作業を行います。Office 365 のすべてのサービスにはリンクが用意されており、リンク元からサービスの説明ページに移動することができます。たとえば、SharePoint Online に標準で設定されている制限値を確認したい場合は、「SharePoint Online サービスの説明」をクリックして、「SharePoint Online の制限」のセクションを探します。

パフォーマンスは変動するものであり、パフォーマンスのトラブルシューティングとは、理想の値を実現して、理想の値を常に維持することではないと理解した上で、トラブルシューティングを実行してください (この目標を実現しようとすると、多くのユーザーへの導入や大規模なデータ移行などの、広い帯域幅を必要とする作業が非常に困難になります。必ず、パフォーマンスの影響度に対する計画を作成してください)。これでパフォーマンス目標の概要を把握できたと思いますが、パフォーマンスには多くの変動要素が関係しており、常に変化します。これがパフォーマンスの特性です。

パフォーマンスのトラブルシューティングとは、特定の目標を満たして、これらの数値を無限に維持することではなく、あらゆる変動要素を考慮して、既存のアクティビティを向上させることです。

それでは、パフォーマンスの問題とはどのようなものでしょうか?

最初に、現在発生している状況が本当にパフォーマンスの問題であり、サービス インシデントでないことを確認する必要があります。 Office 365 では、パフォーマンスの問題はサービス インシデントとは異なります。 この 2 つの違いを次に示します。

Office 365 サービスで問題が発生している場合がサービス インシデントです。 Office 365 管理センターの [現在の正常性] に赤または黄色のアイコンが表示された場合、Office 365 に接続しているクライアント コンピューターのパフォーマンスが遅くなっている可能性があります。 たとえば、[現在の正常性] で赤いアイコンが報告され、Exchange の横に [調査中] というメッセージが表示された場合、組織内の人から多くの電話を受け、Exchange Online を使用しているクライアント メールボックスのパフォーマンスが遅いというクレームを受ける可能性が高くなります。 この場合、Exchange Online のパフォーマンスは、サービス内の問題の影響を受けたに過ぎないと考えていいでしょう。

[サービスが復元されました] と示された Exchange を除き、すべてのワークロードに緑色のマークが付いている Office 365 正常性ダッシュボード

この時点で、Office 365 管理者は [現在の正常性] を確認し、次に [詳細と履歴を表示] を頻繁に確認して、システム上で実行されている保守の最新状況を確認してください。 [現在の正常性] ダッシュボードは、サービスに対する変更、およびその問題の最新情報を表示するように設計されています。 正常性の履歴に書き込まれたメモと説明は管理者から管理者を対象としたもので、影響度を推定しやすくするために、現在実行されている作業状況が常に通知されます。

Exchange Online サービスが回復したことと、その理由の説明が表示された Office 365 正常性ダッシュボードの画像。

サービス インシデントによってパフォーマンスが低下することはありますが、パフォーマンスの問題はサービス インシデントではありません。 パフォーマンスの問題では次のような状況が発生します。

  • パフォーマンスの問題は、Office 365 管理センターの [現在の正常性] での、サービスに関するレポートの内容に関係なく発生します。

  • 以前は比較的シームレスに実行されていた動作が、完了するまでに時間がかかるようになったり、完了しなくなったりします。

  • また、問題を再現できます。あるいは少なくとも正しい手順を知っていれば、同じ状況を発生させることができます。

  • 問題が断続的に発生する場合でも、何らかのパターンが存在します。たとえば、午前 10 時までは Office 365 にアクセスできないという電話が多くかかってきても、お昼近くになると、かかってこなくなるなどがその一例です。

これは身近な問題で、しょっちゅう体験している人もいるかもしれません。 パフォーマンスの問題であることを確認できたら、「次に何をしたらいいか」ということが問題になります。これから、この問題を正確に決定するための方法について説明します。

パフォーマンスの問題を定義してテストする方法

多くの場合、パフォーマンスの問題は時間の経過に伴って発生します。このため、実際の問題を定義するのが難しい場合があります。問題のステートメントを適切に作成し、問題のコンテキストを把握し、繰り返し実施できるテスト手順を用意して、問題を解決する必要があります。そうでないと、自分に過失がないのに責任を取らされる可能性があります。次に、十分な情報が記載されていない問題のステートメントの例を挙げて、その理由を説明します。

  • 受信トレイから予定表への切り替えが、以前はあっという間に実行されていましたが、今では休憩中かと思うほど時間がかかります。 以前のように動作させることはできませんか?

  • SharePoint Online へのファイルのアップロードがずっと終わりません。 午後になるとパフォーマンスが遅くなりますが、その他の時間帯は高速です。なぜでしょうか? 高速に動作させることはできませんか?

上記の問題のステートメントには、大きな課題がいくつかあります。 特に、対処が必要なあいまいな点が多くあります。 たとえば、

  • 受信トレイと予定表の切り替えが以前はノート PC でどのように動作していたのかが不明です。

  • 「高速に動作させることはできませんか」という場合の「高速」とは何でしょうか?

  • また、「ずっと」とはどの程度の期間でしょうか? 数秒、または数分でしょうか? あるいはユーザーが昼食に出かけて戻ってきてから、10 分後に終了したということでしょうか?

上記のすべてのステートメントでは、このような問題のステートメントでは、管理者やトラブルシューティングの担当者が多くの詳細情報を把握できないという点が考慮されていません。 たとえば問題が発生するのが、自宅での作業時にホーム ネットワークに接続している場合にのみ切り替えが低速になる、ローカル クライアントで RAM を大量に使用する複数のアプリケーションを実行する必要がある、以前のバージョンのオペレーティング システムを実行している、最近の更新プログラムを実行していない、などの状況下であるという情報です。

パフォーマンスの問題が報告された場合、収集が必要な多くの情報があります。 この情報収集は、問題の範囲の特定と呼ばれるプロセスの一部です。 範囲を特定するための基本的なリストを次に示します。このリストは、パフォーマンスの問題についての情報収集に使用できます。 このリストは完全なものではありませんが、独自のリストを作成するための出発点になります。

  • 問題が発生した日はいつですか? その時刻は何時ですか?

  • 使用していたクライアント コンピューターの種類は何ですか? そのクライアントをビジネス ネットワークにどのような方法で接続していましたか (VPN、有線、ワイヤレス)?

  • リモートで作業していましたか、オフィスにいましたか?

  • 別のコンピューターで同じ操作を実行した場合、動作は同じでしたか?

  • トラブルが発生した手順をたどり、実行した操作を書き留めます。

  • パフォーマンスの低下はどれくらいでしたか? 秒単位ですか、それとも分単位ですか?

  • 世界のどこにいますか?

上記の質問のいくつかは、他の質問と比べて意図がより明確です。 トラブルシューティングを行う人が問題を再現するために、正確な手順が必要なことは明白でしょう。 つまり、問題点を記録したり、それが解決済みであるかどうかをテストしたりする方法は、他にはありません。 質問の意図がわかりにくいのは、「問題が発生した日時はいつですか?」や「世界のどこにいますか?」などでしょう。これらの情報は組み合わせて使用できます。 ユーザーの作業時間によっては、数時間の時差で、社内ネットワークの一部で、保守作業が既に開始されている場合があります。 たとえば、企業にハイブリッド実装 (SharePoint Online とオンプレミスの SharePoint Server 2013 インスタンスの両方に照会を実行することが可能なハイブリッド SharePoint Search など) が導入されている場合、オンプレミス ファームで更新プログラムの適用が実行されている場合があります。 会社がクラウドに完全移行している場合、システム メンテナンスにはネットワーク ハードウェアの追加や取り外し、更新プログラムの会社全体のロールアウト、DNS の変更、その他のコア インフラストラクチャなどが含まれることがあります。

パフォーマンスの問題のトラブルシューティングは、犯罪現場のようなものです。証拠から結論を導き出すには、緻密によく目を配る必要があります。そのためには、証拠を集めて、問題の適切なステートメントを入手する必要があります。このステートメントには、コンピューターのコンテキスト、ユーザーのコンテキスト、問題の発生時期、パフォーマンスの問題が発生した正確な手順などが含まれる必要があります。この問題のステートメントは、メモ帳の一番上のページに書き留めて保持する必要があります。解決策を試した後、もう一度問題のステートメントを 1 つ 1 つ確認すると、実行したアクションによって問題が解決したかどうかをテストして、証明する手順を行ったことになります。この問題に関して、作業がいつ終了するかを知ることは非常に重要です。

良好だったときのパフォーマンスを把握していますか?

運が悪ければ、誰も知りません。 誰も数値を記録していません。 つまり、「Office 365 の受信トレイが表示されるまで何秒かかったか?」や「エグゼクティブが Lync Online 会議を開くまでどれくらいかかったか?」などの簡単な質問に誰も答えられないということです。これは多くの企業で一般的なシナリオです。

ここで欠けているのは、パフォーマンス ベースラインです。

ベースラインからパフォーマンスのコンテキストが提供されます。 企業のニーズに合わせて、ベースラインの取得頻度を変える必要があります。 大企業の場合、オペレーション チームはオンプレミス環境については既にベースラインを取得している可能性があります。 たとえば、月の第 1 月曜日にすべての Exchange サーバーにパッチを適用し、第 3 月曜日にすべての SharePoint サーバーにパッチを適用する場合、重要な機能が動作していることを証明するため、オペレーション チームはパッチ適用後に実行するタスクのリストとシナリオを用意しているでしょう。 たとえば、受信トレイを開いて、[送受信] をクリックし、フォルダーの更新を確認したり、SharePoint でサイトのメイン ページを参照し、企業の検索ページに移動して検索を実行し、結果を表示したりすることなどです。

使用しているアプリケーションが Office 365 の場合、取得可能な最も基本的なベースラインは、ネットワーク内のクライアント コンピューターから出口ポイント (社内ネットワークを離れて Office 365 に到達するポイント) までの時間 (ミリ秒) を測定することです。 調査、記録できる便利なベースラインを以下に示します。

  • クライアント コンピューターと出口ポイント (プロキシ サーバーなど) 間のデバイスを特定します。

    • 発生したパフォーマンス問題のコンテキスト (IP アドレス、デバイスの種類など) がわかるように、使用しているデバイスを詳細に把握しておく必要があります。

    • プロキシ サーバーは一般的な出口ポイントです。Web ブラウザーをチェックすると、どのプロキシ サーバーを使用するように設定されているかを確認することができます (設定されている場合)。

    • ネットワークの検出とマッピングを行えるサードパーティ製のツールがありますが、デバイスを知るための確実な方法は、ネットワーク チームのメンバーに質問することです。

  • インターネット サービス プロバイダー (ISP) を特定して連絡先情報をメモし、回線数や帯域幅を確認してください。

  • 会社内でクライアントと出口ポイント間のデバイス用リソースを確認してください。または、ネットワークの問題が発生した場合に連絡する緊急連絡先を確認してください。

ツールを使った簡単なテストで計算できるベースラインを次に示します。

  • クライアント コンピューターから出口ポイントまでの時間 (ミリ秒)

  • 出口ポイントから Office 365 までの時間 (ミリ秒)

  • 参照時に Office 365 の URL を解決するサーバーが世界のどこに設置されているか

  • ISP が DNS を解決するまでの時間 (ミリ秒)、パケット到達時の不整合性 (ネットワーク ジッター)、アップロード時間とダウンロード時間 (ミリ秒)

これらの手順の詳細な実施方法については、この後で説明します。

ベースラインとは何ですか?

パフォーマンスが低下すれば、その影響はわかりますが、パフォーマンス データの履歴を知らなければ、パフォーマンス低下の程度や時期についてのコンテキストを知ることはできません。 したがって、ベースラインがなければ、パズルを解くための重要な鍵がないことになります。つまりパズルの箱に描かれている完成図がないということです。 パフォーマンスのトラブルシューティングでは、比較するポイントが必要です。 シンプルなパフォーマンス ベースラインは、簡単に取得できます。 オペレーション チームの仕事は、スケジュールどおりにこのベースラインを実行することです。 たとえば、次のように接続されているとします。

クライアント、プロキシ、および Office 365 クラウドを表す基本的なネットワーク グラフィック

ネットワーク チームと協力してチェックした結果、会社からインターネットへの接続はプロキシ サーバー経由で行われており、クライアント コンピューターからクラウドに送信されるすべての要求がプロキシで処理されていることがわかりました。 この場合、仲介するすべてのデバイスを表示した、簡単な接続図を作成する必要があります。 ここで、クライアント、出口ポイント (自社ネットワークから離れてインターネットへ移動するポイント)、Office 365 クラウド間のパフォーマンスのテストに使用できるツールを挿入します。

クライアント、プロキシ、クラウドが接続された基本ネットワークと推奨ツールの PSPing、TraceTCP、ネットワーク トレース。

これらのオプションは [シンプル] と [拡張] として表示されます。これはパフォーマンス データの検出に必要な専門知識の量が異なるためです。 PsPing や TraceTCP などのコマンドライン ツールを実行する場合と比べて、ネットワークのトレースには非常に時間がかかります。 この 2 つのコマンドライン ツールを選んだ理由は、Office 365 がブロックする ICMP パケットを使用しないためと、クライアント コンピューターやプロキシ サーバー (アクセス権限がある場合) から送信されてから Office 365 に到達するまでの時間をミリ秒で表示できるためです。 1 台のコンピューターから別のコンピューターへの各ホップの実行終了時に、それぞれ時間値が生成されます。これは、ベースラインに最適です。 同じくらい重要なのは、これらのコマンドライン ツールで、ポート番号をコマンドに追加できることです。Office 365 ではポート 443 経由で通信が行われるため、これは便利です。このポートは Secure Sockets Layer と Transport Layer Security (SSL と TLS) によって使用されます。 ただし、状況によっては、他のサードパーティ ツールの方が優れたソリューションとなる場合もあります。 Microsoft はこれらのツールをすべてサポートしているわけではありませんが、何らかの理由で PsPing と TraceTCP が動作しない場合は、Netmon などのツールを使ってネットワーク トレースを実行してください。

勤務時間前、勤務中、勤務時間後にベースラインを取得できます。 つまり、最終的に次のようなフォルダー構造が構築されるということです。

実績データをフォルダーに入れて整理する方法を示した図。

また、ファイルの命名規則を選ぶこともできます。 以下にいくつか例を示します。

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

いろいろな命名規則がありますが、まず <dateTime><what's happening in the test> という形式を使うことをお勧めします。 ここできちんと処理しておけば、後で問題のトラブルシューティングを行う場合に非常に役立ちます。 後で、「8 日の金曜日にトレースを 2 回実行しましたが、パフォーマンスが良好な場合と不十分な場合があったため、この 2 つを比較できます」などと言うことができます。 これはトラブルシューティングに非常に役立ちます。

ベースラインの履歴を保持するためには、整理された方法が必要です。 この例では、シンプルな方法で 3 つのコマンドライン出力が生成され、結果がスクリーン ショットとして収集されますが、代わりにネットワーク キャプチャ ファイルを収集することもできます。 最適な方法を使用してください。 ベースラインの履歴を保存しておき、オンライン サービスの動作の変化に気がついた時点で、そのベースラインを参照してください。

テスト導入期間中にパフォーマンス データを収集する理由

Office 365 サービスのテスト導入期間は、ベースラインの作成開始に最適です。 使用している Office のユーザー数は、何千人、何十万人もいる場合や、5 人しかいない場合があります。しかし、少人数のユーザーでも、テストを実行してパフォーマンスの変動を測定できます。 大企業の場合、Office 365 をテスト導入している数百人のユーザーの代表的なサンプルを数千人のユーザーに当てはめることで、問題が発生する前に、発生する可能性のある場所を特定できます。

小規模企業の場合、導入によってすべてのユーザーが同時にサービスを開始し、テスト導入期間がなく、常にパフォーマンスが測定されます。このため、パフォーマンスが低下しているオペレーションのトラブルシューティングを行う必要がある担当者に、データを提示できます。 たとえば、以前は短時間で終了していた、それほど大きくないサイズのグラフィックのアップロード作業に、急に時間がかかるようになった場合などです。

ベースラインの収集方法

すべてのトラブルシューティング プランでは、少なくとも以下の項目を特定する必要があります。

  • 使用しているクライアント コンピューター (コンピューターやデバイスの種類、IP アドレス、問題が発生する操作)

  • クライアント コンピューターの場所 (たとえば、ユーザーはネットワークに VPN 接続して、リモートで操作しているのか、会社のイントラネットで操作しているのかなど)

  • クライアント コンピューターが使っているネットワークの出口 (ビジネス システムから ISP やインターネットにトラフィックが送信される場所)

ネットワークのレイアウトは、ネットワーク管理者から入手できます。 小規模ネットワークを使用している場合は、インターネットに接続されているデバイスを確認してください。レイアウトについて不明な点があれば、ISP に連絡してください。 参考用に、最終レイアウトのグラフィックを作成します。

このセクションは、シンプルなコマンドライン ツールを使った方法と、高度なツール オプションに分かれています。 最初にシンプルな方法を説明します。 ただし、パフォーマンスの問題が現在発生している場合は、高度な方法に移動して、パフォーマンス トラブルシューティングのアクション プラン例を試してみてください。

シンプルな方法

次に示すシンプルな方法の目的は、時間の経過に合わせて、シンプルなパフォーマンス ベースラインの取得、理解、適切な保存を行い、Office 365 のパフォーマンスを把握できるようにすることです。 以下は、前に示した非常にシンプルな図です。

クライアント、プロキシ、クラウドが接続された基本ネットワークと推奨ツールの PSPing、TraceTCP、ネットワーク トレース。

注記: 

  • このスクリーンショットには TraceTCP が含まれています。これは、要求の処理時間 (ミリ秒) と、要求が宛先に到達するまでのネットワーク ホップ (1 台のコンピューターから別のコンピューターへの接続) の実行回数を示すのに便利なツールであるためです。 TraceTCP を実行すると、ホップ中に使用されるサーバー名も表示できます。これは、サポート部門の Microsoft Office 365 のトラブルシューティング担当者にとって非常に役に立つことがあります。

  • 次に示すように、TraceTCP コマンドは非常に簡単に使用できます。

  • tracetcp.exe outlook.office365.com:443

  • コマンドでは、必ずポート番号を指定してください。

  • TraceTCP は無料でダウンロードできますが、Wincap に依存しています。Wincap は Netmon でもインストール、使用されるツールです。高度なメソッドのセクションでは、Microsoft でも Netmon を使用します。

複数のオフィスを所有している場合、それぞれの場所ごとに、クライアントからのデータ セットを保持する必要があります。 このテストでは待機時間が測定されます。この場合は、クライアントが Office 365 に要求を送信してから、Office 365 が要求に応答するまでの時間を表す数値になります。 このテストではクライアント コンピューターのドメイン内から送信された信号が、出口ポイントを経由して出力され、インターネットを経由して Office 365 に到達し、逆のルートをたどって戻ってくるまでのラウンドトリップを、自社ネットワーク内から測定します。

出口ポイント (この場合はプロキシ サーバー) を処理する方法はいくつかあります。 1 から 2 をトレースし、次に 2 から 3 をトレースしてから、数値 (ミリ秒) を加算して、ネットワークのエッジまでの最終合計値を取得できます。 また、Office 365 アドレスのプロキシを使わないように、接続を構成することもできます。 ファイアウォール、リバース プロキシ、またはこの 2 つの組み合わせを備えたより大規模なネットワークでは、多くの URL に対してトラフィックの通過を許可する例外を、プロキシ サーバーで設定することが必要な場合があります。 Office 365 で使われているエンドポイントのリストについては、「Office 365 の URL と IP アドレスの範囲」を参照してください。 認証プロキシがある場合、次の順番で例外をテストしてください。

  • ポート 80 と 443

  • TCP と HTTP

  • 以下の URL への送信接続:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

プロキシによる干渉や認証なしに、すべてのユーザーがこれらのアドレスに到達できる必要があります。 より小規模なネットワークでは、Web ブラウザーでプロキシ バイパス リストに上記の URL を追加してください。

Internet Explorer で上記の URL をプロキシ バイパス リストに追加するには、[ツール]、[インターネット オプション]、[接続]、[LAN 設定]、[詳細設定] の順に移動します。 [詳細設定] タブには、プロキシ サーバーとプロキシ サーバー ポートも表示されます。 [詳細設定] ボタンを使用できるようにするには、[LAN にプロキシ サーバーを使用する] チェックボックスをオンにすることが必要な場合があります。 [ローカル アドレスにはプロキシ サーバーを使用しない] がオンであることを確認することをお勧めします。 [詳細設定] をクリックすると、テキスト ボックスが表示されます。このテキスト ボックスに例外を入力できます。 上記のワイルドカード URL を、次のようにセミコロンで区切ります。

*.microsoftonline.com; *.sharepoint.com

プロキシを使わないように設定すると、Office 365 URL で直接 ping や PsPing を使用できるようになります。 次のステップは、outlook.office365.com への ping をテストすることです。 また、コマンドでポート番号を指定できる PsPing などのツールを使用している場合は、portal.microsoftonline.com:443 に対して PsPing を実行して、平均ラウンドトリップ時間 (ミリ秒) を確認してください。

ラウンドトリップ時間 (RTT) とは、HTTP 要求を outlook.office365.com などのサーバーに送信してから、要求の送信をサーバーが認識したことを確認する応答を取得するまでにかかる時間を測定した値です。 ラウンドトリップ時間は、RTT と省略されることもあります。 この値は比較的短い時間になります。

このテストを実行するには、Office 365 によってブロックされる ICMP パッケージを使わない PSPing などのツールを使う必要があります。

PsPing を使って、Office 365 の URL から全体的なラウンドトリップ時間 (ミリ秒単位) を直接取得する方法

  1. 次の手順に従って、管理者特権のコマンド プロンプトを実行します。

    1. [スタート] ボタンをクリックします。

    2. [プログラムとファイルの検索] ボックスに「cmd」と入力して、Ctrl + Shift + Enter を押します。

    3. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合は、必要な操作が表示されていることを確認して、[続行] をクリックします。

  2. ツール (この場合は PsPing) がインストールされているフォルダーに移動し、次の Office 365 の URL をテストします。

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      microsoft-my.sharepoint.com のポート 443 に対して実行された PSPing コマンド。

ポート番号 443 を必ず含めてください。 Office 365 は暗号化されたチャネル上で機能します。 ポート番号を指定せずに PsPing を実行すると、要求は失敗します。 短いリストで Ping を実行したら、ミリ秒単位の平均時間を見つけます。 この時間を記録します。

クライアントとプロキシの間で行われる往復 2.8 ミリ秒の PSPing をイラストで示した画像。

プロキシのバイパスについての詳しい知識がない状態で、順番に手順に従う場合は、最初にプロキシ サーバーの名前を知る必要があります。 Internet Explorer で、[ツール]、[インターネット オプション]、[接続]、[LAN の設定]、[詳細設定] の順にクリックします。 [詳細設定] タブに、プロキシ サーバーの一覧が表示されます。 次のタスクを実行し、コマンド プロンプトでプロキシ サーバーに対して Ping を実行します。

プロキシ サーバーに対して Ping を実行し、ステージ 1 から 2 のラウンド トリップ値 (ミリ秒単位) を取得するには

  1. 次の手順に従って、管理者特権のコマンド プロンプトを実行します。

    1. [スタート] ボタンをクリックします。

    2. [プログラムとファイルの検索] ボックスに「cmd」と入力して、Ctrl + Shift + Enter を押します。

    3. [ユーザー アカウント制御] ダイアログ ボックスが表示された場合は、必要な操作が表示されていることを確認して、[続行] をクリックします。

  2. ping <ブラウザーで使用するプロキシ サーバーの名前またはプロキシ サーバーの IP アドレス>」と入力して、Enter キーを押します。 PsPing または他のツールがインストールされている場合は、代わりにそのツールの使用を選ぶことができます。

    次のいずれかの例のようなコマンドを実行します。

    • ping ourproxy.ourdomain.industry.business.com

    • ping 155.55.121.55

    • ping ourproxy

    • psping ourproxy.ourdomain.industry.business.com:80

    • psping 155.55.121.55:80

    • psping ourproxy:80

  3. トレースによるテスト パケットの送信が停止されると、いくつかの平均時間の一覧が表示されます。これが求めている値です。プロンプトのスクリーン ショットを取得し、名前付けの規則に従って名前を付けて保存します。この時点で、図に値を入力しておくと役に立つ場合があります。

早朝にトレースを取得したために、クライアントがプロキシにすぐに接続できる (または出口サーバーがインターネットに接続されている) 場合があります。 この場合、次のような数値になります。

クライアントとプロキシ間のラウンド トリップ時間 (2.8 ミリ秒) を示す図。

クライアント コンピューターがプロキシ (出口) サーバーにアクセスできる数少ないクライアント コンピューターの 1 つである場合、リモートからそのコンピューターに接続して、そこから Office 365 URL に対してコマンド プロンプトで PsPing を実行して、次の一連のテストを実行します。 そのコンピューターにアクセスできない場合は、ネットワーク サポートに連絡してサポートを受けながら次の一連のテストを実行し、正確な数値を取得できます。 これが不可能な場合は、対象の Office 365 の URL に対する PsPing の値を取得し、プロキシ サーバーに対する PsPing または Ping の時間と比較します。

たとえば、クライアントから Office 365 URL までが 51.84 ミリ秒で、クライアントからプロキシ (または出口ポイント) までが 2.8 ミリ秒である場合、出口から Office 365 までは 49.04 ミリ秒になります。 同様に、ピーク時間帯のクライアントからプロキシへの PsPing が 12.25 ミリ秒で、クライアントから Office 365 URL までが 62.01 ミリ秒である場合、プロキシ出口から Office 365 URL までの平均値は 49.76 ミリ秒になります。

値を減算できるように、クライアントからクライアントの横のプロキシへと、Office 365 の Ping をミリ秒単位で表す追加グラフィック

トラブルシューティング時には、これらのベースラインを保持しているだけで役に立つ場合があります。 たとえば、プロキシまたは出口ポイントから Office 365 の URL までの待機時間が通常は約 3 から 7 ミリ秒 (その時間のネットワーク トラフィックの量によって異なる) の場合、直近の 3 回のクライアントからプロキシまたは出口までのベースラインが 45 ミリ秒の待機時間を示している場合は、何か問題が発生していると確信できます。

高度な方法

Office 365 に対するインターネット要求で何が起こっているかを知りたい場合は、ネットワーク トレースに関する詳しい知識を習得する必要があります。これらのトレースに使用するツールはどれでもかまいません。ネットワーク トラフィックをキャプチャしてフィルター処理できるツールであれば、HTTPWatch、Netmon、Message Analyzer、Wireshark、Fiddler、Developer Dashboard や、他の好きなツールを使用できます。このセクションは、これらの複数のツールを実行して問題をより完全に理解するのに役立ちます。テスト中に、一部のツールは、それ自体がプロキシとしても機能します。関連記事「パフォーマンスのトラブルシューティング Office 365 のプラン」では、Netmon 3.4HTTPWatchWireShark などのツールが使用されています。

パフォーマンスのベースラインの取得は、この方法の単純な部分であり、多くの手順は、パフォーマンスの問題のトラブルシューティングを行う場合も同じです。 より高度な方法でパフォーマンスのベースラインを作成する場合は、ネットワーク トレースを取得して保存する必要があります。 この記事のほとんどの例では SharePoint Online を使用しますが、実際に購読している Office 365 サービスでテストして記録するための一般的な作業のリストを作成する必要があります。 以下にベースラインの例を示します。

  • SPO のベースライン リスト - ステップ 1: SPO Web サイトのホーム ページを参照して、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン リスト - ステップ 2: エンタープライズ検索を使用して単語 (会社名など) を検索し、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン リスト - ステップ 3: SharePoint Online ドキュメント ライブラリに大きなファイルをアップロードして、ネットワーク トレースを実行します。 トレースを保存します。

  • SPO のベースライン リスト - ステップ 4: OneDrive Web サイトのホーム ページを参照して、ネットワーク トレースを実行します。 トレースを保存します。

このリストには、ユーザーが SharePoint Online に対して一般的に実行する最も重要な操作を含める必要があります。 最後のステップである、OneDrive for Business へのアクセスのトレースの実行には、SharePoint Online ホーム ページ (多くの場合、企業によってカスタマイズされます) と OneDrive for Business ホーム ページ (ほとんどカスタマイズされません) の負荷の比較が含まれます。 これは、SharePoint Online サイトの読み込みに時間がかかる場合に実行する非常に基本的なテストです。 この違いの記録をテストに組み込むことができます。

パフォーマンスの問題が発生中である場合、ステップの多くは、ベースラインを取得する場合と同じです。 ネットワーク トレースが重要になるため、次に重要なトレースを取得する方法を説明します。

パフォーマンスの問題をすぐに解決するには、パフォーマンスの問題が発生しているときにトレースを取得する必要があります。ログを収集できる適切なツールを用意する必要があり、さらにアクション プラン (つまり最善の情報を収集するために実行するトラブルシューティング アクションのリスト) が必要です。最初にテストの日時を記録し、時期がわかるフォルダーにファイルを保存できるようにします。次に、問題を発生させるステップ自体を絞り込みます。これは、テストに使用する正確なステップです。重要な基本: Outlook だけで問題が発生している場合は、1 つの Office 365 サービスでのみ発生している問題の現象を必ず記録してください。問題の範囲を絞り込むと、解決できる対象に集中的に取り組むことができます。

関連項目

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

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×