私は、私が何度も立ち返ってしまうある数字を、あなたに順を追って説明したいと思います。私は、この数字には、今よりももっと注目が集まるべきだと考えています。その数字は、年間の支出額で、だいたい10億ドルから50億ドルのあたりです。AI業界全体が、誰のエージェントも実際に使うことのないWebページのマークアップを処理するために、どれくらいの額を費やしているかの私たちの推計です。
エージェントが非効率だからではありません。モデルが無駄遣いだからでもありません。ウェブは、人間の目を想定した形式でコンテンツを提供しており、エージェントはページを読むたびに、その視覚的な表示レイヤーにかかるコストを満額払っているからです。
この数字がどこから来ているのかをお見せします。
まずは1つのWebページから
任意のWebページを選んでください。お気に入りのニュースサイトでも、ECの商品のページでも、ドキュメントサイトでも、政府のポータルでも構いません。右クリックして、ソースを表示します。そこにあるのはHTMLです。つまり、コンテンツ（テキスト、リンク、見出し）と、プレゼンテーション（CSSクラス、インラインスタイル、レイアウトのコンテナ、トラッキングスクリプト、広告のマークアップ、SVGアイコン、データ属性）の混合です。
HTTP Archiveの2025 Web Almanacは、中央値のホームページの重さが、デスクトップでは2.86MB、モバイルでは2.56MBになっていると報告しています。ただしAIエージェントにとって重要なのは、ページの総重量（画像、フォント、動画など、エージェントが読み込まないものを含む）ではありません。重要なのは、HTMLドキュメントそのものと、それを生成するJavaScriptです。
私たちの50サイトのベンチマークでは、レンダリングされたWebページは、言語モデルのトークナイザに投入すると平均で約33,000トークンになります。これはエージェントが実際に処理する量です。つまり、HTMLマークアップが33,000トークン、モデルのコンテキストウィンドウに押し込まれるわけです。
そのうち本当のコンテンツはどれくらいでしょうか。私たちは、生のHTMLとSOM（SOMは、プレゼンテーションを取り除きつつ意味のあるコンテンツを保持する構造化表現）を比較することで測定しました。同じページのSOM版は、平均で約8,300トークンです。
つまり、1ページあたりだいたい24,900トークン、全体の約75%は、エージェントが必要としないものをエンコードしているということです。flex items-center justify-between px-4 py-2 bg-white dark:bg-gray-900 のようなCSSクラス名。トラッキングスクリプト。レイアウトの区切り。広告用のコンテナ。クッキー同意のダイアログ。アイコンのためのSVGパスデータ。ページをブラウザで見たときに正しく見せるための視覚的な足場ですが、ページが何を言っているのか、あなたがそのページで何をできるのか、といったエージェントの理解にはまったく貢献しません。
エージェントはそのすべてを処理します。あらゆるトークンを。しかも、誰かがすべてのトークンに対して支払っています。
スケールさせる
では、そのページごとの無駄を、AIエージェントが毎日閲覧するページ数に掛け算します。ここから計算が面白くなります。そして正直に言うと、見積もりが必要になる部分でもあります。1日あたりのエージェントによるページ取得回数の正確な数は、主要なAI企業によって公開されていません。しかし、公開されている情報から妥当なモデルを組み立てることはできます。
Cloudflareの2025 Year in Reviewによれば、全Webトラフィックのうち約30%がボットトラフィックです。AI専用のクローラ（GPTBot、ClaudeBot、Meta-ExternalAgent、Amazonbotなど）が占めるHTMLリクエストの割合は全体の約4.2%で、Googlebotの4.5%とは別です。そしてこれは急速に伸びています。2024年5月から2025年5月にかけて、AIクローラのトラフィックは全体で18%増加しており、その期間におけるGPTBotの増加率は特に305%でした。
しかし、生のクローラトラフィック（主に学習データの収集）と、ユーザーの代わりにエージェントが行う閲覧は別物です。私たちはこの2つを分ける必要があります。
あなたがChatGPTに何かを調べさせるとき、それはユーザーアクションによるページ取得です。GPTBotが午前3時にWikipediaをクロールして学習データセットを作る場合、それは学習クロールのトラフィックです。学習トラフィックは量がはるかに大きいですが、実際にリクエストごとのLLM推論コストが発生するのはユーザーアクションのトラフィックです。なぜなら、取得したページがそのままモデルのコンテキストウィンドウに投入されるからです。
公開されているユーザー数データ（OpenAIはChatGPTの週次アクティブユーザーが3億人超だと報告しており、Perplexityは月間ユーザーが2,000万人だと明らかにしています。Anthropicは開示していませんが、数百万人規模のClaudeユーザーがいると推定されています）を用いて、日次のページ取得回数についてボトムアップのモデルを作りました。推計は、主要なAIエージェントすべてを合計した場合、1日に約4億件のユーザーアクションによるページ取得がある、というものです。
4億ページ。1ページあたり24,900の無駄トークン。それを、入力トークンあたりの加重平均API価格である$0.75/Mトークン（GPT-4oが$2.50、GPT-4o Miniが$0.15、Claude Sonnetが$3.00、Geminiが$1.25）で割り戻します。
計算はこうです。400Mページ/日 × 24,900無駄トークン × $0.75/Mトークン × 365日 = おおよそ27億ドル/年。
別のトップダウンモデルを、Cloudflareの総トラフィック量に照合して用いると、より高い推計が得られます。2つのアプローチを合わせると、業界全体での年間トークン無駄は1年あたり10億ドルから50億ドルの範囲に収まります。
400Mページ/日 × 24,900無駄トークン × $0.75/Mトークン × 365日 = $2.7 billion/year。そしてこれは、ユーザーが引き起こした閲覧のみを数えており、自律的なエージェントの作業負荷は含んでいません。
それは莫大なお金です。実際のところ本当なのでしょうか？
ここで不確実性については、明確にしておく価値があります。正確な数は、主に3つの変数に大きく左右されます。エージェントが1日にどれくらいのページを取得するか（最大の不確実性の源です）、トークンあたりの実効LLM価格（下がっていて、モデルごとに異なります）、そしてエージェントがすでにどれだけ前処理を行っているか（HTMLをmarkdownに変換するものもあれば、切り詰めるものもあり、キャッシュするものもあります）。
私たちはこれらすべてを考慮しています。私たちのモデルでは、エージェントの45%がすでにmarkdownに変換している（これにより無駄が約70%減る）と仮定し、30%がHTMLを切り詰める（無駄が約30%減る）とし、そして取得の15%がキャッシュヒットであるとしています。これらの調整の後、1ページあたりの実効な無駄は24,900トークンから約13,300トークンにまで減ります。10億ドルの規模感は、こうした削減をすでに織り込んでいます。
もしエージェント利用の伸びが見込みより遅い、あるいはLLM価格がこれからも下がり続けるのであれば、数値はもっと低くなると主張することもできます。どちらもあり得ます。しかし、エージェント利用の伸びは、価格が下がるペースよりもずっと速いのです。GPTBotのトラフィックは1年間で305%伸びました。LLM入力価格は同じ期間に305%下がってはいません。総コストは下がっていない、むしろ上がっているのです。
さらに、高くなる可能性を挙げることもできます。私たちのモデルは、ユーザーが求めて実行される閲覧（誰かが明確にエージェントに閲覧を依頼するケース）だけを数えているからです。自律型のエージェントの作業負荷は含んでいません。たとえば監視サービス、価格比較エンジン、リサーチのパイプライン、そして人間の働きかけなしに継続的に動いているその他のマシン対マシンの閲覧です。これらの負荷は急速に増えており、人間のユーザーが行う閲覧よりもはるかに多くのページを1インスタンスあたりで処理しています。
率直な答えはこうです。私たちは1B〜5Bドルが妥当な範囲だと考えています。中心推計の2.7Bドルは、おそらく自律型の作業負荷を過小評価しており、現状の前処理の有効性を過大評価している可能性があります。
お金は実際にどこへ行くのか？
ここがいちばん私が苛立つところです。無駄になったトークンが、ただ消えてなくなるわけではありません。推論パイプラインのあらゆる段階で、現実のリソースを消費します。
GPU計算。すべての入力トークンは、モデルの注意（アテンション）層を通過します。自己注意メカニズムは、入力長に対して二次の計算量を持ちます。入力を2倍にすると、計算は2倍以上になります。入力の75%がプレゼンテーション上のノイズだとすると、モデルは有用な情報を運ばないトークンに注意予算の大半を費やします。これは請求上の抽象概念にとどまりません。CSSクラス名に対して実際の行列乗算を行う現実のGPUが消費する、実際の電力です。
コンテキストウィンドウの押しのけ。 言語モデルには有限のコンテキストウィンドウがあります。128Kトークンのウィンドウは十分に大きいように聞こえますが、実際には単一のHTMLページだけでその33Kを消費します。あるエージェントが1回の推論呼び出しの中で5ページを解析する必要がある場合、HTML形式で収まるのはせいぜい1〜2ページですが、構造化された形式なら5ページすべてを収められます。無駄になったトークンは、そのまま、その1回の推論呼び出しでエージェントが考えられる範囲を直接的に制限します。
レイテンシ。 入力トークンが増えるほど、最初のトークンが返ってくるまでの時間（time-to-first-token）が長くなります。私たちのWebTaskBenchの評価では、このレイテンシの影響を直接測定しました。Claude Sonnet 4では、SOM入力が8.5秒だったのに対し、生のHTML入力だと平均16.2秒かかりました。エージェントはノイズ処理の量が少なかったため、ほぼ2倍速かったのです。GPT-4oでも同様の傾向が見られました。HTMLで2.74秒、SOMで1.44秒です。
このレイテンシ差は、単なるユーザー体験の問題だけではありません（ユーザーは、AIアシスタントが8秒ではなく16秒かかると気づきますが）。それはスループットの問題です。HTML入力で1秒あたりNリクエスト処理できるサービングクラスタは、構造化入力だと概ね1秒あたり2Nリクエスト処理できます。トークンコスト削減の上に、インフラの節約がさらに積み重なります。
誰も話さないこと：クロールからクリックまでのギャップ
この問題には、トークンコスト以上の次元があります。そして私は、それが長期的にウェブの健全性を左右する、より重要な側面だと考えています。
Cloudflareは2025年8月に「The crawl-to-click gap.」という注目すべきデータセットを公開しました。中核となる発見は、AIクローラが参照トラフィック（リファラ）として返す量よりも、はるかに多いコンテンツを消費しているという点です。その比率は驚くべきものです。
2025年7月、Anthropicのクローラは、出版社へ1ページ分の訪問（参照）を返すごとに、約38,000ページを取得していました。これは38,000:1というクロール対リファラの比率です。年の前半では286,000:1でした。Perplexityの比率は実際に2025年を通じて悪化しており、より多くクロールする一方で参照（リファラ）が減り、7月には194:1にまで達しました。
これをGoogleと比べてみましょう。Googleがトラフィックを囲い込んでいるという数々の不満（そしてデータも示している、2025年2月以降にニュースサイトへのGoogle参照が減少していることは、AI Overviewsの拡大と時期が一致しています）があります。それでもGoogleのクロール対リファラ比率は、個別の1桁台です。つまりGoogleはページをクロールして、そのユーザーを返しているのです。
AI企業はページをクロールし、価値を保持します。
この経済的な背景が、トークン無駄の問題を「効率化の課題」以上のものにしています。出版社は、価値を抽出するエージェントに対してコンテンツを提供するために支払っているのに、何も返ってきません。これらのリクエストを処理するためのインフラコスト（帯域幅、計算、CDN、オリジンのレンダリング）は、出版社の予算から出ていきます。そして、そのリクエストで提供されるコンテンツの75%は、エージェントにとって不要な視覚的な提示です。
出版社はそれを生成するために支払います。エージェントはそれを処理するために支払います。そして、どちらの当事者もそこから価値を得ていません。
この10の最大級エージェント・フレームワークは実際に何をしているのか
私たちの調査の一部では、10の主要なエージェント・フレームワークにおけるデフォルトのウェブコンテンツ取り扱いを調査しました。結果は、率直に言って、気が滅入るものでした。
最も人気のある3つのエージェント・オーケストレーションフレームワークであるLangChain、LlamaIndex、CrewAIはいずれも、BeautifulSoupのget_text()メソッドをデフォルトで使います。これは可能な限り強力な抽出です。すべてのHTMLタグを取り除いて、フラットで構造化されていないテキストを返します。結果は小さい（トークンにとっては良い）一方で、構造に関する情報はすべて失われます。要素の種類、インタラクティブ性の手がかり、ページ領域など、ボタンと見出しやリンクを区別するものが何も残りません。
Crawl4AI、Firecrawl、Jina Readerのような専用のスクレイピングツールは、マークダウン抽出を使います。これはより洗練されています。マークダウンは見出し、リンク、基本的な書式を保持します。しかしそれでも要素の種類（ボタンはリンクと同じ見え方）、インタラクティブ性の手がかり（何をクリックできるのか判断できない）、ページ領域（メインコンテンツとサイドバーの内容が区別できない）を捨ててしまいます。
Browser UseとStagehandはアクセシビリティツリー抽出を使い、さらにDOMを扱います。構造化された表現に最も近いものではありますが、スクリーンリーダー向けに設計されていて、エージェント向けではありません。アクセシビリティツリーにはページ上のあらゆる要素が含まれます（典型的なサイトフッターにある200の装飾的なARIAランドマークも含む）ため、出力は元のHTMLと同じくらい冗長になることがしばしばあります。
私たちが調査した10のフレームワークはいずれも、デフォルトでは構造化されたセマンティック表現を使いません。10/10がそうです。
エコシステム全体が、いまの実運用では次のどちらかです。ウェブページを生のテキストまで削り落とす（構造を失う）か、無加工のHTMLを通す（ノイズの代償を払う）か。その中間はありません。
LangChain, LlamaIndex, CrewAI: BeautifulSoup get_text()。すべてのHTMLを削除し、フラットなテキストを返す。最小限のトークン、ゼロの構造。
Crawl4AI: カスタムのHTML-to-Markdown。見出しとリンクは保持するが、要素の種類と手がかり（affordances）を失う。
Firecrawl: Readability + Markdown。記事抽出には良いが、インタラクティブ要素が見えない。
Jina Reader: Markdownへのカスタム抽出。Firecrawlと同様のトレードオフ。
AutoGPT: Jina/Firecrawlに委譲する。それらの制限を引き継ぐ。
Browser Use: アクセシビリティツリー + DOM。構造化に最も近いが、エージェントではなくスクリーンリーダー向けに設計されている。
Stagehand: アクセシビリティツリー。Browser Useと同じ冗長出力の問題。
私の眠りを妨げ続ける数字
私が繰り返し参照してしまう計算があります。WebTaskBenchのデータを使います。SOMはページあたり平均8,301トークン。生のHTMLは33,181トークンです。その差は24,880トークン。
これを1日あたり4億ページで掛けます。すると、1日あたり9.95兆の無駄トークンです。年間では、およそ3.6京トークン。1百万トークンあたり$0.75なら、$27億（2.7 billionドル）になります。
ただ、私が気になって眠れなくなるのはここです。その「1日あたり4億ページの取得」という数字は、私たちの保守的なボトムアップモデルに基づいており、明示的にユーザーがトリガーした閲覧だけを数えています。CloudflareのAIボット総トラフィックに合わせて調整したトップダウンモデルによれば、自律エージェントの作業を含めると実際の数は3〜4倍になる可能性があります。
さらに、エージェントのトラフィックは前年比18〜30%で増えている一方、LLMの価格は生成あたり（おおよそ6〜12か月ごとに）30〜50%ほど下がるかもしれません。量の増加が価格の下落を上回っています。つまり総コストのカーブは上向きになります。
もし現在の傾向が続けば、2027年には年間の無駄が100億ドルを超える可能性があります。誰かが怠慢だからではありません。ウェブが提供するフォーマット（視覚的なHTML）と、エージェントが必要とするフォーマット（構造化されたセマンティックコンテンツ）の根本的な不一致が、ウェブにページが追加されるたび、また新しいエージェントが投入されるたびに、より高くつくものになっていくからです。
解決可能な問題です
はっきりさせたいことがあります。これは絶望的な記事ではありません。無駄は現実で、数字も大きい。しかし問題は、既存の技術で完全に解決できます。
ウェブは、この問題を以前にまさに同じ形で解決しています。別の消費者クラスのためにです。1990年代後半に検索エンジンが新しいウェブの消費者として登場したとき、検索エンジンもHTMLの扱いに苦しんでいました。そこでウェブは、サイトマップ、robots.txt、構造化データ（Schema.org、JSON-LD、OpenGraph）を発明することで対応しました。これらの機械可読な層は、人間が読めるHTMLのそばに並存し、視覚的なマークアップを解析させなくても、クローラが必要とする構造化情報を提供します。
アプリケーションが2000年代半ばにWebの利用者として登場したとき、Webもまた応答しました。REST API、GraphQL、Webhooksです。プログラムによる利用のために作られた専用のインターフェース。
AIエージェントは、Webの4番目の利用者です。彼らにも同じものが必要です。つまり、彼らの利用モデルのために設計された専用の表現が。生のHTMLではありません（ノイズが多すぎる）。単なるテキストでもありません（情報が失われすぎる）。必要なものは保持し、不要なものは捨てる、その中間の何かです。
私たちはPlasmateとセマンティック・オブジェクト・モデルで、それを構築しています。とはいえ正直なところ、特定の技術よりも重要なのは、この課題が存在し、日々ますますコストがかかるようになっているという認識です。誰かがSOMよりも優れた解決策を作るなら、それは素晴らしい。業界全体としては、まだ数十億ドルを節約できます。
完全な推定手法を含む詳細な分析、価格シナリオごとの感度分析、そしてフレームワーク調査のデータは、このサイトの research paper として公開されています。エージェントのインフラ、料金モデル、またはWebコンテンツ配信に取り組んでいる方なら、このデータが役に立つと感じるはずです。
この文章で本当にあなたに残したいのは、数学よりもずっと単純なことです。
その税は合計すると数十億になります。そうである必要はありません。
David Hurley は Plasmate Labs の創業者です。以前、彼は世界初のオープンソース・マーケティング自動化プラットフォームである Mautic を創業しました。彼は dbhurley.com/blog に執筆し、研究を dbhurley.com/papers で公開しています。
