--- title: "Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説" url: "https://www.issoh.co.jp/tech/details/17241/" published: 2026-09-02 updated: 2026-10-17 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説 Amazon SQS（Simple Queue Service）は、処理したいメッセージをいったん預かり、受信側が自分のペースで取り出して処理するフルマネージドのキューです。サーバーの用意もスケーリングの調整も不要で、送信・受信・削除の3つのAPIだけで非同期処理を組めるのが特徴です。この記事では、標準キューとFIFOキューの配信保証とスループットの差、既定30秒の可視性タイムアウトをどう決めるか、`maxReceiveCount`とデッドレターキューをどう設計するか、そして64KB単位の課金とロングポーリングまでを、実装者が判断できる粒度で整理します。SQSを挟むべきでない場面も条件付きで示します。 ## まとめ｜Amazon SQSの採用判断と標準・FIFOの選び分け SQSは「送信側と受信側の処理速度を切り離したいとき」に効きます。バッチ取り込み、外部API呼び出し、画像や帳票の変換のように、失敗しても後から拾い直したい処理が典型です。逆に、呼び出し元がその場で結果を必要とする同期処理にキューを挟むと、レイテンシと運用対象が増えるだけで見返りがありません。 キュー種別は、順序が結果を変えるかどうかで決めます。在庫の増減や口座の入出金のように処理順が誤ると値が壊れるならFIFOキュー。それ以外の大量ジョブは標準キューが素直です。FIFOには非高スループットモードでパーティションあたり300TPSという上限があり、東京リージョンの高スループットモードでも非バッチ9,000TPSが目安になります（2026年9月時点のAWS公式ドキュメント）。 設計で事故が起きるのは、ほぼ可視性タイムアウトとデッドレターキューの2箇所です。可視性タイムアウトが処理時間より短いと同じメッセージが二重に配られ、`maxReceiveCount`が小さすぎると一時的な障害でメッセージがDLQへ落ちます。受信側は重複配信を前提に冪等化しておく。これが標準キューを使ううえでの前提条件になります。 ## Amazon SQSの仕組み｜フルマネージド型キューの構造と主要パラメータ SQSにはブローカーのインスタンスという概念がありません。キューを1本作れば、そのエンドポイントに対してHTTPSでAPIを叩くだけで使えます。RabbitMQやActiveMQのような常駐プロセスの面倒を見る必要がない代わりに、挙動はパラメータでしか調整できません。まずライフサイクルとパラメータの範囲を押さえます。 ### メッセージの3段階ライフサイクル｜受信後に明示削除が要る理由 メッセージは`SendMessage`でキューに入り、`ReceiveMessage`で取り出され、`DeleteMessage`で消えます。ここで見落とされやすいのが3つ目です。受信してもキューからは消えず、可視性タイムアウトの間だけ他のコンシューマから見えなくなる状態（インフライト）に移るだけで、削除APIを呼ばない限りタイムアウト後に再び配信されます。コンシューマがクラッシュしても処理が失われないのは、この「受信＝削除ではない」設計のおかげです。 裏を返せば、処理が成功したのに削除APIの呼び出しに失敗すると、同じメッセージが何度でも戻ってきます。削除は処理完了の直後に置き、例外時は削除しない。この順序を守るだけで、原因不明の再処理はかなり減ります。[同期処理と非同期処理の考え方の違い](https://www.issoh.co.jp/tech/details/13590/)を先に整理しておくと、この挙動の意味が掴みやすくなります。 ### 1MiBの上限と保持4日・遅延15分｜既定値と可変範囲の一覧 メッセージサイズの上限は1,048,576バイト（1MiB）です。かつての256KBから引き上げられており、JSONのペイロードであればほとんどの用途で収まる容量です。それを超える場合はAmazon SQS Extended Client Library（JavaとPython）を使い、実体をS3に置いてキューには参照だけを流す構成になります。この方式なら最大2GBまで扱えます。保持期間は既定4日、最小60秒、最大14日。メッセージタイマー（遅延キュー）は最大15分で、リトライを一定時間ずらしたいときに使います。バッチAPIは1回あたり10メッセージ、メッセージ属性は最大10個までです。 実務で調整対象になるのは保持期間です。既定の4日は、週末に障害が起きて月曜に気づく運用だと足りません。夜間バッチや週次処理を扱うキューは、14日に寄せておくほうが安全側に倒れます。 ## 標準キューとFIFOキューの違い｜順序保証・重複・スループットの比較 SQSのキューは作成時に標準かFIFOかを選び、後から変更できません。移行するには新しいキューを作って切り替える必要があるため、ここは設計初期に決め切る箇所です。判断軸は順序保証とスループット、そして受信側を冪等にできるかどうかの3点になります。 ### at-least-onceとexactly-once｜配信保証の差が実装に及ぼす影響 標準キューは少なくとも1回の配信（at-least-once）で、まれに同じメッセージが2回以上届く配信方式です。順序もベストエフォートで、送信順とは違う順で受け取る場合もある仕様です。FIFOキューは1回のみの処理（exactly-once processing）を保証し、メッセージグループ内では送信順が維持されます。重複は`MessageDeduplicationId`、またはコンテンツベースの重複排除で抑止されます。 | 観点 | 標準キュー | FIFOキュー | | ------- | ---------- | -------------- | | 配信保証 | 少なくとも1回 | 1回のみ処理 | | 順序 | ベストエフォート | グループ内で厳密 | | スループット | ほぼ無制限 | 300TPS〜高スループット | | 重複の抑止 | 受信側の冪等化で吸収 | 重複排除IDで抑止 | | リクエスト単価 | 低い | 標準より高い | | 向く処理 | 大量の非同期ジョブ | 順序が値を変える処理 | ここで判断が割れるのは「順序は要らないが重複は困る」ケースでしょう。決済の確定通知などがそれにあたります。答えは標準キュー＋受信側の冪等化です。FIFOに逃げるとスループット上限まで一緒に背負い込むことになります。 ### メッセージグループIDと300TPS｜FIFO並列化と公平キューの使い分け `MessageGroupId`はFIFOキューでは必須で、指定せずに送信したAPIは失敗扱いです。順序が保たれるのはこのグループの内側だけなので、顧客IDや注文IDのようにグループを細かく切るほど並列度が上がります。逆に全メッセージへ同じグループIDを付けると、キュー全体が1本の直列処理になり、300TPSどころか処理そのものが詰まります。非高スループットモードの上限はパーティションあたり300TPS、10件バッチで3,000メッセージ毎秒。高スループットモードなら東京リージョンで非バッチ9,000TPS、バッチ90,000メッセージ毎秒まで伸びます（2026年9月時点）。 同じ`MessageGroupId`は標準キューでも意味を持ちます。2025年7月に追加された公平キュー（fair queues）は、標準キューでグループIDを付けると有効になり、特定テナントの大量送信が他テナントの待ち時間を押し上げる状態を自動で緩和します。判定はインフライト30件以上かつ同時実行シェア10%以上、または処理時間シェア10%超。SaaSのように1本のキューを複数顧客で共有する構成では、プロデューサ側に1行足すだけで効く対策になります。 ## 可視性タイムアウトの設計｜重複処理が起きる条件と冪等化の実装 可視性タイムアウトは、受信されたメッセージを他のコンシューマから隠しておく時間です。この1つのパラメータが、二重処理の発生率とリカバリの速さを同時に決めます。短くしすぎても長くしすぎても実害が出るため、処理時間の実測から逆算します。 ### 既定30秒・最大12時間｜処理時間から逆算する設定値の決め方 既定値は30秒、設定できる範囲は0秒から12時間です。ワーカーの処理が平均5秒でも、外部APIのタイムアウトやリトライを含めた最悪値が90秒なら、30秒のままでは処理中に可視性が切れて別のワーカーへ同じメッセージが配られます。目安は最悪処理時間に余裕を1.5倍ほど乗せた値です。90秒なら150秒前後に置きます。 逆に、12時間に張ってしまう設定も避けます。ワーカーが落ちた場合、そのメッセージが再配信されるまで12時間戻ってこないからです。長時間処理は次に述べる延長APIで扱うほうが、障害時の復帰が速くなります。 ### 延長APIと冪等化の二段構え｜重複配信を前提にした受信側の設計 処理時間が読めないジョブでは、`ChangeMessageVisibility`で可視性タイムアウトを処理中に延ばす運用です。可視性を60秒に設定し、30秒ごとに60秒へ延長し直すハートビート型にすれば、正常時はタイムアウトせず、ワーカーが落ちれば60秒後に再配信されます。[AWS Lambdaをコンシューマにする構成](https://www.issoh.co.jp/tech/details/15407/)では、関数タイムアウトより可視性タイムアウトを長く（AWSの推奨は6倍）取っておかないと、実行中のメッセージが二重に呼ばれます。 それでも重複はゼロになりません。標準キューの配信保証がat-least-onceである以上、受信側で処理済みIDをDynamoDBやRDBのユニークキーに記録し、既存なら何もせず削除だけする形にします。メール送信や課金のように取り消せない副作用は、この記録の後ろに置きます。 ## デッドレターキューの設計｜滞留を検知して再処理に戻す運用手順 デッドレターキュー（DLQ）は、規定回数を超えて処理に失敗したメッセージの退避先です。DLQを設定していないキューでは、壊れたメッセージが保持期間いっぱい再配信を繰り返し、ワーカーのエラーログを埋め尽くします。DLQとソースキューは同一アカウント・同一リージョンに置く必要があり、種別も揃えます。 ### maxReceiveCountの決め方｜1では早すぎ大きすぎても滞留する境界 移送の条件は`maxReceiveCount`です。この回数だけ受信されて削除されなかったメッセージがDLQへ移る仕組みです。1に設定すると、外部APIの瞬間的な502で1度失敗しただけでDLQ行きになり、自動復旧の余地がなくなります。AWSのドキュメントも、システムの復元性を確保するために十分な再試行ができる値を推奨しています。外部依存のあるワーカーなら3〜5、依存が少なく失敗＝データ不正が濃厚なら2、といった置き方が現実的です。 大きすぎる設定にも副作用があります。`maxReceiveCount`が10を超えると、恒久的に処理できないメッセージがキューを長く占有し、可視性タイムアウトのたびに他の正常なメッセージの取り出しに割り込みます。「一時障害なら助かるが、データ不正なら早めに諦める」境界を数字で決めるのがこのパラメータの役目です。 ### 保持期間はソースより長く｜標準とFIFOで異なる経過時間の扱い 標準キューでは、DLQへ移ってもエンキュー時刻がリセットされません。ソースキューで1日経ってから移送された場合、DLQの保持期間が4日ならDLQ上では残り3日で消える計算です。FIFOキューは移送時に時刻がリセットされ、DLQで丸4日残ります。この差を知らずに両方4日で揃えると、標準キューのDLQだけ調査前にメッセージが消えます。DLQの保持期間はソースより長く、実務では14日に寄せておくのが無難です。 DLQに落ちたメッセージを戻す再ドライブ（redrive）は、コンソールまたはAPIから実行します。手順は次の通りです。 1. DLQのメッセージ本文を確認し、データ不正か一時障害かを切り分ける 2. 原因がコード側ならワーカーを修正してデプロイし、再発しない状態にする 3. ソースキューへ再ドライブし、`ApproximateAgeOfOldestMessage`で滞留が解けたか確認する 監視は`ApproximateNumberOfMessagesVisible`をDLQに対して張り、1件でも入ったらアラートを飛ばす設定にします。DLQは静かなキューであるべきなので、しきい値を0より上に置く理由はほとんどありません。 ## SQSを採用しない場面｜SNS・EventBridgeとの守備範囲の切り分け SQSは万能の接着剤ではありません。ここでは採用を見送るべき条件と、隣接サービスへ渡すべき条件を言い切ります。判断を誤ると、キューを1本増やしたぶんだけ監視対象と障害モードが増えます。 ### キューが過剰になる条件｜同期APIで完結する処理に挟まない判断 次の条件に当てはまるなら、SQSは挟みません。ひとつ、呼び出し元が数百ミリ秒以内に結果の値を必要とする場合。SQSはポーリング型なので、受信側がロングポーリングで待っていても取得までに秒単位の遅延が入ります。ふたつ、処理が1日数十件で、失敗時は担当者が手動で再実行すれば済む規模の場合。キューとDLQと監視を作る運用コストが、得られる耐障害性を上回ります。 判断を明確にします。「非同期にする理由が耐障害性でもスパイク吸収でもなく、なんとなく疎結合にしたいから」であれば、SQSは採用しません。同期呼び出しにリトライとタイムアウトを入れるほうが、デバッグも監視も簡単に済みます。 ### 通知はSNS・連携はEventBridge｜3サービスの役割分担の目安 1つのイベントを複数の受信者へ同時に配りたいなら、SNSでファンアウトしてから各サブスクライバのSQSキューへ入れる構成になります。SQS単体では、1つのメッセージを1つのコンシューマしか処理できないためです。イベントの中身で宛先を振り分けたい、SaaSからのイベントを受けたい、スケジュール実行したいという要件は[Amazon EventBridgeのルールベースのルーティング](https://www.issoh.co.jp/tech/details/15513/)の担当範囲です。SQSが受け持つのは、あくまで「1本の処理列に溜めて、順に捌く」役割に限られます。3サービスの選定基準は[SQS・SNS・SESの違いと使い分け](https://www.issoh.co.jp/tech/details/9310/)で比較軸ごとに整理しています。 迷ったときの目安はこうです。溜めたいならSQS、同報したいならSNS、振り分けたいならEventBridge。3つを直列に並べる構成（EventBridge→SNS→SQS）は珍しくありませんが、最初から3段を組む必要はありません。既存のJMSやAMQPのコードをそのまま移したい場合の比較は[Amazon MQとSQSの違い（プロトコル互換・料金構造・移行判断）](https://www.issoh.co.jp/tech/details/18445/)で整理しています。 ## コストとポーリング設計｜64KB課金と空受信を減らす設定の組み合わせ SQSの料金はリクエスト数の従量課金で、毎月100万リクエストまでは無料枠に収まります。単価はリージョンと時点で変わるため公式の料金ページで確認するとして、設計側で効くのは「何がリクエスト1件として数えられるか」の理解です。 東京リージョンの実額と、件数から月額を出す計算式・コードは[Amazon SQSの料金を東京リージョンの実額で試算する：64KB課金・FIFO単価・ロングポーリングでの削減手順](https://www.issoh.co.jp/tech/details/18453/)で整理しています。 ### 64KB＝1リクエスト換算｜ペイロード分割と課金単位のズレ回避 課金の単位はAPIコール数ではなく64KBのチャンクです。ペイロードは64KBごとにまとめて1リクエストとして請求され、1MiBのメッセージを1回送ると16リクエスト相当です。上限が1MiBに広がったからといって大きなJSONをそのまま流すと、リクエスト数が16倍になって効いてきます。数百KB以上のペイロードは、S3に置いて参照だけをメッセージに載せる構成のほうが安く収まります。 もうひとつ見落とされるのが、SendMessage以外も課金対象という点です。受信も削除も、可視性の変更もリクエストの対象です。1件のメッセージを処理するのに最低3回のAPIコールが発生する前提でコストを見積もると、実績との乖離が小さくなります。AWS上のキュー構成やコスト設計を含めた検討は[AWSインフラの構築支援](https://www.issoh.co.jp/service/system/aws/)でも承っています。 ### ロングポーリング20秒とバッチ10件｜空受信を削る設定の組み方 ショートポーリングのままだと、キューが空でもワーカーが回した分だけリクエスト課金が発生します。`ReceiveMessage`の`WaitTimeSeconds`を最大20秒に設定してロングポーリングへ切り替えると、メッセージが届くまで接続を保持するため、空応答の回数が大きく減ります。あわせて設定しておきたいのは次の3点です。 - `WaitTimeSeconds`を20秒にし、キュー属性の既定値としても設定する - `MaxNumberOfMessages`を10にして、1回の受信で最大10件をまとめて取る - 送信側も`SendMessageBatch`と`DeleteMessageBatch`で10件単位に束ねる バッチ化はコストだけでなくFIFOのスループットにも効きます。非高スループットモードの300TPSは、10件バッチで3,000メッセージ毎秒まで伸びるからです。ワーカーを増やす前に、まずこの3つが入っているかを確認します。 ## よくある質問 SQSの導入検討で実際に挙がる質問を、判断に直結する順で5つ挙げます。 ### Amazon SQSとAmazon MQはどう使い分けますか？ 既存システムがJMSやAMQP、MQTTといった標準プロトコルで書かれており、そのコードを変えずにクラウドへ移したいならAmazon MQです。ActiveMQやRabbitMQのマネージド版として動くため、既存のクライアントライブラリがそのまま使えます。一方、新規にAWS上でアプリケーションを組むならSQSを選びます。ブローカーのインスタンスサイズやパッチ適用を考えずに済み、スケーリングもリクエスト従量課金も自動で追従するためです。プロトコル互換の要件がなければ、運用負荷はSQSのほうが明確に軽くなります。 ### 標準キューでもメッセージの順序を保てますか？ キューの機能としては保てません。標準キューの順序はベストエフォートで、送信順と受信順が入れ替わることを前提に設計します。順序が必要な場合の選択肢は2つあり、ひとつはFIFOキューへの切り替え、もうひとつはメッセージ本文にシーケンス番号やタイムスタンプを載せ、受信側で並べ替える方式です。後者は受信側に状態を持たせる必要があるため、順序が業務要件として明確ならFIFOキューを選ぶほうが実装は単純に収まります。 ### 可視性タイムアウトを長くすると何が起きますか？ 処理中の二重配信は減りますが、ワーカーが異常終了したときの再配信が遅れます。可視性タイムアウトを12時間に設定していれば、クラッシュしたメッセージは12時間後まで誰にも配られません。処理時間が長いジョブでは、値を張るのではなく`ChangeMessageVisibility`で処理中に延長するハートビート方式に切り替えます。正常時はタイムアウトせず、異常時は短い間隔で復帰できる形になります。 ### Lambdaのトリガーに使う場合、DLQはどこに付けますか？ SQSをイベントソースにする構成では、Lambda側の障害宛先ではなくSQSキュー側のDLQを使います。Lambdaが例外で終了するとメッセージは削除されずキューへ戻り、`maxReceiveCount`に達した時点でDLQへ移送されるためです。あわせて、Lambdaの関数タイムアウトよりキューの可視性タイムアウトを長く（AWSの推奨は6倍）設定します。逆にしていると、実行中の関数があるのに同じメッセージが別の実行へ配られます。 ### SQSの料金は無料枠を超えるとどう課金されますか？ 毎月100万リクエストの無料枠を超えた分がリクエスト単位の従量課金になり、標準キューよりFIFOキューの単価が高く設定されています。数え方はAPIコール数ではなくペイロードのサイズ換算で、64KBごとに1リクエストとして請求されます。1MiBのメッセージを1回送れば16リクエストです。単価はリージョンと時点で変わるため、見積もりはAWSの料金計算ツールで確認してください。設計側でできるのは、バッチAPIで束ねること、大きなペイロードをS3参照に逃がすこと、ロングポーリングで空受信を削ることの3点です。 ## 関連記事 - [AWS SQS・SNS・SESの違いと使い分け｜3サービスの選定基準を比較](https://www.issoh.co.jp/tech/details/9310/)：どのサービスに寄せるかを比較軸ごとに判断したいとき。 - [Amazon SNSとは｜Pub/Sub通知の仕組み・配信先と採用判断](https://www.issoh.co.jp/tech/details/15612/)：ファンアウトの起点になる通知側の仕様を確認する記事。 - [Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装](https://www.issoh.co.jp/tech/details/15513/)：イベントの振り分けとスケジュール実行を担う側の解説。 - [SQS・Lambda・EventBridgeを用いた非同期処理の実践と運用方法](https://www.issoh.co.jp/tech/details/6034/)：3つを組み合わせた構成パターンと運用の勘所。 - [CSV一括インポートをAWS Lambda×SQSで実装｜分割と部分失敗の設計](https://www.issoh.co.jp/tech/details/1884/)：本記事の設計を実際のユースケースに落とした実装例。 --- 出典: [Amazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計を解説]()（株式会社一創）