再試行 Budget／Backoff／失敗時の代替処理 Correctness

Retryは各layerの「最大N回」ではなく、original user/workflow requestに対するend-to-end budgetとして管理します。budgetにはtotal downstream attemptsだけでなく、wall-clock deadline、token/compute/API cost、side-effect riskを含めます。

SDK、orchestrator、service、tool clientがそれぞれ自動retryを持つ場合、全layerで独立にretryしません。Amazonの分散システム運用例では、5層のcall stackで各layerが3 attemptsを行うと、最下流databaseへのloadが最大243倍に増幅し得ます。retry ownerを一つまたは明示的に調整された少数layerへ固定し、original request IDでtotal attemptsを数えます。

同じrequestを再送すれば成功する可能性があるtransient failureだけをretry候補にします。429、408、5xx、network errorは候補ですが、status codeだけで無条件にretryしません。provider/product guidance、Retry-After、quota、operation semantics、残deadlineを確認します。invalid credential、schema invalid、unsupported operation、明示的policy denial等を同じ入力でblind retryしません。

retry間隔はbounded exponential backoffを基本とし、jitterで同期再試行を分散します。backoffだけでは十分ではありません。最大attempt、最大backoff、end-to-end deadlineをcapし、deadline内に意味のあるresponseを返せないretryを開始しません。

GenAI SDKやcloud client libraryには既定の自動retryが存在する場合があります。2026-10-05時点のGoogle Gemini Enterprise Agent Platform documentationでは、Gen AI SDK clientがtransient timeout/network/429/5xxにexponential-backoff retryを持ち、Python例では最大4 retries、初期待機約1秒、最大約60秒と説明されています。この既定値を全SDK/versionへ一般化せず、実際のclient/version/configurationをinventoryします。上位orchestratorのretryと二重化しないようtotal budgetへ算入します。

retry安全性はoperation固有です。Google Cloud Storageでは一部mutationがgeneration/metageneration preconditionを付けた場合にconditionally idempotentになります。client libraryごとにretry defaultも異なります。「cloud APIだからretry可能」と一般化せず、operationごとのidempotency、precondition、request tokenを固定します。

timeoutやconnection lossはremote operationが実行されなかった証明ではありません。payment、email、ticket update、resource creation等ではstable idempotency/operation keyを維持し、authoritative status APIまたはresource readbackで既済みか確認します。remote commit後response lossの可能性がある状態をblind retryしません。

fallback responseが返ったことをavailability successと同義にしません。別model、別provider、cache、retrieval-off、tool-less responseでは、freshness、quality、tool capability、structured-output contract、policy、data residencyが変わり得ます。fallback routeには最低限、required capability、freshness bound、policy/data classification、residency、output contract、残deadlineをpreconditionとして持たせます。条件を満たさないfallbackは、エラーを隠す代替成功経路として使いません。

retry/fallbackをoriginal requestの残deadlineと残cost budgetに従わせます。attemptごとにdeadline remainingとtoken/API costを更新し、成功確率があってもuser-visible deadlineを超えるretryやfallbackは開始しません。background recoveryが必要ならinteractive requestとは別workflowへ切り離します。

original request IDに対してtotal attempts、retry layer/owner、provider/model/tool、error class/status、backoff、deadline remaining、token/API cost、idempotency/operation key、authoritative readback、fallback route、final dispositionを記録します。retry amplification ratio、deadline exhaustion、cost amplification、fallback rate/quality、duplicate-side-effect incidentを監視します。

nested SDK/orchestrator retry、retry storm、synchronized retry、cap plateau、Retry-After無視、quota exhaustion、invalid request retry、deadline overrun、token/cost amplification、timeout-after-commit、duplicate side effect、idempotency key loss、precondition omission、stale/low-capability fallback、policy/residency mismatch、fallback loop、telemetry gap、cancellation raceを想定します。

本項は2026-10-05時点のAmazon Builders' Library、Google Cloud Storage retry documentation、Gemini Enterprise Agent Platform retry documentationとbounded local fixtureに基づきます。production provider/tool mutationやoutage injectionは未実施です。

Retryは各layerの回数設定ではなく、original requestに対するend-to-end attempt/deadline/cost budgetとして管理してください。Backoffとjitterはretry集中を緩和しますが、nested retry、non-idempotent side effect、deadline超過を自動的には防ぎません。SDKの自動retryを含むretry ownerを明示し、ambiguous side effectはreadback/reconciliationし、fallbackはcapability・freshness・policy・residencyを満たす場合だけ成功経路として扱います。

対象Agent runtime、provider/model/tool、SDK version/default retry、orchestrator retry、Retry-After処理、retry/deadline/token/cost budget、side-effect idempotency/status API、fallback route/capability、residency/policy、SLO、production failure distributionは未確認です。

nested retry amplification、provider-specific idempotency、SDK auto-retry、deadline/cost budget、fallback semantic correctnessを監査可能な運用境界として固定します。