Heritrix レビュー：WARC の忠実性とアーカイブクローリングの運用コスト

Heritrix は Internet Archive のオープンソースのアーカイブ用クローラ です。Wayback Machine を支えるソフトウェアの系譜にあたり、20 年にわたって本番環境で使われてきました。その役割は、サイトが返した内容を忠実に WARC ファイルへ保存し、何年も後に再生できるようにすることです。内部は Java エンジンで、各クロールは XML で記述された Spring の bean グラフとして構成され、ジョブの全ライフサイクルは REST API 経由で進みます。これはスクレイパーではありません。セレクタ構文も、項目マッピングも、最後に並ぶ行データもありません。

私は 3.16.0 を制御されたローカル環境で検証し、実際に何を書き出したのかをレコード単位で数えました。まず目を引くのは網羅性です。20 個の取得 URI から 61 件の WARC レコードが生成され、各レスポンスには payload digest と capture IP が付き、各リクエストは対応するレスポンスへリンクされていました。しかも、これらを得るために設定を一つもいじる必要はありませんでした。一方で運用はかなり重い体験です。配布物は 41 MB、JAR は 114 個（lib/ には 142 ファイルがあり、残り 28 個は LICENSE と NOTICE の同梱テキスト）、さらに最初の取得前に約 750 行のジョブ設定が必要です。ただし今回の各クロールはすべて curl 経由でヘッドレス実行し、Web UI をクリックする場面は一切ありませんでした。

保存結果からは、あまり目立たない既定値も見えてきました。fixture の 2 つの URL はバイト単位で同一の内容を返しましたが、標準プロファイルは両方を完全な形で取得し、アーカイブしました。つまり response レコードは 2 件で revisit レコードは 0 件です。しかも両レスポンスには同じ payload digest が割り当てられていました。content-digest による重複排除は、履歴処理系を追加した後には機能しますが、標準プロファイルでは有効化されていません。しかも、これは帯域ではなく保存容量を節約する仕組みです。

Heritrix の正体

アーカイブとスクレイピングは別物です。このカテゴリの取り違えは、まずそこを整理する必要があります。Heritrix は行データを返してはくれません。CSV も出ません。出力されるのは HTTP のやり取りそのもので、ヘッダー、本文、捕捉メタデータが保存向けフォーマットに格納されます。そしてこれは、その分野全体における参照実装です。Heritrix に商品価格表を求めるのは、裁判速記者に要約を求めるようなものです。

2026 年 7 月 27 日時点の数字では、リポジトリのスター数は 3,285、未解決 issue は 36 件です。最新リリースは 3.16.0 で、公開日は 2026-07-03。私が検証したのはまさにそのビルドなので、ここで述べる内容は古い版に対する不満ではありません。ライセンスには一つ注意点があります。LICENSE ファイル自体は Apache-2.0 ですが、GitHub の判定では「Other」と表示されます。これは同梱の一部サードパーティファイルに独自の条件があるためです。Heritrix を商用製品に組み込むなら、サイドバーのバッジを眺めるだけで済ませず、法務の目で 5 分確認する価値があります。

もう一つ、構造上の重要点があります。Heritrix はブラウザを動かしません。HTTP で取得し、返ってきたバイト列からリンクを抽出します。現代のアーカイブ分野で近い存在である Browsertrix Crawler はその逆で、実際の Chromium を動かし、ブラウザが何をしたかを記録します。どちらも WARC を出力しますが、このレビューで測定したのは Heritrix の非ブラウザ経路のみです。どちらのシステムについても、規模やスループットの比較は行っていません。

チェーン、bean、SURT：クロールはどう組み立てられるのか

Heritrix のジョブは、内部的には Spring のアプリケーションコンテキストです。「Spring で設定されている」のではなく、XML で書かれた Spring bean グラフそのものであり、クロールの各部分は差し替え可能な bean です。

frontier は URI キューを保持し、ホストごとに分割します。この分割が、politeness の効き方を決めますし、後で重要になります。

processor chain は 3 段階で処理します。candidate chain（発見した URI をスケジュール対象にするか）、fetch chain（DNS、robots、HTTP fetch、リンク抽出）、disposition chain（WARC への書き込み、状態更新）です。Heritrix に機能を追加するとは、適切な chain の適切な位置へ processor bean を差し込むことを意味する場合が多く、私が dedup を有効化したのもまさにその方法でした。

scope は SURT 上で動く DecideRule のスタックです。SURT とは Sort-friendly URI Reordering Transform のことで、http://www.example.com/a を http://(com,example,www,)/a に変換し、ホスト名の接頭辞が階層順に並ぶようにします。既定の scope は seed の SURT プレフィックスから生成されます。ルールは順番に許可・拒否を判定し、最後に一致したものが勝ちます。

WARC writer は disposition chain にあり、politeness は frontier 側で 3 つの数値、delayFactor、minDelayMs、maxDelayMs として管理されます。robots の遵守は fetcher 側のポリシー文字列で制御されます。

そしてこれらすべてを REST API から操作できます。これが、想像以上に重要でした。

セットアップこそが、全体でいちばん重い部分

最初の取得前に配備するものは次のとおりです。

このジョブ設定の大半は、ほとんど触ることがありません。とはいえ省略はできず、クローラが何かを取得する前に必須の項目が 2 つあります。seed と metadata.operatorContactUrl です。標準値はプレースホルダーであり、実際にクロールを実行する担当者を示す有効な URL に差し替えない限り、クロールは始まりません。

この要件には、責任の所在を残す仕掛けがあります。運用者は、クローラが動く前に連絡先 URL を入れなければなりません。もちろん、それだけで本人性や許可の有無、適用法令への準拠を証明できるわけではありませんが、少なくとも連絡先情報を任意の慣行ではなくジョブの一部にします。

セットアップで本当に意外だった点が 2 つありました。

ドキュメントに書かれた最小要件より新しい JDK で動いたこと。 Getting Started ドキュメント では Java 17 以降を求めています。ですが Heritrix 3.16.0 は、--add-opens、--enable-preview、Security Manager の回避策なしで、OpenJDK 26.0.1 上で起動し、REST API を提供し、この fixture の全クロールを完了しました。これは macOS arm64 の一例であって互換性マトリクスではありませんが、この検証ビルドがこのホストで JDK 17 に縛られていなかったことは確認できました。

Web UI を一切触らずに済むこと。 ジョブの全ライフサイクルは REST で完結します。私は curl だけで、ジョブ作成、beans ファイルの PUT、build、launch、unpause、FINISHED になるまでのポーリング、terminate、teardown まで自動化しました。つまり「Heritrix はパイプラインで運用できるのか」という問いへの答えは明確に yes です。完全にヘッドレスで、ブラウザ操作は不要です。多くの解説は Jetty の UI をスクリーンショット付きで見せて、あたかもそれが必須画面であるかのように扱いますが、あれは便利機能であって必須ではありません。

ホスト固有の補足も一つあります。この Mac は Surge を使ってシステム全体の HTTP プロキシを設定しています。Heritrix の Java クライアントはそのプロキシ設定を引き継ぎ、127.0.0.1 の fixture 通信までプロキシ経由にしてしまったため、OS の例外リストや NO_PROXY があっても 503 応答が出ました。JVM を -Djava.net.useSystemProxies=false 付きで起動すると、結果は 2×503 から 18×200 に変わりました。これは Heritrix の欠陥ではなく環境の相互作用です。このフラグが意味を持つのは、システムプロキシ設定の継承が望ましくない場合に限られます。

実際にアーカイブへ入るもの

標準デフォルトプロファイルを、制御された fixture に対して実行しました。fixture は、HTML ページ、3 階層の深さを持つリンクチェーン、robots.txt と sitemap、意図的な 404 と 500 ルートを含む、既知のエンドポイント集合を持つローカルサーバーです。その後、要約行を信じるのではなく、生成された WARC をレコード単位で解析しました。

20 個の取得 URI から 61 件のレコードが生成されました。

URI あたり response / request / metadata が 1:1:1、しかも設定変更なしで成立していました。さらに、レコードごとの完全性も確認できました。

HTTP ステータスも、200 OK、404 Not Found、500 Internal Server Error を含め、文字通りそのまま保存されました。失敗として捨てられるのではなく、保存された response の実際のステータス行として残っています。

この点こそ、アーカイブとスクレイピングをはっきり分けます。スクレイパーにとって 500 は、再試行するか無視するエラーです。アーカイバにとっては「その瞬間にサーバーが何を返したか」という保存すべき事実です。Heritrix Output の wiki はこのレコード構造を説明していますが、私が見たかったのは、実測された多重度と、既知のエンドポイント集合に対する 20/20 のリンク成立でした。その通りに機能しました。

dedup の結果を、両方向から測る

私の fixture は /dup/one と /dup/two に、バイト単位で同一の本文を返しました。URL は違っても内容は同じ。まさに content-digest dedup がまとめるためのケースです。私は 2 回実行しました。1 回は標準プロファイル、もう 1 回は digest-history chain（BdbContentDigestHistory に加え、fetch chain に ContentDigestHistoryLoader、WARC writer の後に ContentDigestHistoryStorer を追加）を入れた後です。

標準状態では、両方の response に同じ digest が付きますが、それを処理する履歴系は動かず、両ペイロードがそのまま完全な形で保存されました。chain を追加すると、2 回目の捕捉は同一 payload digest を指す WARC revisit レコードになりました。これは WARC 1.1 仕様 が revisit のために定めている挙動です。

これは秘密の挙動ではありません。Duplication Reduction Processors の wiki ページには、skipIdenticalDigests の既定値が false であり、URL に依存しない dedup には loader と storer の bean が必要だと書かれています。これは隠れた仕様を暴いた話ではなく、ここで測ったほとんどすべてと同様に、文書化された Heritrix の挙動に一次データを付けただけです。問題は文書と、人々が「Heritrix は dedup する」とだけ思い込む認識との間にあります。設定条件の注記はしばしば無視されます。

ここで押さえておきたい帰結を 2 つ挙げます。

dedup は転送時ではなく書き込み時の処理です。 これは私が個別にメーターで測ったわけではなく、content digest の仕組みから直接導かれる性質です。digest を比較できるのはバイト列が到着した後なので、2 つ目の URL も結局はオリジンから取得されます。chain を有効化すると、転送量でも相手先の負荷でもなく、保存する内容が減ります。dedup を丁寧さや帯域節約の手段として見積もるのは逆です。

「dedup されるはず」という前提で立てた保存容量見積もりは、ひどく外れることがあります。 テンプレートの重複が多いサイト、たとえばミラーされた PDF、定型文だらけのランディングページ、同じ記事の印刷表示版をアーカイブするのに、同一本文が潰れていく前提でディスクを見積もると、標準プロファイルはその見積もりよりかなり多くの容量を消費するかもしれません。2 URL の fixture は既定動作を示しただけで、100 万 URI 規模での効果を示したわけではありません。その効果は、重複率、本文サイズ、再クロール設計に左右されます。

scope と robots は、約束どおりに動いた

クローラが「取得しなかったもの」について語る言葉はあまり信用できません。そこで両方とも、サーバー側のヒットカウンタで測定しました。つまり、Heritrix のログとは独立して、ターゲットサーバー自身にリクエスト数を数えさせました。

実際の遅延は minDelayMs の下限にぴったり乗ります。サブミリ秒のオリジンでは、delayFactor × fetch-time は構造上ほぼ無視でき、最小値が支配的になります。2 行の比率はあまり意味がありません。politeness ゼロ側の分母が数十ミリ秒しかなく、実行ごとの揺れも大きいからです。安定して言えるのは絶対下限です。この fixture では、標準 Heritrix は同一ホストへのリクエスト間で約 3 秒待ちました。その結果、20 ページのクロールが壁時計時間でほぼ 1 分になりました。

感覚的に理解するなら、こうです。ある大学図書館が、廃止前の 50,000 ページある政府サイトをアーカイブしなければならず、それが 1 ホストに集約されているとします。ホストあたり 3 秒の下限なら、強制待機だけで 150,000 秒、つまり約 42 時間、およそ 1 日と 3/4 です。これは私が測った 3,036 ms の下限からの計算です。50,000 × 3.036 秒 = 151,800 秒 = 42.2 時間。設定値の 3,000 ms を使っても 41.7 時間で、四捨五入すれば 41 ではなく 42 です。測定済みクロールではありませんが、プロジェクト計画に必要な算数です。

公平を期すと、Heritrix の politeness は ホスト単位 です。frontier がホストごとに queue を分けるからです。数千ドメインにまたがる広範なクロールなら、それぞれの queue に並列化され、この上限が全体にそのままかかるわけではありません。私の fixture は単一ホストで、今回の数字にとっては最悪条件でした。アーカイブ対象が巨大な 1 サイトなら、その最悪条件がそのままあなたの条件です。

そして、これは機能です。この遅延があるからこそ、アーカイブ用クローラはサイト所有者にブロックされるのでなく受け入れられる存在になります。これを短くするのは他人のサーバーに対する判断であり、このツールはそれを攻撃的な既定値ではなく明示的な決定にしています。

今回テストしなかったこと

ここでの測定は、制御された fixture に対するクロールの挙動だけを対象としています。それ以上ではありません。範囲外は次のとおりです。

• クロール間 dedup と再クロール。 測定したのは同一クロール内の content-digest dedup だけです。別々のクロールをまたいで URI 履歴 DB を保持する仕組み（FetchHistoryProcessor + PersistLog）は別機構であり、試していません。
• 大規模運用と長期安定性。 100 万 URI の frontier も、チェックポイントと復元も、数日運用もありません。fixture が測っているのは持久力ではなく規律です。
• JavaScript レンダリングの捕捉。 Heritrix の既定キャプチャは非ブラウザ方式で、私が測ったのもそれです。任意のブラウザベース動作は未検証です。
• 高レイテンシ起源での politeness。 ローカル遅延はサブミリ秒なので、構造上 minDelayMs が支配しました。delayFactor が遅い実サーバーに対してどう効くかは、このデータでは切り分けていません。
• サイトマップの再現率。 robots.txt は要求され、sitemap の指示も追跡されましたが、<loc> の全エントリを個別に検証したわけではありません。

本番の最初のジョブ前に明示しておくべきこと

標準プロファイルは長いですが、アーカイブの意味を変える判断はかなりコンパクトです。まず scope から始めましょう。seed は既定の SURT プレフィックスを生成し、DecideRule はそれを順番に広げたり狭めたりできます。代表的な scope 内 URL と scope 外 URL で最終的なルール順を確認し、そのうえでサーバー側のトラフィックや別の独立ログと照合してください。クロールレポートだけでは、除外したホストに一度も接続していないことを証明できません。

次に、robots ポリシーと運用者の本人性が、この収集において何を意味するかを決めます。今回の既定値は fixture の disallow ルールに従いましたが、robotsPolicyName を ignore に変えると blocked パスは取得されました。この切り替えは機械的には簡単ですが、組織的には非常に重要です。有効な operatorContactUrl と並べて、誰がなぜ承認したのかを記録してください。必須の URL はサイト所有者が運用者へ戻る連絡経路にはなりますが、許可の根拠までは与えません。

保存容量の計画にも、別途の明示判断が必要です。完全に同じ本文を revisit レコードにしたいなら、アーカイブのサイズ見積もり前に content-digest の履歴処理系を追加し、確認してください。今回の chain は取得後の表現を変えただけなので、オリジン側のトラフィックは両 URL 分を見込む必要があります。クロールをまたぐ dedup は別機構であり、この 2 URL・単一クロールの結果からは推測すべきではありません。既知の重複本文を使った小さな検証クロールは、デプロイした bean グラフが意図したレコード種別を出すか確認する安価な方法です。

最後に、politeness は最後の微調整ではなく、スケジューリング入力として扱ってください。今回のローカル単一ホスト fixture では、minDelayMs が総時間を支配しました。実案件では、設定したホストごとの下限を、対象ホスト数と収集期限に照らして計算し、代表的なレイテンシで試験してください。広域クロールと単一サイトクロールでは、ホスト分割された frontier にかかる負荷の形が違います。このレビューが測定したのは後者だけです。運用手順書には REST のライフサイクルも残してください。build、launch、unpause、poll、terminate、teardown は、それぞれ監視する価値のある別状態です。

長所と短所

長所

• 既定状態でもアーカイブの完全性が非常に高い。20/20 の response に payload digest、capture IP、完全な request↔response のリンクがあり、設定不要。
• エラー応答も事実として保存する。200、404、500 のステータス行がそのまま記録される。
• scope の厳密さをサーバー側カウンタで確認済み。scope 外の取得はゼロで、scope 内ホストは通常どおりクロールされた。
• robots の遵守が本当に fetch を止める。必要なアーカイブのために、意図的な ignore 逃げ道もある。
• REST だけで完全にヘッドレス運用できる。作成、build、launch、poll、teardown をすべて curl で実行可能で、UI クリックは不要。
• OpenJDK 26.0.1 上で JVM フラグなしにきれいに動いた。20 年物コードとしてはかなり現代的な Java 対応です。
• operatorContactUrl が必須なので、匿名では実行できない。
• クロールの各部分が差し替え可能な bean なので、dedup の有効化が fork ではなく 3 つの bean 追加で済む。

短所

• content-digest dedup は既定でオフで、同一ペイロードを完全に書き出す。保存計画では大きな落とし穴になりうる。
• 配備が重い。41 MB の配布物、114 個の JAR、Java エンジン + Jetty、約 750 行の Spring ジョブ設定が必要。
• 既定の politeness によりホストごと約 3 秒の下限がかかる。20 URI の単一ホストクロールは 57.7 秒かかった。
• 既定経路には JavaScript レンダリングがないため、クライアント側でしか生成されない内容は取れない。
• 設定項目が多く、専門知識が前提になる。初回クロールまで 5 分というわけにはいかない。
• 出力は構造化データではない。WARC から項目を取り出すのは別プロジェクトです。

どんな人向けか、どんな人は避けるべきか

Heritrix は、成果物そのものが アーカイブ である組織やチーム向けです。図書館、国立アーカイブ、法務・コンプライアンスの保存業務、ウェブを一次資料として集める研究グループ、5 年後にある URL が特定の日に何を返したかを証明したい人たちです。もしあなたの語彙にすでに「WARC」「replay」「provenance」が入っているなら、このツールはまさにあなたのエコシステムの中心にあるべきもので、その重さは相互運用性の対価です。

ホスト分割された frontier と長い web archiving の実績から見て、多数ドメインにまたがる広域クロールの候補としては十分に筋が通っています。ただしこれは構造と歴史に基づく評価であって、この fixture での規模実測ではありません。長期スループット、チェックポイント復旧、100 万 URI 級の挙動はここでは未検証です。

データが欲しいのであってアーカイブが欲しいのではないなら、使わない方がいいです。商品、リスト、連絡先の表が欲しいだけなら、Heritrix はページを実に丁寧に保存してくれますが、その後の解析パイプラインは別途自分で作ることになります。しかもそのために、Java エンジン、Spring 設定、3 秒の politeness floor を払うことになります。また、対象がクライアント描画の SPA なら、非ブラウザ fetcher は殻だけを取り、内容は取りません。その場合はブラウザベースのアーカイバが正しい道具です。さらに、今日中に最初の結果が必要なら、セットアップ曲線が本当にあるので避けるべきです。

代替案と、マネージド API の位置づけ

アーカイブ分野での直接の現代版は Browsertrix Crawler です。Chromium を操作し、ブラウザが実際に行ったことを記録するブラウザベースのアーカイバで、Heritrix の既定 HTTP 応答にはない JavaScript 生成コンテンツも捕捉できます。その代わり、ブラウザの配備と実行時のオーバーヘッドが増えます。このレビューでは比較ベンチマークを行っていないため、判断の出発点は捕捉要件です。ブラウザが生成する状態が必要ならブラウザ型アーカイバ、通常の HTTP リソースなら Heritrix が本来の経路です。

関連レビュー: Browsertrix Crawler review。

まったく別の問題、つまりアーカイブではなくページから構造化データを取り出したい場合は、Heritrix と抽出系ツールを同列のクローラとしてではなく、出力で比較してください。Heritrix は無料でセルフホスト型です。JVM を動かし、beans ファイルを管理し、ディスク容量を見積もり、politeness を調整します。保存が成果物であるとき、このモデルが適しています。

開示事項: Thunderbit は公開元の製品であり、この Heritrix fixture ではテストしていません。これはマネージド抽出カテゴリに属し、出力は保存用 WARC ファイルではなく、ページ内容または構造化レコードです。再生可能なキャプチャと provenance が必要ならアーカイバを選び、成果物が行データや文書テキストで、マネージド運用が許容できるなら抽出サービスを検討してください。

アーカイブには固有の許可の問題があり、スクレイピングのそれとは同じではありません。Heritrix は既定で robots.txt に従い、バイトを取得する前に自身の識別を求めます。これは良い基準です。ただし、robots に従ったクロールが自動的に許可済みになるわけではありません。著作権、利用規約、個人データ、そして自組織のミッションがその上に乗ります。ignore ポリシーは、法的根拠を持つ組織のために存在するのであって、便利な切り替えではありません。アーカイブプログラムを立ち上げるなら、ディスクが埋まる前に許諾範囲を整理してください。もしこの分野が初めてなら、web scraping と archiving の法的論点 も読んでおくとよいでしょう。

Web データ抽出に Thunderbit を試す

結論

Heritrix を使うべきでしょうか？ もし成果物がアーカイブで、Spring bean を学ぶ気のある人がいるなら、答えは yes です。

今回の fixture は、明確な判断材料を示しました。標準プロファイルは response、request、capture metadata を一貫して保存し、scope と robots の制御は設定どおりにサーバー側の取得へ反映され、ジョブ全体のライフサイクルは REST で実行できました。これらは、今回のような小規模な単一ホスト条件では、アーカイブパイプラインにとって有用な特性です。

運用コストも同様に明確です。Java 配布物と大きな Spring 設定、ローカルクロールを支配したホストごとの遅延設定、そして追加の履歴処理系が必要な content-digest dedup。WARC の忠実性を必要とするチームなら、そのコストを受け入れる価値があります。抽出された項目が必要なチームは、別カテゴリから始めるべきです。

本番クロールの前には、実際のジョブ設定に対して dedup chain、politeness 設定、scope、robots ポリシー、運用者の本人性、保存容量の前提を確認してください。標準プロファイルは出発点であり、これらの運用判断を暗示するものではありません。

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

FAQ

operatorContactUrl があればクロールは許可済みになりますか？ いいえ。ジョブに連絡先 URL を含めることを強制するだけで、サイト運営者に対する責任の窓口はできますが、許可、本人性の正確さ、著作権上の扱い、規制遵守までは確立しません。それらはクローラ外のデプロイ判断です。

content-digest deduplication はオリジンへのリクエスト数を減らしますか？ 今回検証した設定では減りません。2 つの URL は、payload digest を比較できるようになる前に両方とも取得されました。履歴チェーンが変えたのは、2 回目の payload を WARC 上でどう表現するかだけで、2 本目の URL をネットワークリクエストとして省くことではありません。

Heritrix は Web UI なしで動きますか？ はい。今回のライフサイクル、つまり作成、設定アップロード、build、launch、unpause、poll、terminate、teardown は、すべて curl を使った REST API 経由で実行しました。埋め込み Jetty の UI は必要ありませんでした。

標準の Heritrix プロファイルは同一ペイロードを重複排除しますか？ 今回の fixture では、設定どおりにはしませんでした。標準プロファイルは、同一の 2 つの response をどちらも完全な response レコードとして保存しました。content-digest の履歴チェーンを追加すると 2 回目の捕捉が revisit レコードに変わります。つまり deduplication は自動既定ではなく、構成して検証すべきパイプライン選択です。

politeness の遅延はどう選べばいいですか？ ここでのローカルタイミングは、仕組みの確認として扱い、本番向け推奨としては扱わないでください。対象サイトのルール、運用者との合意、サーバー容量、クロールの目的、自分の再試行・並列制御ポリシーを踏まえて遅延を決め、そのうえでログで実際の同一ホスト間隔を確認してください。