TL Terralien
Application Integration

Amazon SQS

メッセージを溜めて消費者が自分のペースで処理するキュー。AIP-C01では「FM呼び出しをSDK経由で非同期化する」ときの標準部品として、可視性タイムアウトとモデルの生成時間の衝突が主な出題点になります。

  • B｜実装まわり
  • D2 実装と統合
  • D4 運用効率と最適化

最終更新: 2026年8月18日

ひとことで言うと

送信者と受信者を時間的に切り離すメッセージキューです。受け取ったメッセージは可視性タイムアウトの間だけ他の消費者から見えなくなり、処理が終わったら削除します。AIP-C01では「同期でモデルを呼ぶと待たせすぎる」場面の標準的な逃げ道として出てきます。

要するに、整理券つきの待合室です。リクエストをキューに積んでおけば、呼び出し元はすぐ解放されます。ワーカーが空いたタイミングで取り出して処理する。整理券には「処理中は他の人に渡さない」ための有効期限（可視性タイムアウト）があり、その期限内に処理が終わらないと、また誰かの手に渡ってしまいます。

なぜ生まれたか

Bedrock APIの同期呼び出しは、API Gatewayの統合タイムアウトやクライアントの待機許容時間を超えることがあります。SDK＋SQSによる非同期化は、この待ち時間の問題を「キューに積んで後で拾う」形に変える定石です。

摩擦SQS 側の受け皿
FM呼び出しの完了を同期で待たせられないリクエストをキューに積み、ワーカーが非同期に処理
処理に失敗したリクエストを握りつぶしたくない再試行の失敗回数を超えたメッセージをデッドレターキュー（DLQ）へ
モデルの処理時間が可視性タイムアウトを超えるChangeMessageVisibilityで動的に延長（ハートビート方式）

何に使うか

用途使い方関連ドメイン
FM呼び出しの非同期化クライアント→SQS→ワーカーがBedrockを呼び結果を返すD2
失敗したリクエストの隔離DLQで異常系だけ分離して原因調査D2, D5
バッチでの推論要求の平準化メッセージバッチ（最大10件）でAPI呼び出し回数を削減D4

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
モデル呼び出しが可視性タイムアウトの間に終わらないことがある処理中にChangeMessageVisibilityで延長する（最大12時間まで）可視性タイムアウトを最初から極端に長く固定する（他の障害時に再試行が遅れる）
同じリクエストが二重処理されているat-least-once配信の前提を理解し、処理側を冪等に作るSQS側の設定だけで重複配信を完全に無くそうとする（標準キューでは保証されない）
処理順序を厳密に守りたいFIFOキュー＋メッセージグループID標準キューのままアプリ側で順序を担保しようとする
何度失敗しても消えないリクエストを分離したいデッドレターキュー（DLQ）可視性タイムアウトを無限に伸ばして握りつぶす

可視性タイムアウトの延長には上限があります。最初にメッセージを受信してから12時間が絶対の上限で、ChangeMessageVisibilityで延長してもこの上限はリセットされません。長時間かかるバッチ推論やモデル評価をSQSのワーカーパターンに乗せる場合、12時間を超える処理はStep Functionsなど別の仕組みに分割する必要があります。

実務でどう使うか

  • メッセージサイズの上限は1MiB（1,048,576バイト）です。 プロンプトや大きめのコンテキストをそのままメッセージ本文に載せると簡単に超えます。実務ではS3にペイロードを置き、SQSメッセージには参照（S3キー）だけを載せる設計が定石です
  • 可視性タイムアウトの既定は30秒です。 モデル呼び出しは数秒〜数十秒かかることが普通なので、既定のままだと処理中に別のワーカーに再配信されてしまいます。処理時間の実測に合わせて調整するか、ハートビートで延長します
  • バッチ処理（送信・受信・削除を最大10件まとめる）でAPI呼び出し回数を削減できます。 コスト最適化（D4）の文脈では、ロングポーリングと組み合わせて空振りの呼び出しを減らすのが基本

標準キューはat-least-once配信です。ネットワーク分断などで同じメッセージが複数回届くことがあるため、ワーカー側の処理は冪等に作る必要があります。「SQSが重複を防いでくれる」という前提で設計すると、モデル呼び出しの二重課金や重複した副作用（通知の二重送信など）につながります。

取り違えやすいもの

迷う相手切り分けの一言
Amazon SNSSQSは受け取ったメッセージを溜めて消費者が自分のペースで処理するキュー。SNSは登録済み購読者全員に即時配信するpub/sub
Step FunctionsSQSは「順番に取り出して処理する」単純な待合室。Step Functionsは複数ステップの状態遷移・分岐・タイムアウト管理まで持つワークフローエンジン。処理が12時間を超える、または複雑な分岐があるならStep Functions側
EventBridgeSQSはポイントの先で溜めるキュー。EventBridgeは条件でルーティングする配送層。SNS/EventBridgeの先にSQSを置くfan-out構成もよく使われる

想起チェック

Q1. モデルの生成処理が可視性タイムアウトの30秒を超えそうなとき、何をする？

ChangeMessageVisibility でタイムアウトを動的に延長します（ハートビート方式）。ただし最初の受信から12時間が絶対の上限で、これを超える処理はSQS単体では扱えません。

Q2. プロンプトと生成結果を含む2MBのペイロードをSQSでやり取りしたい。どう設計する？

そのままでは1MiBの上限を超えます。ペイロードをS3に置き、SQSメッセージには参照（S3キーなど）だけを載せる設計にします。

出典（AWS公式）