Browsertrix Crawler レビュー：コードが示す内容ではなく、ブラウザが実際に行ったことをアーカイブする

Browsertrix Crawler は Webrecorder のアーカイブ用クローラーです。1つの Docker イメージが Puppeteer 経由で実際の Chromium を操作し、ブラウザが取得したすべての内容を記録して、標準的な Web アーカイブ形式である WARC に書き出します。必要に応じて、インデックス・ページ一覧・ログをまとめた WACZ パッケージとして出力することもできます。ここが、見た目は似ていても web scraping ツールとは役割がまったく違う点です。スクレイパーはデータを取りに行って必要な項目だけ抜き出したらページ自体は捨てます。一方でアーカイバーは、アクセスそのもの——バイト列、ヘッダー、到着順まで——を残し、サイトが変わっても消えても後からまた開けるようにします。Webrecorder は、アーカイブがまだ製品カテゴリとして定着する前から、こうした Web の基盤、フォーマット、再生スタックを支えてきました。図書館、報道機関、研究者が今も使っています。

私は v1.14.0 を Docker で動かし、4種類の意図的に異なるエンドポイントを持つローカル検証 fixture に対してテストしました。クロールの両側を計測し、アーカイブ内容については WARC レコードを、実際のリクエストについてはサーバー側のヒットカウンターを使いました。重要だったのは単純に静的か動的かではありません。Browsertrix は、実行時に生成されたリンクとページが発行した fetch() は取得しましたが、呼び出されていない JavaScript 関数の中にある 2つの URL リテラルはリクエストしませんでした。

リンクされた app.js 自体は、2つのリテラルパスを含めてきちんとアーカイブされていました。しかし、そのどちらのエンドポイントも、レスポンス記録・リクエスト記録・サーバーヒットのどれも発生しませんでした。該当の関数が一度も実行されなかったからです。なのでこの記事では、Browsertrix をソースコード内のすべての URL を列挙するツールではなく、ブラウザセッションのアーカイバーとして評価します。

Browsertrix Crawler は実際には何なのか

スクレイパーだと思って来て、がっかりする人は少なくありません。標準のパイプラインには、商品価格を CSV にして返す機能などありませんし、それを期待するのは、ドライブレコーダーに交通レポートの作成を求めるようなものです。出力は再生可能なブラウジングセッションの記録であり、その前提に合わせて設計が組まれています。

私は v1.14.0 を 2026年7月27日にテストしました。webrecorder/browsertrix-crawler:latest の digest は sha256:9d6800a8… で、crawl --version でビルドを確認しています。プロジェクトのライセンスは AGPL-3.0 です。すべての計測は macOS arm64 上の Colima 経由で Docker を使い、管理されたローカル fixture に対して行いました。サーバー側のカウンターは、Browsertrix のログやアーカイブ解析とは独立した証拠として使っています。

AGPL-3.0 は少し立ち止まって確認する価値があります。ネットワーク利用条項を含む強いコピーレフトです。Browsertrix Crawler を単独ツールではなく商用プロダクトの一部として組み込むなら、出荷前にきちんとライセンス確認をしておくべきです。これは注意喚起であって、法的助言ではありません。

アーカイブが記録するのはソースコードではなくセッション

この fixture では、あえて分けて置いた 4種類のエンドポイントを用意しました。アーカイバーはそれぞれをまったく別物として扱うからです。

• Class A — HTML 内の素直な <a href>。4ページと 3階層の深さを持つチェーン。世の中のどのクローラーでも見つけられます。
• Class B — 一度も実行されない関数内の URL リテラル。/api/js-endpoint-7 と /api/js-endpoint-8 の 2パスが、リンクされた app.js 内の未呼び出し loadData() に文字列として置かれています。
• Class C — 実行時に組み立てられるリンク。JavaScript でフラグメント（'endpoint' + (6 * 7)）をつなぎ、DOM に追加した <a href>。連結後のパス /runtime-only/endpoint42 は、配信されたバイト列のどこにもそのままでは存在しません。
• Class D — ページが実際に発行する fetch()。同じようにパスを組み立て（'runtime-xhr-' + (33 * 3)）、読み込み時に本当に要求します。

Class C と D では、完成したパスは配信ファイル中に連続した文字列としては存在していません。なので、サーバー側のヒットとレスポンス記録が残っていること自体が、この fixture でランタイム構築とリクエスト経路が実際に動いた証拠です。

何が捕捉され、何が捕捉されなかったか

2つの計測手段を、各項目で突き合わせました。WARC のレスポンス記録（アーカイブ内に何が入っているか）と、(Host header, path) で集計した fixture のサーバー側ヒットカウンター（実際に何が要求されたか）です。結果はすべて一致しました。

Class C は、実ブラウザと静的クロールを分けるポイントです。デフォルトのリンク抽出は、一般オプションのドキュメント にある通り、描画後の DOM（a[href]->href）を読み取るため、JavaScript 実行後にしか存在しないリンクでもキューに入り、取得され、アーカイブされます。Class D は別の理由で拾われます。ページ自体がリクエストを発行しており、アーカイバーはネットワーク経路上にいるので、その流れを記録できるからです。

ただし、Class C には1点だけ正直な境界があります。今回のリンク注入は ページ読み込み時に同期的 に行いました。Browsertrix の behaviors の途中で後から出てくるリンクは別ケースで、ちょうどその件については未解決の issue があります。#723, "Links on pages that are discovered during behaviors are not extracted" です。私はそのシナリオを試していないので、そこは断言しません。

ファイルはアーカイブされた。エンドポイントはされなかった。

Class B の取りこぼしを確認するには、集計値ではなく WARC をレコード単位で追う必要がありました。

app.js は確かにアーカイブ内にあります。レスポンス記録は1件、JavaScript 本体は 222 バイト。そして Class B の 2つのリテラルは、その中にそのまま入っています。一方で、/api/js-endpoint-7 と /api/js-endpoint-8 は、ファイル全体のどのレコードでもターゲット URI にはなっていません。レスポンス記録 0、リクエスト記録 0 です。各リテラル文字列はアーカイブ全体でちょうど1回ずつ現れ、その 2回とも app.js の保存済み本文の中でした。

これで、ありがちな説明——「app.js がそもそも取得されていなかった」——は否定されます。アーカイバーは、そのエンドポイントを参照するファイル自体は保存していたのに、それらへのリクエストは一切発行しませんでした。loadData() が呼ばれなかったからです。Browsertrix の標準 behaviors は有効でした。autoplay、autofetch、autoscroll、siteSpecific のすべてです。それでも autofetch は助けになりませんでした。これは autofetch の説明 を読めば納得できます。対象は img の srcset、stylesheets、data-* URL であって、関数本体の中に埋め込まれた文字列リテラルではないからです。

同じ fixture を使った比較として、Katana v1.6.1 も katana -u <seed> -jc -silent -nc -d 4 で実行しました。生の discovery summary には、意図的に作った 2つの JavaScript クラスに対して逆の結果が記録されています。

2つのコマンドは同じ fixture とエンドポイント名を使いました。この表は、ブラウザ型クローラーと静的クローラーの一般的な優劣を示すものではありません。エンドポイントの棚卸しとセッション保存には、別々のカバレッジテストが必要だということを示しています。

「実ブラウザだから JavaScript のやることは全部取れる」——レビュー記事でよく見る表現ですが、少し言い過ぎです。実行されたトラフィックは取れます。URL を参照していても一度も呼び出されないコードはトラフィックを生まず、トラフィックがなければ記録も残りません。

リプレイ用の本文は入っているが、確認していないこともある

実行時に生成された 2つのエンドポイントについては、WARC から保存済み HTTP レスポンス本文を取り出し、提供された JSON が入っていることを確認しました。ランタイム注入リンクの先は 206バイト、ランタイム fetch() の先は 201バイト です。つまり、内容のないインデックス stub ではありません。リプレイ時に表示できる前提となる本文そのものがアーカイブ内に存在しています。

ただし、pywb や replayweb.page を立ち上げて、実際にアーカイブをレンダリングするところまではやっていません。本文がアーカイブにあることと、正しくレンダリングされたリプレイができることは別の話です。このテストがカバーしているのは前者だけです。リプレイ挙動、真正性の担保、保全の連鎖、証拠としての採用可能性は、それぞれ別途検証が必要です。

本番の保全には、もっと広い受け入れテストが必要

この fixture が答えているのは狭い問いです。同期的に生成されたランタイムリンクと、ページが発行したリクエストは、ネットワークトラフィックとアーカイブ記録になったのか？ という問いです。本番の保存ジョブは、WACZ をちゃんと生成できていても、失敗しうるポイントが他にもいくつかあります。

まずはリプレイから始めてください。実際にコレクションで使うリプレイシステムでパッケージを開き、一定数のページをキャプチャ時の参照と比較します。描画されたテキスト、画像、スタイル、ナビゲーション、そして記録に必要なインタラクションを確認します。そのうえで、リプレイ側ブラウザのネットワークパネルを見て、欠けているサブリソースがないか調べます。WARC にレスポンス本文が存在していても、書き換え、インデックス、タイミング、オリジン、依存関係が噛み合わなければリプレイは失敗します。本レビューではその境界までは踏み込んでいません。

動的挙動には専用の fixture セットが必要です。ここでの Class C のリンクは、ページ読み込み時に同期的に現れました。実アプリでは、タイマー、スクロール、同意ダイアログの閉鎖、ルート変更、カスタム要素、長い API 連鎖の後に内容が出てくるかもしれません。依存する各挙動の背後に既知のターゲットを1つずつ置き、サーバーヒットとアーカイブ本文の両方を確認してください。Browsertrix のデフォルト behaviors は、そのテストの入力としては有用ですが、「遅延状態がすべて到達した」証明にはなりません。特に、リンクが初回ページ実行時ではなく behaviors 中に現れるなら、issue #723 が重要です。

認証付きのキャプチャでは、セッションの扱いが問題になります。ログイン状態がブラウザプロフィールに入り、必要な遷移をまたいで維持され、分離すべきコレクションに漏れないことを確認してください。トークン更新とログアウトの経路も実行します。アーカイブに私的・個人情報が含まれる可能性があるなら、同じ受け入れ計画の一部としてアクセス制御と保持期間もテストしてください。技術的に完全なキャプチャでも、収集後の扱いがまずければ台無しになります。

サービスワーカー、ストリーミングメディア、WebSocket、ダウンロード、クロスオリジン iframe、署名付き URL なども、対象にとって重要なら代表的なページで確認が必要です。11ページの fixture だけでは、それらについて何も言えません。また、ページが数分間アクティブであり続ける場合、通常の settle ウィンドウの後にリクエストを出す場合、ユーザー操作が必要な場合の挙動も示していません。real Chromium という言葉を万能のカバレッジ保証にしないでください。収集で保持すべきブラウザ挙動を定義し、それぞれを観測可能にしておくべきです。

最後に、取りこぼしを診断するために必要な証拠を残してください。正確なイメージ digest とコマンド、Browsertrix のログ、ページ一覧、インデックス、WARC/WACZ のチェックサム、利用可能ならサーバー側リクエスト証跡、そして小さな ground-truth マニフェストを保存します。繰り返しキャプチャするなら、アーティファクトとともに時刻・設定・環境も記録してください。これらの記録は法的な証拠能力を自動的に生むわけではありませんが、技術的な主張を再現可能にし、後から見つかった差分が対象、クローラー、リプレイスタックのどこから来たのかを明らかにします。

この小さな本文の fixture は、どれだけ容量を食うのか

この fixture の各ページは数百バイト程度しか返さないため、ここで得られたオーバーヘッド比を大きなアセットを持つサイトにそのまま当てはめるべきではありません。その限られた条件の中で、私は最終サイズだけでなくアーカイブの構成も計測しました。

各種件数とバイト数の合計は公開されている capture-summary.json にあり、割合は総レコード内容 17,024 バイトを分母にしています。

この小さな本文の実行では、request レコードのほうが response 本体より多く、request と urn:pageinfo: のバイト数は response ペイロードの約 2.1倍でした。これはこの fixture のレコード構成を表したものであって、WARC 一般の比率ではありません。

ディスク上では、3回の独立した実行を通じて次のようになりました。

中央値からは、次の 4つの比率が導かれます。

そして WACZ の中身を見ると、次の通りです。

最後の行は少し意外でした。小規模クロールでは、アーカイブパッケージの 3分の1近くが Web そのものではなく、クロールの記録なのです。

計測は安定していました。response ペイロードは3回ともバイト単位で完全一致し（毎回 5,339 B）、WARC.gz と WACZ の変動は 0.4% 未満でした。

この比率は、画像やフォント、大きなスクリプト束を含む実サイトにはそのまま当てはまりません。ただ、構造的に重要な点は変わりません。request と page-info レコードは、ペイロードの大きさに関係なくオーバーヘッドを生みます。本番の保存容量を計画する前に、代表サンプルで測定してください。fixture の 10× をサイト全体の見積もりにそのまま掛けてはいけません。

セットアップと、見積もるべきディスク容量

Docker か Colima をインストールして起動したら、Browsertrix 固有のセットアップは docker pull webrecorder/browsertrix-crawler:latest、続いて docker run … crawl --url … --generateWACZ です。イメージに Chromium が含まれているので、別途ブラウザや Python 環境は不要でした。

この便利さの代償は、今回の計測では次の通りです。

コンテナこそが摩擦の本丸であり、ブラウザを同梱するコストはこのダウンロードと展開の行に表れます。私は --shm-size 1g で実行し、fixture はホスト側にありクロールはコンテナ内で動いていたため、--add-host=host.docker.internal:host-gateway と、loopback ではなく 0.0.0.0 にバインドした fixture が必要でした。公開インターネットをクロールするならこのネットワーク設定は不要ですが、自分のマシン上や社内ステージングでアーカイブするなら、半日は見ておいたほうがいいです。

出力ディレクトリは、いちばん過小評価されやすい行です。実際のクロールに当てはめると増加はもっと大きくなるので、ディスクが 3時に尽きてからではなく、開始前に容量を計画してください。

11ページだけのクロールで 28〜30 秒かかる理由には、ブラウザ起動がかなり効いているはずですが、今回は起動時間・遷移時間・パッケージング時間を分けていません。この実行からページ単位のスループット結論は出せません。

fixture の比率をそのまま使わずに容量を見積もる方法

コレクションのサイズを決める現実的な方法は、実測です。対象の実際の分布を代表するページを選びます。たとえば、軽いアプリシェル、画像の多いランディングページ、文書ダウンロード、長文記事、必要なら認証済みビューです。それぞれのカテゴリを、意図した behaviors とパッケージ設定でキャプチャします。response ペイロード、WARC、WACZ、インデックス、ログ、ブラウザプロファイルの残骸、実行中に残る一時領域も測ります。パッケージ化の途中で複数コピーを一時的に持つなら、最終バンドルだけでなくピーク時のディスク使用量も重要です。

固定要素と変動要素は分けて考えてください。3.51 GB のコンテナイメージは、1台のワーカーで多くのキャプチャに共有できるデプロイ上のオーバーヘッドです。request レコード、page-info レコード、インデックス、ページ一覧はクロール活動に応じて増えます。response 本文は対象に大きく依存し、ログは実行時間と詳細度に依存します。さらに保持や複製が最終コレクションをクロール挙動とは独立に増やします。これらをすべて「1ページあたりのバイト数」に押し込む容量モデルは壊れやすくなります。

圧縮と重複排除も、代表的な内容で確認が必要です。この fixture の response ペイロードは3回ともバイト単位で同一でしたが、それは広告、タイムスタンプ、個別化レスポンス、キャッシュ回避用 URL を含むページの挙動を示しません。繰り返しキャプチャがプログラムの一部なら、同じページを連続してキャプチャし、見た目が変わらないページが本当に重複排除されるかどうかを revisit レコードで確認してください。同様に、ログとインデックスが保存ペイロードと同じ複製レベルで保持されるかも検証しましょう。

運用面では、収集開始前に警告しきい値を設定してください。空き容量、コレクション単位の増加、パッケージ化失敗、ブラウザプロファイルや一時ディレクトリのサイズを監視します。チェックサム確認だけでなく、保存した WACZ からの復元テストも実施してください。上の比率が役立つのは、どんな構成要素が存在するかを示してくれるからです。どれくらい大きくなるかを教えてくれるのは、代表サンプルのほうです。

その前提条件は容量見積もりの横に書き残し、パイロットクロール後に見直してください。

スコープの規律を 2つの制御で確認する

範囲を逸脱するアーカイバーは、実運用上の大きなリスクです。法的問題と保存容量の請求書を同時に抱えることになりかねません。私のホームページには http://outofscope.test:<port>/page/out へのリンクがありました。これは同じ fixture を指す別ホスト名です。その Host header を持つヒットが記録されれば、実際のインターネット通信なしに範囲外取得が起きたことの証拠になります。

2行目があるからこそ、1行目に意味があります。any ではそのリンクに 2回到達したので、実際に到達可能でした。デフォルトの prefix scope で 0 だったのは、本当にスコープを守っていた結果であり、クローラーがリンクを見落としたわけではありません。他の設定では範囲外訪問が起きたという未解決レポート #788 もありますが、この fixture でデフォルト prefix scope の下では再現しませんでした。存在を知っておく価値はありますが、私が見たとは言うべきではありません。

堅牢性は、良い意味で特筆すべきことがないほど普通でした。HTTP 500 を返すルートと dead link の両方が要求され、クロールは正常終了し、有効な WARC と WACZ が生成されました。dead link は何かを壊すのではなく、重複排除された revisit レコードとして保存されました。

長所と短所

長所

• 実行時に DOM へ注入されたリンクと、ページが発行した fetch() を捕捉できる。どちらもアーカイブ内とサーバー側の両方で確認済みで、対象パスはソース中のリテラルとしては存在しない。
• 静的 HTML と深さ方向の巡回は完全。4/4 のリンク、3/3 の深さチェーンで、取りこぼしなし。
• Docker/Colima が動いていれば、docker run 1回で WARC と WACZ を生成できる。Chromium はイメージに含まれる。
• デフォルトの prefix スコープでは範囲外取得が 0 件。any は仕様通りに広がるので、設定どおりの挙動をする。
• 出力は独自形式ではなく、標準ベースのアーカイブ（WARC、CDX インデックスとページ一覧付きの WACZ）である。
• かなり決定論的なアーカイブ。3回の実行でペイロードはバイト単位で同一、ディスク上のサイズ変動は 0.4% 未満。
• 失敗時の挙動が素直。500 ルートや壊れたリンクでクロールが止まらない。

短所

• 実行されない JavaScript 内の URL リテラルは見つからない（0/2）。そのファイル自体はアーカイブされていてもそうです。設計上は正しいですが、エンドポイント探索が目的ならカバレッジの穴になります。
• フットプリントが重い。約 1 GB の pull、3.51 GB のディスク使用、しかも出力ディレクトリはすぐ増えます。
• 小さなページではバイトオーバーヘッドが大きい。request と pageinfo の合計が実際のペイロードを超え、WACZ の約 30% がクロールログでした。
• AGPL-3.0 なので、商用組み込みには本気のコンプライアンス作業が必要です。
• 構造化データ用のツールではありません。スキーマもフィールドマッピングも、最後にきれいな行データもありません。
• すべてのページが実ブラウザを通るため、ページ単位のスループットは設計上そこまで高くありません。

どんな人が使うべきで、どんな人は使うべきでないか

Browsertrix は、抽出済みの行ではなく、ブラウザが取得したリソースのアーカイブを必要とするチーム向けです。この fixture では、実行時に取得されたレスポンス本文が WARC に入り、WACZ にもパッケージされています。図書館、報道機関、研究者は有力な利用者ですが、本番導入では、描画リプレイ、認証、サービスワーカー、同意フロー、遅延挙動、ストリーミング資産、保持制御、証拠取り扱い要件を別途テストすべきです。

本当に欲しいのがデータなら、これはやめておきましょう。目的が「400ページの全商品と価格をスプレッドシートにしたい」なら、アーカイバーはかなり遠回りです。ギガバイト単位でアーカイブしたうえで、結局は WARC ファイルに対して抽出コードを書くことになります。アプリの API 面を把握したい場合も同様です。Class B の結果が示す通り、静的 JavaScript パーサーなら Browsertrix が触れないエンドポイントを見つけられます。そして Docker が嫌いだったり、3.5 GB のイメージが問題になる環境なら、このツールはあなた向けではありません。

認可と保持

スコープ制御は認可そのものではありません。クロール前に、許可されたホスト、保持期間、アーカイブアクセスを定義してください。とくに、永続化されたキャプチャに個人データが含まれる可能性がある場合は重要です。prefix/any のテストは設定変更でネットワーク到達範囲が変わることを示すだけで、特定のコレクションにとってどの到達が合法かまでは示しません。

関連レビュー：web scraping とアーカイブの法的論点.

必要な出力別の代替手段

選ぶ基準はアーティファクトです。Browsertrix の狙いは WARC/WACZ による保存です。Playwright のようなブラウザ自動化ライブラリは、プログラム可能なページ操作を提供しますが、キャプチャのパッケージ化は自分で行う必要があります。エンドポイント探索型クローラーは URL を列挙し、抽出ツールはテキストや構造化レコードを返します。これらは同じブラウザを使えても、解決する仕事は別です。

関連レビュー：Heritrix レビュー.

開示事項：Thunderbit は筆者のプロダクトであり、この Browsertrix fixture ではテストしていません。Thunderbit は管理型抽出カテゴリに属し、標準ベースのアーカイブではなく、ページテキストまたは構造化データを出力します。本レビューが支持するのは出力の境界だけであり、性能や機能の比較主張ではありません。

Webデータ抽出に Thunderbit を試す

結論

必要な成果物が WARC/WACZ のキャプチャであり、コンテナ化された Chromium の採用がデプロイ条件に合うなら、Browsertrix Crawler を使うべきです。この fixture では、同期的な runtime-DOM とページ発行の fetch についてアーカイブ記録とサーバーヒットが一致し、デフォルトの prefix scope は別ホストを除外し、失敗ルートがあっても有効なアーカイブ生成を妨げませんでした。

本番利用の前には、リプレイ、遅延挙動、認証済みセッション、サービスワーカー、代表ページでの容量構成、ライセンス義務を検証してください。テストした境界はもっと狭く、実行されないコード参照は、対象 URL に対する request も archive record も生成しませんでした。含まれているスクリプト自体は保存されていたにもかかわらず、です。

Webデータ抽出に Thunderbit を試す Get Started Free

FAQ

ここでの WARC と WACZ の違いは何ですか？ WARC には、取得した request、response、関連レコードが入ります。WACZ は WARC にインデックス、ページ一覧、メタデータ、ログをまとめて、配布やリプレイ用ツール向けにパッケージ化したものです。本レビューでは両方を確認しましたが、リプレイのレンダリング自体は行っていません。

容量はどう見積もればいいですか？ 代表的なページを測定し、ログとインデックスを含む WACZ 全体の構成をサンプルとして保持してください。この記事の比率は、非常に小さい response 本文を前提にしているため、実運用の URL 件数に掛け算する用途には向きません。

指定したサイトの外まで勝手に行きますか？ 私のテストでは、デフォルト設定では行きませんでした。--scopeType prefix では別ホストへのリンクは 0回しか取得されず、--scopeType any に切り替えると 2回取得されました。つまり、そのリンクは到達可能であり、デフォルトで 0 だったのは本当にスコープが守られていたからです。他の設定で範囲外訪問が起きたという上流の未解決報告はありますので、推測せず自分のスコープ設定を確認してください。

リプレイの忠実性を主張する前に何をテストすべきですか？ WACZ を意図したリプレイシステムで読み込み、レンダリングされたページ、インタラクション、必要なサブリソースをライブ版または参照キャプチャと比較してください。WARC に本文があることは必要条件ですが、それだけではレンダリング済みリプレイの正しさは証明できません。

Browsertrix はアーカイブ済みページを構造化行データに変えますか？ いいえ。出力はアーカイブパッケージであって、選択した項目の表ではありません。成果物が商品、価格、連絡先、その他のスキーマなら、キャプチャ後に抽出工程が必要です。あるいは、最初から構造化データを主な出力とする別ツールを使うべきです。