Google Developersは2026年8月3日、サイト信頼性エンジニアのシメラス・マヘシュ(Simerus Mahesh)によるガイドを公開し、リアルタイムAIエージェントにはリクエスト処理量やCPU使用率だけに基づくルーティングではなく、セッション対応の負荷分散が必要だと説明した。標準的なWeb APIは短いリクエスト・レスポンスの周期で動くことが多い一方、リアルタイムAIシステムは音声チャンク、文字起こし、モデル出力、合成音声の継続的な双方向ストリームを扱う。ユーザーが割り込むと、サーバーは接続を落とさずに音声生成を止め、文脈を更新し、必要なら新しいツールを起動し、別の応答を組み立てなければならない。

ガイドによると、QPS（1秒あたりのクエリ数）は長時間続くAI会話が生む負荷を捉えられない。Googleは、50ミリ秒で終わる短いリクエストを100件処理するTask Aと、各リクエストが20分のセッションになる5件を受け付けるTask Bを対比した。リクエスト率だけならTask Bは軽く見えるが、実際にはより重い確定済みワークロードを抱える可能性がある。CPU使用率も誤解を招く。音声ランタイムが20の無音セッションを抱えていても低負荷に見え、その20人が同時に話し始めると急上昇する場合がある。Googleは、リアルタイムAIのルーティングにはCPUまたはメモリ使用率とアクティブセッション数の両方が必要だとしている。

リアルタイムエージェントは、双方向ストリーミングプロトコル（双方向のライブデータ接続）であるgRPCやWebSocketを使うことが多い。ネットワーク層には開いた接続しか見えない場合でも、アプリケーション実行環境は音声バッファ、部分的な文字起こし、実行中のツール呼び出し、モデルの文脈、ユーザー別メトリクスを保持している可能性がある。汎用的な接続メトリクスでは、アクティブな会話、待機中のリスナー、リトライ、ヘルスチェックを区別できないため、バックエンドサービスはセッションがアクティブ、失敗、完了、キャンセルのどれかを報告する必要がある。

GoogleはKotlinのパターンとして、ストリーム開始時にアクティブセッションのカウンターを増やし、処理を20.minutesのタイムアウトで包み、ストリーム終了時にfinallyブロックでカウンターを減らす方法を示した。ガイドは、減算漏れがあると処理終了後もバックエンドが過負荷に見える「ghost sessions」が生じ、二重減算は空き容量を偽って示し、過剰なトラフィックを呼び込む可能性があると警告した。ロードバランサーは一定間隔でメトリクスを取得する一方、セッションは継続的に開始・停止するため、サービスにはアクティブセッションの一貫したスナップショットも必要になる。

remaining_capacity = max_sessions - active_sessionsという単純な容量式は、すべての生成AIセッションが同じCPUコストを持つと仮定するため脆弱だとガイドは述べている。Googleは、セッション数をレートに正規化し、使用率と組み合わせるハイブリッドモデルを推奨した。たとえば、10秒の報告ウィンドウで90のアクティブセッションがある場合、9の「仮想QPS」として扱える。そのうえでフィードバックモデルは、80% CPUのようなTarget Utilization、直近10秒のAverage Utilization、Cost Per Session、2.0のようなSafety Scalerを使ってAdditional_Session_Rateを推定できる。

このハイブリッド手法なら、10のアクティブセッションと90% CPUを抱えるバックエンドへの新規トラフィックを止める一方、80のアクティブセッションと40% CPUのバックエンドには新しいセッションを段階的に流せるとGoogleは説明した。Googleは、同時セッション数、セッション継続時間、到着パターン、アイドル状態から発話状態への比率、キャンセル率と切断率、バックエンド数、バックエンドごとの最大セッション数を変えるベンチマークも推奨している。追跡すべき指標として、アクティブセッション分布、過負荷割り当て率、p95とp99の起動レイテンシ、time-to-first-stream、ドロップしたセッション、強制切断後のカウンター挙動を挙げた。

Googleは、すべてのストリーム開始と終了がセッショントラッカーに触れるため、トラッカーは低オーバーヘッドでなければならないと述べた。JVMサービスについては、JIT最適化、JVMウォームアップ、デッドコード除去を考慮したマイクロベンチマークを推奨し、単一スレッドのレイテンシだけを測るよりも競合テストが重要だとしている。AtomicIntegerは多くのワークロードで機能する可能性があるが、高並行性ではキャッシュライン競合に悩まされることがある。シャーディングされたカウンターやLongAdder型の集約は、スループットをより保ちやすい場合がある。音声、動画、ワールドモデルのエージェントには、QPS、CPU圧力、アクティブセッション数を組み合わせたルーティング戦略が必要だ、という結論である。

Google Developersは2026年8月3日、サイト信頼性エンジニアのシメラス・マヘシュ(Simerus Mahesh)によるガイドを公開し、リアルタイムAIエージェントにはリクエスト処理量やCPU使用率だけに基づくルーティングではなく、セッション対応の負荷分散が必要だと説明した。標準的なWeb APIは短いリクエスト・レスポンスの周期で動くことが多い一方、リアルタイムAIシステムは音声チャンク、文字起こし、モデル出力、合成音声の継続的な双方向ストリームを扱う。ユーザーが割り込むと、サーバーは接続を落とさずに音声生成を止め、文脈を更新し、必要なら新しいツールを起動し、別の応答を組み立てなければならない。

ガイドによると、QPS（1秒あたりのクエリ数）は長時間続くAI会話が生む負荷を捉えられない。Googleは、50ミリ秒で終わる短いリクエストを100件処理するTask Aと、各リクエストが20分のセッションになる5件を受け付けるTask Bを対比した。リクエスト率だけならTask Bは軽く見えるが、実際にはより重い確定済みワークロードを抱える可能性がある。CPU使用率も誤解を招く。音声ランタイムが20の無音セッションを抱えていても低負荷に見え、その20人が同時に話し始めると急上昇する場合がある。Googleは、リアルタイムAIのルーティングにはCPUまたはメモリ使用率とアクティブセッション数の両方が必要だとしている。

リアルタイムエージェントは、双方向ストリーミングプロトコル（双方向のライブデータ接続）であるgRPCやWebSocketを使うことが多い。ネットワーク層には開いた接続しか見えない場合でも、アプリケーション実行環境は音声バッファ、部分的な文字起こし、実行中のツール呼び出し、モデルの文脈、ユーザー別メトリクスを保持している可能性がある。汎用的な接続メトリクスでは、アクティブな会話、待機中のリスナー、リトライ、ヘルスチェックを区別できないため、バックエンドサービスはセッションがアクティブ、失敗、完了、キャンセルのどれかを報告する必要がある。

GoogleはKotlinのパターンとして、ストリーム開始時にアクティブセッションのカウンターを増やし、処理を20.minutesのタイムアウトで包み、ストリーム終了時にfinallyブロックでカウンターを減らす方法を示した。ガイドは、減算漏れがあると処理終了後もバックエンドが過負荷に見える「ghost sessions」が生じ、二重減算は空き容量を偽って示し、過剰なトラフィックを呼び込む可能性があると警告した。ロードバランサーは一定間隔でメトリクスを取得する一方、セッションは継続的に開始・停止するため、サービスにはアクティブセッションの一貫したスナップショットも必要になる。

remaining_capacity = max_sessions - active_sessionsという単純な容量式は、すべての生成AIセッションが同じCPUコストを持つと仮定するため脆弱だとガイドは述べている。Googleは、セッション数をレートに正規化し、使用率と組み合わせるハイブリッドモデルを推奨した。たとえば、10秒の報告ウィンドウで90のアクティブセッションがある場合、9の「仮想QPS」として扱える。そのうえでフィードバックモデルは、80% CPUのようなTarget Utilization、直近10秒のAverage Utilization、Cost Per Session、2.0のようなSafety Scalerを使ってAdditional_Session_Rateを推定できる。

このハイブリッド手法なら、10のアクティブセッションと90% CPUを抱えるバックエンドへの新規トラフィックを止める一方、80のアクティブセッションと40% CPUのバックエンドには新しいセッションを段階的に流せるとGoogleは説明した。Googleは、同時セッション数、セッション継続時間、到着パターン、アイドル状態から発話状態への比率、キャンセル率と切断率、バックエンド数、バックエンドごとの最大セッション数を変えるベンチマークも推奨している。追跡すべき指標として、アクティブセッション分布、過負荷割り当て率、p95とp99の起動レイテンシ、time-to-first-stream、ドロップしたセッション、強制切断後のカウンター挙動を挙げた。

Googleは、すべてのストリーム開始と終了がセッショントラッカーに触れるため、トラッカーは低オーバーヘッドでなければならないと述べた。JVMサービスについては、JIT最適化、JVMウォームアップ、デッドコード除去を考慮したマイクロベンチマークを推奨し、単一スレッドのレイテンシだけを測るよりも競合テストが重要だとしている。AtomicIntegerは多くのワークロードで機能する可能性があるが、高並行性ではキャッシュライン競合に悩まされることがある。シャーディングされたカウンターやLongAdder型の集約は、スループットをより保ちやすい場合がある。音声、動画、ワールドモデルのエージェントには、QPS、CPU圧力、アクティブセッション数を組み合わせたルーティング戦略が必要だ、という結論である。