Webサイト監視の月次レポートは、「対象期間と監視条件」「今月の監視結果」「障害・復旧の概要」「前月からの変化」「未計測や判断できない範囲」「翌月の改善対応」をセットでまとめると、運営責任者や顧客に現状を伝えやすくなります。チェック成功率だけを並べるより、何が起き、何を確認し、次に何をするのかまで一続きで報告することが重要です。
例えば「チェック成功率99.79％、失敗6回」と記載しても、期間内に測定が抜けたのか、どのURLに影響したのか、何が未対応なのかは分かりません。失敗の回数・障害として扱った事象の件数・実際の停止時間は異なる数字です。外部監視の観測時刻だけで停止開始から復旧までの正確な時間を断定しないようにします。
この記事では、Webサイト運営担当者・制作会社・保守管理者が毎月作成する定期報告に限定して、必要な項目、集計手順、前月比較の方法、架空の月次レポート見本、提出前チェック表を説明します。稼働率の数値計算、個々の監視履歴の読み方、障害発生直後の連絡手順は別の内容とし、ここでは1か月分の情報を誤解なく報告書にまとめる実務に集中します。
Webサイト監視の月次レポートに必要な8つの報告項目
月次レポートの目的は、1か月の監視状況を要点から把握し、次月の対応を判断できるようにすることです。表紙だけに稼働率を載せるのではなく、対象条件・失敗した事象・改善の予定までを一組に整理しましょう。
| 項目 | 報告する内容 | 見落としやすい点 |
|---|---|---|
| 1．対象と期間 | 対象サイト・URL・対象月・JSTなど | 集計期間・タイムゾーンが不明 |
| 2．監視条件 | 間隔・方法・地点・成功条件 | 何を成功としたか分からない |
| 3．監視結果 | 実行回数・成功・失敗・成功率 | チェック成功率を実稼働率と誤認 |
| 4．未計測 | 停止設定・欠測数・測定できない時間 | 欠測を自動的に正常扱い |
| 5．障害・復旧 | 事象ごとの確認時刻・影響・状態 | 失敗6回を障害6件と誤認 |
| 6．性能・証明書 | 平均・P95応答時間、SSL期限など | 観測した範囲を記載しない |
| 7．前月との比較 | 前月差と計測条件の変化 | 監視間隔の違いを無視 |
| 8．改善計画 | 対応項目・優先度・担当・期限 | 数字の報告だけで終わる |
1か月の結論を最初の数行で示す
管理者が最初に知りたいのは、今月のサイトがどうだったか、重大な未解決事項がないか、翌月に何を優先するかです。報告書の1ページ目では「観測したチェックの成功率」「確認した事象」「前月からの変化」「次の対応」を短くまとめます。
ただし結果が良好に見えても、監視停止中の欠測があれば別記します。「今月は障害が一切ありませんでした」という断定は、測定していない区間がある場合や未確認の利用者影響がある場合に誤解を生むため、何を観測したかに合わせて書いてください。
詳細データは要約を裏付ける根拠として整理する
本文には最も重要な数値と事象を記載し、詳細な監視履歴や変更記録は必要に応じて別紙・社内記録へまとめます。報告対象のURLが複数ある場合は、サイト別の結果を示したうえで、全体集計の分母を明記します。
個々のチェック結果をすべて貼り付ける必要はありません。報告書の読者が確認したいときに元データへたどれるよう、履歴の保存先、取得日時、対象期間、必要なアクセス権などを管理することが重要です。
月次レポートと障害発生直後の速報は用途が異なる
速報は今起きている問題や暫定対応、次回の連絡を伝えるためのものです。月次レポートは終了した期間の事実と傾向を整理し、複数の異常や改善策をまとめて振り返る資料です。
月次の障害欄へ「発生した」「確認した」「復旧が観測された」と記載する場合も、速報の送信時刻を障害の開始時刻に置き換えないでください。確定したことと推測を分け、重要な障害の原因分析は必要に応じて別資料へリンクします。
月次レポートの作り方を6つの手順で整理する
毎月同じ手順で作成すれば、記載漏れや比較条件の違いを減らせます。まず集計範囲を固定し、監視結果を収集して整合性を確認した後、例外・前月差・改善対応の順にまとめる方法が実務的です。
手順1：報告対象のサイトと集計期間を確定する
例えば「2026年9月1日00:00（JST）から10月1日00:00（JST）の直前まで」と期間を明記します。対象が一つの企業サイトなら代表URLを、複数サイトならサイト名と対象URLの一覧を記録します。対象期間内にサイトを追加・停止した場合も記録してください。
月ごとの日数が違うため、8月と9月を比べる際には期待チェック数が同じとは限りません。月次比較では総回数だけでなく、同じ条件のチェック成功割合などを確認します。
手順2：チェック回数・成功・失敗・欠測を収集する
定期監視の履歴から、実際に計測した回数、成功した回数、失敗した回数を取得します。計画された実行回数が判定できるなら、予定回数との差も調べます。監視停止・監視設定変更・データ収集不良の時間を別に記録します。
実行したチェックの成功と失敗を合計した数が実行件数に一致するか、日付やサイトが重複していないかを確認しましょう。未計測は成功にも失敗にも機械的に置き換えず、記録の根拠を残します。
手順3：障害と復旧の記録を事象単位に整理する
複数の失敗チェックが連続している場合、それらが一つの事象に関連する可能性があります。障害・復旧履歴に記録されたイベントの時刻と、個別チェックの時刻を照合して、事象IDごとにまとめます。
一つの障害中に4回チェックが失敗したら、失敗4回と障害1件は別の数です。実際の停止開始・復旧時刻は監視間隔の間に起き得るため、正確な停止時間を示す場合には別の根拠が必要です。
手順4：応答時間・SSL・必要な付随情報を確認する
平均応答時間だけでなく、遅い側のP95などが取得できる場合は、対象となる成功チェックや期間を明示して報告します。平均がほぼ変わらなくても、遅い側の応答だけ悪化している可能性があるためです。
SSL証明書の期限が近い場合や、DNS・転送先の変化が運用上重要な場合も記録します。ただし監視データで確認できたことと、サーバー内のCPUやアプリケーション処理の原因を混同しないでください。
手順5：前月と同じ指標・同じ定義で比較する
当月と前月の成功率、失敗回数、欠測、応答時間などを並べます。監視間隔・対象URL・観測地点・失敗の条件が変わっていたら、前月差に影響するため注記が必要です。
割合の差は「0.33％上昇」などと曖昧に書くより、「99.46％から99.79％へ、約0.33ポイント改善」と示すと誤解を減らせます。変化の理由は事実と仮説を分け、監視の数値だけから原因を断定しないでください。
手順6：今後の対応・担当・期限を記載し確認する
集計結果から必要な対応を選び、担当者、期限、確認方法を付けます。例えば「公開作業の手順を点検する」「監視停止の再開確認を徹底する」など、完了を確認できる行動へ落とし込みます。
Google SREの事後分析に関する公式資料でも、具体的な対応項目に責任者・優先度・完了条件を持たせる重要性が説明されています。月次報告では詳細な原因分析を全部書き直すより、結果と次の対応を読み手が追えることを優先します。
Webサイト監視の月次レポート記入例。架空の2026年9月分
ここからは架空の企業サイトを15分間隔で監視したという設定の月次レポート例です。実際のエンリンクの顧客データや自動出力を再現したものではありません。本文・数値・表は一つの説明例として整合させています。
| 報告項目 | 2026年9月（当月） | 2026年8月（前月） |
|---|---|---|
| 対象期間 | 9/1 00:00〜10/1 00:00（JST） | 8/1 00:00〜9/1 00:00（JST） |
| 対象URL | https://example.com/（説明用） | 同左 |
| 監視条件 | 15分間隔・同じ成功条件 | 15分間隔・同じ成功条件 |
| 予定チェック数 | 2,880回（30日間） | 2,976回（31日間） |
| 実行したチェック | 2,870回 | 2,964回 |
| 成功チェック | 2,864回 | 2,948回 |
| 失敗チェック | 6回 | 16回 |
| 未計測チェック | 10回 | 12回 |
| チェック成功率 | 99.79％ | 99.46％ |
| 平均応答時間（成功分） | 420ms | 460ms |
| P95応答時間（成功分） | 980ms | 1,100ms |
報告書の冒頭文は結果と留保条件を合わせる
記入例：「2026年9月の公開トップページの外部HTTP監視は、計2,870回の実行に対し成功2,864回、失敗6回で、実行チェックにおける成功率は99.79％でした。前月の99.46％より約0.33ポイント改善しました。予定チェック2,880回との差10回分は未計測として区別し、計画作業の記録と照合しています。」
この文章はあくまで外部HTTPチェックの結果を表します。24時間の全秒でWebサイトが利用できた割合を保証する稼働率ではありません。監視間隔の間に起きて終了した問題は、チェックに残らないことがあります。
予定・実行・成功・失敗・未計測は式で照合する
架空の条件として「15分ごとに毎日同じURLを1回確認する」と仮定すると、9月は30日×24時間×4回で2,880回が予定数です。実行2,870回のうち成功が2,864回、失敗が6回なので、2,864＋6＝2,870となります。予定との差は2,880－2,870＝10回です。
実行したチェックの成功率は2,864÷2,870×100で約99.79％です。監視設定が途中で変わる、予定チェックの定義が変わるなどの場合は、この単純な予定回数をそのまま使わず実際のスケジュールに合わせて修正してください。
前月との比較は割合と計測条件を併記する
前月の架空データは、予定2,976回、実行2,964回、成功2,948回、失敗16回、未計測12回です。チェック成功率は2,948÷2,964×100で約99.46％となり、当月の99.79％との差は約0.33ポイントです。
前月の方が31日と長いため、単純に「失敗回数が16回から6回へ減った」だけで評価を終えず、実行回数も含めて比較します。応答時間も計測方式や成功チェックの対象範囲が同じという説明用の前提で比較します。
平均420msとP95 980msが示すこと
この架空の例では成功チェックの応答時間の平均が前月460msから当月420ms、P95が前月1,100msから980msへ下がっています。平均値だけでなく遅い側の分布も見て、前月から変わった傾向を説明できます。
ただし、HTTP応答時間はブラウザーでの読み込み完了時間や利用者の操作時間と一致しません。またP95の定義、失敗チェックの除外条件、観測地点が違えば数字を単純比較すべきではありません。必要な根拠とともに記載します。
月次レポートでは失敗回数と障害件数を分けて報告する
6回失敗したというチェックの記録だけでは、Webサイトが6回停止したことにはなりません。連続した失敗が一つの事象に関係している場合もあるため、事象IDと最初・最後に観測した結果を整理します。
| 事象 | 最初に失敗を観測 | 最後に失敗を観測 | 次の成功を観測 | 失敗チェック |
|---|---|---|---|---|
| I-01 | 9/5 10:15 | 9/5 10:30 | 9/5 10:45 | 2回 |
| I-02 | 9/18 14:00 | 9/18 14:45 | 9/18 15:00 | 4回 |
| 合計 | 架空の2事象 | 失敗チェックは計6回 | 復旧確認はチェック時刻 | 6回 |
障害の発生数とチェック失敗数は異なる
この例では9月5日に2回、9月18日に4回の失敗チェックがあり、説明用の記録では二つの事象に整理しています。つまり「失敗6回」「記録上の事象2件」は別の数です。監視ツールの障害判定ロジックによっては事象の区切りも違う可能性があります。
必ず監視チェックの時刻と障害・復旧の判定履歴を照合してください。複数のURLで同じサーバー障害を同時に記録した場合、サイト別の件数を単純に足した合計も全体の障害件数とは限りません。
障害の開始・終了時刻を推定だけで断定しない
9月5日は10:15に初めて失敗が観測され、10:30にも失敗し、10:45のチェックで成功したという説明用の記録です。しかし実際の停止は10:15より前に始まった可能性があり、復旧も10:30と10:45の間のどこかだった可能性があります。
「30分間停止しました」と秒単位の正確さで書く根拠は、この三つのチェック結果だけでは不足します。必要ならサーバーログやアプリケーション記録、利用者からの報告を追加し、未確定の区間を分けて扱います。
原因が未確定なら調査中と記載する
月次報告の作成時点で障害の原因が特定できない場合、HTTP 503やタイムアウトなど観測した事実を書き、「原因は調査中」「変更履歴と照合する」と分けて記載します。単に発生時刻が近いだけで更新作業が原因と断定してはいけません。
Google SREのPostmortem Cultureでは、事実・影響・緩和・根本原因・再発防止の記録が重視されています。月次レポートには確定した要点と対応状況を載せ、詳しい技術分析は別の資料へ参照を置く方法が実務的です。
利用者への影響と監視上の異常は別に確認する
トップページへの外部チェックが失敗していても、実際の利用者が何人アクセスできなかったか、問い合わせや購入へどう影響したかは自動的には分かりません。公開の利用状況やアプリケーション側の記録が許可された範囲で得られれば、事象ごとの影響を別記します。
十分なデータがない場合は「利用者影響は未確認」と明記します。監視の数値だけから売上損失や問い合わせ件数の減少を捏造しないことが、読み手の信頼につながります。
未計測・メンテナンス・監視停止を正しく記載する
監視レポートでは、成功と失敗のほかに「測定できなかった」という状態が存在します。欠測を見落とすと実績の説明が過大になり、予定された作業で監視を停止した期間を正常稼働と誤解させるおそれがあります。
架空の10回の未計測は成功に含めない
上の架空データでは、9月の予定2,880回に対し実行2,870回で、10回が未計測です。説明用に9月12日02:00〜04:30（JST）を監視停止として記録した想定ですが、サイトそのものがその時間に停止していたかどうかは、監視結果だけでは分かりません。
報告書では、未計測の件数と理由、対象期間を示し、チェック成功率99.79％の分母には実際に判定した2,870回だけを使います。未計測分を成功に加える、失敗に加えるという操作は、明示した評価ルールがない限り行いません。
予定されたサイト停止と監視システムの欠測は別
サイト管理者が保守作業のため利用停止を予定していた場合でも、その期間をSLAやSLOから除外できるかは契約や社内の評価定義次第です。監視を止めたという事実と、Webサイトが利用できなかったという事実も同じではありません。
メンテナンス中の監視アラートでは、作業前・中・後の確認を解説しています。月次レポートでは、その運用記録から作業日時と影響範囲を引用し、決めつけずに扱います。
未計測を見つけたら理由・件数・影響を記録する
チェックが未実行だった背景は、監視の手動停止、収集システムの障害、設定変更、保存期間の制約などさまざまです。確認できる場合には理由を示し、不明なら不明と記載して調査項目にします。
AWS CloudWatchの公式資料は、アラームでデータ欠損をどう扱うかを明示的に設定する仕組みを説明しています。これはエンリンクの月次レポート機能を示すものではありませんが、欠測を正常扱いするかどうかが設計上の判断であることを理解する参考になります。
複数サイトで対象期間が異なる場合は集計を分ける
監視を開始した日が月の途中だったサイトと、1か月間すべて監視していたサイトの値を、同じ条件とみなして平均すると誤解を生む場合があります。サイト追加・退会・一時停止の時刻を記録し、実際に観測した範囲を示しましょう。
サイト別の成功率を単純平均する場合、実行件数の差によって全体の比率と一致しないことがあります。全体成功率を出すなら成功回数と実行回数を合計して計算し、サイト別の影響も見えるようにする必要があります。
前月比のグラフと応答時間で傾向を説明する
月次レポートでは「先月と比較して何が変わったか」が意思決定に役立ちます。ただし日数やチェック数が違う月同士を比べる場合、単純な失敗回数の増減だけで結論を出すのは避けます。
チェック成功率の前月差はポイントで示す
架空の例では8月99.46％から9月99.79％となり、約0.33ポイント改善しています。報告の表やグラフでは、同じ監視方法・対象URL・成功条件だったことを併記しましょう。
失敗チェックは16回から6回へ減りましたが、8月は31日、9月は30日という違いがあります。件数と割合を両方示せば、単に監視回数が少なかっただけなのか、比率として変化があったのかを読み分けられます。
平均だけでなくP95の変化も確認する
平均応答時間は460msから420ms、P95は1,100msから980msへ改善したという架空のデータです。この二つが同じ方向に動いているか、遅い側だけ目立って悪化していないかを確認すると、平均だけでは分からない傾向を説明できます。
ただしHTTPチェックが観測する待ち時間は、ブラウザーの描画時間やアプリケーション内部の処理時間とは違う場合があります。どの指標を比較しているかを記し、性能低下の原因を応答時間だけで断定しないようにします。
グラフには単位・期間・未計測を明示する
成功率の推移なら縦軸を％、応答時間の推移ならmsとし、観測日と対象URLを明記してください。集計できない日の点を0や100へ埋めると、実際にはない改善や悪化が見えることがあります。
例えば失敗6回を日別に配置する場合は、事象が発生した9月5日と9月18日の観測時刻へ紐づけます。グラフを作るために存在しない測定点を補完せず、未計測の部分は空欄や注記として区別してください。
変化の説明は確定事実と仮説を分ける
月末の平均応答時間が悪化したとしても、原因はサーバー負荷、外部ネットワーク、コンテンツ量、監視地点など複数考えられます。監視結果だけから「サーバー不足が原因」と断定するべきではありません。
月次報告では「P95が上昇した」「更新日以降に遅延が多い」など測定できた事実と、「キャッシュ設定の変更を調査する」といった次の行動を分けて書くと、実務につながります。
改善提案を次月のアクション表へまとめる
月次の数字は原因の調査や運用改善に使ってこそ意味があります。改善提案は大きな理想を書くだけでなく、優先度・担当・期限・完了条件が明確になる形に整理します。
| 優先度 | 改善・確認事項 | 担当（架空） | 期限・完了条件 |
|---|---|---|---|
| 高 | 9/18の連続失敗の原因と変更履歴を照合 | 保守担当 | 10/10までに調査結果を記録 |
| 中 | 監視停止後の再開チェックを運用表へ追加 | 運用担当 | 10/15までに手順・担当を確定 |
| 中 | P95が悪化した場合の調査基準を定義 | 開発・運用 | 10/20までに確認項目を合意 |
| 低 | 月次報告の対象URL台帳を更新 | サイト管理者 | 10/25までに一覧を照合 |
事実・推測・対応予定を同じ欄で混同しない
「9月18日に4回の連続した失敗チェックが観測された」は記録から確認できる事実です。一方で「データベース負荷が原因だった」は、別の根拠がなければ仮説にすぎません。改善提案は事実と調査すべき仮説を区別して作成します。
緊急性が高い障害を月末まで放置するという意味ではありません。月次レポートに載せるのは、必要な対応がすでに行われたか、継続中か、次月に何をするかという事後の確認です。
担当者が誰かと何をもって完了かを決める
「監視品質を改善する」だけでは完了を判断できません。「設定変更後の結果を2週間分確認する」「監視停止の再開チェック項目を運用表に追加する」など、検証できる完了条件を記録しましょう。
Google SREの公式資料でも、事後の改善項目には責任者・優先度・検証可能な終了状態を持たせる考え方が示されています。作業の担当者と、報告内容の承認者を区別する場合は、その役割も明記します。
未解決事項と対応済み事項を分ける
当月中に復旧確認まで終えた問題と、原因調査・恒久対応が終わっていない問題は別の状態です。解決したように見える文章を避け、調査中なら次回の確認日や担当を記載します。
顧客向けには必要な範囲で概要を伝え、内部の詳細なサーバー構成や個人情報などを不用意に共有しないよう、報告書の公開範囲に合わせて情報を調整することが大切です。
継続的な月次レポートでは前回の改善項目も確認する
翌月のレポートでは前月に残した改善項目の進捗を確認し、完了したもの、継続中のもの、優先順位を見直したものを整理します。新しい改善案を毎月追加するだけでは、対応が積み残される可能性があります。
報告書をファイル単位で保存する場合、年月・対象サイト・版数・確認者などの識別情報も付け、同じ期間に複数の版ができたときにどれが確定版か分かるようにします。
そのまま参考にできる月次監視レポートのひな形
次の構成は、担当者から管理者や顧客へ毎月共有するための記入例です。実際に提出するときは自分のサイトの監視結果へ置き換え、架空の数値やURLはそのまま使用しないでください。
| セクション | 記入する内容 | 記入例のポイント |
|---|---|---|
| 報告の基本情報 | 対象月・サイト・対象URL・作成者・作成日 | JSTと集計開始・終了を明記 |
| 総括 | 成功率・主な事象・前月差・未解決点 | 数値と重要な留保条件を短く |
| 監視条件 | 監視間隔・成功基準・監視方法 | 測定した範囲を限定 |
| 当月の数値 | 予定・実行・成功・失敗・未計測 | 実行数＝成功＋失敗を照合 |
| 事象と影響 | 発生時刻の観測、状況、復旧確認、影響 | 正確な停止時間は別の根拠が必要 |
| 比較と傾向 | 前月比・平均・P95・SSLなど | 分母や計測方式の差を注記 |
| 次月対応 | 担当・優先度・期限・完了条件 | 未解決項目の継続管理 |
| 確認・承認 | データ元・作成者・確認者・確定版 | 共有範囲を明記 |
1ページ目は要約、2ページ目以降に裏付けを置く
読者が忙しい場合でも、まず何が改善し、何が残っているかを把握できるよう1ページ目に要約を置きます。必要な場合にだけ、サイト別の結果、日別グラフ、事象の詳細、改善タスクを後続のページで示します。
報告書を毎月長くすること自体は目的ではありません。1サイトの状況が安定していれば要約中心でもよく、複数の異常があった月には証拠を確認できる情報を増やすなど、実情に合わせます。
報告文の見本を実際の条件へ置き換える
記入例：「対象：企業サイトの公開トップページ。期間：2026年9月1日〜9月30日（JST）。15分間隔の外部HTTPチェックは実行2,870回・成功2,864回・失敗6回、チェック成功率99.79％。欠測10回は別記しました。失敗チェックは二つの事象に関連づけて整理し、未解決の調査事項は翌月の対応表に記載しています。」
この例を転用するときは日付・測定方法・数値・対象URLを必ず自社の実データへ変更し、観測できたことと断定できないことを区別してください。実際の利用者影響は別の根拠が必要な場合があります。
PDF・スプレッドシート・管理画面のどれでも項目は共通
報告方法は企業の運用に合わせて選べます。PDFなら確定版の配布に、表計算なら比較や元データの検証に、管理画面なら随時の状況確認に向く場合があります。
ただし閲覧できる管理画面の数値が直近7日などに限られる場合、その画面だけで30日間の月次報告を作れない可能性があります。報告対象月の記録をどの方法で保全するかを事前に考えてください。
顧客向けには秘密情報と未確定原因を省く
外部に提出する場合、監視サイトの管理者アカウント、機密URL、サーバー内の接続情報、個人情報などを添付しないようにします。担当者が異なる複数顧客のデータを混在させないことも重要です。
原因が未確定の障害は「調査中」と表現し、推測を確定的な説明にしないでください。数値の取得元と報告版の確認者を残し、差し替えが必要な場合には版管理を行います。
エンリンクの監視履歴を月次報告に活用する際の注意点
エンリンクではHTTP/HTTPS監視履歴、障害・復旧の履歴、直近24時間・7日間の監視集計、直近14日間の日別応答成功率、平均・P95応答時間などが案内されています。ただし、月次PDF自動作成や30日分の任意期間集計が提供済みとは確認できません。
確認できるのは監視結果・履歴と短い期間の集計
エンリンクの機能一覧では、監視チェックの日時・結果・HTTPコード・応答時間と、障害の可能性や復旧確認の記録を閲覧できると説明されています。また直近24時間・7日間のチェック集計や、直近14日間の日別成功率を確認できます。
これらはサイトの状況を確認する有用な情報ですが、月次報告では1か月の全期間が必要です。短い期間の画面集計だけを足し合わせると期間の重複や抜けが生じることがあるため、データの対象期間を確認してください。
月次PDFの自動生成や30日一括集計を前提としない
現行の公開機能一覧では、月次レポートのPDF自動出力、指定した30日間の集計表、監視履歴のCSVダウンロードなどが利用者向けの提供機能として確認できません。利用可能だと断定したり、存在しない管理画面のボタンを案内したりしないことが重要です。
30日間の実データが月末まで取得できるか、過去履歴の保存期間や出力手段があるかは、実際の管理画面や提供条件で確認する必要があります。監視履歴を必要な期間保存できない場合は、別の許可された記録方法を検討してください。
管理画面の確認時点と対象期間を分けて記録する
7日間や14日間の表示は確認する日によって範囲が変わるため、月末の結果を翌月途中に見た場合、対象月の前半が表示されない可能性があります。定期報告を行う担当者は、どの日時にどのデータを確認したかを残しましょう。
監視を一時停止した区間や登録途中のサイトがある場合も、実行件数が少ない理由を別に整理してください。監視履歴の読み方と照合し、取得可能な範囲を超えて実績を推定しないようにします。
監視間隔と無料プランの範囲を報告条件に記載する
2026年10月24日時点の公式料金プランでは、無料は最大5サイト・1日2回、スタンダードは最大20サイト・15分間隔、ビジネスは最大50サイト・5分間隔、プロは最大100サイト・1分間隔が案内されています。実際のプランと設定した間隔を報告条件に書いてください。
これらは定期チェックの設定可能な間隔であり、障害を必ず一定時間内に見つける保証ではありません。エンリンクは最大5サイトまで無料で開始できるため、まず管理対象のWebサイトの状態を確認し、報告に利用できる情報の範囲を把握する用途にも使えます。
月次レポートで避けたい6つの誤り
毎月同じ形で報告していても、指標の解釈を間違えると意思決定を誤らせます。チェック回数と停止時間、監視できなかった区間、前月比較の条件、未確定の原因を正確に分けて説明しましょう。
チェック成功率をそのまま24時間の実稼働率と書く
15分間隔の監視で成功率99.79％だったという事実は、観測したチェックの成功率を示します。それだけで30日間の全時間について99.79％利用できたと断定することはできません。
正確な停止時間が必要なときは、障害の発生時刻と復旧時刻の根拠を別に用意します。具体的な計算式と違いは稼働率の計算方法で説明しています。
失敗6回を障害6件・停止90分と読み替える
失敗チェックが6回あっても、連続した失敗が二つの事象として記録されていることがあります。また15分間隔だからといって失敗6回を単純に90分の停止と断定できません。
チェックの前後で状態が変わった可能性があるため、実際の停止期間を決めるには別の観測やログが必要です。件数、事象の数、観測時刻を表に分けて記載しましょう。
未計測を成功扱いして見かけの成功率を上げる
監視を止めた時間やデータ収集ができなかった区間を成功と扱うと、実測の根拠がない数値になります。報告書では予定・実行・成功・失敗・未計測を別に示すことが重要です。
監視停止の理由がメンテナンスであっても、サービス自体の停止の有無やSLAでの除外条件は別です。未計測を正常とも異常とも断定しないようにします。
監視間隔が異なる月をそのまま比較する
8月は15分間隔、9月は5分間隔だった場合、予定チェック回数や短時間障害の見つかり方が変わります。同じ成功率でも測定条件が違えば、直接比較できない場合があります。
変更点があるときは脚注に記載し、可能なら同じ条件で比較できる期間やサイトごとの結果を用います。日数が違うだけの場合も、失敗回数と成功率を併記してください。
未確定の障害原因を確定事項として報告する
500系のHTTPコードが出たから「サーバー性能不足」と決めつけたり、更新日時が近いから更新作業が原因だと断定したりすることは避けます。監視で分かったのはレスポンスの事実です。
原因を示すならアプリケーションログや変更履歴などと照合し、根拠が足りない場合は調査中と記載してください。管理者や顧客に伝える文章でも、事実と仮説は分ける必要があります。
報告書を出しただけで改善が終わったと考える
毎月の結果が分かっても、繰り返す異常が放置されれば運用品質は改善しません。月次レポートには次にすること、担当、優先度、期限を付けて、翌月の報告時に進捗を確認しましょう。
記録を残す目的は責任追及ではなく、利用者への影響を減らすための改善です。Google SREの公式資料も、再発防止と実行可能な対応項目を重視しています。
Webサイト監視の月次レポートに関するよくある質問
月次報告の作成頻度、必要な数字、障害の扱い、複数サイトの集計、エンリンクで確認できる情報について、実務で迷いやすい点を整理します。
月次レポートには最低限どの項目が必要ですか？
対象月・対象URL・監視条件・チェック成功率・実行回数・失敗チェック・未計測・確認した事象・前月比・改善事項をまとめると、読み手が重要な状態を判断しやすくなります。
すべての監視ログを本文へ貼る必要はありませんが、元の記録がどこにあるかは分かるようにしてください。
月次レポートはいつ作ればよいですか？
前月の集計期間が確定し、必要な監視記録や運用記録がそろった時点で作成します。具体的な提出日は社内や顧客との運用合意に合わせて決めてください。
画面に表示されるデータが直近14日などの短い期間に限られる場合、月初に全月のデータが取得できるかも事前に確認する必要があります。
稼働率と監視チェック成功率は同じですか？
同じとは限りません。定期監視で成功した割合は、実際に行ったチェックの結果です。監視間隔の間に起きた停止や、未計測の区間はその数字だけでは分かりません。
24時間を通した時間ベースの稼働率を示す場合は別の定義と根拠が必要です。両者を同じ数字として報告しないでください。
失敗チェックが6回あれば障害も6回ですか？
必ずしもそうではありません。連続した複数の失敗が一つの障害に関係する場合があり、監視ツールの障害判定方式でも件数は変わります。
月次報告ではチェックの失敗回数と、障害・復旧の事象件数を分けて示してください。
前月比は何を比較するとよいですか？
同じ条件のチェック成功率、失敗回数、未計測、平均・P95応答時間などが候補です。対象URL・監視間隔・評価期間などが変わった場合は注記が必要です。
数字の比較だけで原因を断定せず、必要に応じて設定変更や障害履歴と照合してください。
監視を止めた期間はどう書けばよいですか？
実行できなかったチェックの数と対象日時、把握できている理由を別記します。監視停止中にサイトが正常だったかどうかは、その監視結果だけでは分かりません。
予定停止としてSLAから除外できるかも契約や測定定義によるため、報告書の都合で自動的に除外しないようにします。
複数サイトを合算した成功率はどう求めますか？
同じ定義のチェックなら、対象サイトの成功チェック数を合計し、実行チェック数の合計で割る方法が考えられます。単純なサイト別成功率の平均とは一致しない場合があります。
複数サイトをまとめる場合でも、重要サイトで大きな障害があった事実が全体平均に埋もれないよう、サイト別の数値も示してください。
月次レポートは毎月PDFにする必要がありますか？
PDFは確定版を配布する方法の一つですが、社内台帳やスプレッドシート、管理画面の閲覧などでも運用できます。必要な項目と監視データの根拠を揃える方が重要です。
閲覧範囲や保管期間が決まっている場合は、社内の情報管理ルールや顧客との合意に従ってください。
エンリンクで月次レポートを自動出力できますか？
公開の機能一覧ではHTTP監視履歴や直近7日・14日などの集計は確認できますが、月次PDFの自動出力や任意の30日集計の提供は確認できません。
必要な期間の履歴が取得できるか、出力・保存の方法があるかを管理画面と現行の提供条件で確認し、未提供機能を使える前提にしないことが重要です。
まとめ：月次レポートは数字の根拠と次の対応まで示す
Webサイト監視の月次レポートは、1か月のチェック結果を並べるだけではなく、何をどのように測り、どの事象があり、何を改善するかを説明する資料です。対象期間・成功と失敗・欠測・前月差・対応予定を同じ定義で整理します。
チェック結果・事象・未計測を区別して報告する
予定チェック数、実行数、成功、失敗、未計測を分け、前月と測定条件が同じか確認します。失敗回数を障害件数や正確な停止時間と混同しないこと、監視できなかった期間を正常と記載しないことが重要です。
読み手には先に要約を示し、必要に応じてチェック履歴や事象の詳細を確認できるようにしましょう。月次レポートの目的は実績の理解と、翌月の運用判断に役立てることです。
エンリンクで確認できる監視情報を整理する
エンリンクにはHTTP/HTTPS監視履歴、障害・復旧履歴、直近のチェック成功率、平均・P95応答時間が案内されています。ただし月次一括集計やPDF自動作成を提供しているとは確認できないため、必要な期間の元データをどう扱うか確認してください。
エンリンクは5サイトまで無料で利用開始できます。まず管理するサイトの監視結果や履歴を把握し、対象と集計期間を決めて、誤解のない月次報告を作成しましょう。
一次資料・参考：Google Cloud「公開Uptime Check」、Google Cloud「Uptime Checkの結果確認」、AWS「CloudWatchでデータが欠損した場合の扱い」、Google SRE Workbook「Postmortem Culture」、Google SRE「Postmortem Culture」（確認日：2026年10月24日）。
