毎日のスクレイピングダッシュボードには成功率という指標があり、そのほぼすべてが同じものを数えている。HTTP 200を返したレスポンスの数だ。これは集計しやすく、報告しても安心できる数字だ。しかしこれはウェブデータ収集において最も誤解を招く数字でもある。なぜなら200はサーバーが何かを返したという意味しか持たず、それがリクエストしたページそのものだったかどうかについては何も語らないからだ。
この2つの間のギャップこそが、静かな失敗率(silent failure rate)である。「成功」とみなされたリクエストのうち、実際には誤ったコンテンツを返していた割合のことだ。これはログには見えない失敗であり、データセットの中では正常なデータとまったく同じ顔をして紛れ込む。
では、その規模はどれくらいか。正直な答えは、誰もそれを公表していないということだ。この不在こそが最も興味深い発見であり、本稿の残りの部分では、なぜそれが存在するのか、近い測定値が何を示しているのか、そして自分自身のデータについてどう測定すればよいのかを扱う。
要点
- ウェブ全体でHTTP 200レスポンスのうちどれだけの割合が誤ったコンテンツを含んでいるかを測定した公表研究は存在しない。最新の大規模なボットブロッキング研究は、200レスポンス内のコンテンツ劣化は調査対象外であると明記している。
- ブロッキングは一般的だが、ラベル付けが不十分だ。Common Crawlを対象としたある研究では、少なくとも1.68%のサイトがクローラーを明示的に拒否しており、ステータスコードの使い方は一貫性がなく、誤っている場合すらあった。
- ブロックページは実際に200として届く。キューバに関する2023年の測定では、ブロックページを提供していた395ドメインのうち32ドメインがステータス200でそれを行っていた。
- 主要なリンク切れ(link-rot)研究では、ソフト404ページを生存しているものとしてカウントしている。コンテンツを確認することはステータスコードを確認することよりもはるかに難しいからだ。
- 自分自身の静かな失敗率は測定可能だが、それはステータスではなくコンテンツを検証することによってのみ可能だ。
何が静かな失敗にあたるか
静かな失敗とは、成功を報告しながら実際の訪問者が受け取ったはずのものを含んでいないレスポンスのことだ。よくある形態は以下の通り。
| 形態 | 受け取るもの | なぜ成功として通ってしまうか |
|---|---|---|
| 200として提供されるブロックページ | 本来のページの代わりに拒否メッセージ | ステータスがOKと言っている |
| チャレンジや割り込み画面 | CAPTCHAや「ブラウザを確認しています」ページ | 多くの場合200、時にはエラーコード |
| ソフト404 | もう存在しないコンテンツに対する汎用ページやホームページ | サーバーが404の代わりに200を返す |
| 空のシェル | コンテンツのないHTML。ページがJavaScriptで構築されるため | 完全で有効なドキュメント |
| 同意画面や課金の壁 | コンテンツの手前にある同意画面 | ページはロードされたが、コンテンツはロードされていない |
| 誤ったバリアント | 別の国のページ、価格、言語 | 完全に本物のページだが、意図したものではない |
これらはどれもパース、保存、集計の過程で正常なデータのように振る舞う。どれもエラーアラートを発生させない。
誰も測定していない数字
ボットブロッキングとウェブの劣化を研究する研究者たちは、この問題を繰り返し避けてきており、何人かはそれを明示的に述べている。
最新の大規模研究であるGundelach、Mühlhauser、Herrmannによる「Detecting Bot Detection」(バンベルク大学、2026年6月)は、2026年2月27日から3月2日にかけて、複数のブラウザ構成でTrancoトップ10,000サイトをスキャンした。その限界事項の節ははっきりとこう述べている。「HTTP 200レスポンス内のコンテンツ劣化は、我々の観測範囲の対象外である」。著者らはさらに81本のウェブ測定論文を調査し、「ボット検知やブロッキング率を明示的に定量化している論文はわずか5%であり、83%はそれについての議論を一切省いている」ことを見出した。
彼らは孤立しているわけではない。Common CrawlにおけるPAM 2025の拒否研究は、非200レスポンスを対象に作業していた。2018年のグローバルなジオブロッキング研究は、あるサイトが読み込まれても「ログインボタンが消えている、あるいは一部のコンテンツが利用できない」ことがあると指摘し、そうした「より微妙なコンテンツの変化」は今後の研究課題として残した。Pew Research Centerの2024年リンク切れ研究は、「ソフト404ページのように、コンテンツが存在するかどうかを保証できない曖昧な状況」をアクセス可能として扱った。Internet Archiveの2026年4月の死んだウェブ研究は「HTTP ステータスコードに依拠しており、ソフト404を確認するためにページの内容を調べることはしなかった」。
これはいずれも怠慢ではない。ステータスコードの分類は数百万ページに対してスケールするが、コンテンツが正しいかどうかを判断するには、各ページにとって正しい状態とは何かを知る必要がある。だからこそ、静かな失敗率はウェブ全体の規模では測定されていないのであり、そしてだからこそ、正しい状態を知っている自分自身の対象については測定可能なのだ。
近い測定値が示していること
単一の数字がこの問いに答えることはないが、いくつかの測定値がその範囲を示している。
| 発見 | 出典 | 測定時期 |
|---|---|---|
| ヘッドレスChromiumはトップサイトの15.2%でソフトブロックされ、他のブラウザ構成では6.8%から7.2%だった。ソフトブロックされたサイトの81.9%はボット検知に起因していた | Gundelach、Mühlhauser、Herrmann, arXiv, 2026年6月 | 2026年2月から3月 |
| Common Crawlを少なくとも1.68%のサイトが明示的に拒否しており、ステータスコードの使い方は一貫性がなく、誤っている場合すらあった。拒否したドメインの80%はすべてのリクエストをブロックしていた | Ansar、Sperotto、Holz, PAM 2025 | Common Crawlスナップショット、2023年後半 |
| キューバのユーザーにブロックページを提供していた395ドメインのうち32ドメインが200ステータスを使用していた | Ablove et al., USENIX Security 2024 | 2023年5月 |
| 自動化されたクロールは、実際のユーザーが遭遇したフィンガープリンティングサイトの45%を見逃していた。一部はボット検知を突破できなかったことが原因だった | Annamalai、Bilogrevic、De Cristofaro, WWW 2025 | ユーザー30人、10週間 |
| 45,000サイトのうち0.6%、ドイツのトップ1,000サイトのうち8.5%にクッキーウォールがあった | Rasaii、Gosain、Gasser, IMC 2023 | 2023年 |
| ウェブサーバーの7.35%が未知のドキュメントに対して404の代わりに200を返した | Prieto Álvarez、Álvarez Díaz、Cacheda Seijo, 2014 | 2014年以前 |
| ソフト404が死んだリンクの15%以上を占めていた | Bar-Yossef、Broder、Kumar、Tomkins, WWW 2004 | 2004年以前 |
最初の2行は、エラーコードを通じて可視化されるブロッキングを記述しており、これは見やすい部分だ。3行目はもう一つの部分が存在することを示している。その研究では、ブロックページのおよそ12件に1件が成功の姿をして届いていた。ソフト404の数字は古く、それでも公表されている中では最新のものだ。
下流にかかるコスト
実際のデータセットにおける静かな失敗の最もはっきりとした姿は、公式統計から見えてくる。英国国家統計局(ONS)がウェブスクレイピングによるスーパーマーケットデータから物価指数を試験的に作成した際、2016年5月の更新版では「この検証ステップの後、異常またはミス分類として分類された商品の総割合は25%だった」と報告し、価格の件数を「340万件から250万件に」削減した。欠損データについては「主に小売業者がウェブサイトに構造的な変更を加えたことが原因だった」と付け加えている。
その25%はHTTPレベルの失敗率ではない。その大部分は誤ったカテゴリーにスクレイピングされた商品と外れ値の価格だった。しかしまさにそこがポイントだ。これらの記録はすべて成功したリクエストから返ってきたものであり、その4分の1が使い物にならなかった。それを見つけるには、統計局が構築した検証ステップが必要だった。
なぜステータスコードではこの信号を伝えられないのか
サーバーが拒否を正直に報告してくれれば都合が良い。しかし証拠が示すのは、サーバーはそれを一貫して行っていないということだ。Common Crawlの研究では、拒否がHTTPステータスコードの一貫性のない、時には誤った使い方を通じて示されていることが判明した。キューバの研究では、ブロッキングがDNS失敗、タイムアウト、403、専用の451コードの一部、そして200にまたがって分布していることが判明した。
一部のインフラは実際に助けになる。Cloudflareはすべてのチャレンジページタイプに対してcf-mitigated: challengeレスポンスヘッダーを設定しており、これはステータスコードよりもはるかに信頼できる信号だ。これを確認しよう。しかし一つのプロバイダーのヘッダーはウェブの標準ではなく、ほとんどの静かな失敗には何のマーカーも付いていない。
自分自身の静かな失敗率を測定する
定義はシンプルだ。自分のシステムが成功とみなしたレスポンスのうち、コンテンツ検証に失敗した割合。作業の中身は検証にある。
- レスポンスではなく記録を検証する。 そのページタイプの各記録が含むべきフィールドを決め、それらを生成しない200をすべて失敗として扱う。
- サイズをそのページタイプの通常値と比較する。 商品ページが突然通常の5分の1のサイズになったら、それはめったに商品ページではない。
- ブロックとチャレンジのマーカーを探す。
cf-mitigatedのようなヘッダーや、対象が実際に使っているフレーズを含む。 - カナリアを実行する。 正しいコンテンツを独立して知っているページを、本番と同じ経路で取得し、比較する。
- どこから取得したかを記録する。 誤った国のバリアントは、取得地点をログに記録していなければ検出できない。これはvantage-point standardで論じられている考え方だ。
- 人によるレビュー用にサンプリングする。 週に数十件のレスポンスを人が読むだけで、ルールが想定していなかった失敗モードを捉えられる。
最初の一歩となる分類器は、非常に小さく書ける。
BLOCK_MARKERS = ("captcha", "access denied", "unusual traffic", "verify you are human")
REQUIRED_FIELDS = ("title", "price")
def classify(resp, record, baseline_bytes):
"""Label one response. Anything but "ok" on a 200 is a silent failure."""
if resp.headers.get("cf-mitigated") == "challenge":
return "challenge"
if resp.status_code != 200:
return "http_error"
if not record and any(m in resp.text.lower() for m in BLOCK_MARKERS):
return "block_page"
if len(resp.content) < 0.2 * baseline_bytes:
return "too_small"
if not record or any(record.get(f) in (None, "") for f in REQUIRED_FIELDS):
return "missing_fields"
return "ok"この結果をターゲットごと、ページタイプごとに、すでに持っている成功率と並べて報告しよう。この2つが乖離するとき、成功率は嘘をついている。あるサイトでソフトブロックが増加していることは、そのサイトがクローラーに対して敵対的になりつつある最も早い兆候の一つでもあり、それをつかむために設計されているのがターゲットヘルススコアだ。より広範な指標についてはウェブスクレイピングパイプラインの監視にまとめてある。
ツールが助けになる部分と、なれない部分
マネージドな収集は、いくつかの静かな失敗をあなたに届く前に取り除く。Shifterの Web Scraping APIは、失敗した取得、CAPTCHA、一時的なターゲットのエラーを異なるプロキシで最大3回まで自動的にリトライし、成功したリクエストに対してのみ課金する。JavaScriptレンダリングは、ブラウザ上で自分自身を構築するページにおける空のシェル問題を取り除き、extract_rulesは名前付きフィールドを返すため、欠けているフィールドを検出しやすくなる。
どの収集レイヤーにもできないのは、完全に整った形式のページが誤った価格や誤った国のカタログを含んでいることを知ることだ。自分のデータにとって何が正しい状態かを知っているのは自分だけだ。コンテンツ検証は、ページがどのように取得されたかにかかわらず、パイプラインに組み込まれるべきものだ。
結論
200はサーバーが行う主張であり、コンテンツについての保証ではない。ブロックページ、チャレンジ、ソフト404、空のシェル、同意の壁、誤ったバリアントは、いずれも成功の姿をして届き、公表された研究は、実務上まっとうな理由から、ウェブブロッキングについてほぼあらゆることを測定してきたが、この点だけは測定してこなかった。
その結果、あなたが持つことになる唯一の静かな失敗率は、自分自身で測定したものだけだ。すべての記録を検証し、答えを知っているカナリアを維持し、その結果を成功率と同じダッシュボードに載せよう。この2つの数字の差こそが、現時点で信頼できないデータセットの部分である。
出典と参考文献
- Gundelach、Mühlhauser、Herrmann, Detecting Bot Detection: Prevalence, Techniques, and Implications for Web Measurement Research, arXiv, 2026年6月12日。スキャン期間は2026年2月27日から3月2日。
- Ansar、Sperotto、Holz, Web Crawl Refusals: Insights From Common Crawl, PAM 2025, 2025年3月7日。
- Ablove et al., Digital Discrimination of Users in Sanctioned States: The Case of the Cuba Embargo, USENIX Security 2024。2023年5月に測定。
- McDonald et al., 403 Forbidden: A Global View of CDN Geoblocking, ACM IMC 2018。
- Annamalai、Bilogrevic、De Cristofaro, Beyond the Crawl: Unmasking Browser Fingerprinting in Real User Interactions, WWW 2025。
- Rasaii、Gosain、Gasser, Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web, ACM IMC 2023。
- Prieto Álvarez、Álvarez Díaz、Cacheda Seijo, Soft-404 Pages, a Crawling Problem, Journal of Digital Information Management, 2014。
- Bar-Yossef、Broder、Kumar、Tomkins, Sic Transit Gloria Telae: Towards an Understanding of the Web’s Decay, WWW 2004。
- Pew Research Center, When Online Content Disappears: methodology, 2024年5月17日。
- Sawood Alam, Internet Archive, Gone but Not Forgotten: Recovering the Dead Web, 2026年4月23日。
- Office for National Statistics, Research indices using web scraped data: May 2016 update, 2016年5月23日。
- Cloudflare, Detect a Challenge Page response。
- Shifter, Web Scraping API errors and limits。