AWS 完全攻略 Ep9: SESエンジニアのためのSQS・SNSメッセージング設計入門

⚡ 3秒でわかる！この記事のポイント

SQS・SNS経験者のSES案件単価は70〜100万円 — マイクロサービス案件で必須のメッセージングスキル
SQSは「非同期キュー」、SNSは「Pub/Sub通知」——役割の違いを理解すれば設計で迷わない
Fan-outパターンとデッドレターキューを使いこなせるエンジニアは現場で即戦力として評価される

なぜSESエンジニアにメッセージングスキルが必要なのか

Amazon SQS（Simple Queue Service）とAmazon SNS（Simple Notification Service）は、AWSが提供するフルマネージドメッセージングサービスです。モノリシックなアプリケーションからマイクロサービスへの移行が加速する2026年現在、SES案件市場でも非同期処理やイベント駆動アーキテクチャの設計経験が強く求められるようになっています。

従来のSES案件ではAPIの同期処理だけで完結するものが大半でしたが、大量リクエストの処理、サービス間の疎結合化、障害の局所化といった要件が増えるにつれて「SQSやSNSを使った非同期設計ができるエンジニア」の需要が急増しています。メッセージングはマイクロサービス案件への入口です。

この記事でわかること

SQS・SNS × SES案件の需要と単価相場
SQSとSNSの違い・使い分けの判断基準
Fan-outパターンなど実務頻出のアーキテクチャ
デッドレターキュー（DLQ）によるエラーハンドリング
Lambda連携やコスト最適化のベストプラクティス

SQS・SNS × SES案件の需要と単価【2026年】

メッセージングエンジニアの市場動向

2026年のSES案件市場では、SQS・SNSをはじめとするメッセージングサービスの経験を求める案件が前年比25%増で伸びています。特に以下の領域で需要が顕著です。

マイクロサービス連携: サービス間の非同期通信基盤としてSQS/SNSを採用
大量データ処理: ECサイトの注文処理、ログ収集パイプライン
通知システム: メール・SMS・プッシュ通知の統合配信基盤
イベント駆動アーキテクチャ: EventBridge + SNS + SQSを組み合わせた設計

SQS・SNS経験者の単価レンジ

経験レベル	月単価目安	求められるスキル
初級（〜1年）	55〜70万円	基本的なキュー操作、メッセージ送受信
中級（1〜3年）	70〜85万円	Fan-outパターン設計、DLQ運用、Lambda連携
上級（3年〜）	85〜100万円	FIFO設計、大規模メッセージング基盤、パフォーマンスチューニング

💡 ポイント: メッセージング単体よりも「Lambda + SQS + DynamoDB」のようにサーバーレス全体を理解していると、単価交渉で有利になります。Ep8: DynamoDB入門もあわせて学びましょう。

SQSの基礎知識

SQSとは

Amazon SQSは、分散型メッセージキューサービスです。プロデューサー（送信側）がキューにメッセージを入れ、コンシューマー（受信側）がキューからメッセージを取り出して処理します。

[プロデューサー] → [SQS キュー] → [コンシューマー]
   (API Gateway)     (メッセージ保持)    (Lambda / EC2)

この仕組みにより、送信側と受信側が完全に非同期で動作し、一方がダウンしてもメッセージが失われません。

SQSのキュータイプ

SQSには2つのキュータイプがあり、要件に応じて使い分けます。

比較項目	標準キュー	FIFOキュー
スループット	ほぼ無制限	300メッセージ/秒（バッチで3,000）
順序保証	ベストエフォート	厳密な先入れ先出し
重複	まれに重複あり	重複排除（5分間）
料金	安い	標準の約1.2倍
用途	ログ収集、通知、一般処理	決済処理、順序が重要な処理

SES案件での使い分け: 多くの案件では標準キューで十分です。FIFOキューが必要なのは「注文処理の順序が重要」「同じリクエストの二重処理を防ぎたい」など、ビジネスロジックで厳密な順序・重複排除が必要なケースに限られます。

可視性タイムアウト

SQSの重要な概念が可視性タイムアウト（Visibility Timeout）です。コンシューマーがメッセージを受信すると、そのメッセージは設定した秒数だけ他のコンシューマーから見えなくなります。

1. コンシューマーA がメッセージを受信
2. 可視性タイムアウト開始（デフォルト30秒）
3. コンシューマーA が処理完了 → メッセージ削除
   もし処理失敗 → タイムアウト後にメッセージが再度キューに現れる

⚠️ 設計のポイント: 可視性タイムアウトは「処理にかかる最大時間 + 余裕」に設定します。短すぎると処理中に他のコンシューマーが同じメッセージを取得し、重複処理が発生します。

SNSの基礎知識

SNSとは

Amazon SNSは、Pub/Sub（パブリッシュ/サブスクライブ）型のメッセージングサービスです。1つのメッセージを複数の宛先（サブスクライバー）に同時配信できます。

                      ┌→ [SQS キュー A]
[パブリッシャー] → [SNSトピック] ─→ [Lambda関数]
                      └→ [メール / SMS]

SNSのサブスクリプションタイプ

SNSは多様なプロトコルにメッセージを配信できます。

プロトコル	用途
SQS	非同期処理キューへの転送
Lambda	サーバーレス関数の直接起動
HTTP/HTTPS	Webhookエンドポイントへの通知
Email / Email-JSON	メール通知
SMS	ショートメッセージ
Kinesis Data Firehose	ストリーミングデータ配信

SES案件でよく使われるのはSQSとLambdaへの配信です。 メール・SMSはアプリケーションのユーザー通知用途で使われます。

メッセージフィルタリング

SNSの強力な機能がサブスクリプションフィルタポリシーです。サブスクライバーごとにフィルタ条件を設定し、必要なメッセージだけを受信できます。

// 注文トピックに対するフィルタポリシー例
// このサブスクライバーは「高額注文」だけを受信する
{
  "orderType": ["premium"],
  "amount": [{"numeric": [">=", 100000]}]
}

フィルタリングを使えば、コンシューマー側でメッセージを選別する処理が不要になり、不要なLambda実行やSQSポーリングのコストを削減できます。

SQS・SNSメッセージングアーキテクチャのインフォグラフィック

実践：メッセージングアーキテクチャパターン

パターン1：非同期処理（SQS単体）

最もシンプルなパターンです。API Gatewayで受けたリクエストを即座にSQSに入れ、Lambdaで非同期に処理します。

[クライアント]
    ↓ HTTPS
[API Gateway]
    ↓ SQS統合
[SQS キュー]
    ↓ トリガー
[Lambda関数]
    ↓ 処理
[DynamoDB / S3 など]

メリット: クライアントへのレスポンスが高速になり、バックエンドの処理遅延やエラーがクライアントに影響しません。

// Lambda：SQSからメッセージを受信して処理する例
export const handler = async (event) => {
  for (const record of event.Records) {
    const body = JSON.parse(record.body);
    console.log("注文処理:", body.orderId);

    // DynamoDBに保存
    await docClient.send(new PutCommand({
      TableName: "Orders",
      Item: {
        PK: `ORDER#${body.orderId}`,
        SK: "DETAIL",
        ...body,
        processedAt: new Date().toISOString()
      }
    }));
  }
};

パターン2：Fan-out（SNS + SQS）

1つのイベントを複数のサービスで並列処理するパターンです。SES案件のマイクロサービス設計で最も頻出する構成です。

                         ┌→ [SQS: 在庫更新キュー] → [在庫Lambda]
[注文サービス] → [SNSトピック] ─→ [SQS: 通知キュー]   → [通知Lambda]
                         └→ [SQS: 分析キュー]   → [分析Lambda]

ユースケース例: ECサイトで注文が確定したら…

在庫サービス: 在庫数を減らす
通知サービス: 購入確認メールを送信
分析サービス: 売上データを集計

各サービスが独立して処理するため、通知サービスが遅延しても在庫更新には影響しません。これがマイクロサービスの疎結合です。

パターン3：リクエスト・レスポンス（SQS双方向）

同期的なレスポンスが必要な場面で、SQSを2本使うパターンです。

[サービスA] → [リクエストキュー] → [サービスB]
[サービスA] ← [レスポンスキュー] ← [サービスB]

💡 このパターンはStep Functionsの.waitForTaskTokenで代替できることも多いです。詳しくはStep Functions実践ガイドをご覧ください。

デッドレターキュー（DLQ）によるエラーハンドリング

DLQとは

デッドレターキュー（Dead Letter Queue）は、処理に失敗したメッセージを退避するための専用キューです。メッセージングシステムの信頼性を担保する重要な仕組みです。

[SQS メインキュー]
    ↓ 処理試行（最大3回）
    ↓ 全て失敗
[SQS デッドレターキュー]
    ↓ アラーム通知
[CloudWatch Alarm → SNS → 運用チームに通知]

DLQ設計のベストプラクティス

SES案件の運用設計で必ず問われるポイントです。

maxReceiveCountは3〜5回に設定: 少なすぎると一時的なエラーで即DLQ行き、多すぎると障害の検知が遅れる
DLQのメッセージ保持期間は長めに: メインキューより長い保持期間（例: 14日）を設定し、調査時間を確保する
CloudWatchアラームでDLQを監視: ApproximateNumberOfMessagesVisible > 0 でアラートを飛ばす
リドライブ機能を活用: DLQからメインキューにメッセージを戻す機能で、修正後の再処理を効率化する

// CloudFormationでDLQ付きキューを定義する例
const mainQueue = {
  Type: "AWS::SQS::Queue",
  Properties: {
    QueueName: "order-processing-queue",
    VisibilityTimeout: 300,
    RedrivePolicy: JSON.stringify({
      deadLetterTargetArn: { "Fn::GetAtt": ["DLQ", "Arn"] },
      maxReceiveCount: 3
    })
  }
};

const dlq = {
  Type: "AWS::SQS::Queue",
  Properties: {
    QueueName: "order-processing-dlq",
    MessageRetentionPeriod: 1209600  // 14日間
  }
};

Lambda連携のベストプラクティス

SQS × Lambda

SQSをLambdaのイベントソースとして設定すると、自動的にポーリングしてメッセージを取得します。

設計時の注意点：

設定項目	推奨値	理由
バッチサイズ	10	スループットとレイテンシのバランス
バッチウィンドウ	5秒	バッチサイズに満たない場合の最大待機時間
同時実行数	予約する	下流サービスへの過負荷防止
部分バッチレスポンス	有効	失敗したメッセージだけ再処理

部分バッチレスポンスは特に重要です。有効にしないと、バッチ内の1件が失敗するだけで全メッセージが再処理されます。

// 部分バッチレスポンス対応のLambda
export const handler = async (event) => {
  const failedItems = [];

  for (const record of event.Records) {
    try {
      const body = JSON.parse(record.body);
      await processOrder(body);
    } catch (error) {
      console.error(`処理失敗: ${record.messageId}`, error);
      failedItems.push({ itemIdentifier: record.messageId });
    }
  }

  return { batchItemFailures: failedItems };
};

SNS × Lambda

SNSはLambdaを直接トリガーできますが、SQSを間に挟むことを推奨します。理由は以下の通りです。

リトライ制御: SNS→Lambda直接だと、Lambda失敗時のリトライがSNS側の制御（最大3回）になる。SQSを挟めばDLQで失敗メッセージを管理できる
スロットリング対策: 大量メッセージが同時に来た場合、SQSがバッファとなりLambdaの同時実行数を制御できる
メッセージの永続化: SNS→Lambda直接だとLambdaがダウンしている間のメッセージが消失する可能性がある

SES案件では「どのサービスを使うべきか」を判断する力が求められます。

要件	推奨サービス	理由
1対1の非同期処理	SQS	シンプルなキューイング
1対多の同時配信	SNS	Fan-outパターン
複雑なルーティング	EventBridge	コンテンツベースのルーティング
順序保証が必要	SQS FIFO	厳密な順序制御
クロスアカウント連携	SNS or EventBridge	IAMポリシーで制御
大量データストリーミング	Kinesis	高スループット順序付きストリーム

💡 面接対策: 「なぜこのサービスを選んだか」を技術要件とビジネス要件の両面から説明できると、設計力の高さをアピールできます。

コスト最適化の実践

SQSの料金構造（東京リージョン）

最初の100万リクエスト/月: 無料
以降: $0.40 / 100万リクエスト（標準キュー）
FIFOキュー: $0.50 / 100万リクエスト

SNSの料金構造（東京リージョン）

最初の100万パブリッシュ/月: 無料
以降: $0.50 / 100万パブリッシュ
SQS/Lambda/HTTP配信: 無料
SMS: 送信先国による従量課金

コスト削減の3つのポイント

1. バッチ送信を活用する

SQSのSendMessageBatchは最大10メッセージを1リクエストで送信でき、APIコールを最大90%削減できます。

2. ロングポーリングを有効にする

SQSのWaitTimeSecondsを20秒に設定すると、空のレスポンス（＝無駄なAPIコール）を大幅に削減できます。

// ロングポーリングの設定（手動ポーリング時）
const result = await sqsClient.send(new ReceiveMessageCommand({
  QueueUrl: queueUrl,
  MaxNumberOfMessages: 10,
  WaitTimeSeconds: 20  // 最大20秒待機
}));

3. メッセージフィルタリングで不要な配信を防ぐ

SNSのサブスクリプションフィルタを活用し、不要なメッセージがSQSやLambdaに配信されないようにします。フィルタリングされたメッセージには課金されません。

SES案件でのメッセージング面接対策

よく聞かれる質問と回答例

Q: SQSとSNSの違いを教えてください

A: SQSはポイント・トゥ・ポイントのメッセージキューで、1つのメッセージを1つのコンシューマーが処理します。SNSはPub/Sub型で、1つのメッセージを複数のサブスクライバーに同時配信します。1対1ならSQS、1対多ならSNSが基本です。

Q: メッセージの順序保証が必要な場合はどうしますか？

A: SQS FIFOキューを使用します。メッセージグループIDを指定することで、同じグループ内の順序を保証しつつ、異なるグループは並列処理が可能です。ただしスループットが300メッセージ/秒に制限されるため、要件に応じた設計が必要です。

Q: メッセージが失われないようにするにはどうしますか？

A: 3つの対策を組み合わせます。①DLQで処理失敗メッセージを退避、②メッセージの保持期間を適切に設定（デフォルト4日、最大14日）、③SNS→Lambda直接ではなくSQSを間に挟んでメッセージを永続化。さらにCloudWatchアラームでDLQの監視を行い、障害を早期検知します。

まとめ：メッセージングスキルでマイクロサービス案件を狙おう

SQS・SNSは、マイクロサービスアーキテクチャの普及とともにSES案件で必須のスキルになりつつあります。

この記事のポイントを振り返りましょう：

SQSは非同期キュー、SNSはPub/Sub通知——役割を理解して使い分ける
Fan-outパターン（SNS + SQS）はマイクロサービス連携の基本設計
デッドレターキュー（DLQ）で障害に強いメッセージング基盤を構築する
Lambda連携では部分バッチレスポンスとSQSバッファを活用する
コスト最適化はバッチ送信・ロングポーリング・フィルタリングの3本柱

まずはAWS公式のSQSチュートリアルで手を動かし、Fan-outパターンを実際に構築してみましょう。サーバーレス構成全体を学びたい方は、Ep2: サーバーレス案件ガイドやEp8: DynamoDB入門もあわせてご覧ください。

出典・参考文献: