「DockerでFirecrawlを立ち上げ、ドメインのリストに向けて実行し、RAG用のmarkdownを取得する」というスキームは、最初の1000ページまでうまく機能します。その後、2つの請求が発生します。1つ目はアンチボットからのものです：一部のドメインがコンテンツの代わりに403を返し、知識ベースに穴が開きます。これは、アシスタントが「提供された資料には情報がありません」と答えるときにわかります。2つ目の請求はトラフィックに対するもので、クローラーは最終的にmarkdownに含まれないすべての画像やフォントを誠実に引き出します。
2026年の最も人気のある3つのLLMクローラー、Firecrawl、Crawl4AI、Crawleeにプロキシを接続する方法と、プロキシが必要な場所でのみ機能するように設定する方法を見ていきましょう。無駄に各ページでギガバイトを消費しないようにします。
このガイドは誰のためか
RAG用の文書コレクションを構築している場合、内部知識ベースを充実させている場合、再学習のためのデータパイプラインを構築している場合、または定期的に数百のドメインをダウンロードしている場合は、これがあなたのケースです。以下の3つのツールは、デフォルト設定でサーバーのIPを使用し、ページ全体を読み込みます。この2つのデフォルトは変更する必要があります。
問題の規模は人気の数字から明らかです：Firecrawlは公開時点でGitHubで約17万のスター（ライセンスはAGPL-3.0）、Crawl4AIは約7.9万、ApifyのCrawleeは約2.5万です。これはもはやニッチな実験ではなく、標準的なツールセットであり、アンチボットシステムはその挙動をあなたと同じくらいよく知っています。
請求1：コンテンツの代わりに403
コレクションを作成する際の主な誤りは、クローラーがクラッシュしなければ成功したと考えることです。FirecrawlとCrawl4AIは、ブロックされたページで例外を返すのではなく、アンチボットのスタブページ、ブラウザチェックのページ、またはアクセス拒否の短いテキストを返します。形式的にはこれは有効なmarkdownであり、ベクトルデータベースに問題なく格納され、ユーザーの最初のリクエストまでそこに存在します。
したがって、プロキシの設定を行う前に最初に行うべきことは、結果の品質をチェックすることです。最小限のオプションとしては、ある閾値よりも短い文書を除外すること（典型的なコンテンツページの場合、500〜800文字のテキストが妥当です）と、テキスト内の特有のマーカー—接続チェック、JavaScriptが有効であること、「アクセス拒否」の言及—を別個にキャッチすることです。これらの文書はデータベースに送られるのではなく、再訪問のキューに送られます—すでにプロキシを介して。
請求2：捨てているギガバイト
ここでは算数が役立ちます。2025年のHTTP ArchiveによるWeb Almanacのデータによると、中央値のホームページはデスクトップで約2.86MB、モバイルで約2.56MBの重さがあります。そのうち、ホームページの画像は約1059KB、内部ページでは911KB、JavaScriptはそれぞれ697KBと632KBです。つまり、画像は最も重いカテゴリであり、ページの重さの約3分の1を占めています。
さて、結果に対して何をしているかを思い出してください。あなたはページをmarkdownに変換し、埋め込み用にチャンクに切り分けます。画像はこのパイプラインには全く入らず—良くてもaltテキストの行だけが残ります。動画、フォント、分析スクリプト、広告ピクセルも同様です。
レジデンシャルプロキシを介してギガバイトあたりの料金を支払ってクローリングを行うと、次のパイプラインステップで捨てるデータの配信に対して実際に支払っていることになります。10万ページのコレクションでは、「すべてを引き出す」と「HTMLとテキストだけを引き出す」の違いはパーセンテージではなく、倍数で測定されます。正確な節約はサイトのテーマによって異なります：メディアやeコマースはドキュメントやブログよりも重いです。
ステップ1：すべてにプロキシを使うのではなくエスカレーションを行う
最も多くの節約をもたらす主要なアーキテクチャの手法は、すべてのトラフィックをプロキシを通さないことです。知識ベースを構築する際の大部分のドメインは、ドキュメント、ブログ、リファレンスサイト、政府ポータルであり、コンテンツを直接提供し、誰もブロックしません。プロキシは少数のドメインに必要です。
正しいスキームは多層エスカレーションです：最初は直接リクエストを行い、ブロックの兆候があれば次のレベルに移行します。これは自作の応急処置ではなく、両方の主要なフレームワークはその機能を標準で備えています。
Crawleeでは、これを実現するためにtieredProxyUrlsがあります。レベルは安価なものから高価なものまで列挙され、クローラーはブロックが発生した際に自動的に上に上がり、定期的に下のレベルに戻ろうとします：
const proxyConfiguration = new ProxyConfiguration({
tieredProxyUrls: [
[null],
['http://user:pass@datacenter-proxy:8080'],
['http://user:pass@residential-proxy:8000'],
]
});ドキュメントからの重要なニュアンス：tieredProxyUrlsはクローラーのインスタンスを介して使用する場合にのみ機能します。直接の呼び出しnewUrl()は予期しない結果をもたらします。
Crawl4AIでは、バージョン0.8.5で似たようなメカニズムが登場し、現在のブランチに存在します（公開時点での最新リリースは2026年7月15日のv0.9.2です）。これをプロキシエスカレーションと呼び、CrawlerRunConfig内で設定します：3層のブロック検出—アンチボットの既知のベンダー、一般的なブロック指標、ページの構造的完全性のチェック—に加え、プロキシのチェーンによる自動リトライが行われます。
from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig
config = CrawlerRunConfig(
proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
max_retries=2,
)ProxyConfig.DIRECTを最初の要素として注意してください—これは「最初にプロキシなしで試す」という意味です。
ステップ2：各ツールでのプロキシ接続
次に、設定の具体的な内容です。手順は同じです：最初にプロキシ、次に余分なトラフィックのカット、最後にチェックです。
- Firecrawl（セルフホスティング）。 プロキシは、Playwrightに渡される3つの環境変数で設定されます：
PROXY_SERVER、PROXY_USERNAME、PROXY_PASSWORD。これらは.envにapps/api用に記述され、開発者は静的アドレスの代わりに各リクエストでIPをローテーションするプロキシサービスを指定できると明記しています。 - Crawl4AI。 プロキシは
BrowserConfigにあり、proxy_configフィールドにはProxyConfigオブジェクトまたはserver、username、passwordフィールドを持つ辞書が含まれます。クローリングセッション全体に対して1つのブラウザ構成があり、各arun()呼び出しには個別のCrawlerRunConfigが渡されます。 - Crawlee。
ProxyConfigurationクラスにはproxyUrlsオプションがあり、ライブラリはアドレスのリストをラウンドロビンで循環します。リスト内のnullは「プロキシなし」を意味します。統合はスムーズです：HttpCrawler、CheerioCrawler、JSDOMCrawler、PlaywrightCrawler、PuppeteerCrawler。 - ポイントルール。 どのドメインがブロックされ、どれがされないかがわかっている場合、Crawleeには
newUrlFunctionがあります—リクエストのURLに基づいてプロキシを選択する独自のロジックです。ホワイトドメインにはnullを返し、その他にはプロキシのアドレスを返します。これは、ターゲットリストが安定している場合の最も安価なオプションです。 - チェック。 本番前に、設定されたクローラーを通じて外部IPを返すページを通し、プロキシのアドレスがサーバーではなく表示されることを確認してください。この3行が、1日のトラブルシューティングを節約します。
ステップ3：テキストにならないものはすべてカットする
プロキシが接続されたら、トラフィックの節約を開始します—さもなければ、ギガバイトの請求がコレクションが集まる前に来ることになります。
Firecrawlでは、これを制御するのはBLOCK_MEDIA変数です。公式の設定例には、プロキシの帯域を節約するためにメディアリクエストをブロックしたい場合は設定してくださいという文字通りのコメントがあります。これは、主要なコスト項目を取り除く最も迅速な方法です。
Crawl4AIでは、同様の制御がBrowserConfigにあり、text_modeは画像をオフにしてテキストクローリングを加速し、light_modeはブラウザの一部のバックグラウンド機能をオフにし、avoid_cssはCSSの読み込みをブロックします。これらは組み合わせ可能です。RAG用のコレクションを収集する場合、これはほぼ常に正しいセットです—レイアウトは必要なく、テキストが必要です。
Crawleeでは、ロジックが異なります：コンテンツがHTMLで提供される場合、ブラウザベースの代わりにCheerioCrawlerまたはHttpCrawlerを使用します。完全なレンダリングの代わりに通常のHTTPリクエストを使用することは、単なるトラフィックの節約ではなく、支出の順序が異なることを意味します。ブラウザクローラー（PlaywrightCrawler、PuppeteerCrawler）は、JavaScriptなしでは収集できないページのみに残しておきます。
落とし穴
セッション対ローテーション。 各リクエストでIPを変更することは、それ自体が疑わしく見え、多段階のシナリオ—ページネーション、同一ドメイン内の遷移—を壊します。Crawleeでは、各newUrl()呼び出しがプロキシをSessionオブジェクトに結びつけ、ブラウザのフィンガープリンティングやヘッダーと共にローテーションします。この結びつきを手動で切り離さないでください。
メディアはオフになっているが、コンテンツが消えた。 一部のサイトは遅延読み込みで画像だけでなくテキストも引き出します。text_modeまたはBLOCK_MEDIAを有効にした後は、必ず20〜30ページのサンプルを通し、テキストの量を基準と比較してください。
リトライに上限なし。 プロキシのレベルによるエスカレーションは、1つの頑固なページが3回ダウンロードされることを意味し、すべて3回分の料金が発生します。max_retriesを制限し、N回の失敗後にクローリングから除外されるドメインのリストを作成してください。
Robots.txtと法的枠組み。 2026年の学習とRAGのためのデータ収集は、数年前よりも厳しく規制されています—ソースの開示要求からテキストおよびデータマイニングの拒否メカニズムまで。あなたのパイプラインがこれらの信号を尊重していることを確認してください、100,000ページで動作する前に。
RAGパイプラインに適したプロキシの種類
答えは、あなたがどのエスカレーションレベルにいるかによります。
- ゼロレベル—プロキシなし。 ドキュメント、オープンソースプロジェクト、政府サイト、大多数の企業ブログ。ここではサーバーのIPが正常に機能し、支払う必要はありません。
- 中間レベル—データセンタープロキシ。 速くて安価で、単純なレート制限や地域制限に対抗できます。大規模なコレクションを収集する際には、作業馬として機能します：ボリュームが数百ギガバイトで測定されると、ギガバイトあたりの価格差が主要な要因になります。
- 上位レベル—レジデンシャルプロキシ。 深刻なアンチボット保護を持つドメイン用で、データセンターのサブネットは入口でフィルタリングされます。したがって、デフォルトレベルとして設定することはできません—ギガバイトあたりの料金が余分な画像をコストに変えます。
パイプラインを構築する前に、経済性を正直に計算することが重要です：ページの重さ、リトライ、隠れたコストを考慮した百万ページのパースの完全なコストを分析しました。そして、最初のコード行を書く前に尋ねるべき別の質問があります：クローリングは本当に必要ですか—公式API対既存データセットとパースの分析では、一部のソースに対して既存のデータが独自のクローラーよりも安価であることがわかります。
結論
LLMクローラーにおけるプロキシは、単なる「オン/オフ」スイッチではなく、三層のスキームです。デフォルトレベルとしての直接リクエスト、中間レベルのデータセンタープロキシ、レジデンシャルは、他に方法がないドメインのみに使用します。さらに、メディアを厳しくカットすることが重要です。なぜなら、テキストを収集しているからで、バイトに対して支払っているからです。
作業の順序はシンプルです：最初に結果の品質チェック（さもなければ、コレクションの半分がスタブページであることに気づきません）、次にフレームワークの手段を使ったプロキシのエスカレーション、最後にトラフィックの節約です。この順序で—コレクションは完全になり、請求も予測可能になります。
```