Dead Letter Queue／Poison Task運用

Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。

AI/Agentでは、LLM/provider障害、schema drift、tool/API変更、policy denial、権限、stale resource、deterministic bad inputを同じblind retryへ入れないことが重要です。

少なくともfailureを次へ分けます。

• transient/retryable: timeout、429、一時5xx、短期provider outage等
• deterministic/non-retryable: schema invalid、unsupported tool version、明示的policy denial等
• authorization/configuration: credential失効、permission不足、KMS/IAM不整合
• ambiguous external outcome: tool/APIが成功した可能性があるがack/response/checkpointを失った状態
• unknown: 根拠なくretryableへ分類しない

retry budgetを超えたtransient failureと、即時隔離すべきdeterministic failureを区別します。

delivery/receive countの意味をcross-provider invariantとして扱いません。

Google Cloud Pub/Subのmaximum delivery attemptsはbest-effortであり、設定値どおりの厳密な境界とは限りません。

Amazon SQS、Azure Service Bus、Pub/Sub等でattempt counting、TTL、redrive条件が異なるため、対象product/queue type/versionのdocumented semanticsを固定します。

DLQ/quarantine recordには可能な範囲で以下を保持します。

• original task/message ID
• workflow/run ID
• tenant/principal
• input hashとschema/version
• model/provider ID
• prompt/tool/schema/policy version
• attempt count
• first/last failure timestamp
• normalized failure class/reason
• raw errorの安全なlocator
• external operation ID/idempotency key
• last known authoritative external state
• remediation owner/status

secret tokenや不要なPIIをerror descriptionへ複製しません。

Amazon SQSではsource queueのredrive policyとDLQ側redrive allow policyを区別します。DLQ redriveにはSQS操作権限に加え、暗号化構成によってKMS権限が必要です。Standard/FIFOではDLQ移動後のtimestamp/retention semanticsも異なります。

Azure Service Busでは通常のDLQとtransfer dead-letter queueを区別します。consumer processing failureとforwarding infrastructure failureを同一reasonへ潰しません。DLQは自動cleanupされず、明示的な処理まで残ります。

Google Cloud Pub/Subではdead-letter topicの設定だけでなく、service accountのpublish/ack権限とdead-letter topic側subscriptionを確認します。maximum delivery attemptsはbest-effortです。

Kafka Connectではerrors.tolerance=allで処理継続できても、failed recordの存在が消えるわけではありません。DLQとmetricsを監視し、欠落をsilent successとして扱いません。

RabbitMQではdead-letter exchangeへのrepublish自体が失敗し得ます。queue typeとpublisher-confirm semanticsを確認し、DLXをlossless archiveと仮定しません。

redrive前に少なくとも次を確認します。

• root causeが特定されているか。
• consumer/tool/schema/policy/codeの修正版が配備されているか。
• credential/IAM/KMS/configurationが回復しているか。
• original taskが対象としたresource version/preconditionがまだ有効か。
• external side effectが既に成功していないかauthoritative readbackできるか。
• stable idempotency key/operation IDを維持できるか。
• redrive destination、batch size、concurrency、ordering影響が許容されるか。
• 再失敗時のre-dead-letterと停止条件があるか。

root cause未修正のmass redriveを行いません。

timeoutやworker crashでは、外部tool/APIが成功した後にconsumer側が失敗と認識する場合があります。

この状態を単純にredriveするとduplicate side effectを作り得ます。redrive前にexternal operation ID、idempotency key、resource state/versionを照合し、既済みなら再実行せずworkflow stateをreconcileします。

DLQ retentionを“隔離後N日”と一般化しません。製品・queue type固有のtimestamp/TTL semanticsを確認します。

DLQ depthだけでなくoldest ageとretention expiry riskを監視し、期限前にtriageします。修復不能または不要になったtaskは、削除理由、operator、evidence locator、最終状態を記録してdispositionします。

DLQは失敗prompt、tool arguments、customer payload、error traceを蓄積するため、高感度archiveになり得ます。

least privilege、encryption、KMS/IAM、tenant isolation、redaction、retention、data residency、削除証跡を通常queueと別に確認します。redrive authorityを通常consumer権限へ無条件に含めません。

少なくとも、deterministic poison input、transient retry exhaustion、external success/ack loss、DLQ publish failure、missing DLQ subscription、IAM/KMS denial、retention expiry、wrong redrive destination、concurrent redrive、re-dead-letter loopをfault injectionします。

DLQ depth/rate/oldest age、failure class、retry amplification、redrive success、re-dead-letter rate、retention risk、operator response timeを監視します。

poison input、schema error、malformed model/tool output、policy denial、credential失効、permission loss、provider outage、consumer bug、code/schema drift、stale resource、ambiguous external outcome、duplicate delivery、attempt counter ambiguity、retry storm、DLQ publish failure、missing subscription、retention expiry、PII/secret leakage、wrong redrive、ordering break、cycle、manual deletion without auditを想定します。

本項は2026-10-05時点のAmazon SQS、Azure Service Bus、Google Cloud Pub/Sub、Kafka Connect、RabbitMQの現行documentationとbounded local fixtureに基づきます。production queue、Agent task、external side effectのmutation/redriveは未実施です。

DLQは失敗message/taskを隔離する運用境界であり、失敗原因の修復やside effectのexactly-onceを自動保証しません。delivery-attempt semantics、retention、dead-letter forwarding、IAM/KMSは製品ごとに異なります。redrive前にroot causeの修正、version/precondition、既済みside effectのreadback/reconciliationを確認し、stable idempotency identityを維持してください。

対象broker/runtime、queue type/version、retry budget、DLQ topology、IAM/KMS、retention、ordering/session、task schema、model/tool/policy versions、side-effect status API、redrive authority、alert/SLO、data classification/residency、disposal evidenceは未確認です。

attempt count・retention・dead-letter forwarding safetyを一般化せず、Agent poison taskのquarantine、triage、redrive gate、external side-effect reconciliationを監査可能な運用境界として固定します。