ナレッジ

レジデンシャルプロキシのSLAと稼働時間保証を解説

プロキシのSLAが対象とするのはゲートウェイの可用性であり、ターゲット側がアクセスを通すかどうかではありません。ここでは、数値が実際に何を保証しているのか、契約前に確認すべき点を説明します。

James Meadow

James Meadow

2026年8月25日 · 1 分で読める

プロキシネットワークを本番のパイプラインに組み込むなら、調達担当者やプラットフォームエンジニアリング担当者が、いずれSLAはどうなっているのかと尋ねてくるはずです。それは当然の質問ですが、返ってくる答えは見た目ほど有益ではないことが多いものです。99.9%というような数字は、何を基準に、どの期間で測定されているか、そして達成できなかった場合にどうなるかがわからなければ意味を持たないからです。

このカテゴリには特有の落とし穴もあります。プロキシのSLAが約束するのは、ゲートウェイに到達可能であることです。収集対象のサイトがあなたのリクエストを通してくれることは約束していません。これらはまったく別のことです。この境界を理解しておくことが、契約書に署名する前に必要な知識の大部分を占めます。

アップタイムの数値が実際に意味すること

パーセンテージの背後には3つの変数があり、パーセンテージだけを提示するプロバイダーは、最も有益でない部分だけを提示していることになります。

1つ目は測定期間です。月次で99.9%のSLAは、月あたり約43分のダウンタイムを許容します。同じ99.9%を年次で測定すると、約8時間45分のダウンタイムが許容され、しかもそれが連続していても構いません。月次のほうが明確に厳しく、年次の数値を提示するプロバイダーは、同じ言葉を使いながらより弱い約束をしていることになります。

2つ目はダウンタイムの定義です。ゲートウェイが接続を拒否したときだけをダウンとみなすのか、それとも技術的には応答しているもののエラー率が急上昇していたり、レイテンシーが使い物にならないほど劣化していたりする場合も含むのか。多くのSLAは完全な利用不能状態のみをカウントしており、これはつまり、すべてのリクエストがエラーを返しているのにエンドポイントが接続自体は受け付け続けている期間が、まったくダウンタイムとして記録されない可能性があるということです。

3つ目は誰が測定するかです。プロバイダーが唯一の情報源であり、独立した記録を公開していない場合、その数値は自己申告に過ぎません。インシデント履歴を含む公開ステータスページがあってこそ、検証可能になります。

最も重要な区別:ゲートウェイのアップタイムは成功率ではない

これがチームを見誤らせる部分であり、率直に述べておく価値があります。

アップタイムSLAが対象とするのはプロバイダーのインフラです。つまり、ゲートウェイが接続を受け入れ、認証を行い、リクエストをルーティングすることです。それはプロバイダーが制御できる範囲であり、彼らが約束しているのはその部分です。

対象外なのは、ターゲットサイトがそのリクエストを受け入れるかどうかです。サイトが出口アドレスをブロックしたり、チャレンジページを返したり、空の結果を返したりしても、それはダウンタイムではありません。プロキシは仕事をこなしています。それでもあなたの収集は失敗しています。第三者のサイトに対する成功率を保証できるプロキシプロバイダーは存在しません。なぜなら、決定権はサイト側にあり、サイトは予告なく防御策を変更し、月曜日にはターゲットを突破できていた同じプールが、金曜日には苦戦することもあるからです。任意のターゲットに対する成功率を保証すると謳うプロバイダーがいれば、それは自分たちの制御の及ばないものを約束していることになります。

したがって、調達担当者にとっての実務上の帰結は次のとおりです。SLAはプロバイダー側の故障からあなたを守るものであり、それ以外のすべてからあなたを守るのは自分たちの監視です。両方が必要であり、両者を混同すると、契約上は保護されているのに運用面では何も見えていないチームができあがります。そのためにパイプラインの監視が必要であり、SLAがカバーしていると思い込むのではなく、ターゲットごと・地域ごとに検証済みの成功率を測定するのです。また、ブロックや偽コンテンツの検出が重要なのもそのためです。200を伴って返されるチャレンジページは、SLA上は準拠した応答でありながら、同時にデータとしては失敗しているのです。

サービスクレジットの実際の価値

SLAが達成できなかった場合の標準的な救済策はサービスクレジットです。通常は月額料金の一定割合を、目標をどれだけ下回ったかに応じてスケーリングし、将来の請求書に適用します。

その規模については冷静に見る必要があります。クレジットはあなたがプロバイダーに支払った金額を基準に計算されるのであって、そのダウンタイムがあなたに与えた損害を基準にするものではありません。4時間のゲートウェイ障害があなた自身の商業的判断を左右する価格フィードを停止させたとしても、クレジットは月額プロキシ料金のわずかな一部にすぎず、ビジネスへの影響はあなた自身が負うことになります。クレジットは説明責任のメカニズムであり、プロバイダーがその約束を真剣に受け止めているというシグナルではありますが、保険ではありません。

確認しておく価値のある機械的な詳細が2つあります。クレジットは通常自動では発行されません。多くの契約では、多くの場合30日という期間内に、自分自身の証拠とともに申請することが求められます。そして、クレジットには通常、月額料金の一定割合という上限が設けられています。どちらも一般的なことですが、必要になる前に知っておくべきです。

注意深く読むべき除外事項

SLAが実際に定義されているのは除外事項のセクションです。標準的で妥当な除外事項には、事前に告知された定期メンテナンス、不可抗力、そしてプロバイダーが運用していないネットワークにおける障害が含まれます。以下には注意してください。

上限や告知期間のない定期メンテナンス。これは事実上、プロバイダーが事前に宣言したダウンタイムを何でも除外できることを意味します。「顧客側の設定ミス」を理由とする除外が、通常の利用まで含むほど広く定義されている場合。第三者に関する除外が非常に広く書かれていて、実際に故障の大半を占める上流ネットワークの問題が約束の対象外になってしまう場合。そして、利用不能とは別に「劣化」を除外している場合。これは、遅いけれども動いてはいるサービスがカウントを免れる方法です。

また、SLAが実際に依存しているコンポーネントをカバーしているかどうかも確認してください。プロキシ事業にはいくつかの要素があります。ゲートウェイ、パネルと認証、請求、そして各種APIです。ゲートウェイはカバーしているが認証は除外されているSLAは、あまり保護になりません。認証できないゲートウェイに到達可能であっても使えないからです。

署名する前に主張を検証する方法

SLAは未来についての約束ですが、検証できるのは現在と過去のことです。

まずステータスページから始めましょう。リアルタイムのステータス、そしてそれ以上に重要な公開インシデント履歴は、どのくらいの頻度で障害が起きているか、どれだけ迅速に認識されているか、事後報告が誠実かどうかを教えてくれます。公開ステータスページを持たないプロバイダーは、アップタイムを信用してほしいと言っているに等しいのです。Shifterはstatus.shifter.ioで公開しており、ゲートウェイ、ISP IP、各種API、パネルと認証、請求が別々のサブサービスとして追跡されています。これはまさに求めるべき粒度で、どのコンポーネントが障害を起こしたかを把握できます。

次に、評価期間中に自分自身で測定してみましょう。自社のインフラから低頻度でゲートウェイへの可用性チェックを試用期間中に実行すれば、マーケティング上の数字ではなく独立した記録が得られます。それを実際のターゲットに対する適切な成功率テストと組み合わせれば、速度、成功率、位置情報の精度をテストする方法にあるように、サービスが稼働しているかどうかと、それが自分にとって機能するかどうかの両方がわかります。

最後に、サポートの応答時間を確認してください。実務上は、これがクレジットよりも重要な意味を持つことが多いからです。午前2時に何かが壊れたとき、復旧の速さを左右するのは翌月の請求書に表示されるパーセンテージではなく、人間がどれだけ早く応答するかです。

Shifterが公開している内容

参考までに、公開されているティアは次のとおりです。StarterからGrowthまではベストエフォートで、通常99.5%以上。BusinessからProまでは正式なクレジットメカニズムなしで月次99.9%のアップタイム。Enterpriseでは、署名済み契約に基づくサービスクレジット付きで99.9%となっており、月額支出を基準に計算され、次回請求時にアカウントクレジットとして支払われます。サポートの応答時間も同様に段階分けされており、エントリープランのベストエフォートチャットから、Enterpriseでは専用チャンネルと専任アカウントマネージャーまで用意されています。詳細はサポートおよびSLAのドキュメントにあります。

これをはっきりと述べておく理由は、このような段階分けがこの業界全体で一般的であり、理解しておく価値があるからです。正式でクレジット付きのSLAは一般的にエンタープライズ契約の機能であり、調達プロセスでそれが必須なのであれば、セルフサーブプランにそれが含まれていると思い込むのではなく、事前にその点について話し合うべきです。

調達で尋ねるべき質問

測定期間を尋ね、それが月次か年次かを確認してください。ダウンタイムの定義を尋ね、特にエラー率の上昇やレイテンシーの劣化がカウントされるかどうかを確認してください。SLAがどのコンポーネント、ゲートウェイ、認証、パネル、APIをカバーしているか、それらが別々に測定されているかを尋ねてください。クレジットが自動なのか申請制なのか、申請期間はどれくらいか、上限はいくらかを尋ねてください。過去12か月のインシデント履歴を求めてください。本番環境がダウンした場合のサポート応答の約束はどうなっているか、どのチャンネルを通じてかを尋ねてください。そして、明示的に何が除外されているかを尋ねてください。

これらすべてに書面で快く答えられるプロバイダーは、数字そのものとは別に有益な情報を伝えてくれています。

まとめ

パーセンテージはSLAの中で最も有益でない部分だと捉えてください。期間、ダウンタイムの定義、カバーされるコンポーネント、そして除外事項こそが、その約束が意味を持つかどうかを決定づけるものであり、サービスクレジットはあなたの損失を補償するものではなく、説明責任にすぎません。最も重要なのは、その境界を忘れないことです。アップタイムSLAがカバーするのはゲートウェイが利用可能であることだけであり、第三者のターゲットがあなたのトラフィックを受け入れるかどうかは決してカバーしません。ですから、自分の収集が実際に機能しているかどうかを知るには、自分自身の成功率監視が依然として必要です。公開インシデント履歴と試用期間中の自分自身の測定で検証し、応答性の高さを数字そのものと少なくとも同じ重みで評価してください。

その観点で評価するなら、プラン選択については適切なレジデンシャルプロキシプランの選び方を、プロバイダー選択の基準についてはプロキシネットワークの選び方を参照してください。サービス自体はレジデンシャルプロキシで、セルフサーブから契約制のEnterpriseまで拡張できるティアとGBあたりの料金が用意されています。

始める準備はできていますか?

Shifterのレジデンシャルプロキシをお試しください。IP 205M+件、195+カ国、$0.75/GBから。

始める