製品セキュリティの最前線【第1回】

もはや調達要件となった製品セキュリティ
―セキュリティ法規対応の義務化は「やらされ仕事」なのか？

※こちらのページに記載されている内容は、2026年3月時点の情報です。

世の中の多くの製品は、もはや単体で完結するものではなくなりました。
ネットワークに接続され、ソフトウエアによって機能が更新・拡張されることは、自動車、産業機器、医療機器、ネットワーク機器、IoTデバイスなど、さまざまな分野で当たり前になっています。
その結果、製品は出荷・販売後もネットワークにつながり続ける限り、長期間にわたってサイバーリスクにさらされ続ける存在となりました。
さらに近年では、攻撃者の関心もITシステムだけでなく、製品そのものへと広がっています。製品の脆弱(ぜいじゃく)性が悪用され、社会インフラや人命に影響を及ぼす事例も、決して珍しいものではなくなりました。
これは国内だけの動きではなく、グローバル全体で起こっていることです。
こうした状況を受け、ネットワーク接続機能を持つ製品を開発・製造する企業（製品メーカーや、その主要なサプライヤー）に対して、

を求める動きが、世界的に加速しています。

製品セキュリティを巡る動きは、ここ数年、全世界で一気に具体化しました。
自動車分野では、国連欧州経済委員会(UNECE)傘下の自動車基準調和世界フォーラム(WP.29)により策定されたサイバーセキュリティ法規UN-R155及びその実現のためのプロセス標準であるISO/SAE 21434への対応が2020年頃から始まり、すでにサプライチェーン全体に波及しています。これらは自動車向けの規格ではあるものの、「製品ライフサイクル全体でセキュリティを管理する」という考え方は、ほかの製品分野にも共通するものです。
この考え方を、業界横断の法規として明確に打ち出したのが、欧州連合(EU)で施行された「サイバーレジリエンス法 (Cyber Resilience Act、以下「CRA」)」です。CRAは、ソフトウエアやネットワーク機能を備えたあらゆる製品を「デジタル要素を持つ製品」と定義し、設計・開発段階からセキュリティ対策を講じること、さらに出荷後も脆弱性対応や情報提供を継続することを、法的義務として求めています。

このような動きはEUに限ったものではありません。
英国ではProduct Security and Telecommunication Infrastructure Act (PSTI法) が施行され、米国やシンガポールでもIoT製品向けのセキュリティラベリング制度が導入されるなど、製品として最低限備えるべきセキュリティ水準を市場が法規や認証制度により可視化する流れが加速しています。そのプロセス標準として多方面で参照されているのが、IEC62443、ETSI EN 303 645に代表される国際的なセキュリティ規格です。
日本でも同様の流れとして、セキュリティ要件適合評価及びラベリング制度 (JC-STAR) が始まりました。JC-STARは、IoT製品に対して共通の物差しでセキュリティ要件への適合状況を評価・可視化する制度であり、ETSI EN 303 645やNISTの要件とも整合を取りながら設計されています。現時点では任意制度ですが、一般IoT製品から政府調達や重要インフラ分野での活用が見込まれ、さらにCRA等の海外法規対応を可能にするための相互承認を視野に入れた動きも進んでいます。

これらに共通するのは、セキュリティを「後付け」ではなく、製品の企画・設計段階から組み込み、初期状態から一定の安全性を担保することを前提とする「Security by Design」と「Security by Default」という思想です。

また、これらの法規の多くは認証を取得すれば終わりということではなく、むしろ出荷後に脆弱性が発見された場合の対応体制や、継続的なアップデートの仕組みまで含めて評価される形になっています。
そのため、グローバル市場で製品を展開する企業にとって「セキュリティは後付けや場当たり的な対応でなんとかすればよい」「日本企業だから関係ない」というわけにはいかず、もはや製品セキュリティ対応が取引先からの調達要件となるケースも増えてきています。

多くのセキュリティ法規や認証制度で共通して製品メーカーに求められている主な要求事項は、大きく次のように整理できます。

これらは一見すると個別の技術要件の集合に見えますが、CRAやJC-STARが本質的に求めているのは、「一度作って終わり」ではなく、変化に対応し続けられる製品であるかどうかです。
しかし、実際にこれらの要件に対応しようとした際、多くの製品メーカーが戸惑う理由の一つは、これらの要求事項が特定の部門や工程だけで完結しない点にあるのではないでしょうか。
いずれの要件も個別には理解できても、それらを製品開発・製造・運用の流れの中で一貫して実装し、維持していくには、設計思想や組織体制の見直しが避けられません。

また、取り組むにあたって、社内の役割分担が曖昧ということもあります。「法規対応は品質保証部門の仕事」「セキュリティ対策は情報セキュリティ部門が担当するもの」「セキュリティは難しくて面倒なので自分は担当したくない」と思っている方が大多数なのではないでしょうか。
さらに、CRAのような法規は「どの技術を使え」とは指示せず、達成すべき結果を示す形を取っています。そのため、「最低限どこまでやれば足りるのか、自社製品においてなにを優先すべきなのか」を判断しにくい、という声が多く聞かれます。
こうした理由から、製品セキュリティの要求を十分に満たすことが難しいどころか、検討が進まないまま時間だけが過ぎていってしまうというケースも見られます。

製品セキュリティ法規への対応は、どうしても「コストが増える」「やることが増える」「本来やりたいことを圧迫する」といった理由から、「やらされ仕事」として受け止められがちです。
しかし、CRAをはじめとする近年の製品セキュリティ法規が本当にめざしているのは、企業に過剰な負担を強いることではありません。
「脆弱性が見つかることを前提に、きちんと直せる製品かどうか」
「問題が起きたとき、説明責任を果たせる体制があるかどうか」
という、極めて基本的な問いに集約されます。

では、なぜ今それが製品メーカーに「義務」として求められるのか。
かつては、製品の内部構造やセキュリティ対策は、メーカーしか知り得ない領域でした。
しかし、ネットワークに接続されたさまざまな製品が企業を支え、社会インフラや生活の一部となった現在、製品の脆弱性は、企業単体の問題では済まなくなっています。
CRAやJC-STARが調達要件として位置づけられ始めているのは、事故や被害が起こる前提で備えている製品を選ぶという市場側の意思表示でもあります。
製品セキュリティ法規対応は、競争優位を直接生み出すものではないかもしれません。

しかし、対応していない製品は、そもそも比較の土俵にすら上がれなくなる時代に入りつつあります。
見方を変えれば、

という点で、製品セキュリティ法規対応は、企業と顧客の双方にとって合理的なルールでもあります。

製品セキュリティは、「やらされ仕事」から「製品をよりよくするために必要なこと」へ。その認識転換こそが、今求められているのかもしれません。

次回は、こうした製品セキュリティ要求の中でも、設計段階での判断が後戻りしにくく、多くの企業が悩みやすい「信頼の前提をどう作るか」というテーマを取り上げていきます。