常時稼働AI時代、ボトルネックはモデルだけでなく「通信設計」にある

トレンドシグナル

• ITmediaで、常時稼働AIによるトラフィック急増対策が報道。
• Cloudflareの技術記事では、PMTUやQUIC経路品質の重要性が継続的に提示。
• HNでも「モデル性能より通信経路が遅延要因」という実運用報告が増加。

何が従来と違うか

従来のWebトラフィックはピークが比較的読みやすい一方、常時稼働AIは次の特性を持ちます。

• セッションが長く、1操作あたりの処理連鎖が多い
• ストリーミング応答で、テール遅延が体感品質に直結
• RAG・ツール呼び出し・ポリシーチェックで内部通信が増幅
• クライアント経路品質の差がそのままUX格差になる

3層ボトルネックモデル

1) クライアント〜エッジ

MTU不一致、再送増、経路劣化で、見えにくい遅延が蓄積。

2) 内部サービス間通信

ツール連携増加でeast-west通信が急拡大。CRUD前提のタイムアウト設計が破綻。

3) 推論ランタイム

ソフトサチュレーション時はキュー遅延が支配。利用率だけ見ても実態を見誤る。

今すぐ導入すべき運用制御

AI専用SLO

• First token遅延（P95）
• ストリーム中断率
• ツール連鎖完了時間
• 検索失敗時のフォールバック率

トラフィッククラス

• 低遅延優先（対話）
• 標準対話
• 後回し可能なバッチ推論

混雑時はクラス別受け入れ制御で重要UXを防衛する。

劣化設計（Graceful degradation）

• まず検索幅を絞る
• 次にツール連鎖を簡略化
• 最終的に短文モードへ

いきなり品質を落とすのではなく、段階的に性能を守る。

容量計画の実務

1. エンドポイント単位ではなく業務フロー単位で負荷見積もり。
2. 月末・障害時の急増を前提に試験。
3. パケット損失・ジッタ・PMTU不一致を含むカオステスト。
4. 推論系と検索系の独立フェイルオーバーを検証。

まとめ

常時稼働AIは「LLM運用」だけの課題ではありません。LLMトラフィック工学として、ネットワーク・SRE・ML運用の合同設計を持つチームが、遅延とコストを同時に制御できます。