クライアントポータルで監視データを見せる方法｜月次報告の実践ガイド
「監視を導入したのに、クライアントに伝わっていない」
死活監視ツールを契約し、アラートの設定まで完了した後に多くの制作会社がぶつかる壁が「クライアントに監視の価値が伝わっていない」という問題です。ダッシュボードには毎日データが積み上がっているのに、クライアントからは「毎月何をしているのですか？」という質問が来る。
この記事では、監視データをクライアントに届ける3段階の構造を整理します。具体的には「リアルタイムの閲覧（ステータスページ）→ 月次の振り返り（定期レポート）→ 障害発生時の即時告知」という流れです。それぞれを適切に設計することで、クライアントは「監視されている安心感」を日常的に得られ、制作会社は保守契約の継続率と単価の両方を高められます。
なぜクライアントへの可視化が重要なのか
保守サブスクリプションを解約する理由で最も多いのは「費用対効果がわからない」です。障害が起きないほど「何もしていないのでは？」と思われるという皮肉な構造があります。
| クライアントの状況 | 見えていないと | 見えていると |
|---|---|---|
| 障害なし（平常月） | 「何もしていない月に料金を払っている」 | 「監視のおかげで障害ゼロだった」と理解 |
| 障害あり（対応済） | 「なんで落ちたの？」という不安 | 「15分で復旧した実績」として信頼に変わる |
| SSL更新・DNS変更 | 「いつの間にか更新されている」 | 「アラートで事前に気づいた」と伝わる |
この認識の差を埋めるのが「クライアントポータル」の役割です。ここではポータルを特定のツールに限定せず、「クライアントが監視の状態を確認できる仕組み全体」として定義します。
第1段階：ステータスページでリアルタイムを共有する
クライアントが「今すぐ確認できる場所」を作る
監視ポータルの基盤となるのがステータスページです。クライアントが「サイト、今大丈夫かな？」と気になったとき、制作会社に電話やメールをする前に自分で確認できる場所を提供することが第一歩です。
Miterlのステータスページには以下の情報がリアルタイムで表示されます。
- 監視対象の現在の稼働状態（正常 / 低下 / 障害中）
- 直近90日間の稼働率グラフ
- 過去のインシデント履歴と解決状況
- 予定メンテナンスのスケジュール
# 公開ステータスページのデータをAPIで取得（認証不要）
curl -X GET https://miterl.com/api/v1/status-pages/your-client-slug \
-H "Content-Type: application/json"
# レスポンス例
# {
# "data": {
# "name": "クライアントA ステータス",
# "overall_status": "operational",
# "monitors": [
# {"id": 1, "name": "Webサイト", "status": "up", "uptime_90d": 99.9}
# ],
# "incidents": [],
# "upcoming_maintenance": []
# }
# }
ステータスページのURLをクライアントのブックマークに追加してもらうだけで、「今どうなっていますか？」という問い合わせが60〜70%減るというデータがあります（詳細は「クライアント向けステータスページの活用法」を参照）。
ステータスページをどこに設置するか
| 設置場所 | メリット | 向いているケース |
|---|---|---|
status.client-domain.jp |
クライアントブランドで完結する | 上位プランで独自ドメインを提供する場合 |
miterl.com/status/your-slug |
設定が最小限で始められる | まず試したい場合 |
| 提案書・月次メールに毎回URLを記載 | クライアントが忘れない | 定着するまでの誘導 |
Miterl Standard プラン以上では独自ドメインでのステータスページ公開が可能です。クライアントから見ると制作会社ブランドのサービスとして映るため、保守の専門性を示す場として機能します。
第2段階：月次レポートで振り返りを届ける
レポートに含める5つのKPI
毎月一度、監視データをまとめてクライアントに届けることで、「今月も問題なく管理されていた」という事実を積み重ねられます。月次報告で使うべき監視KPIについては「クライアントサイト監視で報告すべきKPI 5選」で詳しく解説していますが、ここでは構成のポイントを整理します。
=== [クライアント名] サイト監視 月次報告（202X年XX月）===
【稼働率】
- 直近30日稼働率: 99.97%（業界標準: 99.9%）
- ダウンタイム合計: 9分（1件）
【応答時間】
- 月間平均応答時間: 340ms（前月: 380ms）
【SSL証明書】
- 状態: 正常
- 有効期限まで: 残り85日
【メール認証】
- SPF / DMARC / DKIM / MX: 全件正常稼働中
【障害復旧時間（MTTR）】
- 今月発生件数: 1件
- 平均復旧時間: 15分
▶ ステータスページ: https://status.example-client.com
このテンプレートはMiterlのAPIでデータを自動収集して生成できます。複数のクライアントを持つ場合は、月末の集計作業を大幅に短縮できます。
自動集計スクリプトの基本構成
#!/bin/bash
# monthly_portal_report.sh
# 全クライアントの月次レポートデータを収集する
API_KEY="YOUR_API_KEY"
BASE_URL="https://miterl.com/api/v1"
MONTH="${MONTH:-$(date +%Y-%m)}"
declare -A MONITORS=(
[1]="クライアントA コーポレートサイト"
[2]="クライアントB ECサイト"
[3]="クライアントC 採用サイト"
)
for MONITOR_ID in "${!MONITORS[@]}"; do
CLIENT="${MONITORS[$MONITOR_ID]}"
# 稼働率を取得
UPTIME=$(curl -s "${BASE_URL}/monitors/${MONITOR_ID}" \
-H "Authorization: Bearer ${API_KEY}" \
| jq -r '.data.uptime_30d // "N/A"')
# 当月の障害サマリーを取得
INCIDENTS=$(curl -s "${BASE_URL}/incidents?monitor_id=${MONITOR_ID}&status=resolved&per_page=100" \
-H "Authorization: Bearer ${API_KEY}" \
| jq --arg ym "${MONTH}" '
[.data[] | select(.resolved_at | startswith($ym))]
| {count: length, total_min: (map(.duration_seconds) | (add // 0) / 60 | round)}
')
COUNT=$(echo "$INCIDENTS" | jq -r '.count')
DOWNTIME=$(echo "$INCIDENTS" | jq -r '.total_min')
echo "## ${CLIENT}"
echo "- 稼働率: ${UPTIME}%"
echo "- 障害件数: ${COUNT}件 / ダウンタイム: ${DOWNTIME}分"
echo ""
done
このスクリプトをcronで毎月1日に実行し、HTMLメールに変換して送信する全体の仕組みは「クライアント月次稼働率レポートを自動化する方法」で詳しく解説しています。
障害なしの月こそレポートが効く
「今月は障害がなかったから報告することがない」というのは誤りです。障害がなかった月は「監視と管理が機能していた月」であり、それ自体がレポートのコンテンツになります。「今月の稼働率 99.99%、障害件数ゼロ」という一行は、何もしなかった月ではなく、意図的に安定させた月であることをクライアントに伝えます。
第3段階：障害時の即時告知でパニックを防ぐ
障害が起きた瞬間が「信頼を作る機会」
クライアントへの可視化の3段階のうち、最も重要なのが障害発生時の対応です。クライアントが「サイトが落ちている」と気づく前に告知できれば、不安の問い合わせが来る前に状況を伝えられます。
件名: 【Miterl 監視アラート】クライアントAサイト - 現在調査中
クライアントA 担当者様
xx:xx に貴社サイト（https://example-client.com）での
サービス低下を検知しました。
現在、原因を調査中です。
▶ 最新状況: https://status.example-client.com
引き続き状況をお知らせします。
このような告知をクライアントより先に送ることができれば、「気づいたら制作会社がもう動いていた」という印象を与えられます。これがクライアントが制作会社を信頼し続ける最大の根拠になります。
障害告知の3段階タイムライン
| フェーズ | タイミング | 内容 |
|---|---|---|
| 第1報 | 検知から5分以内 | 「現在調査中」の告知。ステータスページを案内 |
| 第2報 | 原因判明時 | 原因と対応方針の報告 |
| 復旧報告 | 復旧後すぐ | 復旧確認と再発防止策の説明 |
ステータスページのインシデント欄をリアルタイムで更新することで、クライアントは問い合わせをしなくても最新状況を把握できます。この仕組みがあると、「障害中の問い合わせ対応」という二重の工数が発生しなくなります。
Webhookを使ったメンテナンス告知の自動化
計画メンテナンス（サーバー移行・WordPressアップデートなど）は、最低48時間前にステータスページで告知します。デプロイスクリプトにWebhookを組み込むと、作業開始と同時に監視アラートの一時停止と告知が自動で完了します。
# デプロイ前にメンテナンスウィンドウを開始（1時間後に自動終了）
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/start \
-H "Content-Type: application/json" \
-d '{"duration_hours": 1, "name": "定期メンテナンス — WordPressコアアップデート"}'
このワンコマンドで「監視アラートの停止」と「ステータスページへの予定メンテナンス表示」が同時に完了します。
3段階を組み合わせた効果
ステータスページ・月次レポート・障害告知の3段階を組み合わせると、クライアントが監視価値を感じる機会が月に複数生まれます。
通常月の流れ:
日常 → ステータスページで稼働状態を自己確認
月末 → 月次レポートで「今月も安定稼働」を確認
必要時 → メンテナンス告知で事前に把握
障害発生時:
検知 → 制作会社がクライアントより先にアラートを受信
第1報 → 5分以内に「調査中」の告知メール送信
ステータスページ → リアルタイム更新でクライアントが自己確認
復旧 → 復旧報告メール + ステータスページ更新
翌月 → 月次レポートで「障害1件・復旧15分」を数字で報告
このサイクルが回ることで、「何かあったとき制作会社がいる」という信頼が積み上がり、保守契約の解約率低下と単価向上につながります。
保守プランの価格設計への応用
クライアントポータルの完成度を段階的に価格に結びつけると、保守プランのグレードが明確になります。
| プラン | 提供内容 | 想定月額 |
|---|---|---|
| ベーシック | 稼働率監視のみ（月次メール1通） | 5,000〜10,000円 |
| スタンダード | 監視5KPI + ステータスページ + 月次レポート | 15,000〜30,000円 |
| プレミアム | 全機能 + 独自ドメインステータスページ + 障害告知自動化 | 30,000〜60,000円 |
保守サービスへの監視の組み込み方と料金設計の詳細は「保守契約に監視を組み込む料金設計ガイド」を、ROIの数値算出は「制作会社が死活監視を保守契約に組み込むROI」を参照してください。
まとめ
クライアントに監視データを届ける3段階の構造は以下のとおりです。
- ステータスページ（日常）: クライアントがいつでも自己確認できる場所。問い合わせ60〜70%削減
- 月次レポート（定期）: 5つのKPIで「今月も安定稼働」を数字で証明。保守費の根拠に
- 障害告知（緊急）: クライアントより先に伝えることで信頼のピンチをチャンスに変える
Miterlはこの3段階をすべてカバーします。まずは無料プランでステータスページを設定し、動作を確認してください。設定手順の詳細はドキュメントで確認できます。制作会社向けの活用シナリオはユースケース一覧にもまとめています。