保守契約のSLAはどう決める？稼働率99.9%の合意手順と落とし穴

保守契約の更新時に「SLAはどのくらいにしますか？」とクライアントから問われた際、「99.9%で」と即答できる制作会社はそれほど多くありません。しかし適当な数字を口約束すると、後になって「うちのサイトが落ちたのはSLA違反では？」というトラブルになることがあります。

このガイドでは、Web制作会社がクライアントとSLAを合意する際の具体的な手順と、よくある落とし穴を解説します。

SLAとは何か（30秒でわかる定義）

SLA（Service Level Agreement）は「サービス品質の最低保証ラインを文書化した合意」です。死活監視の文脈では、主に以下の指標が使われます。

SLAの核心は「何を計測して、どこまでが免責か」を事前に合意しておくことです。

稼働率の数値：99.9%と99.99%の選び方

稼働率の表記は「ナイン（9）の数」で表します。各レベルのダウンタイム換算は以下の通りです。

制作会社の現実的な選択肢

99.9%が適切なケース:

• コーポレートサイト・情報発信型サイト
• 夜間の障害に翌朝対応する運用体制
• 少人数チームで24時間対応体制が取れない

99.99%を検討するケース:

• ECサイト・予約システムなど売上に直結するサイト
• 金融・医療など業界規制がある場合
• 24時間対応体制を整備済みの場合

現実的なアドバイス: 多くの制作会社にとって99.99%の保証は「技術的には可能だが、リソース的に現実的でない」数値です。インフラに依存する部分（ホスティング側の障害）は制作会社がコントロールできないため、コントロールできる範囲だけを保証対象にすることが重要です。

SLAの計測範囲を定義する

数値よりも重要なのが「何を計測するか」の定義です。

計測対象の設定

計測対象URL例:
- https://example.com/（トップページ）
- https://example.com/contact/（お問い合わせフォーム）

計測除外:
- 第三者のCDN・外部APIの障害
- 合意したメンテナンスウィンドウ（毎週日曜 03:00〜05:00 JST）
- クライアント起因の問題（DNS変更ミス・コンテンツ更新による503等）

Miterlでの設定例

Miterl では複数のモニターを設定し、各URLを個別に計測できます。

# トップページモニターの作成
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/",
    "name": "example.com - コーポレートサイト",
    "type": "http",
    "interval_seconds": 60,
    "alert_contact_ids": [1, 2]
  }'

稼働率は uptime_30d フィールドで自動集計されます。

# 月間稼働率の取得
curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '{name: .name, uptime_30d: .uptime_30d}'
# 出力例: {"name": "example.com - コーポレートサイト", "uptime_30d": 99.97}

クライアントとの合意プロセス

ステップ1: 現状の計測から始める

SLAを約束する前に、まず1〜3か月間、実際の稼働率を計測します。「99.9%を保証する」と言っておいて実績が99.7%だった、という事態を防ぐためです。Miterl の無料プランでも稼働率の実績データは取得できます。

ステップ2: 免責事項を先に決める

以下の項目は、事前にクライアントと合意しておくことで後のトラブルを防げます。

• 第三者起因の障害: ホスティング会社・CDN・ドメインレジストラのシステム障害
• クライアント操作による停止: CMS管理画面での誤操作、DNS設定変更
• 自然災害・不可抗力: 大規模なインフラ障害（AWS・GCPの大規模障害等）
• 計画メンテナンス: 事前通知済みのメンテナンスウィンドウ内の停止

ステップ3: 違反時のペナルティを現実的に設定する

SLAを下回った場合のペナルティは、「月次費用の何%を返金する」という形式が一般的です。

重要: ペナルティの上限を設けることも忘れずに（「最大でも当月費用の100%を上限とする」等）。

ステップ4: レポートサイクルを決める

SLAの達成状況は月次で報告することを契約書に明記します。Miterl では月次レポートの自動生成が可能です。

# 月次稼働率レポートの自動取得スクリプト
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | "[\(.name)] 月間稼働率: \(.uptime_30d)%"'

月次レポートの自動生成から配信まで仕組み化する手順は「保守サブスク向けSLAレポート自動化ガイド」で詳しく解説しています。

よくある落とし穴と回避策

落とし穴1: 「稼働率」の定義が曖昧

問題: クライアントが「サイトが重かった」を障害とみなし、SLA違反を主張する。

回避策: SLAの定義に「HTTPステータスコード200が返っていることを稼働と定義する。レスポンスタイムは計測対象外」と明記する。または「レスポンスタイムが○秒以内」を追加指標として合意する。

落とし穴2: 計測ツールが変わると数値も変わる

問題: 途中で監視ツールを変更したことで、計測方法が変わり数値が変動する。

回避策: SLA合意書に「Miterl（https://miterl.com）の計測データを正とする」と計測ツールを明記する。

落とし穴3: 第三者障害の取り扱い

問題: AWSの大規模障害でサイトが落ちた場合、制作会社の責任か問題になる。

回避策: 「Miterl の障害レポートで第三者起因と記録された障害は免責対象」と明記する。Miterl では障害原因のメモを記録できるため、後から証跡として提示できます。

落とし穴4: 深夜・休日の対応について

問題: 「24時間365日稼働率99.9%保証」と言ったが、深夜の障害には翌朝対応になる。

回避策: SLAは「稼働率の計測」と「障害対応時間」を分けて定義する。「稼働率99.9%を計測する（24時間365日）」と「障害通知から対応開始まで: 営業時間内は30分以内、夜間・休日は翌営業日10時まで」を別条項に分けるとトラブルが減ります。

SLA合意書テンプレート（抜粋）

■ サービスレベル合意書（抜粋）

1. 稼働率の定義
   本サービスにおける稼働率は、Miterl（https://miterl.com）の
   HTTPモニターがHTTPステータスコード2xxを返した時間の割合とします。

2. 計測対象URL
   - https://example.com/
   （追加URLは別紙に定める）

3. 目標稼働率
   月間稼働率: 99.9%以上

4. 計測除外
   a) 月1回・最大2時間の計画メンテナンス時間（事前通知要）
   b) ホスティング会社・CDN等の第三者サービス起因の障害
   c) クライアント操作（DNS変更・CMS操作等）に起因する停止

5. SLA未達時の措置
   月間稼働率が99.9%を下回った場合、翌月費用から10%を減額します。
   ただし減額上限は月額費用の100%とします。
   
6. 報告
   毎月末日に前月の稼働率レポートを電子メールで送付します。

SLA設計が完了したら：監視設定のチェックリスト

• 計測対象URLをMiterlに登録済み
• 監視間隔を1〜3分に設定済み（頻度が粗いと稼働率が水増しされる）
• アラート通知先（Slack・メール）を設定済み
• メンテナンスウィンドウを設定済み（計画メンテ中はアラート停止）
• 月次レポートの自動生成・送付を設定済み

SLAで保証するレスポンスタイムを設定する場合の閾値設計は「レスポンスタイム監視ガイド：HTTP応答障害を早期検知する方法」を参照してください。稼働率の数値（99.9%・99.99%）とダウンタイムの換算は「稼働率99.9%と99.99%の違いとは？ダウンタイム換算と計算方法」で詳しく解説しています。

まとめ

保守契約のSLA設計は「数値を決める」ことよりも「計測範囲と免責事項を明確にする」ことの方が重要です。

• まず実績計測（1〜3か月）してから数値を約束する
• 制作会社がコントロールできない障害（第三者・クライアント操作）は明示的に除外する
• 「稼働率の計測」と「障害対応時間」を分けて定義する
• 月次レポートで達成状況を定期的に可視化する

SLAを設定したら、次は月次レポートの作成フローを自動化しましょう。「稼働率レポートの作り方｜SLAを満たすクライアント報告テンプレート」でレポートの構成例と提出タイミングの設計を確認してください。月次レポートの配信まで自動化する実装手順は「保守サブスク向けSLAレポート自動化ガイド」で解説しています。詳しい機能はドキュメントで確認できます。導入前の疑問はよくある質問もあわせてご覧ください。まずは無料プランで登録して、計測を始めてみましょう。