AIエージェントの負荷分散は「リクエスト数」だけでは不十分、Googleが注意点を解説

Googleが2026年8月3日、音声会話などをリアルタイムで処理するAIエージェントを安定して運用するための負荷分散で注意すべき点を解説しました。

Scaling real-time AI agents with session-aware load balancing - Google Developers Blog
https://developers.googleblog.com/scaling-real-time-ai-agents-with-session-aware-load-balancing/

一般的なウェブAPIは利用者がリクエストを送り、サーバーが結果を返すと処理が終了します。一方で音声AIエージェントは接続を長時間維持しながら、音声や文字起こし、AIの回答、合成音声などを継続的に送受信します。利用者がAIの発言を遮った場合は音声生成を止め、会話の文脈を更新して回答を作り直す必要もあります。

例えばサーバーAが50ミリ秒で終わるリクエストを100件処理し、サーバーBが20分間続く会話を5件処理している場合、1秒当たりのリクエスト数を示すQPSではサーバーAの方が忙しく見えます。しかし実際にはサーバーBが長時間にわたって、より大きな処理負荷を抱えている可能性があります。

また、サーバーの忙しさをCPU使用率だけで判断するのは危険とのこと。20人が音声AIへ接続していても全員が黙っている間は負荷が低く見えますが、一斉に話し始めれば処理量は急増します。低いCPU使用率だけを見て新しい利用者を割り当てると、サーバーが処理能力を超えるおそれがあります。

GoogleはQPSやCPU使用率に加えて「アクティブなセッション数」を記録する必要があると説明しています。セッションとは利用者とAIエージェントの間で続いている一連の接続や会話です。CPU使用率が目の前の負荷を示すのに対し、セッション数はサーバーが引き受け済みの仕事量を示します。

実際の振り分けではセッション数だけに頼らず、CPUやメモリの使用率も考慮するとのこと。CPU使用率が90％に達したサーバーにはセッション数が少なくても新しい会話を割り当てず、CPU使用率が低くても多数のセッションを抱えているサーバーには新しいセッションを段階的に割り当てます。

QPSとCPU使用率だけで振り分けると、特定のサーバーに長時間の会話が集中し、別のサーバーには空きが残る場合があります。セッション数も考慮すれば、すでに引き受けた会話を把握した上で新しい接続を分配できるため、負荷の偏りを抑えられるというわけです。

セッション数はアプリケーション側で開始時に増やし、終了時に減らします。タイムアウトやキャンセル、切断が重なってもセッション数のカウンターを1回だけ減らす必要があり、終了済みの会話が残る「幽霊セッション」はサーバーを実際より忙しく見せ、負荷分散を誤らせる原因になるとのこと。

また、多数の処理が同じカウンターを一斉に更新すると、セッション数を数える処理自体がボトルネックになる可能性があります。GoogleはJavaの「AtomicInteger」でも多くの処理には対応できるものの、高い並行性が求められる環境では同じメモリアドレスの更新が競合するため、更新先を分散して後から合計する「LongAdder」のような仕組みが適する場合もあると説明しています。

負荷テストでも短いリクエストを大量に送るだけでは不十分です。会話時間や同時接続数、発話と無言の割合、キャンセルや切断の頻度を変え、応答開始までの時間や途中で失われたセッション数、サーバーごとのセッション数の偏りを確認する必要があります。

GoogleはAIエージェントの本番導入が進む中、単発のリクエストではなく、継続中の会話を負荷分散の単位として捉える設計へ移る必要があると述べています。