# エージェント基盤のバックプレッシャーとロードシェディング設計

> AIエージェント基盤の過負荷対策は、キューによるバックプレッシャーと優先度別ロードシェディングの組み合わせで設計します。Claude APIのretry-afterとPriority Tierを使った実装パターンを解説します。

- Canonical: https://kuucorp.com/blog/agent-backpressure-load-shedding-design/
- Date: 2026-08-24
- Last modified: 2026-08-24
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
マルチエージェント構成が一斉にツール呼び出しをファンアウトすると、LLM APIへのリクエストが数秒で数百件に膨れ上がる。429エラーが返ってきた瞬間、各ワーカーが個別にリトライを始めれば負荷はさらに増幅し、キュー深度は際限なく伸びていく。エンタープライズのエージェント基盤には、負荷を上流で吸収するバックプレッシャーと、限界を超えたときに低優先度の処理から間引くロードシェディングの両方が要る。

## バックプレッシャーとロードシェディングは何が違うのか

> バックプレッシャーは処理速度に合わせて上流の流入を抑える仕組みで、ロードシェディングは過負荷時に低優先度の処理を意図的に切り捨てる仕組みだ。

両者は補完関係にある。バックプレッシャーはキューを挟んで生産者（エージェントの呼び出し元）と消費者（LLM API・ツール実行系）を疎結合にし、消費者のペースで処理させる。だがバックプレッシャーだけでは、生産速度が消費速度を恒常的に上回る場合にキューが際限なく伸び、レイテンシが悪化し続ける。Microsoft Learnのアーキテクチャパターン集は、平均生産レートが消費レートを超え続けるならキュー深度を監視してスケールするか、生産者側で処理を間引く（shed work at the producer）べきだと明記している。ロードシェディングは、この「間引き」を優先度に基づいて意図的に行う設計だ。

## キューベースのロードレベリング設計

> タスクとサービスの間にキューを挟み、消費者のペースで処理させることで、突発的な負荷ピークを平準化できる。

エージェントのツール呼び出しやLLM APIコールを直接同期実行せず、キューを介した非同期実行に切り替える。この構成にはいくつかの実装上の前提がある。

- **at-least-once配信を前提にする**: 多くのキューサービスはメッセージを重複配信しうる。ツール実行側を冪等に設計しないと、同一操作が二重に走る
- **デッドレターキューを用意する**: 不正なペイロードや永続的エラーで処理できないメッセージは、通常キューを塞がずデッドレターキューに退避し、監視対象にする
- **順序保証は必須要件のときだけ導入する**: 並列消費者を使う構成では到着順は保証されない。厳密な順序が必要なタスクにはメッセージセッション等の追加機構が要る

キュー深度とコンシューマーのスケール台数はセットで監視する。オートスケーリングでコンシューマーだけを増やしても、下流の共有リソース（DB・外部API）への負荷が移動するだけで、ボトルネックが後段にずれるだけになる。

## 優先度別ロードシェディングの設計

> 過負荷時はP0（ユーザー応答・安全チェック）を死守し、P1・P2の補助的処理から段階的に間引く設計が実務的だ。

すべてのリクエストを均等に扱うと、優先度の低いバッチ処理が優先度の高いユーザー対話をブロックする。処理を優先度階層に分け、キュー深度やレイテンシがしきい値を超えたら下位階層から間引く設計が有効だ。

1. **P0（常に処理）**: ユーザー向け同期応答、安全性チェック
2. **P1（高負荷時に間引く）**: 要約・エンリッチメントなどの補助ステップ
3. **P2（積極的に間引く）**: 装飾的な後処理、優先度の低いバッチジョブ

Claude APIはこの優先度分離を仕組みとして提供している。レスポンスヘッダーには標準の`anthropic-ratelimit-*`に加え、Priority Tier契約時のみ`anthropic-priority-input-tokens-remaining`等が返り、429時には`retry-after`ヘッダーで再試行までの待機秒数が明示される。エージェント基盤側は、この`retry-after`をバックオフの起点にしつつ、429を受けたリクエストの優先度がP1/P2であればリトライせず即座に間引く、といった判断をゲートウェイ層に実装できる。

## 実装・運用のポイント

> 生産者側での間引きと、[サーキットブレーカー](/blog/agent-graceful-degradation-circuit-breaker/)・[冪等性設計](/blog/agent-idempotency-at-least-once-design/)を組み合わせて多層防御にする。

バックプレッシャーとロードシェディングは単体では機能しない。キューが飽和する前に生産者側でP2トラフィックを絞る、LLM APIそのものが不安定ならサーキットブレーカーで遮断する、リトライが二重実行を生まないよう冪等性キーを併用する——という3層で設計して初めて、過負荷時にも中核機能を守れる基盤になる。監視面では、キュー深度・消費レート・シェディング発生率をダッシュボード化し、P1/P2がどの頻度で間引かれているかを可視化しておくと、キャパシティプランニングの判断材料になる。

エンタープライズ規模のエージェント基盤でバックプレッシャー・ロードシェディングの設計を支援する場合は、[Kuu株式会社のRDEサービス](/services/rde/)にご相談ください。

## 参考

- [Queue-Based Load Leveling Pattern — Azure Architecture Center, Microsoft Learn](https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling)
- [Rate limits — Claude Platform Docs](https://platform.claude.com/docs/en/api/rate-limits)
- [Building Effective AI Agents — Anthropic](https://www.anthropic.com/engineering/building-effective-agents)

## まとめ

エージェント基盤の過負荷対策は、キューによるバックプレッシャーで生産者と消費者を疎結合にし、優先度別ロードシェディングでP0を守りながらP1/P2を間引くという二段構えで設計する。Claude APIの`retry-after`ヘッダーとPriority Tierは、この優先度判断をゲートウェイ層に実装するための具体的な足がかりになる。サーキットブレーカー・冪等性設計と組み合わせた多層防御が、本番品質のエージェント基盤には欠かせない。

大規模なエージェント基盤の設計・実装を検討している場合は、[Kuu株式会社のRDEサービス](/services/rde/)にご相談ください。