LASSIC Media らしくメディア
IoT機器のセキュリティ規制｜JC-STARと海外
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 共通する最低ライン：初期パスワードの扱い、脆弱性の受付窓口、更新をいつまで出すかの明示——各制度で要求が重なります。
- 制度の性格：国内は適合を示すラベリング、英国は売る側への義務、EUは市場に出す条件という違いがあります。
- 開発の実務：個体ごとの初期認証情報、更新の配信経路、部品表と脆弱性の追跡を最初から設計に入れるのが要です。
※ 本記事は2026年8月時点の公式情報（省庁・公的機関・ベンダー公式ドキュメント）に基づきます。
ネットにつながる機器が増えるにつれ、「売る前に満たしておくべきセキュリティの最低ライン」が制度として定められるようになってきました。国内ではラベリング制度が動き出し、英国では販売時の義務が課され、EUでは市場に出す条件として要件が整えられています。
本記事では、IoT機器やその組込みソフトウェアを開発・供給する立場の担当者に向けて、国内制度と海外の枠組みの違い、共通して求められる要件、開発で必要になる実装、そして調達・委託の実務を整理します。制度は改定が続く領域のため、実際の対応は公式資料で確かめながら進めてください。
目次
なぜIoT機器に規制が広がっているのか
背景はシンプルです。つながる機器が増え、その多くが長く使われ、しかも初期設定のまま放置されがちだからです。共通の初期パスワードで出荷された機器が大量に乗っ取られ、他への攻撃に使われる——こうした事例が繰り返された結果、「機器そのものに最低ラインを設ける」という方向へ各国が動きました。
要求の中身を並べてみると、制度をまたいで似通っています。共通の初期パスワードを使わない、脆弱性の報告を受け付ける窓口を公開する、更新をいつまで提供するのかを購入前に分かる形で示す。この三点は、多くの枠組みで最初に挙げられる項目です。したがって、どの市場を狙うかに関係なく、この三つを先に作り込んでおくのが合理的でしょう。
裏を返せば、これらは「作り方の問題」です。あとから足すのが難しいものばかりで、とくに更新の配信経路は、機器の設計段階で組み込んでおかないと後付けが困難です。企画の段階で「何年間、どうやって更新を届けるのか」を決めておくことが、制度対応の実質になります。
国内のJC-STAR——適合を示すラベリングの仕組み
国内では、IPA（情報処理推進機構）が運営する「セキュリティ要件適合評価及びラベリング制度（JC-STAR）」が動いています*1。IoT製品が定められたセキュリティ要件に適合していることを示す仕組みで、調達する側が製品を選ぶときの手がかりになるよう設計されています。
特徴は、段階が設けられている点です。下位の段階では、事業者自身が要件への適合を宣言する形が採られており、比較的取り組みやすくなっています。上位の段階では第三者による確認が入り、示せる水準が上がります。まずは下位から始め、必要に応じて上を目指す——という進め方が想定されている形です。
調達側の視点で見ると、この仕組みは要件書を書く手間を減らします。「JC-STARの該当段階に適合していること」と書けば、細かな要件を一つずつ列挙しなくても水準を伝えられるためです。政府調達や大手企業の調達で参照が広がれば、供給側にとっても対応の意味が明確になります。
供給側としては、自社製品がどの段階を狙うのかを早めに決めておきたいところです。要件への適合を宣言するには、設計と検証の記録が必要になります。開発が終わってから記録を作ろうとすると辻褄合わせになりがちなので、開発の中で自然に残る形にしておくのが確実です。
海外の枠組み——英国の義務とEUの市場条件
海外では、より強い形で要求が課されています。性格の違いを整理しておきましょう。
| 枠組み | 性格 | 供給側に生じる作業 |
|---|---|---|
| 国内のラベリング制度 | 要件への適合を示す仕組み。段階があり、下位は自己適合宣言 | 要件への対応と、適合を示す記録の整備 |
| 英国の製品セキュリティ法（PSTI） | 売る側への義務。最低要件と、適合の宣言・記録の保持を求める | 初期パスワードの扱い、報告受付、更新期間の明示と文書化 |
| EUの製品規則・無線機器の要件 | 市場に出す条件。適合しなければ販売できない | 要件への適合評価と技術文書、脆弱性対応の体制 |
英国の制度は、対象となる機器を売る事業者に対して、最低要件を満たすことと、それを宣言する文書を用意することを求めます*2。要件そのものは前述の三点が中心で、目新しさはありません。ただ「義務」であることの意味は大きく、対応していない製品は流通させられません。
EUについては、無線機器に関する要件と、より横断的な製品規則の両方が関わってきます。後者は対象がソフトウェアを含む製品全般に及ぶ枠組みで、脆弱性対応の期間や報告の義務まで踏み込みます。詳しくはEUサイバーレジリエンス法（CRA）で整理していますが、機器を欧州向けに出すなら早めに見ておきたい領域です。
開発側で必要になる実装
要求を実装に落とすと、次のような作業になります。ハードウェアの制約と絡む部分が多く、後戻りしにくいのが特徴です。
- 個体ごとの初期認証情報：製造時に個体別の値を書き込む、または初回起動時に設定を強制する仕組み
- 更新の配信経路：署名の検証、段階的な配信、失敗時に戻せる構成。通信が細い環境での分割配信も検討
- 部品表と脆弱性の追跡：使用しているライブラリとバージョンの一覧を持ち、公表された脆弱性の影響を調べられる状態
- 報告の受付と対応：連絡窓口の公開、受け付けたあとの調査・修正・公表の流れ
- ログと初期化：異常の記録と、譲渡・廃棄時にデータを消せる機能
とくに部品表の整備は、後から作るのが大変な割に効果が大きい項目です。脆弱性が公表されたとき、「影響するかどうか」を即答できるかで対応の速度が変わります。ここはIT側の議論と共通で、ソフトウェアサプライチェーン対策の考え方をそのまま持ち込めます。
組込み側の実装は、ハードウェアの制約と密接に関わります。鍵をどこに保管するか、更新用の領域を確保できるか、通信の帯域と電力に余裕があるか。設計の初期に決めておく必要があるため、組込み・ファームウェア開発の委託のように、経験のある体制と早い段階で議論するのが得策でしょう。
調達・委託の実務——要件化と証跡の受け渡し
機器を調達する側、開発を委託する側の視点でも、押さえるべき点があります。
第一に、要件を具体的に書くことです。「セキュリティに配慮すること」では実装が決まりません。初期認証情報の方式、更新の提供期間、脆弱性報告への応答時間——このあたりを数字と条件で書き込みます。制度の名前を引いて「該当する要件に適合すること」と書く方法も有効です。
第二に、証跡の受け渡しを決めることです。適合を示す文書、部品表、検証の記録。誰がいつどの形式で渡すのかを契約に含めておくと、後から集める手間が省けます。とくに部品表は、更新のたびに変わるため、受け渡しの頻度も決めておきたいところです。
第三に、サポート期間の合意です。更新をいつまで出すのか。この期間は、制度上の要求だけでなく、調達側の設備更新の周期とも関わります。機器の寿命が10年でも更新提供が3年なら、その差の期間はリスクを抱えることになります。ここは価格と一緒に交渉する項目です。
第四に、再委託先の管理です。ファームウェアの一部を別会社が作っている、通信モジュールを外部から調達している——こうした構成では、要求が末端まで届いているかを確かめる必要があります。委託先・サプライチェーンのセキュリティ管理で扱う仕組みが、ここでも効いてきます。
受託開発で押さえる実務ポイント
受託する立場では、次の三点を見積りと設計の初期に固めておくと、後半の負担が読めるようになります。
第一に、対象市場の確認です。国内だけなのか、欧州や英国にも出すのか。市場によって求められる文書と手続きが変わるため、ここが決まらないと必要な作業量が見積もれません。「将来的に海外も」という場合は、共通部分を先に作っておく設計にします。
第二に、更新の仕組みを最初に作ることです。後から足せない部分であり、かつ制度対応の中核です。署名の検証、配信の段階化、戻し。この三つが動く状態を早い段階で作れば、以降の開発は落ち着いて進められます。
第三に、記録の型を決めることです。要件と検証の対応、部品表、変更の履歴。テンプレートを最初に決め、開発の流れの中で埋まるようにしておきます。IoTの案件は関わる会社が多くなりがちなので、様式を統一しておくと集約が楽になります。
人材面では、組込みとセキュリティの両方に触れられる体制を組めるかが分かれ目になります。社内で抱えきれない部分は、IoT領域の開発体制のように外部の力を組み合わせる前提で計画を立てるほうが、現実的に前へ進みます。
まとめ：IoT機器のセキュリティ規制で押さえる3つの視点
つながる機器に対して、売る前に満たすべきセキュリティの最低ラインが制度として整えられてきました。押さえたい視点は三つです。第一に、要求の中身は制度をまたいで似ており、共通の初期パスワードを使わない・脆弱性の受付窓口を公開する・更新の提供期間を明示するという三点が中心になること。第二に、制度の性格は異なり、国内は適合を示すラベリング、英国は売る側への義務、EUは市場に出す条件という違いがあるため、対象市場によって必要な文書と手続きが変わること。第三に、開発では個体ごとの初期認証情報、更新の配信経路、部品表と脆弱性の追跡を最初から設計に入れることが実務の要になることです。まずは対象市場を確かめ、更新の仕組みと部品表の整備から着手するのが堅実でしょう。
よくある質問
国内で売るだけなら、対応は不要ですか。
義務としての扱いは制度によって異なりますが、調達側が要件として求める流れが広がっています。国内のラベリング制度は、適合を示すことで製品を選びやすくする仕組みで、政府調達や大手企業の調達で参照されると実質的な要件になります。国内だけでも、最低ラインは満たしておくのが現実的です。
既に売っている製品も対象になりますか。
制度ごとに適用の考え方が異なります。新たに市場へ出すものが対象になる場合と、流通しているものにも影響が及ぶ場合があります。いずれにしても、更新を提供している製品については、脆弱性が公表されたときの対応が問われます。まずは自社製品の一覧と、それぞれの更新提供状況を整理するところから始めるとよいでしょう。
更新の提供期間は、どれくらいに設定すべきですか。
製品の使われ方と、調達側の設備更新の周期から逆算するのが実務的です。機器が10年使われるのに更新が3年で終わるなら、その差の期間はリスクとして残ります。期間を延ばすとコストがかかるため、価格や保守契約と合わせて決める項目になります。購入前に分かる形で示すことが求められる点も押さえておきます。
部品表（SBOM）はどの場合に必要ですか。
制度上の要求として明示される場合と、実務上不可欠という場合があります。いずれにせよ、脆弱性が公表されたときに影響を調べるには、使用しているライブラリとバージョンの一覧が要ります。後から作るのは大変なので、ビルドの過程で自動生成する仕組みにしておくのが確実です。
開発の初期に、まず何を決めるべきですか。
対象市場と、更新の提供方法・期間です。この二つが決まると、必要な文書と実装の範囲が定まります。あわせて、個体ごとの初期認証情報をどう書き込むかを製造工程と合わせて決めておきます。いずれも後から変更しにくい部分なので、企画の段階で議論しておきたいところです。
IoT機器のセキュリティ要件対応・開発体制のご相談はLASSICへ
元請（プライムベンダー）として、更新配信の実装から部品表の整備、記録の型づくりまで、制度で問われる要件を見込んだ開発をご提案します。まずはお気軽にご相談ください。
出典
- *1 参考：情報処理推進機構（IPA）「JC-STAR（セキュリティ要件適合評価及びラベリング制度）」（https://www.ipa.go.jp/security/jc-star/index.html）。国内のIoT製品向けラベリング制度の目的・段階・要件の考え方の参考として（2026年8月確認）
- *2 参考：GOV.UK「Product Security and Telecommunications Infrastructure (PSTI) factsheets」（https://www.gov.uk/government/collections/the-product-security-and-telecommunications-infrastructure-psti-bill-factsheets）。英国の製品セキュリティに関する要件と、事業者に課される義務の概要の参考として（2026年8月確認）
