Web制作会社がホスティング選定で重視すべきSLAと保証のチェックポイント
Webサイトの公開直後にサーバーがダウンしたり、サポートの返信が来なかったりするトラブルは、多くの制作現場で頭を悩ませる問題だ。こうした事態を防ぐための指標となるのが、SLA（Service Level Agreement / サービス品質保証）である。
SLAとは、サービス提供者が利用者に対して「どの程度の品質を保証するか」を明文化した合意書を指す。多くのホスティング会社が「高い信頼性」を謳うが、具体的な数字や補償内容が伴わなければ、それは単なるスローガンに過ぎない。
特に複数のクライアントサイトを管理するエージェンシーにとって、インフラの安定性は自社の信頼に直結する。この記事では、ホスティングパートナーを選ぶ際に確認すべきSLAの核心と、見落としがちな保証の裏側について詳しく掘り下げていく。
SLAの正体とWeb制作会社が注視すべき理由
SLAは、ホスティングプロバイダーが提供するサービスの品質を定義し、その目標が達成されなかった場合の救済措置を定めた正式な文書だ。これには稼働率の目標値、サポートの応答時間、セキュリティ対応などが含まれる。
SLAは「単なる努力目標」ではない
マーケティング資料で見かける「高速なパフォーマンス」や「専門家によるサポート」といった言葉には、客観的な基準がない。一方でSLAは、これらを測定可能な数値で定義する。例えば「月間稼働率99.9%を維持し、下回った場合は利用料金の一定割合を返金する」といった具体的な約束事だ。
KinstaのCarlo Daniele氏によれば、SLAはプロバイダーが自社のサービスにどれだけの責任を持っているかを示す指標となる。障害が起きた際のフレームワークが事前に決まっていることで、利用者側はリスク管理がしやすくなるという利点がある。
クライアントへの信頼性に直結するインフラの裏付け
Web制作会社にとって、ホスティングのトラブルは自社のトラブルとしてクライアントに認識されることが多い。サーバーが原因のダウンタイムであっても、クライアントが最初に連絡を入れるのは制作担当者だからだ。
明確なSLAを持つパートナーを選んでおけば、万が一の際にも「どのような保証があるか」「いつまでに復旧が期待できるか」をクライアントへ論理的に説明できる。これは、制作会社のプロフェッショナリズムを守るための防波堤となるのだ。
稼働率99.9%の落とし穴と数字の読み解き方
ホスティングの比較で最も頻繁に目にするのが「稼働率（Uptime）」のパーセンテージだ。一見すると99.9%も99.99%も大差ないように思えるが、年間の停止時間に換算するとその差は歴然としている。
わずか0.01%の差が年間ダウンタイムに与える影響
稼働率の数字が意味する「許容される停止時間」を整理してみよう。以下のデモ表は、各稼働率における年間の最大停止時間を示している。
この表からわかる通り、99.9%の保証では年間で1営業日近い停止が発生する可能性がある。ECサイトや広告キャンペーン中のランディングページにとって、数時間の停止は大きな機会損失につながるため、この差は無視できない。
ネットワーク層かアプリケーション層か：測定範囲の重要性
稼働率をどこで測定しているかも重要なチェックポイントだ。一部のプロバイダーは「ネットワークの稼働」のみを保証し、サーバー上のアプリケーション（WordPressなど）が正常に動作しているかどうかを保証対象外としている場合がある。
実務においては、ネットワークが生きていてもデータベース接続エラーでサイトが表示されなければ「ダウン」と同じだ。アプリケーションレベルでの稼働を監視し、保証に含めているプロバイダーの方が、Web制作の実務に即しているといえるだろう。
サポートとパフォーマンスの保証をどう評価するか
サーバーが動いていることと同じくらい重要なのが、問題が発生したときの「人の対応」と、平常時の「表示速度」だ。これらもSLAの対象となることがある。
応答時間と解決時間は別物である
サポートのSLAでよく見られるのが「初回応答時間（First Response Time）」だ。これはチケットを発行してから最初の返信が来るまでの時間を指す。しかし、ここには落とし穴がある。最初の返信が自動送信メールや「確認します」というだけの定型文であっても、応答時間はカウントされてしまうからだ。
本当に評価すべきは、問題を解決するまでのプロセスや、技術レベルの高いエンジニアに直接つながる仕組みがあるかどうかだ。24時間365日の対応はもちろん、緊急時のエスカレーションパス（上位エンジニアへの引き継ぎルート）が明確に定義されているかを確認したい。
インフラ構成がパフォーマンス保証の根拠となる
パフォーマンスに関する保証は、単なる数値目標よりも「それを実現するためのインフラ」に注目すべきだ。例えば、以下のような要素がSLAの信頼性を支える技術的根拠となる。
- 隔離されたコンテナ環境：他のサイトの負荷影響を受けない仕組み
- 自動スケーリング：急激なトラフィック増に対応できるリソース配分
- グローバルなCDN統合：物理的な距離による遅延を最小化する配信網
これらの技術が組み込まれているプロバイダーは、結果として安定したレスポンスタイムを提供できる可能性が高い。パフォーマンスの低下は直帰率の増加やSEO順位の下落を招くため、インフラの堅牢性はビジネス上の成果に直結する。
セキュリティとバックアップに関する合意事項
セキュリティ事故が起きた際、誰がどこまで責任を負うのかを明確にすることもSLAの役割だ。特にWordPressのようなCMSを利用する場合、プラットフォーム側の保護範囲を知っておく必要がある。
マルウェア除去とDDoS対策の責任範囲
多くのプロバイダーがセキュリティ対策を謳っているが、実際にサイトが改ざんされた際の「無償での復旧」までを保証しているケースは限られる。SLAの中にマルウェアの検出だけでなく、除去作業が含まれているかどうかは大きな分かれ目だ。
また、DDoS攻撃（大量のアクセスでサーバーを麻痺させる攻撃）に対するネットワークレベルの防御が標準で含まれているかも確認したい。攻撃を受けてから対策を追加するのではなく、インフラ側で常にトラフィックを監視・遮断する体制が保証されているのが理想的だ。
RTO（目標復旧時間）とRPO（目標復旧時点）の確認
バックアップは「取っていること」よりも「戻せること」が重要だ。ここで重要になるのがRTO（Recovery Time Objective / 目標復旧時間）とRPO（Recovery Point Objective / 目標復旧時点）という概念である。
- RTO：障害発生からどれだけの時間で復旧させるか（例：2時間以内）
- RPO：どの時点のデータまで戻せるか（例：1時間前のバックアップまで）
これらが明文化されているホスティングサービスは、万が一のデータ消失時にも事業継続性を担保しやすい。制作会社としては、クライアントの要件に合わせてこれらの指標をチェックする必要がある。
契約前に確認すべき「隠れた制限事項」と除外規定
SLAには必ずといっていいほど「除外規定（Exclusions）」が存在する。ここを読み飛ばすと、いざという時に保証が受けられない事態になりかねない。
最も一般的な除外項目は「計画メンテナンス」だ。サーバーのアップデートなどのために事前に通知された停止時間は、稼働率の計算から除外されるのが通例だ。ただし、その頻度や時間帯（深夜帯かどうかなど）が適切かどうかは確認しておくべきだろう。
また、アプリケーション層の不具合も除外されることが多い。例えば、特定のプラグインが原因でサイトが真っ白になった場合、それはサーバーの責任ではなく利用者の責任とみなされる。SLAがカバーするのはあくまで「ホスティング側がコントロールできる範囲」であることを理解しておく必要がある。
さらに、補償の申請方法も重要だ。稼働率を下回った場合に自動で返金（クレジット付与）されるのか、あるいは利用者側がログを添えて申請しなければならないのか。WP Mayorなどの専門メディアでも指摘されている通り、申請の手間が壁となり、実質的に補償を受けられないケースも少なくない。
独自の分析：マネージドホスティングがSLAを強化する理由
筆者の見解として、SLAの信頼性を最も高めるのは「マネージド（管理代行型）」の運用体制だ。単にサーバーを貸し出すだけのサービスとは異なり、マネージドホスティングはプラットフォーム全体を最適化し、プロアクティブ（先回り的）な監視を行う。
問題が起きてからSLAに基づいて補償を求めるよりも、問題が起きないように常にリソースを調整し、脆弱性をパッチで塞ぐ運用のほうが、結果としてWeb制作会社のコスト（対応工数）を抑えられる。SLAの数字そのものだけでなく、その数字を維持するための「運用の質」に投資するという視点が重要だ。
エージェンシーにとっては、自社のエンジニアがサーバーの保守に時間を取られるのを防ぎ、本来の業務であるクリエイティブやマーケティングに集中できる環境を作ることこそが、真のSLAの価値といえるのではないだろうか。
この記事のポイント
- SLAは単なる宣伝文句ではなく、品質未達時の救済措置を含む法的合意である
- 稼働率99.9%と99.99%の間には、年間で約8時間の停止時間の差が存在する
- サポートの評価は「返信の速さ」だけでなく「解決までの技術力」を重視すべき
- セキュリティやバックアップの保証範囲を確認し、責任の所在を明確にする
- 計画メンテナンスやユーザー起因のトラブルなど、SLAの除外規定を必ずチェックする
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験