SQS の CreateQueue は「同名キューが既に存在しても、指定した属性が既存キューと完全一致していれば成功する」という条件付きの冪等性を持つ。属性が一つでも異なると QueueAlreadyExists エラーになる。このため、デプロイスクリプトや環境準備スクリプトで毎回 CreateQueue を呼ぶ設計は、初回と再実行では通るのに「キュー属性の設定値を変更したコミット以降、既存環境への再デプロイだけが落ちる」という壊れ方をする。新規環境では再現しないため、CI 失敗の原因調査で見落としやすい。

破綻パターン

• provisioning スクリプト内の VisibilityTimeout などの値を変更 → 既存環境に再デプロイ → CreateQueue が属性不一致で QueueAlreadyExists。
• 新規に作った環境や、値を変えていないブランチでは成功するため、flaky や環境固有問題に見える。

対処の判断基準

• スクリプトを「キュー URL の取得（get-queue-url 相当）で存在確認 → 存在すれば set-queue-attributes 相当で属性更新、なければ CreateQueue」に分岐させる。
• ただし FifoQueue のように作成時にしか指定できない属性は set-queue-attributes では変更不可。既存キューへは変更可能な属性（VisibilityTimeout 等）だけを渡す。作成時専用属性を変えたい場合はキューの作り直しが必要。
• 削除→再作成による冪等化は採らない。SQS は削除後 60 秒間は同名キューを作成できない制約があり、デプロイが不安定化する。

検証

既存キューがある環境で属性値を変更したスクリプトを再実行し、エラーにならず属性が新しい値へ更新されることを確認する。属性の実値はキュー属性取得 API で照合できる。