AIエージェントは、知能の壁にぶつかる前にインフラの壁にぶつかる

モデルの進化は、求められる処理を提供する能力の進化を上回る速さで進んでいる。

AIエージェントの今後をめぐる議論の大半は、その能力に関するものだ。モデルは確実に計画を立てられるのか。自らの誤りから立ち直れるのか。結果を伴う行動を任せても信頼できるのか。

いずれも現実的な問いだ。しかし、今後数年間にエージェントが大規模に導入されるかどうかを左右するのは、これらの問いではない。もっと差し迫った制約があり、その到来はより早いからだ。エージェントの運用には経済面で難しさがあり、その難しさは、誰もが追加したいと考えている機能が増えるほど大きくなる。

チャットボットとエージェントでは処理の性質が異なる

対話型のリクエストは1往復で完結する。プロンプトを送り、トークンが返ってきて、接続が切れる。バッチ処理やプレフィックスのキャッシュが可能で、スループットも単一の数値で評価できる。

エージェントへのリクエストはセッションとして進む。ツールを呼び出して応答を待ち、結果を読み、次の行動を決め、別のツールを呼び出し、最終的に回答する。簡単なタスクでも、待ち時間を挟みながらモデルを6回または8回呼び出すことがある。

この違いが重要なのは、知能とは無関係な理由による。ステップの合間、エージェントは会話、ツールの出力、そこまでに積み上げた推論といった状態を保持している。推論の提供側では、この状態はGPUメモリ上のKVキャッシュとして保持され、セッションが続く間ずっとメモリを占有する。その時間には、エージェントが自分たちの運営するものではないAPIの応答を待つ秒数も含まれる。

そのため、処理能力を測る単位は「1秒あたりのリクエスト数」から「メモリ上に常駐する同時実行セッション数」へと変わる。対話型のリクエストを毎秒1,000件、余裕をもって処理できるシステムでも、同じハードウェアで処理できるエージェントの同時実行セッション数は数十件程度かもしれない。

待ち時間こそがコストを押し上げる

厄介なのは次の点だ。ツールを呼び出している間、エージェントは何もしていない。トークンは生成されず、計算資源も消費されない。しかしGPUメモリは占有されたままだ。コンテキストを退避して再計算するコストは、保持し続けるコストを上回るためだ。

最も高価なハードウェアが、その時点ではデータベースのクエリを待っているだけのリクエストに割り当てられている。

従来の分散システムでは、ずっと前にこの問題を解決している。リソースを解放し、応答が届いたら処理を再開すればよい。モデルの推論提供で同じことをするには、KVキャッシュをホストメモリやディスクに退避させ、後で復元する必要がある。しかし転送コストが十分に高いため、ほとんどのシステムはそこまでしていない。まさにこの問題に関する研究は現在も進められている。問題のコストが大きいからこそ、研究が活発なのだ。

逐次実行は、本来必要な以上に状況を悪化させる

ほぼすべてのエージェントフレームワークは、ツール呼び出しを一つずつ順番に実行する。モデルが天気を調べるよう求め、その結果を受け取り、次にカレンダーを確認するよう求め、その結果を受け取り、さらに航空便を検索するよう求め、その結果を受け取る。

この3つの呼び出しは、互いに依存していないことが多い。その場合、同時に実行できる。逐次実行では、レイテンシは各処理の合計になる。並行して実行すれば、最も時間のかかる処理の長さで済む。

これはエージェントに特有の新しい指摘ではない。レイテンシの予算内で複数のモデルやサービスを動かすすべてのシステムに当てはまる、同じ構造上の問題だ。合計レイテンシは、各段階の時間をすべて足したものではなく、依存関係グラフ上の最長経路で決まるべきだ。この問題がエージェントでより重要なのは、セッションが全期間にわたってGPUメモリに常駐するためだ。つまり、実時間を短縮すれば、ユーザー体験が向上するだけでなく、同じハードウェアに収容できるセッション数も直接増える。

セッションの所要時間を半分にすれば、モデルを変更せず、同じGPUで、同時処理能力をおよそ2倍にできる。

誰も意図していない形でリトライが重なる

エージェントフレームワークは、その下層で使われるHTTPライブラリのリトライ設定を引き継いでいる。通常は3回の試行だ。

モデルもまた、独自の形でリトライする。ツールから役に立たない結果が返ってくると、推論モデルは別の方法を試すことが多い。これもリトライだが、誰も設定していない。

これらが重なると、3回の試行を行うポリシーのもとで、モデルが独自に推論してさらに3つの方法を試す場合、誰も明文化していない9回の試行が生じる。それぞれの試行でモデルが完全に1回呼び出され、個別にトークンとGPU稼働時間が消費される。

依存先の応答が遅くなると、この増幅によって性能低下が障害へと発展する。しかも、試行1回あたりのコストは、REST呼び出しをリトライする場合を桁違いに上回る。

実際に立ちはだかる壁とは

能力の限界ではない。もっとありふれた問題、つまり、パイロット運用から本番運用へ移る段階でプロジェクトを止めてしまう単位経済性の問題だ。

パイロット運用はうまくいく。ユーザーは10人で、レイテンシも許容範囲内、請求額も誤差のようなものだ。ところが、ユーザーが10,000人になった場合を試算すると、必要なGPUの数は現実的ではない。モデルが遅いからではなく、同時実行中の各セッションが存続する全期間にわたってメモリを占有し、その期間には待ち時間も含まれるからだ。

有望な社内デモの多くが、ひそかに行き詰まるのはこの段階だ。

壁を動かす要因

目新しいものは何もない。いずれもモデリングではなく、インフラに関するものだ。

独立したツール呼び出しを並行して実行する。 今日すぐに実現でき、新たなハードウェアも不要で、単独の施策としては最も大きな効果が見込める。

セッションの継続時間を容量の指標にする。 トークン毎秒でも、GPU使用率でもない。状態がメモリー上に保持される時間と、収容できるセッション数だ。

リトライの予算は呼び出しごとではなく、システム全体で配分する。 全体の上限を設け、リトライを総トラフィックに対する小さな割合に抑えれば、前述のような連鎖的な増加を防げる。GoogleのSREにおける過負荷への対処と、Envoyのリトライ予算は、いずれもAIスタックの外側でこの考え方を実践している。

推論と実行を分ける。計画には大規模モデルを使い、機械的な手順にははるかに小さなモデルを使う。エージェントの処理の大半に、最先端モデルは必要ない。

コンテキストの退避を低コストにする。量子化KVキャッシュ、ページドアテンション、アイドル状態のセッション向けのオフロード経路を活用する。今、サービング分野で最も興味深い取り組みが進んでいるのはここだ。

モデルは今後も改善し続けるだろう。この点は確かな見通しだ。エージェントがインフラになるのか、デモにとどまるのかは、もっと地味な課題にかかっている。処理を待つ間も高価なメモリーを占有するワークロードを提供できるかどうか、そして、最長経路分のコストで済むのに、処理列全体のコストを払い続ける状況をなくせるかどうかだ。

この最後の点の基盤となる実行モデル、すなわち単一のレイテンシ予算内で依存関係のあるモデル呼び出しを並行実行する手法については、「機械学習システムにおけるモデルルーティングのための非同期推論グラフ実行」として、International Journal of Computer Trends and Technology 72(10)、2024年10月に発表した。特に、レイテンシ制約のある意思決定システムへの生成モデルの統合については、「LLMを活用した取引・意思決定プラットフォーム：生成AIと金融意思決定システムの橋渡し」を参照されたい。掲載誌はJournal of Information Systems Engineering and Management 11(1s)、2026年だ。