CBORとは｜RFC標準のバイナリJSONとIoT活用を解説

2026年6月4日

CBOR（Concise Binary Object Representation、シーボア）は2013年にRFC 7049として標準化されたバイナリシリアライズ形式で、現行仕様は2020年のRFC 8949に更新されている。MessagePackから派生した設計をもとに、JSONと等価なデータモデルを維持しつつ、IETF標準としての厳密さとIoT／組込領域での運用性を強化した形式だ。WebAuthnのアサーション、COSE（CBOR Object Signing and Encryption）、CoAPなどの規格で内部表現として採用され、IETFエコシステムの共通言語となっている。

この記事の目次

CBORのデータモデルと型タグ
IoT・WebAuthnでの採用例
MessagePackとの違いと選択基準
CBOR運用での注意点
まとめ

CBORのデータモデルと型タグ

CBORのワイヤー表現は3ビットのMajor Typeと5ビットの追加情報で1バイトの先頭を構成する。Major Type 0〜7はそれぞれ正整数・負整数・バイト列・文字列・配列・マップ・タグ・浮動小数／単純値に割り当てられ、可変長は1／2／4／8バイトで追加表現される。この設計によりJSON互換の8型をシンプルにバイナリ化できる。

CBOR独自の機能としてTag（Major Type 6）がある。Tag 0はRFC 3339日時文字列、Tag 1はUNIX時間、Tag 2/3は大整数、Tag 32〜34はURI／base64URLなど、用途ごとに予約番号があり、IANAレジストリで一元管理される。これによりMessagePackで悩む「日付の標準形」をRFCに従って統一できる点が、CBOR採用の大きな動機となる。

IoT・WebAuthnでの採用例

CBORがIoT領域で広く使われる理由は、コンパクトさに加えて「決定的エンコード」（同じデータが常に同じバイト列になる）を仕様で規定できる点にある。COSEで電子署名や暗号化を施す際には、署名対象が一意に決まらないと検証できないため、CBORのCanonical Encodingルールが本質的に重要となる。これはJSON Canonicalizationで苦労してきた領域で大きな利点だ。

WebAuthn／FIDO2では、認証器が返すattestationObjectがCBORで表現される。ブラウザJavaScriptはこれをデコードしてサーバへ送り、サーバ側がCOSE_Keyを解釈して公開鍵を取り出す。CoAP（Constrained Application Protocol）と組み合わせることで、低帯域・低電力デバイス向けのRESTful APIをHTTPより遥かに軽量に実装でき、スマートメーターやセンサーネットワークで採用が広がっている。

MessagePackとの違いと選択基準

CBORとMessagePackは見かけのバイナリ表現が似ているが、設計の出自が異なる。MessagePackはWebアプリ高速化が出発点で、実装の手軽さと速度を重視する。CBORはIETF標準としての厳密さと、IoT・セキュリティ規格との連携を重視し、Tag機構・Canonical Encoding・Indefinite Length表現などより仕様が緻密だ。

選び方の目安として、ストリーミングログや汎用RPCの軽量化が目的ならMessagePack、デバイス間／署名付きメッセージなど規格準拠が必要ならCBOR、と捉えると判断が容易になる。実装ライブラリはRFC 8949対応のものを選び、特にPythonならcbor2、Goならfxamacker/cborといった成熟したライブラリを使うと、Canonical EncodingやTag解釈で躓きにくい。

CBOR運用での注意点

CBORの細部仕様はMessagePackより複雑で、Indefinite Length（長さ不定の連結）やHalf-Precision Float（16bit浮動小数）など、対応していないライブラリではデコード失敗するケースがある。相互運用する場合は事前にプロファイル（CBOR Sequences、CDDLによる型定義など）を合意することが望ましい。

また、Tag番号は将来IANAで拡張される可能性があるため、未知のTagに遭遇した際の挙動（ignoreかerrorか）を実装ポリシーとして決めておく必要がある。WebAuthnで扱う場合、COSE_Keyのkty／alg値の検証を厳密に行わないと暗号アルゴリズムダウングレード攻撃のリスクが残るため、ライブラリ任せにせず仕様書ベースで確認することを強く推奨する。