{
  "format": "agent-article-v0",
  "article_id": "EA-245",
  "canonical_url": "/tools/ea-245-dead-letter-queue-poison-task",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EA-245-CURRENT-APPROVAL",
    "EA-245-CURRENT-BODY-READBACK"
  ],
  "unknown_ids": [
    "EA-245-UNKNOWN-01"
  ],
  "operational_object_ids": [],
  "provider": [],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "CURRENT",
  "observation_status": "SPEC_ONLY",
  "freshness": "CURRENT",
  "last_verified": "2026-10-05",
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "CANDIDATE-EA245-FIRST-20261005-C2-RESCUE20261013",
    "BODY-SHA256:73b2f7425339ab1c79397690fcff29cee149751bd60c3b263b09fd0334bdc867"
  ],
  "article_sources": [
    {
      "id": "EA-245-CURRENT-APPROVAL",
      "evidence_class": "RESEARCH",
      "title": "現行本文の監査・revision対応",
      "supports": [
        "現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。"
      ],
      "limit": "監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "CANDIDATE-EA245-FIRST-20261005-C2-RESCUE20261013"
      ],
      "supporting_locators": [
        "1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ",
        "EA_REVISION_LEDGER!A48:U48",
        "EA-245-FIRST-20261005"
      ],
      "provenance_status": "CURRENT_CANONICAL_APPROVAL_READBACK"
    },
    {
      "id": "EA-245-CURRENT-BODY-READBACK",
      "evidence_class": "IMPL",
      "title": "現行本文の収録照合",
      "supports": [
        "公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。"
      ],
      "limit": "本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。",
      "checked_at": "2026-10-13",
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "BODY-SHA256:73b2f7425339ab1c79397690fcff29cee149751bd60c3b263b09fd0334bdc867"
      ],
      "supporting_locators": [
        "content/staging/EA-245.md",
        "73b2f7425339ab1c79397690fcff29cee149751bd60c3b263b09fd0334bdc867",
        "EA-245-FIRST-20261005"
      ],
      "provenance_status": "CURRENT_APPROVED_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "PUBLIC_CLAIM",
      "text": "Dead Letter Queue（DLQ）は、繰り返し失敗するmessage/taskを通常処理から隔離するための運用境界です。DLQへ移動したこと自体は、root causeの修復、messageの永久保存、外部side effectのexactly-onceを意味しません。\n\n\nAI/Agentでは、LLM/provider障害、schema drift、tool/API変更、policy denial、権限、stale resource、deterministic bad inputを同じblind retryへ入れないことが重要です。"
    },
    {
      "heading": "FAILURE_CLASSIFICATION",
      "text": "少なくともfailureを次へ分けます。\n\n\n- transient/retryable: timeout、429、一時5xx、短期provider outage等\n- deterministic/non-retryable: schema invalid、unsupported tool version、明示的policy denial等\n- authorization/configuration: credential失効、permission不足、KMS/IAM不整合\n- ambiguous external outcome: tool/APIが成功した可能性があるがack/response/checkpointを失った状態\n- unknown: 根拠なくretryableへ分類しない\n\n\nretry budgetを超えたtransient failureと、即時隔離すべきdeterministic failureを区別します。"
    },
    {
      "heading": "ATTEMPT_SEMANTICS",
      "text": "delivery/receive countの意味をcross-provider invariantとして扱いません。\n\n\nGoogle Cloud Pub/Subのmaximum delivery attemptsはbest-effortであり、設定値どおりの厳密な境界とは限りません。\n\n\nAmazon SQS、Azure Service Bus、Pub/Sub等でattempt counting、TTL、redrive条件が異なるため、対象product/queue type/versionのdocumented semanticsを固定します。"
    },
    {
      "heading": "QUARANTINE_ENVELOPE",
      "text": "DLQ/quarantine recordには可能な範囲で以下を保持します。\n\n\n- original task/message ID\n- workflow/run ID\n- tenant/principal\n- input hashとschema/version\n- model/provider ID\n- prompt/tool/schema/policy version\n- attempt count\n- first/last failure timestamp\n- normalized failure class/reason\n- raw errorの安全なlocator\n- external operation ID/idempotency key\n- last known authoritative external state\n- remediation owner/status\n\n\nsecret tokenや不要なPIIをerror descriptionへ複製しません。"
    },
    {
      "heading": "PRODUCT_BOUNDARIES",
      "text": "Amazon SQSではsource queueのredrive policyとDLQ側redrive allow policyを区別します。DLQ redriveにはSQS操作権限に加え、暗号化構成によってKMS権限が必要です。Standard/FIFOではDLQ移動後のtimestamp/retention semanticsも異なります。\n\n\nAzure Service Busでは通常のDLQとtransfer dead-letter queueを区別します。consumer processing failureとforwarding infrastructure failureを同一reasonへ潰しません。DLQは自動cleanupされず、明示的な処理まで残ります。\n\n\nGoogle Cloud Pub/Subではdead-letter topicの設定だけでなく、service accountのpublish/ack権限とdead-letter topic側subscriptionを確認します。maximum delivery attemptsはbest-effortです。\n\n\nKafka Connectでは`errors.tolerance=all`で処理継続できても、failed recordの存在が消えるわけではありません。DLQとmetricsを監視し、欠落をsilent successとして扱いません。\n\n\nRabbitMQではdead-letter exchangeへのrepublish自体が失敗し得ます。queue typeとpublisher-confirm semanticsを確認し、DLXをlossless archiveと仮定しません。"
    },
    {
      "heading": "REDRIVE_GATE",
      "text": "redrive前に少なくとも次を確認します。\n\n\n1. root causeが特定されているか。\n2. consumer/tool/schema/policy/codeの修正版が配備されているか。\n3. credential/IAM/KMS/configurationが回復しているか。\n4. original taskが対象としたresource version/preconditionがまだ有効か。\n5. external side effectが既に成功していないかauthoritative readbackできるか。\n6. stable idempotency key/operation IDを維持できるか。\n7. redrive destination、batch size、concurrency、ordering影響が許容されるか。\n8. 再失敗時のre-dead-letterと停止条件があるか。\n\n\nroot cause未修正のmass redriveを行いません。"
    },
    {
      "heading": "SIDE_EFFECT_RECONCILIATION",
      "text": "timeoutやworker crashでは、外部tool/APIが成功した後にconsumer側が失敗と認識する場合があります。\n\n\nこの状態を単純にredriveするとduplicate side effectを作り得ます。redrive前にexternal operation ID、idempotency key、resource state/versionを照合し、既済みなら再実行せずworkflow stateをreconcileします。"
    },
    {
      "heading": "RETENTION_AND_DISPOSAL",
      "text": "DLQ retentionを“隔離後N日”と一般化しません。製品・queue type固有のtimestamp/TTL semanticsを確認します。\n\n\nDLQ depthだけでなくoldest ageとretention expiry riskを監視し、期限前にtriageします。修復不能または不要になったtaskは、削除理由、operator、evidence locator、最終状態を記録してdispositionします。"
    },
    {
      "heading": "SECURITY_AND_PRIVACY",
      "text": "DLQは失敗prompt、tool arguments、customer payload、error traceを蓄積するため、高感度archiveになり得ます。\n\n\nleast privilege、encryption、KMS/IAM、tenant isolation、redaction、retention、data residency、削除証跡を通常queueと別に確認します。redrive authorityを通常consumer権限へ無条件に含めません。"
    },
    {
      "heading": "OPERATING_CHECK",
      "text": "少なくとも、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します。\n\n\nDLQ depth/rate/oldest age、failure class、retry amplification、redrive success、re-dead-letter rate、retention risk、operator response timeを監視します。"
    },
    {
      "heading": "FAILURE_ENVELOPE",
      "text": "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を想定します。"
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "本項は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は未実施です。"
    },
    {
      "heading": "SAFE_WORDING",
      "text": "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を維持してください。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "対象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は未確認です。"
    },
    {
      "heading": "STOP_CONDITION",
      "text": "attempt count・retention・dead-letter forwarding safetyを一般化せず、Agent poison taskのquarantine、triage、redrive gate、external side-effect reconciliationを監査可能な運用境界として固定します。"
    }
  ],
  "human_url": "/tools/ea-245-dead-letter-queue-poison-task",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-245-dead-letter-queue-poison-task",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-245-dead-letter-queue-poison-task"
}