Webサイトリッパーツール：完全ガイド

私たちの立場を明確にしておきます：私たちは Geonode であり、プロキシを販売していますが、この用途でプロキシが必要になることはほぼありません。ミラーリングの許可を得ているサイトをミラーリングするのは、単一のソースから行われる中程度のトラフィック量の仕事であり、ご自身の接続環境から問題なく実行できます。 もしこのためにプロキシの利用を検討しているなら、それは通常、サイト側が問題視する速度でミラーリングを行っていることを意味しており、正しい対処法は配信を分散させることではなく、速度を落とすことです。唯一の正当な例外として、地域限定コンテンツのミラーリングがありますが、これについては後述します。この記事で説明しているその他のすべての手順は、インフラを一切必要とせず、ノートパソコン1台で実行可能です。

これらのツールの実際の機能

このカテゴリのすべてのツールで共通する4つのステップ。

ページを取得する。 HTMLをダウンロードします。 アセットを見つける。 画像、スタイルシート、スクリプト、フォントを解析し、それらも追跡します。 リンクをたどる。 定義した範囲内で、さらに多くのページを発見します。 参照先を書き換える。 絶対URLを相対パスに変更し、ファイルシステム上でコピーが動作するようにします。

この4番目のステップこそが、リッパーとクローラーを区別する点です。クローラーはデータを収集するのに対し、リッパーは閲覧可能なローカルコピーを生成します。その違いは、リンクの書き換えにあります。

正当な用途は特に目新しいものではありません。サイトがオフラインになる前のアーカイブ、出張やアクセス制限のあるネットワーク用にドキュメントをオフラインで利用できるようにすること、プラットフォーム間の移行、コンプライアンス記録の保持、ホストが閉鎖された際の自身の作品の保存などです。

wget：定番の選択肢

すでにほとんどのUnixシステムに搭載されており、多くの作業に十分対応できます。

wget --mirror --convert-links --adjust-extension --page-requisites \
     --no-parent --wait=1 --random-wait \
     https://example.com/docs/

各オプションにはそれぞれ存在意義があり、wgetのマニュアルにはそれらが詳しく説明されています。

**--mirror

** 「ミラーリングに適したオプションを有効にします。このオプションは再帰とタイムスタンプを有効にし、再帰の深さを無制限に設定し、FTPディレクトリ一覧を保持します。現在は -r -N -l inf --no-remove-listing

と同等です。」

**--page-requisites

** 「指定されたHTMLページを正しく表示するために必要なすべてのファイルをWgetがダウンロードするようにします。これには、インライン画像、音声、参照されているスタイルシートなどが含まれます。」これを指定しないと、スタイルや画像のないHTMLが取得されます。

**--convert-links

** は、「ダウンロード完了後... ローカルでの閲覧に適した形にするため」に参照先を書き換えます。これは「目に見えるハイパーリンクだけでなく、外部コンテンツへのリンクを含むドキュメントのあらゆる部分」に影響します。

**--adjust-extension

** は、HTML拡張子なしでHTMLとして配信されるページに「.html

」を付加します。マニュアルでは、「.aspページを使用するリモートサイトをミラーリングするが、ミラーされたページを標準のApacheサーバー上で閲覧可能にしたい」という例が挙げられています。

**--no-parent

** は、「特定の階層以下のファイルのみがダウンロードされる」ことを保証します。これにより、サイト全体ではなく /docs/

に作業範囲が限定されます。

**--wait=1

** は「礼儀フラグ」であり、マニュアルでは次のように明示的に推奨されています。「このオプションの使用は推奨されます。リクエストの頻度を減らすことで、サーバーの負荷を軽減できるためです。」とあります。これを --random-wait

と組み合わせて使用してください。マニュアルには、このオプションについて「1人のユーザーの行動を理由に、無関係な多くのユーザーをウェブサイトから締め出すという、この不適切な推奨事項に触発された」と記されています。

さらに知っておく価値のあるオプションが2つあります。-Q

はダウンロードのクォータを設定し、制限のないミラーリングによってディスク容量が埋まってしまうのを防ぎます。また、-l

は、infinite では範囲が広すぎる場合に再帰の深さを設定します。

wgetには確かに制限があります。JavaScriptは実行できず、リンクの書き換え機能は優れていますが、複雑なサイトでは完璧とは言えず、グラフィカルインターフェースもありません。しかし、ドキュメントサイトや静的なブログであれば、こうした点は問題になりません。

HTTrack：グラフィカルな定番ツール

HTTrack は、この分野で最もよく知られている専用ツールであり、オープンソースでクロスプラットフォームに対応し、グラフィカルインターフェースとコマンドラインの両方を備えています。このプロジェクトは現在も活発に開発が続いています。

wgetより優れている点：ターミナルに馴染みのないユーザー向けの本格的なインターフェース、複雑なリンク構造への優れた対応、プロジェクトの再開機能、変更された部分のみを再ミラーリングする更新モード。

劣る点：wgetと同じ根本的な制限（JavaScriptの実行不可）に加え、習得に多少の時間を要するフィルタリング構文、そしてサイト運営者の間で「ユーザーエージェントによってブロックされる」という評判があること。

静的サイトの閲覧可能なコピーが必要な技術に詳しくないユーザーには、こちらをお勧めします。シェル操作に慣れているユーザーであれば、wget を使えば予期せぬ事態が少なく、同じ作業をこなせます。

シングルページツール

これはまた別の種類の解決策ですが、多くの場合、最適な選択肢となります。

サイト全体ではなく、1ページだけを完成させたい場合、すべての内容を単一の独立したHTMLファイルに埋め込むツールは、ミラーサイトよりも有用です。 これらは画像をデータURIとして埋め込み、CSSをインライン化し、依存関係なしでメール送信やアーカイブ、どこでも開くことができる単一のファイルを生成します。

この種のブラウザ拡張機能は、多くの人にとって実用的な選択肢であり、ここで紹介するあらゆるコマンドラインツールに対して決定的な利点が1つあります。それは、JavaScriptの実行後にレンダリングされた状態のページをキャプチャできることです。 現代のアプリケーションにおいて、これは「正常に動作するコピー」と「空っぽの殻」との違いに他なりません。

その代償として、操作は手動で行わなければなりません。つまり、人間がクリックして、1ページずつ処理する必要があります。ページ数が数ページ程度なら問題ありませんが、1,000ページにもなると現実的ではありません。

ArchiveBox と保存ツール

ArchiveBox は、オフラインでの閲覧ではなく保存を目的とする場合に注目すべき選択肢です。URLを入力するだけで、HTML、スクリーンショット、PDF、抽出されたテキスト、WARCファイルといった複数のアーカイブ形式を一度に生成します。

WARCは、ウェブアーカイブで実際に使用されている形式であるため、知っておく価値があります。この形式は、ファイルシステムの近似値ではなく、HTTPトランザクションそのものを保存するため、ヘッダー、ステータスコード、そして正確なバイトデータが保持されます。正確性が求められる分野（法務、コンプライアンス、研究など）においては、書き換えられたHTMLのディレクトリよりも、はるかに優れた記録となります。

ArchiveBoxはセルフホスト型で、インデックスを管理し、ヘッドレスブラウザを駆動してJavaScriptを処理します。wgetよりもリソースを消費しますが、より耐久性の高いアーカイブを生成します。

なぜ皆、現代的なサイトには苦戦するのか

このカテゴリーにおける失望のほとんどを説明する唯一の理由。

JavaScriptによるレンダリング。 wgetやHTTrackはHTMLを取得して解析します。一方、シングルページアプリケーションは、ほぼ空のドキュメントとスクリプトバンドルを返すだけで、コンテンツはブラウザ内で組み立てられます。ミラーリングされるのは、あくまで「殻」に過ぎないのです。

API駆動型のコンテンツ。 初期のHTMLにコンテンツが含まれていても、その後のナビゲーションでAPIからJSONが取得される場合があります。これらのリクエストはマークアップ内のリンクではなくコードによって行われるため、リンクを追跡するミラーリングツールでは決してそれらを発見できません。

無限スクロールと遅延読み込み。 操作によって表示されるコンテンツは、マークアップには一切含まれていません。

クライアントサイドルーティング。 サーバーに到達することのないURL。ミラーリングでは、リクエストされたことのないコンテンツを取得することはできません。

認証とパーソナライゼーション。 ログインが必要なコンテンツや、ユーザーごとに異なるコンテンツ。

回避策を、手間のかかる順に挙げます：

静的エクスポートの有無を確認する。 ドキュメントサイトでは、PDFやダウンロード可能なバンドルが提供されていることがよくあります。構築する前に確認しましょう。

APIの有無を確認する。 コンテンツがAPIから提供されている場合、フロントエンドをミラーリングするよりも、APIから直接取得する方が簡単で、より完全なデータが得られます。

本当にレンダリングが必要なページには、ブラウザベースのツールを使用する。 Playwright を使えば、ナビゲーションやコンテンツの読み込み待機を行い、レンダリングされた HTML を保存できます。これは、スクリプトの作成とかなり多くの帯域幅を要するものの、JavaScript に対応したミラーとなります。

部分的なミラーで妥協する。 多くの場合、サイトの静的な部分こそが本来求めていたものです。

Playwright を使った JavaScript サイトのミラーリング

従来のツールでは空のシェルしか返ってこない場合の実用的な代替手段です。汎用的なリッパーではありませんが、定義された一連のページをレンダリングされたままの状態で取得するには十分です。

import { chromium } from 'playwright';
import { writeFile, mkdir } from 'fs/promises';
import { dirname } from 'path';

const urls = [/* the pages you want */];

const browser = await chromium.launch();
const ctx = await browser.newContext();
const page = await ctx.newPage();

for (const url of urls) {
  await page.goto(url, { waitUntil: 'domcontentloaded' });
  await page.waitForSelector('main', { timeout: 15000 }).catch(() => {});

  const html = await page.content();          // rendered DOM, not source
  const path = 'mirror' + new URL(url).pathname.replace(/\/$/, '/index') + '.html';
  await mkdir(dirname(path), { recursive: true });
  await writeFile(path, html);

  await page.waitForTimeout(1000 + Math.random() * 1000);
}

await browser.close();

ここで重要な点が 4 つあります。

** ``page.content()`

` はソースHTMLではなく、レンダリング済みのDOMを返します**。これが、wgetではうまくいかない場面でこのアプローチが機能する唯一の理由です。つまり、JavaScriptによって構築された後の状態のままのマークアップを取得できるのです。

ネットワークのアイドル状態ではなく、セレクタを待機する。 アナリティクスビーコンやWebSocketを含むページは決してアイドル状態にならないため、waitUntil: 'networkidle'

を使用すると、多くの最新サイトでは単にタイムアウトしてしまいます。確実に存在すると分かっている要素を待機する方が、高速かつ信頼性が高いのです。

ページ間の意図的な一時停止。 wgetの--wait

オプションと同様の配慮であり、同様に不可欠です。

リンクの書き換えなし。 これが率直な制限です：絶対パスで参照されたレンダリング済みHTMLが取得されるため、正しく表示するにはインターネット接続が必要です。 書き換えを追加すると、各ドキュメントを解析し、すべてのアセットをダウンロードして参照先を書き換える必要が生じます。これは wget を再実装することになり、その段階では両者を組み合わせる方が簡単です。Playwright を使ってレンダリングして保存し、保存されたファイルに対して wget を実行してアセットを収集します。

また、帯域幅のコストも想定しておく必要があります。 ブラウザはすべての画像、フォント、スクリプト、動画をプリロードして取得するため、同じページの wget ミラーよりもトラフィックがおよそ 1 桁ほど多くなります。page.route()

を使用してフォントやメディアのリクエストをブロックすれば、保存対象に含まれていないものについてはトラフィックを大幅に削減できます。

ツールの選び方

最後の行は、人々が最も頻繁に手間のかかる方法で解決してしまうケースであるため、特に言及する価値があります。 サイトの所有者であれば、プラットフォームのエクスポート機能を利用してください。 データベースのダンプ、静的サイトのビルド、あるいはホスティングプロバイダのバックアップは、完全であり、ミラーリングでは把握できない部分も含まれており、数分で完了します。自分のサイトをミラーリングするのは、簡単な作業をわざわざ難しくしているようなものです。

どのような場合でも適用されるルール

使用するツールに関係なく。

robots.txt はあなたにも適用されます。 wget はデフォルトでこれを順守します。HTTrack もデフォルトでこれを順守します。どちらのツールも順守しないように設定することは可能ですが、そうすることは意図的な選択であり、その結果として何らかの影響が生じます。 これは現在、標準規格となっています — RFC 9309 — その読み方については、robots.txt ファイルの読み方で解説しました。

レート制限は必須です。 --wait を指定しないミラーサイトは、接続が許す限り高速にリクエストを送信しますが、これはサーバー側から見れば攻撃と見なされます。1秒に1リクエストが妥当な下限です。

著作権は消滅しません。 個人的なオフライン閲覧のためにコピーをダウンロードするのは別問題ですが、それを再公開するのはまた別の話です。コンテンツの所有権は引き続き権利者に帰属します。

利用規約によって、技術的な実現可能性にかかわらず、それが完全に禁止されている場合もあります。

帯域幅にはサイト運営者にとってコストがかかります。 大規模なサイトのミラーサイトでは、数ギガバイトものデータ転送が発生する可能性があり、その費用は誰かが負担することになります。

依頼してみてください。 重要な内容については、回避策を講じるよりもメールで問い合わせたほうが早いです。サイト運営者はしばしば承諾してくれますし、場合によっては、手間を省けるようなパッケージを提案してくれることもあります。

プロキシの活用場面について（概要）

これは当社の製品であるため、率直に言えば答えは簡潔です。

プロキシは必要ありません。許可を得ており、1つの場所から適切な速度でサイトをミラーリングする場合です。これは正当な利用の圧倒的多数を占めており、単一の接続で対応可能です。

プロキシが必要になる場合は、サイトが地域ごとに異なるコンテンツを提供しており、その地域版を取得したい場合です。例えば、ローカライズされたページを持つドキュメントサイトや、国ごとの在庫情報を掲載したカタログなどです。ここでは地理的な要素が重要であり、これは正当なユースケースです。

速度を上げるためにそれらが必要になることはありません。その理由でそれらに頼るということは、サイト側が異議を唱えるような速度でミラーリングを行っていることを意味します。それに対する正しい対応は、--wait であり、分散化ではありません。

地域別のケースが該当する場合、データセンターの帯域幅が賢明な選択となります（当社の料金は1GBあたり0.14ドルからで、2026年9月時点の価格ページで確認済みです）。また、完全なミラーリングはギガバイト単位で計測されるため、計算が重要になる点にご注意ください。

よくある質問

ウェブサイトリッパーとは何ですか？

ウェブサイトのページやリソースをローカルストレージにダウンロードし、リンクを書き換えてオフラインでも閲覧できるようにするツールです。このリンクの書き換え機能こそが、閲覧可能なミラーサイトを作成するのではなく、単にデータを収集するだけのクローラーとの違いです。

ウェブサイト全体をダウンロードするにはどうすればよいですか？

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent --wait=1 URL を使えば、ほとんどの静的サイトに対応できます。グラフィカルな代替ツールとしては、HTTrackが同様の機能を提供します。JavaScriptを多用するサイトの場合、これらはいずれもうまく機能しないため、ブラウザベースのアプローチが必要になります。

ダウンロードしたウェブサイトが正しく表示されないのはなぜですか？

通常は、--page-requisites が欠落しているため、スタイルシートや画像が取得されていないか、--convert-links が欠落しているため、参照先がまだライブサイトを指しているからです。スタイルが適用されていないのではなく、ページが空白になっている場合は、そのサイトが JavaScript を使用してコンテンツをレンダリングしており、レンダリング機能のないツールではそれを取得できないためです。

ウェブサイトのダウンロードは合法ですか？

個人的なオフライン利用のためのダウンロードは、一般的に問題ありません。ただし、再公開については、著作権が依然として適用されるため、別の問題となります。利用規約によっては、技術的な手段にかかわらず、自動ダウンロードが全面的に禁止されている場合があります。これは法域によって異なり、法的助言ではありません。

JavaScript を使用しているウェブサイトをダウンロードできますか？

wget や HTTrack ではできません。これらはスクリプトを実行せずに HTML を取得・解析するからです。ブラウザベースのアプローチが必要です。個々のページ用の単一ファイル拡張機能、またはページを移動し、コンテンツを待ち、レンダリングされた結果を保存する Playwright スクリプトなどです。

おすすめの無料ウェブサイトダウンローダーは？

コマンドラインに慣れているなら wget がおすすめです。すでにインストールされており、静的サイトには十分な機能を備えています。グラフィカルインターフェースが必要な場合は HTTrack が良いでしょう。閲覧ではなく保存が目的なら、HTML とともに WARC ファイルを生成する ArchiveBox が適しています。

ブロックされずにウェブサイトをダウンロードするにはどうすればよいですか？

リクエスト間の遅延を少なくとも1秒に設定し、robots.txtを遵守し、自身を正直に識別し、--no-parentや深度制限で範囲を限定してください。このカテゴリでのブロックの多くは、フルスピードでのミラーリングに起因しており、サーバー側から見ると攻撃と区別がつかないためです。

ウェブサイトのダウンロードにプロキシを使うべきですか？

地域限定のコンテンツが必要な場合のみです。適切な速度で通常のミラーリングを行う場合、1つの接続で十分です。速度を上げるためにプロキシに頼るということは、サイト側が許容しない速度で転送していることを意味します。その解決策は、遅延フラグを設定することです。

まとめ

静的サイトの場合、この問題はすでに解決済みであり、必要なツールはすでに手元にあります。5つのオプションを指定したwgetコマンド1つで、ブラウザで閲覧可能なローカルコピーを作成できます。ただ、人々が忘れがちなオプションが1つだけあります。それは、ダウンロードを「礼儀正しく」行うためのオプションです。

一方、現代のアプリケーションの場合、従来のツールはどれも機能しません。その理由は、設定で回避できるような欠点ではありません。これらのツールはHTMLを取得して解析しますが、コンテンツは取得後にJavaScriptによって組み立てられるからです。 現実的な選択肢としては、重要なページについてはブラウザベースのキャプチャ、APIが存在する場合はその利用、あるいはサイト所有者であればエクスポート機能の利用が挙げられます。ただし、最後の方法は、多くの場合、苦労して解決しなければならないケースです。

どのような手段を用いるにせよ、ツールに関係なく3つの原則が適用されます。レート制限を設けること。フルスピードでのミラーリングは攻撃と見分けがつかないからです。robots.txtを尊重すること。これは標準であり、これを無視するのは意図的な選択だからです。そして、重要なデータについては、必ず許可を求めること。メールを送るのに1分もかかりませんが、そのおかげで、作業全体が不要になるようなデータ一式が提供されることはよくあります。