EUサイバーレジリエンス法は「AIが原因」の免責を許さない──CE適合・SBOM・脆弱性開示を輸出入企業に課す現実と、今すぐ備えるべきこと

今日の深掘りポイント

• 法の射程は「プロダクトに組み込まれたすべてのデジタル要素」。生成AIやエージェント機能が入っていれば、その挙動も製造者責任の範囲に含まれます。もはや「AIがやった」は通用しない設計思想です。
• CEマーキングの前提に「サイバーセキュリティ適合」を組み込み、EU市場アクセスの条件に格上げします。技術文書、SBOM、CVD（協調的脆弱性開示）体制が“出荷条件”になります。
• 移行は段階的ですが、脆弱性の取扱い・通報など一部義務は前倒しで適用されます。製品PSIRTと報告動線の整備は、後回しにできない領域です。
• 調達と供給網に波及します。EU域外の日本企業も「EUで流通させるなら遵守」が原則で、OEM/EMS/代理店（importer/distributor）まで役割ごとの法的義務が生じます。
• 現場視点では「規格適合＝脅威低減の自動達成」ではありません。SBOM運用、CVE露出の短期是正、Default設定の是正など、運用まで含めた組織能力が鍵です。

参考（一次情報・公式）

• 欧州委員会「Cyber Resilience Act（サイバーレジリエンス法）」政策ページ（法の目的・適用範囲・義務の骨子）: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• ENISA（EUサイバー安全機関）「Coordinated Vulnerability Disclosure（CVD）」ガイダンス（CRAが要請する体制の実務参照）: https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure
• 二次情報（背景理解）: The New Stack「EU Cyber Resilience Act」（法の実装論点と業界の受け止め）: https://thenewstack.io/eu-cyber-resilience-act/

はじめに

欧州のサイバーレジリエンス法（CRA）は、「製品の安全性＝サイバー安全性」を水平規制として織り込み、デジタル要素を含む製品のライフサイクル全体にセキュリティ要件を課す法体系です。機能拡張のために生成AIや自律エージェントを積んだとしても、それは製造者が制御し責任を負うべき「デジタル要素」に過ぎません。ここが、この法の本質であり、調達・設計・運用・サポートまで一気通貫での変革を迫る理由です。

現場で感じる緊張感は、単に罰則や認証の話だからではないです。SBOMやCVD、セキュアアップデートの提供、ユーザー向けのセキュリティ情報開示は、日々のPSIRTオペレーションそのものの成熟度を問う指標になります。メトリクスを眺めれば、規制の確度と緊急度は高く、実務上の準備に移すべき時期にあります。ここでは、規制文言の“読み方”と、CISO・SOC・Threat Intelが最短距離で打ち手に落とすための視点を整理します。

深掘り詳細

ファクト：CRAの骨子（適用範囲・義務・適合）

• 適用範囲
  • 「デジタル要素を含む製品（Products with Digital Elements）」全般が対象です。ハードウェア・ソフトウェア双方を含み、組込みソフトやファームウェア、接続機能を持つ機器、専用アプリケーション等が射程に入ります。SaaSは原則対象外とされつつも、製品の機能提供に不可欠なリモート機能の扱いなど、境界は今後の調和規格やガイダンスでの具体化が続く想定です。［出典：欧州委員会 概要ページ］
• 製造者（manufacturer）の主な義務
  • セキュア設計・開発・生産・配布・保守のプロセス確立と文書化（技術文書）
  • 脆弱性取扱い（CVD）プロセスの常設と脆弱性への是正アップデート提供
  • SBOM等の構成情報を技術文書に含め、想定受領者に応じて提供
  • インシデント／積極的に悪用されている脆弱性の当局（ENISA等）への通報ルール順守（初報・追報・終報という段階的報告の枠組みが導入）
  • 適合性評価（リスクに応じた自己適合宣言または第三者関与）、CEマーキング付与と市場監視への協力
  • Importer/Distributorも、それぞれの役割に応じた適合確認・不適合是正・トレーサビリティ確保が義務化されます。［出典：欧州委員会 概要ページ］
• 時間軸
  • CRAは2024年にEUで正式採択され、段階的に適用されます。施行（発効）後、概ね数年の移行期間が設けられ、多くの製品要件は猶予後に適用、他方で脆弱性取扱い・報告など一部は前倒し適用の設計です。最新の適用日程は欧州委員会の公式ページでの更新が最も信頼できます。［出典：欧州委員会 概要ページ］

補助線：CVDの実務設計では、ENISAの協調的脆弱性開示ガイダンスが参照ベースになります（受付窓口、脆弱性評価、利害関係者間の調整、公開タイミング、通報との整合など）。［出典：ENISA CVDガイダンス］

インサイト：なぜ「AIが原因」は免責にならないのか

• CRAは「製品の安全」に横串を通す法です。製品にAIモデルやエージェントが搭載されているなら、それは“製品の構成要素”であり、リスク分析・セキュア設定・アップデート提供・既知脆弱性曝露の是正といった管理対象になります。AI特有の挙動（幻覚、プロンプト注入、モデル供給元の更新影響）であっても、「選定・統合・デフォルト設定・境界制御・アップデートの方法」まで含めて製造者の設計責任に内包されます。
• 実務では、次のような“AI固有×製品安全”の接点が問われます。
  • サプライヤーモデルの更新でポリシー逸脱が生じるリスクに対する「受入れテスト」「セーフティラッピング」「ロールバック手順」の前置き設計
  • LLM/エージェントが操作可能なアクチュエータや外部APIの権限境界（最小権限・レート制御・人間による確認ステップ）
  • プロンプト／システム命令の機密性・改ざん耐性の確保（例えば、ファームウェア格納領域やセキュアエレメント活用）
  • モデルおよび依存ライブラリのSBOM化とCVE影響判定の自動連携（VEX等の実務ツールの採用は有効ですが、法が特定フォーマットを義務づけているわけではない点は留意します）
• 端的に言えば、AIは「新しい責任主体」ではなく、「従来の製品責任の中身を増やすコンポーネント」に過ぎないという整理です。したがって“AI由来の問題”を示すログや証跡を備え、是正可能に統合していない製品は、CRA上の適合・市場監視の観点で不利になります。

脅威シナリオと影響

CRAは規制ですが、その裏側には具体的な攻撃シナリオがあります。SOC/PSIRTの思考に寄せて、MITRE ATT&CKに沿った仮説ベースの整理を置きます（以下は仮説であり、個社リスク評価が必要です）。

• サプライチェーン汚染からの大量曝露

  • シナリオ：サプライヤーのOSSコンポーネントにバックドアが混入し、組込み機器やアプリに波及。SBOMが未整備だと影響範囲特定が遅延します。
  • 関連TTP：Supply Chain Compromise（T1195）、Trusted Relationship（T1199）
  • 影響：CVE公表から是正までのMTTRが長引き、CE適合維持に必要な「迅速な是正」が満たせず市場監視当局からの是正要求リスクが高まります。

• 既知脆弱性の悪用による初期侵入

  • シナリオ：公開インターフェース（Web UI/API、OTA更新経路）の既知CVEを悪用した初期侵入。
  • 関連TTP：Exploit Public-Facing Application（T1190）、Valid Accounts（T1078/Default設定悪用）
  • 影響：機器乗っ取りからボット化、企業ネットワーク側への横展開。是正アップデートの配信・適用率が低いと、当局通報と顧客通知の二重負荷になります。

• LLM/エージェントの誤作動を起点にした横展開

  • シナリオ：プロンプト注入によって機器内エージェントが過剰権限APIを叩き、デバッグ機能を有効化、ログ消去を試みる。
  • 関連TTP：Abuse Elevation Control Mechanism（T1548）、Modify Authentication Process（T1556）、Indicator Removal（T1070）
  • 影響：監査可能性が損なわれ、原因究明と適合性評価が難航します。「AIが原因」は是正計画の不備として扱われるため、事前の権限境界・監査証跡が決定打になります。

• 脆弱性情報の早期通報が攻撃者の弾薬になる副作用（運用上のリスク）

  • シナリオ：前倒し適用される通報義務で「積極的に悪用中の脆弱性」を短時間で通報する際、広く共有されるメタ情報から攻撃者が対象製品を特定。
  • 関連TTP：Reconnaissance（T1595/Active Scanning, T1592/Gathering Victim Host Information）
  • 影響：通報内容の最小化・匿名化ガイダンスに従いつつ、同時に是正パッチの準備・段階公開を設計しておかないと、通報が攻撃促進に転じるリスクがあります（ENISAのCVD実務を踏まえた運用分離が重要です）。

総じて、CRA準拠は「監督当局に見せる書類作成」ではなく、「攻撃ライフサイクルの各段で有効なコントロールを持つこと」を証明する営みです。ATT&CKで穴が残る領域は、適合審査でも脆弱と見なされやすいです。

セキュリティ担当者のアクション

ここからは、現場でそのまま動けるチェックリストです。既存のISMSやプロダクトセキュリティ体制に重ね、優先度順で進めることを勧めます。

• CRAギャップアセスメントを最優先で実施します

  • 対象製品の棚卸し（EU向けSKU/型式、ファームウェア群、同梱アプリ）
  • 役割の確認（manufacturer/importer/distributorのどれに当たるか）と役割別義務のマッピング
  • 技術文書の現状レベル（リスク分析、セキュリティ要件、試験記録、SBOM、アップデート方針）

• PSIRTの“法対応版”強化

  • CVDポリシーの公開、受付・トリアージ・修正・リリース・公開のSLA定義
  • ENISA等への通報プロセスをインシデント連絡網に統合（初報→追報→終報の雛形、法務レビューの時間を含めたタイムボックス）
  • 顧客通知テンプレート（影響評価、緩和策、更新手順）の先行整備

• SBOMプログラムの常設化

  • ビルド時自動生成（SPDX/CycloneDXなどの標準フォーマット活用は実務上有効です）
  • 脆弱性情報源との連携（NVD、GitHub Advisory等）と影響判定の自動化（VEX等の補助も検討）
  • 顧客提供方針（提供対象・チャネル・再配布条件）と市場監視当局への提示手順

• セキュアアップデートの運用保証

  • 署名・検証・ロールバック・段階展開・失敗時復旧（A/Bパーティション）まで含めたアップデートSOP
  • アップデートの提供期間と頻度の方針明確化（製品寿命とサポートの整合）

• 設計・デフォルト設定の原則を明文化

  • 既定で安全（Secure by Default）：管理ポート無効、初回起動時の強制パスワード変更、最小権限
  • AI機能の権限境界、人手確認の設計（Safety Interlock）、外部APIトークン管理

• 適合性評価と試験の計画

  • 自己適合で足りるか、第三者評価（Notified Body）が必要な分類かの見極め
  • 想定される調和規格のドラフト追跡（CEN/CENELEC/ETSIの動向）と社内標準への取り込み

• サプライヤー・契約の改定

  • SBOM提供、脆弱性是正SLA、セキュリティ通知義務、アップデート提供期間、セキュア開発の保証条項
  • 生成AI/モデルの更新管理条項（回帰テスト、影響通知、ロールバック手段）

• SOC/Threat Intelの連携強化

  • SBOMを資産台帳に統合し、露出CVEの優先順位付けに反映
  • 通報義務のトリガとなる「悪用中」判定基準をIntelチームと合意（目撃情報、攻撃キャンペーンの相関）

• 顧客フロントの準備

  • セキュリティ情報ページの整備、アドバイザリ配信の仕組み（RSS/メール/サポートポータル）
  • 設定ガイド・ハードニング手順の整備（多言語対応、特にEU主要言語）

• 教育とリハーサル

  • 法務・PSIRT・開発・カスタマーサクセス横断での通報机上演習
  • 生成AI機能を含む製品の「誤作動→是正」までのエンドツーエンド演習

最後に一言添えるなら、CRAは「書類で守る」法律ではないです。プロダクトの強さ、運用の速さ、顧客への誠実さ、そのすべてがセキュリティの実力として可視化されます。準備を前倒しできた組織から、競争力としての「レジリエンス」を手に入れられます。

参考情報

• 欧州委員会「Cyber Resilience Act」: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• ENISA「Coordinated Vulnerability Disclosure」: https://www.enisa.europa.eu/publications/coordinated-vulnerability-disclosure
• The New Stack「EU Cyber Resilience Act」: https://thenewstack.io/eu-cyber-resilience-act/