ソース: Oxylabs, Decodo, Webshare は同じ所有者の下にあります

2026年10月13日、ウェブデータ収集の世界から5つの企業が、Sourceという共通の傘の下で活動することを発表しました。これにはOxylabs、Decodo（旧Smartproxy）、Webshare、ScrapingBee、Honeygainが含まれます。多くの顧客は長年にわたり、これらのブランドから「主要」と「バックアップ」のプロバイダーを選んできましたが、今や公式にこれらは一つのグループです。何が統合されたのか、なぜこれはバックアッププロキシプールを持つすべての人に関係するのか、そして1時間であなたのバックアッププロバイダーが本当に主要プロバイダーから独立しているかを確認する方法を見ていきましょう。

何が起こったのか：5つのブランド、1つの所有者

Proxywayによると、Sourceは自らを「データエコシステム」と表現しています。母体はビリニュスにあり、Proxywayが指摘するように、より広いTesonetエコシステムに属しています。グループが自らについて示す数字は以下の通りです：

800人以上の従業員、そのうち350人以上が開発者およびエンジニア；
180件以上の特許と215件の商標；
分散システムでの毎秒150万リクエスト；
AIエージェントおよびAI製品からの需要は、1年で約4倍に増加しました。

グループはOxylabsから成長しました。2026年7月、OxylabsはWarburg Pincusから1億3000万ドルを調達し、評価額は36億ドルに達しました。これは彼らの初の外部ラウンドでした。ブランド間の関係は何年にもわたって築かれてきました：Webshareは2022年にOxylabsに買収され、ScrapingBeeは2025年に、Honeygainは2021年からOxylabsの主要なレジデンシャルIP調達パートナーとして機能しています。DecodoとOxylabsの関係は、Sourceの立ち上げ前には公にはそれほど明白ではなかったとWilson's Mediaは述べています。象徴的な詳細として、SourceのCEOであるヴィタウタス・サヴィツカスは2026年3月までDecodoを率いていました。

ブランドが市場を分け合う方法

Oxylabs — 大規模ビジネスおよびAIラボ；
Decodo — 中規模セグメント；
ScrapingBee — 開発者向けAPI；
Webshare — 高度な個人や小規模チーム；
Honeygain — 一般の人々に「余分な」トラフィックに対して報酬を支払うアプリ。

形式的には、ブランドは独立しています：それぞれのチーム、価格、製品、顧客があります。Sourceは自社で何も販売せず、特許、調達、採用、コンプライアンスを中央集権化していると述べています。ブランド間でIPプールやインフラが共通しているかどうかについては、Sourceも専門メディアも明らかにしていません。しかし、顧客にとってこれは最も重要な問題です。

なぜこれはあなたのバックアッププールに関係するのか

バックアッププロキシプールは、主要なプロバイダーが機能しなくなった場合に必要です：ターゲットサイトがプロバイダーのサブネットを禁止した、プロバイダーに障害が発生した、条件や価格が変更されたなどです。バックアップのシナリオとアーキテクチャについては、バックアッププロキシプールが実際にアカウントを救う時で詳しく説明しています。そこでの主なルールはシンプルです：バックアップは別のプロバイダーから取得し、理想的には異なるIPソースからのものであるべきです。

一つの所有者の下での統合は、このルールを見かけ以上に複雑にします。依存関係には3つのレベルがあり、ブランドはウェブサイト上で最初のレベルのみを反映しています：

法的。 会社を所有しているのは誰で、誰の決定が価格、ルール、サービスの運命を決定するのか。
IPソース。 レジデンシャルアドレスはどこから来るのか：自社アプリ、他社アプリのSDK、パートナーシッププログラム（Honeygainのような）、他のプロバイダーからの卸売購入。
インフラ。 トラフィックが通過するゲートウェイ、そのホスティングとネットワーク。

2つの「異なる」プロバイダーは、いずれかのレベルで一致する可能性があります。IPソースが一致する場合、ターゲットサイトのアンチボットがこれらのアドレスを認識し、両方のプールを同時にブロックするため、バックアップは購入された目的のために無駄になります。

プールの一致は共通の所有者なしでも起こる

このニュースを陰謀論に変えないことが重要です。IPの交差は、まったく関係のない企業でも見られます：レジデンシャルプロキシ市場は多層的であり、多くのブランドが大規模な卸売ネットワークのアドレスを再販しており、これらのネットワークは同じアプリやSDKを通じてトラフィックを購入しています。したがって、「所有者は誰か」だけでなく、「アドレスの出所はどこか」、「実際に交差しているか」を確認する必要があります。

バックアッププロバイダーが独立していることを確認する方法：5つのステップ

確認には約1時間かかり、数百メガバイトのトラフィックが必要です。バックアップが必要になる前に実施してください。

ステップ1. 法人と所有者

両方のプロバイダーの利用規約（Terms of Service）とプライバシーポリシーを開いてください：そこには法人名、登録国、住所が記載されています。次に、その国の企業登録簿と「会社について」セクションやプレスリリースを確認します。一致する住所、同じディレクター、または共通のグループに関する言及があれば、プロバイダーを同一の供給者と見なす理由になります。また、明細書の支払い記述子も確認することが有益です：これはしばしば実際の法人名を示すことが多いです。

ステップ2. レジデンシャルIPのソース

サポートに直接尋ねてください：「レジデンシャルIPはどのように取得していますか？自社アプリ、他社アプリのSDK、パートナー、または卸売購入ですか？」正常なプロバイダーは、少なくとも一般的な概要を答えるでしょう。両方が同じトラフィック収益化プログラムを挙げるか、回答を回避する場合、ソースは共通と見なされます。この問題は安全性の観点からも重要です：10月16日、GBHackersはGreyNoiseを引用して、攻撃者がD-LinkのNAS、ビデオレコーダー、SAP NetWeaverの脆弱性を通じて、他人のデバイスに合法的なアプリPawns.appを密かにインストールし、商業的なレジデンシャルノードに変えていたキャンペーンを説明しました。34カ国で少なくとも143台のデバイスが影響を受けました。IPRoyalはPawns.appをレジデンシャルIPの直接のパートナーと呼んでいますが、同時に、キャンペーンがプロバイダーの誰かによって指揮されたというデータはありません。顧客への結論：IPの出所の透明性は、受け取るアドレスがどれほどクリーンであるかという問題でもあります。

ステップ3. 出口IPの交差

これは主な技術テストです。同じ国で両方のプロバイダーからローテーションを取得し、500〜1000のリクエストをIPを返すサービスに送信します。リストを保存し、比較します：

正確なIPの一致 — 共通のプールの直接的な兆候；
/24のサブネットの一致 — 共通のソースまたは共通のオペレーターの兆候；
ASNによる分布 — 両方のリストで同じオペレーターのネットワークが似た割合で支配している場合、ソースはおそらく近いです。

Pythonでの最小スクリプト：

import requests

def collect(proxy_url, n=500):
    ips = set()
    for _ in range(n):
        try:
            r = requests.get("https://api.ipify.org",
                             proxies={"http": proxy_url, "https": proxy_url},
                             timeout=15)
            ips.add(r.text.strip())
        except requests.RequestException:
            pass
    return ips

a = collect("http://login:[email protected]:port")
b = collect("http://login:[email protected]:port")
net24 = lambda s: {".".join(ip.split(".")[:3]) for ip in s}

print("ユニークIPの数:", len(a), len(b))
print("共通IPの数:", len(a & b))
print("共通の/24の数:", len(net24(a) & net24(b)))

取得したアドレスのASNは、任意のIPジオロケーションサービスやローカルデータベースで特定できます。サンプル内のユニークアドレスの数を正しく解釈する方法については、1000リクエストでプロキシプールの実際のサイズを確認する方法で詳しく説明しています。短いルール：大きなプールで数パーセントの共通の/24は1つの国にとっては正常な背景であり、数十パーセントの共通の正確なIPは事実上1つのプールです。

ステップ4. ゲートウェイとインフラ

両方のプロバイダーのゲートウェイのホストがどこに解決されるか（digまたはnslookupコマンド）を見て、これらのアドレスがどのネットワークに属しているかを確認します。同じホスティングは何も証明しませんが、ゲートウェイのアドレス範囲が共通している、ポートのスキームが同じ、ログイン形式が似ている、認証エラーに対する応答が似ている場合、異なるブランドの背後に同じプラットフォームが存在する可能性があるという信号です。この場合、ゲートウェイの障害は両方のサービスを同時に停止させるでしょう。

ステップ5. 共同禁止テスト

最も実用的な確認です。主要プロバイダーがすでにキャプチャやブロックを受けているターゲットサイトを取得し、バックアップを通じて同じシナリオを同じヘッダーとブラウザプロファイルで実行します。バックアップが同じ頻度で同じステップでブロックされる場合、そのサイトにとってはバックアップではなく、所有者が異なっても同様です。プールは変わるため、月に1回テストを繰り返してください。

異なるタスクに応じたバックアップの選択方法

データ解析と価格モニタリング。 IPソースとゲートウェイの独立性が最も重要です。合理的なスキームは、異なるタイプのバックアップを持つことです：主要なプールがレジデンシャルプロキシの場合、バックアップはデータセンター型であってもよく、逆もまた然りです。
マルチアカウントとソーシャルメディア。 ここでは、バックアップは主要なものと同じタイプである必要があります。そうでないと、プラットフォームはネットワークの「プロファイル」の変更を認識します。モバイルシナリオでは、主要なプールに存在しないオペレーターのモバイルプロキシをバックアップとして保持することが理にかなっています。
SLAを伴う重要なタスク。 異なる所有者と異なるIPの出所を持つ2つのプロバイダーを保持し、ステップ3と5での交差を少なくとも四半期に1回確認してください。

統合が変えるその他のこと

統合にはもう一つの側面があります。グループは、公共のウェブデータへの「責任あるアクセス」を保護するために共通の声が必要だと主張しており、Wilson's MediaはOxylabsが2025年10月にRedditに対して提起された訴訟の被告であることを思い出させています。このことは、顧客にとって単純な意味を持ちます：1つのブランドの法的および評判リスクは、今やグループ全体に潜在的に影響を及ぼします。利用規約、価格、および許可される目的に関する決定も調整される可能性があります。

それでも、ブランドは依然として別々のサービスとして販売されており、どれかを利用することを妨げるものはありません。ただ一つ変わるのは、2つを「主要とバックアップ」として選ぶことは、確認なしにはもはや適切ではないということです。

結論

Sourceの立ち上げは、バックアップスキームを見直す良い機会です。ブランド名はプロバイダーの独立性を示すものではありません：所有者、IPソース、インフラが重要です。法人を確認し、アドレスの出所を尋ね、出口IPとサブネットを比較し、共同禁止テストを実施してください。交差が大きい場合、あなたには2つのプロバイダーではなく、2つのアカウントを持つ1つのプロバイダーがいることになります。主要なプールがダウンする日までにこれを知る方が良いです。