1. 意思決定の背景と実務上の重要課題
大規模言語モデル（LLM）や検索拡張生成（RAG）パイプラインの構築において、最大のボトルネックは「外部Webデータの収集・クレンジング精度」にシフトしている。従来のスクレイピング技術（Requests + BeautifulSoup、Scrapyなど）は、現代のReact、Next.js、Vueなどで構築されたクライアントサイドレンダリング（CSR/SPA）のWebサイトに対して無力である。HTMLを取得しても中身は空の<div id="root"></div>であり、ブラウザエンジンによるJavaScript実行が不可欠となっているためだ。
さらに、LLMのインプットとしてWebページを利用する場合、従来の生HTMLをそのままコンテキストに投入すると以下の致命的な問題が発生する。
- トークン消費の爆発：HTMLタグ、インラインCSS、JavaScriptコード、追跡用トラッカー情報が全トークンの70%〜90%を占有し、モデルの推論コストを跳ね上げる。
- ハルシネーションの誘発：ヘッダーのナビゲーションメニュー、フッターの著作権表示、サイドバーの広告枠が文脈に混入し、プロンプトの指示精度を著しく劣化させる。
- WAF・Bot検知の壁：Cloudflare Turnstile、DataDome、Akamaiなどの最新ボット対策がヘッドレスブラウザのシグネチャを検知し、HTTP 403 ForbiddenやCAPTCHA画面を返送してデータパイプラインを停止させる。
これらを解決するアプローチとして、現在市場では以下の3つの選択肢が激突している。
- Firecrawl（SaaS / マネージド）：URLをPOSTするだけで、内部のブラウザプール、アンチボット回避機構、HTMLクレンジングエンジンを通過させ、整形済みMarkdownを一発で返却するプロプライエタリAPI。
- Crawl4AI（オープンソース・セルフホスト）：Python/PlaywrightをベースにLLMフレンドリーなMarkdown抽出、非同期並行処理、CSSセレクタ・正規表現・ヒューリスティックによるコンテンツ抽出を高速実行するOSSフレームワーク。
- Playwrightスクラッチ開発（内製パイプライン）：Microsoft Playwrightを直接制御し、TrafilaturaやReadability.js、外部プロキシプール（Bright Data等）を自社エンジニアが独自に統合・運用する完全内製構成。
本稿では、これら3手法の「動的SPA解析成功率」「インフラ維持・API従量コスト」「保守人件費を含めた3年間のTCO（総保有コスト）」を客観的数値で比較し、企業が選択すべき最適解の損得分岐点を提示する。
2. 【条件別】損得分岐マトリクス（早見表）
企業の月間スクレイピング量、ターゲットサイトのアンチボット強度、社内インフラの制約に基づいて導き出される推奨アプローチの早見表である。
| 判定条件 | ターゲット特性 | 推奨アプローチ | 月額想定コスト | 決定的な選定理由 |
|---|---|---|---|---|
| 月間ページ数：5万ページ未満 開発リソース：極小（1人未満） | Cloudflare等のWAF導入サイトが主 SPA・無限スクロール多用 | Firecrawl（SaaS） | $16〜$99 （約2,400〜15,000円） | ヘッドレスブラウザ管理、プロキシローテーション、WAFバイパス保守をすべて外注化し、即日RAGパイプラインを本番稼働できるため。 |
| 月間ページ数：10万〜500万ページ 開発リソース：Pythonエンジニア常駐 | 社内イントラ、規約上外部SaaS送信不可 中〜軽度のBot対策サイト | Crawl4AI（OSS自社基盤） | $150〜$800 （コンピュート＋住宅用プロキシ） | SaaS従量課金の指数関数的増大を回避。非同期アーキテクチャによりc6i.xlarge等の安価なEC2インスタンス上で超高速に大量Markdown化が可能。 |
| 月間ページ数：1,000万ページ以上 データ抽出：超複雑な業務ロジック | 2要素認証後の画面、Canvas描画、 独自プロトコル通信 | Playwrightスクラッチ自作 | $2,000〜 （インフラ＋保守専任工数） | 既成ツールのラッパーでは対応できないDOM操作、セッション保持、独自ブラウザパッチ適用の自由度を最優先する場合の唯一の解。 |
| 機密性：最重要（医療・金融） 外部クラウドへのHTML送信厳禁 | 個人情報、未公開財務データを含む クローズドWeb環境 | Crawl4AI（ローカルDocker） | $50〜$300 （社内オンプレ/プライベートVPC） | データが外部APIプロバイダのログに残るリスクをゼロにしつつ、Readabilityを超えるLLM用構造化抽出パイプラインを完全内製化。 |
3. 【徹底対比】主要選択肢の構造・スペック・料金比較
各手法の技術スタック、アーキテクチャ特性、公式料金規約に基づく詳細なスペック比較を行う。
| 比較項目 | Firecrawl（SaaS） | Crawl4AI（OSS） | Playwrightスクラッチ自作 |
|---|---|---|---|
| 提供形態 | マネージドAPI / セルフホストOSS | Pythonライブラリ / Dockerコンテナ | 自社コード資産（Node.js / Python） |
| 中核エンジン | ヘッドレスChromiumクラスタ（独自改造） | Playwright（AsyncIOベース） | Playwright / Puppeteer |
| SPAレンダリング能力 | 極めて高い（ネットワークアイドル自動検知） | 高い（js_code実行、待機条件指定可） | 無制限（コード次第で完全制御可能） |
| WAF/Bot対策回避 | 自動（住宅用プロキシ内蔵・フィンガープリント偽装） | 準標準（ユーザーエージェント偽装、プロキシ自前設定要） | 完全自前（Stealth plugin、プロキシ、CAPTCHA解除連携） |
| Markdownクレンジング | 独自アルゴリズム（メインコンテンツ完全特化） | ヒューリスティック＋Pruning＋LLM抽出 | Trafilatura / Readability等の外部ライブラリ依存 |
| 並行処理性能 | APIエンドポイントのレートリミット依存 | 非同期（async/await）により単一ノードで極めて高い | ワーカー設計依存（Celery / BullMQ等） |
| 公式基本料金体系 | ・Free: $0 (500 credits) ・Hobby: $16/月 (3,000 credits) ・Standard: $99/月 (100,000 credits) ・Growth: $399/月 (500,000 credits) ※超過: $0.0009〜/credit | オープンソース（Apache 2.0相当） ソフトウェアライセンス費用：$0 | オープンソース（Apache 2.0） ソフトウェアライセンス費用：$0 |
| 必須付帯インフラ費用 | なし（API課金に内包） | AWS ECS/EC2等のコンピュート費用 住宅用プロキシ費用（必要時） | コンピュート費用（大） Bright Data等のプロキシ費用（$5〜15/GB） CAPTCHA解除API費用 |
| 初期導入リードタイム | 即日（5分でAPI連携完了） | 1〜3日（Dockerコンテナ立ち上げ・検証） | 2〜4週間（パイプライン設計・テスト） |
| 月間保守工数（目安） | 0〜2時間（障害対応不要） | 8〜16時間（コンテナ監視、バージョン追従） | 20〜40時間（DOM変更、IPブロック、ブラウザ更新） |
技術特性の深掘り
Firecrawlの優位性とボトルネック
Firecrawlの最大の価値は、「WebサイトのクロールからMarkdown化までのパイプラインがブラックボックスとして最適化されている点」にある。特に/crawlエンドポイントでは、サイトマップの探索、ページネーションの巡回、差分更新検知を1回のリクエストで実行できる。裏側で住宅用プロキシ（Residential Proxy）を自動ローテーションさせているため、スクレイピングエンジニアが最も時間を奪われる「IP BANへの対抗措置」から完全に解放される。一方、月間100万リクエストを超えるような大規模バッチ処理では、API利用料金が跳ね上がり、経済的合理性を失う境界が存在する。
Crawl4AIの設計思想と実力
Crawl4AIは、Playwrightを非同期ラッパーで包み、LLM抽出に特化した最適化（不要なメディア・スクリプトのパージ、コンテンツスコアリング、埋め込みベクトル生成用チャンキング）を単一フレームワークで提供する。ローカルや社内VPCのDockerコンテナ上で稼働するため、外部にデータを一切送信しない。また、GPUインスタンスを併用すれば、軽量なローカルLLM（Ollama等）を用いた「抽出時構造化（JSON化）」をコンテナ内部で完結できる。ただし、高度なアンチボット（Cloudflare Turnstileのインタラクティブ認証など）が敷かれたサイトに対しては、自前で住宅用プロキシサービスをバインドし、適切な待機スクリプトを書かなければブロックされる。
Playwright自作の現実
Playwrightを直接用いる構成は、ブラウザコンテキストの完全な制御を可能にする。特定のCookieインジェクション、IndexedDBの事前ロード、LocalStorageの書き換え、WebAssembly内部のフックなど、あらゆるエッジケースを突破できる。しかし、取得したHTMLから不要なボイラープレート（フッター、広告、ヘッダー）を取り除き、美しいMarkdownへ正規化する処理は、自前でTrafilaturaや独自パーサーをメンテナンスし続ける必要があり、継続的なエンジニア人件費が重くのしかかる。
4. 【規模別・年数別】3年間の実額TCO（総保有コスト）シミュレーション
スクレイピング基盤の選定において、API利用料やクラウドサーバー代だけを見るのは誤りである。スクレイピング基盤は「対象サイトのUI変更」「Bot検知アルゴリズムの更新」「ブラウザエンジンのアップデート」に伴い、恒常的なメンテナンス工数（エンジニア人件費）を消費する。
ここでは、エンジニア人件費を時給5,000円（社内原価ベース）として試算に組み込み、3つのスケールにおける3年間のTCO（Total Cost of Ownership）を算出する。
算出前提条件
- 為替レート：1ドル＝150円換算
- プロキシ費用：OSSおよび自作構成で、対象の30%に住宅用プロキシ（1GBあたり5ドル、HTML+レンダリング通信量換算）を適用
- インフラ構成：
- Crawl4AI：AWS ECS Fargate（4vCPU / 8GBメモリ）＋データ転送量
- Playwright自作：AWS ECS Fargate（8vCPU / 16GBメモリ、ヘッドレスブラウザの多重起動用）
- 保守人件費：
- Firecrawl：月2時間（仕様変更追従）＝月10,000円
- Crawl4AI：月10時間（インフラ監視・ブロック対策調整）＝月50,000円
- Playwright自作：月25時間（パーサー修正・ブロック解除・パイプライン改修）＝月125,000円
3年間のTCO比較テーブル
| 処理規模 | 項目 | Firecrawl（SaaS） | Crawl4AI（OSS基盤） | Playwright自作 |
|---|---|---|---|---|
| 小規模 月間3万ページ （社内ナレッジ・競合調査） | 月額直接費用 月間保守人件費 初期構築費（初月のみ） 3年間TCO総額 | 約15,000円（Standard） 10,000円 50,000円（初期連携） 950,000円 | 約12,000円（最小ECS） 50,000円 200,000円（環境構築） 2,432,000円 | 約25,000円（ECS+Proxy） 125,000円 500,000円（フルスクラッチ） 5,900,000円 |
| 中規模 月間50万ページ （バーティカル検索・AI製品機能） | 月額直接費用 月間保守人件費 初期構築費（初月のみ） 3年間TCO総額 | 約60,000円（Growth） 10,000円 100,000円 2,620,000円 | 約45,000円（ECSスケール） 50,000円 300,000円 3,720,000円 | 約80,000円（クラスタ構成） 125,000円 800,000円 8,180,000円 |
| 大規模 月間500万ページ （全Web監視・LLM事前学習） | 月額直接費用 月間保守人件費 初期構築費（初月のみ） 3年間TCO総額 | 約540,000円（Enterprise） 20,000円 300,000円 20,460,000円 | 約220,000円（大規模Fargate） 75,000円 600,000円 11,220,000円 | 約350,000円（自社クラスタ） 150,000円 1,500,000円 19,500,000円 |
TCO分析から導かれる経済的境界線
-
月間50万ページ以下ではFirecrawlの一強： 小〜中規模では、SaaSの利用料（月1.5万〜6万円）よりも、エンジニアの社内リソース消費が総コストを左右する。PlaywrightやCrawl4AIを導入してサーバー代を浮かせても、保守人件費によって年間150万〜300万円以上の実質コストが上乗せされる。
-
月間100万ページを超えるとCrawl4AIが圧倒的優位に転換： 月間処理量が100万ページを突破すると、FirecrawlのAPI従量料金は月額30万円〜50万円を超過し始める。この領域では、Crawl4AIを社内インフラ（AWS FargateやGCP Cloud Run）にデプロイし、固定費化されたサーバーリソースで並行処理させる方が、人件費を合算しても圧倒的に安価になる。
-
Playwrightスクラッチはコスト面での正当化が困難： すべての規模において、Playwrightの完全内製は最悪のTCOを記録する。Markdown化アルゴリズムの自作、ヘッドレスブラウザのゾンビプロセス管理、メモリリーク対策、Bot検知シグネチャの更新を自社で背負い続けるコストは、ビジネス上の特殊要件がない限り投資対効果が合わない。
🧭 【この分岐とあわせて検討したい意思決定バイブル】
関連する周辺領域の損得分岐点もあわせて確認し、全体の費用対効果を最大化してください。
- 🔗 【条件別】ローコードiPaaS AI連携（Make vs Zapier vs n8nセルフホスト）のタスク実行数・月額課金爆発防止マトリクス
【損得分岐】月間実行数（1万回未満 vs 10万回超）とZapierのステップ従量課金 vs Makeの安価なオペレーション課金の分岐- 🔗 【条件別】AIアバター・動画解説（HeyGen vs Synthesia vs D-ID）の社内研修・YouTube動画制作費用の回収分岐マトリクス
【損得分岐】実写撮影コスト（1本15万〜30万円）とAIアバター月額（約3,000円〜1万円）の損益分岐と多言語展開メリット
5. 実務で直面する「3大失敗パターン」と生々しい回避策
失敗1：ヘッドレスブラウザのメモリ枯渇によるクラスター全滅（OOM Killerの連鎖）
発生事象
Crawl4AIや自作PlaywrightをDockerコンテナ上で並行稼働させた際、Chromiumプロセスがメモリを解放せず蓄積し、コンテナのメモリ上限に達してSIGKILL (Exit Code 137)で強制終了される。1つのタスクのクラッシュがコンテナ全体の再起動を引き起こし、キューに滞留していた未処理ジョブが数千件単位でロストする。
原因の深掘り
Chromiumは極めてリソース集約的であり、動的SPAのレンダリング時にService Worker、キャッシュ、V8エンジンのヒープをコンテキスト内に保持し続ける。単にbrowser.close()やpage.close()を呼び出すだけでは、孤立したゾンビプロセス（Zombie Process）がOSレベルで残留することが頻発する。
生々しい回避策
- 1プロセス1ライフサイクルの原則：単一のブラウザインスタンスで処理するページ数を制限する（例：50ページクロールごとにブラウザプロセスを完全に破棄・再起動）。
- コンテナ init プロセスの適用：Dockerfileに
tini（軽量initシステム）を組み込み、ゾンビプロセスの確実な回収（Reaping）を行わせる。 - スワップおよび共有メモリ（shm）の明示的拡張：Docker実行時に
--shm-size=2gb以上を明示的に割り当て、Chromiumのレンダリングクラッシュを防ぐ。 - マネージドの回避策：このトラブルシューティングに工数を割けない場合は、Firecrawl SaaSを採用し、ブラウザプロセスのライフサイクル管理を完全にプロバイダへ押し付ける。
失敗2：Cloudflare Turnstile等の最新WAFによるサイレントブロック（200 OKの罠）
発生事象
HTTPステータスコードは200 OKを返しているにもかかわらず、LLMに渡されたMarkdownの中身が「Just a moment… Enable JavaScript and cookies to continue」という文面のみになり、RAGの検索インデックスが汚染される。エラーログが出力されないため、検知が数週間遅れる。
原因の深掘り
最新のBot保護ソリューションは、HTTPヘッダーだけでなく、navigator.webdriverフラグの有無、WebGLレンダラーのシグネチャ、Canvasフィンガープリント、マウスの移動軌跡、TCP/IPスタックの挙動（JA3/JA4フィンガープリント）を複合的に監視している。Playwrightの標準モードや、未調整のヘッドレス設定は数ミリ秒で機械判定される。
生々しい回避策
- レスポンス検証バリデータの必須化：抽出されたMarkdownの文字数が極端に少ない（例: 200文字以下）、または「Just a moment」「Verify you are human」「Cloudflare」といった文字列が含まれている場合、パイプライン側でハードエラー（ブロック検知）として扱うカスタムリトライロジックを実装。
- Playwright Stealthの適用とパッチ適用済みバイナリの使用：OSSを使用する場合、
puppeteer-extra-plugin-stealthのPlaywright移植版や、フィンガープリントを偽装したカスタムChromiumビルドを使用する。 - 住宅用プロキシ（Residential Proxy）のインジェクション：データセンターIP（AWS等のIPレンジ）からのアクセスは即座にブロックされるため、Bright DataやSmartproxyの住宅用IPプールを経由させる。
- Firecrawlの活用：Firecrawlはリクエスト単位でアンチボット回避のプロキシとヘッダーシグネチャを自動切り替えするため、この種のリバースエンジニアリング作業をゼロ化できる。
失敗3：SPAの「見かけ上のレンダリング完了」によるデータ欠損
発生事象
ブラウザのロードイベント（loadやDOMContentLoaded）が発火した直後にHTMLを取得した結果、ページのスケルトン（読み込み中のグレー枠）やスピナーアイコンのみが取得され、本編のテキストデータがごっそり欠落したMarkdownが生成される。
原因の深掘り
Next.jsやReact等のモダンなSPAでは、初期HTMLがロードされた後に非同期でクライアントサイドのGraphQLやREST API通信（fetch）が走り、DOMへデータを流し込む。従来のスクレイパーが検知する「ページ読み込み完了」は、データ描画の完了を意味しない。
生々しい回避策
- ネットワークアイドル待機の導入：Playwright/Crawl4AIにおいて、
page.goto(url, wait_until="networkidle")（500ms以上ネットワーク接続が発生しない状態）を基本待機条件とする。 - 特定セレクタの出現監視：SPAのデータロード完了を示す特定のクラス名やタグ（例:
main article div.content）の出現を明示的に待つ（wait_for_selector）。 - スクロールアクションのエミュレーション：画面を最下部まで段階的にスクロールさせるJavaScriptを実行し、遅延読み込み（Lazy Loading）される画像や無限スクロールコンポーネントを強制発火させる。
- Crawl4AIの
js_codeパラメータ実行：Crawl4AIではクロール実行前にwindow.scrollTo(0, document.body.scrollHeight);などのスニペットを注入できるため、これをパイプラインに標準組み込みする。
6. あなたの最適解を導く「意思決定フローチャート」
以下の4つの質問を順番に回答することで、自社の状況に合致した技術スタックが決定される。
[START]
│
▼
【Q1: 対象データに外部送信が許されない機密情報・個人情報が含まれるか？】
├─［YES］──> 外部SaaSは規約上不可
│ │
│ ▼
│ 【Q2: 月間スクレイピング規模は50万ページ以上か？】
│ ├─［YES］──> 【解 A: Crawl4AI（自社VPC/Fargate大規模クラスタ）】
│ │ ※住宅用プロキシを自前契約し分散並行処理
│ │
│ └─［NO］ ──> 【解 B: Crawl4AI（社内単一Dockerインスタンス）】
│ ※最小インフラで低コスト安全運用
│
└─［NO］（公開Webデータの収集が主目的）
│
▼
【Q3: 月間の処理ボリュームは50万ページを超えるか？】
├─［YES］──> 【解 A: Crawl4AI（自社クラウド基盤）】
│ ※TCO逆転ライン突破。SaaS課金を回避してインフラ固定費化
│
└─［NO］
│
▼
【Q4: スクレイピングのインフラ・Bot回避を専任で保守するエンジニアがいるか？】
├─［YES（かつ特殊なブラウザ操作が必須）］
│ └──> 【解 C: Playwrightスクラッチ自作】
│ ※特殊認証、Canvas解析等の極端なエッジケースのみ
│
└─［NO（または開発工数をLLMアプリ本体に集中させたい）］
└──> 【解 D: Firecrawl（マネージドSaaS）】
※開発工数ゼロ、即日高品質Markdown取得で最速本番化
7. 現場で迷ったときのFAQ（よくある質問5選とズバリ回答）
Q1. Firecrawlのセルフホスト（OSS版）とSaaS版の決定的な違いは何か？
回答： 「プロキシプールとCAPTCHAバイパス機構の有無」である。Firecrawlのリポジトリ自体はOSSとして公開されており、自前サーバーでホスト可能だが、OSS版に含まれるのはルーティングロジックとMarkdown変換エンジンのみである。SaaS版で提供されている「Cloudflare等のブロックを自動で回避する住宅用プロキシのローテーション網」や「最新のBot検知シグネチャへの追従」はOSS版には含まれない。したがって、OSS版をセルフホストしても、Bot対策が厳しいサイトに対しては自前でプロキシ連携を行わなければ即座に403エラーとなる。
Q2. Crawl4AIでCloudflare等の厳しいWAFを突破することは可能か？
回答： 「可能だが、外部プロキシ連携とカスタムコードの設定が前提」となる。Crawl4AI単体では、高度なTurnstileなどの対話型チャレンジを完全自動で突破することはできない。これを突破するためには、Bright DataやOxylabsなどの住宅用プロキシをCrawl4AIのプロキシ設定に組み込み、さらにPlaywrightのStealth設定を有効化し、ページ遷移時の待機スクリプト（人間らしいマウス移動や遅延）を記述する必要がある。
Q3. BeautifulSoupやTrafilaturaでのHTMLパースと、AIスクレイパーのMarkdown抽出は何が違うのか？
回答： 「DOM構造のセマンティクス理解とコンテキスト保持力」が異なる。BeautifulSoupは単なるHTMLパーサーであり、不要タグの除去ルールをすべて人間がCSSセレクタ等で書く必要がある。Trafilaturaは強力な本文抽出ライブラリだが、SPAの動的実行ができない。Crawl4AIやFirecrawlは、PlaywrightでJavaScriptを完全レンダリングした後のレンダリングツリーを解析し、視覚的に不可視な要素や広告枠を排除した上で、見出し構造（H1〜H6）やテーブル（表）、リンクの関係性を壊さずにLLMが理解しやすいMarkdownへ再構築する点が決定的に異なる。
Q4. サイト全体のクロール（Sitemapからの巡回）を行いたい場合、どれを選ぶべきか？
回答：
「小〜中規模ならFirecrawl、大規模ならCrawl4AI」である。Firecrawlには/crawlエンドポイントが存在し、URLを1つ渡すだけでサブページを自動探索し、全ページのMarkdownを一括返却する機能がネイティブで備わっている。一方、Crawl4AIも非同期クロールが可能だが、巡回ロジックやURLの重複排除（Deduplication）、深さ優先/幅優先の探索キュー管理は、自前のPythonコード側でハンドリングする必要がある。
Q5. スクレイピング対象のサイト利用規約でスクレイピングが禁止されている場合の法的・技術的リスクは？
回答： 「利用規約違反による民事上の差し止め・損害賠償請求、およびIP BANのリスク」が存在する。日本では著作権法第30条の4に基づき、AIの学習や情報解析を目的としたデータ収集は原則として著作権者の許諾なく行えるが、利用規約への同意（アカウントログイン等）を伴うWebサイトの場合、契約違反に問われる法的リスクが生じる。また、過度なアクセス集中は刑法第234条（威力業務妨害罪）に抵触する恐れがあるため、どのツールを採用する場合でも、リクエスト間隔の制御（Rate Limiting）、robots.txtの尊重、夜間バッチへの分散をシステム的に強制実装しなければならない。
8. 結論と今すぐできるアクションプラン
WebスクレイピングAIの選定において、エンジニアが陥りがちな最大の誤謬は「ツール自体の利用料（無料OSSか有料SaaSか）だけで判断すること」である。保守人件費とインフラ構築コストを含めた3年間のTCOで見れば、月間50万ページ以下のスケールにおいてPlaywrightを自作したりOSSの運用に時間を溶かしたりすることは、企業経営の観点から明確な損失である。
自社が取るべきアクションプランは以下の3ステップに集約される。
アクションプラン
-
データ規模と機密要件の棚卸し（Day 1）
- スクレイピング対象の月間総ページ数を算出する。
- 対象データが社外クラウド（Firecrawl等の米国SaaS）を通過可能か、セキュリティ部門へ確認する。
-
PoCの即時実行（Day 2〜Day 5）
- 外部送信可能＆月間50万ページ未満の場合： FirecrawlのFree/Hobbyプランでアカウントを作成し、最もブロックされやすい対象サイトのURLを投げてMarkdown変換精度を検証する。
- 機密データ必須、または月間100万ページ以上の場合：
ローカル環境にDockerでCrawl4AIを立ち上げ、非同期スクリプト（
AsyncWebCrawler）を用いて対象SPAのDOMが正常にMarkdown化されるかをテストする。
-
本番アーキテクチャの確定と例外ハンドリングの実装（Week 2）
- Firecrawlを採用する場合：クレジット超過アラートと、抽出失敗時の自動リトライキュー（SQSやCloud Tasks）を設計する。
- Crawl4AIを採用する場合：AWS ECS等のコンテナ基盤にデプロイし、メモリ上限に応じたコンテナ自動再起動スケジュールおよび住宅用プロキシの接続テストを完了させる。
無駄なスクラッチ開発に工数を奪われる時代は終わった。自社の処理ボリュームが「SaaSの損得分岐点」を超えるまでは徹底してマネージドサービスで開発速度を買い、スケールが確定した段階でOSS基盤へ移行するのが、最も合理的かつROIを最大化するシステム投資である。