AIエージェントのトラフィックが従来のオートスケーリング設計をすべて無効にする — CPUではなく「ふるまい」でスケールする4層アーキテクチャ

8月18日、Towards Data Scienceが「Three Generations of Autoscaling — And Why Agentic Traffic Breaks All of Them」と題した記事を公開した。AIエージェントが生み出すトラフィックは、オートスケーリング設計の根底にある「トラフィックは人間が生み出す」という前提を7つの軸で同時に崩壊させる。記事はその構造的な破綻を3世代の進化史から解き明かし、対策として取るべき4層のアーキテクチャパターンを詳述している。

「エージェント型トラフィック」が壊すもの

オートスケーリングの歴史を振り返ると、設計の根底には一貫した前提があった。「トラフィックは人間が生み出す」という前提だ。人間のリクエストには日周リズムがある。ピークは予測でき、リトライには限界があり、障害が起きれば人間はそれ以上叩くのをやめる。

AIエージェントはこの前提を7つの軸すべてで同時に破壊する。

3世代のオートスケーリングがそれぞれ失敗する理由

記事の著者はバックエンドエンジニア兼アーキテクトとして、大規模な動画ストリーミング基盤を含む複数のシステムを手がけてきた経験から、スケーリングの進化を3世代に整理している。

第1世代：事前予測（オンデマンドインスタンス）　大規模ライブ配信などでは、スパイクの来る時間帯が分かっていた。EC2フリートを数日前からウォームアップし、ウォールームで監視するというアプローチが通用していた。前提は「スパイクは予測可能」。

第2世代：リアクティブ信頼（サーバーレス）　Lambda・API Gatewayなどの登場で、事前プロビジョニングの会話は消えた。プラットフォームが自動的に反応してくれるから、予測しなくていい。前提は「プラットフォームの反応速度 > 需要の立ち上がり速度」。

第3世代：予測的・MLベースのスケーリング　HPA（Horizontal Pod Autoscaler）のカスタムメトリクスや、Amazon SageMakerの予測スケーリング、あるいはKEDAのようなイベントドリブンなオートスケーラーに代表される世代だ。過去のトラフィックパターンや外部メトリクスを機械学習モデルで分析し、需要が顕在化する前にスケールアウトを開始する。第1世代の「人手による予測」を自動化し、第2世代の「事後反応」の遅延を補う試みとして登場した。しかしエージェント型トラフィックの前では、この世代も崩れる。MLモデルが学習する「過去のパターン」は、スケジュールも規則性も持たないエージェントのオーケストレーションイベントには存在しない。予測の土台となる周期性そのものが欠如しているため、モデルは実質的に機能しない。

なぜ3世代すべてが同時に崩れるか　エージェントは第1世代を崩す（スケジュールがないので事前ウォームアップ不可）。第2世代も崩す（CPUベースのオートスケーリングは遅延シグナルであり、ミリ秒単位の立ち上がりには追いつけない）。第3世代も崩す（学習すべき周期パターンが存在しないため、予測モデルが機能しない）。さらにサーバーレスの場合、暴走したエージェントループのすべての冗長コールを忠実に実行し、その分の請求が来る。3世代の進化が積み上げてきた前提を、エージェント型トラフィックはことごとく無効化する。

4層の対策パターン

4つのLayerはそれぞれ独立した防御線ではなく、上流から下流へとシグナルを渡す連鎖として機能する。Layer 1でループを検知して隔離し、Layer 2でゲートウェイがコストを単位に流量を制御し、Layer 3でキューが瞬間的なスパイクを平滑化し、Layer 4でアドミッション制御が重いセッションを早期に遮断する。各Layerが独立して動くのではなく、前段の判断が後段の負荷を減らす多段構造として設計されている点が核心だ。

Layer 1：ふるまいベースのスケーリング

CPUをトリガーにスケーリングするのをやめるべきだ。リクエストの速度とペイロードの多様性を監視し、エージェントループを検知する。同一CallerIDから短時間に大量の類似リクエストが来ていれば、CPUに反映される前に隔離できる。

class AgentLoopDetector:
    def __init__(self, window_s=10, rate_threshold=50, diversity_threshold=0.2):
        self.window_s = window_s
        self.rate_threshold = rate_threshold
        self.diversity_threshold = diversity_threshold
        self.events = defaultdict(deque)

    def is_looping(self, caller_id: str, payload_hash: str) -> bool:
        now = time.monotonic()
        q = self.events[caller_id]
        q.append((now, payload_hash))
        while q and now - q[0][0] > self.window_s:
            q.popleft()
        rate = len(q)
        if rate < self.rate_threshold:
            return False
        unique = len({h for _, h in q})
        diversity = unique / rate
        return diversity < self.diversity_threshold

10秒間のウィンドウ内でリクエスト速度が閾値を超え、かつペイロードの多様性が20%未満であれば「ループ中」と判定する設計だ。ポイントは「CPUという結果指標」ではなく「ふるまいという先行指標」でスケーリングをトリガーしている点にある。なお、このようなカスタムメトリクスに基づくイベントドリブンなスケーリングには、KEDA（Kubernetes Event-driven Autoscaling）のような外部メトリクス対応のオートスケーラーと組み合わせることで、Kubernetes環境でも同等のふるまいベース制御を実現できる。

Layer 2：AIゲートウェイをショックアブソーバーとして使う

通常のAPIゲートウェイはHTTPリクエスト数をカウントする。AIゲートウェイはトークンや計算コストを単位として各接続を制御し、推論システムへの到達前に予算超過の接続を遮断する。Envoy AIゲートウェイやAzure API Management（AIトークン制限機能）がこのレイヤーの実装例として挙げられる。

特に強力なのがセマンティックキャッシュ（意味的類似度に基づくキャッシュ）だ。URLではなくプロンプトの埋め込み表現の類似度でキャッシュヒットを判定するため、エージェントが繰り返し送る類似クエリをモデルに到達させずに返却できる。ただし、キャッシュが古い回答や不正確な回答を返すリスク、キャッシュキーのスコープ設定を誤ると他ユーザーのレスポンスが漏洩するリスクには注意が必要だと記事では明示している。

Layer 3：非同期キューイング

人間向けAPIはサブ秒応答を要求するが、エージェント向けAPIはそうではない。この違いを活かし、非同期キューに切り替えることでスパイクを平滑化する。キューの深さが高水準ライン（記事例では10,000）を超えたら、HTTP 429を返してバックプレッシャーシグナルを送る。クライアントにこれ以上エンキューするなと伝える仕組みだ。

Layer 4：トークンベースのアドミッション制御

リクエスト数ではなくリソースコストを単位にアドミッション制御する。セッションごとのトークンバケットを持ち、実際に消費したトークン数でデビットする。重い推論チェーンを実行するセッションは早期に遮断しつつ、軽量な呼び出しは影響を受けずに通過できる。

まとめ

記事が提示するフレームワークは「シグナルを上流に移動させる」という一言に集約される。CPUという遅延シグナルではなく、リクエストのふるまいや消費コストという即時シグナルに基づいて制御を行うことが、エージェント型トラフィックに対応する上での核心だ。3世代のオートスケーリングが共通して抱えていた「需要を観測してから反応する」という構造的限界を、4層のアーキテクチャは「需要の予兆をふるまいから読む」という設計思想で乗り越えようとしている。

詳細はThree Generations of Autoscaling — And Why Agentic Traffic Breaks All of Themを参照していただきたい。