製品セキュリティとは？情報セキュリティとの違いと関連法規制・開発での始め方を解説

自社が開発・出荷する機器やソフトウェアがインターネットにつながることが当たり前になり、製品そのものがサイバー攻撃の対象になっています。取引先から調達の条件としてセキュリティ対応を求められたり、EUへ輸出する製品で「CRA（サイバーレジリエンス法）への対応」を問われたりする場面も増えてきました。

その文脈で使われるのが「製品セキュリティ（プロダクトセキュリティ）」という言葉です。社内の情報システムを守る情報セキュリティとは守る対象が異なり、近年あらためて独立した分野として扱われるようになっています。もっとも、言葉は見聞きしても「結局どういう意味で、今までのセキュリティと何が違うのか」「自社は何から始めればよいのか」が整理できていない方も多いのではないでしょうか。

本記事では、製品セキュリティの定義とIT・情報セキュリティとの違いから、なぜ今求められているのか、自社に関わる主な法規制・制度の一覧、開発の流れに沿った始め方、押さえておきたい用語、外部の脆弱性診断サービスという選択肢までを順に解説します。自社の製品セキュリティ対応を検討するための出発点として活用いただけます。

製品セキュリティとは？IT・情報セキュリティとの違い

ここでは、製品セキュリティの定義と、情報システムを守る従来のセキュリティとの違いを整理します。

製品セキュリティ（プロダクトセキュリティ）とは

製品セキュリティ（プロダクトセキュリティ）とは、自社が開発・出荷する製品そのもの（ハードウェアとソフトウェア）を、企画・設計から開発、出荷後の運用・保守、サポート終了までのライフサイクル全体にわたって守る取り組みを指します。対象となるのは、インターネットや他の機器につながるIoT機器・組み込み機器・コネクテッド製品や、そこで動くソフトウェアです。

背景にあるのは、製品にソフトウェアが載りネットワークにつながる構造が一般化したことです。欧州委員会はサイバーレジリエンス法（CRA）の対象を「デジタル要素を持つ製品（software or hardware products with digital elements）」と表現しており、ソフトウェアを備えネットワーク機能を持つ製品が広く対象として意識されています。

こうした製品は出荷後も長期間ネットワークにつながり続けるため、売って終わりではなく、使われている間ずっとセキュリティに向き合う必要があります。

出典・参考資料（1件）

• 出典：The Cyber Resilience Act｜European Commission

IT・情報セキュリティ／工場（OT）セキュリティとの違い

製品セキュリティは、名前が似ている情報セキュリティや工場のセキュリティと混同されがちですが、守る対象・担当する部署・守るべき期間が異なります。社内の他部署や上司に説明するときの足場として、まず違いを押さえておきましょう。

情報セキュリティが自社の中で使う仕組みと情報を守るのに対し、製品セキュリティは自社の外に出て顧客が使う製品を守ります。守る相手が社外にいて、出荷後も攻撃にさらされ続ける点が、製品セキュリティを独立した分野として考える理由です。工場の設備を狙う攻撃を防ぐOT（Operational Technology、制御技術）セキュリティとも、対象が「出荷する製品」か「自社の生産設備」かで区別されます。

なぜ今、製品セキュリティが求められているのか

製品セキュリティが近年あらためて問われるようになった背景には、技術・取引・法規制の3つの変化があります。

1つ目は、製品のネットワーク化です。家電や産業機器までがインターネットにつながり、ソフトウェアで機能を更新するようになった結果、これまで情報システムに向いていた攻撃者の関心が製品そのものへ広がりました。1つの脆弱性が、利用者の安全や社会インフラにまで影響しかねない点が、従来のセキュリティとは異なる重みを持ちます。

身近なIoT機器で狙われやすい脆弱性と実際の被害事例は、『IoT機器の脆弱性とは？代表的な種類・実被害事例と自社で今すぐ確認すべき対策の優先順位』で具体的に確認できます。

2つ目は、調達要件化です。製品を納入する取引先や、製品を組み込んで使う企業が、発注の条件としてセキュリティ対応を確認するようになってきました。自社が最終製品メーカーでなくても、サプライチェーンの一員として対応状況を説明できることが求められる場面が増えています。

3つ目は、法規制・認証制度の整備です。EUのサイバーレジリエンス法（CRA）や英国の製品セキュリティ法、日本のIoT製品向けラベリング制度（JC-STAR）など、製品のセキュリティを直接対象とする枠組みが各国で動き出しました。自社の製品分野や輸出先によって関わる制度が変わるため、どれが自社に効くのかを把握することが出発点になります。具体的な制度は次の章で一覧に整理します。

こうした海外の規制への対応は、製品を輸出する企業にとって現実の相談事になりつつあります。脆弱性診断サービスを提供する株式会社TECHFUND（Hi AUDIT）も、MCB FinTechカタログの独自インタビューで次のように話しています。

製品セキュリティに関わる主な法規制・制度【一覧表】

製品セキュリティに関わる主な法規制・制度を、対象（国・製品分野）・義務か任意か・施行時期・主な要求事項の観点で一覧にまとめました。自社の製品分野と輸出先に照らし、どの制度が関わるかを確認する起点としてご覧ください。横にスクロールすると各制度の詳細を確認できます。

※上記は各制度の公表情報を基に整理したものです。対象範囲や施行時期の詳細、具体的な要求事項は、必ず各制度の公式文書をご確認ください（2026年11月時点）。

義務に当たるのは、EUのCRA・英国のPSTI法・自動車のUN-R155・医療機器の基本要件基準で、いずれも対象製品を市場に出す前提として適合が求められます。一方、日本のJC-STARやSBOM導入手引、IEC 62443、ETSI EN 303 645は、法的な義務ではなく任意の制度・規格ですが、取引先からの調達要件や業界の慣行として事実上求められることがあります。

出典・参考資料（8件）

• 出典：The Cyber Resilience Act｜European Commission
• 出典：The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023｜legislation.gov.uk
• 出典：セキュリティ要件適合評価及びラベリング制度（JC-STAR）の運用開始｜情報処理推進機構（IPA）
• 参考資料：自動車のサイバーセキュリティに関する資料（UN-R155・別添120）｜国土交通省
• 出典：医療機器のサイバーセキュリティについて｜厚生労働省
• 参考資料：ソフトウェア管理に向けたSBOMの導入に関する手引 Ver2.0｜経済産業省
• 参考資料：ISA/IEC 62443 Series of Standards｜ISA（International Society of Automation）
• 参考資料：ETSI EN 303 645（Consumer IoT security）｜ETSI

どの制度が自社に関わるかは、製品の分野と販売・輸出先によって決まります。ネットにつながる一般的なIoT・組み込み機器であれば、EUへ輸出するならCRA、国内ではJC-STARやETSI EN 303 645、横断的にはSBOMの整備が確認の起点になります。自動車や医療機器のように特定分野の製品では、その分野固有の制度（UN-R155、薬機法の基本要件基準など）が加わります。

たとえば医療機器では、ネットワークに接続する機器や外部からの不正アクセスが想定される機器について、サイバーセキュリティの確保が製造販売承認の要件として求められています（薬機法 基本要件基準 第12条第3項）。このように、制度ごとに「どの製品が対象か」が条文や基準で定められています。

このように、自社の製品がどの制度の「対象」に当たるかは、ネットワーク接続の有無や製品分野によって決まります。一覧で当たりを付けたら、関係しそうな制度は公式文書で対象と要求事項を確認し、社内で対応要否を検討する材料にするとよいでしょう。

何から始める？開発ライフサイクルで取り組む製品セキュリティ

製品セキュリティは、出荷直前にまとめて対策するのではなく、開発の流れに沿って段階的に組み込むのが基本です。情報処理推進機構（IPA）が公開する製品開発者向けのガイドも、設計から出荷後までの各段階で取り組む考え方を示しています。ここでは「設計」「開発」「出荷後」の3段階に分けて、最初の一歩を整理します。

出典・参考資料（1件）

• 参考資料：製品開発者向け・製品利用者向けガイド｜情報処理推進機構（IPA）

設計段階：セキュリティ・バイ・デザインと脅威分析

最初の一歩は、企画・設計の段階からセキュリティを織り込む「セキュリティ・バイ・デザイン（Security by Design）」の考え方に立つことです。製品が扱うデータや通信経路、想定される利用環境を洗い出し、どこが攻撃されうるかを設計時に分析（脅威分析）しておくと、後の手戻りを抑えられます。暗号化や認証の方式、ソフトウェアを安全に更新する仕組みも、この段階で設計に織り込んでおくことが重要です。

開発段階：SBOMの整備・SCA・脆弱性診断

開発段階では、製品に組み込むソフトウェア部品を把握することが出発点になります。多くの製品はオープンソースソフトウェア（OSS）をはじめ多数の部品で構成されており、どの部品を使っているかを一覧にした「ソフトウェア部品表（SBOM）」を整備しておくと、既知の脆弱性が公表されたときに影響範囲をすばやく確認できます。

経済産業省もSBOM導入の手引を公表しており、部品の把握と脆弱性管理への活用を促しています。

そのうえで、ソフトウェアコンポジション解析（SCA）やソースコード診断、動作中の製品に対する脆弱性診断を組み合わせ、問題を出荷前に見つけて修正することが基本です。開発のたびに自動で検査を回し、要所では専門家が確認する進め方は、開発スピードを保ちながらセキュリティを確認する方法として広がっています。

ソースコード診断の費用相場や依頼先タイプ別の選び方については、『ソースコード診断とは？費用相場と依頼先の選び方をタイプ別に整理』で詳しく解説しています。

開発工程にセキュリティ検査を織り込む進め方が広がる背景について、開発者向けの脆弱性診断ツールを提供する株式会社AndGoは、MCB FinTechカタログの独自インタビューで次のように述べています。

出荷後：脆弱性対応体制（PSIRT）と調整された脆弱性開示

製品は出荷した後も新たな脆弱性が見つかります。そこで、自社製品の脆弱性情報を受け付け、分析し、修正パッチの配布や情報公開までを担う専門チーム「PSIRT（Product Security Incident Response Team）」を用意し、出荷後も対応を続ける体制を整えることが求められます。

脆弱性を受け取ってから修正・公開するまでの進め方は、関係者が足並みをそろえて行う「調整された脆弱性開示（CVD）」の考え方に沿って設計します。

日本では、発見された脆弱性情報の届出を情報処理推進機構（IPA）が受け付け、製品開発者への連絡や公表の調整をJPCERTコーディネーションセンター（JPCERT/CC）が担う「情報セキュリティ早期警戒パートナーシップ」が、経済産業省の告示に基づいて運用されています。自社の脆弱性報告の受付窓口を公開し、こうした枠組みと連携できるようにしておくことが、出荷後の備えになります。

出典・参考資料（1件）

• 出典：脆弱性関連情報の届出受付（情報セキュリティ早期警戒パートナーシップ）｜情報処理推進機構（IPA）

覚えておきたい製品セキュリティの重要用語

製品セキュリティの解説や制度の文書では、略語や専門用語が数多く登場します。ここまでに出てきた用語を、定義と相互の関係に絞って整理します。

PSIRT（CSIRTとの違い）

PSIRT（Product Security Incident Response Team）は、自社が出荷する製品の脆弱性に対応する組織です。名前の似たCSIRT（Computer Security Incident Response Team）が自社の情報システムや社内ネットワークのインシデントに対応するのに対し、PSIRTは自社製品を対象とする点が異なります。

守る相手が社外の製品利用者に広がるため、PSIRTの役割には修正パッチの配布や、脆弱性を見つけた外部の発見者との連携までが含まれます。

SBOM・SCA（ソフトウェア部品表とその解析）

SBOM（Software Bill of Materials、ソフトウェア部品表）は、製品に含まれるソフトウェア部品（OSSやライブラリなど）の一覧です。SCA（Software Composition Analysis、ソフトウェアコンポジション解析）は、SBOMなどをもとに、既知の脆弱性を含む部品が使われていないかを検出する手法・ツールを指します。

SBOMで部品を見える化し、SCAで脆弱性を照合する、という関係で使われます。

CVD（調整された脆弱性開示）

CVD（Coordinated Vulnerability Disclosure、調整された脆弱性開示）は、脆弱性の発見者・製品の開発者・調整機関が連携し、修正が整うまで情報を伏せたうえで、対策が用意できた段階で公開する進め方です。

国際的には、脆弱性を外部に開示する際の指針（ISO/IEC 29147）と、報告を受けてから処理する内部プロセスの指針（ISO/IEC 30111）が対になって参照されます。

CVE・CVSS（脆弱性の識別子と深刻度評価）

CVE（Common Vulnerabilities and Exposures）は、公開された個々の脆弱性に付与される一意の識別番号で、関係者が同じ脆弱性を指して話すための共通の名札の役割を果たします。

CVSS（Common Vulnerability Scoring System）は、脆弱性の深刻度を数値スコアで評価する仕組みで、FIRST（Forum of Incident Response and Security Teams）が公開しています。現行はバージョン4.0で、スコアに応じて対応の優先順位を判断する際に使われます。

出典・参考資料（2件）

• 参考資料：CVE Program Overview｜The CVE Program
• 参考資料：Common Vulnerability Scoring System (CVSS)｜FIRST

セキュリティ・バイ・デザイン

セキュリティ・バイ・デザイン（Security by Design）は、製品の企画・設計の段階からセキュリティを組み込む考え方です。前述の設計段階の取り組みの基礎となる姿勢で、出荷後に対策を後付けするのではなく、脆弱性が作り込まれにくい製品を最初から目指します。

自社対応か外部支援か：脆弱性診断サービスという選択肢

ここまで見てきた設計・開発・出荷後の取り組みを、すべて自社だけで進めるのは容易ではありません。脆弱性診断には、検出した問題が実際に悪用できるかを見極め、優先順位を付ける専門性が必要になるためです。そこで、外部の脆弱性診断サービスを活用し、自社の体制に合わせて診断や改善支援を受ける選択肢があります。

目安として、ソフトウェア部品表（SBOM）の整備や、開発フローへの自動検査の組み込みは、ツールを使えば自社でも進めやすい領域です。一方、検出した脆弱性が実際に悪用できるかの見極めや、専門的な侵入テスト、IoT機器などハードウェアを含む製品の診断は、外部の専門家の力を借りる場面が多くなります。

脆弱性診断サービスを診断方法・費用相場・選び方から幅広く比較したい場合は、以下の記事で主要なサービスを整理しています。製品セキュリティ以外の用途も含めて検討する際の出発点としてご覧ください。

製品セキュリティの文脈では、ソースコードや依存するソフトウェア部品の検査、動作中の製品への脆弱性診断、IoT機器・医療機器といったハードウェアの診断など、製品の性質に合った診断を選べることが重要です。

以下で紹介する3つのサービスは、ソースコードやソフトウェア部品の検査が中心のものから、IoT機器・ハードウェアを含む製品の診断に対応するものまで、得意とする領域が異なります。まずは比較表で全体像を確認してください。

1. Aikido Security（株式会社AndGo）

Aikido Securityは、開発段階のセキュリティ検査を一つにまとめたオールインワン型の脆弱性診断SaaSです。日本では株式会社AndGoが取り扱っています。ソースコードの静的解析（SAST）、依存するソフトウェア部品の解析（SCA）、クラウド設定の点検（CSPM）、コンテナや稼働中のWebアプリの検査までを同じ画面でまとめて実行できます。

製品セキュリティの観点では、ソフトウェア部品の把握とソースコード・依存部品の脆弱性検査を開発フローに組み込める点が特徴です。無料で試せるプランがあり、日本窓口を通じて日本円の請求書払いにも対応しています。料金は年額3,780ドルからのプランが案内されており、正式な金額は取り扱い窓口への確認が必要です（2026年11月時点）。

2. Hi AUDIT（株式会社TECHFUND）

Hi AUDITは、株式会社TECHFUNDがブランドとして展開するセキュリティ診断サービスです。Web3のスマートコントラクト監査を主力としつつ、TECHFUNDの説明によれば、Webアプリケーションに加えてIoT機器や医療機器といったハードウェアの診断にも対応領域を広げています。製品そのものを守る診断を検討する企業にとって選択肢になります。

ツールによる自動診断と専門家によるマニュアル診断を組み合わせ、見つけた脆弱性が事業に与える影響まで整理して報告する点を強みとし、レポート提出後も修正完了まで相談や再確認を支援する方針を掲げています。製造業で欧州へ輸出する企業から、欧州の規制（CRAなど）に対応できるかという相談も受けているとしています。料金は要問い合わせです（2026年11月時点）。

3. CoWorker 脆弱性診断サービス（CoWorker株式会社）

CoWorker株式会社が提供する脆弱性診断サービスは、自社開発のAIによる自動解析と、社内のセキュリティ専門家による最終確認を組み合わせた二段構えの診断が特徴です。メニューは、本番環境に影響を与えずに実施できるソースコードAI診断、稼働中のWebアプリ・APIを対象とする動的診断、攻撃者の視点で侵入を試みるペネトレーションテストの3つから選べます。

ソースコードAI診断は単体から利用でき、最短3営業日での納品を掲げています。料金は、ソースコードAI診断が150,000円、ソースコードと動的診断を組み合わせたプランが500,000円からと案内されています（2026年11月時点）。生成AI・大規模言語モデル（LLM）を対象とした脆弱性診断もメニューに加わっています。

まとめ

製品セキュリティは、自社が出荷する製品そのものを、設計から出荷後まで守る取り組みです。社内の情報システムを守る情報セキュリティとは守る対象が異なり、製品のネットワーク化・調達要件化・法規制の整備を背景に、あらためて独立した分野として求められています。

まずは自社の製品分野と輸出先に照らして、CRAやJC-STARなど関わる制度を把握し、設計段階のセキュリティ・バイ・デザイン、開発段階のSBOM整備と脆弱性診断、出荷後のPSIRT体制という流れで、着手できるところから始めることが現実的です。自社だけで進めにくい診断は、外部の脆弱性診断サービスを活用する選択肢もあります。各サービスの詳細は、資料を取り寄せて比較検討するとよいでしょう。

よくある質問（FAQ）

Q. 製品セキュリティ（プロダクトセキュリティ）とは何ですか？

A. 製品セキュリティとは、自社が開発・出荷する製品そのもの（ハードウェアとソフトウェア）を、設計から出荷後の運用・サポート終了までのライフサイクル全体にわたって守る取り組みです。対象となるのは、インターネットや他の機器につながるIoT機器・組み込み機器・コネクテッド製品や、そこで動くソフトウェアです。

製品にソフトウェアが載りネットワークにつながる構造が一般化し、製品そのものが攻撃対象になったことを背景に、社内の情報システムを守る情報セキュリティとは別の分野として位置づけられるようになっています。

Q. 製品セキュリティと情報セキュリティの違いは何ですか？

A. 製品セキュリティと情報セキュリティの違いは、守る対象が「自社が出荷する製品」か「自社の情報システム」かという点にあります。情報セキュリティ（IT）が社内ネットワークや保有する情報資産を情報システム部門が守るのに対し、製品セキュリティは社外に出て顧客が使う製品を、開発・品質保証やPSIRTが設計から出荷後まで守ります。

守る相手が社外にいて出荷後も攻撃にさらされ続ける点が、独立した分野として考える理由です。自社の工場・生産設備を守るOT（制御技術）セキュリティとも、対象が「出荷する製品」か「自社の生産設備」かで区別されます。

Q. 製品セキュリティではどの法規制が自社に関係しますか？

A. 製品セキュリティで自社に関係する制度は、製品の分野と販売・輸出先によって決まります。EU市場に出す「デジタル要素を持つ製品」ならCRA（EUサイバーレジリエンス法）、英国で販売する消費者向けのコネクタブル製品なら英PSTI法、対象車両なら自動車のUN-R155、ネットワーク接続が想定される医療機器なら薬機法の基本要件基準が、いずれも市場に出す前提の義務として関わります。

一方、日本のJC-STARやSBOM導入手引、IEC 62443、ETSI EN 303 645などは任意の制度・規格ですが、取引先からの調達要件として事実上求められることがあります。一覧で当たりを付けたうえで、関係しそうな制度は公式文書で対象と要求事項を確認してください。

Q. 製品セキュリティは何から始めればよいですか？

A. 製品セキュリティは、出荷直前にまとめて対策するのではなく、開発の流れに沿って段階的に組み込むことから始めます。設計段階ではセキュリティ・バイ・デザインの考え方で想定される脅威を分析し、開発段階ではソフトウェア部品表（SBOM）の整備や脆弱性診断で問題を出荷前に見つけて修正し、出荷後はPSIRT体制で新たに見つかる脆弱性に対応します。

まずは自社の製品分野や輸出先に効く制度を把握し、設計・開発・出荷後のうち着手できるところから始めるのが現実的です。

Q. PSIRTとCSIRTの違いは何ですか？

A. PSIRTとCSIRTの違いは、対応する対象が、PSIRTは「自社が出荷する製品」、CSIRTは「自社の情報システム・社内ネットワーク」である点です。

PSIRT（Product Security Incident Response Team）は自社製品の脆弱性情報を受け付け、分析・対応・情報公開を担う組織で、守る相手が社外の製品利用者に広がるため、修正パッチの配布や外部の発見者との連携までを役割に含みます。名前は似ていますが、社内のインシデントに対応するCSIRTとは守備範囲が異なります。

Q. SBOM（ソフトウェア部品表）とは何ですか？

A. SBOM（Software Bill of Materials）とは、製品に含まれるソフトウェア部品（OSSやライブラリなど）を一覧にしたものです。多くの製品は多数の部品で構成されているため、どの部品を使っているかをSBOMで把握しておくと、既知の脆弱性が公表されたときに影響範囲をすばやく確認できます。

SBOMで部品を見える化し、SCA（ソフトウェアコンポジション解析）で脆弱性を照合する、という関係で使われます。経済産業省もSBOM導入の手引を公表し、部品の把握と脆弱性管理への活用を促しています。

Q. CRA（EUサイバーレジリエンス法）はいつから対応が必要ですか？

A. CRAは、2024年12月10日に発効し、脆弱性・重大インシデントの報告義務が2026年9月11日から、主要な義務が2027年12月11日から適用されるとされています。EU市場に出す「デジタル要素を持つ製品」が対象で、セキュリティ要件への適合とCEマーキング、能動的に悪用されている脆弱性・重大インシデントの報告などが求められるとされています。

適用時期や要求事項の詳細は段階的に定められているため、自社製品が対象となるかも含め、必ずEUの公式文書で確認してください。

Q. 製品セキュリティ対応は自社で行うべきか、外部に頼むべきですか？

A. 製品セキュリティ対応を自社で行うか外部に頼むかは、自社に脆弱性診断の専門性やリソースがあるかどうかで判断します。脆弱性診断には、検出した問題が実際に悪用できるかを見極めて優先順位を付ける専門性が必要なため、設計から出荷後までのすべてを自社だけで進めるのは容易ではありません。

ソースコードや依存するソフトウェア部品の検査、動作中の製品への診断、IoT機器・医療機器などハードウェアの診断は、製品の性質に合った外部の脆弱性診断サービスを活用し、自社の体制に合わせて診断や改善支援を受ける選択肢があります。

脆弱性診断サービスの料金・資料を一括チェック

MCB FinTechカタログでは、製品の脆弱性診断・セキュリティ診断サービスの最新資料を無料で一括請求できます。診断の対象範囲や料金、支援内容を見比べて、自社の製品セキュリティ対応に合うサービスを検討できます。

MCB FinTechカタログに掲載しませんか？

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。