再試行 Storm / Circuit Breaker / Nested 再試行 Budget Composition

AIエージェントやワークフローでは、単一の「再試行回数」だけを見ても実際の外部呼び出し回数は制御できません。オーケストレータ、durable execution、エージェント実行系、provider SDK、HTTP transport、gateway、fallback、tool、output validationなどが独立して再試行すると、各層の試行回数が乗算され、障害中の下流サービスへ負荷を集中させる retry storm が発生します。本項の運用原則は、再試行を層別に棚卸しし、観測可能な各層について明示的なownerと有限budgetを定め、重複する自動再試行を可能な範囲で無効化し、実際のattempt identityを記録することです。

AWS Builders’ Libraryは、複数階層でそれぞれ再試行すると下流負荷が乗算されることを説明し、backoffとjitter、再試行箇所の制御を推奨しています。Google SREのoverload/retry guidanceも、障害時の再試行が負荷を増幅し、回復を遅らせ得ることを扱います。AzureのRetry StormおよびCircuit Breakerパターンも、失敗中の依存先へ無制限に要求を送り続けない設計を要求します。したがって「agent側のrequest_limitが3だから最大3回」という推論は、下位SDKやtransport、gatewayが追加attemptを生成する構成では成立しません。

• Nested retry amplification: durable engineが1 stepを再実行し、その各step内でSDK/transportが複数回retryすることでwire callが乗算されます。
• Retry ownership ambiguity: orchestrator、agent runtime、SDK、gatewayのどこが再試行責任を持つか不明確で、複数層が同じ障害へ反応します。
• Circuit breaker bypass: 上位層のbreakerが開いても、既に開始済みの下位retryや別経路fallbackが継続する場合があります。
• Hidden fallback/routing: gatewayやprovider内部のrouting/fallbackは、agentから観測できるrequest数と一致しない場合があります。
• Durable replay ambiguity: durable workflowの再実行では、前回attemptが外部効果を残したか不明なまま次attemptへ進むと、retry stormだけでなく重複副作用も生じます。
• Hedging/speculation: latency低減のための並列・投機要求はretryとは別機構でも、下流attempt budgetを消費します。

・Retry domain inventory: orchestrator/durable engine、agent runtime、model/provider SDK、HTTP transport、gateway/router、fallback、tool、output validation、hedgingを別々のdomainとして列挙します。 ・Single explicit owner per observable layer: 同一障害を複数層が無制御にretryしないよう、どの層が再試行するかを明示します。durable step retryを採用する場合、provider SDKやtransport retryを無効化または最小化できる構成ではそうします。 ・Finite budgets: attempts、elapsed time、deadline、concurrency、downstream request rateを有限値として設定します。無期限retryを既定値のまま残しません。 ・Worst-case envelope: 観測可能な層について、上位attempt × 下位retry × fallback候補 × hedged copies の最大包絡を設計時に計算します。ただしprovider内部attemptを観測できない場合、その値を推測で加算せずUNKNOWNとして扱います。 ・Backoff + jitter: 一斉再試行を避けるため指数backoff等とjitterを使い、deadlineを超える再試行を止めます。 ・Circuit breaker / load shedding: 下流障害率やlatencyが閾値を超えた場合、短時間に新規attemptを増幅させず、fail-fast、queue/backpressure、degraded modeへ移します。breakerはretry budgetの代替ではなく併用する制御です。 ・Attempt identity and telemetry: logical operation IDと各層のattempt IDを分け、どの層が何回呼んだかを観測可能な範囲で記録します。agent-visible response countだけをwire-call countとして扱いません。 ・Side-effect boundary: 非冪等な外部効果は、retry budgetとは別にidempotency/reconciliationを必要とします。timeoutを単純FAILEDとみなして再試行せず、外部状態を確認できる場合は先にreconcileします。

この設計は、LLM API、tool/API invocation、durable workflow、gateway経由のprovider routing、複数model fallbackなど、複数の自動再試行層が重なる系に適用します。単一同期呼び出しでretryが完全に一箇所へ集約されている系では管理対象は減りますが、SDK既定retryやproxy/gateway挙動は確認が必要です。

「再試行は常に一層だけにする」という普遍則ではありません。異なるfailure domainに対して別層のretryが合理的な場合があります。重要なのは、各層の責任・上限・相互作用を明示し、総attempt envelopeを制御することです。また、provider内部routingやretryが公開されない場合、外部からexact attempt countを保証できません。Circuit breakerも既に飛行中の要求を必ず取り消すものではなく、全providerで同一の永続化・分散整合性を持つとは限りません。

・provider内部retry/routing/fallbackのexact attempt accounting（非公開部分）。 ・breaker stateの永続化、partition時の挙動、複数worker間共有の製品別差異。 ・hedged/speculative requestを含むend-to-end budgetの製品別実装。 ・version-pinned Pydantic AI + durable execution等での独立したwire-call実測fixture。 ・provider gatewayを跨ぐ場合の内部attemptと課金/レート制限カウンタの対応。

「agentのrequest_limitだけでproviderへの総attempt数が保証される」とは表現しません。「retryを完全に排除すべき」とも表現しません。公開可能な主張は、複数層のretryは負荷を増幅し得るため、retry domainを列挙し、観測可能な層ごとにownerと有限budgetを定め、重複retryを抑制し、backoff/jitter、breaker/backpressure、attempt telemetryを組み合わせる、という範囲です。provider内部の非公開attempt数やexactly-onceを保証しません。

Source / provenance locator ・Amazon Builders’ Library — Timeouts, retries, and backoff with jitter（登録済みprovenance） ・Google SRE / SRE Workbook — retry amplification, handling overload, Niantic incident（登録済みprovenance） ・Microsoft Azure Architecture Center — Retry Storm pattern / Circuit Breaker pattern（登録済みprovenance） ・AWS SDK retry behavior（登録済みprovenance） ・Pydantic AI current Retries / Durable Execution / Tool Execution documentation（2026-10-16確認記録） ・EA_Research_Continuation_Log / EA-505 bounded refresh records（発展拡張統合管理台帳にlocator記録済み）

主要claimは上記登録済み一次資料・継続調査記録へ追跡可能です。製品内部attempt数、独立fixture、breakerの分散永続性は未確認として本文で限定しました。READY、AUDIT_PASS、GIT_INTEGRATED、ACCEPTEDは本candidateでは自己判定しません。