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最適化の豊富な経験
エンタープライズホスティングの真のリスクは「不確実性」にあり：ダウンタイムより怖い見えない限界
エンタープライズ向けのWebサイト運営において、最大の懸念事項は「サイトが落ちること（ダウンタイム）」だと考えられがちだ。しかし、ダウンタイムのリスクは測定可能であり、技術的な対策も立てやすい。真にビジネスを脅かすのは、サイトがいつ、どのような条件下で不安定になるか予測できない「不確実性」である。
不確実性とは、プロモーション中にサーバーが耐えられるか、なぜチェックアウトが遅いのか、ユーザー増に伴いコストがどう変動するのかが「見えない」状態を指す。この不透明さは、ホスティングプロバイダーが提示する「無制限」という甘い言葉や、不完全な技術仕様によって引き起こされることが多い。
サイトの挙動を正確に予測できる能力は、単なる稼働率（アップタイム）の保証よりも価値が高い。予測可能性こそが、マーケティング投資の成果を確実にし、ビジネスの成果に直結するためだ。
ダウンタイムよりも恐ろしい「不確実性」というリスク
多くのホスティングプロバイダーは「リソース無制限」という夢を売るが、ITの世界に無制限など存在しない。CPUが処理できるリクエスト数、データベースに同時アクセスできるユーザー数、1秒あたりのPHPプロセス数には、必ず物理的な限界がある。
「無制限」という言葉の裏に隠された限界
元記事の著者であるCarlo Daniele氏は、プロバイダーが「無制限」という言葉を使うとき、それはパワーを提供しているのではなく、リソースの限界を隠しているだけだと指摘している。透明性の欠如は、管理者がデータに基づいた意思決定を行うことを妨げる最大の要因となる。
例えば、稼働率99.999%を保証するSLA（Service Level Agreement / サービス品質保証）があったとしても、それはサイトが「表示されていること」を保証するだけで、サイトが「正常に機能していること」を保証するものではない。高負荷時にショッピングカートの読み込みに10秒かかる状態は、技術的には「稼働中」だが、ビジネスとしては「ダウン」しているのと同義だ。
サイレント・ダウンタイムの恐怖
負荷が限界に達した際、一部のプロバイダーはサイトを完全に停止させるのではなく、利用可能なリソースを制限することでインフラを保護しようとする。具体的にはPHPのプロセス数を削減するなどの措置が取られるが、これによりサイトの動作は極端に重くなる。
ユーザーはイライラしてサイトを離脱し、広告予算は無駄になり、ブランドの評判は傷つく。ITチームは何が起きているのか把握できず、サポートからの返信を待つしかない。これが、不確実性がビジネスを殺すと言われる理由だ。
ビジネスの投資対効果（ROI）を左右するキャパシティ管理
ROI（Return on Investment / 投資利益率）を算出するためには、投資によって得られる「生産能力」を把握している必要がある。サーバーの限界を知らずにインフラ費用を支払うのは、積載量を知らずに貨物船をチャーターするようなものだ。
サーバー性能が広告予算を無駄にする仕組み
例えば、200万円を投じて大規模な広告キャンペーンを実施したとする。このキャンペーンにより、毎秒100件のトランザクション（決済処理）が発生すると予測されるが、サーバーが毎秒10件しか処理できない場合、残りの90件の機会損失が発生する。この状況下では、広告投資の価値は激減する。
Daniele氏によれば、ホスティングインフラが透明であれば、1秒間に処理できるトランザクション数を事前に計算できる。これにより、無駄なリソース確保（オーバープロビジョニング）を避けつつ、キャンペーンの成功に必要なスペックを正確に選定することが可能になる。
予測可能なインフラがもたらす戦略的メリット
インフラがブラックボックスではなく、制御可能な資産になれば、経営陣に対してデータに基づいたROI予測を提示できる。ホスティングは単なる「固定費」から、ビジネスを成長させるための「最適化可能なエンジン」へと進化する。
PHPスレッド：サイトの処理能力を決定付ける正体
WordPressサイトの真の処理能力を測る指標は、訪問者数ではなく「PHPスレッド数」である。これは、キャッシュされていないリクエストを処理するための専用プロセスのことだ。
PHPスレッドとは何か？
PHPスレッドは、サイトの裏側で働く「窓口担当者」のようなものだ。以下のようなアクションが発生するたびに、1つのスレッドが占有される。
- 顧客が商品をカートに追加し、データベースを更新する
- 予約投稿の公開や在庫情報の同期など、WordPressのバックグラウンド処理が走る
- Stripeなどの外部決済サービスやCRM（顧客管理システム）と通信する
- キャッシュにないページを表示するためにデータベースへクエリを投げる
スレッドが不足すると、新しいリクエストは「待ち」の状態になり、ユーザーのブラウザでは読み込み中を示すアイコンが回り続けることになる。自分のサイトに割り当てられたスレッド数を知ることは、不確実性を排除する第一歩だ。
スレッド不足が引き起こすチェックアウトの停滞
ECサイトにおいて、最もリソースを消費するのはチェックアウト（決済）プロセスだ。このプロセスはセキュリティと整合性の観点からキャッシュできないため、必ずPHPスレッドを消費する。同時購入者がスレッド数を超えた瞬間、サイトは「サイレント・ダウン」の状態に陥る。
透明性の高いホスティングが「不確実性」を排除する
不確実性を解消するためには、プロバイダーがアーキテクチャの透明性を確保している必要がある。具体的には、各サイトにどれだけのCPU、RAM、そしてPHPスレッドが割り当てられているかが明示されているべきだ。
コンテナ技術による「ノイジー・ネイバー」の解消
従来の共有サーバーでは、同じサーバー上の他サイトの負荷に影響される「ノイジー・ネイバー（うるさい隣人）」問題が避けられなかった。最新のマネージドホスティングでは、各サイトを独立したソフトウェアコンテナ（Linux, NGINX, PHP, MySQLを含む）に隔離することで、他者の影響を受けない安定した環境を提供している。
各コンテナに割り当てられたリソースが固定されていれば、他サイトの突発的なトラフィックに怯える必要はなくなる。この記事によれば、透明性の高い環境ではプランごとにスレッド数が定義されており、必要に応じて特定のサイトのスレッド数だけを増強することも可能だという。
APMツールによるパフォーマンスの可視化
不確実性を排除するもう一つの強力な武器が、APM（Application Performance Monitoring / アプリケーション性能監視）ツールだ。これは、PHPの処理時間、データベースのクエリ実行時間、外部へのHTTP呼び出しなどを詳細に追跡する仕組みを指す。
APMツールを活用すれば、決済処理に平均何秒かかっているかを特定できる。データに基づいた最適化を行えば、1リクエストあたりの処理時間を短縮でき、同じスレッド数でもより多くの同時アクセスをさばけるようになる。
自分のサイトの限界を知るための計算式
割り当てられたPHPスレッド数と、決済プロセスの平均処理時間がわかれば、サイトの理論的な限界値を算出できる。Daniele氏は以下のシンプルな数式を紹介している。
PHPスレッド数 ÷ 平均処理時間 ＝ 1秒あたりの最大動的リクエスト数
秒間リクエスト数を算出する数式
この数式を2つのシナリオで比較してみよう。
シナリオ1：低速なホスティングと未最適化のサイト
PHPスレッド数が10、決済に2秒かかる場合：
10 ÷ 2 ＝ 毎秒5リクエスト
シナリオ2：高速なホスティングと最適化されたサイト
PHPスレッド数が10、決済に0.5秒かかる場合：
10 ÷ 0.5 ＝ 毎秒20リクエスト
同じリソース（10スレッド）でも、最適化によって処理能力は4倍に跳ね上がる。この計算ができるようになれば、「なんとなく不安」という状態から脱却し、キャンペーンの規模に合わせた適切なプラン選択ができるようになる。
まとめ：この記事のポイント
- エンタープライズホスティングの真のリスクは、ダウンタイムではなく「予測不能な不確実性」である。
- 「無制限」という言葉はリソースの限界を隠すためのマーケティング用語であり、ITの世界には必ず物理的な限界が存在する。
- サイトの真の処理能力は「PHPスレッド数」によって決まり、これは決済などのキャッシュできない処理の同時実行数に直結する。
- 独立したコンテナ技術を採用したホスティングを選ぶことで、他サイトの影響（ノイジー・ネイバー問題）を排除できる。
- APMツールで処理時間を可視化し、数式に基づいてキャパシティを計算することで、データに基づいたROIの最適化が可能になる。
出典
- Kinsta Blog「Enterprise hosting risk isn’t downtime—it’s uncertainty」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験