報告義務はもう動いている。問われているのは、自社が24時間で第1報を出せるかどうかだ。 EUのサイバーレジリエンス法（CRA。ネット接続機能を持つ製品の安全を定めるEUの規則）は、2026年9月11日に第14条の報告義務だけを先に発効させた。同じ日に、報告を受け付けるENISAの窓口も稼働している。残りの規定が適用されるのは2027年12月11日で、報告だけが1年以上早く始まった形だ。
対象はネットワーク接続機能を持つ製品の製造者だ。ハードウェアもソフトウェアも、業務用も消費者向けも含まれる。発効前に市場へ出した製品も外れない。 すでに売った商品から悪用された脆弱性が見つかれば、同じように報告の対象になる。以下では発効日を「2026年の実例」として置き、次に同じ局面が来たときに使える判定・役割分担・逆算の型に組み直す。
結論
- 2026年9月11日に報告義務が発効し、24時間で第1報を出す体制が問われている。
- まず製品を接続機能の有無で分け、認識の窓口を1つに決めて第1報の項目を1枚にする。
- 発効前に市場へ出した製品も対象で、24時間と72時間の2段階では終わらず最終報告まで続く。
まずやること
- EU向けに売っている製品を、ネット接続機能の有無で2つに分ける
- 「認識した時点」を記録する窓口を、サポートか品質のどちらか1つに決める
- 24時間の第1報に書く項目を、1枚の雛形にしておく
- 主要部品の製造者・保守主体の連絡先を、部品表の列として足す
2026年9月11日に何が動き出したのか
報告は3段階で、最後まで義務だ。 1段目は早期警告で、悪用されている脆弱性か、製品のセキュリティに影響する重大インシデントを認識してから24時間以内に、限定的な情報で第一報を出す。2段目は72時間以内の詳細報告。3段目が最終報告で、期限は事象によって分かれる。
| 段階 | 期限 | 起点 | 出す内容 |
|---|---|---|---|
| 早期警告 | 24時間以内 | 認識した時点 | 限定的な情報の第一報 |
| 詳細報告 | 72時間以内 | 認識した時点 | より詳しい内容 |
| 最終報告（悪用された脆弱性） | 14日以内 | 修正・緩和措置が利用可能になった時点 | 完全な報告 |
| 最終報告（重大インシデント） | 1か月以内 | 72時間報告の時点 | 完全な報告 |
2段階で終わりではない。 中国語圏の報道では24時間と72時間の2段階だけが紹介されている例が見られるが、第3段階の最終報告までが義務に含まれる。 ここを取りこぼすと、期限内に出した第1報の意味が薄れる。
制裁金の上限は1500万ユーロ、または全世界の年間売上高の2.5%のうち高い方だ（第64条）。円換算は為替で変わるため、ここではユーロ額のまま置く。製品の市場からの撤去やリコールが命じられる可能性もある。
対象かどうかは3つの質問で決まる
CRAが対象とするのは「デジタル要素を持つ製品」の製造者だ。判定は次の3つで足りる。
EU市場に製品を出しているか。 AmazonのEU各サイトで販売していれば、市場に出している状態にあたる。
その製品にネットワーク接続機能があるか。 Wi-FiやBluetoothでの接続、スマートフォンのアプリからの操作、クラウドへのデータ送信、遠隔からのファームウェア更新のどれかがあれば、接続機能ありと考える。「ネット接続の家電ではないから関係ない」と切り捨てる前に、アプリ連携の有無を確認したい。
自社が製造者にあたるか。 自社ブランドで市場に出している製品は、まず製造者として扱われると疑う。設計や製造を外部に委託している場合の該当性は、製品ごとに確認が必要で、本記事では断定できていない。
3つとも「はい」なら、対象として動く。1つでも「いいえ」なら対象外の可能性が高いが、判断を保留していいのは、その根拠を書ける場合だけだ。
時計は「認識した時点」から動く
24時間という短さが、実務の設計を決める。起点は「認識した時点」で、原因を突き止めた時点でも、修正を作った時点でもない。 だから、誰がいつ何を認識したかを記録する仕組みが先に要る。
認識はたいてい、開発チームの外から来る。顧客からの問い合わせ、販売パートナー経由の連絡、セキュリティ研究者からの指摘、SNS上の投稿などだ。窓口が3つに分かれていると、最初の連絡から24時間が静かに過ぎる。
機密性への配慮を申し出ることはできるが、それによって期限が止まるわけではない。 情報を開示しないという判断は、受け取る側のCSIRTが行う。報告は単一の報告プラットフォーム（SRP）経由で1回だけ行い、主たる拠点のCSIRT宛てに提出され、同時にENISAにも共有される。提出先が散らばる心配はないが、社内で合意形成をしている時間もない。
24時間の第1報は、分かったことと分かっていないことを分ける
24時間では、原因も影響範囲も確定しない。確定を待つのではなく、確定していないことを明記して出す。 そのために項目を先に決めておく。
第1報を24時間で書き切るための項目
- 01対象製品とバージョンどの製品のどの版か
- 02認識した日時時計の起点になる。記録の要
- 03事象の種類悪用された脆弱性か、重大インシデントか
- 04影響の範囲現時点で分かっている範囲でよい
- 05悪用の確認状況確認済み・未確認を分けて書く
- 06暫定の緩和策あるなら内容、なければ検討中と書く
- 07次の報告の予定72時間で詳細を出す約束
この7項目は、規則が定めた記載様式ではない。 24時間で書き切るための実務用の型だ。様式そのものは原文で確認する必要があり、本記事では確認できていない。
社内では、報告するかどうかの線を先に決めておきたい。24時間で議論する余裕はない。 「悪用が確認された時点で報告する」「影響する製品が1つでもあれば報告する」のように、判断の言葉を決めておけば、当番は迷わず動ける。
1つの脆弱性は3社に飛ぶ
自社製品だけを見ていれば足りる設計ではない。 第三者コンポーネントに脆弱性を見つけた場合、その製造者や保守主体へ通知する義務もある。報告は自社の窓口に閉じず、部品の供給元へ同じ日のうちに連絡が飛ぶ。
だから、部品表に「連絡先」の列を持たせる。どの部品を、どの会社の、誰に、何語で連絡するか。 ここが埋まっていないと、見つけた日のうちに動けない。
部品表（SBOM。製品に含まれるソフトウェア部品の一覧）の正式な義務化は2027年12月からだ。ただし、24時間で「どの製品のどの部品が影響を受けるか」を判断するには、実質的にSBOMがないと間に合わない。 義務化を待たずに整備を始めるのが現実的になる。部品表は規制対応の書類ではなく、24時間で答えを出すための道具として作ると続く。
EUの規制は「誰が責任を負うか」が動くときに実務が詰まる。同じ読み方で、プラットフォームがみなし輸入者になる話も並べて読むと判断しやすい。
本格適用までは逆算の週数で並べる
日付ではなく、週数で並べると動かせる。 基準日は2027年12月11日、または新製品を市場に出す日だ。そこから逆算して、四半期ごとに区切る。
| 逆算 | やること | 主に動く人 |
|---|---|---|
| T-52週 | 部品表の雛形を作り、主要製品1つで試験運用する | 開発・品質 |
| T-26週 | 全製品に展開し、連絡先の列を埋める | 品質・調達 |
| T-13週 | 第1報の雛形と当番を決め、想定演習を1回やる | 法務・サポート |
| T-4週 | 提出先・権限・連絡先を最終確認する | 法務 |
| T-0 | 運用を開始する | 全員 |
週数は目安で、規則が定めた数字ではない。 自社の製品数と部品数に合わせて詰める。大事なのは、「部品表を作る」と「24時間で出せる体制を作る」を別の四半期に置くことだ。同じ四半期に詰め込むと、どちらも中途半端になる。
結局、この規則が変えたのは、脆弱性への対応を「見つけた人が頑張る仕事」から「組織が24時間で回す仕事」に移したことだ。個人の力量では24時間は守れない。窓口が1つに集まり、項目が決まり、連絡先が埋まっているかどうかで、同じ期限の重さが変わる。
だから最初にやるのは、立派な規程を作ることではない。窓口を1つに決めて、第1報の項目を1枚に書き、主要部品の連絡先を10件埋める。 この3つで、24時間は現実的な数字になる。
よくある質問
CRAの報告義務はいつから始まった？
2026年9月11日に報告義務だけが発効し、残りの規定は2027年12月11日から適用される。
違反すると制裁金はいくら？
上限は1500万ユーロ、または全世界の年間売上高の2.5%のうち高い方だ（第64条）。市場からの撤去やリコールが命じられる可能性もある。
24時間の第1報はどう準備すればいい？
窓口を1つに決め、第1報の7項目を1枚の雛形にし、主要部品の連絡先を10件埋める。この3つで24時間は現実的な数字になる。
まとめ：今週やること
今週やること
- 01EU向け製品を接続機能の有無で分けるアプリ連携も接続に含める
- 02認識の窓口を1つに決めるサポートか品質か。担当者名まで
- 03第1報の7項目を1枚にする雛形のファイルを作る
- 04主要部品の連絡先を10件埋める会社名・窓口・言語
- 05逆算の基準日を決める2027年12月11日か、市場に出す日か
制度が先に動いて実務が後から追う構図は、金額の単位が実務を決める話と似ている。小包単位で費目が変わる例は、EUの小包取扱手数料で整理している。