クライアントサイト監視で報告すべきKPI 5選|Web制作会社向け指標ガイド
「何を報告すればいいか」で詰まる月次レポート
死活監視を導入した後に壁として立ちはだかるのが、「クライアントに何の数字を見せるべきか」という問いです。稼働率だけを並べても「99.9%って何が良いの?」と言われ、障害件数だけでは「そんなに落ちてるの?」と不安にさせてしまいます。
本記事では、Web制作会社がクライアントへの月次報告で使うべき監視固有のKPI 5つを、数字の意味・伝え方・Miterlでの取得方法とあわせて解説します。SEOやアクセス解析のKPIではなく、死活監視・SSL・メール認証・応答速度という監視インフラ特有の指標に絞っています。
なぜ「監視KPI」を別枠で考えるのか
Webサイトのパフォーマンス指標には大きく2種類あります。
| 種類 | 代表指標 | 担当者 |
|---|---|---|
| 集客・コンバージョンKPI | セッション数・CVR・直帰率 | マーケター・ディレクター |
| 監視KPI(本記事の対象) | 稼働率・応答時間・SSL期限残日数 | 保守担当・エンジニア |
集客KPIを報告するツールはGA4・Search Consoleと組み合わせて使われることが多いですが、監視KPIは死活監視ツールが唯一の情報源です。ここを整備することで、「サイトが健全に動き続けているか」という保守価値の可視化が完成します。
KPI 1:稼働率(Uptime Rate)
指標の意味
稼働率は「サイトが正常に応答していた時間の割合」です。100%から引いたダウンタイム率は、実際のユーザー影響を推定する基準になります。
| 稼働率 | 月間許容ダウンタイム | ユーザーへの影響 |
|---|---|---|
| 99.0% | 約7時間12分 | 影響大(ECサイトでは大きな機会損失) |
| 99.9% | 約43分 | 一般的な許容ライン |
| 99.99% | 約4分 | SLA明記水準(決済・医療等) |
クライアントへの伝え方
「今月は稼働率 99.97%(ダウンタイム:9分)でした。業界標準(99.9%)を上回る安定稼働でした」という形で、業界標準との比較を添えるだけで数字の重みが伝わります。
Miterlでの取得方法
# モニターの30日稼働率を取得する
curl -s "https://miterl.com/api/v1/monitors/1" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq '{name, uptime_30d, status}'
出力例:
{
"name": "クライアントA コーポレートサイト",
"uptime_30d": 99.97,
"status": "up"
}
KPI 2:平均応答時間(Average Response Time)
指標の意味
応答時間(レスポンスタイム)は「監視拠点からHTTPリクエストを送って最初のバイトを受け取るまでの時間(TTFB)」です。ダウンしていなくても、応答が遅いサイトはユーザー体験を損ないます。
Google の研究では、ページ表示速度が3秒を超えると直帰率が32%上昇することが示されています。保守担当者はサーバー応答(TTFB)で500ms以下を目安に管理するのが一般的です。
| 応答時間 | 評価 | 代表的な原因 |
|---|---|---|
| 500ms以下 | 良好 | — |
| 500ms〜1秒 | 許容範囲 | DBクエリの増加、キャッシュ設定の劣化 |
| 1秒以上 | 要調査 | プラグイン追加、サーバー過負荷、CDN設定ミス |
| 3秒以上 | 深刻 | ユーザー離脱リスク・直帰率の上昇 |
クライアントへの伝え方
「今月の平均応答時間は 340ms です。先月(380ms)より高速化されており、ユーザーがページを開くまでの待ち時間を短縮できています」という変化率の伝え方が効果的です。
# 複数モニターの応答時間一覧を取得する
curl -s "https://miterl.com/api/v1/monitors?per_page=50" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | "\(.name)\t\(.avg_response_time_ms // "N/A") ms"'
KPI 3:SSL証明書の残り有効日数
指標の意味
SSL証明書が期限切れになると、ブラウザが「この接続は安全ではありません」という警告を表示し、事実上サイトにアクセスできなくなります。これは稼働率0%と同義のインシデントです。
「自動更新があるから大丈夫」は油断の温床です。WordPressのキャッシュプラグインがACMEチャレンジをブロックしたり、サーバー移行時にcertbot設定が引き継がれなかったりと、更新失敗の原因は複数あります(詳細は「WordPress制作会社向けSSL証明書期限を一括管理する方法」を参照)。
推奨アラート設定
| アラートタイミング | 目的 |
|---|---|
| 残り30日 | 余裕を持った更新確認 |
| 残り14日 | 担当者へのリマインド |
| 残り7日 | 緊急対応の準備 |
Miterlでの取得方法
# 全SSLモニターの期限情報を一覧表示
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | select(.type == "ssl") | "\(.name)\t\(.status)\t\(.expires_at)"'
この一覧を月次報告に添付するだけで、「SSL証明書は全件問題ありません(最短期限:残り〇〇日)」という一行が書けるようになります。
KPI 4:メール認証スコア(SPF・DMARC・DKIM の稼働状態)
指標の意味
メール認証レコード(SPF・DMARC・DKIM・MX)は、DNS編集のたびに「気づかないうちに」壊れることがあります。発覚するのは「クライアントからメールが届かないと言われて」からがほとんどです。
Web制作会社の保守報告にメール認証の稼働状態を含めることで、「メールが届く」という当たり前の状態を意図的に維持していることを証明できます。
報告フォーマット
| レコード | 状態 | 備考 |
|---|---|---|
| SPF | 正常 | v=spf1 レコード確認済み |
| DMARC | 正常 | p=quarantine ポリシー設定済み |
| DKIM | 正常 | セレクター default で署名確認済み |
| MX | 正常 | 優先度10 メールサーバー応答中 |
「全レコード正常稼働中」が理想ですが、異常が検知された場合は即座にアラートが届くため、クライアントが気づく前に対処できます。
# メール認証モニターの稼働状態を確認する
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | select(.type | test("spf|dmarc|dkim|mx")) | "\(.name)\t\(.status)"'
KPI 5:障害復旧時間(Mean Time to Recovery / MTTR)
指標の意味
MTTRは「障害発生から復旧(サイト正常化)までの平均時間」です。稼働率が同じでも、1分の障害が40回起きた制作会社と、30分の障害が1回起きた制作会社では保守品質が全く異なります。
MTTRが短い制作会社は「障害への初動対応が速い」という信頼を蓄積できます。
Miterlでの取得方法
# 指定モニターの過去インシデント一覧(解決済み)を取得する
curl -s "https://miterl.com/api/v1/incidents?monitor_id=1&status=resolved&per_page=10" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | "\(.started_at)\t\(.duration_seconds)秒"'
duration_seconds から MTTR を計算します:
# 過去N件のインシデントからMTTRを計算する
incidents = [120, 300, 90, 480, 60] # 例:秒数のリスト
mttr_seconds = sum(incidents) / len(incidents)
mttr_min = mttr_seconds / 60
print(f"MTTR: {mttr_min:.1f}分")
# → MTTR: 17.5分
クライアントへの伝え方
「今月発生した1件の障害の復旧時間は 15分でした。アラート受信から復旧確認までの対応時間です。業界平均は約40〜60分とされており、迅速に対応できています」という形が理想的です。
5つのKPIをまとめた月次報告テンプレート
=== [クライアント名] サイト監視 月次報告(202X年XX月)===
【稼働率】
- 先月の稼働率: 99.97%(業界標準: 99.9%)
- ダウンタイム合計: 9分(1件の軽微な障害)
【応答時間】
- 月間平均応答時間: 340ms(前月: 380ms)
- 状態: 良好
【SSL証明書】
- 現在の状態: 正常
- 有効期限まで: 残り85日(次回: XXXX年XX月)
【メール認証レコード】
- SPF / DMARC / DKIM / MX: 全件正常稼働中
【障害復旧時間(MTTR)】
- 今月発生件数: 1件
- 平均復旧時間: 15分
詳細はステータスページからご確認ください:
https://status.example-client.com
このテンプレートを毎月自動生成する手順は「制作会社向け|クライアント月次稼働率レポートを自動化する方法」で解説しています。
KPIを保守単価に結びつける
5つのKPIを毎月クライアントに報告する仕組みが整うと、保守料金の根拠が数字で見える化されます。これが単価アップ・契約継続率向上に直結します。
保守メニューを「ベーシック(稼働率のみ)」「スタンダード(稼働率+SSL+メール認証)」「プレミアム(全5KPI+ステータスページ)」の3段階で設計することで、クライアントが自分の必要なプランを選べるようになります。
料金設計の詳細は「保守契約に監視を組み込む料金設計ガイド」を、SLAへの落とし込みは「保守契約向けSLAレポート自動化ガイド」をご覧ください。
まとめ
Web制作会社の月次保守報告に含めるべき監視KPIは以下の5つです。
- 稼働率(Uptime Rate): サイトが正常稼働していた時間の割合
- 平均応答時間: ユーザー体験に直結するサーバー応答速度
- SSL証明書の残り有効日数: 更新失敗を事前に防ぐ安全弁
- メール認証スコア: SPF・DMARC・DKIMの稼働状態
- 障害復旧時間(MTTR): 保守会社の対応品質を示す指標
これらをMiterlのAPIで自動取得し、毎月1日に自動送信する仕組みを作ることで、手作業のレポートから解放されます。まずは無料プランで動作を確認し、設定の詳細はドキュメントをご覧ください。制作会社向けのより詳しい活用例はユースケース一覧でも紹介しています。よくある質問はFAQにまとめています。