# エージェント失敗タスクの隔離設計——DLQと再処理

> エージェントの失敗タスクはデッドレターキュー（DLQ）に隔離し、原因調査後に再投入します。Amazon SQSの仕様を基に、最大受信回数・保持期間・redriveの設計手順を示します。

- Canonical: https://kuucorp.com/blog/agent-failed-task-dead-letter-queue-redrive-design-smb/
- Date: 2026-10-16
- Last modified: 2026-10-16
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
問い合わせ対応や請求書処理をキュー経由でエージェントに任せると、必ず「何度やっても失敗するタスク」が1件は出ます。放置すれば同じタスクが再試行を繰り返してワーカーを占有し、後続の正常なタスクまで遅れます。

この問題はLLM固有ではなく、キュー設計の古典的な課題です。失敗したタスクを本流から切り離して保管する仕組みが、デッドレターキュー（DLQ）です。本記事では Amazon SQS の公式仕様を基に、中小企業の小規模なエージェント基盤でも組める隔離と再処理の設計を整理します。

## なぜ失敗タスクを本流から隔離するのか

> 失敗を繰り返すタスクは、再試行のたびに処理能力を消費します。DLQへ隔離すれば、正常なタスクの処理を止めずに原因調査へ進めます。

エージェントのタスクが失敗する原因は、大きく3種類に分かれます。

- 一時的な障害: ネットワーク断やAPIのレート制限。時間を置けば成功する
- 恒久的な入力不備: 添付ファイルの破損や必須項目の欠落。何度やっても成功しない
- 設計上の欠陥: 想定外の入力でループする、ツール定義が合っていない

AWS Builders' Library は、リトライは障害が稀で一時的な場合に限って有効であり、過負荷時には復旧を遅らせると指摘しています。恒久的な失敗を無限に再試行する設計は、この最悪の形です。上限回数を超えたら本流から外し、人間か別の処理系が判断する。これがDLQの役割です。

## DLQの仕組みと最大受信回数はどう決めるか

> SQSでは、redrive policyの maxReceiveCount を超えて受信されたメッセージが自動でDLQへ移ります。値が小さすぎると一時障害でも隔離されます。

SQS公式ドキュメントによると、DLQは通常のキューを事前に作成して指定します。DLQは元のキューと同じAWSアカウント・同じリージョンに置く必要があります。

`maxReceiveCount` は、コンシューマーが同一メッセージを受信できる回数の上限です。公式は、値を1のように低くすると1回の失敗で即座にDLQへ移るため、エラーへの耐性を保つには再試行に十分な値を設定するよう述べています。

設計の目安は次のとおりです。

1. 一時障害が混じるツール呼び出しは、3〜5回程度を起点に実測で調整する（数値は運用で決める設定値であり、公式の推奨値ではありません）
2. 再試行は呼び出しスタックの1層だけで行う。Builders' Library は、各層で3回ずつ再試行すると5層で通常の243倍の負荷になりうると説明しています
3. 副作用のある処理は冪等性キーを持たせる。再試行が安全なのは読み取りか冪等な操作に限られます

なお、FIFOキューでメッセージの順序を厳密に守りたい場合は、DLQを使わないよう公式が注意しています。順序依存の処理は別設計が必要です。

## DLQの保持期間と監視はどう設計するか

> DLQの保持期間は元のキューより長く設定します。標準キューでは、DLQへ移っても元の送信時刻が保たれたまま期限が進むためです。

標準キューでは、メッセージの期限は元のエンキュー時刻を基準に計算され、DLQへ移っても変わりません。公式の例では、元のキューに1日滞留したメッセージを保持期間4日のDLQへ移すと、DLQには3日で消えます。そのため公式はDLQの保持期間を元のキューより長くすることをベストプラクティスとしています。

運用上は、DLQに1件でも入ったら通知する構成が基本です。公式は Amazon CloudWatch でDLQ向けのアラームを作成する手順を案内しています。

DLQの中身は、次の項目を添えて記録しておくと原因調査が速くなります。

- タスクID・投入時刻・受信回数
- 最後のエラー種別とエージェントの実行ログへの参照
- 入力データの所在（個人情報を含む場合は保存先とアクセス権を限定）

## 再処理（redrive）をどう安全に行うか

> 再処理は原因を直してから、速度を絞って行います。SQSのredriveは最大毎秒500件まで指定でき、小さく始めて引き上げるのが公式の推奨です。

原因を直す前に再投入しても、同じ失敗を繰り返してDLQへ戻るだけです。手順は次の順序で進めます。

1. DLQのメッセージを調べ、入力不備かコードの欠陥かを切り分ける
2. 欠陥ならエージェントやツール定義を修正し、入力不備なら元データを直すか破棄を決める
3. redriveで元のキューへ戻す。コンソールの Start DLQ redrive、またはAPIの `StartMessageMoveTask` を使う
4. 速度は Custom max velocity で小さい値から始め、元のキューが詰まらないことを確認しながら上げる

公式ドキュメントに記載された制約も把握しておきます。

- redrive中にメッセージの絞り込みや書き換えはできない
- 1回のredriveタスクは最長36時間
- redriveされたメッセージは新しいメッセージとして扱われ、新しい messageID とエンキュー時刻が付与される
- 暗号化キューではKMSの権限（kms:Decrypt 等）も必要になる

書き換えが必要な場合は、DLQから別の処理で読み出して補正し、元のキューへ送り直す運用になります。

## 小さく始めるための最小構成

> 最小構成は、元のキュー1本、DLQ1本、DLQ到着のアラーム1つです。この3点だけで、失敗の放置と無限再試行は防げます。

中小企業が最初に整えるなら、次の順序が現実的です。

- 元のキューにredrive policyを設定し、DLQを紐付ける
- DLQの保持期間を元のキューより長くする
- DLQの到着を担当者へ通知する
- 週次でDLQを確認し、原因別に分類して再処理か破棄を決める

DLQに溜まった失敗の傾向は、エージェントの改善点そのものです。入力不備が多ければ受付側のバリデーションを、同じツールで落ちるならツール定義を見直す材料になります。

自社の基盤にどこまで組み込むべきか判断がつかない場合は、[Kuuの導入〜定着の伴走支援](https://kuucorp.com/services/ai-ops/)で、業務量に合った構成から整理できます。

## 参考

- [Using dead-letter queues in Amazon SQS（AWS公式ドキュメント）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)
- [Learn how to configure a dead-letter queue redrive in Amazon SQS（AWS公式ドキュメント）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue-redrive.html)
- [Timeouts, retries, and backoff with jitter（AWS Builders' Library）](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)

## まとめ

> 失敗タスクは本流から隔離し、原因を直してから速度を絞って戻します。DLQ・長めの保持期間・到着アラームの3点が最小構成です。

エージェントの運用では、失敗をゼロにするより、失敗を隔離して学べる状態にすることが先です。キュー、DLQ、アラームの3点から始め、DLQの中身を改善サイクルに接続してください。導入や運用設計のご相談は、[Kuuの問い合わせフォーム](https://kuucorp.com/contact/)から受け付けています。