LLM抽出の費用対効果が合わなくなるとき

Firecrawlは、ページのスクレイピングに1クレジット、同じページから構造化フィールドを抽出するのに5クレジットを課金しています（Firecrawlの料金、2026年）。これは、モデルに送信される同じHTMLに対して5倍のマークアップが課されていることを意味します。

セールストークは本物です。欲しいものを説明すれば、JSONが返ってき、メンテナンスが必要なセレクターもありません。不安定なレイアウトや単発のターゲットに対しては、このマークアップに見合う価値があります。しかし、同じ5つの小売サイトから1日に50万件の商品ページを取得する本番パイプラインにおいては、そうではありません。

私たちは、開発チームがデフォルトでLLM抽出を導入し、請求月を迎えてから、抜け道を探し始める姿を見てきました。解決策は通常、LLMを完全に諦めることではありません。LLMをパイプラインの適切な場所に配置することです。

計算はすぐに厄介なものになります

安価な部類に入るFirecrawlを例に挙げてみましょう。スクレイピングにAI抽出を加えると、クロールなしで1ページあたり6クレジット、クロールありで7クレジットになります（ScrapeGraphAIの内訳、2026年）。Growthティアで1日10万ページを処理すると、リトライや、1つのproxyの費用を支払う前の段階で、月額およそ21,000ドルに達します。

独自のLLMパイプラインを運用する場合、計算は変わりますが、金額が小さくなるわけではありません。GPT-4oは、100万 input tokensあたり2.50ドル、100万 output tokensあたり10ドルです（PricePerToken、2026年）。Markdown変換後の商品ページは、4K-8Kの input tokensになります。インプットを6K、JSONの出力（blob）を200 tokensと仮定しましょう。1日10万ページの場合、日額360ドル、月額11,000ドルになります。これは、一度セットアップすればCSSセレクターが無料で実行できる処理に対するコストです。

これは安価なモデルの場合です。Claude Sonnet 4.6（インプット3ドル、アウトプット15ドル）に移行すると、請求額は2倍になります（PE Collective、2026年）。推論モデルに移行すれば、回答前にどれだけ思考するかに応じて、3〜10倍のペナルティが上乗せされます。

これには失敗のコストが含まれていません。3〜5%のハルシネーション率は無害に聞こえるかもしれませんが、計算してみるとそうではないことが分かります。1日10万ページの場合、3,000〜5,000件の誤ったレコードがデータウェアハウスに流れ込むことになります。モデルが自信満々にそれらを返すため、正しいデータとまったく同じように見えます。DataHenが指摘したように、「AIが時々間違えることが問題なのではない。自信満々に間違えることが問題なのだ」ということです（DataHen、2026年）。

経験豊富なチームが実際に行っていること

実際に本番環境でスクレイパーを運用しているベンダーのドキュメントを読むと、一貫したパターンが見えてきます。それはハイブリッドです。LLMを使用して最初に一度だけページ構造を把握し、その後のすべての処理には安価で決定論的なコードを実行します。

Zyteは自社のドキュメントで次のように明記しています。「ページごとにLLMを使用するのではなく、最初のページの生のHTMLをLLMに渡して目的のフィールドのCSSセレクターを生成させ、そのセレクターを使用して他のすべてのページをパースします。」（Zyte LLMガイド、2026年）。Apifyも2026年のガイドで同様のフローを推奨しています。まずCSSセレクターを試し、失敗した場合にLLMにフォールバックします（Apify 2026年ガイド）。本番環境への導入に関するDEV Communityの記事は、そのアーキテクチャを正確に捉えています。キャッシュされたセレクターパスのコストはゼロであり、LLMはバリデーションが失敗したときにのみ起動します（DEV.to、2026年）。

そのため、本番環境での役割分担は次のようになります。

LLMがセレクターをブートストラップする（ターゲットごとに1回の呼び出し、1セント未満）
セレクターがすべてのページに対して実行される（無料）
バリデーター（通常は正規表現または存在チェック）がドリフトを検知する
ドリフトが発生すると、数週間または数ヶ月後に再ブートストラップがトリガーされる

1ページあたりのコストは、約0.005ドルから0.0001ドルを大幅に下回るレベルまで激減します。決定論的なパースはハルシネーションを起こさないため、品質が向上します。And、すでにマッピング済みの構造をオウム返しにさせるのではなく、新しい構造を読み取るという、LLMが本当に得意とするタスクに tokensを費やすことができます。

それでもLLMがコストに見合うケース

これはLLMを否定する記事ではありません。多くの抽出タスクにおいて、モデルが適切なツールであり、クレジットの計算が成り立つケースが存在します。

毎週のように変更される不安定なレイアウト。 毎週火曜日に壊れるセレクターは、LLM抽出にかかる tokens費用よりも、エンジニアリング時間において多くのコストがかかります。モデルを実行しましょう。
二度とアクセスしないようなロングテールのターゲット。 セレクターを作成するメリットはありません。モデルを実行しましょう。
出力自体が要約である非構造化コンテンツ。 求人票からスキルへの変換、記事から主張の抽出、レビューから感情分析など。セレクターは役に立ちません。モデルを実行しましょう。
レイアウトのバリエーション全体にオプションのフィールドが散在しているページ。 20個の条件付きレンダリングを持つ単一のテンプレートこそ、LLMが正規表現チェーンに勝る領域です。

ご自身のパイプラインを確認してください。ターゲットをボリューム順にソートします。リクエスト数で上位20%を占めるターゲットは、ほぼ常に安定した構造を持っています（だからこそ、意図的に統合された上位20%なのです）。これらはセレクターの候補です。ロングテールこそが、モデルを適用すべき領域です。

これがあなたのスタックに意味すること

2026年におけるベンダーのセールストークは、デフォルトでLLM抽出を使用させようとします。クレジット課金方式は、小規模なプロジェクトでは合理的に見えます。しかし、スケールすると合理性を失います。これは、基礎となるシグナルが壊れた後に、proxyのプールサイズが実際の成功を予測しなくなったのと同じです。

実用的なパイプラインを構築しているチーム向けの3つの要点：

fetchとパースを分離する。 スクレイピングベンダーがLLMで抽出したJSONしか返さない場合、請求書が届いたときにセレクターにフォールバックすることができません。HTMLをそのまま渡し、抽出パスを選択できるインフラストラクチャを選択してください。
セレクターレベルで積極的にキャッシュする。 生成されたセレクターは、何千ものページで再利用可能です。コストがかかるのは生成の呼び出しであり、使用時ではありません。
ページ単位ではなく、レコード単位でコストを測定する。 1ページあたり0.001ドルだが5%の不正なレコードを出力するパイプラインは、1ページあたり0.005ドルでクリーンなデータを出力するパイプラインよりもコストが高くなります。ストレージ、下流のクエリ、そして最終的なクリーンアップ作業のすべてにコストがかかるためです。

退屈な半分を選択する

デフォルトでのLLM抽出は、デモには適した形ですが、本番環境には適していません。うまく運用しているチームは、LLMをページを読み取るためのツールではなく、ページを理解するためのツールとして扱っています。2026年においても、退屈な決定論的コードがボリューム勝負で勝利し、モデルは新規性の勝負で勝利します。両方がスタックに必要なのです。

FourAでは、SingleとBrowserが生のresponse（HTML、レンダリングされたDOM、header、body）を返し、そこで処理を終了します。セレクターでパースするか、モデルに送信するか、あるいはその両方を行うかは、あなた次第です。私たちは、私たちが実行していない抽出に対してクレジットの倍率を上乗せすることはありません。