Miterl 活用ガイド：基本から、もっと活用まで
クライアントサイトを運用する Web 制作会社が、Miterl を 5 分で導入し、業務に組み込み、差別化に使うまでを 3 ステップで案内します。
なぜ Web 制作会社に Miterl が必要か
サイトを納品して終わり、ではなく「公開後の運用」までを請け負う制作会社にとって、サイトのダウンや SSL 切れに最初に気づくのは自社であるべきです。クライアントから「サイトが落ちている」と連絡が来た時点で、信頼は少し損なわれています。
Miterl は制作会社の運用業務を仕組み化するために設計されています。クライアント別の監視管理、メンテナンス窓の事前通知、月次レポート、ステータスページの提供、自社ブランド表示まで、必要な道具が一通り揃っています。
クライアントから先に連絡が来る
サイトが落ちていることをクライアントから知らされ、その都度信頼が削れていく状況を防ぎます。
案件が増えると管理しきれない
10 件、20 件と運用案件が増えると、エクセル管理では SSL 期限や障害履歴を追えなくなります。
保守料金の根拠が示せない
月額の保守費を請求しているのに、何をしているか説明できないと「高い」と言われ続けます。
このガイドの使い方
上から順に読んでも、必要な STEP だけつまみ食いしても構いません。各セクションには「ダッシュボードでやってみる」リンクがあるので、画面を開きながら進めてください。
まず使う
クライアント 1 サイトを 5 〜 10 分で監視に乗せて、Slack 通知とステータスページを公開します。
業務に組み込む
複数案件をクライアント別に整理し、メンテナンス窓・調査依頼・月次レポート・ホワイトラベルを使いこなします。
もっと活用
公開前監査、リリース集中監視、オンコール訓練、API 連携で、他社と差がつく運用体制を作ります。
1-1. クライアントのサイトを 1 つ監視する
まずは 1 つ、確実に動かしたいクライアントサイトを監視に登録します。コーポレートサイトなら HTTP / HTTPS タイプでトップページを指定するのが定番です。
登録手順
- ダッシュボード → 「監視追加」を開く
- 監視タイプ「HTTP / HTTPS」を選択し、URL を入力（例：https://example-client.com）
- 監視名は「（クライアント名）コーポレートサイト」のように分かりやすく
- 保存すると即座に監視開始。1 〜 5 分間隔でチェックされます
SSL 証明書の期限切れも自動で検知されます。HTTPS の URL を登録すれば、期限 30 日前から通知が届きます。
1-2. Slack / メールで通知を受け取る
監視を作っただけでは通知は届きません。通知先（アラート連絡先）を最低 1 つ設定し、監視に紐付けます。Slack なら 5 分で繋がります。
対応チャネル
- メール — どのプランでも利用可、複数アドレス登録可
- Slack — Incoming Webhook URL を貼るだけ、チャンネル別の振り分けも可能
- Chatwork — クライアント連絡で Chatwork を使うチームに最適
- LINE — 個人や少人数チーム向け、深夜の即気付きに有効
通知先を作ったら必ず「テスト送信」を実行してください。本番障害で初めて通知が届かないことに気づくのを防げます。
1-3. ステータスページを公開する
ステータスページは「今、サイトが正常か」をクライアント自身が確認できる公開ページです。問い合わせ前に状態を見てもらえるので、保守業務の負担が下がります。
制作会社での使いどころ
- クライアント自身が「落ちてる？」を確認 — 問い合わせ削減
- 障害発生時の最新状況をリアルタイムで共有 — 何度も同じ説明をしなくて済む
- 復旧後にメール購読者へ自動通知 — 継続的な信頼につながる
ここまでで、クライアント 1 サイトの「監視 → 通知 → 公開」の流れが完成しました。基本機能としてはこれで十分使えます。
2-1. クライアントグループで複数案件を整理する
案件が増えてくると「どれがどのクライアントの監視か」が分からなくなります。クライアントグループを使って、案件単位でまとめて管理します。
整理するメリット
- クライアント別の月次レポートが自動生成できる
- 通知先を案件ごとに振り分けられる（A 社は Slack、B 社はメール、など）
- 担当者が変わっても、誰が何を見ているか一目で分かる
2-2. メンテナンス窓で誤通知を防ぐ
WordPress 更新、サーバー再起動、DNS 切替など、計画的に止める作業の前にメンテナンス窓を登録します。窓の時間内はアラートが抑止されるので、深夜の誤通知で起こされません。
よくある使い方
- 毎月のサーバーメンテ（定期）— 第 2 水曜の深夜帯を年間予約
- リリース作業（単発）— 公開作業の前後 30 分を確保
- DNS 切替（単発）— 反映待ちの数時間を含めて広めに設定
2-3. 障害調査依頼を「窓口」として使う
クライアントから「サイトが重い」「動かない」と連絡が来たら、調査依頼フォームから受け付けます。フォームに沿って入力してもらうことで、必要な情報が抜けなく集まります。
受付の流れ
- クライアントから連絡 → 担当者が調査依頼を起票
- 症状・URL・スクリーンショット添付 → Miterl 側で調査
- 回答とともに該当インシデントを紐付け、再発防止策まで残せる
「窓口」として運用すると、過去の調査履歴がクライアント別に蓄積され、次回の対応スピードが上がります。
2-4. 月次レポートで保守費の根拠を示す
月末に「今月の稼働率 99.98%、障害 1 件、検知から復旧まで平均 12 分」というレポートを自動生成できます。クライアントへの月次報告にそのまま添付できます。
活用の仕方
- クライアントへの月次報告メールに PDF 添付 — 保守費の説得力が増す
- 稟議資料として — 「もっと厚い保守プラン」を提案する材料に
- 更新案件の継続提案で — 過去の稼働実績を見せる
2-5. 自社ブランドで提供する（ホワイトラベル）
ステータスページや通知メールに自社のロゴ・ブランド色を表示できます。クライアントから見ると「Miterl」ではなく、御社の保守サービスとして見えます。
カスタマイズできる項目
- ロゴ画像のアップロード
- ブランドカラー（ステータスページ・通知メールに反映）
- 「Powered by Miterl」表記の非表示（Standard プラン以上）
ここまで進めば、案件が 10 件、20 件と増えても運用が破綻しない仕組みができています。保守業務として「収益化」できる土台です。
3-1. 公開前監査で納品ミスを防ぐ
公開直前の WordPress サイトに「noindex が残っていないか」「robots.txt がブロックしていないか」「リンク切れはないか」を一括チェックします。納品後に発覚するとリカバリ工数が大きい問題を、公開前に潰せます。
チェック項目
- meta robots / X-Robots-Tag の noindex 残り
- robots.txt のクロール拒否設定
- 内部リンク切れ / 画像 404
- HTTPS / mixed content / 主要メタタグの確認
3-2. リリース集中監視で「30 分間だけ厚く見る」
本番リリースの直後 30 分は最も障害が起きやすい時間帯です。リリース集中監視を ON にすると、その時間だけチェック間隔を 30 秒に短縮し、終了後に「集中期間レポート」が残ります。
使い方
- 監視ページで「リリース集中監視を開始」
- デプロイ実行 → Miterl が高頻度で監視
- 終了後にレポートを確認、Slack に共有
3-3. オンコール訓練で「いざ」に備える
実際に障害が起きないと、通知が届くか・誰が一次対応するか・どう動くかが検証できません。ドリル機能は「擬似障害」を起こして社内のオンコール体制を訓練します。
ドリルは公開ステータスページには絶対に表示されません。社内訓練に閉じた仕組みです。
活用シーン
- 新人エンジニアの初動訓練
- 深夜帯の通知到達テスト（実害ゼロで実施できる）
- 障害ハンドオフ手順の年次見直し
3-4. API / Webhook で社内ツールと繋ぐ
Miterl の API キーを発行すれば、社内の管理画面・Notion・Backlog などと監視データを自動連携できます。Webhook で障害発生時に独自の処理を走らせることも可能です。
連携アイデア
- 社内案件管理ツールに「現在の監視状況」ウィジェットを表示
- 障害発生時に自動で Backlog 課題を起票
- CI/CD パイプラインから公開前監査を呼び出し、合格したら本番デプロイ
ここまで使い切ると、Miterl は単なる「監視ツール」ではなく、御社の保守サービスを支える基盤になります。クライアントへの提案資料にも組み込めるレベルです。
もっと深く知るには
このガイドはジャーニー型で「順番に進める」構成ですが、機能の詳細仕様や個別の質問には、以下のページが役立ちます。