この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

MQTT v3でAWS IoT CoreにCBOR形式のペイロードを送る話。デバイス側でJSONの代わりにCBORエンコードして送信するのは普通にできる。MQTT自体はペイロードの中身に制限を持たないプロトコルなので、v3.1.1でもCBORでもバイナリでも何でも通る。

やってみて引っかかったのが、AWS IoT Coreの挙動。IoT Core（ブローカー部分）はペイロードの中身を一切解釈しない。JSONだろうがCBORだろうがJPEGだろうが、届いたバイト列をそのまま右から左へ中継するだけ。

ここで一瞬「じゃあCBORにしたところで通信量削減にはならないのでは」と思った。でもこれは勘違いで、「解釈しない」のと「サイズが変わらない」のは別の話。IoT Coreが中身を見ないのは事実だが、実際に流れるバイト数はエンコード方式に依存する。CBORはJSONより表現がコンパクトなので、同じデータでも送信バイト数自体は減る。IoT Coreが解釈するかどうかとは無関係に、ネットワーク上を流れる量は軽くなる。

整理するとこんな感じ。

flowchart TD
    A[Device] -->|CBOR binary| B[AWS IoT Core broker]
    B -->|そのまま中継| C[Rule Engine]
    B -->|そのまま中継| D[Lambda]
    C -->|JSON解析のみ対応| E[CBORは処理不可]
    D -->|デコード処理を実装| F[CBORを利用可能]

ただし制約もある。IoT CoreのルールエンジンはSELECT *のようなSQL風の構文でペイロードを解析する機能を持つが、これはJSONにしか対応していない。CBORで送ると、ルールエンジン側での中身の解析はできない。ペイロードが必要なのはあくまで後段（Lambdaなど）でデコードしてから、という設計になる。

Kinesisに流す場合やS3に保存する場合も同様で、CBORのままバイナリとして保存されるだけ。中身を扱いたければ別途デコード処理を書く必要がある。

まとめると、AWS IoT CoreがCBORを「理解しない」のは本当だが、通信量が減らないという意味ではない。通信の軽量化にはCBORはそのまま効く。代わりに失うのは、ルールエンジンでの中身ベースのフィルタリングや変換ができなくなる点で、そこはLambda側の処理として作り込む前提になる。