Web制作会社 2026年4月28日

制作会社が保守クライアント30社を『調査込み』の保守サブスクで仕組み化する運用フロー

Web制作会社がMiterlを使って複数顧客サイトの死活監視・障害調査・月次レポートをまとめて仕組み化する運用シナリオ。Webhookによるメンテ除外、ホワイトラベルでのクライアント提供、保守契約の付加価値化までを実例ベースで解説します。

制作会社保守契約サイト監視障害調査ホワイトラベル

想定するチームと前提条件

東京・関西エリアで中小企業のコーポレートサイトを中心に制作する10名規模の制作会社「A社」を想定したシナリオです。保守契約中のクライアントは30社、本番サイトは合計90件。月額3万〜10万円の保守契約を結んでいるものの、実態としてはクライアントから「サイトが見られない」と電話が来てから初めて気付く状態が続いていました。

このユースケースでは、A社が Miterl を導入してから3ヶ月で「監視と障害調査込みの保守サービスとして売れるサブスク」に変えるまでの運用フローと、月次の手間と費用感を整理します。

導入前に抱えていた3つの課題

1. クライアントから先に「落ちてますよ」と連絡が来る

業界標準の監視SaaSは死活監視はしてくれますが、「なぜ落ちたか」までは調べてくれません。アラートが来てから自社のエンジニアが深夜にログを漁ることになり、気づいた時にはクライアントから先に電話が入っている状況が続いていました。次の更新案件にも影が差します。

2. デプロイ時の誤通知が運用負担

CMS（WordPressやMovable Type）のメジャーバージョンアップやサーバー移行のタイミングで、監視がDOWN扱いの誤検知を出し、深夜・休日にSlackが鳴り続ける。「どうせ作業中だから無視で」という運用が常態化してしまい、本物の障害も埋もれるリスクが高まっていました。

3. 月次レポートと障害報告書を毎月手書きしている

「先月の稼働率は99.95%でした」というレポートを、エンジニアがCSVを集計してPDFで送る作業に毎月3〜4時間。クライアントによってフォーマットがバラバラで、テンプレ化もできず属人化していました。障害が起きるたびに作る「報告書」もMSワードで毎回ゼロから書き起こしていました。

Miterl を採用した3つの決め手

観点	期待値
障害調査までエンジニアが代行	Pro プラン：月3件の調査込み（NDAでサーバー内部まで）
メンテナンス除外	デプロイスクリプトから Webhook 1発で自動除外
ホワイトラベル	Standard から Powered by 非表示・独自ドメイン対応、A社の保守サービスとして提供可能

特に効いたのは「障害が起きたら Miterl のエンジニアが原因を調べてレポートを出してくれる」点でした。エンジニアが深夜にログを漁る作業を、翌朝の調査レポート受領に置き換えられることは、社内エンジニアの離職防止にも直結します（Miterl の調査窓口は平日 10:00〜19:00 JST、Standard は初動 4 営業時間以内 / Pro は初動 2 営業時間以内）。

運用フローの全体像

1. クライアントごとに Workspace を分離

A社では、クライアント単位で Workspace を分けて運用しています。社内メンバー（プロジェクトマネージャー）には対応する Workspace のみを viewer 権限で割り当て、開発者は member 権限で監視ルールの編集まで可能。退職や担当変更時の権限管理が直感的になりました。

2. デプロイスクリプトでメンテナンス自動除外

メンテナンス用 Webhook トークンを発行し、デプロイ前後で START/END を呼び出すだけ。GitHub Actions、Bitbucket Pipelines、社内の Jenkins、どれでも 2 行追加で済みます。

# デプロイ開始前
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{"duration_hours": 1, "name": "Deploy v1.2.3"}'

# 本処理（rsync, デプロイ, キャッシュクリア等）
./deploy.sh

# デプロイ完了後
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/end

リリース完了するまでの数十分間、誤検知でアラートが飛ぶことはなくなります。デプロイが想定より長引いてもタイムアウト（duration_hours）で自動的にメンテが切れるため、END を呼び忘れても安全側に倒れます。

3. 障害調査は Miterl のエンジニアに依頼

A社は保守契約に「障害検知後の1次連絡＝平日営業時間内 1 時間以内、夜間・休日は翌営業日朝」を明文化しました。Miterl から Slack の #oncall チャンネルに通知が飛んだ後、ログ確認や原因特定は Miterl の障害調査リクエスト（Pro プランで月3件・平日10〜19時 JST・初動 2 営業時間以内）に投げて、A社のエンジニアはクライアントへの一次連絡と社内意思決定に集中します。深夜・休日に検知した障害の調査も、翌営業日の対応分として Miterl が引き受けます。

調査結果は Miterl から原因と再発防止策のレポート（PDF）として上がってくるので、それをA社のロゴ付きでクライアントに転送。**「深夜の調査作業を、翌朝のレポート受領に置き換えられる」**という変化は、エンジニアの離職率にも効きました。

4. オンコール訓練（Drill）

実際に障害が起きないと、通知が届くか・誰が一次対応するか・どう動くかが検証できません。Miterl の Drill 機能で「擬似障害」を月1回起こして社内のオンコール体制を訓練。新人でも3ヶ月以内には独立して当番が回せる状態になりました。Drill は公開ステータスページには絶対に表示されないので、クライアントから見えない社内訓練として安全に使えます。

5. 月次レポートと障害報告書の自動生成

毎月1日朝に、各 Workspace の稼働率レポートが自動的に PDF として生成され、A社のロゴ・ブランドカラー入りで配布できる状態になります。クライアントごとのフォーマットも統一され、レポート作成の工数は月3時間 → 月15分まで削減できました。障害発生時の報告書も自動生成されるので、「報告書をMSワードで書く時間」がなくなります。

ホワイトラベルで「A社の保守サービス」として提供

Standard プランから Miterl の表記をすべて消せます。具体的には：

ロゴ・ブランドカラーをA社のものに差し替え
「Powered by Miterl」表記の非表示
ステータスページを status.client.com のように独自ドメインで公開（クライアント側DNSにCNAMEを1本足すだけ）

独自ドメイン公開は、クライアント側DNSに次のようなCNAMEレコードを1本追加するだけで完了します。

; status.client.com を Miterl のステータスページに向ける
status.client.com.    3600    IN    CNAME    cname.miterl.com.

クライアントから見えるのは「A社の保守サービス」だけで、Miterl というツールの存在はクライアントには伝わりません。再販モデルとして長く運用できる仕掛けです。

Miterl の費用と保守単価

A社が選んだのは Pro プラン（月額 ¥49,800）。100モニターまで監視でき、1分間隔・全通知チャネル・LINE・SMS・Webhook、月3件の障害調査＋NDAサーバー調査、優先サポートが含まれます。

90サイト × Pro = 1サイトあたり約 ¥553/月。

これに対して、保守契約に「24時間自動監視＋翌営業日までの調査レポート込み」のオプションを月額 ¥4,000/社で組み込むと：

30社 × ¥4,000 = ¥120,000/月の追加売上
引いて Pro 原価 ¥49,800 = ¥70,200/月の純益

「監視サービス」を売っているのではなく「クライアントから先に検知して、原因まで調べて、ブランド付きの月次レポートで報告する保守サブスク」を売っているのがポイントです。

クライアントへの提案で使えるトーク例

「現在の保守契約には『障害発生時の対応』が含まれていますが、実態としてお客様ご自身がサイトの異常に気付いてからのご連絡となるケースが多いのが現状です。私たちが先回りして検知し、お客様より先にご連絡できる体制を作るために、24時間自動監視＋平日営業時間内の原因調査オプションをご提案させてください。月額¥4,000で、SSL証明書の期限切れや特定キーワードの欠落、ページの表示速度低下までカバーし、障害が起きたときは原因調査までこちらで対応します（深夜・休日に発生した障害は翌営業日の朝に調査着手）。」

具体的な数字（去年のクライアント全体での障害件数、平均復旧時間、検知遅れによる機会損失）を添えると、提案が一気に通りやすくなります。