ウェブは記憶を失っている：デジタル劣化と闘う
年間に数百万ページが消えるウェブ。リンク切れが歴史記録を脅かす理由と、開発者にできるデジタル劣化への対策を解説します。
Elena Vasquez
2014年、気候研究者のマリア・チェン博士は北極海の氷の融解に関する画期的なデータセットを公開しました。大学のサーバーでホスティングし、査読付き論文3本にリンクを張り、十数の学術メーリングリストで共有しました。ところが2019年に大学がウェブインフラを移行すると、URLは切れ、データセットは消えてしまいます。どの公開アーカイブにもバックアップは残っていませんでした。5年分のフィールドワークが、404エラー一つに変わってしまったのです。
チェン博士の件は珍しくありません。むしろ当たり前なのです。ウェブは驚くほどの速さで記憶を失っていて、私たちは必要になって初めて、それがすでに消えていたことに気づくのです。
リンク切れと、ウェブ史のじわじわとした浸食
研究者たちはこれを「リンク切れ（link rot）」と呼んでいます。URLが機能しなくなっていく、ゆっくりと、しかし容赦なく進む現象です。Pew Research Centerの調査では、2013年のウェブページのおよそ38%が、10年以内にアクセスできなくなっていました。これは誤差の範囲ではありません。たった1年分に書かれた知識の3分の1以上が、丸ごと消えたということです。
原因は実にありふれたものです。企業が合併したり社名を変えたりする。ホスティング料金の支払いが滞る。CMSを入れ替える。選挙のたびに政府のサイトが再編される。ブログの作者が亡くなり、誰もドメインを更新しない。どれも単独では大事件に見えません。しかし積み重なっていきます。年々、ウェブは過去の自分を皮が剥がれるように落としていくのです。
その影響は抽象的な話ではありません。裁判所が判決文でURLを引用したものの、数か月後にはリンクが死んでいた、という事例もあります。ジャーナリストが取材資料を失うこともあります。プラットフォームが方向転換したりサービスを終了したりすると、そこにあったコミュニティ全体──会話、内輪ネタ、創作物、共同で積み上げた知識──が一夜にして消えることもあります。Vine、Google+、初期のGeoCitiesを覚えていますか？サービスが終わるたびに、二度と完全には再構築できない文化史の一片が失われていくのです。
ウェブアーカイブはなぜ簡単になるどころか難しくなっているのか
状況は良くなっているはずだと思うでしょう。ストレージは安く、帯域は潤沢です。成熟したアーカイブツールもあり、保存に特化した組織もあります。それなのに、なぜ問題は悪化しているのでしょうか。
2つの力が重なっています。1つ目は技術的な要因です。現代のウェブは、初期インターネットの静的なHTMLページに比べて、アーカイブがはるかに難しくなっています。SPAはコンテンツをすべてJavaScriptで描画します。API駆動のサイトには、キャプチャできる安定したURLがありません。ペイウォールや認証ゲート、パーソナライズされたコンテンツフィードは、訪問者ごとに異なるページを作り出します。アーカイブ用のクローラーも例外ではありません。
2つ目は政治的な要因です。大規模言語モデルの爆発的な普及は、ウェブクロールへの反発を生みました。許可なく自分のコンテンツがAIの学習に使われることを懸念した発行者やサイト運営者は、攻撃的なブロック措置を導入しています。robots.txtを更新し、ボット検出を実装し、データ収集に使われているとみなしたIPレンジを丸ごとブロックしているのです。
その結果、思わぬ副作用が出ています。こうしたブロック措置は、商用AIクローラーとアーカイブ用クローラーをほとんど区別しません。インターネット・アーカイブのWayback Machineはrobots.txtを尊重します。サイトがすべてのボットを一律にブロックすると、アーカイブ用クローラーも締め出されます。サイト運営者はAIの学習を止めたいだけでしょう。ところが実際に起きているのは、そのサイトの歴史的記録が一つも残らなくなることです。
AIによるスクレイピングを防ぐためにアーカイブ用クローラーをブロックするのは、本をコピーされないように図書館を焼くようなものです。意図は理解できます。しかし歴史的記録が受けるダメージは計り知れません。
インターネット・アーカイブ：圧力を受けながらも不可欠な存在
インターネット・アーカイブは、ウェブにとって最も公共図書館に近い存在です。そのWayback Machineは1996年以来、8000億を超えるウェブページを保存してきました。この数字は途方もないものですが、それでもオンラインに公開されたものの一部にすぎません。
同団体は深刻な逆風にも直面してきました。Open Libraryの貸出プログラムをめぐる訴訟には、多くの資源と注意が割かれました。さらに、それらの訴訟を見た他の機関がアーカイブ対象に慎重になるなど、デジタル保存活動全体に萎縮効果も及んでいます。
しかし最大の課題は、単純に規模の問題です。ウェブは、どの単一組織が取り込めるペースよりも速く成長しています。さらに動的でJavaScriptに依存したアプリケーションへの移行により、従来型のクロールでは、ユーザーが実際に目にするものの取り込み量がどんどん減っています。ReactアプリのRAWなHTMLをクロールすると、空のdivとJavaScriptのバンドルしか手に入りません。記事も画像もインタラクティブな要素もないのです。
- クライアントサイドで描画されるアプリケーションは、意味のあるスナップショットを取得するためにヘッドレスブラウザが必要
- API駆動のコンテンツには、安定してクロール可能なURLがないことが多い
- 動画、ポッドキャスト、インタラクティブな可視化などのマルチメディアコンテンツには、専用の保存手法が必要
- ウェブコンテンツの増加率は、どの組織のクロール能力も大きく上回っている
- 法的な不確実性があるため、機関は積極的なアーカイブに慎重にならざるを得ない
これは集中型アーカイブを見限る理由ではありません。もはやそれだけに頼るのはやめるべき、という理由です。
開発者なら知っておきたい、セルフホスト型ウェブアーカイブツール
良いニュースがあります。ウェブをアーカイブするのに組織である必要はありません。オープンソースのツールが充実してきていて、個人や小規模チームでも自前のアーカイブ基盤を運用しやすくなりました。中にはびっくりするほど強力なものもあります。
個人利用で一押しなのはArchiveBoxです。URLを受け取り、HTML、PDF、スクリーンショット、WARCなど複数の形式で保存するセルフホスト型ツールです。ブラウザのブックマーク、RSSフィード、プレーンテキストのURLリストを食わせると、閲覧可能なローカルアーカイブが作られます。セットアップは数分で終わります：
# Set up ArchiveBox with Docker
docker pull archivebox/archivebox
mkdir -p ~/web-archive && cd ~/web-archive
docker run -v $PWD:/data -it archivebox/archivebox init --setup
# Archive some URLs
docker run -v $PWD:/data -it archivebox/archivebox add \
'https://example.com/important-report' \
'https://example.org/research-dataset'
# Launch the web UI to browse your archive
docker run -v $PWD:/data -p 8000:8000 archivebox/archivebox server 0.0.0.0:8000JavaScriptを多用するサイトのキャプチャには、Webrecorderが別のアプローチを取ります。クロールする代わりに、実際のブラウザセッションを記録します。すべてのネットワークリクエスト、動的に読み込まれた要素、すべての操作を記録するのです。結果は高忠実度のキャプチャとしてWARCまたはWACZ形式で保存され、ReplayWeb.pageを使ってブラウザ上で再生できます。建物を写真に撮るのと、フル3Dのウォークスルーを作るくらいの違いがあります。
同じWebrecorderプロジェクトのBrowsertrixは、このアプローチをスケールさせたものです。実際のブラウザインスタンスを使ってページを描画・キャプチャするクラウドネイティブのクローリングシステムです。大学、図書館、政府機関が制度的なアーカイブ事業に使っています。JavaScriptの描画を含めて数千ページを保存する必要があるなら、Browsertrixが答えです。
開発ワークフローに保存の仕組みを組み込む方法
フルのアーカイブシステムを立ち上げなくても、貢献はできます。サイトをどう作りどうデプロイするかという小さな判断が、コンテンツを保存できるかどうかに大きく影響します。実際に重要なポイントを紹介します。
1つ目は、アーカイブしやすさを意識した設計をすることです。安定していて人が読めるURLを使いましょう。URL構造をデータベースのIDやセッショントークンに結びつけないことです。重要なコンテンツは、ページ読み込み後にクライアントサイドのJavaScriptで読み込むのではなく、最初のHTMLレスポンスに含まれているようにしてください。SPAを作るなら、フォールバックとしてサーバーサイドレンダリングか静的生成を用意しましょう。これらはアーカイブのためだけでなく、SEO、アクセシビリティ、パフォーマンスにとっても良い習慣です。
2つ目は、robots.txtを外科手術のように精密に扱うことです。AI学習用のクローラーをブロックしたいなら、名前を指定してブロックしてください。サイトに訪れるボットすべてに一律で覆いをかぶせるのはやめましょう。
# robots.txt — block AI crawlers, welcome archival bots
# Explicitly allow archival crawlers
User-agent: ia_archiver
Allow: /
User-agent: archive.org_bot
Allow: /
# Block specific AI training crawlers
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: anthropic-ai
Disallow: /
User-agent: ClaudeBot
Disallow: /
# Default: allow everything else
User-agent: *
Allow: /完璧な仕組みではありません。ユーザーエージェント文字列は偽装できますから。それでも、正当な保存活動への扉は開けたまま、望まない学習だけを閉じるための誠実な努力です。
3つ目は、アーカイブへの登録を自動化することです。何かを公開するたびに、Wayback Machineに送信しましょう。数行のコードで済み、どのCI/CDパイプラインや公開後のフックにも組み込めます：
import requests
import time
def archive_url(url: str, retries: int = 3) -> str:
"""Submit a URL to the Wayback Machine's Save Page Now endpoint."""
save_url = f"https://web.archive.org/save/{url}"
for attempt in range(retries):
try:
resp = requests.get(save_url, timeout=30)
if resp.status_code == 200:
location = resp.headers.get("Content-Location", resp.url)
return f"Archived: https://web.archive.org{location}"
except requests.RequestException:
if attempt < retries - 1:
time.sleep(2 ** attempt)
return f"Failed to archive {url} after {retries} attempts"
# Wire this into your publish script
new_post = "https://yourblog.com/posts/new-article"
print(archive_url(new_post))このリトライ処理は大事です。Wayback Machineの保存エンドポイントには負荷が集中しがちで、一時的な失敗もよく起こります。少し堅牢にしておくだけで、ずいぶん助かります。
WARCを理解する：ウェブアーカイブの裏側にあるファイル形式
ウェブアーカイブを扱うなら、WARCを理解しておく必要があります。Internet Archive、Webrecorder、そして本格的なアーカイブツールの多くが使っている、ISO標準のファイル形式です。WARCファイルは、ページを読み込む際に発生するすべてのHTTPリクエストとレスポンスの完全な記録だと考えてください。HTML、スタイルシート、スクリプト、画像、API呼び出し。すべてです。
この網羅性があるからこそ、再生が可能になります。WARCファイルは生のHTMLだけを保存しているのではありません。キャプチャ時点のページを再現するために必要な文脈全体を保存しているのです。プログラムから読み込む方法は次のとおりです：
from warcio.archiveiterator import ArchiveIterator
def inspect_warc(filepath: str):
"""List all HTTP responses captured in a WARC file."""
with open(filepath, "rb") as stream:
for record in ArchiveIterator(stream):
if record.rec_type == "response":
url = record.rec_headers.get_header("WARC-Target-URI")
status = record.http_headers.get_statuscode()
content_type = record.http_headers.get_header("Content-Type")
print(f"[{status}] {url} ({content_type})")
inspect_warc("my-archive.warc.gz")新しいWACZ形式は、WARCの上にインデックスとメタデータの層をZIPコンテナ内に追加したものです。実用面での利点は非常に大きいです。WACZファイルはReplayWeb.pageを使ってブラウザで直接開けて、サーバー基盤は一切不要です。WACZファイルをメールで送れば、相手はすぐにアーカイブされたサイトを閲覧できます。技術的に可能なだけでなく、実際に役立つ保存を実現するための、摩擦の少ないアクセス手段です。
コミュニティによるアーカイブと、ボランティアによる安全網
最もドラマチックな保存活動の多くは、緊急事態の中で行われます。プラットフォームがサービス終了を発表すると、ArchiveTeamというボランティアグループが動員されます。GeoCities、Vine、Google+など、数十の小規模サービスのコンテンツを救出してきました。彼らの方法はシンプルです。サーバーが停止する前に、大量のアーカイブリクエストを送りつけ、すべてをWARC形式で保存し、一般公開のためにInternet Archiveへアップロードするのです。
誰でも貢献できます。ArchiveTeamのWarriorツールは、自分のマシンで動かす仮想アプライアンスです。同団体の調整サーバーに接続し、アーカイブのタスクを受け取り、進行中の救出作業に自分の帯域と処理能力を提供します。最も草の根的な形の分散アーカイブと言えるでしょう。
ただ、緊急救出は最後の手段です。本当の目標は、保存を日常的なものにすることです。分野ごとのコミュニティが次々と動き出しています。メーリングリストや課題トラッカーを保存するOSSプロジェクト、先住民の言語資料を守る文化遺産団体、調査報道のアーカイブを維持するジャーナリズム組織などです。ツールはすでにあります。難しいのは、年々この取り組みを続けるための人的な調整と資金を確保することです。
実践的なデジタル保存ツールキット
ここまで読んで実際に行動したいなら、スターターキットを紹介します。どの規模のウェブアーカイブにも使える、最も成熟していてメンテナンスの行き届いたツールです。
- ArchiveBox：セルフホスト型の個人アーカイブ。HTML、PDF、WARC、スクリーンショット形式で保存。自分の研究や参考資料の保存に最適。
- Browsertrix：ブラウザベースのクロール、制度的規模向け。実際のブラウザインスタンスでJavaScriptを完全に描画。
- Webrecorder：ブラウザセッションを記録し、高忠実度のインタラクティブなキャプチャを実現。WARC/WACZファイルを出力。
- ReplayWeb.page：WARC/WACZファイルをブラウザ上で直接再生。サーバー不要。
- SingleFile：ウェブページ全体を、単一の自己完結型HTMLファイルとして保存するブラウザ拡張機能。とにかくシンプル。
- warcio：WARCファイルをプログラムから読み書き・処理するためのPythonライブラリ。
- Heritrix：Internet Archiveのオープンソースクローラー。産業用途の堅牢性があるが、学習コストは高め。
- ArchiveTeam Warrior：分散型のボランティアアーカイブプロジェクトに参加するための仮想アプライアンス。
- Wayback Machine API：アーカイブページの送信と取得をプログラムから行うためのAPI。
- Conifer：個人や小規模チーム向けのマネージド型ウェブアーカイブサービス。自前でホストしたくない人向け。
ウェブは自力では保存されない
「インターネットは決して忘れない」という根強い神話があります。実際には忘れます。絶えず忘れていきます。ウェブは図書館というより川に近いものです。コンテンツは流れていき、誰かが意図的にスナップショットを撮らなければ、源流が枯れた瞬間に消えてしまいます。
ここで開発者はなかなか大きな影響力を持っています。私たちはrobots.txtを書き、URL設計をし、サーバーサイドで描画するかクライアントサイドで描画するかを選びます。さらに、数行のコードを足すだけで新しいページをすべて公開アーカイブに送れるデプロイパイプラインを組んでいます。どれも英雄的な行為ではありません。ウェブの歴史が生き残るかどうかを、たまたま決めてしまう小さな技術的判断なのです。
チェン博士のデータセットは、今も失われたままです。URLが切れる前に、どのアーカイブも保存していませんでした。しかし今日も、誰かが重要なものを公開しています。調査報道の記事、科学的なデータセット、何年も引用されることになるコミュニティフォーラムのスレッド。問題は、そのコンテンツがいつか消えるかどうかではありません。消えるのです。問題は、先にコピーを保存しておく人がいるかどうかです。
