JC-STAR取得済み？ EU CRAで追加対応が必要な6つの要求事項と認定代理人の論点

JC-STARラベルを取得した日本メーカーの中には、EU CRAの対応もこれで完了と考えている方が少なくありません。

経済産業省（METI）とIPAが2025年3月に開始したJC-STARは、IoT製品のセキュリティ基準を可視化する制度として急速に普及しています。2025年10月時点で41社89件がラベルを取得しました。英国PSTI法との相互承認も実現し、シンガポールCLSとの相互承認は2026年6月1日に発効済みです。

しかし、EU CRA（サイバーレジリエンス法、EU規則2024/2847）との相互承認は交渉中であり、合意には至っていません。そして仮に相互承認が実現しても、JC-STARがカバーしていない要求事項が少なくとも6つ存在します。さらにCRA第18条のEU認定代理人選任（任意）も、運用設計上の判断対象として加わります。

本記事は、前回のCRA第14条解説記事で予告した「JC-STARとEU CRAの差分ガイド」です。JC-STAR取得済み、または取得を検討中の日本メーカーが、EU CRA対応に向けて何を追加で準備すべきかを具体的に解説します。

JC-STARの概要

JC-STAR（セキュリティ要件適合評価及びラベリング制度）は、経済産業省とIPAが2025年3月25日に運用を開始したIoT製品向けのセキュリティラベリング制度です。

4段階のレベル構成：

★1の申請費用は198,000円（税込、早期申請は110,000円）。有効期間は2年間。★1の16要件はETSI EN 303 645をベースとし、デフォルトパスワードの禁止、安全な通信、暗号化、ソフトウェア更新メカニズム、脆弱性開示ポリシーなどの基本的なセキュリティ要件を規定しています。

★1は2025年3月25日から申請受付中です。★2はIPAが2026年以降の受付開始を計画している段階で、まだ受付は始まっていません。★3・★4は第三者評価を前提とする高信頼レベルとして扱われます。

相互承認の現状：

CRA概要：JC-STAR取得者向け

EU CRA（EU規則2024/2847）は、デジタル要素を含む全製品に対しEU市場投入の条件としてサイバーセキュリティ要件を義務付ける規制です。JC-STARが任意の認証制度であるのに対し、CRAは法的義務です。

2つの期限：

• 2026年9月11日：脆弱性・インシデント報告義務の発効（第14条の詳細は前回記事を参照）
• 2027年12月11日：全要求事項の完全適用（SBOM、CE認証、技術ファイル等）

違反時の制裁： 最大1,500万ユーロまたは全世界売上高の2.5%

JC-STARとCRAの根本的な違いは、JC-STARが製品のセキュリティ特性を評価するのに対し、CRAは製品セキュリティに加えてライフサイクル全体の義務（脆弱性管理、当局報告、技術文書、適合性評価）を課す点にあります。

直接比較：JC-STAR ★1 vs CRA 要求事項

pie title JC-STAR ★1 による CRA要求事項のカバー率
    "JC-STARでカバー済み" : 30
    "部分的にカバー" : 10
    "JC-STARで未対応（ギャップ）" : 60

以下の表は、JC-STAR ★1の要件とCRAの製品セキュリティ要求を対照したものです。

JC-STARでは対応できない6つのCRA要求事項とEU認定代理人（任意）

flowchart TB
    subgraph JC["JC-STAR ★1 がカバーする領域"]
        A["デフォルトパスワード禁止"]
        B["暗号化通信"]
        C["更新メカニズム"]
        D["脆弱性開示ポリシー"]
        E["攻撃面の最小化"]
    end
    subgraph GAP["CRA固有の要求事項（ギャップ）"]
        G1["❌ SBOM（機械可読）"]
        G2["❌ ENISA 24時間報告"]
        G3["❌ EU適合性宣言"]
        G4["❌ 技術ファイル"]
        G5["❌ CEマーキング"]
        G6["❌ 5年間サポート"]
        G7["EU認定代理人（任意）"]
    end
    JC -.->|"約30%カバー"| CRA["CRA全体要求"]
    GAP -.->|"約60%が未対応"| CRA

❌ 1. SBOM（ソフトウェア部品表）

機械可読形式（CycloneDXまたはSPDX）でソフトウェアコンポーネントと依存関係を記したSBOMが求められます。

JC-STARはソフトウェアの構成管理を要件としていません。ファームウェアに含まれるOSSライブラリの一覧を作成・維持する仕組みは、JC-STARの範囲外です。

必要な対応： SBOMの自動生成パイプラインを構築します。Syft、cdxgen等のツールを用い、ビルドプロセスに組み込みます。

❌ 2. ENISA 24時間早期警告

CRA第14条は、製品の脆弱性が積極的に悪用されていることを認識してから24時間以内にENISAへ早期警告を提出することを義務付けています。この要件の詳細と日本企業特有の課題（稟議文化との構造的矛盾）については、前回の記事で詳しく解説しています。

JC-STARは脆弱性開示ポリシーの策定を求めていますが、当局への報告義務やタイムラインの規定はありません。

必要な対応： 事前承認済み報告者の設定、24時間対応体制の構築、ENISA SRPへの登録。

❌ 3. EU適合性宣言（EU DoC）

EU適合性宣言は、製品がCRAの全要求事項に適合していることを製造業者が宣言する正式文書です。製品の識別情報、適用した整合規格、適合性評価手続きの結果などを含めます。

JC-STARの適合ラベルはIPA発行の認証であり、EU法上の適合性宣言とは法的性質が異なります。

必要な対応： EU DoC文書を製品ごとに作成し、製品識別情報、適用規格、適合性評価結果を管理します。

❌ 4. 技術ファイル

技術ファイルは、製品の設計・開発に関する証拠をまとめ、長期保管する文書パッケージです。リスク評価、SBOM、テスト結果、適合性評価のエビデンスを含みます。

JC-STARの申請書類はチェックリスト形式の自己宣言であり、技術ファイルの詳細度とは大きく異なります。

必要な対応： 技術ファイルのテンプレートと管理プロセスを確立します。

❌ 5. CEマーキング

適合性評価を完了した製品にはCEマーキングを貼付します。CEマーキングなしにEU市場へは投入できません。

JC-STARの★ラベルはCEマーキングの代替にはなりません。

必要な対応： 適合性評価の完了後、CEマーキングの貼付プロセスを製造工程に組み込みます。

❌ 6. 5年間セキュリティサポート

サポート期間は原則として5年以上が下限です。製品の想定利用期間が5年未満の場合だけ、その期間に合わせます。

JC-STARの適合ラベル有効期間は2年間です。ラベルの更新は可能ですが、制度として5年間のサポートコミットメントを要求していません。

必要な対応： 製品ごとにサポート期間を定義し、5年間のセキュリティ更新提供体制を文書化します。

7. EU認定代理人（Authorised Representative・任意）

CRA第18条のEU認定代理人は任意です。MDRやREDのような域外製造業者への必須選任制度ではありません。選任した場合の実務範囲は、EU適合宣言書と技術文書の10年間保管、市場監視当局への応答、是正措置への協力が中心で、製品セキュリティ義務の最終責任は製造業者に残ります。詳細はEU認定代理人とCRA第18条を参照してください。

JC-STARは日本国内の制度であり、EU域内の代理人に関する要件はありません。

実務上の選択肢： EU域内の単一窓口を設けることで、市場監視当局との対応を当地の言語と時間帯で処理できる利点があります。MDR・REDで既に代理人を委嘱している場合は、CRAスコープへの延長を含め運用を一体化する設計が現実的です。選任しない場合は、文書保管・当局対応・是正措置記録を製造業者本体または輸入業者経由で運用します。

相互承認の現状と限界

METIは国際的な相互承認を積極的に推進しています。

実現済みの相互承認：

• 英国 PSTI法：2025年11月6日にMoC署名。2026年1月1日から、JC-STAR ★1取得製品は英国PSTI法の3つの適合基準を満たすとみなされます。ただし、英国PSTI法はEU CRAとは別の法規制であり、PSTI相互承認はCRA適合を意味しません。
• シンガポール CLS：MoC署名済み。2026年6月1日から発効。

EU CRAとの相互承認： 交渉中。合意時期は未定。

JC-STARレベル別のCRA準備度

flowchart LR
    subgraph S1["★1"]
        P1["約30%\n製品セキュリティ\nベースライン"]
    end
    subgraph S2["★2"]
        P2["約35-40%\nカテゴリ別\n追加要件"]
    end
    subgraph S3["★3"]
        P3["約40-45%\n第三者評価で\n信頼性向上"]
    end
    subgraph S4["★4"]
        P4["約45-50%\n最高レベル\n製品セキュリティ"]
    end
    subgraph MISSING["全レベル共通の未対応領域"]
        M1["SBOM"]
        M2["ENISA報告"]
        M3["EU DoC"]
        M4["CEマーキング"]
        M5["技術ファイル"]
        M6["5年サポート"]
        M7["EU認定代理人"]
    end
    S1 --> S2 --> S3 --> S4
    S4 -.->|"★4でも\nカバーされない"| MISSING

★4は製品セキュリティの観点で最も厳格な評価を受けるため、CRAの製品セキュリティ要件への対応度は高くなります。しかし、CRAの義務の約半分を占めるライフサイクル要件・規制手続きは、どのレベルでも対応していません。

本記事は情報提供を目的としており、法的アドバイスを構成するものではありません。EU製品規制に関する具体的なコンプライアンス対応については、EU規制に精通した法律の専門家にご相談ください。