ほとんどのSharePoint障害はこうして発見されます：ヘルプデスクのチケット。経理部の誰かがドキュメントライブラリを開けず、その後3件のチケットが続き、管理チームが問題を確認する頃には、会社の半分がすでに影響を受けています。
ファームのサーバーはおそらくずっと「稼働中」でした。これがSharePoint Serverの罠です。単一ページの読み込みはIISのフロントエンド、認証チェーン、サービスアプリケーション、SQL Serverを横断します。これらの層のどれか一つが劣化していても、基本的な稼働確認はすべて正常を示します。
このガイドは、SharePointファームで実際に監視すべきもの、組み込みツールの限界、最初のチケットが上がる前に発火するアラートの設定方法、そして管理者が受け入れるSLAレポートへの監視データの変換方法を説明します。
なぜSharePointの問題はあなたに届く前にヘルプデスクに到達するのか
Pingとポートチェックは1つの質問に答えます：サーバーに到達できるか？SharePointはその質問では検知できない形で失敗します。
月曜朝のログインラッシュを考えてみてください。何百人もの社員が午前9時に認証し、ADFSサーバーが追いつかず、通常2秒かかるログインが40秒かかります。すべてのサーバーはpingに応答し、IISは200を返します。しかし誰もイントラネットにアクセスできず、チケットが発生します。
または、ゆっくりと進むバージョン：最大のコンテンツデータベースを格納するSQLボリュームのディスクレイテンシが1ヶ月かけて徐々に上昇。ページ読み込み時間が1秒から4秒に伸びますが、閾値は作動しません。動いた数値を監視していなかったからです。
どちらの場合もパターンは同じです。失敗している層は「サーバーは稼働中」と「ユーザーがドキュメントを受け取った」の間にあり、その中間地帯こそがSharePointサーバー監視がカバーすべき範囲です。
SharePointサーバーファームで監視すべき項目
数百のカウンターは必要ありません。ユーザーの問題を予測する短いリストを一貫して監視する必要があります。
| 層 | 監視項目 | 理由 |
|---|---|---|
| IISフロントエンド | リクエストキューの長さ、5xxエラー率、CPUおよびメモリ使用率、アプリプールのリサイクル | キューにたまるリクエストはファームが負荷に追いつけなくなっている最も早い兆候です。 |
| SQL Server | コンテンツデータベースボリュームのディスク読み書きレイテンシ、ブロッキング待機、トランザクションログの増大 | ほぼすべてのSharePoint操作はSQLで完結します。ここでディスクが遅ければすべてが遅くなります。 |
| 検索 | クロールの新鮮さ、クロールキューバックログ、クエリレイテンシ | 古い、または遅い検索は報告されるSharePointの苦情の中でも最も多く、静かに劣化します。 |
| タイマージョブ | 失敗したジョブ数、重要なジョブの最終実行時間 | 失敗したタイマージョブはワークフロー、プロファイル同期、使用状況報告を静かに破壊します。 |
| 分散キャッシュ | キャッシュホストのステータス（各サーバー）、AppFabricサービスの健全性 | ログイントークンとフィードはこちらにあり、1台のキャッシュホストの故障がファーム全体の症状を引き起こし追跡が困難です。 |
| 認証 | AD、ADFS、またはEntra IDを通るログインの往復時間 | 認証はファーム全体の単一障害点であり、サーバーカウンターではほとんど反映されません。 |
| ユーザー体験 | ログイン時間、主要サイトコレクションのページ読み込み時間、検索応答、ドキュメントのアップロード/ダウンロード | これらはユーザーが感じるものであり、SLAに書かれている用語です。 |
最後の行は多くのSharePoint監視設定がスキップするものです。サーバーカウンターはコンポーネントの負荷を示します。ユーープのように動作し、ログイン、ライブラリの開封、検索を行うチェックだけがファームが実際に機能しているかを伝えます。ファームに応じて、サービスアプリケーションプールやレガシーワークフローを利用している場合はWorkflow Managerも監視してください。
閾値を設定する前に、通常稼働週の各メトリックのベースラインを設定しましょう。CPU使用率70％は、正常時が40％か65％かで意味が異なります。
組み込みツールが検知するもの（と見逃すもの）
SharePoint Serverには本格的な監視機構が搭載されており、それを使うべきです。 Microsoftの監視ドキュメントは3つの主な要素を説明しています：
- Health Analyzerはルールベースのチェックをファーム構成や既知の障害状態に対して実行し、一部は自己修復可能です。
- Diagnostic（ULS）ログは詳細なトレースログを書き込み、原因追及時に役立ちます。
- 使用状況および健全性データ収集はリクエストとサービス統計を使用状況・ログデータベースに集約します。
System Centerを使うチームはSharePoint管理パックを追加し、イベント駆動のアラートを受け取ることができます。
しかしこれらすべてに共通するのは、ファーム内で動作しファームを報告することです。ロードバランサーが死んだノードにユーザーを振っている、ADFSエンドポイントの証明書が期限切れ、または支店からのページ読み込みに9秒かかっているなどは教えてくれません。Health Analyzerのルールもスケジュール実行で、日次や週次のため問題が検知されないまま次の実行まで放置されることがあります。
組み込みツールは監視戦略の内側の半分です。外側の半分はユーザーと同じ方法でSharePointにアプローチするチェックで補う必要があります。
ユーザーが実際に体験していることを監視する方法
外側の半分は合成監視です：スクリプト化されたチェックをスケジュールで実行し、本物のSharePoint操作を行います。SharePointファーム用の有用なスクリプトは以下の4つのステップを行います：
- ステップ1：ログイン。最小権限の専用監視アカウントを使い、完全な認証往復時間（SSOリダイレクト含む）を計測します。
- ステップ2：ページを読み込む。最もトラフィックの多いサイトコレクションやイントラネットのホームページを開き、HTMLレスポンスだけでなくリアルブラウザでのロード時間を記録します。
- ステップ3：検索を実行する。既知のドキュメントが返る検索語句でクエリを実行し、結果が返らなければチェックは失敗とします。これによりサーバー側のビューではユーザー問題と判断されないインデックス遅延を検知します。
- ステップ4：ドキュメントにアクセスする。テストファイルをライブラリから開くかダウンロードし、IIS、権限、SQLを経る完全経路を検証します。
Dotcom-MonitorではWebアプリケーション監視タスクとしてEveryStepスクリプティングで一度記録し、ユーザーのいる場所から再生します。インターネット公開またはハイブリッド展開ならユーザー地域の外部ノード、イントラネット限定ファームの場合はプライベートエージェントが内部ネットワークから同じスクリプトチェックを実行し、オンプレミス環境もユーザーレベル監視から逃れられません。
認証は回避ではなく計画が必要です。Entra ID（旧Azure AD）利用時は監視アカウントにMFAの代わりに許可済み監視IP範囲を切り替える条件付きアクセスポリシーを設定してください。アカウントの資格情報はボールトに保存し、通常のスケジュールでローテーションを行います。ADFSまたはEntra ID経由の認証であればログインステップはそのチェーン全体の健全性チェックも兼ねます。設定手順はADFSを使うアプリケーションの監視で解説しています。
Microsoft 365の一部を利用している場合も同じスクリプト手法が適用でき、Office 365合成監視ガイドで詳細を説明しています。Microsoftのサーバーは見えないため、ユーザーレベルチェックがSharePoint Onlineにおける唯一の測定手段です。
最初のチケットより先に鳴るアラートの設定方法
目標は特定のレースです：アラートが最初のヘルプデスクチケットより先に届かなければなりません。3つの実践で決まります。
ユーザーが感じる数値でアラートし、サーバー数値で診断する。ログイン時間が3倍に延びるか検索チェックが失敗したときにオンコールへ連絡してください。これがチケット生成の原因です。CPUやディスクのメトリックはアラートの注釈とし、主導させないでください。サーバーカウンターでのページングはチームが自分たちのアラートを無視する原因となります。効果的な開始ルールは：ログイン時間がベースラインの2倍を2回連続で超えた時、検索チェックが既知の結果を返さなかった時にページングすることです。
誰かを起こす前に検証する。1ヵ所の場所で1回だけ失敗するチェックはネットワークの一時的な途切れかもしれません。2ヵ所の場所、あるいは2回連続の失敗はインシデントです。ほとんどのアラート疲弊はこのステップを省くことに起因します。Dotcom-Monitorはアラート送信前に2つ目の場所で自動的に再チェックします。
頻度をSLAの数値に合わせる。99.9%の稼働率を達成する責任があるなら、月間約43分のダウンタイムが許容されます。15分毎のチェックだと1回発火する前にその予算の3分の1が消費される可能性があります。重要なフローは1～5分毎にユーザーレベルチェックを実行し、メンテナンスウィンドウは監視ツールでスケジュール設定し、パッチ夜間に誰も起こさず稼働記録も汚さないようにしてください。
SLA対比でSharePoint稼働率を報告する方法
ほとんどのSharePointチームは契約上あるいは社内のビジネス約束としてSLAに回答しています。上記監視設定は証拠を提供します：すべてのチェック、失敗、応答時間のタイムスタンプ付き記録で、ファーム自身のログとは独立しています。
この独立性が重要です。ファームのログが「正常」と記録し、ユーザーが「遅い」と感じるとき、ユーザー側からの3つ目の記録が議論を決着させます。また、Microsoftのサービスダッシュボードがハイブリッド環境で決して提供しないものを提供します：オンプレミスとクラウドの連続した単一の稼働率数値です。
月次SLAレポートには以下が必要です：目標に対する計測稼働率、スクリプト化されたユーザーフローの応答時間傾向、インシデントの一覧（期間と原因付き）。稼働率とSLAレポートはチェック履歴から直接これらの2つを生成し、必要な人にスケジュール配信します。傾向線はインシデント間に意味を持ちます。ページ読み込み時間が1秒から3秒へ四半期で徐々に遅くなるのは、チケット洪水になる前の初期容量警告となります。
あなたの環境に合うSharePoint監視ツールはどれか
問題のそれぞれの半分を監視する異なるツールがあるため、公平な比較は視点別で行います。
組み込みツール（無料）。Health Analyzer、ULSログ、使用状況データ収集。何を買うにしても使いましょう。ファームを正しく設定し、原因調査をサポートしますが、リアルタイムアラートやユーザー体験の測定はできません。
エージェントベースのインフラ監視。ManageEngine Applications ManagerやSolarWinds Server & Application Monitorはどちらもファームカウンター（データベースサイズ、タイマージョブ障害、IISとSQLの健全性、リクエスト毎秒）を収集するSharePointテンプレートを搭載します。PRTGはWindows、IIS、SQLの既成センサーを持ち、カスタムスクリプトで拡張可能です。上記表のサーバー側行に強く、Windows資産を既に管理していればファームに向けて運用可能。System Center環境ではSCOMのSharePoint管理パックが同じ範囲をカバー。
合成監視プラットフォーム。Dotcom-Monitorはユーザー側から動作します：スクリプト化ログイン、ページ読み込み、検索、ドキュメント操作を外部ノードやプライベートエージェントで行い、アラートやSLAレポートも組み込み。これは最初のチケットとのレースで勝ち、エージェントベースツールが構造的に検知できない問題も捕捉し、SharePoint Onlineにおいては唯一利用可能な層です。
この両者をペアリングするチームが多いです。重要なのは両方の半分が存在することです。それぞれの死角を相手がカバーするからです。
まとめ
SharePointサーバー監視は両方の半分をカバーするときに機能します：問題を説明するファームメトリックとそれらを検知するユーザーレベルチェック。痛みを予測する短いカウンターリストを監視し、重要な4つのユーザー操作をスクリプト化し、ユーザーの感覚に基づくアラートを検証付きで設定し、チェック履歴をSLAレポートにも活用しましょう。
