OpenRouterでは、AIエージェント型のトラフィックが使うトークン量が、人間型の約5倍に達している。米ベンチャーキャピタルAndreessen Horowitz（a16z）が8月21日に紹介したデータでは、エージェント型の利用量は2月から約14倍に増え、その85％超をキャッシュ済みの入力が占めるという。

Futurum GroupのCEO、Daniel Newman氏も9月30日のX投稿で、この比率が今後10倍以上へ広がるとの見方を示した。

ただし、トークン数が5倍だからといって、推論コストや請求額まで5倍になるわけではない。同じ文脈を再利用するキャッシュ済み入力と、新しい入力や出力では料金が異なるためだ。また、大量の文脈を繰り返し扱うエージェントが増えれば、計算だけでなく、その情報を保持して再利用する仕組みも必要になる。

AIエージェントによる需要の拡大を考えるには、処理されるトークン量、実際の請求額、再利用する文脈を支えるメモリやストレージを分けて見る必要がある。

OpenRouterで観測された「約5倍」が意味するもの

a16zの"掲載図" (https://www.a16z.news/p/charts-of-the-week-winds-of-thematic)は、OpenRouter上のトークン利用量を「agentic」「human」「mixed」に分類し、7日移動平均で示している。

8月時点でエージェント型は7.3兆トークン、人間型は約1.4兆トークンとなり、約5倍の差がついた。

ここで重要なのは、この数字が1体のAIエージェントと1人の利用者を同じ仕事で比較した結果ではないことだ。

OpenRouter全体で、エージェント型に分類されたAPI利用によって処理されたトークン量と、人間型に分類された利用のトークン量を比較している。利用者数やエージェント数、1件の仕事を終えるまでの効率を直接示した数字ではない。

また、7.3兆トークンは「直近7日間の合計」ではなく、7日移動平均として示された利用量である。

データを説明したOpenRouterのPeter Walker氏によると、エージェント型のトークン量が人間型を上回ったのは2026年2月6日だった。その後、約半年でエージェント型は14倍に増えた。一方、人間型も同じ期間に2.8倍へ増えている。

つまり、人間によるAI利用が減ったのではない。人間が目標を与えた後、ソフトウェアがモデルを何度も呼び出しながら作業を続ける利用方法が、さらに速いペースで拡大したことを示している。

分類方法にも注意が必要だ。

Walker氏の説明とOpenRouterの"公式解説" (https://openrouter.ai/blog/insights/deepseek-v4-adoption/)によると、ツールの呼び出し頻度、対話のターン数、応答間隔など7つの指標を組み合わせ、APIキー単位でagentic、mixed、humanを判定する。

個々のリクエストを一件ずつ「人間」「エージェント」と判定しているわけではない。同じAPIキーで複数の用途を扱っていれば、そのキー全体の主な行動パターンによって分類される。

したがって「約5倍」から、1人の利用者に対して5体のエージェントが動いているとも、1件の仕事で5倍の計算が必要だとも判断できない。分かるのは、OpenRouterを流れるトークンの構成が、急速にエージェント型へ傾いていることだ。

「85％超」と「約70％」は集計条件が違う

a16zは、エージェント型のトークン利用量の85％超がキャッシュ済みのプロンプトだとしている。一方、Walker氏は、平均的なエージェント型リクエストについて約70％がキャッシュ済みだと説明している。

公開情報だけでは、両者の集計方法を完全には対応付けられない。

公開された説明| キャッシュの割合| 数字が指す対象 a16zの8月21日付記事| 85％超| OpenRouterで観測されたエージェント型トークン利用量 Peter Walker氏の説明| 約70％| 平均的なエージェント型リクエストの総トークン量

出典："a16zの記事" (https://www.a16z.news/p/charts-of-the-week-winds-of-thematic)、"Walker氏の投稿" (https://www.linkedin.com/posts/peterjameswalker_february-6th-2026-potentially-the-last-share-7493029881841344512-IK89/)。

トークン全体を集計した割合と、リクエストごとの平均では、長い文脈を扱う一部の大きなリクエストが結果に与える重みも変わり得る。ただし、それが85％と70％の差の原因だと確認されたわけではない。

どちらか一方を誤りとして扱うより、集計条件の異なる数字として分けて読む方が安全だ。

両者に共通するのは、エージェントでは過去の文脈を繰り返し参照する割合が非常に高いという点である。

例えばコードを修正するエージェントなら、最初に与えられた作業指示やリポジトリの情報、ツール定義、これまでに行った変更を保持しながら、新しいテスト結果を読み、次の処理を決める。

ターンが増えるほど、新しく追加された情報だけでなく、それ以前の文脈も入力の大きな部分を占めるようになる。

ただし、ここでいう「キャッシュ」は、以前の回答をそのまま返す仕組みではない。

OpenRouterには同一リクエストに以前の応答をそのまま返す「Response Caching」も別に存在するが、今回の統計で中心となっているのはPrompt Cachingである。

Prompt Cachingでは、システムプロンプト、ツール定義、過去の会話など、前回までと共通する入力部分を再利用し、新しく加わった情報を含めてモデルが次の出力を生成する。

そのため、「キャッシュ済みトークンが多い」という数字だけから、エージェントが同じ失敗を無意味に繰り返しているとは判断できない。今回のグラフには、作業の成功率や成果物の品質は含まれていない。

トークン量が14倍でも、請求額が14倍とは限らない

OpenRouterが7月21日に公開した"Prompt Cachingの料金解説" (https://openrouter.ai/blog/tutorials/prompt-caching-sticky-routing/)によると、キャッシュから読み出す入力トークンの単価は、提供元によって通常入力の0.1〜0.5倍になる。

エージェントが毎回送る長いシステムプロンプトやツール定義、JSON Schema、作業履歴などを再利用できれば、同じ量の入力を毎回最初から処理するより安くなる。

そのため、同じモデルと料金条件なら、キャッシュ済みトークンの割合が高くなるほど、トークン総量と請求額の伸びは乖離しやすくなる。

ただし、安くなるのはキャッシュから読み出せた部分である。

新しく追加された入力や、モデルが生成する出力には通常の料金がかかる。また、提供元によってはキャッシュを最初に作る「書き込み」に通常入力以上の料金が設定されている。

例えばOpenRouterの説明では、Anthropicの場合、5分保持するキャッシュの書き込みは通常入力の1.25倍、1時間保持する場合は2倍となる。キャッシュを一度作っただけで再利用しなければ、むしろ通常入力より高くなる場合もある。

したがって、a16zの「85％超がキャッシュ済み」という数字を、そのまま「料金を85％削減できる」と読み替えることはできない。

キャッシュが有効になる条件もある。

保持期間が切れたり、キャッシュ対象となるプロンプトの先頭部分が変わったりすれば再利用できない。またOpenRouterのように複数の推論事業者へリクエストを振り分けるサービスでは、前回とは別の提供元に送られれば、その提供元には使えるキャッシュがない場合がある。

OpenRouterはこれを減らすため、Prompt Cachingが使われた後のリクエストを、同じキャッシュを持つ提供元へ優先的に戻す「Sticky Routing」を使っている。

開発者が"session_id"を指定すれば、セッションの最初から同じ提供元へ送られやすくすることもできる。

ただし、その提供元が利用できなくなった場合には別の提供先へフォールバックするため、すべてのリクエストでキャッシュが利用できるとは限らない。

AIエージェントの予算を管理するなら、総トークン数だけでなく、

  • 新しい入力
  • キャッシュから読み出した入力
  • キャッシュの書き込み
  • 出力

を分けて見る必要がある。

そうすれば、トークン量が増えた理由と、実際の支出が増えた理由を切り分けやすくなる。

Prompt CachingとKVキャッシュは同じ数字ではない

大量のキャッシュ済みトークンは、推論インフラのメモリ需要とも関係する。ただし、ここには重要な区別がある。

OpenRouterの統計に表示される「cached tokens」は、APIや料金の観点から、キャッシュを利用して処理された入力トークンを数えたものだ。

一方、LLMを実際に動かす際には、Attentionの計算で得られたKeyとValueを保持して再計算を避けるKVキャッシュが使われる。

Prompt Cachingでは、提供元がこうした計算済み状態を再利用することで処理を減らせる場合がある。ただし、具体的な保存方法はモデルや提供元の実装によって異なる。

したがって、OpenRouterで85％のトークンがキャッシュ済みだったからといって、その85％に対応する情報がそのままGPUのHBMへ保存されているわけではない。

まして、7.3兆トークンという累計的な処理量から、必要なHBM容量を直接計算することもできない。

同じ文脈を何度も参照すれば、キャッシュ済みとして処理されるトークン数は増える。一方、同じ情報を再利用しているのであれば、保存するデータ自体が同じ割合で増え続けるとは限らない。

必要なメモリ量は、

  • 同時に動いているエージェントやセッションの数
  • 各セッションのコンテキスト長
  • モデルのレイヤー数やAttention構造
  • KVキャッシュのデータ型
  • キャッシュを共有・圧縮する仕組み
  • どの程度の期間保持するか

などによって変わる。

HBMだけでは支えきれない長いコンテキスト

エージェント型の処理が長時間続き、大量のコンテキストを同時に保持するようになると、すべてをGPUの高速メモリだけに置くことは難しくなる。

NVIDIAが3月16日に公開した"技術解説" (https://developer.nvidia.com/blog/introducing-nvidia-bluefield-4-powered-inference-context-memory-storage-platform-for-the-next-frontier-of-ai/)では、KVキャッシュなどのコンテキストを、利用頻度や必要な速度に応じて複数の階層へ配置する考え方を示している。

保存階層| NVIDIAが説明する主な役割 GPU HBM（G1）| トークン生成中に直接使う、最も高速なKVキャッシュ システムDRAM（G2）| HBMから退避したKVキャッシュのステージングやバッファ ローカルSSD（G3）| 少し時間を置いて再利用する「warm」なKVキャッシュ 共有ストレージ（G4）| 履歴や成果物など、即座の推論処理から離れた永続的なデータ

GPUに近いほど高速にアクセスできる一方、保存できる容量は限られる。より遠いDRAMやSSD、共有ストレージへ移せば容量を増やせるが、GPUへ戻す際の転送時間が問題になる。

NVIDIAのCMXは、このG3とG4の間に「G3.5」と呼ぶネットワーク接続のフラッシュ層を追加する。

大量のKVキャッシュを保持しながら、再び必要になる情報をGPUやホストメモリへ事前に転送しておくことで、生成処理がデータ待ちで止まる時間を減らす狙いだ。

重要なのは、容量だけを増やせばよいわけではないことだ。

エージェントが必要とする文脈を、次に使う時点までにGPUへ届けられなければ、容量があっても推論処理は待たされる。エージェントの増加は、計算能力だけでなく、コンテキストを保存し、必要な場所へ移動させる能力もインフラの性能要因にする。

ただし、これはNVIDIAが自社のAIインフラ向けに示している設計であり、OpenRouterが同じ構成でキャッシュを保存していることを意味しない。

OpenRouterの利用統計とNVIDIAのインフラ設計を直接結び付けて、必要なHBMやSSDの量を推定することはできない。

それでも、エージェント型AIの拡大を「GPU演算性能だけの需要」と考えられない理由は見えてくる。長く続く処理では、計算する能力と同時に、過去の文脈を効率よく再利用する仕組みが必要になるからだ。

「5倍」が「10倍」になっても、価値が10倍になるとは限らない

Daniel Newman氏は、現在約5倍となっているエージェント型と人間型の利用量の差が、今後10倍、さらにそれ以上へ広がるとの見方を示している。

これはOpenRouterが観測した現在の比率とは異なり、将来についての予測である。到達時期や算定モデルが示された予測ではないため、「10倍になることが確定した」と読むことはできない。

OpenRouterのデータから分かるのは、企業のAI需要を「何人がAIを使っているか」だけで測ることが難しくなっていることだ。

人間がモデルへ1回指示した後、その裏でエージェントが検索し、コードを書き、ツールを実行し、結果を読み、修正し、再びモデルを呼び出せば、人間との対話回数をほとんど増やさずに大量の推論処理が発生する。

同じ100人がAIを使っていても、チャットだけを使う場合と、複数のエージェントを長時間動かす場合では、必要な計算量は大きく違う。

一方、消費したトークンの多さだけでは、その投資が価値を生んだかどうかも判断できない。

10万トークンで仕事を完了したエージェントと、100万トークンを使って途中で失敗したエージェントを、後者の方が需要や価値が大きいとは評価できないからだ。

測るべきなのは「完了した仕事あたり」のコスト

エージェント型AIの利用が増えるほど、企業が見るべき指標も変わる。

単純なトークン単価や利用者1人あたりの月額費用だけではなく、一つの仕事を成功させるために、最終的にいくらかかったのかを見る必要がある。

例えば、

  • 仕事を完了するまでの総トークン量
  • キャッシュ適用後の実際の推論費用
  • 完了までの所要時間
  • 成功率
  • 人間による確認や修正に必要な時間
  • 失敗や再試行に使ったコスト

を合わせて測る。

キャッシュによって大量の文脈を安く再利用できても、何度も失敗して人間が修正していれば効率が良いとは限らない。反対に、トークン量が大きくても、人間が数時間かけていた作業を短時間で確実に終えられるなら、費用に見合う可能性がある。

OpenRouterでエージェント型のトークン量が人間型の約5倍に達したことが示しているのは、AI需要の中心が単純な「人間とAIの会話」だけでは捉えられなくなりつつあることだ。

エージェントが長時間自律して動くほど、モデルの計算能力だけでなく、キャッシュの料金設計、コンテキストを保持するメモリ、保存と転送の仕組みまでがコストを左右する。

その規模が今後さらに拡大するなら、重要になるのは「何トークン使ったか」だけではない。そのトークンで、いくつの仕事を実際に完了できたかである。