2026年5月27日

Web制作会社向け Miterl 初期設定ガイド｜死活監視を保守メニューに組み込む手順

制作会社初期設定死活監視保守契約

「設定が複雑で導入が進まない」を解消する

制作会社が監視ツールを保守メニューに組み込もうとするとき、最初の壁になるのが初期設定の手間です。複数クライアント分のモニターを一つひとつ手動で作っていては、サイト数が増えるほど運用コストが膨らみます。

このガイドでは Miterl を制作会社が使い始める際の初期設定を、アカウント作成からクライアント向けステータスページの公開まで、一本通しで解説します。設定後は「障害調査込みの保守サブスク」として販売できる状態になります。

ステップ0：全体の流れを把握する

ステップ	内容	所要時間の目安
1	アカウント作成・プラン選択	5分
2	Workspace（クライアント単位）の作成	3分
3	モニターの追加（HTTP / SSL / DNS）	10〜15分
4	アラート通知チャンネルの設定	5〜10分
5	ステータスページの公開	5分
6	メンテナンス除外 Webhook の設定	5分

クライアント1社あたり30〜40分で監視体制が立ち上がります。2社目以降は API または設定コピーで半分以下の時間になります。

ステップ1：アカウント作成とプラン選択

まず Miterl に登録します。制作会社に向いたプランの選び方は次のとおりです。

Free: 3モニターまで。動作確認・社内テスト用
Standard: 複数クライアント対応、ホワイトラベル（Powered by 非表示）、ステータスページへの独自ドメイン対応
Pro: 月3件の障害調査代行（NDA締結でサーバー内部まで）、優先サポート。保守単価に「調査込み」を乗せて販売するならこのプラン

保守サービスとして販売する場合は Standard 以上を推奨します。ホワイトラベル機能でクライアントには「A社の保守サービス」として見せることができます。

ステップ2：Workspace の作成（クライアント単位で分ける）

クライアントごとに Workspace を分けることで、担当者の権限管理とレポートの切り分けが容易になります。

ダッシュボード左上のワークスペース名をクリック
「新しいワークスペースを作成」を選択
クライアント名を入力（例：「株式会社サンプル」）

担当のプロジェクトマネージャーには viewer 権限、エンジニアには member 権限を付与すると、監視ルールの変更を社内に限定しつつ、PMが状況を参照できます。

ステップ3：モニターを追加する

ダッシュボードから追加する

ダッシュボードの「＋モニターを追加」から設定します。制作会社の保守メニューとして提供する際の推奨設定は以下です。

監視タイプ	チェック間隔	用途
HTTP	1〜3分	ページの表示確認・レスポンスコード検証
SSL証明書	1日	証明書の期限切れ防止
DNS	1時間	DNS設定の変更・ハイジャック検知

API で一括追加する（複数サイト対応）

2サイト目以降は API を使うと格段に速くなります。API キーはダッシュボードの「設定 → API キー」から発行できます。

# 1. HTTP モニターを追加する例（クライアントのコーポレートサイト）
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "株式会社サンプル - コーポレート",
    "url": "https://example-client.co.jp",
    "type": "http",
    "interval_seconds": 180,
    "alert_contact_ids": [1, 2]
  }'

# 2. SSL証明書モニターを同サイトに追加
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "株式会社サンプル - SSL",
    "url": "https://example-client.co.jp",
    "type": "ssl",
    "interval_seconds": 86400,
    "ssl_expiry_alert_days": 30,
    "alert_contact_ids": [2]
  }'

複数クライアントの初期設定をスクリプト化しておくと、新規保守契約が取れたその日に監視体制が立ち上がります。

ステップ4：アラート通知チャンネルを設定する

障害発生時の通知先を設定します。制作会社として運用する場合、「社内への即時通知」と「クライアントへの報告フロー」を分けて考えるのがポイントです。

Slack（社内エンジニア向け）

Slack の通知先はダッシュボードの「アラート連絡先」で Slack Webhook URL を登録して作成します。API では作成済みの連絡先 ID を取得し、モニター作成時の alert_contact_ids に指定して紐付けます。

# 登録済みのアラート連絡先と ID を一覧取得
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY"
# → 返ってきた id を、モニター作成時の alert_contact_ids に渡す

メール（クライアント担当 PM 向け）

ダッシュボードの「アラート連絡先」から担当 PM のメールアドレスを追加し、モニターに紐付けます。クライアントに直接通知を送りたくない場合は PM のみに設定し、PM がクライアントへ連絡するフローを社内で決めておくとスムーズです。

通知チャンネルの使い分け

通知先	用途
Slack `#oncall`	エンジニアへの即時通知・対応開始のトリガー
メール（PM）	平日日中の報告・エスカレーション管理
LINE / SMS	深夜・休日の緊急連絡（重要度高のサイトのみ）

ステップ5：ステータスページを公開する

保守サービスの信頼性をクライアントに見せる上で、ステータスページは重要な差別化ポイントです。

ダッシュボードで「ステータスページ」を選択
表示するモニターを選び、ページ名・説明を設定
公開設定を「公開」にする

独自ドメインで公開する（Standard 以上）:

クライアントの DNS に次の CNAME レコードを1行追加するだけです。

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

これで status.client.co.jp にアクセスするとクライアントブランドのステータスページが表示されます。「Powered by Miterl」表記も Standard プラン以上では非表示にできます。

ステップ6：メンテナンス除外 Webhook を設定する

WordPress のメジャーバージョンアップやサーバー移行など、意図的なダウンタイムが発生する作業時に、Slack が誤検知で鳴り続ける問題を防ぎます。

Webhook トークンはダッシュボードの「設定 → メンテナンス Webhook」から発行します。

# デプロイ・作業開始前
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/start \
  -H "Content-Type: application/json" \
  -d '{"duration_hours": 2, "name": "WordPress 6.5 アップデート"}'

# --- ここで WordPress 更新・サーバー作業を実施 ---

# 作業完了後
curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$MITERL_TOKEN/end

duration_hours を設定しているため、END を呼び忘れてもタイムアウトで自動解除されます。GitHub Actions や Bitbucket Pipelines のデプロイスクリプトに2行追加するだけで完了です。

設定完了後の確認チェックリスト

全モニターが「稼働中（UP）」ステータスになっている
テストアラートを送信し、Slack・メールへ届くことを確認
ステータスページが正しく表示される（独自ドメインも確認）
メンテナンス Webhook をテスト発行し、期間中はアラートが止まることを確認
担当 PM に Workspace の viewer 権限を付与済み

保守サービスとして売り出すために

初期設定が完了したら、クライアントへの提案に進みます。「障害調査込みの保守サブスク」として提案する際のトーク例です。

「現在の保守契約では、障害に気づくのがお客様側になってしまう場合があります。Miterl の導入により、24時間365日の自動監視で障害を平均3分以内に検知し、平日営業時間内であれば原因調査まで当社で対応します。月次稼働率レポートも自動生成されますので、透明性の高い保守サービスを提供できます。」

管理するサイト数が増えてきたら、タグ・Workspace管理・アラートルールの整理など運用上のベストプラクティスも重要です。「複数サイト監視を効率化する10のヒント——制作会社向け運用術」では、20〜50サイト規模の制作会社向けに通知疲れの防止と監視コストの最適化をまとめています。

料金設計や ROI の試算については Web制作会社向け死活監視 ROI 比較を参考にしてください。保守契約への組み込み方の全体像は制作会社が死活監視を保守契約に組み込む5つの理由でも解説しています。

実際の運用フロー（Workspace 分離・障害調査依頼・月次レポート自動化）は制作会社向けユースケースでシナリオベースにまとめています。

機能の詳細はドキュメントで確認できます。導入前の疑問はよくある質問もあわせてご覧ください。