▪️目的

AWSでシステムを構築していると、

• 大量の処理を一度に実行したくない
• アプリケーション同士を直接通信させたくない
• 一時的に処理を待たせたい
• システムに負荷が集中するのを防ぎたい
• 何かの処理に失敗したときに、後から再処理したい

といった場面があります。

このようなときに利用されるAWSサービスの一つが、**Amazon SQS（Simple Queue Service）**です。

SQSは、メッセージをキューに保存し、処理するシステムが必要なタイミングでメッセージを取得できるサービスです。

この記事では、AWS初心者の方向けに、SQSの基本的な仕組みから、キュー、メッセージ、Producer、Consumer、Visibility Timeout、Dead-Letter Queue、SNSとの連携まで分かりやすく解説します。

---

---

▪️SQSとは？

SQSとは、Amazon Simple Queue Serviceの略です。

簡単にいうと、

メッセージをキューに保存し、別のシステムが後から処理できるようにするマネージドサービス

です。

「キュー」と聞くと少し難しく感じるかもしれません。

身近な例で考えてみましょう。

例えば、人気の飲食店にたくさんのお客さんが来たとします。

お客さん
 ↓
受付
 ↓
順番待ち
 ↓
空いたら案内

お客さんが一度に全員入店するのではなく、順番待ちの列に並びます。

SQSも似ています。

処理要求
 ↓
SQS Queue
 ↓
処理できるタイミングで取得
 ↓
処理

つまりSQSは、

「今すぐ処理できないものを、いったん列に並べておく」

ような仕組みです。

---

▪️SQSの基本的な仕組み

SQSを理解するうえで重要なのが、

• Queue
• Message
• Producer
• Consumer

という4つの言葉です。

全体像を見てみましょう。

Producer
   │
   │ Message
   ▼
┌─────────────┐
│ SQS Queue   │
│             │
│ Message A   │
│ Message B   │
│ Message C   │
└─────────────┘
   │
   │ Message
   ▼
Consumer

それぞれの役割を見ていきましょう。

---

▪️Queueとは？

Queue（キュー）とは、

メッセージを一時的に保持しておく場所

です。

例えば、

OrderQueue

というキューを作ったとします。

そこへ、

注文A
注文B
注文C

というメッセージを送ることができます。

OrderQueue
│
├─ 注文A
├─ 注文B
└─ 注文C

処理する側は、このキューからメッセージを取得して処理します。

---

▪️Messageとは？

Message（メッセージ）とは、

SQSに登録される処理データ

です。

例えば注文処理なら、

{
  "orderId": "12345",
  "productId": "A001",
  "quantity": 2
}

のようなデータをメッセージとして送ることができます。

実際にどのようなデータを入れるかは、システムの設計によって決まります。

重要なのは、

「処理してほしい内容をメッセージとしてキューに入れる」

という考え方です。

---

▪️Producerとは？

Producerとは、

SQSへメッセージを送信する側

です。

例えば、

Webアプリケーション
       │
       ▼
    SQS Queue

という構成の場合、WebアプリケーションがProducerです。

Producerは、

注文が発生
 ↓
メッセージを作成
 ↓
SQSへ送信

という処理を行います。

---

▪️Consumerとは？

Consumerとは、

SQSからメッセージを取得して処理する側

です。

例えば、

SQS Queue
    │
    ▼
Lambda

という構成なら、LambdaがConsumerとして処理を行えます。

流れとしては、

SQS
 ↓
メッセージ取得
 ↓
Lambda
 ↓
処理

となります。

---

▪️SQSを使うと何が嬉しいの？

SQSを利用する大きなメリットの一つが、

システム同士を直接つながなくてもよくなる

ことです。

例えばSQSを使わない場合、

アプリケーションA
      │
      ▼
アプリケーションB

という直接的な関係になることがあります。

この場合、アプリケーションBが停止していると、A側の処理にも影響が出る可能性があります。

そこでSQSを間に入れます。

アプリケーションA
      │
      ▼
   SQS Queue
      │
      ▼
アプリケーションB

すると、AはまずSQSへメッセージを送っておき、Bは処理できるタイミングでSQSからメッセージを取得できます。

---

▪️システムの負荷を分散できる

SQSは、処理の集中を緩和するためにも利用できます。

例えば、通常時は毎秒10件程度の注文が来るとします。

しかし、キャンペーンなどによって、

毎秒1000件

の注文が一気に発生する可能性があります。

すべての処理を即座に実行しようとすると、後段のシステムに負荷が集中する可能性があります。

そこで、

大量のリクエスト
       │
       ▼
    SQS Queue
       │
       ▼
処理できる速度でConsumerが処理

という構成にできます。

SQSが一時的にメッセージを保持することで、処理側の負荷を平準化しやすくなります。

---

▪️SQSを使った注文処理の例

例えばECサイトを考えてみましょう。

ユーザーが商品を注文すると、

ユーザー
 ↓
Webアプリケーション
 ↓
SQS
 ↓
注文処理

という流れを作れます。

注文処理のシステムが一時的に遅くなったとしても、注文メッセージをSQSに保持しておくことで、後から処理できます。

例えば、

SQS
│
├─ 注文A
├─ 注文B
├─ 注文C
├─ 注文D
└─ 注文E

となっていれば、Consumerが順番に処理していくことができます。

---

▪️Standard Queueとは？

SQSには代表的に、

• Standard Queue
• FIFO Queue

があります。

まずStandard Queueです。

Standard Queueは、

高いスループットとスケーラビリティを重視した一般的なキュー

です。

大量のメッセージを処理するようなシステムで利用できます。

ただし、メッセージの処理順序を厳密に保証する用途には向いていません。

また、同じメッセージが複数回配信される可能性があるため、Consumer側で重複処理に耐えられるよう設計することが重要です。

---

▪️FIFO Queueとは？

FIFO Queueは、

メッセージの順序を保ちながら処理したい場合に利用するキュー

です。

FIFOは、

First In, First Out

の略です。

つまり、

先に入ったメッセージ
        ↓
先に処理

という考え方です。

例えば、

注文A
 ↓
注文B
 ↓
注文C

という順番を重要視する処理では、FIFO Queueが適しています。

また、FIFO Queueには重複排除などの機能もあります。

---

▪️Standard QueueとFIFO Queueの違い

簡単に比較すると、

項目	Standard Queue	FIFO Queue
主な特徴	高スループット	順序を重視
順序	厳密には保証されない	順序を保証
重複	発生する可能性あり	重複排除機能あり
主な用途	大量の非同期処理	順序が重要な処理

どちらを利用するかは、

「処理順序が重要なのか」

「重複処理をどう扱うのか」

などを考えて決めます。

---

▪️Visibility Timeoutとは？

SQSを理解するうえでもう一つ重要なのが、Visibility Timeoutです。

少し難しそうに見えますが、考え方はシンプルです。

例えば、

SQS
 ↓
Consumerがメッセージを取得

したとします。

このとき、同じメッセージを別のConsumerがすぐ取得してしまうと、同じ処理が同時に実行される可能性があります。

そこで、Consumerがメッセージを取得すると、そのメッセージを一定時間ほかのConsumerから見えない状態にします。

これがVisibility Timeoutです。

イメージとしては、

SQS
│
├─ Message A ← Consumerが取得
│
├─ Message B
└─ Message C

Message A
↓
一時的に非表示
↓
Consumerが処理

となります。

---

▪️Visibility Timeout中に処理が成功したら？

Consumerが正常に処理できた場合、メッセージを削除します。

SQS
 ↓
Message取得
 ↓
処理
 ↓
成功
 ↓
Message削除

これで、そのメッセージは処理済みになります。

---

▪️Visibility Timeout中に処理が失敗したら？

処理に失敗してメッセージが削除されなかった場合、Visibility Timeoutが終了すると、そのメッセージが再び取得可能になります。

SQS
 ↓
Message取得
 ↓
処理失敗
 ↓
削除されない
 ↓
Visibility Timeout終了
 ↓
再び取得可能

この仕組みによって、処理に失敗したメッセージを再処理できるようになります。

---

▪️Dead-Letter Queueとは？

何度処理しても失敗してしまうメッセージがあると、

SQS
 ↓
処理失敗
 ↓
再処理
 ↓
また失敗
 ↓
再処理
 ↓
また失敗

という状態になってしまう可能性があります。

そこで利用されるのが**Dead-Letter Queue（DLQ）**です。

Dead-Letter Queueとは、

何度も処理に失敗したメッセージを別のキューへ移動して、通常の処理から切り離す仕組み

です。

例えば、

Main Queue
    │
    ├─ 正常 → 処理完了
    │
    └─ 何度も失敗
           ↓
       Dead-Letter Queue

という構成です。

これによって、問題のあるメッセージを後から調査できます。

---

▪️Dead-Letter Queueを使うメリット

例えば注文処理で、

注文ID：12345

だけ何度もエラーになるとします。

そのまま再処理を続けると、通常の注文処理にも影響する可能性があります。

そこで、

Main Queue
 ↓
何度も失敗
 ↓
DLQ

とすることで、

通常の注文処理
↓
継続

問題のある注文
↓
DLQへ隔離
↓
後から調査

という運用ができます。

---

▪️SNSとSQSの違い

前回の記事ではSNSを紹介しました。

SNSとSQSはどちらもメッセージングに関係するため、混乱しやすいサービスです。

簡単にいうと、

SNS＝メッセージを配信する

SQS＝メッセージをキューに保持する

という違いがあります。

比較すると、

項目	SNS	SQS
主な役割	メッセージ配信	メッセージ保持・処理待ち
基本構造	Topic	Queue
代表的な用途	通知・イベント配信	非同期処理
複数システムへの配信	得意	Queue単位で処理
処理待ち	主目的ではない	重要な役割

イメージすると、

SNS
↓
「みんなに知らせる」

SQS
↓
「処理するまで列に並べておく」

と考えると分かりやすいでしょう。

---

▪️SNSとSQSを組み合わせる

SNSとSQSは、組み合わせて利用することもできます。

例えばECサイトで注文が発生した場合、

注文発生
   │
   ▼
SNS Topic
   │
   ├────────────┐
   ▼            ▼
SQS            SQS
│              │
▼              ▼
在庫処理       発送処理

のような構成を作れます。

SNSがイベントを複数のSQSへ配信し、それぞれのSQSを各システムが処理します。

このような構成にすることで、複数のシステムを疎結合にしやすくなります。

---

▪️SNSとSQSの役割を整理

ここは非常に重要なので、もう一度整理します。

SNS
 ↓
イベントを配信する

SQS
 ↓
イベントをキューに保持する

Consumer
 ↓
キューから取得して処理する

例えば、

注文発生
 ↓
SNS
 ↓
SQS
 ↓
Lambda
 ↓
注文処理

という構成です。

SNSとSQSを組み合わせることで、

「イベントを知らせる」

と

「処理を待たせる」

を分離できます。

---

▪️SQSとLambda

SQSはLambdaとも組み合わせることができます。

例えば、

SQS
 ↓
Lambda
 ↓
処理

という構成です。

LambdaがSQSをポーリングし、メッセージを取得して処理する構成が一般的です。

処理が成功すればメッセージが削除され、失敗した場合は設定などに応じて再処理されます。

これによって、

イベント発生
 ↓
SQSへ保存
 ↓
Lambdaが処理

という非同期処理を構築できます。

---

▪️SQSを利用するときのポイント

SQSを設計するときには、単純にキューを作るだけではありません。

例えば、

• Standard QueueとFIFO Queueのどちらを使うか
• メッセージをどのくらい保持するか
• Visibility Timeoutをどの程度にするか
• 処理に失敗したメッセージをどう扱うか
• DLQを利用するか
• Consumerをどの程度並列化するか
• 重複処理が発生した場合にどうするか

などを考える必要があります。

特に重要なのが、

「メッセージを受け取った後、処理に失敗した場合どうするのか」

という視点です。

SQSは単なる「データ置き場」ではなく、

「非同期処理を安全に行うための仕組み」

として考えることが重要です。

---

▪️SQSを使ったシステムの全体像

ここまでの内容をまとめると、例えば以下のようなシステムを構築できます。

                 Webアプリケーション
                         │
                         ▼
                    SNS Topic
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
         SQS Queue A            SQS Queue B
              │                     │
              ▼                     ▼
          Lambda A              Lambda B
              │                     │
              ▼                     ▼
           DB処理                発送処理

この構成では、

SNS
↓
イベントを配信

SQS
↓
処理を一時的に保持

Lambda
↓
実際の処理を実行

という役割分担になっています。

それぞれのサービスが得意な仕事を担当していることがポイントです。

---

▪️AWSの運用サービスとメッセージング

ここまで紹介したAWSサービスを並べてみると、AWSの仕組みがさらに見えてきます。

IAM
 ↓
権限管理

CloudTrail
 ↓
AWS操作の記録

CloudWatch
 ↓
監視

CloudWatch Alarm
 ↓
異常検知

SNS
 ↓
メッセージ配信

SQS
 ↓
メッセージ保持・非同期処理

例えば、

EC2
 ↓
CloudWatch
 ↓
CPU異常
 ↓
Alarm
 ↓
SNS
 ↓
メール通知

という運用もできます。

一方で、

アプリケーション
 ↓
SNS
 ↓
SQS
 ↓
Lambda
 ↓
処理

というシステム間連携もできます。

このように、AWSでは各サービスを組み合わせることで、監視・通知・非同期処理・システム連携などの仕組みを構築していきます。

---

▪️まとめ

今回は、AWSのSQSについて解説しました。

SQSは、メッセージをキューに保存し、処理するシステムが後から取得できるようにするサービスです。

ポイントを整理すると、

• SQSはAmazon Simple Queue Serviceの略
• メッセージをキューに一時的に保持する
• Producerがメッセージを送信する
• Consumerがメッセージを取得して処理する
• システム同士を疎結合にできる
• 大量の処理を一時的にキューへためて負荷を平準化しやすい
• Standard QueueとFIFO Queueがある
• Visibility Timeoutによって処理中のメッセージを一時的に見えなくできる
• 処理に何度も失敗するメッセージはDead-Letter Queueへ隔離できる
• SNSと組み合わせてイベント配信と非同期処理を分離できる
• Lambdaなどと組み合わせて非同期処理を構築できる

特に、

SNS＝メッセージを配信する

SQS＝メッセージをキューに保持する

という違いは覚えておきましょう。

SQSを理解すると、AWSでよく使われる**「非同期処理」や「疎結合なシステム設計」**の考え方が見えてきます。

AWSでは、すべての処理をリアルタイムで直接つなぐのではなく、SQSのようなサービスを間に入れることで、システムの負荷を分散したり、障害時の再処理をしやすくしたりする設計ができます。

次回は、AWSのネットワークやアプリケーション構成でも重要になる**Elastic Load Balancing（ELB）**について解説します。
＊「ELB」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのelbとは？ロードバランサーの仕組みを初心者向/」