Webページの解析、LLMに全文を渡すと高くつく〜ローカルLLMへ逃がしてトークンを減らした実測
大きなWebページから必要な情報を取り出す作業を、最初はLLMにページ本文を丸ごと渡して任せていました。動くには動くのですが、1ページあたりのトークンがふくらみ、件数が増えるほどコストが効いてきます。そこで「ページ全部をLLMに読ませる」のをやめ、確定値はコードで抜き、迷う部分だけ手元のローカルLLM（ollama）に渡す形へ切り替えました。同じ作業のトークン量がどれだけ変わるか、手元のPC（RTX 3090＋RTX 3060＋ollama）で実際に測ってみます。
計測日 2026-06-22／ローカルモデル gemma4（26B・MoE）のトークナイザで測定。題材は一般公開されている技術系の一覧ページ。
なぜ「全文を読ませる」と高くつくのか
LLMの利用料は、入力したテキスト量（トークン）にほぼ比例します。Webページは見た目以上に重く、本文だけでも数千〜数万トークンに達します。1ページなら気になりませんが、何十・何百ページを処理すると、入力トークンがそのまま積み上がっていきます。
厄介なのは、取り出したい情報が価格や型番のように「ページのごく一部」であっても、全文を渡せばページ全体ぶんの料金がかかる点です。欲しいのは数十文字でも、支払うのはページ一枚ぶん、という構図になりがちでした。
考え方〜確定値はコード、迷う部分だけLLM、取得は実ブラウザ
作業を一段ずつに分け、それぞれ一番安く確実な道具を割り当てます。LLMに任せるのは「人の判断が要る曖昧な部分」だけに絞り込みます。
工程ごとの役割分担
| 工程 | 担当 | LLMトークン |
| ページ取得（動的描画・読み込み待ち） | 実ブラウザ（Playwright等） | ゼロ |
| 確定値の抽出（価格・型番・IDなど） | 正規表現／DOMセレクタ | ゼロ |
| 曖昧な判定（表記ゆれの名寄せ等） | ローカルLLM（ollama） | 少量★ |
| 整形・集計・保存 | スクリプト | ゼロ |
LLMは曖昧判断にだけ使う。確定値はコードで抜けばトークンはゼロ
確定値の抜き出しは、LLMよりも正規表現やDOMセレクタの方が速く、外しません。LLMの出番は「メーカー表記のゆれを揃える」「複数候補から本命を選ぶ」といった、ルールにしづらい判断だけにとどめます。
取得層〜実ブラウザでページを取る
読み込み後にJavaScriptで中身が描かれるページは、単純なHTTP取得では空っぽのことがあります。表示を待ってから本文を受け取るために、Playwrightのような実ブラウザを使う方法が手堅いやり方です。ここはLLMを通しません。取得したHTMLをそのまま次の抽出層へ渡します。
抽出層〜確定値はコード、曖昧マッチだけローカルLLM
受け取ったHTMLから、まず機械的に取れるものをコードで抜きます。価格や型番のように形が決まっている値は、正規表現やDOMセレクタで十分です。ここまではトークンを一切消費しません。
残った「迷う部分」だけを、短い抜粋にしてローカルLLMへ渡し、JSONで返してもらいます。ollamaならローカルで完結するので、何件投げても外部の従量課金は発生しません。渡すテキストを小さく保つほど、処理は速く軽くなります。
実測〜全文方式とハイブリッドのトークン比較
同じ1ページに対して、入力トークンを3通りで測りました。①ページ本文を丸ごと渡す方式、②関連する表だけをまとめて渡す現実的な抽出、③必要な1ブロックまで絞った抽出です。
1ページあたりの入力トークン（実測）
このPC・gemma4トークナイザで測定（2026-06-22）。全文13,136に対し、絞り込むほど大きく下がる
全文方式の13,136トークンに対し、関連する表に絞ると3,717トークン（およそ4分の1）、必要な箇所まで削ると567トークン（およそ23分の1）まで下がりました。どこまでコードで前処理できるかで着地は変わり、調べたところ実務では1ページあたり6分の1前後に収まる例が多いようです。いずれにせよ、LLMへ渡すテキストを削るほどコストはまっすぐ下がります。
どこまでローカルで足りるか〜限界と対処
小さく切った抜粋からJSONを起こす程度であれば、中規模のローカルモデルでも十分こなせます。一方で、長い文脈をまたいだ要約や、難しい言い回しの解釈は、ローカルモデルだと取りこぼすことがあります。そうした重い判断だけクラウドの上位モデルに回し、量の出る単純処理はローカルに残す、という線引きが現実的です。
ローカル側の精度が足りないと感じたら、モデルを一段大きくする、抜粋の作り方を見直して必要な手がかりを入れる、出力をJSONスキーマで縛る、といった調整で安定します。
応用〜価格監視・在庫・カタログ整備・素材集め
この分け方は、商品情報の取り出しに限りません。価格や在庫の定点観測、カタログの整備、記事を書くための素材集めなど、「大量の半構造データを決まった形に直す」作業ならほぼそのまま当てはまります。確定値はコード、迷う部分だけLLM、という骨格は共通です。
必要な機材〜ローカルLLMを動かす土台
ローカルLLMを快適に回すには、それなりのGPUかメモリ帯域の太いマシンが要ります。
どのくらいの性能で何が動くかは、別の記事で実測をまとめています。
手元の環境さえ整えば、量の出る処理をローカルに逃がして、外部の従量課金を必要な判断だけに絞り込めます。まずは小さなページ1枚で、全文方式と抽出方式のトークン差を測ってみると、効き目がはっきり見えてきます。