Chapter 22
認証と製品化 — CSA 認証・VID/PID・量産
この章がなぜ必要なのか——ここを知らずに開発を始めると、必ず遅延する.
「Matter 対応」を名乗るには、CSA の会員資格と製品認証が必要である。 ロゴを使うのも同様。
そして手続きには時間がかかる。VID の取得、証明書の調達、 テストの実施、認証の申請——数か月単位のリードタイムを見込む必要がある。
「ソフトが完成したら認証を取ろう」では間に合わない。 開発の最初に手続きを開始するのが正しい進め方である。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、コミッショニング（01 章 3 節）、セキュリティ（01 章 2 節）、ネットワーク（01 章 3 節）、ACL（02 章 4 節）、IPv6（02 章 1 節）、データモデル（02 章 1 節）、Router（04 章 2 節）、Wi-Fi（04 章 9 節）、必要（05 章 5 節）、FeatureMap（07 章 2 節）、Fail-Safe（09 章 9 節）、証明書（11 章 5 節）、CSA（12 章 3 節）、DAC（12 章 11 節）、DCL（12 章 11 節）、委託製造（12 章 7 節）、RAM（16 章 3 節）、Flash（17 章 1 節）、認証実績（17 章 1 節）、Apple（20 章 1 節）、仕様書（21 章 8 節）
1. CSA 会員資格
| レベル | 概要 |
|---|---|
| Adopter | 仕様を実装し、認証製品を出せる。最も基本的な参加形態 |
| Participant | 加えて、仕様策定のワーキンググループに参加できる |
| Promoter | 理事会レベル。標準の方向性に関与する |
製品を出すには最低でも Adopter が必要である（年会費がかかる）。 VID の割り当ても会員資格に紐づく。
仕様書自体は誰でも無償で読めるが、 「Matter 対応」を名乗り、ロゴを使い、認証を取るには会員である必要がある。 ここは技術ではなく契約の話なので、法務・調達部門との連携が要る。
2. VID / PID
| ID | 割り当て |
|---|---|
| VID（Vendor ID、16 bit） | CSA が会員に割り当てる。1 社に 1 つ（複数取得も可） |
| PID（Product ID、16 bit） | メーカーが自由に決める。社内で管理する |
VID の取得を最優先で行うこと.
VID がないと:
- DAC / PAI が発行できない（12 章）
- CD が取得できない
- 認証申請ができない
開発初期にテスト VID（
0xFFF1〜0xFFF4）で進めるのは正しいが、 正式な VID の申請は並行して進めておく。
PID の設計
PID は社内で体系立てて管理すること.
- 製品ラインごとに範囲を分ける
- 派生モデル（色違い、地域違い）をどう扱うか決める
- 一度出荷した PID は変えられない（DAC に焼かれている）
CD は「VID + PID のリスト」に対して発行されるので、 PID を増やすたびに CD の再取得が必要になる場合がある。 認証の単位とも関わるので、製品企画の段階で設計する。
3. 認証プロセスの全体像
[1] CSA 会員登録、VID 取得
↓
[2] 開発（テスト VID で進める）
↓
[3] 仕様バージョンの決定（どの版で認証を取るか）
↓
[4] 社内テスト（Test Harness で事前検証）
↓
[5] 証明書の調達（PAI / DAC の発行体制、[12 章](12_デバイス認証と証明書.md)）
↓
[6] CD の取得（CSA に VID/PID を申請）
↓
[7] 認証テストの実施
├── 認定試験所（ATL）に依頼、または
└── 自己試験（対象と条件は CSA の規定による）
↓
[8] CSA に認証申請、審査
↓
[9] 認証取得、DCL への登録
↓
[10] 各エコシステムでの動作確認（別途）
↓
[11] 出荷[10] が忘れられやすい. CSA の認証を取っても、各エコシステムが自社ハブで動作を確認する 独自のプログラムを持っている場合がある。 「Works with Apple Home」といったバッジは、それぞれ別の手続きである。
どのエコシステムを対象にするかを早期に決め、それぞれの要件を確認すること。
4. Test Harness（テストハーネス）
CSA が提供する認証テストの実行環境。認証と同じテストを社内で回せる。
| 構成 | 内容 |
|---|---|
| 実行環境 | Raspberry Pi や Linux PC 上のコンテナ |
| テストケース | Test Plans リポジトリで公開されている |
| 対象 | データモデル、インタラクション、コミッショニング、セキュリティ、各クラスタ |
| 出力 | 合否レポート |
Test Harness を早期に導入すること。これが最大の実務的アドバイスである。
認証直前に初めて走らせると、大量に落ちて手戻りになる。 開発の途中から定期的に回していれば、少しずつ直せる。
テストケースは公開されているので、 「何を確認されるか」を事前に読める。 Device Library の必須クラスタと、テストケースの対応を確認しておくこと。
よく落ちる項目
| 項目 | 内容 |
|---|---|
| 必須属性・コマンドの欠落 | Device Library の M を満たしていない |
| FeatureMap と実装の不一致 | 宣言したが動かない（08 章） |
| 値域・制約の違反 | CONSTRAINT_ERROR を返すべき場面で受け入れてしまう |
| エラーコードの誤り | 適切なステータスを返していない（09 章） |
| Fail-Safe の巻き戻し不備 | 途中で切断したときに戻らない（09 章） |
| マルチアドミン | 複数 Fabric で正しく動かない（14 章） |
| ファクトリリセットの不完全性 | 消え残り（14 章） |
| ACL の実装 | 権限チェックの漏れ |
| サブスクリプションの動作 | MinInterval の遵守、報告の抜け |
| Identify | 反応がない（08 章） |
| DataVersion の管理 | 変更時に増えていない |
5. 証明書の準備（12 章の実務面）
| 項目 | 決めること |
|---|---|
| PAA | CSA のものを使うか、自社で運営するか |
| PAI | 誰が発行するか。製品ラインごとに分けるか |
| DAC の発行体制 | 自社 / PKI ベンダー / SoC ベンダーの事前注入 |
| 鍵の保護 | セキュアエレメント / SoC のセキュア領域 |
| 量産ラインの設計 | 書き込み装置、ネットワーク、記録 |
| CD の取得 | CSA への申請。VID/PID のリスト |
リードタイムの目安（あくまで目安。実際は変動する）:
- CSA 会員登録: 数週間
- VID 取得: 数週間
- PKI ベンダーとの契約・立ち上げ: 1〜数か月
- CD の取得: 数週間
- 認証テスト: 数週間〜（不合格なら再試験）
合計で数か月。 これを製品スケジュールに織り込むこと。
6. 仕様バージョンの選択
どのバージョンで認証を取るかは重要な判断である.
選択 影響 新しい版 新機能が使える。ただしエコシステムの対応が追いついていない可能性 枯れた版 動作実績が多い。ただし新デバイスタイプは使えない 自分の製品カテゴリがどの版で追加されたかを確認すること（24 章）。 1.2 で追加された家電なら、1.0 では認証を取れない。
また SDK のバージョンと仕様バージョンは対応している（15 章）。 開発中に SDK を上げると、認証対象の版が変わることがある。タグで固定する。
7. 量産の準備
Factory Data の書き込み（12・17 章）
| 決めること | 内容 |
|---|---|
| 書き込み方式 | 治具、ツール、所要時間 |
| 鍵の生成場所 | 機器内 / 外部 |
| ネットワーク | 工場が CA と通信するか、オフラインか |
| 記録 | シリアル ↔ 証明書の対応を保存 |
| 不良品 | 発行済み証明書の扱い |
| 委託製造 | EMS に何を渡すか |
品質管理
| 検査項目 | 内容 |
|---|---|
| Factory Data の書き込み確認 | 読み戻して検証 |
| 個体ごとの一意性 | Discriminator、passcode、DAC が重複していないか |
| コミッショニングの実動作 | 抜き取りで実際にペアリングする |
| 無線性能 | 出荷検査 |
| QR コードの印刷品質 | 読み取れるか |
QR コードの印刷品質は見落とされがちである. 小さすぎる、コントラストが低い、曲面に貼る、擦れる—— ユーザーが最初に触れる部分が読めないという事故が起きる。
手動コードを必ず併記すること（13 章）。QR が読めなくても救済できる。
梱包・ドキュメント
- ☐ QR コード（本体と説明書の両方に）
- ☐ 手動ペアリングコード
- ☐ 対応エコシステムの明記
- ☐ Thread 機器なら「Border Router が必要」の明記
- ☐ IPv6 が必要である旨（Wi-Fi 機器）
- ☐ トラブルシューティングの手順（05 章の落とし穴が実際に起きる）
「Border Router が必要」の説明は必須である. Thread 機器を買ったユーザーが、ハブを持っていないために 設定できないという事態は頻繁に起きる（04 章）。 箱の外側に明記すべきである。
8. 出荷後の運用
| 項目 | 内容 |
|---|---|
| OTA の配信体制 | どこにイメージを置き、どう承認されるか（18 章） |
| 脆弱性対応 | 報告受付、修正、配信のプロセス |
| 仕様の更新への追随 | 新しい版への対応判断 |
| エコシステムの変更 | 各社の仕様変更で動かなくなるリスク |
| DCL の更新 | ソフトウェアバージョン情報など |
| サポート | ユーザーからの問い合わせ対応 |
セキュリティ脆弱性への対応体制は事前に整備すること. 「報告を受けてから 3 か月かかりました」では信用を失う。 OTA が動くこと自体が、脆弱性対応能力の前提である（18 章）。
9. チェックリスト
開発開始時
- ☐ CSA 会員登録の手続きを開始
- ☐ VID の申請
- ☐ 対象とする仕様バージョンの決定
- ☐ 対象エコシステムの決定
- ☐ 証明書の調達方針の決定
- ☐ SoC の選定（認証実績を確認、17 章）
- ☐ Flash / RAM の余裕（OTA 込み、17 章）
開発中
- ☐ Test Harness を定期的に実行
- ☐ Device Library に照らして実装漏れをチェック
- ☐ マルチアドミン（3 Fabric 以上）でテスト
- ☐ 電池寿命の実測
- ☐ Factory Data の書き込み方式を製造部門と確定
- ☐ CI にテスト証明書の混入チェック
認証前
- ☐ Test Harness が全項目パス
- ☐ CD の取得
- ☐ 量産ビルドでテスト証明書が入っていないことを確認
- ☐ ファクトリリセットの完全性を確認
- ☐ 各エコシステムでの実機動作確認
出荷前
- ☐ DCL への登録完了
- ☐ OTA の配信体制
- ☐ QR / 手動コードの印刷品質
- ☐ ドキュメント（Border Router の要否、IPv6）
- ☐ サポート体制
10. まとめ
- 「Matter 対応」を名乗るには CSA 会員資格（最低 Adopter）と製品認証が必要。
- VID の取得を最優先。これがないと証明書も CD も認証申請もできない。
- 認証プロセスは 会員登録 → VID → 開発 → CD → テスト → 申請 → DCL 登録。 合計で数か月。開発の最初から並行して進める。
- Test Harness を早期に導入する。直前に回すと大量に落ちて手戻りになる。
- よく落ちるのは **必須クラスタの欠落、FeatureMap の不一致、Fail-Safe、 マルチアドミン、ファクトリリセット、ACL**。
- 仕様バージョンの選択は製品カテゴリと SDK のタグに直結する。
- 量産では Factory Data の書き込み設計と個体の一意性検査が要点。
- QR コードの印刷品質と手動コードの併記を軽視しない。
- Thread 機器は「Border Router が必要」を箱に明記する。
- 出荷後の OTA 配信体制と脆弱性対応プロセスを事前に整備する。