こんにちは、インフラエンジニアのryuです。
2026年9月11日、ヨーロッパで一つの法律の「報告義務」が動き始めました。 EUのサイバーレジリエンス法、略してCRAです。
「EUの法律なら、日本で働く自分には関係ないのでは？」と思った方も多いのではないでしょうか。
ところが、そうとも言い切れません。 EUに製品を出荷している日本のメーカーやソフトウェア会社は、この日から報告義務の対象になっています。 そして、その報告を支えるのは、多くの場合インフラエンジニアが整えている「記録」と「把握」の仕組みなんです。
この記事では、CRAで何が始まったのかを整理しながら、インフラエンジニアの現場で何が求められるのかを考えていきます。 法律の解説書ではなく、あくまで現場目線の整理として読んでくださいね。
サイバーレジリエンス法（CRA）って、そもそも何なのでしょうか？¶
CRAは、EU市場に出回る「デジタル要素を含む製品」に、セキュリティの責任を求める法律です。 正式には Regulation (EU) 2024/2847 といい、2024年12月10日に発効しました。
サイバーレジリエンス法（CRA）とは、ネットワークにつながるハードウェアやソフトウェアを対象に、設計段階から販売後のサポート終了までセキュリティを確保することを、製造業者などに義務づけるEUの規則。
身近なもので考えてみましょう。 家電には、感電や発火を防ぐための安全基準がありますよね。 基準を満たさない製品は、そもそも売ることができません。
CRAは、その安全基準の考え方を、サイバーセキュリティに広げたものだといえます。 ルーターやスマート家電、業務用のソフトウェアなど、ネットワークにつながる製品が「売ったら終わり」ではなくなるんです。
いつから、何が始まるの？¶
CRAは一度にすべてが始まるわけではありません。 段階的に適用される仕組みになっています。
| 時期 | 起きること |
|---|---|
| 2024年12月10日 | CRAが発効 |
| 2026年9月11日 | 製造業者の報告義務が適用開始（悪用された脆弱性・重大インシデント） |
| 2027年12月11日 | セキュリティ要件への適合やCEマーキングなど、主な義務が全面適用 |
今回始まったのは、表の2段目、報告義務の部分です。 製品を設計し直すような大きな義務は、2027年12月からになります。
ここで見落としやすいのが、報告義務は2026年9月11日より前に市場に出た製品にも適用されるという点です。 「新製品からの話」ではなく、すでに売っている製品も対象に入ります。
対象になる製品、ならない製品¶
対象は「デジタル要素を含む製品」で、ハードウェアもソフトウェアも含まれます。 一方で、純粋なSaaS（ブラウザから使うクラウドサービス）は、原則としてCRAの対象外です。
ただし例外があります。 製品が正しく動くために欠かせない「リモートデータ処理」は、製品の一部として扱われます。 たとえば、スマート家電を外出先から操作するためにメーカーが提供しているクラウド機能は、対象に含まれます。
| 例 | CRAの扱い |
|---|---|
| 家庭用ルーター、ネットワークカメラ | 対象 |
| 業務用のインストール型ソフトウェア | 対象 |
| スマート家電を遠隔操作するためのメーカーのクラウド | 製品の一部として対象 |
| 単独のSaaS（Webブラウザから使う業務サービス） | 原則として対象外（NIS2など別の規制で扱われる） |
インフラエンジニアとして関わりが深いのは、3段目のケースでしょう。 自社製品のクラウド側を運用している場合、そのサーバー群も報告の対象範囲に入りうるわけです。
始まった報告義務の中身を見てみよう¶
では、具体的に何を、いつまでに報告するのでしょうか。
報告の対象は、大きく2つです。 製品に含まれる「積極的に悪用されている脆弱性」と、製品のセキュリティに影響する「重大インシデント」です。
24時間・72時間・最終報告という3段階¶
報告には、段階ごとに期限があります。 いちばん短いものは、把握してから24時間以内です。
| 段階 | 期限 | 主な内容 |
|---|---|---|
| 早期警告 | 把握から24時間以内 | 悪用やインシデントが起きていることの第一報 |
| 通知 | 把握から72時間以内 | 脆弱性や悪用の性質、講じた対策、利用者がとれる対策 |
| 最終報告（脆弱性） | 修正措置が利用可能になってから14日以内 | 深刻度と影響、原因、修正内容など |
| 最終報告（インシデント） | 72時間の通知から1か月以内 | 原因の見立て、実施中の緩和策など |
報告は、EUのサイバーセキュリティ機関であるENISAが運営する「単一報告プラットフォーム（SRP）」から行います。 一度提出すると、調整役の各国CSIRTを通じて、製品が売られている他の加盟国の当局にも情報が共有される仕組みです。
また、オープンソースソフトウェアの「スチュワード」と呼ばれる、OSSを継続的に支援する組織にも、一定の報告義務が定められています。
違反するとどうなるの？¶
CRAには罰則もあります。 違反の内容によっては、最大1500万ユーロ、または全世界の年間売上高の2.5%のいずれか高いほうが上限とされています。
金額の大きさもさることながら、EU市場で製品を売り続けられるかどうかに関わる話です。 日本のメディアでも、24時間以内に報告できる体制づくりが急務だと報じられています。
なぜ、インフラエンジニアに関係してくるの？¶
ここまで読むと、「法務やセキュリティ部門の仕事では？」と感じるかもしれません。 たしかに、報告書を提出するのは別の部署かもしれません。
でも、24時間以内に第一報を出すには、次の問いにすぐ答えられる必要があります。
- その脆弱性のあるソフトウェアは、どの製品の、どのバージョンに入っている？
- いつから悪用されていた？ログは残っている？
- 影響を受けたサーバーや利用者の範囲は？
この答えを持っているのは、多くの場合インフラエンジニアです。 報告の期限は、調べ始めた時点からではなく、把握した時点から数え始めます。 だから、調べ方を知っていても、記録がなければ間に合いません。
火事のときの「避難経路図」と同じ¶
たとえるなら、ビルの避難経路図のようなものです。 火事が起きてから図を描き始めても、誰も逃げられませんよね。
脆弱性の報告も同じで、平時に「どこに何があるか」を把握しておくことが、そのまま報告のスピードになります。 CRAは、その平時の準備ができているかを問う法律だともいえます。
「積極的に悪用されている」かどうかは、どう知るの？¶
報告の対象になるのは、すべての脆弱性ではありません。 「積極的に悪用されている」脆弱性です。
では、自分たちの製品に入っている脆弱性が、実際に悪用されているかどうかは、どうやって知ればよいのでしょうか。 ここは、インフラエンジニアが普段の情報収集で力を発揮できるところです。
自社で気づくケースと、外から知るケース¶
悪用に気づくきっかけは、大きく2つに分かれます。
一つは、自社の環境で気づくケースです。 監視のアラートや、見慣れないアクセスのログから、攻撃の痕跡が見つかることがあります。 製品のクラウド側を運用しているなら、そのサーバーのログがまさに最初の手がかりになります。
もう一つは、外部の情報から知るケースです。 たとえば米国のCISAは、実際に悪用が確認された脆弱性を KEV（Known Exploited Vulnerabilities）カタログとして公開しています。 日本語で情報を追うなら、JPCERT/CCとIPAが共同で運営する脆弱性情報ポータルのJVNが入り口になります。
| 情報源 | 分かること | 使いどころ |
|---|---|---|
| 自社の監視・ログ | 自分の環境で攻撃が起きているか | クラウド側の運用、社内の検証環境 |
| CISA KEVカタログ | 世界で悪用が確認された脆弱性の一覧 | 優先して対応すべきものの見極め |
| JVN | 日本語での脆弱性情報と対策 | 国内製品や日本語での情報共有 |
大事なのは、こうした情報と、備え1で作るパッケージの一覧を照らし合わせられることです。 一覧と情報源の両方がそろってはじめて、「うちの製品は影響を受けるか」を短い時間で判断できます。
製造業者以外の立場でも、無関係ではない¶
CRAは、製品を作る製造業者だけでなく、EUに製品を持ち込む輸入業者や、販売する流通業者にも一定の義務を定めています。 自社は製品を作っていなくても、取引先の製品を扱っている場合は、脆弱性の情報を製造業者に伝える役割が求められることがあります。
また、自社の業務システムに使っている製品が対象になっていれば、メーカーから脆弱性の通知が届く機会も増えるでしょう。 通知を受け取ったときに、社内のどのサーバーに影響するかを答えられるかどうか。 ここでも、やはり日ごろの把握がものをいいます。
現場で整えておきたい3つの備え¶
ここからは、インフラエンジニアが手を動かせる備えを見ていきます。 どれも、CRAの対象かどうかに関係なく、運用の質を上げてくれるものばかりです。
備え1：何が入っているかを、機械で読める形で残す¶
2027年12月から全面適用される要件には、SBOM（ソフトウェア部品表）の作成も含まれています。 少なくとも最上位の依存関係を、機械で読める形でまとめておくことが求められます。
SBOMの考え方そのものは 2026年のソフトウェアサプライチェーン攻撃とSBOM／SLSAで守る新常識 で詳しく解説しました。 インフラの現場なら、まずはサーバーやコンテナに入っているパッケージの一覧を取れるようにしておくことから始められます。
# RHEL系：インストール済みパッケージとバージョンを一覧にする
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\n' | sort > packages_$(hostname)_$(date +%F).tsv
# Debian/Ubuntu系：同じくパッケージとバージョンを一覧にする
dpkg-query -W -f='${Package}\t${Version}\n' | sort > packages_$(hostname)_$(date +%F).tsv
# コンテナイメージからSBOMを作る例（Syftを使う場合）
syft nginx:latest -o cyclonedx-json > sbom_nginx.json
一覧があれば、新しい脆弱性が公表されたときに「うちの製品に入っているか」を数分で確かめられます。 一覧がなければ、全サーバーにログインして調べるところから始めることになります。
備え2：ログの保管期間と時刻をそろえる¶
「いつから悪用されていたか」を答えるには、ログが残っていることが前提です。 そして、複数のサーバーのログを並べて読むには、時刻がずれていないことも欠かせません。
# 時刻同期ができているかを確認する（chronyの場合）
chronyc tracking
# ログのローテーション設定で、保管期間を確認する
grep -E 'rotate|daily|weekly' /etc/logrotate.conf
ログの読み方に自信がない方は、原因はだいたいログに書いてある。ログの読み方入門 から押さえておくと安心です。
備え3：報告の流れを、平時に1回なぞっておく¶
最後は、技術というより段取りの話です。 脆弱性を見つけたとき、誰が誰に連絡し、どの情報を集めるのか。 この流れを一度、訓練としてなぞっておくと、本番で24時間を無駄にしません。
報告の期限は「調査が終わってから」ではなく「把握してから」数え始める。だから、最初の数時間で集める情報を、あらかじめ決めておくことが大切です。
日本でも、2026年10月から基幹インフラ事業者にインシデント報告を義務づける仕組みが動き出します。 国内の動きは 能動的サイバー防御の法律がインフラエンジニアの現場に求めること で整理しました。 国内と海外、どちらの報告にも同じ準備が効いてくるはずです。
学び直すなら、どこから？¶
CRAのような規制の話は、最終的に「自分の環境に何があり、何が起きたかを説明できるか」に行きつきます。 これは、Linuxやネットワークの基礎を理解しているからこそできることです。
InfraAcademy の Linuxロードマップ では、パッケージ管理やログ、時刻同期といった、今回の備えの土台になる内容を順番に学べます。 ネットワーク側の基礎を固めたい方は ネットワークロードマップ もあわせてどうぞ。
また、チームで脆弱性対応や報告の流れを教えたい企業の方は、法人プラン もご覧ください。
まとめ¶
今回は、2026年9月11日に報告義務が始まった、EUのサイバーレジリエンス法（CRA）を見てきました。
- CRAは、EU市場向けのデジタル要素を含む製品に、販売後まで続くセキュリティ責任を求める
- 悪用された脆弱性や重大インシデントは、把握から24時間以内の早期警告が必要
- すでに市場にある製品も対象で、日本企業も無関係ではない
- 報告を支えるのは、パッケージの把握、ログと時刻、報告の段取りという平時の準備
規制が増えるのは大変に見えますが、求められていることの中身は、良い運用そのものです。 できるところから一つずつ、備えを整えていきましょう。
参考¶
- The CRA Single Reporting Platform is launched（ENISA）
- Single Reporting Platform (SRP)（ENISA）
- Cyber Resilience Act - Reporting obligations（European Commission）
- Cyber Resilience Act: the fine line between SaaS and digital products（DLA Piper）
- 欧州CRAが26年9月に脆弱性報告を義務化、24時間以内に報告できる体制が必要（日経クロステック）
- EU Cyber Resilience Act – Open Source Security Foundation
- Known Exploited Vulnerabilities Catalog（CISA）
- JVN（Japan Vulnerability Notes）
