【2026年最新版】AWS IoT CoreシャドウVersion Conflictの原因と対処法【完全ガイド】

公開日：2026/04/16　更新日：2026/04/16　

※本ページにはプロモーション(広告)が含まれています

AWS IoT CoreでMQTTデバイスシャドウを活用しているとき、突然「Version Conflict」エラーが発生してデバイスの状態更新が止まった経験はありませんか？

デバイスシャドウのVersion Conflictは、IoTシステムの安定稼働を妨げる代表的な問題のひとつです。複数のデバイスや複数のマイクロサービスから同時にシャドウを更新しようとするシステムほど、このエラーに悩まされやすくなります。本記事では、シャドウドキュメントのVersion Conflictの仕組みから原因、実践的な対処法まで徹底解説します。

この記事でわかること

AWS IoT Coreのデバイスシャドウとは何か
Version Conflictエラーが発生する仕組み
よくある原因パターン（単一デバイス / 複数クライアント / Lambda関数）
楽観的ロック・リトライ戦略での解決方法
Named Shadowを活用した分離設計

AWS IoT Coreデバイスシャドウの基礎知識

デバイスシャドウとは

AWS IoT Coreのデバイスシャドウ（Device Shadow）は、物理デバイスの状態をクラウド上に仮想的に保持する仕組みです。デバイスがオフラインでも、シャドウに対してコマンドを送ることで、次回オンライン時に状態を同期させることができます。

シャドウドキュメントはJSON形式で、reported（デバイスが報告した現在状態）とdesired（クラウドが設定したい目標状態）の2つのセクションで構成されます。

シャドウドキュメントの構造

{
  "state": {
    "reported": {
      "temperature": 22.5,
      "led": "off"
    },
    "desired": {
      "led": "on"
    }
  },
  "metadata": {...},
  "version": 15,
  "timestamp": 1713200000
}

ここで重要なのが "version" フィールドです。シャドウが更新されるたびに自動でインクリメントされ、楽観的ロックの基準として機能します。

Version Conflictとは何か

シャドウへのUPDATE/DELETEリクエストに "version" フィールドを含めた場合、IoT Coreはサーバー上の最新バージョンと照合します。リクエストのバージョンがサーバー上のバージョンより古い場合、以下のエラーレスポンスが返ります。

// $aws/things/{thingName}/shadow/update/rejected トピックに届くメッセージ
{
  "code": 409,
  "message": "Version conflict"
}

Version Conflictが発生する原因パターン

パターン1: デバイスのキャッシュしたバージョンが古い

最も多い原因です。デバイスがシャドウを取得したタイミングのバージョン番号をキャッシュし、しばらく後に同じバージョン番号でUPDATEリクエストを送ったケースです。その間に別のクライアントがシャドウを更新していると、バージョンが合わなくなります。

パターン2: 複数クライアントからの同時更新

Webアプリ、モバイルアプリ、Lambdaバックエンドなど、複数のクライアントが同じシャドウを同時に更新しようとする設計の場合に発生します。どちらかが先に成功し、もう一方は古いバージョンになってConflictします。

パターン3: Lambda関数のリトライによる二重実行

IoTルールでLambda関数をトリガーしている場合、Lambdaのリトライポリシーによって同じメッセージが2回処理されることがあります。1回目の処理でシャドウが更新されると、2回目の処理（同じバージョン番号を持つ）がConflictします。

パターン4: OTA更新中のシャドウ競合

AWS IoTのジョブ機能を使ってOTA（Over-The-Air）アップデートを実行中、ジョブの進捗状態とデバイスシャドウの両方を更新するロジックが衝突することがあります。

パターン5: Named Shadow未使用による用途混在

Named Shadow（名前付きシャドウ）を使わずに、デフォルトシャドウに複数の用途のデータを詰め込むと、異なるマイクロサービスが同じシャドウを頻繁に更新することになり、競合が増加します。

Version Conflictの対処法

対処法1: versionフィールドを省略する（最もシンプル）

シャドウUPDATEリクエストに "version" を含めない場合、IoT Coreはバージョンチェックを行わずに更新を受け付けます。競合チェックが不要なシステムではこの方法が最も簡単です。

// ❌ バージョンを含めると Conflict する可能性がある
{
  "state": {"desired": {"led": "on"}},
  "version": 15
}

// ✅ バージョンを省略すると常に受け付けられる
{
  "state": {"desired": {"led": "on"}}
}

注意: この方法は「最後の書き込みが勝つ（Last Write Wins）」セマンティクスになります。互いの更新内容が独立している場合は問題ありませんが、依存関係がある場合は後述の楽観的ロック戦略を使ってください。

対処法2: 楽観的ロック + 指数バックオフリトライ

バージョンを使った整合性チェックが必要な場合は、Conflictが発生したら最新のシャドウを再取得してリトライするロジックを実装します。

import boto3
import time
import json

iot_data = boto3.client('iot-data', region_name='ap-northeast-1')

def update_shadow_with_retry(thing_name, desired_state, max_retries=5):
    for attempt in range(max_retries):
        try:
            # 最新シャドウを取得
            response = iot_data.get_thing_shadow(thingName=thing_name)
            shadow = json.loads(response['payload'].read())
            current_version = shadow['version']

            # 取得したバージョンでUPDATE
            payload = {
                "state": {"desired": desired_state},
                "version": current_version
            }
            iot_data.update_thing_shadow(
                thingName=thing_name,
                payload=json.dumps(payload)
            )
            print(f"成功: バージョン {current_version}")
            return True

        except iot_data.exceptions.ConflictException:
            wait = (2 ** attempt) * 0.5  # 指数バックオフ: 0.5, 1, 2, 4, 8秒
            print(f"Version Conflict (試行{attempt+1}). {wait}秒後リトライ")
            time.sleep(wait)

    raise Exception(f"{max_retries}回リトライ後も失敗")

# 使用例
update_shadow_with_retry('my-device-001', {"led": "on", "brightness": 80})

対処法3: Named Shadowで用途を分離する

1つのデバイスに複数の用途のシャドウデータがある場合、Named Shadowで分離することでConflict頻度を大幅に削減できます。

# デフォルトシャドウ: デバイス基本状態
$aws/things/{thingName}/shadow/update

# Named Shadow: 照明制御用
$aws/things/{thingName}/shadow/name/lighting/update

# Named Shadow: センサーデータ用
$aws/things/{thingName}/shadow/name/sensors/update

# Named Shadow: OTAジョブ用
$aws/things/{thingName}/shadow/name/ota/update

Python（boto3）でNamed Shadowを操作する場合：

# Named Shadow の取得
response = iot_data.get_thing_shadow(
    thingName='my-device-001',
    shadowName='lighting'
)

# Named Shadow の更新
iot_data.update_thing_shadow(
    thingName='my-device-001',
    shadowName='lighting',
    payload=json.dumps({"state": {"desired": {"led": "on"}}})
)

対処法4: IoTルールのSQSキューイング

複数のデータソースからシャドウを更新する場合、SQSキューを経由してシリアライズすることでConflictを防げます。

各クライアントはシャドウを直接更新せず、SQSキューにメッセージを送信
Lambda関数がSQSから1件ずつメッセージを取り出してシャドウを更新
Conflictが発生しても、Lambda側でリトライロジックを一元管理できる

対処法5: デバイス側のDelta処理を改善する

デバイスは $aws/things/{thingName}/shadow/update/delta トピックを購読し、desired と reported の差分のみを受け取って処理するパターンが推奨されています。シャドウ全体を取得してから更新するのではなく、差分のみに反応することでバージョン競合を最小化できます。

エラーパターン別の対処法まとめ

エラー発生シナリオ	推奨対処法	難易度
単一デバイスからの更新	version省略またはDelta購読	低
複数クライアントからの同時更新	楽観的ロック + リトライまたはSQSキュー	中
Lambdaのリトライによる二重実行	冪等性確保 + version省略	中
用途の異なるデータが混在	Named Shadowで分離	低〜中
OTA更新中の競合	OTA専用Named Shadow + 指数バックオフ	高

CloudWatchでVersion Conflictを監視する

AWS CloudWatchのIoTメトリクスを使うと、Version Conflictの発生頻度をリアルタイムで監視できます。

aws cloudwatch get-metric-statistics \
  --namespace AWS/IoT \
  --metric-name UpdateShadowThrottled \
  --dimensions Name=Protocol,Value=MQTT \
  --start-time 2026-04-15T00:00:00Z \
  --end-time 2026-04-16T00:00:00Z \
  --period 3600 \
  --statistics Sum

また、IoTルールを使って $aws/things/+/shadow/update/rejected トピックを監視し、拒否メッセージをSNSに転送してアラートを送る設定もおすすめです。

システム設計で避けるべきアンチパターン

アンチパターン	問題点	正しい設計
シャドウにセンサーデータを高頻度で書き込む	スロットリングとConflictが多発	Kinesis Data Streamsへ直接送信
シャドウに大量のフィールドを詰め込む	更新頻度が増え競合しやすい	Named Shadowで用途別に分離
version を静的にハードコード	常にConflictする	取得したシャドウのversionを使う
リトライなしで1回だけ更新を試みる	Conflictで更新が無視される	指数バックオフでリトライ

🛒

この記事に関連するおすすめ商品

AWS IoT 実践ガイドブック

約3,500円〜

IoT Core・デバイスシャドウの設計から運用まで

🛒 Amazonで探す

Raspberry Pi IoT開発キット

約8,000円〜

AWS IoT CoreとMQTT接続の学習に最適

🛒 Amazonで探す

クラウドアーキテクチャ設計パターン本

約4,000円〜

楽観的ロック・冪等性など分散システム設計の基礎

🛒 Amazonで探す

※ 価格は変動します。最新価格はリンク先でご確認ください

よくある質問（FAQ）

Q: Version Conflictが発生しても、シャドウは壊れませんか？

A: 壊れません。Version Conflictは「楽観的ロックの失敗」であり、拒否されたUPDATEはシャドウに適用されないだけです。現在のシャドウ状態は変わらずサーバー上に保持されています。エラーを受け取ったクライアントが最新シャドウを再取得してリトライすれば問題ありません。

Q: version番号はいつリセットされますか？

A: シャドウドキュメントを削除して再作成すると、バージョンは1にリセットされます。通常の運用ではリセットされず、更新のたびにインクリメントされ続けます。

Q: MQTTとHTTPどちらで更新しても同じConflictエラーが返りますか？

A: はい、MQTT（パブリッシュ/サブスクライブ）でもHTTP REST API経由でも同一の楽観的ロック機構が適用されます。MQTTの場合は $aws/things/{thingName}/shadow/update/rejected トピックでエラーを受け取り、HTTP APIの場合はステータスコード409が返ります。