OpenRouterのエージェントによるトークン使用量は人間トラフィックの5倍、ただし主な要因はキャッシュ済みコンテキスト

OpenRouterにおけるエージェントのトークン使用量は8月に7.3兆トークンに達し、人間に帰属する1.4兆トークンの5倍を超えた。しかし報道によれば、そのエージェントトークンの85％超は、新たに処理された指示や生成された回答ではなく、キャッシュ済みプロンプトに由来していた。

この違いは、AIが今や人間以上にAIを利用しているという主張を複雑にする。エージェントがタスク当たりで大幅に多くのモデルトラフィックを生み出していることは明らかだ。一方で、このグラフが測定しているのは単一プラットフォームを経由したトークンであり、世界全体のAI導入、支出、生産的な作業、経済価値ではない。

Futurum GroupのCEOであるDaniel Newmanは、9月30日のX投稿でこの数値を拡散した。同氏は、この比率が5倍から10倍へ上昇し、その後もさらに高まると予測した。5倍という数値は観測されたOpenRouterのトラフィックに基づく。一方、10倍という数値は、時期や裏付けとなるモデルが示されていない予測にとどまる。

したがって、本当の競争はエージェント対人間ではない。生のトークン量と有用な仕事の比較である。この違いは、エージェントループを管理する開発者、投資対効果を評価する企業、メモリ容量を計画するインフラ提供者にとって重要だ。

OpenRouterのエージェントによるトークン使用量は明確な閾値を超えた

8月のデータはモデルトラフィックの大きな変化を示すが、それはOpenRouterが測定する環境内に限られる。

OpenRouterは、複数のモデルと推論プロバイダーにリクエストをルーティングするゲートウェイを運営している。その立場により、同社は直接的な会話、コーディングツール、自律ワークフローを含む多様なアプリケーショントラフィックを把握できる。

報じられたグラフは、2026年8月10日までの7日間平均のトークン使用量を示している。エージェント型トラフィックは約7.3兆トークンに達し、人間トラフィックの1.4兆トークンと比較された。

その結果、比率は約5.2対1となる。これは、この測定期間中にOpenRouter上でエージェントが人間の5倍のトークントラフィックを生み出した、というより限定的な主張を裏付ける。

ただし、ChatGPT、Claude、Gemini、プライベートクラウドのデプロイメント、ローカルホストのモデルを含む全体で同じ比率が成立することを示すものではない。これらのシステムには、OpenRouterが観測できない相当量のトラフィックが存在する。

OpenRouterはまた、2月6日以降、エージェント型の使用量が約14倍に増加したと報告した。同じ期間に人間のトークン使用量は約2.8倍に増えた。人間とエージェント的な挙動を組み合わせた混合トラフィックは、約4.7倍に増加したとされる。

2月6日は、このデータセットで人間トラフィックがエージェントトラフィックを上回った最後の観測日だった。このため、8月の結果は単日の急上昇よりも意味を持つ。エージェントは約6カ月にわたり優位を維持し、その差を広げてきた。

OpenRouterは各APIキーを、エージェント型、人間、混合に分類した。報道によれば、このシステムはツール呼び出し率、ターン数、応答間の時間間隔を含む7つの重み付けシグナルを利用した。

この手法は、アプリケーション名だけに依存するよりも有益だ。汎用的なAPIクライアントでも自律ループを実行できる一方、エージェントとして売り出されているアプリケーションが、人間の直接的な制御下にとどまることもある。

ただし、行動に基づく分類には不確実性が伴う。APIキーは複数の製品、チーム、ユースケースにまたがって使われる場合がある。認証情報を変更せずに、ワークロードが人間主導と自動化された挙動の間を移行することもある。

混合カテゴリはこの曖昧さを認めているが、解消するものではない。そのトラフィックの一部を再分類すれば、エージェントと人間の比率は変わる。

もう一つ重要な意味論上の問題がある。通常の経済的な意味で、エージェントは独立した顧客ではない。人間と組織がエージェントを導入し、目標を定義し、リクエストの費用を負担し、その出力に価値があるかを判断する。

エージェントは、自動化された仲介者として理解する方が適切だ。1つの人間のリクエストが、計画、検索、ツール実行、検証、修正、反復的なモデル呼び出しを開始しうる。

この増幅効果こそが中核となる出来事だ。AI需要はもはや、何人がチャットウィンドウを開くかだけで決まらない。1つの人間のリクエストがどれほど多くの機械的活動を誘発するかへの依存を、ますます強めている。

OpenRouterの以前の1,000億トークン調査も、同じ構造的な変化を示している。同調査は、エージェント型推論を、計画、ツール、修正、反復的なモデル対話を伴う長い連続プロセスとして説明した。

この調査では、プログラミングがプロンプト増加の主要な要因になったことが明らかになった。プログラミング向けプロンプトは、2025年後半までに汎用プロンプトの数倍の長さにもなっていた。

これらのパターンは、なぜエージェントが閾値を超えたのかを説明する助けになる。人間は1件のコーディング依頼を送るかもしれない。エージェントは繰り返しファイルを確認し、ツールを呼び出し、テスト結果をレビューし、作業中のコンテキストを再送できる。

8月のグラフは、こうした増幅をプラットフォーム規模で捉えている。自律ソフトウェアが人間の需要を置き換えたことを証明するものではない。人間の需要が、多数の下流リクエストを生むシステムを通じて届く割合が高まっていることを示す。

1つの人間の指示が数千回のモデル操作を引き起こしうる

エージェントが多くのトークンを消費するのは、単一のリクエストを継続的な計算プロセスに変えるためだ。

従来のチャットボット対話は、通常、目に見えるリズムに従う。人がプロンプトを書き、回答を受け取り、続けるかどうかを決める。新しいターンはそれぞれ、次の人間の行動に依存する。

エージェントは、その間を置かずに継続できる。目標を解釈し、手順を作成し、ツールを選び、結果を評価し、もう一度試すべきかを判断する。

たとえば、ソフトウェアの移行を考えてみよう。開発者は、あるクラウドサービスから別のサービスへアプリケーションを移すよう、エージェントに依頼するかもしれない。

最初のモデル呼び出しでは、リクエストを調べて計画を立てられる。その後の呼び出しでは、設定ファイルの確認、ドキュメント検索、コード編集、テスト実行、失敗の診断、実装の改訂が行われる可能性がある。

各呼び出しには、最新の指示以上のものが含まれる場合が多い。システムルール、ツール定義、リポジトリの詳細、過去のメッセージ、コマンド出力、エージェントの以前の判断などを保持できる。

この蓄積された情報がコンテキストウィンドウ、すなわち1回のリクエスト中にモデルが利用できるテキストと構造化データを意味する。タスクが続くにつれて、そのコンテキストは元の人間のプロンプトよりはるかに大きくなりうる。

ツール利用はトラフィックをさらに増やす。モデルがデータベースクエリを生成し、結果を確認した後、次に何をするかを決めるために再びモデルを呼び出すことがある。

並列エージェントは、このプロセスをさらに増幅しうる。1つのコーディネーターが、調査、コーディング、テスト、レビューを別々のワーカーへ委任するかもしれない。各ワーカーは自身の指示とタスク履歴を維持する。

これは、トークン量がユーザー数よりはるかに速く増加しうる理由を説明する。基本単位は会話ターンからワークフローステップへ移行している。

OpenRouterのデータは、推論およびプログラミングのワークロードの増加も反映している。これらのタスクは、中間状態、外部ツール、反復的な検証を伴うため、自然と長い対話を促す。

学術的な証拠は、この増幅が極端な規模になりうることを示している。2026年のあるエージェント型コーディング研究では、実験環境において、エージェントのタスクはコードチャットの約1,000倍のトークンを消費した。

エージェントコスト研究では、反復実行の間に大きなばらつきも見られた。研究者のテストでは、同じタスクにおけるトークン使用量が最大30倍異なった。

重要なのは、トークンが多いほど一貫して良い結果が得られたわけではないことだ。パフォーマンスはしばしば中程度の水準でピークに達し、その後は追加の消費が見合う改善をもたらさなくなった。

この知見は、OpenRouterのエージェントトークン使用量の背後にある主な緊張関係を強める。増加するトークン数は、生産的な自動化、不必要な反復、あるいはその両方の混在を表しうる。

そのためエージェント開発者は、生成された活動量だけでなく、完了した作業を測定する圧力に直面している。有用な指標には、採用されたコード変更、解決済みのサポートケース、成功した取引、人間による修正なしに完了したタスクなどがある。

トークンはテキスト処理の単位にすぎない。正確性、難易度、新規性、ビジネス価値を本質的に測るものではない。

同じ数のトークンを消費する2つのワークフローでも、結果は大きく異なりうる。一方は難しいエンジニアリング上の問題を解決するかもしれない。もう一方は、制限によって停止するまで失敗した計画を繰り返すかもしれない。

どちらの結果になりやすいかは、周囲のシステム設計によって決まる。明確な完了テストは、エージェントが成功を認識する助けになる。上限のある再試行ポリシーは、失敗中のタスクが無期限に実行されることを防ぐ。

優れたツールは、長いテキスト推論の必要性も減らす。構造化APIは、そうでなければ繰り返しのブラウジングと解釈を必要とする正確な結果を返せる。

メモリアーキテクチャも同じ理由で重要だ。エージェントはすべてのステップで過去の詳細すべてを必要とするわけではない。現在の判断に関連し続ける部分集合を必要としている。

ここで、検索可能な個人向けナレッジベースが、人間主導のワークフローを支援できる。システムがコンテキストを慎重に選択すれば、取得した根拠は無差別な履歴の代わりになりうる。

この圧力は開発者だけに及ばない。企業の購買担当者は現在、製品がループをどのように制御し、コンテキストを取得し、消費量を報告するかを評価する必要がある。

短いデモでは効率的に見える製品でも、長時間実行されるワークロードでは異なる挙動を示す可能性がある。本番タスクでは、欠落した権限、曖昧な目標、変化するデータ、予期しないツール応答に直面する。

こうした条件は再試行を生む。また、エージェントに信頼できる停止ルールがあるのか、それとももっともらしい次のステップを出し続けるだけなのかを明らかにする。

人間の導入は依然として重要だが、それだけでは推論需要を予測できなくなっている。より有用な式には、ユーザー数、委任されたタスク数、タスク当たりのモデル呼び出し数、呼び出し当たりのトークン数が含まれる。

この式から見れば、10倍という比率は原理的にはあり得る。ただし、Newmanの予測が必然となるわけではない。比率は最適化、モデルの挙動、アプリケーション設計、OpenRouter外のトラフィックにも左右される。

キャッシュ済みプロンプトがトークン急増の大部分を説明する

エージェント優位の最大部分は、まったく新しい推論や出力ではなく、繰り返されるコンテキストとみられる。

a16zのプレゼンテーションでは、エージェントトークンの85％超がキャッシュ済みプロンプトに由来したと報じられている。キャッシュ済みプロンプトとは、後続のリクエストが一致する内容で始まる場合に、プロバイダーが再利用できる、以前に処理された入力セグメントのことだ。

エージェントは安定した素材を繰り返し再送することが多い。その素材には、システム指示、ツールの説明、プロジェクトファイル、ポリシー、過去の会話履歴などが含まれうる。

各呼び出しで同じ接頭辞をゼロから処理すると、計算を無駄にすることになる。プロンプトキャッシュにより、プロバイダーはその接頭辞に関連付けられた中間結果を再利用できる。

OpenRouterのキャッシュテレメトリーは、キャッシュ済みトークンを新たに処理されたプロンプトトークンから分離している。また、将来の再利用に向けてキャッシュへ書き込まれたトークンも識別できる。

つまり、7.3兆トークンを7.3兆単位の新規モデル作業と解釈すべきではない。大きな割合は、システムが以前に遭遇した情報を表している。

この違いはコストに影響する。一般にプロバイダーは、新規入力を処理する場合よりもキャッシュ読み取りの料金を低く設定する。以前の計算の大部分がすでに行われているためだ。

しかし、キャッシュされているからといって無料というわけではない。システムはキャッシュエントリを特定し、そのデータを取得し、推論時に関連するモデル状態を利用可能にしなければならない。

関連するモデル状態は、しばしばキー・バリュー・キャッシュ、すなわちKVキャッシュと呼ばれる。これは以前のトークンから導出されたアテンション情報を保存し、モデルが先行するすべての位置を再計算することなく処理を継続できるようにする。

プロンプトが長いほど、KVキャッシュも大きくなる。同時に動くエージェントセッションが増えるほど、その数も増加する。長期にわたるワークフローでは、大量に保存されたコンテキストへ繰り返しアクセスする必要も生じうる。

これにより、インフラのボトルネックは変化する。計算能力は依然として重要だが、メモリ容量、メモリ帯域幅、データ移動の重要性はますます高まる。

だからこそ、キャッシュの比率が高いからといって、OpenRouterのデータが無意味になるわけではない。データが示す意味が変わるのである。

このグラフは、新規の推論需要を示す証拠としては弱い。一方で、エージェントシステムが多数のモデル呼び出しにまたがり、大きな履歴を繰り返し保持している証拠としては強い。

これは、同じ大きなプロジェクト用バインダーを何度も参照する状況に似ている。見慣れたページを再読する準備は新しいページを分析するより少なくて済むが、バインダー自体は利用可能な状態に保たれなければならない。

キャッシュは、非効率なエージェント設計を財務的に許容可能にする場合もある。割引されたキャッシュ読み取りによってコストの一部が見えにくくなるため、ワークフローが巨大なシステムプロンプトを再送してしまう可能性がある。

それでも、その設計は容量を消費する。レイテンシーを増やし、ルーティングを複雑にし、安定したプロンプト接頭辞への依存を生むおそれがある。

すべての構成でキャッシュヒットが保証されるわけではない。プロンプトの初期部分を変更すると、後続のキャッシュ済み素材が無効になることがある。プロバイダー間でリクエストをルーティングすることも、再利用に影響しうる。

動的なデータも別の課題をもたらす。タイムスタンプ、取得した文書、ツールの結果、ユーザー固有の詳細が先頭付近に現れると、接頭辞の安定性を下げる可能性がある。

したがって、エージェント開発者には意図的なコンテキスト構造が必要になる。安定した指示は冒頭付近に置き、変更される情報は、プロバイダーの挙動が許す場合には再利用可能なセクションの後に置くべきだ。

セッションアフィニティも重要になりうる。互換性のあるプロバイダーに関連付けられ続けるリクエストは、予測不能にルーティングされるリクエストより、以前のコンテキストを再利用できる可能性が高い。

85%という数字についても、慎重な帰属が必要だ。情報源の報告によれば、これはOpenRouterデータに対するa16zの位置付けの中で示された。OpenRouterの元の分析では、別の計算方法により、より低い比率が示されたとも説明されている。

分母が異なれば、割合も異なりうる。ある方法ではすべてのトークン量を集計し、別の方法ではリクエストごとのキャッシュ比率を平均することができる。

少数の非常に大規模なワークフローは、典型的なリクエストを代表していなくても、総量を支配しうる。逆に、リクエスト単位の平均比率は、最大級のワークロードが持つ影響を過小評価する可能性がある。

両方の測定値は、異なる問いに答えている限り、正確でありうる。公開グラフには、報告されたすべてのキャッシュ比率を独立に整合させるための方法論的な詳細が十分に示されていない。

したがって、最も安全な結論は方向性にとどめることだ。キャッシュされたコンテキストはエージェントのトークントラフィックの明確な過半を占める一方、正確な比率はプラットフォームによるリクエストの集計方法に左右される。

これは「AIがAIを使っている」という表現にも異議を唱える。エージェントが必ずしも、何兆回もの独立した推論行為を実行しているわけではない。トラフィックの多くは、委任された作業を継続するために必要なコンテキストを復元することに関わっている。

その挙動は、それでも実際の価値を生みうる。コーディングエージェントは、ツール呼び出しのたびにゼロから始めることを避けるため、リポジトリの状態と過去の判断を必要とする。

効率性に関する問いは、選択にある。エージェントは最小限で有用なコンテキストを再読み込みするのか、それとも実装が容易だからという理由で毎回すべてを送信するのか。

トークン量が増えるにつれ、この差は重要なエンジニアリング上の選択となる。効率的なコンテキスト管理は、タスクの性能を弱めることなくメモリ需要を減らせる。

トークンが5倍でもROIが5倍になるとは限らない

トークン量は利用度を測る一方、投資対効果は成果の成功と総運用コストに左右される。

Newmanは、AIのリターンを評価する際に企業が人間による導入を過度に重視していると論じた。チャットベースの導入指標からは見えないほど大量の推論を、今や1人のユーザーが開始できるという点で、彼のより広い主張には妥当性がある。

月間アクティブユーザー数は、インフラ需要を過小評価しうる。従業員がデスクを離れた後も継続して動く自動化作業を、シート数では捉えきれないこともある。

しかし、ユーザー数をトークン数に置き換えても、別の不完全な指標になる。トークンは活動を明らかにするが、その活動が収益を生んだか、人件費を削減したか、品質を改善したか、あるいはリスクを増やしたかは示さない。

5倍という比率も、2つの経済主体ではなく、2つのトラフィックカテゴリーを比較している。エージェントのリクエストは、依然として人間または組織による意思決定の下流にある。

企業がリターンを得るのは、エージェントがより多くのトークンを消費したからではない。許容可能なコストとリスクの水準で、価値のある仕事をエージェントが完了したときに得られる。

有用な評価は、タスクの成功から始まる。チームは、ワークフローが意図されたアクションを完了したか、人間がその結果を受け入れたかを問うべきだ。

次の問いは介入に関するものだ。監督なしで完了するエージェントは、繰り返しの修正を必要とするエージェントとは異なる運用プロファイルを持つ。

レイテンシーも重要である。最終的に成功するワークフローでも、顧客の待ち時間が長すぎたり、ピーク負荷時にインフラのキューが膨らんだりすれば、商業的には失敗しうる。

次に総コストが来る。トークン料金は一要素にすぎない。ツール呼び出し、検索サービス、データベース、サンドボックス、可観測性、セキュリティレビュー、人間による修復対応には、多額の費用が加わる可能性がある。

リスク調整後の成果も重要だ。本番システムを変更するエージェントには、公開文書を要約するエージェントより強力な統制が必要になる。

OpenRouterのグラフは、こうした問いのいずれにも答えられない。これは企業のリターンではなく、トラフィックを説明するために設計されたものだ。

同じ制約はNewmanの10倍予測にも当てはまる。この比率を外挿することは、同等の効率性改善がないまま、エージェントトラフィックが人間のトラフィックより速く成長し続けると仮定している。

この仮定はいくつかの理由で崩れうる。アプリケーションはコンテキストを圧縮し、定型的なステップにはより小さなモデルを使い、繰り返しの推論を決定論的なソフトウェアに置き換え、ループをより早く止められる。

モデルの改善は再試行を減らせる。より良いツールインターフェースも、より整理された情報を返すことで、タスク完了に必要な呼び出し回数を減らせる。

経済的な圧力は、そうした変更を促す。キャッシュ読み取りが比較的安価であっても、成果を改善しない呼び出しを取り除くインセンティブが企業にはある。

ループ収束に関するa16zの議論は、同じ問題を浮き彫りにしている。利用可能な価値の大半がすでに現れた後も、エージェントは追加の作業を続ける可能性がある。

外部的な完了テストのないループは、継続的な活動を進捗と取り違えかねない。文書を繰り返し編集したり、失敗したコマンドを再実行したり、すでに十分に受け入れられる回答をさらに洗練したりするかもしれない。

各呼び出しが個別には妥当に見える場合、この挙動の検出はとりわけ難しい。無駄は1つの応答の中ではなく、全体の軌跡を通じて現れる。

したがって、可観測性はタスクレベルで機能しなければならない。開発者には、各モデル呼び出しをツール利用、状態変化、エラー、最終的な成果へと結び付けるトレースが必要だ。

予算もタスクの価値を反映すべきである。高リスクの調査は、定型的な書式設定の依頼より多くの反復を正当化しうる。

エスカレーションルールも別の境界を作る。エージェントが繰り返しの失敗や不確かな権限に直面した場合、人に制御を渡す方が安く安全になることがある。

OpenRouterのトラフィックには、選択効果もある。このプラットフォームはモデルゲートウェイを意図的に利用する開発者にサービスを提供しており、消費者向けアプリケーションより技術的なワークロード構成になる可能性がある。

そのため、プログラミングとエージェントフレームワークは、AI市場全体における比率よりも、OpenRouterで大きな割合を占める可能性がある。

それでもOpenRouterの規模は、この傾向を重要なものにしている。そのデータは、多数のモデルとプロバイダーにまたがる相当な実世界トラフィックをカバーしている。ただし、結果はその対象範囲に結び付けたまま解釈すべきだ。

同プラットフォームとの関係も、別の考慮点をもたらす。Andreessen HorowitzはOpenRouterに投資しており、a16zはトークンルーティングインフラの成長に利害を持っている。

これは数字を無効にするものではない。特にデータがAI経済について広範な主張を支える場合、透明な方法論と独立した再現の重要性を高める。

最も強い解釈は、両極端を避ける。グラフは、自律型マシンがAIの主要顧客になった証明でもなければ、キャッシュによる空虚な見かけでもない。

これは、エージェントアーキテクチャが推論需要を増幅する証拠である。また、この増幅が現時点では、古いコンテキストの転送と取得に大きく依存していることも示している。

購入者にとって中心的な問いは、エージェントが多くのトークンを使うかどうかではない。追加のラウンドごとに、成功し価値のある成果が得られる確率が高まるかどうかである。

メモリプロバイダーとエージェントプラットフォームに迫る差し迫った圧力

このトラフィックの変化は、コンテキストを効率的に管理するシステムに報い、トークン消費を進捗の代理指標として扱う製品に圧力をかける。

モデルプロバイダーは、通常のリクエスト・レスポンス型チャットより複雑なワークロードに直面している。エージェントセッションはより長くアクティブであり続け、ツールを繰り返し呼び出し、履歴を増大させる可能性がある。

そのワークロードは、スケジューラーとルーティングシステムに圧力をかける。プロバイダーは、変動する需要の中で、キャッシュの局所性、モデルの可用性、レイテンシー、信頼性のバランスを取らなければならない。

OpenRouterのようなゲートウェイプラットフォームは、アプリケーションが複数のモデルを使う機会が増えるにつれ、戦略的重要性を増している。ワークフローは、計画、コーディング、検証、要約を異なるエンドポイントにルーティングできる。

動的ルーティングはコストを下げたり性能を高めたりできるが、キャッシュを妨げる可能性もある。別のプロバイダーへ送られたリクエストは、以前に確立されたキャッシュへのアクセスを失うかもしれない。

明確なキャッシュ指標を公開するプロバイダーは、高度な購入者に対して優位に立つ。チームは、どれだけのトークンが新規、キャッシュ済み、生成済み、あるいはストレージに書き込まれたものなのかを把握する必要がある。

メモリメーカーも、より大きなコンテキストとより多くの同時セッションから需要に直面している。高帯域幅メモリはモデルアクセラレーターに供給され、従来型メモリとストレージは周辺システムを支える。

ただし、このグラフは将来のメモリ購入量を定量化するものではない。示しているのはトークントラフィックであり、各トークンと新たなハードウェア容量の正確な対応関係ではない。

ハードウェア需要は、モデルアーキテクチャ、データ型、バッチ処理、キャッシュの退避、圧縮、同時セッション数に左右される。ソフトウェアの改善は、これらの各関係を変えうる。

エージェントプラットフォームは別の方向からも圧力を受ける。顧客は、単に高性能なモデルへアクセスできるかではなく、トークン当たりの有用な作業量をますます比較するようになる。

幅広い利用主張の裏に消費量を隠す製品は、企業の財務チームがタスクレベルの経済性を求める場面で苦戦する可能性がある。購入者は、自社のワークロードにわたって再現可能な証拠を求めるだろう。

コーディングエージェントは、ビルド、テスト、レビュー、デプロイの成果で出力を評価できるため、初期の試金石となる。これらのシグナルは測定可能な停止条件を生み出す。

他の領域は依然として難しい。リサーチ、戦略、執筆には、単一の客観的なテストがないことが多い。エージェントは、完了の明確な瞬間がないまま出力を洗練し続ける可能性がある。

その不確実性は、エージェントが中間作業の大半を担う場合でも、人間によるレビューをより重要にする。また、ベンダー間でトークン効率を比較することも難しくする。

インフラベンダーは、コンテキスト圧縮、プレフィックスキャッシュ、ステートフルセッション、検索システムで対応できる。各アプローチは、不必要な履歴の再送を避けようとするものである。

アプリケーション開発者は、永続メモリとワーキングコンテキストを分離できる。永続メモリには将来役立つ可能性のある情報を保存し、ワーキングコンテキストには現在のステップで必要な情報だけを含める。

この分離により、重複テキストを減らし、無関係な情報を制限できる。また、アクティブなプロンプトから気を散らす情報を除外することで、モデルの精度向上にもつながる可能性がある。

決定論的な作業は、決定論的なソフトウェアが担うべきだ。信頼できるコードが直接実行できる計算、スキーマ検証、アクセスチェックまで、エージェントが推論する必要はない。

最も効率的なシステムは、おそらくモデルと従来型ソフトウェアを組み合わせる。モデルは曖昧さの処理と計画を担い、コードはルールを強制し、安定した処理を実行する。

このハイブリッド設計は、エージェントのトラフィックが無制限に増え続けなければならないという前提を弱める。より優れたシステムは、タスクあたりのトークン数を減らしながら、より多くのタスクを完了できる。

同時に、単位コストの低下は総需要を増やす可能性がある。各ワークフローが安価になれば、開発者はより多くの場所にエージェントを導入し、より頻繁に実行できる。

このようなリバウンドにより、個々のタスクがより効率的になっても、インフラ成長は維持され得る。この可能性は、Newman氏の予測の方向性を支持するが、その正確な比率までは裏付けない。

人間によるトラフィックも増加し得る。より優れた消費者向け製品、新たなインターフェース、企業での導入拡大により、エージェントのトラフィックと並行して直接利用も増える可能性がある。

将来の比率は、どちらの曲線がより速く成長するかに左右される。エージェントの改善だけで決まるものではない。

OpenAI、Anthropic、Google、オープンウェイトモデルの開発者、専門的な推論プロバイダーの競争が、その曲線を形作る。キャッシュのルールやツールの機能はそれぞれ異なる。

ワークフローの途中でモデルの選択が変わることもある。小規模モデルがリクエストを分類し、大規模モデルが難しい判断を処理する、といった構成だ。

このアーキテクチャでは、単一の集計トークン数の重要性が低下する。コンパクトなモデルで処理されるトークンは、フロンティアモデルで処理されるトークンとは異なるリソースプロファイルを持つ。

企業には、モデル選択、トークン種別、レイテンシー、エネルギー、タスク成功を組み合わせた正規化指標が必要になる。現時点では、全体像を捉える広く受け入れられた標準は存在しない。

そうした標準が確立されるまでは、OpenRouterのエージェントトークン使用量は有用な先行指標であり続ける。財務報告がその価値を説明する前に、需要の形を明らかにする。

10倍予測を検証する3つのシグナル

次の段階は、分類の安定性、新規トークンの増加、推論単位あたりの完了作業量で評価すべきだ。

最初のシグナルは、OpenRouterにおけるエージェント対人間の比率が8月以降も上昇を続けるかどうかだ。持続的な上昇は、自律型ワークフローが直接的な対話よりも速く拡大しているという考えを支持する。

比較には、同一の分類方法と測定期間を用いるべきだ。手法の変更は、行動の同等な変化を伴わずに、見かけ上の成長を生む可能性がある。

混合トラフィックには特に注意が必要だ。これが両カテゴリーより速く増加すれば、人間利用とエージェント利用の境界はより信頼しにくくなる。

2つ目のシグナルは、エージェントトークンの構成だ。キャッシュされた割合の上昇は、新たなモデル処理ではなく、コンテキストの反復が引き続き主要な成長エンジンであることを示す。

キャッシュ比率の低下と総量の増加が同時に起きれば、異なる見方が必要になる。それは、エージェントが主に既存コンテキストを再生するのではなく、より多くの新規推論を実行していることを示唆する。

公開報告では、新規入力、キャッシュ読み取り、キャッシュ書き込み、推論トークン、出力を区別すべきだ。それらを一つの数値にまとめると、コストとインフラ需要における大きな違いが隠れてしまう。

3つ目のシグナルはタスク効率だ。エージェントベンダーと企業ユーザーは、モデル呼び出しあたりの完了作業量、成功タスクあたりのトークン数、完了あたりの人間による介入回数を報告すべきだ。

これらの指標が改善する一方で総エージェントトラフィックも増加すれば、成長の根拠はより強くなる。導入と成功した自動化が同時に拡大していることを示すためだ。

成功率が横ばいのままトークン使用量だけが増えれば、そのグラフはますます運用上の無駄を表すものになる。その場合、比率の上昇はROIの論拠を強めるのではなく、弱めることになる。

独立したデータセットも信頼性を高める。直接モデルAPI、クラウドプラットフォーム、プライベートデプロイメントのトラフィックは、OpenRouterがより広い市場を反映しているかを示し得る。

現時点での証拠が支持する結論は、拡散した主張よりも限定的だ。エージェントは2026年8月、OpenRouterで観測された人間のトークントラフィックの5倍以上を生成した。

そのトラフィックの大半は、キャッシュされたコンテキストに関わるものとみられる。このコンテキストにもメモリ、ルーティング、慎重な管理が必要だが、同量の新規推論と混同すべきではない。

10倍への移行は予測であり、確立された結果ではない。その重要性は、追加されるトークンが何を達成するかに左右される。

開発者は、各ループに明確な目的、予算、停止条件があるかを検討すべきだ。企業の購入担当者は、消費量を導入の証拠として扱う前に、タスクレベルの証拠を求めるべきである。

もはや有用な問いは、エージェントが人間より多くのトラフィックを生み出すかどうかではない。OpenRouterのデータは、すでにそうなっていることを示唆している。問うべきなのは、次の1兆トークンがより多くの作業を完了させるのか、それとも過去をより多く読み返すだけなのかということだ。