Amazon SQSを使い始めて最初に直面する判断が「標準キューにするか、FIFOキューにするか」です。公式ドキュメントには特徴の列挙はありますが、「どんな条件でどちらを選ぶか」という設計判断の基準が見えにくい。結果として「よくわからないので標準キューにした」か「念のためFIFOにした」という両極端に流れがちです。
この記事では、Amazon SQSの2つのキュータイプの仕組みの違いを整理し、順序保証・べき等性（重複処理の防止）・スループット上限・料金の観点から、現場で使える設計判断フローを解説します。
オンプレのメッセージングとAmazon SQSの違い
オンプレ環境でよく使われるメッセージブローカー（RabbitMQ、ActiveMQ、IBM MQなど）では、「キューの種類」よりも「ブローカーのクラスター構成」がメインの関心事でした。メッセージの順序保証は基本的にクラスター設計で担保し、重複排除はアプリ側で処理するのが一般的です。
Amazon SQSはフルマネージドサービスで、ブローカーの可用性管理はAWSが担います。その代わり、設計者は「標準キュー」と「FIFOキュー」という2つのキュータイプを使い分けることで、順序保証・重複排除・スループットのトレードオフを明示的にコントロールします。
標準キューとFIFOキューの基本的な違い
| 項目 | 標準キュー | FIFOキュー |
|---|---|---|
| 配信保証 | 少なくとも1回（At-Least-Once） | 正確に1回（Exactly-Once） |
| 順序保証 | ベストエフォート（保証なし） | 送信順を厳密に保証 |
| スループット（デフォルト） | 実質無制限 | 300 TPS（メッセージグループ単位） |
| スループット（高スループットモード） | ― | 最大30,000 TPS（2026年10月時点） |
| 料金（2026年10月時点） | $0.40/100万リクエスト | $0.50/100万リクエスト |
| コンソール上の末尾識別子 | なし | キュー名の末尾が「.fifo」必須 |
標準キュー：設計の核心は「べき等性の実装をアプリ側で持つこと」
標準キューは高スループットと高可用性を最優先に設計されています。そのため、以下の2点を前提として設計する必要があります。
・重複配信が発生する：分散システムの性質上、同じメッセージが複数回コンシューマーに届く場合があります。
・順序が入れ替わる：メッセージは送信した順に届くとは限りません。
オンプレMQに慣れていると「重複なんて普通ないでしょ」と思いがちですが、SQSの標準キューでは重複配信を前提として設計するのが正しいアプローチです。
重複配信への対策として、受信側のアプリケーションにべき等性（Idempotency）を持たせます。同じメッセージIDで2回処理しても結果が同じになるよう、処理済みIDをDBやElastiCacheで記録しておく設計が一般的です。
冪等性設計の詳細については「冪等性（Idempotency）設計入門」でも解説しています。
FIFOキュー：「正確に1回」を支える2つの仕組み
FIFOキューが「正確に1回」の処理を実現するために使う仕組みが、メッセージグループIDと重複排除IDです。
1. メッセージグループID（MessageGroupId）
FIFOキューは「グループ単位」で順序を保証します。同じMessageGroupIdを持つメッセージは必ず送信順に処理されます。一方、異なるグループのメッセージは並列処理が可能です。
想定例として、注文システムで「注文ID」をMessageGroupIdに使うとします。同一注文の「注文確定→在庫引当→配送指示」という一連のメッセージは順序通り処理される一方、別の注文（別のグループ）とは並列処理できます。
2. 重複排除ID（MessageDeduplicationId）
同一の重複排除IDを持つメッセージを5分以内に送信した場合、重複とみなして2回目以降は廃棄されます。重複排除IDは明示的に指定するか、コンテンツベースの重複排除（ContentBasedDeduplication）を有効にしてメッセージ本文のSHA-256ハッシュで自動生成する方法があります。
スループット上限の実態と高スループットFIFOモード
FIFOキューのデフォルト制限（300 TPS）は、小中規模のワークロードでは問題になりません。ただし、高頻度イベント処理（IoTデータ収集、ログ集約など）では上限に達する可能性があります。
高スループットFIFOモードを有効にすると、2026年10月時点で最大30,000 TPSまで引き上げられます（リージョンやアカウントのクォータ設定により変動あり）。ただし、高スループットFIFOを使うとメッセージグループ内での順序保証が緩和される点に注意が必要です。
スループット要件が非常に高い場合は、Apache KafkaベースのマネージドサービスであるAmazon MSKの採用も検討に値します。
料金の比較と実務上の影響
2026年10月時点の料金は下記の通りです（最初の100万リクエストは無料枠あり）。
・標準キュー：$0.40/100万リクエスト
・FIFOキュー：$0.50/100万リクエスト
料金差は約25%です。月間1億リクエストの場合、標準キューで$40、FIFOキューで$50（差額$10）となります。大規模システムでは差が開きますが、単体では意思決定の主要因にはなりにくいでしょう。
一方、コスト最適化の観点では「ロングポーリング」の設定が重要です。デフォルトのショートポーリングは空のレスポンスでもリクエストカウントが増えます。ReceiveMessageWaitTimeSecondsを20秒に設定するロングポーリングにするだけで、空ポーリングのコストを大幅に削減できます。
設計判断フロー：結局どちらを選ぶか
判断のフローを整理すると下記のとおりです。
| 条件 | 推奨キュー |
|---|---|
| 処理順序の厳密な保証が必要（決済・在庫更新など） | FIFOキュー |
| 重複処理が業務上許容できない（二重送金・二重登録など） | FIFOキュー |
| スループットが高く（数千 TPS 以上）かつ順序は不要 | 標準キュー |
| ファンアウト（SNSからの複数キュー配信） | 標準キュー（SNS→SQS FIFOは不可※） |
| Lambda トリガーとして使う | どちらも可（FIFOはグループ単位でバッチ処理） |
| 処理結果が冪等で重複を許容できる | 標準キュー（コスト・スループット有利） |
※SNS→SQS FIFOのファンアウトは、SNSのFIFOトピックを使えば可能ですが構成が複雑になります。
【重要】「なんとなくFIFO」は避ける
よくあるつまずきとして、「とりあえず順序保証しておけば安心」という理由でFIFOを選ぶケースがあります。FIFOは300 TPSという制約とキュー名変更不可という制限を持ちます。
標準キューで作成したあとFIFOに変更する手段はなく、新しいFIFOキューを作り直す必要があります。設計初期の段階で要件（順序の必要性・重複排除の要否・スループット）を明確にしておくことが重要です。
LambdaとSQSの組み合わせ時の注意点
AWS LambdaをSQSのコンシューマーとして使う場合、FIFOキューではメッセージグループ単位でバッチ処理が行われます。1つのグループ内のメッセージが失敗するとそのグループ全体がブロックされる点を考慮した設計が必要です。
Dead Letter Queue（DLQ）の設定は標準・FIFOどちらでも必須です。処理失敗メッセージを本キューで無限リトライさせないよう、最大受信数（maxReceiveCount）とDLQをセットで設定しましょう。
本記事のまとめ
・標準キュー：高スループット・重複処理をアプリ側べき等で吸収できる場合に選ぶ。SNSファンアウトとの相性も良い。
・FIFOキュー：処理順序の厳密な保証と重複排除がビジネス要件として必要な場合に選ぶ。スループット上限に注意。
・料金差は約25%。スループット・順序要件が判断の主軸であり、料金差だけでの逆転判断は避ける。
・作成後にキュータイプを変更できないため、設計段階での要件確認が重要。
SQSのキュータイプの違いを正しく理解すると、EventBridgeやSNSとの組み合わせ設計にも自信が持てるようになります。AWS SNS vs SQSの使い分けガイドもあわせて参照してください。
PR
SQS・SNS・EventBridgeを活用したイベント駆動アーキテクチャを含む、AWSマネージドサービスを組み合わせたクラウドネイティブ設計パターンを体系的に学べる一冊。メッセージングの設計判断に迷ったときの参考書として最適です。
