保守契約の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": 300,
    "alert_contact_ids": [1, 2]
  }'

interval_seconds の最小値はプランごとに異なります（無料プランは300秒＝5分が下限）。より短い間隔で計測したい場合は上位プランへのアップグレードが必要です。

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

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

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

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

SLAを約束する前に、まず1〜3か月間、実際の稼働率を計測します。「99.9%を保証する」と言っておいて実績が99.7%だった、という事態を防ぐためです。Miterl の無料プランでも稼働率の実績データは取得できますが、チェックログの保持期間はプランによって異なります（無料プラン7日、Standard30日、Pro180日）。数か月単位で実績を追いたい場合はStandard以上のプランを検討してください。

ステップ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レポート自動化ガイド」で詳しく解説しています。

なお、月次レポートをメールで送付する運用にしている場合、送信ドメインのSPF・DKIM・DMARCが正しく設定されていないと、せっかく作成したレポートが迷惑メールフォルダに振り分けられたり、クライアントに届かないまま気づかれなかったりすることがあります。レポート配信を仕組み化する前に、送信ドメインの認証設定が正しいか一度確認しておくと安心です。確認手順は「SPF・DMARC・DKIMの設定確認手順」にまとめています。

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

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

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

回避策: SLAの定義に「HTTPステータスコード2xxが返っていることを稼働と定義する。レスポンスタイムは計測対象外」と明記する。または「レスポンスタイムが○秒以内」を追加指標として合意する。どのステータスコードを障害と判定し、何回連続の失敗でダウンと確定するかという判定ロジックの詳細は「HTTP応答障害を検知する監視設定ガイド」で解説しています。

落とし穴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分に設定済み（頻度が粗いと稼働率が水増しされる。無料プランは5分が下限のため、1〜3分にするにはStandard以上のプランが必要）
• アラート通知先（Slack・メール）を設定済み
• エスカレーション設計を完了済み（SLA違反の恐れがある障害時に、誰に・何分後・どの経路で通知するか）
• メンテナンスウィンドウを設定済み（計画メンテ中はアラート停止）
• 月次レポートの自動生成・送付を設定済み

SLAで保証するレスポンスタイムを設定する場合の閾値設計は「レスポンスタイム監視ガイド：HTTP応答障害を早期検知する方法」を参照してください。稼働率の数値（99.9%・99.99%）とダウンタイムの換算は「稼働率99.9%と99.99%の違いとは？ダウンタイム換算と計算方法」で詳しく解説しています。SLAの数値を約束しても、実際に障害が起きたときに誰が対応するかが曖昧では意味がありません。通知の段階設計は「監視アラートのエスカレーション設計｜誰に・何分後・どの経路で通知するか」を参照してください。

よくある質問

保守SLAとはそもそも何ですか？

保守契約における「稼働率」「復旧時間」「通知時間」など、提供するサービス品質の最低ラインを文書で約束したものです。死活監視の文脈では特に稼働率（Uptime）が中心指標になりますが、数値だけでなく「何を計測対象とし、何を免責とするか」まで含めて合意しておかないと、後から「障害の定義」を巡ってクライアントとトラブルになります。

SLAの目標稼働率はどう決めればいいですか？

最初から数値を約束するのではなく、まず1〜3か月間の実績を計測してから、その実績に見合う数値を設定するのが安全です。コーポレートサイトなら99.9%が基本で、ECサイトや予約システムなど売上に直結するサイトでは99.99%を検討します。ただし99.99%は運用負荷が高く「技術的には可能だが現実的でない」ケースも多いため、制作会社側でコントロールできない第三者障害（ホスティング・CDN等）は目標値の対象から明示的に除外しておくことが重要です。

SLAの稼働率99.9%とは具体的にどういう意味ですか？

月間の稼働時間の99.9%以上を正常稼働として保証するという意味です。逆算すると月間で許容される停止時間は約43.8分になります。この数値には通常、事前に合意した計画メンテナンス時間は含まれません（免責事項として別途定義します）。ダウンタイム換算の詳細は「稼働率99.9%と99.99%の違いとは？」を参照してください。

保守契約でSLAを設定するのは義務ですか？

法的な義務ではありませんが、稼働率の目標値を明記していないと「障害が起きたのは誰の責任か」でクライアントとトラブルになりやすくなります。特に稼働率の低下が売上に直結するECサイトや予約システムでは、SLAを明文化しておくことでトラブルを未然に防げます。

SLA違反時のペナルティ（サービスクレジット）の相場はどれくらいですか？

月間稼働率が目標を下回った場合、当月または翌月費用の10〜50%をクレジット（返金）するケースが一般的です。稼働率がどれだけ下回ったかに応じて段階的にペナルティ率を上げる設計が多く、上限（例: 当月費用の100%まで）を必ず定めておくことが重要です。

稼働率の計測はどのツールを使えば良いですか？

どのツールを使うかより「どのツールを正とするか」を契約書に明記することが重要です。Miterlのような外形監視ツールで対象URLを短い間隔（プランにより1〜5分）で計測し、その計測結果をSLA判定の一次情報として扱うのが一般的な設計です。

まとめ

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

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

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