まずは一言愚痴らせてほしい。工場は認証を真剣に考えていない。全然だ。
今年の3月、私は画面付きのスマートプラグを一ロット仕入れ、Amazonに出品する準備をしていた。商品が米国西海岸の倉庫に届いたばかりのとき、工場は何も言わずにOTAアップデートを配信した。専用アプリに「電力統計」ページが追加され、WiFiセットアップの流れも変わっていた。私は気にしなかった。ハードウェアは無傷だ。単なるソフトウェアのUI刷新。何が問題になるというのか？
ところが4月初め、大口のバイヤーが発注前にこう聞いてきた。「あなたのFCC認可は、このファームウェアバージョンでもまだ有効ですか？」
凍りついた。
工場に電話した。相手は断言した。「ハードは変わっていない。認証は間違いなく有効だ。安心して売ってくれ」。私は信じなかった。元の認証を担当したラボに戻った。そこのエンジニアの一言で目が覚めた。「ハードが無傷でも、認証が無傷とは限らない。認可はハードウェア単体ではなく、ハードウェアとソフトウェアの組み合わせに対して発行されるものだ。まず、このOTAが実際に何を変えたのか教えてくれ」。
この記事のテーマはまさにそこにある。ソフトウェアの変更がコンプライアンスの境界を越えるのはどこなのか。
私が取った行動
ネタバレ：そのロットは問題なかった。しかし全プロセスを踏んだ後でないと、販売を続ける気にはなれなかった。
ステップ1：工場から変更履歴を入手する。聞くではなく、入手だ。工場は最初「UIのちょっとした調整だけ」と言ったので、私はこう返した。「項目別の変更リストを送ってくれ」。5年間工場と付き合って学んだことが一つある。口頭の「小さな変更」は、たいてい3〜4項目に化ける。
リストには、UI刷新と電力統計ページに加え、セットアップフローの変更が載っていた。ペアリング時にデバイスは2.4 GHzだけを発信していたが、今は両方のバンドをスキャンするようになっていた。
ステップ2：リストをラボに持ち込み、ギャップアセスメントを依頼する。私が持って行ったのは3点。工場の変更履歴、元の認可書類、各ファームウェアバージョンの説明だ。エンジニアの言葉は今でも正確に覚えている。「RF放射に影響しない純粋なUI変更には、証明書上の対応は不要です。ただ、ペアリングフローが変わった。これは放射特性を変える可能性がある。その場合はFCCの変更手続きに従います」。
その場で学んだポイント：FCC規則47 CFR 2.1043はこの点についてかなり明確だ。RF放射に影響しないソフトウェア変更には追加の届出は不要。RF放射特性に触れるものはすべて、パーミッシブチェンジ（許可変更）のプロセスを通す。クラスIかクラスIIかは変更の内容によるので、FCCの最新の公開ポリシーを確認してほしい。これはセラーの体験談であり、法的助言ではない。
ステップ3：工場が技術文書を提供し、ラボが変更を届け出、数週間後に更新された書類が届いた。その後初めて、良心にやましいところなく大口バイヤーにロットを出した。
この一件で得た最も重要な教訓：ハードが無傷でも、認証が無傷とは限らない。 直感に反するが、事実だ。認可は特定のハードウェア＋ソフトウェアの組み合わせに対して発行された。ソフトウェアをある程度変えれば、組み合わせも一緒に変わる。
警告の物語：失われた2か月
私の話はハッピーエンドだったので、バランスを取るために他の人の惨事を紹介しよう。
2025年後半、深センの同業セラーLao Chenはスマートライトを売っている。OTAアップデートで、彼のデバイスは2.4 GHz専用から5 GHz対応のデュアルバンドになった。彼の考え：全部WiFi、バンドが一つ増えただけ。だが5 GHzの放射パラメータは元の認可申請と合わなくなり、証明書は棚に並ぶ製品と一致しなくなった。
Amazonのコンプライアンス審査で、彼の出品は「販売中のバージョンとコンプライアンス書類が一致しない」という理由で取り下げられた。再認証と再提出に2か月以上かかり、繁忙期を直撃した。Lao Chenは言った。あの2か月で逃した利益は、認証10回分の費用になった、と。
パターンは見えたか？ 失うのは認証費用ではない。時間だ。出品が停止している毎日が、二度と戻らない売上だ。
数字で見る：私の変更分類フレームワーク
この二つの一件の後、私は判断フレームワークを作った。今では工場のOTAはすべてこれにかける。3分で、答えは一つ。
| 変更の種類 | 例 | リスク | 私の対応 | | 純粋なUI | アイコン、色、文言、レイアウト | 低 | 内部に記録。どのファームウェアバージョンがどの認可に対応するかを記録する | | アプリ層の新機能 | 電力統計、タイマー、シーン自動化 | 中 | RFや安全ロジックに触れないことをラボに確認してもらう | | RF関連 | ペアリングフロー、送信出力、新バンド、アンテナ特性 | 高 | 認証機関から書面で確認。正式な変更届出を想定する | | 安全関連 | 過負荷保護ロジック、チャイルドロック、漏電保護 | 高 | 全面再評価。安全関連ソフトウェアにはULの固有要件があるため、ULの最新の公開ポリシーを確認する |
順序が重要だ。まず分類、次に確認、そして書面記録。 先に売って後で整理するようなことはしない。
ラボとの付き合い方について、もう一つ実用的な注意点。持ち込むのは、変更履歴、元の認可書類、各ファームウェアバージョンの違いを平易に説明した資料の3点だ。ラボは時間単価で課金される。準備万端で持ち込めば評価時間は半分になるし、エンジニアに「この人は本気だ」と伝わり、率直な回答が返ってくる。
汗で学んだ4つのルール
その1：契約に入れる。工場はOTAの前に必ず書面で事前通知し、変更リストを添付すること。無通知でアップデートを配信したら契約違反。この条項は今や私が交わすすべての工場契約に初日から標準で入っている。
その2：OTAごとに変更履歴を要求し、分類ごとに保管する。口頭の「大して変わっていない」は未提供と同じだ。書面になければ、起きていないのと同じ。
その3：工場の口頭の「大丈夫」は絶対に信じない。認証機関かラボから書面をもらう。メールで十分だ。いざというとき、紙は音声メッセージに必ず勝つ。
その4：ファームウェアバージョンと認可の対応表を作る。バージョン番号、OTA日、認可番号、評価結果。スプレッドシートの4列だ。バイヤーに聞かれたら、この表を送る。
自分で試した。効く。先月、別のバイヤーが証明書の質問を出してきて、私は3分で対応表を送った。バイヤーは読んだ直後に発注した。このスプレッドシートは、どんな営業トークより売る。コンプライアンスは、受注の決め手になる日が来るまで、ただのコスト項目に見える。
Ah K（Eコマース販売者、5年）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
