制作会社向け｜クライアント月次稼働率レポートを自動化する方法

月次レポートは「保守契約の成績表」

保守サブスクを契約してもらっていても、クライアントから「毎月何をしてくれているの？」と聞かれる場面は少なくありません。コーディングやWordPressアップデートは目に見えますが、死活監視や障害対応は成果が見えにくいのが難点です。

月次の稼働率レポートは、その見えにくい価値を数字で示す最も直接的な手段です。「今月は99.97%の稼働率でした。障害は1件発生しましたが、クライアントより先に検知し15分で復旧しました」——このような報告は、保守費の正当性を裏付け、契約継続率と単価を両方押し上げます。

ただし、手動でレポートを作り続けると月末の工数が膨らみます。本記事では、MiterlのAPIを使って稼働率・障害データを自動取得し、クライアントへの報告を仕組み化する方法を説明します。

手動レポートがスケールしない理由

クライアント数が増えると工数が線形に増える

1社あたり20〜30分かかるレポート作業が、10社なら3〜5時間、20社なら半日以上に膨らみます。月末に障害が重なると、復旧対応とレポート作業が同時期に集中してパンクします。

手作業では数字がずれやすい

ダッシュボードを目視してスプレッドシートに転記すると、期間のズレやコピーミスが発生します。稼働率の数字を間違えてクライアントに指摘された場合、謝罪と再送で失う信頼は大きいです。

自動化で変わること

Miterlで取得できるデータ

Miterlのダッシュボードには稼働率と障害履歴が蓄積されています。これをAPIで取得することで、スプレッドシートへの手動コピーを省けます。

レポートに使う主なデータは以下の3種類です。

1. 30日稼働率 (uptime_30d): ローリング直近30日間の稼働率パーセント
2. 障害一覧 (/api/v1/incidents): 発生日時・復旧日時・継続時間
3. ステータスページURL: クライアント自身がいつでも確認できる公開ページ

なお、MiterlはAPIでデータを取得する機能を提供していますが、「レポートPDFを自動送信する」機能自体は現時点では提供していません。後述するように、APIでデータを取得して制作会社側のスクリプトでレポートを生成・送信する構成になります。

ステップ1：APIキーの取得とモニター一覧の確認

MiterlダッシュボードのSettings → API Keysからキーを発行します。次に、レポート対象のモニターIDを確認します。

# 全モニターのid・name・30日稼働率を一覧表示
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | "\(.id)\t\(.name)\t\(.uptime_30d)%"'

出力例：

1    クライアントA コーポレートサイト    99.97%
2    クライアントA 採用ページ            100.00%
3    クライアントB ECサイト              99.83%

ステップ2：当月の障害履歴を取得する

稼働率は直近30日のローリング集計ですが、カレンダー月（例：6月1〜30日）での障害件数をレポートに含めたい場合は、インシデント一覧から絞り込みます。

# モニターID=1の2026年6月の解決済み障害を取得
MONITOR_ID=1
YEAR=2026
MONTH=06

curl -s "https://miterl.com/api/v1/incidents?monitor_id=${MONITOR_ID}&status=resolved&per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq --arg ym "${YEAR}-${MONTH}" '
    [
      .data[]
      | select(.resolved_at | startswith($ym))
    ]
    | {
        count: length,
        total_downtime_min: (map(.duration_seconds) | (add // 0) / 60 | round)
      }
  '

出力例：

{
  "count": 1,
  "total_downtime_min": 9
}

duration_secondsは障害開始から復旧までの秒数です。ダウンタイム分数を月間稼働率に変換するには次のように計算します。

# 例: 6月（30日）に9分のダウンタイム
downtime_min = 9
total_min = 30 * 24 * 60  # 43200分
uptime_pct = (1 - downtime_min / total_min) * 100
print(f"稼働率: {uptime_pct:.4f}%")
# → 稼働率: 99.9792%

ステップ3：全クライアントのデータを一括収集するスクリプト

モニターIDとクライアント名のマッピングを定義し、ループで全データを収集します。

#!/bin/bash
# monthly_report_collect.sh
# 使い方: MONTH=2026-06 ./monthly_report_collect.sh

API_KEY="YOUR_API_KEY"
BASE_URL="https://miterl.com/api/v1"
MONTH="${MONTH:-$(date +%Y-%m)}"

declare -A MONITORS=(
  [1]="クライアントA コーポレートサイト"
  [2]="クライアントA 採用ページ"
  [3]="クライアントB ECサイト"
)

echo "# ${MONTH} 月次稼働率レポート（自動生成）"
echo ""

for MONITOR_ID in "${!MONITORS[@]}"; do
  CLIENT_NAME="${MONITORS[$MONITOR_ID]}"

  # 30日稼働率を取得
  UPTIME=$(curl -s "${BASE_URL}/monitors/${MONITOR_ID}" \
    -H "Authorization: Bearer ${API_KEY}" \
    | jq -r '.data.uptime_30d // "N/A"')

  # 当月の障害サマリーを取得
  INCIDENT_DATA=$(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)}
    ')

  INCIDENT_COUNT=$(echo "$INCIDENT_DATA" | jq -r '.count')
  DOWNTIME_MIN=$(echo "$INCIDENT_DATA" | jq -r '.total_min')

  echo "## ${CLIENT_NAME}"
  echo "- 直近30日稼働率: ${UPTIME}%"
  echo "- 当月障害件数: ${INCIDENT_COUNT}件"
  echo "- 当月ダウンタイム: ${DOWNTIME_MIN}分"
  echo ""
done

このスクリプトをcronで毎月1日に実行し、出力をMarkdownやHTMLに変換してメール送信するとレポートの自動化が完成します。

ステータスページとの組み合わせ

レポートメール単体でも価値はありますが、ステータスページのURLをレポートに添付することで効果が高まります。クライアントが「今サイトは動いているか？」と気になったとき、制作会社に問い合わせる前に自分で確認できる場所を提供できるからです。

MiterlのステータスページはMonitorに紐付けて公開できます。URLをクライアントにブックマークしてもらうだけで、問い合わせ件数の削減が期待できます。

ステータスページの導入コストと効果の詳細については「ステータスページの運用コストとROI——保守費に組み込む方法と収益化」を参照してください。

レポートを「保守費の根拠」として活用する

稼働率レポートの本質的な役割は、クライアントに保守の価値を毎月リマインドすることです。障害がなかった月でも「今月も99.99%の稼働率を維持しました」というメールは、何もなかったのではなく「監視と管理があったから何もなかった」ことを示します。

保守サブスクの解約を検討するクライアントの多くは「よくわからないお金を払っている」という感覚を持っています。レポートでその「よくわからない」を「安定稼働の実績」に変換できれば、解約トリガーを大幅に減らせます。

制作会社が監視を保守サービスに組み込む具体的な方法については「死活監視を保守サービスに組み込む方法｜制作会社向けガイド」で解説しています。

SLAを契約に明記してクライアントに稼働率の目標値を約束する場合は、月間許容ダウンタイムの換算が必要です。「保守契約向けSLAレポート自動化ガイド」に換算表と自動化の詳細手順があります。

クライアントに送るレポートの構成例

最低限含めるべき要素を整理しておきます。

シンプルでも構いません。大切なのは、クライアントが「数字を見て安心できる」ことです。グラフや詳細ログは付加価値ですが、なくても基本的な信頼感は伝わります。

まとめ

月次の稼働率レポート自動化は、制作会社にとって3つのメリットをもたらします。

1. 工数削減: 月末のレポート作業を大幅に短縮
2. 信頼構築: 数字でサービス品質を継続的に証明
3. 解約防止・単価向上: 保守の価値が可視化されることで契約継続率と値上げ交渉力が上がる

Miterlのダッシュボードでモニター設定を確認し、APIキーを発行したら上記のスクリプトから試してみてください。まずは1〜2社のクライアントに送ってみるだけで、反応の違いがわかるはずです。

Miterlで無料トライアルを開始する