制作会社が顧客サイト150件を月3,000円で一括監視する運用フロー
Web制作会社がMiterlを使って複数顧客サイトを束ねて死活監視する運用シナリオ。Webhookによるメンテ除外、月次レポート自動化、保守契約の付加価値化までを実例ベースで解説します。
想定するチームと前提条件
東京・関西エリアで中小企業のコーポレートサイトを中心に制作する10名規模の制作会社「A社」を想定したシナリオです。クライアント数は30社前後、保守契約中の本番サイトは合計150件。月額3,000〜10,000円程度の保守契約に「サイト稼働の見守り」を含めているものの、実態としてはクライアントから「サイトが見られない」と電話が来てから初めて気付く状態が続いていました。
このユースケースでは、A社が Miterl を導入してから3ヶ月で「監視を売れるサービスに変えた」までの運用フローと、月次の手間と費用感を整理します。
導入前に抱えていた3つの課題
1. 既存監視ツールが「重すぎる」「高すぎる」
業界標準の監視SaaSは、機能が豊富な反面、150件規模になるとライセンス費用だけで月数万円。中小規模のクライアント保守費に乗せると赤字になります。社内サーバーで自前のスクリプトを動かしていたチームもありましたが、監視サーバー自体が落ちて誰も気付かないという本末転倒な状況も発生していました。
2. デプロイ時の誤通知が運用負担
CMS(WordPressやMovable Type)のメジャーバージョンアップやサーバー移行のタイミングで、監視がDOWN扱いの誤検知を出し、深夜・休日にSlackが鳴り続ける。「どうせ作業中だから無視で」という運用が常態化してしまい、本物の障害も埋もれるリスクが高まっていました。
3. 月次レポートを毎月手書きしている
「先月の稼働率は99.95%でした」というレポートを、エンジニアがCSVを集計してPDFで送る作業に毎月3〜4時間。クライアントによってフォーマットがバラバラで、テンプレ化もできず属人化していました。
Miterl を採用した3つの決め手
| 観点 | 期待値 |
|---|---|
| 月額コスト | 150件で月3,000円台。クライアント1件あたり実コスト20円 |
| メンテナンス除外 | デプロイスクリプトから Webhook 1発で自動除外 |
| 多言語・タイムゾーン | 海外オフショアチームと日本側で表記を切り替え可能 |
特に効いたのは「Webhookでメンテナンス除外できる」点でした。CI/CD に組み込むだけで誤通知が止まり、エスカレーションの信頼性が一気に上がっています。
運用フローの全体像
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. インシデント対応のエスカレーションSLA
A社では「障害検知から1次連絡まで30分以内」を保守契約に明文化しました。Miterl から Slack の #oncall チャンネルに通知が飛び、当番のエンジニアが Drill 機能で訓練済みの手順に従って、状況確認 → クライアントへの一次報告 → 復旧作業 → 復旧連絡、という流れを回します。
オンコール訓練は月1回、リアルな本番環境ではなく Drill モードで疑似インシデントを発生させる形で実施。新人でも3ヶ月以内には独立して当番が回せる状態になりました。
4. 月次レポートの自動生成
毎月1日朝に、各 Workspace の稼働率レポートが自動的に PDF として生成され、共有用URLで配布できる状態になります。クライアントごとのフォーマットも統一され、レポート作成の工数は月3時間 → 月15分まで削減できました。
月3,000円で150サイトを監視できる理由
Miterl の Plus プラン(月額3,300円)では監視数が250件まで含まれます。1分間隔でのチェック、複数の通知先(Slack/メール/Discord/Chatwork)、Webhookによるメンテナンス除外、SLA計算、月次PDFレポート、これらが追加課金なしで使えるため、150件規模であれば1サイトあたり月22円で監視できる計算です。
クライアントの保守契約に「24時間サイト監視・障害検知サービス」として月500円〜1,000円のオプションを設定すれば、150件で月7.5万〜15万円の純利益を生むサービスに変わります。
クライアントへの提案で使えるトーク例
「現在の保守契約には『障害発生時の対応』が含まれていますが、実態としてお客様ご自身がサイトの異常に気付いてからのご連絡となるケースが多いのが現状です。私たちが先回りして検知し、お客様より先にご連絡できる体制を作るために、24時間監視のオプションをご提案させてください。月額1,000円で、SSL証明書の期限切れや特定キーワードの欠落、ページの表示速度低下までカバーできます。」
具体的な数字(去年のクライアント全体での障害件数、平均復旧時間、検知遅れによる機会損失)を添えると、提案が一気に通りやすくなります。
関連リンク
このユースケースで触れた仕組みの詳細は、以下の記事もあわせて読むと運用イメージが固まります。
- Miterl ドキュメント — 監視タイプ・通知設定・API リファレンス全体
- Web制作会社向けの機能紹介 — エージェンシー向けプラン・割引
- Web制作会社が死活監視を保守契約に組み込むべき5つの理由 — 提案論側の整理
- 料金プラン — Free/Plus/Pro の比較
- 導入ユースケース一覧 — 他業種の運用シナリオ