Summary

  • ARIN の登録は AS63199 と CDSC-AS1 を CDS Global Cloud Co., Ltd に結び付け、RIPEstat の観測は同 AS がインターネット上で広く見えていることを示す。これは実在するルーティング基盤の証拠だが、顧客ごとの遅延、損失率、帯域、経路制御を保証するものではない。
  • PeeringDB には AS63199 について26の稼働中交換接続と26の施設接続が記録されている。この分布は相互接続の広がりを評価する有力な手掛かりになる一方、設備所有、実トラフィック量、利用可能容量、契約関係の証明にはならない。
  • Global Cloud Co., Ltd は GPN、Premium Internet Routing、Global DIA、Enhanced Internet、CloudConnect などを通じて、中国と国外クラウドの接続を売り込む。ただし、キャリア数、SLA、拠点数、バックボーン容量、免許範囲に関する記述の多くは会社自身の説明である。
  • 購買側が確かめるべきなのは「世界に拠点があるか」だけではない。対象都市とクラウドごとの通常経路と退避経路、BGP 制御権、障害時の責任、現地支援体制、SLA の測定点、越境通信に関する法的責任を、契約と試験結果に落とし込めるかが核心になる。

「接続できる」と「経路を選べる」の間

多国籍企業にとって、中国本土の拠点から国外のクラウドへ到達する経路は、一般的なインターネット回線の調達よりも多層的である。アプリケーションが起動し、画面が表示されるだけなら「接続」は成立する。しかし業務が依存するのは、混雑時にも同じ品質が続くか、障害時にどの経路へ切り替わるか、その切り替えを誰が観測し、誰が指示できるかという運用面だ。経路が変わった結果、遅延、パケット損失、クラウド利用料、データの通過地域、規制上の扱いまで変わる可能性がある。

Global Cloud Co., Ltd の公開像を読む際に重要なのは、同社を単に「クラウド事業者」と分類して終わらせないことである。今回の公開記録で最も輪郭がはっきりしているのは、計算資源の量ではなく AS63199 を中心とするルーティングと相互接続の面だ。ARIN の登録、RIPEstat による経路観測、PeeringDB に登録された交換拠点と施設、そして会社が説明する中国向けネットワーク製品を重ねると、同社がどこで評価されるべきかが見えてくる。

同時に、公開情報には越えられない境界がある。AS が広く観測されることは、ある顧客の上海拠点からあるクラウドリージョンまでの経路が最適であることを意味しない。交換拠点への接続記録は、そのポートで顧客トラフィックが実際に流れていることを示さない。製品ページに掲げられた SLA は、契約書の対象区間、除外条件、測定方法、補償条件を読まなければ運用品質に換算できない。公開記録は調達判断の入口であり、結論そのものではない。

登録情報が固定する企業と番号の関係

最初に確認できるのは、番号資源と組織の結び付きである。ARIN の RDAP 記録は AS63199 をハンドルAS63199、名称CDSC-AS1として示し、組織として CDS Global Cloud Co., Ltd を関連付けている。AS の登録日は2014年9月8日、記録上の最終変更日は2026年1月9日である。組織ハンドルCDSC-1も CDS Global Cloud Co., Ltd に解決され、登録日は2014年6月2日、最終変更日は同じく2026年1月9日となっている。

さらに ARIN はNET-148-153-0-0-1を、148.153.0.0から148.153.255.255までの直接 IPv4 割り当てとして表示する。名称はCDSC-1、登録日は2016年1月12日、登録主体もCDSC-1である。これらは、AS63199 と少なくとも一つの大きなアドレス割り当てが、公開レジストリ上で同じ組織アイデンティティに結び付いていることを示す。

ここで分かるのは、法的・管理上の公開名と番号資源の関係であって、サービス品質ではない。割り当てられた IPv4 範囲の全アドレスが現在アナウンスされているとも、すべてが顧客向けに使われているとも限らない。RDAP の住所や連絡先も、実際の営業拠点や支援窓口の最新状態を自動的に保証しない。それでも、ブランド説明だけに依存せず、ネットワークを追跡するための安定した識別子が存在する点は重要である。

会社のウェブサイトは AS63199 と AS38353 の二つを自社ネットワークとして挙げるが、今回の第三者資料で外部から十分に追えるのは AS63199 である。したがって AS38353 は、会社が併用を主張する AS として扱うべきであり、AS63199 と同じ水準で登録、経路、接続関係まで確認済みとみなすことはできない。この区別を外すと、二つの AS にまたがるとされる製品構成を、公開証拠以上に確定的に描いてしまう。

2014年から2026年までの記録を、成長物語にしない

公開記録には時間の軸もある。組織ハンドルは2014年6月、AS63199 は同年9月に登録され、RIPEstat では2015年4月に同 AS の経路が初めて観測されている。直接 IPv4 割り当ては2016年1月に登録された。ARIN の AS と組織記録は2026年1月に変更され、PeeringDB のネットワークプロフィールは同年6月に更新され、RIPEstat の主要観測は7月20日時点で取得されている。

この並びは、番号資源が一日に作られた一時的な表示ではなく、複数年にわたって公開記録に残っていることを示す。ただし、「2014年から継続して成長した」「2015年以降ずっと同じ品質だった」「2026年の変更が事業拡大を意味する」といった物語までは導けない。登録情報の変更理由は公開された日付だけでは分からず、RIPEstat の初回観測も商用サービス開始日とは限らない。

時系列の正しい使い方は、質問を具体化することである。2014年の組織・AS 登録、2016年のアドレス割り当て、2026年のプロフィール更新が、現在提示される契約主体とどうつながるか。買収、組織再編、ブランド変更、運用主体の変更があったか。過去に発行された LOA、IRR、RPKI、連絡先情報が現在の顧客設計と整合しているか。これらを事業者に確認すれば、古い登録を現在の運用へ無条件に外挿する危険を減らせる。

また、更新日の新しさ自体を品質評価に使うべきでもない。PeeringDB が2026年6月に更新されていても、26の全接続が同日に技術確認されたとは限らない。ARIN 記録が2026年1月に変更されても、割り当て全体の利用状況が監査されたとは限らない。公開記録は「いつ確認した情報か」を示すメタデータとして扱い、サービスの実査は別に行う必要がある。

547プレフィックスが示す広がりと、示さない品質

RIPEstat の AS 概要は、資源63199の保有者をCDSC-AS1 - CDS Global Cloud Co., Ltdとし、ARIN から割り当てられ、アナウンス中であると報告する。2026年7月6日から7月20日までの観測窓では、AS63199 について547のアナウンス済みプレフィックスが返された。例には IPv4 の38.123.107.0/24148.153.219.0/24118.193.20.0/24と、IPv6 の2400:5280:804::/48が含まれる。

この547という数字は、AS63199 が単一の小さなネットワークとしてしか見えないわけではないことを示す。しかし、プレフィックス数は観測時点、集約の仕方、オリジンの変更によって動く。アドレス空間の量をそのまま顧客数、サーバー数、売上、実効容量へ置き換えることもできない。公開時点に近いスナップショットとして有用だが、将来も同じ数字が続くという意味ではない。

RIPEstat の routing-status では、AS63199 が139.159.48.0/24とともに最初に見えた日が2015年4月2日とされる。照会時刻2026年7月20日16時には154.223.132.0/24が直近の観測例として示され、RIS の IPv4 ピア325中325、IPv6 ピア320中320から AS が見えていた。これは観測網の中での可視性が広いことを支える。一方で「全ピアから見える」は、「すべての地域から最短で届く」や「どの時間帯も損失がない」と同義ではない。

隣接 AS の観測も同様である。RIPEstat は211の隣接 AS を返し、例として AS174、AS1299、AS12956、AS17408 が含まれる。経路表上の隣接は、相互接続の選択肢と到達範囲を考える材料になるが、現在有効な有償トランジット契約、無償ピアリング契約、優先経路、最低帯域を証明しない。経路は第三者ネットワークを介して観測される場合もあり、商流と BGP 上の隣接を一対一で対応させることはできない。

したがって、AS63199 の価値は「大きな数字がある」ことより、顧客が測定すべき対象を特定できることにある。候補サービスを試験するなら、対象プレフィックス、時刻、送信元、クラウド宛先を固定し、往路と復路を分けて記録する必要がある。公開 BGP データは、その試験結果が平常時の経路と整合するか、異常時にどこが変わったかを検討する基準線になる。

PeeringDB の26対26を、設備所有の証明にしない

PeeringDB のネットワーク API は、AS63199 について一件のプロフィールを返す。名称はCDS Global Cloud Co., LTD、ネットワーク ID は8581、種別はNSP、一般的なピアリング方針はOpen、IPv4 プレフィックスの自己申告値は200、IPv6 は10、IRR AS-SET はAS-CAPITALONLINEDATAで、更新日は2026年6月12日である。業界内で接続点を確認するうえで具体性の高い記録だが、PeeringDB は原則として参加組織が保守するデータであり、独立監査報告ではない。

交換接続の API には26の稼働中接続が記録される。そこには IX.br Sao Paulo、DE-CIX Frankfurt、Equinix Singapore、Equinix Hong Kong、HKIX、SGIX、BBIX Singapore、Equinix Dallas、Equinix Miami、JPNAP Tokyo、BBIX Tokyo、FL-IX、IIX-Jakarta などが並ぶ。南北アメリカ、欧州、東アジア、東南アジアに接続点が分布する姿は、Global Cloud Co., Ltd を中国国内だけの閉じた事業者として捉えるのが不十分であることを示す。

施設接続も26件あり、米国、ドイツ、韓国、ブラジル、シンガポール、香港、日本、中国本土、台湾にまたがる。例として Equinix DA1、Equinix SG3、Equinix TY4、Equinix HK2、Digital Realty LAX、DataBank Dallas、DataBank Miami、Chief Taipei、KINX Seoul、Capital Online Beijing の施設が挙がる。この地理的分布は、AS63199 がどこで他ネットワークや顧客設備と接続し得るかを検討する地図になる。

しかし、交換接続と施設接続のどちらも「所有」を意味しない。施設一覧から Global Cloud Co., Ltd が建物を所有している、専用の大規模スペースを持つ、十分な未使用容量がある、常駐要員を配置している、と結論することはできない。交換接続がoperationalであっても、顧客の対象トラフィックが常にその接続を通るか、どのルートを受け入れ、どのルートを広報しているかは別問題だ。

また、PeeringDB の自己申告プレフィックス数と RIPEstat の観測プレフィックス数は、同じ指標として比較すべきではない。前者はプロフィール上の説明であり、後者は特定期間の経路観測である。差があることだけで誤記や異常を断定するのではなく、契約対象プレフィックスと実際のオリジンを個別に照合するほうが有益である。

接続点の分布は、候補経路の集合として読む

交換拠点と施設の分布からは、いくつかの地理的な接続候補が見える。東アジアでは香港の HKIX と Equinix Hong Kong、東京の JPNAP Tokyo と BBIX Tokyo、さらにシンガポールの SGIX、BBIX Singapore、Equinix Singapore が記録される。施設側にも Equinix HK2、Equinix TY4、Equinix SG3、Chief Taipei、KINX Seoul、Capital Online Beijing がある。この組み合わせは、中国本土、香港、台湾、日本、韓国、シンガポールを結ぶ設計を検討する際の具体的な照会先になる。

だが、地図上で近い接続点が、ネットワーク上でも最短とは限らない。上海から東京へ向かうパケットが必ず JPNAP Tokyo を通るわけではなく、香港の施設記録があるからといって中国本土からの通信が必ず香港で引き渡されるわけでもない。トラフィック工学、利用可能なポート、相手側のポリシー、障害、商業条件によって、実際のパスは変わる。接続点一覧は「ここを通る」という地図ではなく、「ここを通せる可能性を確認する」ための一覧である。

欧州では DE-CIX Frankfurt、南米では IX.br Sao Paulo、米国では Equinix Dallas、Equinix Miami、FL-IX などが記録される。施設一覧には Digital Realty LAX、DataBank Dallas、DataBank Miami もあるため、アジアから欧州・米州へ向かうサービスを評価するとき、複数大陸に観測可能な接続面があることは分かる。しかし、大陸間の海底区間がどの事業者のどの経路を使うか、容量をどの顧客と共有するか、障害時に大西洋・太平洋のどちらへ回るかは、これらの記録だけでは決まらない。

顧客は都市名ではなく「経路候補の組」を求めるべきだ。例えば北京からシンガポール、上海から東京、広州から香港、中国本土からフランクフルト、中国本土から米国西海岸という業務上の組み合わせごとに、入口、交換点、出口、クラウド引き渡しを示してもらう。各組に通常経路と少なくとも一つの障害シナリオを設定し、公開 BGP で観測できる区間と、専用網のため公開観測できない区間を分ける。それにより、GPN の非公開区間と AS63199 の公開区間を混同せずに評価できる。

PeeringDB の広がりは、調達側に交渉材料も与える。特定の交換拠点を利用すると説明されたなら、該当する接続記録、ポート、相手ネットワーク、経路広報を確認できる。施設での引き渡しを提案されたなら、その施設がプロフィールにあるかを照合できる。ただし一致しない場合も直ちに虚偽とは限らない。非公開ピアリング、更新前の新規接続、提携事業者名義の引き渡しがあり得るため、差分の説明と証拠を求めるのが適切である。

製品群が描くのは、計算資源より接続の層

会社の説明を読むと、中心に置かれているのは Global Private Network(GPN)である。GPN のページは、中国、アジア太平洋、北米、欧州を結ぶフルメッシュのレイヤー2網として説明し、キャリア、回線、経路の多様性を掲げる。利用例には WAN バックボーン、P2P Ethernet、IEPL、SD-WAN、EVPL/VPL、企業 VPN が並ぶ。ここでの価値提案は、仮想マシンを何台提供できるかではなく、離れた拠点とクラウドをどの下位回線で結ぶかにある。

Premium Internet Routing(PIR)は、最適化された IP トランジットとして売り出されている。会社は AS63199 が中国のキャリアを含む200超の世界的キャリアとピアリングし、中国の利用者が国外サーバーへ接続するサービスに99.9%の SLA を設けると説明する。料金は Mbps 単位または利用量ベースを選べ、最大10Gbps までバーストできるとしている。いずれも調達上は魅力的な条件だが、キャリア数、SLA、バースト上限は会社の製品主張であり、公開経路データだけでは検証できない。

BGP IP Transit の説明は、AS38353 を使う China Blended IP Transit と Global BGP を区別する。前者について China Telecom、China Unicom、China Netcom、CERNET とのピアリングを、後者について PCCW、NTT、TATA、Zayo、Level 3、HE など国際 ISP との接続を掲げる。しかし、名前が製品ページにあることは、現在の契約、セッション状態、容量、優先順位を第三者が確認したことにはならない。特に AS38353 は、この資料群では AS63199 と同じ外部検証を終えていない。

Global DIA は、中国本土から企業クラウドへ向かう動的ルーティングの下位接続として説明される。会社は上海の SmokePing 例を掲載し、通常の DIA で10日間の平均パケット損失率が20.97%だったとする。この例は、経路選択がアプリケーション体験に影響し得ることを伝えるが、会社が選んだ一地点・一期間の比較材料である。すべての一般回線、すべての顧客、現在の上海、他都市に当てはめることはできない。Global DIA 自体も企業向けで、利用制限があると説明されている。

CloudConnect は Equinix Cloud Exchange を利用し、複数のネットワークを介して複数のクラウドやリソースへ直接接続すると説明される。GPN を組み合わせ、必要に応じて世界規模の接続を提供するという構成だ。ここでも確認すべきなのは、サービス名の存在ではなく、顧客の拠点から選択したクラウドまで、どの都市、どのポート、どの仮想回線、どの AS を通るのかである。公開ページだけでは、すべての顧客拠点からすべての CloudConnect 経路を利用できるとは分からない。

Enhanced Internet のページは、50超の国、89都市、400超のキャリア、100本近い専用海底ケーブル、94のデータセンターという広い提供範囲を掲げ、GPN とクラウド交換接続を構成要素に挙げる。一方、ホームページは世界10超のフルサービス・データセンターと中国本土50超のサテライト拠点を、拠点ページは北京の主要10データセンターに加えて広州、上海、無錫、武漢と50超のサテライト拠点を説明する。数字の対象が施設、サービス提供地点、接続先、販売可能範囲のどれかによって意味は変わるため、一つの「所有データセンター総数」にまとめるべきではない。

GPN、PIR、Global DIA、CloudConnect を一つの回線にまとめない

四つの製品名は、同じ「速い国際回線」の言い換えではない。Global Private Network は会社説明上、拠点間を結ぶレイヤー2の私設網であり、企業 WAN や Ethernet 系サービスの土台を想定する。PIR は AS63199 を用いる最適化 IP トランジットとして説明され、インターネット宛ての経路選択が中心になる。Global DIA は企業クラウド向けに動的ルーティングを使うアクセス下位層として位置付けられ、CloudConnect は Equinix Cloud Exchange と GPN を使って特定クラウドへの接続を構成するとされる。

この違いは、障害の場所と責任を決める。顧客拠点から GPN へのアクセス回線が切れた場合、AS63199 の外部ピアリングが正常でもサービスは使えない。PIR の経路が遠回りになった場合、クラウド専用接続そのものに問題がなくてもインターネット経由のアプリケーションは遅くなる。CloudConnect の仮想接続が停止した場合、GPN が稼働していても対象クラウドへ到達できない可能性がある。製品を束ねて購入するほど、各層の測定点を分ける必要がある。

設計書には少なくとも、顧客構内、ローカルアクセス、GPN、PIR または Global DIA、交換拠点、クラウド引き渡し、クラウド内ネットワークを別々の区間として表すべきだ。各区間について、提供主体、回線または仮想接続の識別子、帯域、冗長方式、監視主体、変更権限、障害連絡先を記す。会社が複数区間を一括提供する場合でも、内部で利用する第三者と責任の継ぎ目を顧客から完全に見えなくしてよいわけではない。

レイヤー2と IP の違いも運用に影響する。GPN 上で顧客がルーティングを管理するのか、事業者が管理するのか。PIR ではフルルート、デフォルトルート、限定プレフィックスのどれが提供されるのか。Global DIA の動的ルーティングは顧客機器とどの境界で確立されるのか。CloudConnect ではクラウド事業者側の仮想回線と BGP セッションを誰が設定するのか。公開ページは用途を示すが、こうした引き渡し仕様までは閉じていない。

製品の組み合わせには、障害時の代替関係も必要である。CloudConnect が使えないとき PIR へ自動的に切り替える設計なのか、GPN の別経路へ移すのか、一般 DIA を非常用に残すのか。切り替え後も同じ送信元アドレス、セキュリティポリシー、DNS、クラウド側許可リストを維持できるか。これらが決まっていなければ、複数製品を買うことがそのまま冗長性になるとは限らない。

大きな数字より、分母と測定点を確かめる

会社の About ページは、中国、アジア太平洋、欧州、北米、南米を GPN がカバーし、AS63199 と AS38353 が世界のデータセンター間を10G または100Gb のプライベート・バックボーンで結び、ペタバイト規模のデータを運ぶと説明する。こうした数字はサービスの想定規模を理解する手掛かりにはなるが、外部測定、期間、ピークと平均、予約済み容量と利用可能容量の区別は公開されていない。

調達では、数字そのものより分母を尋ねる必要がある。「200超のキャリア」は契約中の組織数なのか、到達可能なネットワーク数なのか、交換拠点で見える参加者を含むのか。「99.9%」は月間の可用性か、特定区間のパケット配送か、計画停止や顧客側障害をどう扱うのか。「10Gbps までのバースト」はどの拠点、ポート、課金方式でも使えるのか。「94のデータセンター」は自社運営、コロケーション、販売可能な提携先のどれを含むのか。答えが契約付属書に落ちなければ、マーケティング上の規模を運用上の保証に変換できない。

価格面でも同じである。Mbps 単位と利用量ベースの選択肢があるという説明だけでは、総費用は決まらない。通常経路と最適化経路の料金差、クラウド側の転送料、ポートや仮想接続の費用、最低利用期間、バースト時の計算、退避経路への切り替え後の課金、性能未達時のクレジットを同じトラフィックモデルで比較する必要がある。安価な単価でも、経路変動による再送やアプリケーション待ち時間、運用者の調査時間が増えれば、業務全体の経済性は悪化し得る。

99.9%を顧客体験へ換算する

PIR ページの99.9% SLA は、契約交渉の出発点にはなるが、それだけでは利用者が感じる停止時間を算出できない。可用性の分母が月単位か年単位か、測定対象が事業者ポートか二地点間か、パケットを一つでも通せれば稼働とみなすのか、性能劣化を停止に含めるのかによって結果は変わる。中国本土から国外クラウドへの接続では、完全断よりも高遅延や断続的損失が先に業務へ影響する場合があるため、二値の稼働率だけでは不十分である。

測定点は特に重要だ。事業者の中核網だけを測れば、顧客アクセス回線、交換拠点、クラウド引き渡しの問題は SLA 外になり得る。顧客端末から測れば、社内 LAN やアプリケーションの問題まで事業者へ含めかねない。現実的には、顧客側境界、事業者網の入口と出口、クラウド側境界に測定点を置き、同じ時刻のデータを突き合わせる必要がある。どの測定器の時計とログを紛争時の正本にするかも決めておく。

性能指標には、可用性に加えて遅延、ジッター、パケット損失、経路収束時間を含める余地がある。ただし、世界の全経路に一つの閾値を適用するのではなく、北京・東京、上海・シンガポール、広州・香港、中国本土・欧州、中国本土・北米など、契約対象の組み合わせごとに基準を置くべきだ。利用者の業務が音声、対話型アプリケーション、データ同期、バックアップのどれかによっても許容値は異なる。

除外条件も品質の一部である。計画保守、第三者キャリア、クラウド事業者、規制当局の措置、DDoS、顧客機器、不可抗力をすべて除外すれば、数字は高くても実務上の補償範囲は狭い。除外すること自体が不合理なのではない。どの事象を誰が証明し、代替経路の提供義務が残るかを明確にする必要がある。クレジットだけでなく、一定回数以上の未達時に設計見直しや解約を選べるかも、長期契約のリスクを左右する。

Global DIA の上海例は、損失率という性能指標を前面に出す点で参考になる一方、同じ方法で顧客環境を測れるかが問われる。使用した宛先、パケット間隔、測定時間帯、比較経路、欠測処理が分からなければ、20.97%を再現性のある基準にはできない。調達側は会社の例をそのまま信じるか否定するのではなく、同じ種類の測定を自社の送信元と宛先で共同実施し、原データを共有する条件へ変えるべきである。

中国最適化は、一つの固定経路を意味しない

「中国最適化」という言葉は、単一の技術仕様ではない。中国本土の送信元、国外の着信先、利用キャリア、時刻、トラフィック方向、規制上許容されるサービス形態によって、望ましい経路は変わる。北京から東京のクラウドへ向かう通信と、上海からフランクフルトへ向かう通信では、同じ製品名でも利用可能な接続点と代替経路が異なる可能性がある。往路が最適化されても、復路が別 AS や別都市を経由すれば、体感品質は対称にならない。

AS63199 の広い可視性と PeeringDB 上の分布は、経路を組み立てる材料があることを示す。しかし、材料があることと、顧客が選択権を持つことは別である。顧客コミュニティ、ローカルプリファレンス、MED、AS パス・プリペンド、BGP community、静的な優先設定など、どの制御手段が提供されるかは公開資料から確定できない。障害時に事業者が自動で切り替えるのか、顧客が申請できるのか、クラウド側の設定変更が必要なのかも、契約と設計書で確かめる必要がある。

最低限、導入前試験では通常時だけでなく意図的な切り替えを含めるべきだ。対象となる中国本土の各都市から、実際に使うクラウドの各リージョンへ、遅延、ジッター、損失、経路、DNS 応答、アプリケーション処理時間を継続測定する。IPv4 と IPv6、上りと下り、平日繁忙時間と閑散時間を分ける。経路を切り替えたとき、何分で収束し、セッションがどう影響を受け、監視通知とサポート連絡がどの順で届くかを記録する。これは AS63199 の公開評価を否定するためではなく、公開評価を顧客固有の証拠へ変える作業である。

コンプライアンス説明は、免責符ではない

Global Cloud Co., Ltd の Legal Compliance ページは、中国本土における国内固定回線データ伝送、IDC、CDN、国内 VPN、ISP の各サービスについて免許を保有すると説明し、越境サービスを MIIT No.32、MIIT No.2496 および CDTIA の規約要件に沿うものとして位置付ける。中国向け接続を販売する事業者が法令枠組みを明示すること自体は、調達側にとって重要な情報である。

ただし、この記述は会社自身による法的ポジショニングであり、今回の公開資料には規制当局の免許原本、番号、名義、対象地域、サービス範囲、有効期限を独立に照合できる記録が含まれていない。したがって「準拠している」と一語で処理するのではなく、契約主体と免許主体が一致するか、再販・提携回線を使う区間では誰の免許に依拠するか、対象となる通信が国内 VPN、国際専用線、一般インターネット、クラウド接続のどれとして扱われるかを確認する必要がある。

規制対応はネットワーク事業者だけで完結しない。顧客側も、運ぶデータの種類、暗号化、保存場所、アクセス権、ログ、越境移転の根拠を判断しなければならない。Global DIA や GPN を採用しただけで、データ保護、サイバーセキュリティ、業界別規制、輸出管理を含むすべての義務が自動的に解消されるわけではない。逆に、経路が中国を通るという地理的推測だけで違反を断定することもできない。必要なのは、設計した経路、契約主体、法的根拠、監査証跡を同じ資料上で結び付けることである。

現地支援は、施設リストからは読めない

国際ネットワークの品質は、BGP 設計だけでなく、人がどの速度で異常を切り分けられるかにも左右される。PeeringDB に施設接続があることや、会社サイトに都市名があることは、その場所に24時間対応の自社技術者がいる証拠ではない。現地作業が施設事業者、提携会社、回線事業者のいずれに委託されるかも、公開一覧からは分からない。

購買側は、販売窓口とは別に運用体制を確認すべきだ。中国語、日本語、英語など必要な言語で一次応答と技術エスカレーションが可能な時間帯、重大度の定義、ネットワーク運用センターから現地作業者を呼び出す手順、交換拠点やクラウド事業者との共同調査の責任者を特定する。チケットの受付時間だけでなく、経路変更を実行できる権限を持つ担当者へ何分で到達できるかが重要である。

また、一つのインシデントが複数地域にまたがる場合の統括者も決めておく必要がある。東京の交換接続、香港の施設、中国本土のアクセス回線、国外クラウドの仮想接続が別々の供給者に分かれていれば、各社が自区間は正常だと報告しても、エンドツーエンドでは障害が残り得る。Global Cloud Co., Ltd が単一窓口を提供するなら、その窓口がどこまで診断・変更・補償を約束するのかを RACI と SLA に明記しなければならない。

調達前に閉じるべき九つの確認項目

公開情報から見える強みを実際の契約価値へ変えるには、次の項目を顧客固有の資料で閉じる必要がある。

  1. 対象経路:中国本土の各送信拠点から各クラウドリージョンまで、通常時と退避時の AS パス、引き渡し地点、往復経路を示せるか。
  2. 経路制御:顧客が利用できる BGP community、優先度変更、経路フィルタ、DDoS 時の迂回、メンテナンス時の事前変更手段は何か。
  3. 接続の実体:PeeringDB にある交換・施設接続のうち、対象サービスが実際に使用する接続はどれか。ポート速度と予約済み・利用可能容量をどう確認するか。
  4. SLA の境界:99.9%の対象はアクセス回線、GPN、PIR、クラウド接続、エンドツーエンドのどこか。測定点、集計期間、除外条件、クレジットは何か。
  5. 障害対応:経路劣化と完全断をどう判定し、自動切り替え、手動変更、顧客通知、原因報告をそれぞれ何分以内に行うか。
  6. 現地支援:各都市で誰が物理作業と回線事業者への連絡を担い、どの言語・時間帯・重大度で対応するか。
  7. 商流と費用:Mbps 課金と利用量課金に含まれる区間、クラウド側料金、ポート料金、バースト、退避経路、最低利用期間、解約費用を同じ前提で比較できるか。
  8. 法令上の責任:契約主体、免許主体、再販事業者、データ管理者の責任を区間ごとに分け、MIIT および CDTIA に関する根拠資料を提示できるか。
  9. 証拠の更新:AS、プレフィックス、交換接続、施設、キャリア、SLA、免許に変更があった場合、誰がどの頻度で顧客の設計書と監査資料を更新するか。

これらは過度な要求ではない。相互接続型サービスでは、製品名が同じでも顧客ごとの入口、出口、経路、クラウド、契約主体が異なる。公開情報の粒度より契約の粒度が粗ければ、障害時に「どこまでがサービスか」を確定できない。反対に、九項目が具体的な設計、試験、責任分界に落ちれば、AS63199 と広い接続分布は実務的な強みとして評価できる。

証拠を三層に分ければ、評価はぶれにくい

Global Cloud Co., Ltd を公平に評価するには、証拠を三層に分けるとよい。第一層は ARIN の登録と RIPEstat の観測である。ここからは AS63199 の組織アイデンティティ、直接 IPv4 割り当て、公開 BGP 上の可視性、観測プレフィックスと隣接 AS を確認できる。時点依存ではあるが、会社のマーケティングだけに基づかない層だ。

第二層は PeeringDB である。ネットワークプロフィール、26の交換接続、26の施設接続は、相互接続面と地理的な配置を具体化する。業界で広く利用される有用な情報である一方、自己管理型データであり、所有権、利用量、契約、性能の監査ではない。実装候補地を絞り、接続の裏付け資料を求めるための層と位置付けるべきである。

第三層は会社の製品・拠点・法令説明である。GPN、PIR、Global DIA、Enhanced Internet、CloudConnect、BGP サービス、拠点数、キャリア数、SLA、帯域、免許に関する説明は、事業者が何を売ろうとしているかを理解させる。だが、顧客固有の可用性や法的結果を確定するには、契約書、設計書、試験、免許資料、運用記録による追加確認が要る。

三層を混ぜると過大評価が起きる。例えば、RIPEstat で AS63199 が広く見えるという第一層の事実を使って、PIR の99.9% SLA という第三層の主張まで実証済みと扱ってはならない。PeeringDB の施設接続という第二層の情報を、会社所有のデータセンター数に読み替えることもできない。逆に、会社主張が独立監査されていないからといって、第一層と第二層の具体的な公開証拠まで無視するのも適切ではない。

公開されていないことを、存在しないことにしない

公開情報の空白には二つの読み違いが起きやすい。一つは、会社の主張で空白を埋め、契約や性能まで確認済みとみなすこと。もう一つは、公開証拠がないものは存在しないと断定することだ。AS63199 の顧客別経路、各ピアリングの商業条件、ポート利用率、GPN の非公開トポロジー、障害時の作業手順が公開されていないからといって、それらが実装されていないとは言えない。ネットワークの安全性や契約上の秘密のため、公開されない情報は当然にある。

同時に、非公開であることを理由に検証を免除することもできない。公開できない経路図なら、秘密保持契約の下で顧客に提示する方法がある。ポート利用率の生データを共有できないなら、期間、集計方法、余裕率、第三者確認の有無を示せる。キャリア契約そのものを開示できなくても、対象区間を提供する権利、障害連絡経路、終了時の代替計画を契約上表明できる。秘密と無証拠は同じではない。

調達側は、証拠を「公開確認できるもの」「秘密保持下で確認するもの」「契約で表明・保証させるもの」「受け入れ試験で測るもの」に分けるとよい。ARIN、RIPEstat、PeeringDB は第一の区分に入る。顧客固有の物理・論理構成、容量資料、運用手順は第二に、免許範囲、SLA、変更通知、補償、再委託先の責任は第三に置ける。遅延、損失、収束、アプリケーション動作は第四の区分で実測する。

この分け方により、公開記録へ過大な役割を負わせずに済む。例えば PeeringDB の26施設は候補地点を確認する公開証拠であり、そこで利用できる容量は秘密保持下の資料と試験で確かめる。RIPEstat の211隣接 AS は経路上の広がりを示す公開観測であり、特定キャリアとの契約と優先順位は事業者の表明と実経路で確認する。会社サイトの99.9% SLA は提示条件であり、適用区間と補償は署名する契約が最終的な根拠になる。

確認資料が互いに食い違った場合も、直ちに一方を虚偽と決め付けない。公開 BGP は時点によって変わり、PeeringDB は更新に遅れがあり得て、設計書には非公開経路が含まれ得る。重要なのは、差分を説明できる責任者と更新手続きがあるかである。説明が具体的で再測定できるなら差分は管理可能だが、「独自最適化だから詳細は示せない」だけでは、顧客は障害時の判断材料を持てない。

逆に、すべてを公開 URL で証明するよう求めれば、専用接続の本質を見誤る。GPN や CloudConnect の価値は、一般の経路表に全区間をさらすことではなく、顧客の要件に合わせて管理された接続を提供する点にあるはずだ。評価すべきなのは非公開であること自体ではなく、非公開区間にも識別子、責任者、測定点、変更履歴、障害時の証拠があるかである。

Global Cloud Co., Ltd に対する妥当な姿勢は、公開記録で確認できる相互接続面を正当に評価しつつ、その先を推測で埋めないことだ。AS63199 は強い公開アンカーである。そこから先の顧客固有サービスは、秘密保持下の設計、契約上の約束、実地試験、継続監査という別の証拠で閉じる必要がある。

導入時の合格だけでなく、変更を追跡する

ネットワーク評価は契約締結時の一回で終わらない。RIPEstat のプレフィックスと隣接 AS は変化し、PeeringDB の交換・施設接続は追加または削除され、会社の製品範囲や提携先も更新される。顧客側でもクラウドリージョン、トラフィック量、セキュリティ要件、利用拠点が変わる。導入時に最適だった設計が、一年後も同じとは限らない。

変更監査では、すべての経路変動を問題扱いする必要はない。正常な容量増強、保守、ピアリング改善でも AS パスは変わる。重要なのは、契約上重要な変化を定義することである。対象交換拠点の撤退、主要な通常経路や退避経路の変更、顧客プレフィックスのオリジン変更、SLA 測定点の変更、契約・免許主体の変更、現地支援会社の変更は、事前通知と再試験の対象にできる。

AS63199 に関しては、ARIN の組織・AS 記録、直接 IPv4 割り当て、RIPEstat の概要・プレフィックス・routing-status・隣接 AS、PeeringDB のネットワーク・交換・施設という公開面を定期的に同じ条件で保存すれば、変化を比較しやすい。数字の増減だけで良否を判定せず、契約対象経路に影響する差分を抽出する。例えばプレフィックス総数が変わっても対象プレフィックスが安定していれば影響は限定的かもしれず、総数が同じでも利用する交換接続が消えれば重要である。

会社側のページも、主張の版を追う必要がある。10超のフルサービス拠点、50超の中国本土サテライト拠点、Enhanced Internet の89都市・94データセンター・400超キャリアといった数字は、それぞれ定義と更新日を記録する。将来数字が変わったとき、拡大・縮小を即断するのではなく、集計範囲が変わったのか、製品範囲が変わったのか、実拠点が変わったのかを問い合わせる。

運用レビューでは、公開情報の更新と同時に顧客自身の測定結果を振り返るべきだ。四半期ごと、重大障害後、大きな経路変更後などの頻度を決め、通常時の基準線、切り替え試験、チケット応答、原因報告、SLA 判定を比較する。公開上の接続面が広くても顧客経路の品質が悪化していれば設計変更が必要であり、公開数字が減っても顧客経路が改善しているなら直ちに否定的評価をする必要はない。

この継続監査は、事業者を疑うためだけの仕組みではない。Global Cloud Co., Ltd にとっても、AS63199 の公開可視性と顧客固有の性能を結び付け、会社主張と第三者観測の差を説明する機会になる。双方が同じ時刻、同じ経路、同じ測定点を参照できれば、障害時の責任争いを減らし、次の容量・経路投資を具体化できる。

最終的な評価表には、公開事実、会社説明、契約上の約束、実測結果を別々の欄に残すべきだ。一つの欄が未確認でも、他の欄の証拠まで消えるわけではない。反対に、公開事実が強くても、契約と試験の欄が空白なら、本番業務を委ねる判断はまだ完了していない。この記録方法なら、承認時の期待と運用後の実績を同じ基準で比較できる。

結論:見えるネットワークを、検証できるサービスへ

公開資料が支える安全な結論は明確である。AS63199 は ARIN の登録上 CDS Global Cloud Co., Ltd に結び付き、RIPEstat で広く観測され、PeeringDB では複数地域の交換拠点と施設への接続が記録されている。Global Cloud Co., Ltd を、単に名前だけのクラウドブランドとみなすのは妥当ではない。少なくとも公開インターネット上には、ルーティングと相互接続を中心とした具体的な運用面が見える。

しかし、その可視性だけでは、ある顧客の経路、契約中のキャリア、実際に使える容量、クラウドまでの性能、障害時の復旧境界、現地支援、法令上の結果は確定しない。会社が掲げる中国最適化の価値は、交換接続数や拠点数の大きさではなく、顧客が通常経路と代替経路を理解し、試験し、必要時に変更できるかによって測られるべきだ。

AS63199 は、その検証を始めるための強いアンカーである。次に必要なのは、公開 BGP の広がりを契約上の経路制御へ、PeeringDB の接続分布を顧客固有の引き渡し地点へ、製品ページの SLA と法令説明を測定可能な責任分界へ変えることだ。そこで初めて、Global Cloud Co., Ltd の対中クラウド接続は、見えるネットワークから検証できるサービスになる。

出典

  1. https://www.cdsglobalcloud.com/
  2. https://www.cdsglobalcloud.com/about-us/
  3. https://www.cdsglobalcloud.com/locations/
  4. https://www.cdsglobalcloud.com/gpn/
  5. https://www.cdsglobalcloud.com/premium-ip-transit/
  6. https://www.cdsglobalcloud.com/bgp-internet/
  7. https://www.cdsglobalcloud.com/enhanced-internet/
  8. https://www.cdsglobalcloud.com/cloud-connect/
  9. https://www.cdsglobalcloud.com/global-dia/
  10. https://www.cdsglobalcloud.com/legal-compliance/
  11. https://rdap.arin.net/registry/autnum/63199
  12. https://rdap.arin.net/registry/entity/CDSC-1
  13. https://rdap.arin.net/registry/ip/148.153.0.0
  14. https://stat.ripe.net/data/as-overview/data.json?resource=AS63199
  15. https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS63199
  16. https://stat.ripe.net/data/routing-status/data.json?resource=AS63199
  17. https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS63199
  18. https://www.peeringdb.com/api/net?asn=63199
  19. https://www.peeringdb.com/api/netixlan?asn=63199
  20. https://www.peeringdb.com/api/netfac?net_id=8581