2026年10月7日時点で、ShifterはOxylabsやBright Dataを上回る、最大規模の米国ライブIPプールを保有しており、しかもコストはその一部で済みます。Shifterは現在、稼働中の米国IPの中で最大のプールを保有しています

ベンチマークを見る

データソースとしてのウェブアーカイブ: Wayback Machineでわかること、わからないこと

Wayback Machineは1兆件を超えるキャプチャを保有している。その検索方法、カバレッジと品質が不十分な点、そして近年より多くのサイトがアクセスを拒否するようになった理由について。

データサイエンス · 2026年11月10日に更新 · 2分で読めます
1ページのキャプチャ20202026キャプチャページが変更されました
数十件のキャプチャのうち、変更は6件です。アンバーのマークは、実際にページが変更された箇所を示しています。
ナレッジ
このページについて
  1. Wayback Machineが保存しているもの
  2. クエリの方法
  3. カバレッジが不十分な点
  4. 品質が不十分な点
  5. なぜアクセスが難しくなっているか
  6. アーカイブをうまく使う方法
  7. プロキシが役立つ場面と、役立たない場面
  8. 結論
  9. 出典と参考文献

最も多くのウェブデータは現在についてのものだ。今日の価格、今日のランキング、今日のページ。しかし多くの疑問には過去が必要になる。競合のプライシングページはこの3年でどう変化したか。ポリシーページに条項が追加されたのはいつか。リデザイン前のサイトはどんな見た目だったか。ウェブデータを収集するチームにとって、ウェブアーカイブはそうした答えが今も存在する唯一の場所であることが多い。

最大のものはInternet ArchiveのWayback Machineだ。本ガイドでは、そこに何が保存されているか、どうクエリするか、データがどこで不十分か、そしてなぜアクセスが難しくなっているかを扱う。

Wayback Machineが保存しているもの

2025年10月22日、Internet Archiveは「1兆ウェブページの保存」を祝った。これはWayback Machineを通じて利用できる。そのインフラチームによる2026年のプレゼンテーションでは、現在のペースは1日あたり約8億ページのキャプチャで、Archiveの全コレクションを合わせたユニークデータは210ペタバイト以上に上るとしている。

この数字について2点注意したい。まず、ここでの「ページ」とはキャプチャのことであり、人気のあるURLは何千回も登場しうる。次に、Archiveはユニークなurlの保有数を公表していないため、1兆という数字はウェブ全体の広さよりも、一部のページの深さを物語っている。

対照的に、Common Crawlの2026年8月のクロールは21億4000万ページを保持しており、一括でオープンにダウンロード可能だ。この2つは異なる問いに答える。Common Crawlは広範な月次サンプルであり、Wayback Machineは特定のurlの長い履歴だ。Common Crawlに関する私たちのガイドでは、そうしたデータセットで十分な場合について扱っている。

クエリの方法

Wayback Machineにはプログラムによるアクセス用に文書化された2つのインターフェースがある。

インターフェース返す内容向いている用途
CDX Server APIキャプチャごとに1行: urlキー、タイムスタンプ、元のurl、MIMEタイプ、ステータスコード、コンテンツダイジェスト、長さキャプチャの一覧化とフィルタリング
Availability APIある日付に最も近い単一のキャプチャ1つのurlの1時点を確認する

大部分の作業をこなすのはCDX APIだ。ステータスコードやMIMEタイプでフィルタし、隣接する重複をまとめ、大量の結果をページングできる。そのドキュメントは一括クエリにページングを推奨している。最も手間を省けるコツは、コンテンツダイジェストでまとめることで、実際にページが変化したキャプチャだけを見ることができる。

import time
import requests

UA = "research-pipeline/1.0 (data-team@example.com)"

def captures(url, start="2020", end="2026"):
    params = {
        "url": url,
        "output": "json",
        "fl": "timestamp,original,statuscode,digest",
        "filter": "statuscode:200",
        "collapse": "digest",  # keep only captures where the content changed
        "from": start,
        "to": end,
    }
    r = requests.get("https://web.archive.org/cdx/search/cdx",
                     params=params, headers={"User-Agent": UA}, timeout=60)
    r.raise_for_status()
    rows = r.json()
    return [dict(zip(rows[0], row)) for row in rows[1:]]

def fetch(capture):
    # id_ returns the archived bytes without the Wayback banner or rewritten links
    url = f"https://web.archive.org/web/{capture['timestamp']}id_/{capture['original']}"
    time.sleep(5)  # one request at a time, with a pause
    return requests.get(url, headers={"User-Agent": UA}, timeout=60)

for c in captures("example.com/pricing"):
    print(c["timestamp"], c["digest"])

CDXのリストから始め、実際に必要なキャプチャを見極め、それらだけを取得する。2,000件のキャプチャのリストが、数十個の異なるバージョンにまとまることも珍しくない。

カバレッジが不十分な点

アーカイブはキャプチャしたものしか保持しておらず、キャプチャには偏りがある。

  • すべてがアーカイブされているわけではない。 複数のソースから抽出したurlを対象とした研究では、サンプルによって35%から90%のウェブに少なくとも1つのアーカイブコピーがあると推定され、月に1回以上アーカイブされたurlは31.3%を超えなかった。
  • ウェブは消え続けている。 Pew Researchは2024年、2013年に存在したページの38%がもはやライブウェブ上でアクセスできないことを発見した。そうしたページの多くにとって、アーカイブのコピーだけが残された全てであり、それすら存在すればの話だ。
  • カバレッジは国によって異なる。 研究では長年、アーカイブのカバレッジが国や言語によって異なり、各国のウェブアーカイブは自国のドメインをより良くカバーする傾向があることが示されてきた。
  • JavaScriptがコンテンツを隠す。 アーカイブされたページを対象とした研究では、JavaScriptが欠落した埋め込みリソースの52.7%の原因であることが分かった。シングルページアプリケーション、スクリプトで読み込まれる価格、コンセントウォールの背後にあるコンテンツは、欠落しているか空であることが多い。

したがって、アーカイブに存在しないことは、それがかつて存在しなかった証拠にはならない。アーカイブのカバレッジはサンプルとして扱い、サンプリングの欠落をデータとともに記録すべきだ。

品質が不十分な点

存在するキャプチャであっても、訪問者が見たものを示しているとは限らない。

1ページ内での時間のずれ。 ページのHTML、画像、スクリプト、スタイルシートは、異なる時点でキャプチャされることが多い。15のアーカイブにまたがる82,425件のアーカイブ済みページを対象としたある研究では、時間的に一貫していたのはわずか38.7%であり、一貫性と完全性の両方を満たしていたのは5件に1件程度、17.9%にすぎなかった。

無関係なキャプチャ。 あるurlの履歴には、パークされたドメイン、エラーページ、乗っ取られたコンテンツが含まれうる。ある研究では、サンプリングしたキャプチャ履歴の24%に無関係なページが見つかった。

サイレントなエラー。 ステータス200のキャプチャであっても、ブロックページやコンセントウォール、ソフト404である可能性がある。ライブスクレイピングにおけるサイレントな失敗について私たちが推奨しているのと同じチェックがここにも当てはまる。ステータスコードだけでなく、コンテンツ自体を検証することだ。

これは分析において、バージョン間でテキストと構造化フィールドを比較すべきであり、スクリーンショットではないこと、そして抽出した値すべてにキャプチャのタイムスタンプを添えておくべきことを意味する。変化検出に関する私たちのガイドでは、ノイズに埋もれることなくバージョン間の差分を取る方法を扱っている。

なぜアクセスが難しくなっているか

2つの圧力がアーカイブの提供できる範囲を狭めている。

サイト側がアーカイブを締め出している。 2025年8月、RedditはWayback Machineのアクセスを制限し始め、AI企業がアーカイブ経由で自社データをスクレイピングしたと述べた。2026年1月までに、Nieman Labは9カ国の1,167のニュースサイトのうち241サイトがInternet Archiveのクローラーの少なくとも1つを拒否していることを発見した。The New York Timesはこう述べた。「私たちはInternet ArchiveのボットがTimesにアクセスするのをブロックしています」。Archive自身のFAQは、特定のAI企業がそれを通じてスクレイピングしていることを出版社が指摘できなかったと注記しているが、いずれにせよカバレッジの欠落は現実のものだ。

Archive自身が防御している。 2026年9月、Internet ArchiveはWayback Machineが「大量の自動化トラフィックの波に見舞われた」こと、保護措置を導入したこと、そしてブロックされたリクエストには429エラーが返されることを明らかにした。そのFAQにはこうある。「私たちは、乱用的なアクセスを防ぐためにレート制限、フィルタリング、監視を使用しています」、そして「Wayback Machineは人間の読者のために作られています」。

Archiveは非営利の図書館であり、過去には大量のトラフィックによってオフラインに追い込まれたこともある。保護措置が存在する理由は、まさにヘビーユーザーにある。

アーカイブをうまく使う方法

  1. ページではなくインデックスにクエリする。 CDX APIを使って必要なキャプチャを見つけ、ダイジェストでまとめ、最小限だけを取得する。
  2. ゆっくりと、身元を明らかにして。 一度に1リクエストずつ、間隔を空けて、説明的なUser-Agentを使う。大規模なプロジェクトの場合は、まずArchiveに連絡する。
  3. 他のアーカイブも確認する。 Mementoの標準を通じてアクセスできる各国の図書館やその他のアーカイブが、欠落を埋められる場合がある。
  4. 出所を記録する。 AIトレーニングパイプラインにおける出所に関する私たちのガイドが述べているように、キャプチャのタイムスタンプ、元のurl、ダイジェストをすべての値とともに保持する。
  5. 欠落を報告する。 キャプチャが存在しなかったurl、あるいは使用可能なキャプチャがなかったurlが何件あったかを明示し、読者が結果を判断できるようにする。

プロキシが役立つ場面と、役立たない場面

Wayback Machineの制限を回避するためにプロキシを使ってはならない。それは公共の使命を持つ図書館であり、その保護措置は大量の自動化トラフィックのせいで存在し、429を回避するためにIPをローテーションすることは、まさに防御されている行為そのものだ。丁寧なアクセスで許される以上のものがプロジェクトに必要な場合は、Archiveに相談すべきだ。

レジデンシャルプロキシは別の仕事に向いている。今日の現地の訪問者が見ているライブウェブを収集することだ。多くの歴史的データセットはそこから始まる。今気にかけている市場から、今気にかけているページを今キャプチャしておけば、後で他者のアーカイブに頼る必要はなくなる。

結論

Wayback Machineはウェブの過去に関する最も深い記録であり、CDX APIはそれを実用的に使えるものにしている。しかしそのカバレッジはサンプルにすぎず、キャプチャは複数の時点を混在させうるし、ますます多くのサイトがそれを締め出している。インデックスにクエリし、取得は最小限にとどめ、得られたものを検証し、すべての値がどこから来たかを記録し、アーカイブを共有された公共資源として扱うべきだ。

出典と参考文献

  • Internet Archive, one trillion web pages archived (22 October 2025): blog.archive.org
  • Jonah Edwards, Internet Archive materials update, Designing Storage Architectures meeting (2026): digitalpreservation.gov
  • Wayback CDX Server API documentation: github.com
  • Wayback Machine APIs: archive.org
  • RFC 7089, HTTP Framework for Time-Based Access to Resource States (Memento): rfc-editor.org
  • Common Crawl, August 2026 crawl archive: commoncrawl.org
  • Ainsworth et al., How much of the web is archived?: arxiv.org
  • Pew Research Center, When online content disappears (17 May 2024): pewresearch.org
  • AlSum et al., profiling web archive coverage: arxiv.org
  • Brunelle et al., the impact of JavaScript on archivability (2016): doi.org
  • Ainsworth, Nelson and Van de Sompel, temporal coherence of archived pages (2015): ws-dl.blogspot.com
  • AlNoamany, Weigle and Nelson, detecting off-topic pages in web archives (2016): doi.org
  • Nieman Lab, News publishers limit Internet Archive access (28 January 2026): niemanlab.org
  • Engadget, Reddit restricts the Wayback Machine (August 2025): engadget.com
  • Internet Archive, An update on Wayback Machine access (15 September 2026): blog.archive.org
  • Internet Archive, FAQ on publishers blocking the Wayback Machine: help.archive.org

よくある質問

Wayback Machineからデータを取得するにはどうすればよいですか。

キャプチャの一覧を取得するには、CDX Server APIを使用してください。これはキャプチャごとに1行を返し、タイムスタンプ、URL、ステータスコード、コンテンツダイジェスト、サイズを含み、フィルタリング、折りたたみ、ページネーションに対応しています。最も近い単一のキャプチャを取得するには、Availability APIを使用してください。そのうえで、必要なキャプチャだけをゆっくり取得してください。

Wayback Machineにはレート制限がありますか。

しきい値は公開されていませんが、制限はあります。2026年9月、Internet Archiveは大量の自動化トラフィックの波を受けて保護策を導入したと発表し、ブロックされたリクエストには429エラーが返されます。同団体のFAQでは、レート制限、フィルタリング、モニタリングを用いており、Wayback Machineは人間の読者向けに構築されていると述べられています。

Wayback Machineの網羅性はどの程度ですか。

網羅性には程遠いです。研究によれば、ウェブページのうち35%から90%が少なくとも1つのアーカイブコピーを持つと推定されていますが、これはサンプルの取り方によって変動し、頻繁にアーカイブされるページはさらに少なくなります。JavaScriptでコンテンツを読み込むページや、アーカイブのクローラーをブロックするサイトは、カバー率が低くなります。

アーカイブされたページを見れば、訪問者が実際に見たものがわかると信頼できますか。

必ずしもそうとは限りません。ページとその画像、スクリプト、スタイルは、しばしば異なる時点でキャプチャされています。15のアーカイブにまたがる82,425件のアーカイブページを対象としたある研究では、完全かつ時間的に一貫していたのは約5件に1件に過ぎないことがわかりました。結論を出す前にリソースのタイムスタンプを確認してください。

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

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

始める