第三者リソースは中国の内側から到達できますか？
中国内のどこから計測するかによって変わり、その差は全面的でありえます。 計測された事実：中国本土のデータセンタープローブ（Alibaba Cloud cn-zhangjiakou）から、2026-08-28に12時間、10分おきにサンプリング——720回の計測——では、fonts.googleapis.comとwww.googletagmanager.comはどちらも100%、およそ110msで応答し、両者を直接接続のまま残すことを推奨しました。2026-08-30、ボランティアが同じコードを北京のChina Mobile住宅用回線で88サイト・264回のページ読み込みにわたり走らせたところ、www.googletagmanager.comは112回リクエストされ一度も応答せず、fonts.googleapis.comは54回リクエストされ一度も応答しませんでした。これはタイムアウトのせいではありません——正常に完了したページ読み込みの中でも、タグマネージャーは14回中14回失敗しました。その実行全体で102のホストが応答を返さず、そのうち101は第三者でした。一方、読み込みを完了できなかった57サイトはすべて最初のバイトを返しました。壊れているのはたいていサイトではなく、サイトが引き込むものです。経路をリソースごとに決めることは、訪問者が実際にいる場所から取った計測の上でしか意味を持ちません——そして越境をなくすために本土の内側から配信することは、[ICP備案の要件](/ja/china-icp-license-website.html)を伴います。
中国の第三者リソースについて公表されている数字の大半は、単一サンプルです。以前にも単一サンプルは計測ではないと論じました——そこでの越境の挙動は1日の中で2桁以上変動し、午後2時に取った数字は午後9時についてほとんど何も語りません。
そこで、きちんと走らせました。5つの第三者リソースのカテゴリを、10分おきに、中国本土の内側のプローブから、それぞれ2回ずつ——1回は直接、もう1回は当社自身の配信ネットワーク経由で——リクエストしました。12時間で720回の計測。事業者が計画の軸に据える夕方のピークをカバーしています。
そのうえで、より重要なことを行いました。それは当社に一つの推奨を手放させることになりました。
更新、2026年8月30日。 下の12時間の調査は、中国国内の商用クラウド回線から走らせたものです——これは当社のものを含め、ほとんどの公表された中国計測が取られている取り方です。当時、消費者回線からも繰り返し、たとえ都合の悪い結果でも公表すると述べました。いまそれを行い、問題は誤った推奨よりも大きいことがわかりました。あるカテゴリのホストについては、中国本土のクラウドプローブと中国本土の消費者回線は、同じ国を報告しないのです。 クラウドからは100%応答したホストが、北京の家庭用回線からは0%の応答でした。元のデータは有効です——それはその観測地点を忠実に描いています。それが描いていないのは、訪問者です。プローブを移したときに何が変わったかを参照してください。
何を計測したか
| リソース | カテゴリ | リストに入っている理由 |
|---|---|---|
fonts.googleapis.com | Webフォントのスタイルシート | 多くのエンタープライズページで使われている |
fonts.gstatic.com | Webフォントファイル | 実際のフォントのバイト列 |
cdn.jsdelivr.net | 公開JS CDN | よくあるスクリプトホスト |
www.googletagmanager.com | タグマネージャー | 解析・マーケティングのタグ |
www.google.com/recaptcha | フォーム検証 | フォームを送信できるかを左右する |
このリストは恣意的なものではありません。前週に中国の内側から実在のベンダーWebサイトを計測し、実際に応答を止めた第三者ホストを記録したところから来ています——この5つのカテゴリが、そこに現れたものです。
手法：中国本土の内側のプローブ（Alibaba Cloud cn-zhangjiakou）。各リソースを同じラウンドで直接および当社ネットワーク経由でリクエスト。スループットは本体転送のみで算出し、小さなファイルが接続確立に支配されないようにTTFB（最初のバイトまでの時間）を除外。タイムアウトは30秒、タイムアウトは破棄せず結果として計上。セルあたり72サンプル、2026年8月28日。以下の時刻は中国現地時間。
12時間の結果
| リソース | 経路 | 成功率 | TTFB中央値 | TTFB p95 | スループット中央値 |
|---|---|---|---|---|---|
| フォントのスタイルシート | 直接 | 100% | 111ms | 137ms | 2.4 MB/s |
| 当社ネットワーク | 100% | 278ms | 303ms | 5.0 MB/s | |
| フォントファイル | 直接 | 100% | 102ms | 121ms | 4.9 MB/s |
| 当社ネットワーク | 100% | 195ms | 208ms | 0.8 MB/s | |
| 公開JS CDN | 直接 | 100% | 660ms | 1,757ms | 4.0 MB/s |
| 当社ネットワーク | 100% | 103ms | 114ms | 16.1 MB/s | |
| タグマネージャー | 直接 | 100% | 118ms | 143ms | 13.5 MB/s |
| 当社ネットワーク | 100% | 312ms | 327ms | 4.1 MB/s | |
| フォーム検証 | 直接 | 0% | — | — | — |
| 当社ネットワーク | 100% | 169ms | 263ms | 1.5 MB/s |
セルあたり72サンプル。
何を結論し、何を間違えたか
このデータに基づき、Google Fontsとタグマネージャーは今あるそのままにしておくべきだと書きました。どちらも100%の試行で到達可能で、どちらも直接でおよそ110ミリ秒、追加のホップを経るとおよそ300ミリ秒で応答していました。そして——その数字の上では正しく——すでに健全なホストを別の場所に回すのは、何の便益もなくリクエストごとに払う遅延の税金だ、と論じたのです。
推論は健全でした。観測地点が違ったのです。同じ記事の中で*「このホストは上海から午後9時に健全か」*はほかのどこからも答えられない問いだと書いておきながら——その問いにデータセンターから答えていました。
実際に中国でWebサイトを運用した経験のある人なら、あの表に片眉を上げているはずです。なぜならGoogle所有のホストは中国の消費者回線からは概して使えないからで、現地で働く人に、それを告げる計測は要りません。それこそが、この結果を公表する価値のある理由です。私たちは、それらのホストが訪問者に対して失敗することを発見したのではありません。発見したのは、当社のプローブが、111ミリ秒で、72回中72回、そうではないと言ったことです。
中国本土のクラウドインスタンスは、中立的な観測所ではありません。独自の取り決めを持つ商用ネットワークであり、少なくともあるカテゴリのホストについては、その取り決めは、自宅からページを読み込む人にまでは明らかに及んでいません。
中国でソフトウェアを作る人なら、この形はすでに知っています。ツールチェーンの日常の体験だからです。世界のほかの地域が当たり前と見なす上流のソースは本土からは使えないので、国内のクラウドは独自の代替物を走らせます——コンテナレジストリ、パッケージレジストリ、言語ランタイム。当社自身これに頼っています——ボランティアが走らせた計測パッケージは、そのブラウザとランタイムを国内のミラーからダウンロードします。上流のソースが、彼らがそれを走らせている場所からは到達できないからです。 壊れた経路をそっと動く経路に差し替えてくれる環境は、ものを作るにはとても便利な場所です。そこから計測するには、とても不向きな場所です。
これら特定のホストの具体的な仕組みを推測するつもりはありません——計測していませんし、裏づけられない説明は、裏づけられる観察よりも価値が低いからです。この発見は食い違いそのものの上に立っており、その食い違いは全面的です——クラウドからは72回中72回、家庭用回線からは112回中0回。
役に立つのは一般化の部分です。もし貴社の中国計測が中国本土のクラウドインスタンスから来ているなら——そしてほとんどの公表された中国計測はそうです——それが訪問者の見るものを描いていると決めつけることはできません。 それには当社のものも含まれます。これらを確かめたのと同じやり方で確かめるまでは。
プローブを移したときに変わったこと
2026年8月30日、北京のボランティアが当社の計測スタックをChina Mobileの住宅用ブロードバンド回線で走らせました。当社のデータセンタープローブと同じコード、同じ60秒の上限、同じ「サイトあたり3回」の設計を用いています。その実行は88の実在するWebサイトを読み込み——264回のページ読み込み——リクエストごとに、応答を一度も返さなかったホストをすべて記録しました。
同じ5つのホストが示したのは、次のとおりです。
| ホスト | データセンター回線（12時間、各72サンプル） | 北京の家庭用回線（2026-08-30） |
|---|---|---|
www.googletagmanager.com | 100%成功、118ms | 112リクエスト、112回とも無応答 |
fonts.googleapis.com | 100%成功、111ms | 54リクエスト、54回とも無応答 |
fonts.gstatic.com | 100%成功、102ms | 6リクエスト、6回とも無応答 |
www.google.com（reCAPTCHAのホスト） | 0%成功 | 18リクエスト、18回とも無応答 |
cdn.jsdelivr.net | 100%成功、660ms中央値 | 36リクエスト、失敗0 |
今あるままにしておけと言った2つのホストが、ちょうど一度も応答しなかった2つでした。 遅いのではありません。断続的でもありません。112回中、54回中、それぞれ応答ゼロです。
これはタイムアウトのせいではない
当然の反論は、これらのリクエストは60秒のページ読み込みが打ち切られた時点でまだ処理中で、もっと長ければ完了しただろう、というものです。そうはなりません。確認方法は、正常に完了したページ読み込みだけを見て、その中で同じホストが何をしたかを問うことです。
| ホスト | 完了したページ読み込みでの出現回数 | 無応答 |
|---|---|---|
www.googletagmanager.com | 14 | 14 |
geolocation.onetrust.com | 12 | 12 |
www.google.com | 4 | 4 |
ページは完了しました。それでもホストは一度も応答しませんでした。これらは時間切れになったリクエストではなく、その接続では決して応答されることのなかったリクエストです。
誰も警告してくれないホスト
その264回のページ読み込み全体で、102の異なるホストが応答を一切返さず、そのうち101——99%——は第三者であって、リクエストされているサイト自身ではありませんでした。102のうちGoogle所有はわずか13。それらをすでに理解済みとして脇に置くと、89のホストが残ります。これが常識ではない部分であり、行動に移す価値のある部分です。
| ホスト | 役割 | リクエスト数 | 無応答 |
|---|---|---|---|
geolocation.onetrust.com | 同意バナーの位置情報 | 50 | 50 |
c.go-mpulse.net | リアルユーザーモニタリング | 12 | 12 |
use.typekit.net | Webフォント配信 | 11 | 11 |
cdn.optimizely.com | A/Bテスト（実験） | 9 | 9 |
px.ads.linkedin.com | 広告ピクセル | 9 | 9 |
d3e54v103j8qbb.cloudfront.net | サイトビルダーのアセットCDN | 9 | 9 |
static.hotjar.com | セッション解析 | 6 | 6 |
epsilon.6sense.com | アカウントインテリジェンス | 6 | 6 |
二度見すべきは同意バナーのホストです。同意スクリプトはふつうページ上の何よりも先に走り、解決するまで描画をブロックすることがよくあります。したがって、決して返ってこない位置情報の照会は、クッキーバナーの欠落ではなく、始まらないページそのものです。
断続的なホストは、死んでいるホストより興味深いのです。断続というのは、誰も計画に織り込まない場合だからです。
| ホスト | リクエスト数 | 失敗 | 失敗率 |
|---|---|---|---|
fast.wistia.com | 15 | 6 | 40% |
widget.trustpilot.com | 9 | 3 | 33% |
cdn.weglot.com | 9 | 3 | 33% |
challenges.cloudflare.com | 12 | 3 | 25% |
uhf.microsoft.com | 12 | 3 | 25% |
play.vidyard.com | 15 | 3 | 20% |
rum.hlx.page | 18 | 3 | 17% |
4回に1回失敗するホストは、ページを一度読み込むだけでは診断できません——そして、ほとんどの人はそのやり方で確認しています。経験則でも直せません。その経験則は、ほとんどの場合は正しいホストについて、正しくなければならないからです。
これらすべての失敗の4分の3は、ある特定の一種でした——リクエストは送られ、何も返ってこず、エラーは一度も発生しなかった。拒否でもなく、リセットでもなく——沈黙です。ページ内の何も問題を報告しません。ブラウザの視点では、まだ何も間違っていないからです。
そしてサイト自身はおおむね問題ありませんでした。読み込みを完了できなかった57サイトのうち、一つ残らず最初のバイトを返し、3分の2は止まる前に画面に何かを描きました。到達不能だったものは一つもありません。中国でページを壊すのは、たいていページではないのです。
フォームが機能するかを決める結果
www.google.com/recaptchaは一度も応答しませんでした。データセンター回線で、サンプリングしたすべての時間帯——午後の半ばから夕方のピークを経て深夜過ぎまで——を通じて、72回中、成功したリクエストはゼロ。当社ネットワーク経由では72回中72回。北京の家庭用回線では、到達した18リクエストすべてで同じホストが失敗しました。
これは遅延の話ではなく、勾配でもありません。フォーム検証は送信の関門です。ウィジェットが決して読み込まれなければ、送信ボタンは決して有効になりません。その状態のページは遅いのではありません。たった1件のリードも受け取れないフォームです。そしてページ内の何もエラーを報告しません。リクエストは発行され、ただ決して応答されないからです。
中国のサイトに関門つきの問い合わせフォームがあり、このまさに一点を一度も計測したことがないなら、それが最初に確認する価値のあることです。
時間をかけて初めて見えてくる結果
公開JS CDNは、データセンター回線では両経路とも100%の試行で到達可能で、家庭用回線では36リクエストのうち一つも失敗しませんでした。到達性は何も有益なことを教えてくれませんでした。教えてくれたのは分布です。
| 中国現地時刻 | 直接のTTFB（中央値） | 当社ネットワーク | 比率 |
|---|---|---|---|
| 16:00 | 477ms | 103ms | 4.6× |
| 17:00 | 932ms | 99ms | 9.4× |
| 19:00 | 987ms | 104ms | 9.5× |
| 21:00 | 1,076ms | 102ms | 10.5× |
| 23:00 | 548ms | 103ms | 5.3× |
| 01:00 | 728ms | 110ms | 6.6× |
直接の最初のバイトまでの時間は、サンプリングした最も静かな時間帯と21:00のピークとの間で2倍以上になりました。同じ12時間を通じて、配信された経路は99〜110ミリ秒の間に収まりました——幅にして11ミリ秒です。
それを一つの数字で捉えるなら、95パーセンタイルの中央値に対する比です。
| リソース | 直接 | 当社ネットワーク |
|---|---|---|
| 公開JS CDN | 2.7× | 1.1× |
| フォントファイル | 1.2× | 1.1× |
| タグマネージャー | 1.2× | 1.0× |
中央値660msに対するp95が1,757msということは、20回に1回のリクエストが2秒近くかかるということです——そしてそのようなリクエストが十数個あるページでは、そのうち1つがその裾に落ちるだけで描画が止まるのに十分です。これが、平均が中国にとって誤った要約統計である理由であり、一度だけサンプリングした数字の価値がほとんどない理由です。
これらが示すこと
4つの失敗モードがあり、そのうち人が「中国で遅い」と言うときに通常意味するものは一つだけです。
- 本当に問題ないホストもある——ただし、どこからかを言わなければならない。 公開JS CDNは両方の観測地点で持ちこたえました。これは、いまや1つではなく2つのデータ点で言える主張であり、このリストの中でそれを勝ち取ったのはこのホストだけです。
- 到達はできても不安定なホストもある。 中央値は許容範囲に見えます。ページが実際に壊れるのは裾です。1日を通じてサンプリングしないと、これは見えません。
- 一切応答しないホストもある。 エラーもタイムアウトのイベントも信号もなく——そしてそのホストが貴社のフォーム検証なら、ビジネス上の帰結は劣化ではなく全損です。
- 中国内のある場所からは完璧に応答し、別の場所からは決して応答しないホストもある。 これは以前には手にしていなかったもので、当社自身の推奨を覆したものです。同じ国のデータセンター回線と消費者回線は、同じネットワークではありません。
実務上の帰結は、「すべて回す」や「何も回さない」よりも狭く、より有益です。経路はリソースごとに、訪問者が実際にいる場所から取った計測に基づいて決めなければなりません——そしてクラウド回線で合格したホストが、家庭用回線で合格することは示されていません。すでに速いホストに手を触れないことは、訪問者にとって本当に速いなら、やはり正しい行動です。変わったのは、それがどのホストなのかについての当社の確信と、そう言うのにどれだけの証拠が要るか、です。
これが配信だけの問いではない理由
上のすべては、どのリクエストが完了するかの話で、それは配信の問題です。しかし人が手を伸ばす直し方——中国本土の内側から配信し、リクエストが国境を越える必要をそもそもなくす——は、純粋に技術的な決定ではありません。中国のユーザーに本土のインフラから配信することは、ICP備案の要件を発動させます。備案は中国本土の法人に対して発行され、ホスティングの取り決めに紐づきます。そして備案のないサイトは、本土のアクセスプロバイダーによって合法的に運ばれることはできません。
つまり、同じアーキテクチャの決定が2つの問いに同時に答えており、それらを別々に——2つ目を手遅れに気づくのではなく——一緒に答える価値があります。貴社のリクエストのうちどれが実在の訪問者に対して完了するか、そして、それらが完了する場所から配信することが許されているか。
限界
- 消費者計測はボランティア1人、ISP1社、1晩です。 北京のChina Mobile住宅用回線を、2026年8月30日に一晩走らせました。2社目のISPと2つ目の都市があれば、データ点ではなく発見になります。ホストごとの結果は勾配ではなく100%と0%で、最大の2つの背後には112と54のリクエストがあります。だからこそこのサンプル数で公表する気になったのですが——単一の観測地点は、やはり単一の観測地点です。
- 12時間の調査はデータセンター回線です。 商用クラウドからの国際トランジットは消費者回線からよりも実質的に良いので、この記事の前半にある直接経路のすべての数字は楽観的です。後半は、その楽観が何を代償にしているかです。
- ブラウザのビルドが異なる。 データセンタープローブはDebianのChromium 151.0.7922.173、ボランティアはChrome for Testing 151.0.7922.77を走らせました。完了と最初のバイトまでの時間はこの差に鈍感です。描画のタイミングは方向性としてのみ読んでください。
- 5つのリソース、88サイト。 それらが一般的で、かつ以前の失敗データに現れたから選んだのであって、網羅的だからではありません。
- スループットはTTFBを除外しています。小さなファイルを公平に比較する方法ですが、スループットの列とTTFBの列は別々に読むべきということでもあります。
- 12時間のテストはすべてのリソースを両経路に押し込みました。 これは比較に必要なことで、サイトが配信される様子ではありません。そこでの配信経路は、本番の構成ではなく、計測しやすさのために作った簡略化された構成でもあります。
次に計測すること
別の本土ISP上の2つ目の消費者観測地点。北京の結果をデータ点から発見へと動かす、ただ一つのことです。ここで報告した88サイトを超えて、消費者計測も拡張しています。
自社のものだからという理由で残すよりは、覆される推奨を公表したいと思います。この記事の前半の強さに基づいてアーキテクチャの決定をしようとしているなら、後半こそ考えを変えるべき部分です。
これらの数字の背後にある手法は、最初に8通りの間違いをした話に。より広い全体像は、中国本土の内側から計測した280サイトの普査（英語）に。そして自社サイトがどの第三者ホストに依存しているかを見たいなら、当社の中国ファイアウォールテスト（英語）が、本土の内側からリソースごとに報告します。
よくあるご質問
第三者リソースは中国の内側から到達できますか？
ホスト次第であり、中国内のどこから計測するか次第です。データセンタープローブ（Alibaba Cloud cn-zhangjiakou、12時間で720回の計測、2026-08-28）からは、fonts.googleapis.com、www.googletagmanager.com、fonts.gstatic.com、cdn.jsdelivr.netはすべて100%到達可能で、失敗したのはwww.google.com/recaptchaのみでした。北京のChina Mobile住宅用回線（88サイト、264回のページ読み込み、2026-08-30）からは、最初の3つは一つのリクエストにも応答せず——それぞれ112回、54回、6回の試行——一方でcdn.jsdelivr.netは36回のうち一つも失敗しませんでした。同じ国のクラウド回線と消費者回線は同じネットワークではなく、一方で合格したホストが他方で合格することは示されていません。
なぜエンタープライズの問い合わせフォームは中国で失敗するのですか？
送信の関門となる検証ウィジェットが決して読み込まれないことが、よくある原因です。当社の計測ではwww.google.com/recaptchaは12時間にわたる72回の試行のうち成功した応答がゼロでした。そうなると、フォームは正常に描画されるのに送信ボタンが決して有効になりません——ページは遅いのではなく、たった1件のリードも受け取れないフォームです。何もエラーになりません。リクエストは発行され、ただ決して応答されないからです。
中国の配信レイヤーは常に速いのですか？
いいえ。そうしようとすべきでもありません。訪問者のネットワークから本当に到達可能で速いホストについては、それを追加のホップに通すのは便益なしに約170〜200ミリ秒のコストになります——当社自身のデータセンター計測は、2つのホストでまさにそれを示しました。間違えたのは確信のほうです。その同じ2つのホストは北京の消費者回線からは一度も応答しなかったので、「すでに速い」は、クラウドプローブからではなく、訪問者が使う観測地点から立証されなければなりません。経路はリソースごとに決め、一つを手つかずにする証拠は正しい場所から来なければなりません。
なぜ平均は中国のパフォーマンスにとって誤った統計なのですか？
ページが壊れるのは裾だからです。ある公開JS CDNは、直接で最初のバイトまでの時間の中央値が660ms、95パーセンタイルが1,757ms——比にして2.7でした。20回に1回のリクエストが2秒近くかかることは、そのようなリクエストが十数個あるページでは描画を止めるのに十分です。同じ12時間を通じて、配信された経路はp95が114ms、中央値が103ms、比にして1.1でした。この2つの比の差は、どんな平均にも表れません。
中国の越境パフォーマンスは時間帯で変動しますか？
大きく変動します。サンプリングした公開JS CDNでは、直接の最初のバイトまでの時間が中国現地時間の16:00の477msから21:00の1,076msへと上昇し、その後、夜間にかけて戻りました。同じ時間帯を通じて、配信された経路は99〜110ミリ秒の間に収まりました。一度だけサンプリングした数字は、それが取られた瞬間の産物です。
これらの計測はどのように取られましたか？
5つの第三者リソースを、中国本土の内側のプローブから12時間、10分おきにサンプリングし、各ラウンドで2回ずつ——1回は直接、1回は当社の配信ネットワーク経由で——リクエストし、合計720回の計測を行いました。スループットは本体転送のみで算出し、小さなファイルが接続確立に支配されないようTTFBを除外しています。タイムアウトは30秒で、タイムアウトは破棄せず結果として計上します。プローブはデータセンター回線で、その国際トランジットは企業のブロードバンド接続よりも実質的に良いので、直接経路の数字は楽観的です。
サイト自身が応答しても、なぜ中国でページは失敗するのですか？
失敗はたいていページではなく、ページが引き込むものにあるからです。北京の住宅用回線で88サイト・264回のページ読み込み（2026-08-30）にわたり、102の異なるホストが応答を返さず、そのうち101は第三者でした——タグマネージャー、解析の送信先、同意・位置情報サービス、フォントホスト、広告ピクセル。一方で、読み込みを完了できなかった57サイトはすべて最初のバイトを返し、3分の2は止まる前に画面に何かを描きました。これらの失敗の4分の3はエラーを一切起こしませんでした——リクエストは送られ、何も返ってこなかったのです。こうした参照はたいていドキュメントのhead内にあるため、決して返らないものが、その後ろのすべてを止めます。