# EU法の "incident" と日本語の「インシデント」の差異に関する考察 ## 更新履歴 | 版 | 日付 | 内容 | |---|---|---| | 初版 | 2026-09-05 | 作成 | --- ## 1. 本レポートの目的 **【事実】** EU サイバーレジリエンス法（Regulation (EU) 2024/2847。以下「CRA」）第14条は、2026年9月11日から適用される[^1]。同条は、デジタル要素を持つ製品の製造者に対し、「能動的に悪用されている脆弱性」と「製品のセキュリティに影響を与える重大インシデント（severe incident）」の報告を義務づける。認識から24時間以内の早期警告が起点となる。 **【解釈】** この "incident" は、日本語の「インシデント」と同じ範囲を指していない。差異は翻訳の巧拙の問題ではなく、**二つの体系がそれぞれ内部で一貫した設計を持ち、その設計が異なることに由来する**。したがって「正しい訳語を選ぶ」ことでは解消しない。 **【解釈】** 本レポートは、この差異の所在と構造を明らかにし、実務上の対処を示す。結論を先に述べれば、対処は語を置き換えることではなく、**両者が似て非なるものであるという前提を持つこと**である。 構成は次のとおりである。第2章から第3章で、EU法と日本語圏の各体系がそれぞれ incident をどう定義しているかを一次情報で確認する。第4章から第6章で、両者のずれの構造を、状態と事象の区別を軸に整理する。第7章と第8章で、EU法内部の不統一と英語圏における議論状況を検討し、この差異が日本語固有のものかを確認する。第9章で日本語訳の実態を、第10章で日本法との比較を扱う。第11章に実務上の含意を、第12章に事実・解釈・仮説の区分を、第13章に残された論点をまとめた。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 2. EU法における "incident" ### 2.1 CRA第14条の報告対象は三層で画定される **【事実】** CRA第14条(3)は「製品のセキュリティに影響を与える重大インシデント」の報告を義務づける。この報告対象は、第14条の中だけで完結しておらず、三つの条文にまたがって画定されている[^1]。 | 層 | 用語 | 根拠条文 | 内容 | |---|---|---|---| | ① | `incident` | 第3条(43) → NIS2第6条(6) | 保存・伝送・処理されるデータ、またはネットワーク・情報システムが提供しもしくは経由して利用可能なサービスの、可用性・真正性・完全性・機密性を侵害する事象一般 | | ② | `incident having an impact on the security of the product with digital elements` | 第3条(44) | ①のうち、製品がデータまたは機能を保護する能力に悪影響を与える、または与えうるもの | | ③ | `severe` | 第14条(5) | ②のうち、重大と評価されるもの | **【事実】** 第14条(3)の文言は "any **severe** incident having an impact on the security of the product with digital elements" であり、②の語句に "severe" が前置修飾された構造をとる。したがって各条文の役割は次のとおりである。 - 第14条(3)：報告対象（②かつ③）の指定、報告先、同時通知の義務 - 第14条(5)：③の判定基準のみ - 第3条(44)：②の定義（第14条の中にはない） - 第3条(43)：①の定義（CRA本文になく、NIS2への参照で入る） **【事実】** 第14条(5)は、③の判定基準を次のように定める[^1]。 > 5. For the purposes of paragraph 3, an incident having an impact on the security of the product with digital elements shall be considered to be severe where: > > (a) it negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or > > (b) it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product with digital elements. > > （参考訳：5. 第3項の適用上、デジタル要素を持つ製品のセキュリティに影響を与えるインシデントは、次のいずれかに該当する場合に重大とみなされる。／(a) 機微または重要なデータもしくは機能の可用性・真正性・完全性・機密性を保護するデジタル要素を持つ製品の能力に悪影響を与え、または与え**うる**場合、または／(b) デジタル要素を持つ製品内、もしくは当該製品の利用者のネットワーク・情報システム内における悪意あるコードの導入または実行につながった、もしくはつながり**うる**場合） **【解釈】** 実務上、第14条(5)は目に付きやすい。判定基準が明示的に列挙されているためである。一方、①の定義は第3条(43)を経て別の法令の中にある。**判定の入口が、判定基準の列挙より三段階手前に置かれている。** この構造は、読み手が③から読み始めることを誘発する。 ### 2.2 NIS2は "incident" と "near miss" を書き分けている **【事実】** CRA第3条(43)が参照するNIS2指令（Directive (EU) 2022/2555）第6条には、二つの定義が隣接して置かれている[^2]。 > (5) 'near miss' means an event that could have compromised the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems, but that was successfully prevented from materialising or that did not materialise; > > （参考訳：「ニアミス」とは、保存・伝送・処理されるデータ、またはネットワーク・情報システムが提供しもしくは経由して利用可能なサービスの、可用性・真正性・完全性・機密性を侵害し**えた**事象であって、実現が阻止された、または実現しなかったものをいう） > (6) 'incident' means an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems; > > （参考訳：「インシデント」とは、上記と同じものを**侵害する**事象をいう） **【事実】** 両者の差は、`could have compromised ... but ... did not materialise`（侵害しえたが実現しなかった）と `compromising`（侵害する）の対比にある。**EU法は「侵害が生じた事象」と「侵害が生じなかった事象」を、別々の語で定義している。** **【事実】** そしてCRAは、この二つを別々の条文に振り分けている。CRA第15条(2)は、near miss および「製品のセキュリティに影響を与えるインシデント」（＝②のまま、severe の限定を付さないもの）を任意報告の対象としている[^1]。 | 該当範囲 | 扱い | |---|---| | ②かつ③ | 第14条(3)による**義務的報告** | | ②のみ | 第15条(2)による**任意報告** | | near miss | 第15条(2)による**任意報告** | | ①のみ（製品のセキュリティに影響しない社内インシデント等） | CRA上の報告対象外 | ### 2.3 「うる」がどこに置かれているか **【事実】** CRA第14条の判定において、可能性を示す文言は②と③にのみ存在する。 | 層 | 文言 | 可能性の文言 | |---|---|---| | ① | `compromising` | **なし** | | ② | `capable of negatively affecting` | あり | | ③ | `capable of negatively affecting`（(a)）／`capable of leading to`（(b)） | あり | **【解釈】** すなわち条文の構造は、「**現に侵害が生じた事象**を起点とし、その事象が製品に及ぼす帰結がまだ確定していない段階でも報告対象とする」というものである。「うる」は帰結の不確定性を指すのであって、起点となる事象の存在や侵害の発生を緩めるものではない。 **【解釈】** この点は誤読されやすい。第14条(5)(b)の「つながりうる」を判定の緩さと受け取ると、「侵害されうる状態」全般が報告対象に見える。しかし①がアンカーとして働くため、そうはならない。 **【事実】** 委員会ガイダンスは、報告義務が生じる場面を説明する際、「重大インシデントが発生し、かつ**製品のセキュリティが危殆化されるに至った（has occurred and has led to the security of its product with digital elements being compromised）**」という表現を用いている[^10]。 **【解釈】** 完了の語（has led to ... being compromised）が用いられており、「危殆化されうる」ではない。ただしこれは「認識」の時点を論じる文脈での言い換えであり、**重大インシデントの定義を確認したものではない**。同ガイダンスは第14条(5)に言及していない（第8.1節）。したがって、この記述は本レポートの読みと整合するが、当局による定義の確認として扱うことはできない。 ### 2.4 層ごとに修飾語が異なる **【事実】** ②と③を比較すると、データ・機能に対する限定語が一致していない。 | 条文 | データ・機能への限定 | |---|---| | 第3条(44)（②の定義） | "data or functions" ― **限定なし** | | 第14条(5)(a)（③の基準） | "**sensitive or important** data or functions" ― 限定あり | | 第14条(5)(b)（③の基準） | **限定語を置いていない** | **【解釈】** 入口である②は広く取り、重大性判定(a)で「機微または重要な」という絞りをかける設計と読める。ところが(b)にはこの絞りがない。悪意あるコードの導入・実行という事実そのもので成立し、対象データの重要性を問わない。 **【解釈】** したがって(b)は(a)より早く、低い閾値で発火する。「capable of」の文言だけでなく、この修飾語の非対称にも由来する。 ### 2.5 前文68が示す典型例 **【事実】** CRA前文68は、重大インシデントの典型例を次のように述べる[^1]。 > Severe incidents having an impact on the security of the product with digital elements, on the other hand, refer to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer in such a way that it could result in an increased cybersecurity risk for users or other persons. Such a severe incident could include a situation where an attacker has successfully introduced malicious code into the release channel via which the manufacturer releases security updates to users. > > （参考訳：他方、デジタル要素を持つ製品のセキュリティに影響を与える重大インシデントとは、サイバーセキュリティインシデントが製造者の開発・生産・保守のプロセスに影響を与え、その結果、利用者その他の者にとってのサイバーセキュリティリスクを増大させうる状況をいう。そのような重大インシデントには、攻撃者が、製造者が利用者にセキュリティ更新を配信するリリースチャネルに悪意あるコードの導入に成功した状況が含まれうる。） **【解釈】** 同前文は、能動的に悪用されている脆弱性と重大インシデントを "on the other hand"（他方）で対比しており、両者を並列の別類型として書き分けている。**製造者の開発・生産・保守プロセスへの侵害は、周辺事例ではなく中核的な想定である。** --- ## 3. 「インシデント」概念の分野別の実態 **【解釈】** 日本語話者が「インシデント」の語に「おそれ」を含めるのは、個人の感覚の問題ではない。**複数の体系が、それぞれ独立にその方向の定義を与えている。** 以下、分野ごとに一次的な定義を確認する。 ### 3.1 航空：ICAO Annex 13 **【事実】** 国際民間航空条約第13附属書（ICAO Annex 13）は、incidentを次のように定義する[^3]。 > Incident. An occurrence, other than an accident, associated with the operation of an aircraft which affects or could affect the safety of operation. > > （参考訳：インシデントとは、アクシデント以外の事象であって、航空機の運航に関連し、運航の安全に影響を及ぼす、または及ぼしうるものをいう） **【事実】** さらに serious incident（重大インシデント）が置かれ、注記において次のように述べられている[^3]。 > The difference between an accident and a serious incident lies only in the result. > > （参考訳：アクシデントと重大インシデントの違いは、結果においてのみ存在する） **【解釈】** 「結果においてのみ違いがある」という注記は、この体系が**害の発生という結果を基準に語を分けている**ことを明示している。incidentは定義上、accidentを除いたものである。 ### 3.2 労働安全：ISO 45001（逆の構造） **【事実】** ISO 45001:2018（労働安全衛生マネジメントシステム）の3.35は、incidentを次のように定義する[^4]。 > occurrence arising out of, or in the course of, work that could or does result in injury and ill health > > Note 1 to entry: An incident where injury and ill health occurs is sometimes referred to as an "accident". > > Note 2 to entry: An incident where no injury and ill health occurs, but has the potential to do so, may be referred to as a "near-miss", "near-hit" or "close call". > > （参考訳：業務に起因して、または業務の過程で生じる事象であって、負傷および疾病を生じ**うる**もの、または現に生じさせたものをいう。／注記1：負傷および疾病が生じたインシデントは、「アクシデント」と呼ばれることが**ある**。／注記2：負傷および疾病が生じないインシデントであって、**生じる潜在性を有するもの**は、「ニアミス」「ニアヒット」「クロースコール」と呼ばれること**がある**） **【解釈】** ISO 45001では**incidentが上位概念**であり、accidentもnear-missもその部分集合として注記に置かれる。ICAO Annex 13とは包含関係が逆転している。**安全工学の内部でも用語法は一枚岩ではない。** **【解釈】** ただし、規格本文が定義しているのはincidentのみであり、accidentとnear-missは「呼ばれることがある（sometimes / may be referred to as）」という緩やかな言及にとどまる点に注意が要る。**ISO 45001はaccidentとnear-missを定義していない。** **【解釈】** それでも、両者に共通する点がある。**いずれも「生じうるもの（could result in）」を incident の内包に含めている。** 包含関係は逆でも、「おそれ」を含むという性質は共通する。さらに注記2は、near-missについても「生じる潜在性を有する」ことを要件としており、**この体系では「おそれ」が概念の中核に置かれている。** ### 3.3 医療安全：厚生労働省 **【事実】** 厚生労働省医療安全対策検討会議（2002年）は、次の定義を示している[^5]。 - **アクシデント＝医療事故**：医療に関わる場所で医療の全過程において発生する人身事故一切を包含し、医療従事者が被害者である場合や廊下で転倒した場合なども含む - **インシデント＝ヒヤリ・ハット**：日常診療の場で、誤った医療行為などが患者に実施される前に発見されたもの、あるいは、誤った医療行為などが実施されたが、結果として患者に影響を及ぼすに至らなかったものをいう **【解釈】** この体系では、**インシデントは定義上「害が生じなかったもの」を指す**。害が生じたものはアクシデントと呼ばれ、インシデントから除かれる。 **【解釈】** 医療・介護・看護の分野で職業教育を受けた者にとって、「インシデント」は明確に「おそれ」の側の語である。この語感は、分野を越えて日本語話者一般に相当程度浸透している。 ### 3.4 情報セキュリティ：JIS Q 27000 **【事実】** 情報セキュリティマネジメントシステムの用語規格 JIS Q 27000:2019 は、「情報セキュリティインシデント」を次のように定義する[^6]。 > 望まない単独若しくは一連の情報セキュリティ事象，又は予期しない単独若しくは一連の情報セキュリティ事象であって，事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの **【事実】** 対応する原規格 ISO/IEC 27000 の英文は次のとおりである[^7]。 > single or series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security > > （参考訳：望まない、または予期しない単独もしくは一連の情報セキュリティ事象であって、事業運営を危うくし、情報セキュリティを脅かす**確率が高い**もの） **【事実】** 定義の核は `significant probability of compromising`（危殆化させる確率が高い）である。NIS2第6条(6)の `compromising`（侵害する）とは、**同じ動詞を用いながら、確率で修飾するか否かが異なる**。 **【解釈】** この差は決定的である。**日本の情報セキュリティ実務が依拠する公式の定義そのものが、侵害の発生を要件とせず、確率で定義している。** 日本語話者が「インシデント」に「おそれ」を含めるのは、規格に忠実であることの帰結であって、逸脱ではない。 **【事実】** なお、両者は目的語も異なる。ISO/IEC 27000が挙げるのは事業運営（business operations）および情報セキュリティであり、NIS2が挙げるのは保存・伝送・処理されるデータ等の四要素である。JIS公式訳は当該箇所を「事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの」と訳している[^6]。 **【解釈】** すなわち両者の差は確率修飾の有無だけではなく、**何を侵害の対象とするか**にも及ぶ。ISMSの定義は組織の事業運営を基準とし、EU法の定義はデータとサービスの属性を基準とする。ただし本レポートの論点にとって決定的なのは前者である。 **【事実】** なお JIS Q 27000 は、その前段階として「情報セキュリティ事象（information security event）」を別に定義している[^6]。 > 情報セキュリティ方針への違反若しくは管理策の不具合の可能性，又はセキュリティに関係し得る未知の状況を示す，システム，サービス若しくはネットワークの状態に関連する事象 **【解釈】** ISMS体系は「事象（event）→ インシデント（incident）」という二段構えをとる。事象のうち、侵害の確率が高いものがインシデントである。**この体系において、インシデントとは評価の結果として与えられる格付けであり、侵害の事実そのものではない。** ### 3.5 サイバー：JPCERT/CC・NIST **【事実】** JPCERT/CCは、コンピュータセキュリティインシデントを「情報および制御システムの運用におけるセキュリティ上の問題として捉えられる事象」と説明する[^8]。例として、情報流出、フィッシングサイト、不正侵入、マルウエア感染、Webサイト改ざん、DoS（DDoS）攻撃を挙げる。 **【事実】** NIST SP 800-61 Revision 3 は、cybersecurity incident を次のように定義する[^9]。 > An occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. > > （参考訳：正当な権限なく、情報または情報システムの完全性、機密性もしくは可用性を、現に、または差し迫って危殆化させる事象。あるいは、法令、セキュリティポリシー、セキュリティ手順もしくは利用規程の違反、または違反の差し迫った脅威を構成する事象） **【事実】** なお、この定義はNIST独自のものではなく、2014年連邦情報セキュリティ近代化法（FISMA 2014）からの引用として出典が付されている[^9]。 **【解釈】** いずれも**害の発生を要件としていない**。攻撃の検知、ポリシー違反、切迫した脅威までが同一の語で括られている。 ### 3.6 なぜサイバーの incident は広いのか **【解釈】** 理由は語彙の未熟さではなく、対象の性質にある。 | 観点 | 物理事象 | サイバー事象 | |---|---|---| | 害の発生 | 発生と同時に観測可能 | 潜伏する | | 害の範囲 | 現場を見れば判明する | 調査を経ないと不明 | | 判定時点 | 即時 | 数週間〜数か月後 | **【解釈】** 航空機が墜落したかどうかは、その場で判定できる。したがって害の有無で語を分けることが可能である。一方、サイバー事象では侵入から発覚まで数か月を要することがあり、被害の確定にはさらに時間がかかる。**初動の時点では、害があったのかどうかが分からない。** 害の有無で語を分ける方式を採ると、対応を開始する時点で使うべき語が決まらない。 **【解釈】** したがって、サイバーセキュリティの incident が広いのは、**害の有無が事後にしか判定できないという認識論的な制約に由来する**と整理できる。対応の起動条件として機能する語が必要であり、そのためには害の有無を問わない概念でなければならなかった。 **【解釈】** これを裏返すと、サイバーセキュリティには**害が確定した事象を指す専用語が存在しない**ということになる。breachは近いが、日本語では「侵害」「漏えい」「被害」「事故」と訳が揺れ、定着していない。結果として incident が両方を飲み込んでいる。 ### 3.7 五つの体系の重なり **【解釈】** 日本語話者が接する定義を整理すると、次のようになる。 | 出典 | 「インシデント」の性質 | |---|---| | ICAO Annex 13（航空） | accident以外の事象。「及ぼしうる」を含む | | ISO 45001（労働安全） | 上位概念。「生じうる」を含む | | 厚労省（医療安全） | **害が生じなかった**事象。害が生じたものはアクシデント | | JIS Q 27000（情報セキュリティ） | 侵害する**確率が高い**事象。侵害の発生は要件でない | | JPCERT/CC・NIST（サイバー） | 害の発生を**要件としない** | **【解釈】** 五者は同じことを言っているわけではない。医療安全の定義は害の不在を要件とするが、JIS Q 27000とJPCERT/CCの定義は害の有無を問わない。ISO 45001とICAO Annex 13は包含関係が逆である。論理的には整合していない。 **【解釈】** それにもかかわらず、**すべてが「おそれを含む」という一点で重なっている。** 日本語話者の頭の中では、この重なりだけが残り、差は吸収される。結果として形成されるのは「**インシデント＝害や侵害が確定していない段階も含む広い概念**」という理解である。 --- ## 4. ずれの構造 ### 4.1 対応関係は三分割になる **【解釈】** EU法と日本の実務感覚の対応関係を、四要素の侵害と害の発生という二軸で整理すると、次のようになる。 | 領域 | EU法の語 | 日本の実務感覚 | |---|---|---| | 侵害なし・害なし | near miss | インシデント（ヒヤリ・ハット） | | **侵害あり・害なし** | **incident** | **インシデント**（ヒヤリ・ハット寄り） | | 侵害あり・害あり | incident | アクシデント | **【解釈】** 中央の帯において、両体系の所属が食い違う。EU法はこれを incident 側に置き、日本の実務感覚はインシデント（ヒヤリ・ハット）側に置く。 **【解釈】** 具体例を挙げる。 | 事象 | 四要素の侵害 | 害の発生 | EU法 | 日本の実務感覚 | |---|---|---|---|---| | 攻撃者がWebシェルを設置。まだ何もしていない | あり（完全性） | なし | **incident** | ヒヤリ・ハット寄り | | 認証情報が窃取された。悪用の形跡なし | あり（機密性） | なし | **incident** | ヒヤリ・ハット寄り | | マルウェアの実行が試みられ、阻止された | なし | なし | near miss | インシデント | | ランサムウェアで業務停止 | あり | あり | incident | アクシデント | **【解釈】** 上二例が食い違う領域である。そして、**この領域こそがサイバーセキュリティ事案の大半を占める**。侵入は確認されたが被害は未確定、という状態が最も多い。境界線が最も太い場所を通っている。 **【解釈】** したがって「EU法の incident は日本でいうアクシデントに近い」という理解は、方向としては正しいが不正確である。EU法の incident は害の発生を要件としないためアクシデントより広く、同時に侵害の発生を要件とするため日本のインシデントより狭い。**両者は包含関係になく、部分的に重なる。** ### 4.2 誤りは二方向に生じる **【解釈】** 日本語の語感は、EU法の適用において両方向の誤りを生じさせる。 | 誤りの方向 | 原因となる語感 | 帰結 | |---|---|---| | **過大** | 「インシデントはおそれを含む」 | 脆弱性の存在やCVE公表を報告対象と誤認する | | **過小** | 「EU法の incident はアクシデントに近い」 | 侵入されたが被害が未確定の事案を対象外と誤認する | **【事実】** CRA第17条(4)により、通知したこと自体によって通知者の責任が加重されることはない[^1]。一方、第14条の義務の不遵守は第64条の最上位区分（1,500万ユーロ、または事業者の場合は前会計年度の全世界年間売上高の2.5%のいずれか高い方）に置かれている[^1]。 **【事実】** ただし第64条(10)(a)は、零細企業および小企業について、第14条(2)(a)および第14条(4)(a)の期限（24時間の早期警告）に係る制裁金を免除している。中企業には適用されない。なお同項の柱書は、官報初出時には「第3項から第9項の適用除外」と規定されており、第14条違反の制裁金を定める第2項が文言上含まれていなかった。この点は2025年7月2日付の正誤表により「第2項から第9項」に訂正されている[^1]。 **【解釈】** すなわち制裁は非対称である。過大報告は制裁を招かず、過小報告は最上位区分に触れる。**実務上は過小方向の誤りのほうが危険である。** 零細・小企業には24時間期限についての緩和があるが、義務そのものが免除されるわけではない。 --- ## 5. 「状態」と「事象」 ### 5.1 vulnerability と incident は別系列である **【事実】** CRA第3条(40)は「脆弱性（vulnerability）」を、サイバー脅威によって悪用されうる製品の弱点・脆さ・欠陥として定義する[^1]。これは**製品の属性**であり、時刻を持たない。 **【事実】** 一方、incident も near miss も `event`（事象）として定義される。時刻を持つ。 **【事実】** さらに near miss は「実現が阻止された、または実現しなかった」という確定した否定を要件とする。したがって、事象が存在しない状態は near miss にも当たらない。 **【解釈】** したがって「ある製品が脆弱性を内包している状態」は、EU法において vulnerability であって incident ではない。これに接続する報告ルートは第14条(1)（能動的に悪用されている脆弱性）であり、第14条(3)ではない。 **【事実】** そして第14条(1)のルートは、第3条(42)により「悪意ある行為者がシステム所有者の許可なくシステム内でこれを悪用したという信頼できる証拠が存在する」ことを要件とする[^1]。単に悪用可能であることでは足りず、CVSSスコアの高低も判断基準ではない。CRAは第3条(41)で "exploitable vulnerability"（悪用可能な脆弱性）を別に定義しており、両者は条文上書き分けられている[^1]。欧州委員会のFAQも、統合コンポーネントに脆弱性があっても自社製品で悪用されえないのであれば能動的悪用に当たらないとしている[^12]。委員会ガイダンスはさらに踏み込み、第三者コンポーネント由来の脆弱性について、(i) 自社製品では悪用されえない場合（脆弱なコードが到達可能でない場合を例示）、または (ii) 自社製品では悪用されていない場合には、義務的報告の対象とならないとしている[^10]。 **【解釈】** すなわち判定に要するのは、脆弱性の存否ではなく**自社製品における悪用可能性と、現実の悪用の有無**である。到達可能性は前者の一例にすぎず、到達可能なコードであっても現に悪用されていなければ義務的報告の対象とならない。この判定を24時間で行える構成情報の管理が、報告義務への備えの実質をなす。 **【解釈】** 以上より、条文は**状態を脆弱性ルートに、事象をインシデントルートに振り分けている。状態がインシデントルートに入る経路は設けられていない。** ### 5.2 二種類の「おそれ」 **【解釈】** 日本語の「おそれ」「可能性」は、次の二つを区別しない。 | 種類 | 内容 | EU法上の扱い | |---|---|---| | **静的な可能性** | 脆弱性があるので、いつか侵害されうる | vulnerability。悪用の証拠がなければ報告義務なし | | **動的な可能性** | 事象が起きた。侵害されたかもしれない、または帰結が確定していない | 第14条(5)(b)の "capable of leading to"。報告対象 | **【解釈】** 日本語話者は、静的な可能性を動的な可能性と同じ「おそれ」の語で捉え、さらにその「おそれ」を含む語として「インシデント」を選択する。**二回の橋渡しが、いずれも語彙の側で自動的に行われる。** **【解釈】** EU法はこの二回とも切っている。一回目は vulnerability と incident を別系列に置くことで、二回目は incident の定義に `compromising` を置くことで。 ### 5.3 判定の第一の問い **【解釈】** 以上から、報告対象の判定において最初に置くべき問いが確定する。重大性でも侵害の有無でもなく、次の問いである。 > **事象が起きたか。それとも、元々そういう状態だったか。** **【解釈】** ここで系列が分かれ、分かれた先で初めて別々の判定に入る。この問いを飛ばして第14条(5)の判定基準から読み始めると、状態と事象が同じ表に混在することになる。 **【解釈】** 比喩を用いれば、次のようになる。家が燃えている、あるいは煙が立ちこめている——これはインシデントである。誰かがガソリンを撒いた——これも事象であり、家の安全な状態が外部の作用によって現に変更されている。一方、家が燃えやすい材で建っている——これは属性であって、事象ではない。**問うべきは「今どういう状態か」ではなく「その状態に至る事象があったか」である。** --- ## 6. 条文が語を持たない領域 **【事実】** NIS2の incident と near miss は、いずれも侵害の発生が**確定した後**の語である。incident は侵害が生じたもの、near miss は「実現が阻止された、または実現しなかった」もの——後者は確定した否定である。 **【解釈】** したがって、**「事象は起きたが、侵害が生じたか未確定」という状態を指す語が、EU法には存在しない。** **【解釈】** そして、実務において認識の瞬間に立っているのは、常にこの領域である。侵入の痕跡を検知した時点で分かっているのは「何かが起きた」ことだけであり、四要素のどれが侵害されたかは調査を経ないと確定しない。 **【解釈】** 第3.6節で整理した認識論的制約——害の有無は事後にしか判定できない——を、EU法は条文の側で吸収せず、製造者に押し戻した。日本の実務語彙が「インシデント」を広く定義することでこの空白を埋めてきたのに対し、EU法は語を精密に分けた結果、**最も頻度の高い状態を指す語を失っている**。 **【事実】** 欧州委員会が2026年7月27日に公表したガイダンス（非拘束）は、第14条の「認識（becoming aware）」について、速やかな初期評価を経て合理的な程度の確実性に達した時点とする解釈を示している[^10]。 **【事実】** 同ガイダンスは、この「認識」の解釈を、NIS2実施規則（EU）2024/2690の前文31およびGDPRの個人データ侵害通知に関するガイドライン9/2022のSection II(A)と整合させた旨を明記している[^10]。 **【解釈】** この基準は、まさに上記の空白に置かれている。「侵害があったという確実性」ではなく「侵害があったと考えるに足る合理性」であり、この領域を報告義務が発生する側に寄せる基準である。他法令との整合が図られていることは、**この空白がCRA固有ではなく、EUの報告義務体系に共通する問題である**ことを示している。ただしガイダンスは非拘束であり、ガイダンス自身が、CRAの権威的解釈はEU司法裁判所のみが与えうると明記している[^10]。 **【解釈】** **どちらの体系も、何かを取って何かを捨てている。** EU法は義務の外縁を確定するために精密さを取り、判定中の空白を製造者の負担として残した。日本の実務語彙は起動条件として使えることを取り、外縁の曖昧さを残した。優劣の問題ではない。 --- ## 7. EU法内部における "incident" の複数性 **【事実】** EUの新しいサイバーセキュリティ法群は、複数の incident 類型を持つ。Ruohonen らの分析（査読誌 Computers & Security 掲載）によれば、次のように整理される[^13]。 | 類型 | 定義の所在 | 報告義務 | |---|---|---| | near miss | NIS2第6条(5) | 任意 | | incident（通常のインシデント） | NIS2第6条(6) | **任意** | | severe incident（重大インシデント） | CRA第14条(3)・(5) | 義務 | | significant incident（重要インシデント） | NIS2第23条(3) | 義務 | | large-scale cybersecurity incident（大規模インシデント） | NIS2第6条(7) | 義務（含意） | | actively exploited vulnerability | CRA第3条(42) | 義務 | **【事実】** これらのうちCRAに基づく報告は、ENISAが運用する単一報告プラットフォーム（SRP）を通じて行われる。SRPは義務的報告と任意報告の双方に対応する[^18]。 **【解釈】** 注意すべきは、**NIS2第6条(6)の incident それ自体は、報告義務の対象ではない**点である。NIS2第30条により任意報告にとどまる。義務が生じるのは、そこに severe（CRA）あるいは significant（NIS2）という修飾が加わった場合である。 **【解釈】** すなわち、EU法において incident とは**報告義務の単位ではなく、義務を画定するための基礎概念**である。この点は、日本の実務で「インシデントが発生したら報告する」という発想が一般的であることと対照的である。 **【事実】** さらに、同一の語がEU法内部で統一されていない箇所がある。Ruohonen らは、CER指令（Directive (EU) 2022/2557、重要事業体レジリエンス指令）第2条(3)にも incident の定義が置かれており、**その定義がNIS2の定義と同一でない**ことを指摘している[^13]。 **【事実】** CER指令第2条(3)の定義は「不可欠なサービスの提供を著しく妨げる**潜在性を有する**、または現に妨げる事象」である[^14]。NIS2第6条(6)と比べると、侵害の対象（四要素／不可欠サービスの提供）が異なるだけでなく、**可能性を示す文言（has the potential to）が定義そのものに含まれている**点で異なる。 **【解釈】** すなわちEU法は、ある法令では incident の定義に可能性を含め、別の法令では含めない。**同じ語が、法令ごとに「おそれ」を含んだり含まなかったりする。** 本レポート第2.3節で確認したNIS2の厳格さは、EU法全体の特徴ではなく、NIS2固有の設計である。 **【解釈】** つまり「EU法における incident」という単一の概念が存在するわけではない。**どの法令の、どの条文の incident かを特定しなければ、範囲は定まらない。** 日本語話者にとっての不通約性の問題は、この不統一の上に重なることになる。 --- ## 8. 英語圏における議論状況 **【解釈】** 本レポートが扱う差異は、日本語固有の問題なのか。それとも、ISMS体系と法令体系の断層として、言語を問わず存在するのか。この点を確認するため、英語圏の学術・実務双方の文献を調査した。 ### 8.1 学術文献：「capable of」の境界問題として認識されている **【事実】** Ruohonen らは、CRA第14条(5)について次のように述べている[^13]。 > It remains to be seen how manufacturers will interpret the demarcation between the impacts and executions on one hand and the potential impacts and executions on the other hand. > > （参考訳：製造者が、現実の影響および実行と、潜在的な影響および実行との境界をどう解釈するかは、今後を待つほかない） **【事実】** 同様に、NIS2第23条(3)の significant incident に含まれる "capable of" の文言についても、次のように指摘している[^13]。 > the wording "capable of" yet again entails a demarcation problem between actual significant incidents and those merely conveying a probability of such incidents. Presently, no guidance is available upon this demarcation > > （参考訳：「capable of」という文言は、現実の重要インシデントと、単にその確率を示すにすぎないものとの間に、境界画定の問題を再び生じさせる。現在、この境界についてのガイダンスは存在しない） **【解釈】** すなわち、**英語圏の学術文献においても、「現実の影響」と「潜在的な影響」の境界は未解決の問題として認識されている。** 本レポート第2.3節および第5.2節で扱った論点は、日本語話者に固有のものではない。 **【事実】** ただし、比較対象が異なる。Ruohonen らが NIS2 の incident 定義について比較しているのは NIST の定義であり[^13]、ISO/IEC 27000 の定義との差は論じられていない。 **【事実】** また、同論文は near miss を「false positive（偽陽性）」として位置づけ、アラートのうち実際のインシデントになることが阻止されたものと解釈している[^13]。 **【解釈】** この解釈には検討の余地がある。NIS2第6条(5)の文言「実現が阻止された、または実現しなかった」は、誤検知だけでなく、**現実の攻撃が防御機構によって阻止された場合**も含むと読むほうが自然である。誤検知（そもそも攻撃がなかった）と阻止（攻撃はあったが防がれた）は、実務上まったく異なる意味を持つ。この点は、条文の文言が両様に読めることを示している。 **【事実】** 同論文が「ガイダンスは存在しない」と述べた後、2026年7月27日に委員会ガイダンスが公表された。同ガイダンス附属書の全文（257段落）において、**`near miss`／`near-miss`、`Article 14(5)`、`sensitive or important` のいずれも出現しない**[^10]。9.1節が扱うのは、報告義務の適用範囲、「認識」の時点、スチュワードの義務、遡及適用の否定、対象製品の範囲、利用者への通知である。 **【解釈】** すなわち、**委員会ガイダンスは境界画定の問題に答えていない。** Ruohonen らが指摘した「ガイダンスの不在」は、CRAについても解消していない。委員会が答えたのは「いつ認識したことになるか」という時点の問いであり、「何が重大インシデントに当たるか」という範囲の問いではない。 ### 8.2 実務文献：定義ではなくガバナンスの差として論じられている **【事実】** ISO/IEC 27001 と NIS2 を比較する実務向け解説は多数存在する。しかし、そこで論じられているのは次の点である。 - 認証の任意性と法令の強制力の差 - 24時間・72時間という報告期限に対応する運用能力の有無 - サプライチェーンの継続的な可視性 - 当局の求めに応じて即座に提出できる証跡 **【解釈】** すなわち、**「ISO 27001 は NIS2 コンプライアンスではない」という論点は広く共有されているが、その理由として挙げられるのはガバナンスと運用能力の差であって、incident という語の定義の差ではない。** **【解釈】** 「何が significant incident に当たるか」という閾値の議論は存在する。しかしそれは severe / significant という**修飾語の閾値**の議論であり、その手前にある incident そのものの定義の差は、実務文献では扱われていない。 ### 8.3 業界団体：トリガー時点の調和が要求されている **【事実】** DIGITALEUROPE は、Digital Omnibus（デジタル・オムニバス）に対する意見書において、次の点を求めている[^15]。 > Converging around a 72-hour substantive deadline and harmonising the trigger point, ensuring the clock starts ticking only when an incident is confirmed, would improve both compliance and security > > （参考訳：72時間の実質的期限に収斂させ、トリガー時点を調和させて、**インシデントが確認されたときに初めて時計が動き出す**ようにすることは、コンプライアンスとセキュリティの双方を改善する） **【事実】** 同意見書はまた、CRAの簡素化として「**報告を宣言されたサポート期間内に限定すること**」および「本質的に低リスクの製品を除外すること」を挙げている[^15]。 **【解釈】** この二つの要求は、本レポートの解釈を**裏側から裏付ける**。 | 業界団体の要求 | そこから読める現行法の理解 | |---|---| | インシデントが確認された時点で時計が動き出すようにせよ | **現行法ではそうなっていない**（確認より早く起算されうる） | | 報告をサポート期間内に限定せよ | **現行法では限定されていない**（第69条(3)にサポート期間の限定はない） | **【事実】** この読み取りは、委員会ガイダンスによって明示的に裏付けられる。同ガイダンス9.1節は、脆弱性取扱義務が製品のサポート期間中に限られるのに対し、**報告義務は製品がサポートされなくなった後も適用され続ける**と述べている[^10]。 **【解釈】** ロビイング文書は、解説記事より正直な資料である。自社に有利な解釈を主張する場ではなく、**現行法の不利さを認めたうえで変更を求める場**だからである。業界が「確認された時点で」への変更を求めているということは、現行条文がそう読めないことを業界自身が認めている。 **【解釈】** また、業界の論点は「インシデントとは何か」ではなく「**いつ時計が動き出すか**」に置かれている。これは第8.1節で見た学術文献の関心（「capable of」の境界）とも、本レポートが扱う語感の問題とも異なる、第三の角度である。業界にとって、①の定義そのものは争点ではなく、**その判定にかかる時間**が争点になっている。 **【事実】** なお、Digital Omnibus における単一エントリポイント（SEP）の構想について、EU理事会（欧州連合理事会）事務局が回付した欧州委員会の説明資料は、SEPが「各法令の現行要件に実質的な変更を加えるものではなく、受領当局・その役割・権限にも変更を加えない」ものであると明記している[^16]。 **【解釈】** すなわち、**報告窓口の統一は進むが、定義や閾値の統一は現時点で予定されていない。** 業界が求める「トリガー時点の調和」は、提案には含まれていない。 ### 8.4 実務指針に現れた①の具体例 **【事実】** Open Regulatory Compliance Working Group（ORC WG）は、オープンソースソフトウェア・スチュワードとCRAに関するホワイトペーパーにおいて、スチュワードが報告すべき重大インシデントの例として次を挙げている[^17]。 - バージョン管理システムの不正な改変につながるITインフラへの侵入 - アカウントの乗っ取り - **署名鍵の漏洩** - インフラの長期にわたる利用不能 **【解釈】** 四つの例に共通する性質がある。**いずれも時刻を特定できる事象であり、かつ四要素のいずれかが現に侵害されている。** 「脆弱性が存在する」「悪用されうる状態にある」といった状態の記述は、一つも含まれていない。 **【解釈】** これは本レポート第5章の整理を、実務指針の側から裏付けるものである。実務指針が具体例を列挙するとき、そこに現れるのは事象であって状態ではない。**判定の第一の問い（事象か状態か）は、明文化されていないが、実務では機能している。** **【解釈】** ただし、これは明文化されていないがゆえに、共有されていない読者には伝わらない。ORC WG のホワイトペーパーも、なぜ状態が含まれないのかを説明していない。**暗黙の前提は、共有されている限り機能するが、文書が独り歩きした瞬間に機能を失う。** ### 8.5 評価 **【解釈】** 以上から、次のように整理できる。 | 問い | 答え | |---|---| | 「現実／潜在」の境界問題は英語圏で認識されているか | **認識されている**。学術文献が境界画定の問題として明記している | | その問題は解消されたか | **解消していない**。その後公表された委員会ガイダンスも、第14条(5)にも near miss にも言及していない | | 業界団体は①の判定を論点にしているか | **論点にしている。ただし角度が違う**。定義そのものではなく、起算点（いつ確認とみなすか）を問題にしている | | ISO/IEC 27000 の定義と法令の定義の差は論じられているか | **論じられていない**。学術文献はNISTと比較し、実務文献はガバナンスの差を論じる | | したがって、本レポートの論点は日本語固有か | **固有ではない。ただし現れ方が異なる** | **【解釈】** 同じ①の層をめぐって、三つの立場が別々の角度から問題を立てている。 | 立場 | 何を問題にしているか | |---|---| | 学術 | 「capable of」の境界がどこか（**範囲**の問題） | | 業界団体 | いつ時計が動き出すか（**時間**の問題） | | 日本語話者 | そもそも何がインシデントか（**語感**の問題） | **【解釈】** 三つは排他的ではなく、同じ条文の異なる側面である。しかし**日本語話者の立場だけが、他の二つの前提となる**。何がインシデントかが定まらなければ、範囲も起算点も論じられない。にもかかわらず、この層は英語圏の議論では所与とされている。 **【解釈】** 差異の現れ方は次のように異なる。 - **英語圏**：条文の文言（"capable of"）の解釈問題として現れる。境界がどこかは分からないが、**境界を引くべき問題であることは認識されている** - **日本語圏**：語感の問題として、境界問題以前の段階で現れる。「インシデント」という語が既に「おそれ」を含むため、**境界を引くべき問題であること自体が意識されにくい** **【仮説】** ISO/IEC 27000 の定義と法令の定義の差が、いずれの言語圏でも論じられていないことは、**この論点が空白であることを示唆する**。ISMS認証を取得した組織がNIS2やCRAの報告義務に直面したとき、社内の「情報セキュリティインシデント」の定義（＝侵害の確率が高い事象）と、法令上の incident（＝侵害が生じた事象）が同じ語で呼ばれ、範囲が異なるまま並存する。この状態が実務上どのような帰結を生むかは、まだ検証されていない。 --- ## 9. 日本語訳における訳語の問題 **【解釈】** 第8章までで確認した差異は、日本語で条文を読む際に、さらに一段の問題を生む。EU法が異なる語で書き分けているものが、日本語では同じ語に潰れる箇所があるためである。 ### 9.1 severe と significant は別の次元を指す語である **【事実】** EU法は、報告義務の閾値を示す語として severe（CRA第14条(3)）と significant（NIS2第23条(3)）を使い分けている。両者は同義語ではない。 **【事実】** CRA第3条(38)は、significant を次のように定義する[^1]。 > ‘significant cybersecurity risk’ means a cybersecurity risk which, based on its technical characteristics, can be assumed to have a high likelihood of an incident that could lead to a severe negative impact, including by causing considerable material or non-material loss or disruption; > > （参考訳：「重要なサイバーセキュリティリスク」とは、その技術的特性に基づき、**深刻な負の影響（severe negative impact）**をもたらしうるインシデントの**高い蓋然性（high likelihood）**があると想定されるサイバーセキュリティリスクをいう。当該影響には、相当な物的または非物的な損失もしくは中断を引き起こすことによるものを含む） **【解釈】** すなわち **significant ＝ high likelihood × severe impact** である。**significant の定義の内側に severe が部品として組み込まれている。** 両者は程度の大小の関係になく、次元が異なる。 | 語 | 指すもの | 問い | |---|---|---| | **severe** | 影響（impact）の程度 | どれだけ深刻か | | **significant** | 蓋然性と影響を掛け合わせた水準 | 注目に値するか、無視できるか | **【事実】** CRA本文における両語の使用分布も、この使い分けと一致する。severe は "severe incident" および "severe negative impact" という形で現れ、significant は "significant cybersecurity risk" および "significant risk" という形で現れる[^1]。**severe はインシデントと影響を、significant はリスクを修飾する。** **【事実】** 重要製品の分類にも同じ構造が現れる。CRA前文(43)は、製品の潜在的脆弱性の悪用による負の影響が **severe** となりうる場合に重要製品とすべきとし、その理由として「悪影響の **significant risk** を伴う機能」等を挙げる。これを受けた第7条(2)(b)は、判断要素を「悪影響の significant risk を伴う機能（a function which carries a significant risk of adverse effects）」として条文化しており、**条文本文に severe は現れない**[^1]。 **【解釈】** すなわち、前文では severe（影響の深刻さ）と significant（リスクの水準）が併記され、条文では判定基準として significant のみが採用されている。影響の深刻さは分類の理由として述べられ、実際の判定はリスクの水準で行う——**両語の役割分担が、前文と条文の関係にそのまま表れている。** **【事実】** NIS2側も同様である。第23条(3)は significant incident を次のように定義する[^2]。 > An incident shall be considered to be significant if: (a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned; (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. > > （参考訳：インシデントは、次のいずれかに該当する場合に重要とみなされる。(a) 当該事業体にとって、サービスの**深刻な（severe）**運用中断または財務上の損失を引き起こした、もしくは引き起こしうる場合。(b) **相当な（considerable）**物的または非物的損害を生じさせることにより、他の自然人または法人に影響を与えた、もしくは与えうる場合） **【解釈】** ここでも、significant の判定基準の中に severe が現れる。NIS2第6条(11)の "significant cyber threat" の定義も、「その技術的特性に基づき、相当な物的または非物的損害を生じさせることにより、事業体のネットワーク・情報システムまたは当該事業体の**サービスの**利用者に **severe impact** をもたらす可能性があると想定されるサイバー脅威」という同じ入れ子構造をとる[^2]。 **【解釈】** 語の選択は恣意的ではない。**CRAが severe を用いるのは、製品規制として影響の性質そのものを問うからであり、NIS2が significant を用いるのは、事業体規制としてサービス提供に対する有意性を問うからである。** | | CRA第14条 | NIS2第23条 | |---|---|---| | 用いる語 | severe incident | significant incident | | 判定の視点 | 製品の保護能力への影響、悪意あるコードの導入・実行 | 事業体の運用中断・財務損失、第三者への損害 | | 見ているもの | **製品**に何が起きたか | **サービス提供**にどう響いたか | ### 9.2 日本語ではいずれも「重大」に訳されている **【事実】** 日本語圏の解説において、CRA第14条の severe incident は「重大インシデント」または「重大なインシデント」と訳されている。法律事務所、監査法人系コンサルティング、実務解説のいずれもこの訳を用いる[^19]。 **【事実】** NIS2第23条の significant incident もまた、「重大なインシデント」と訳されている。セキュリティベンダーおよびコンサルティング各社の解説がこの訳を用い、経済産業省サイバーセキュリティ課が2023年に作成した「EU NIS2指令概要」も「重大なインシデントを認識してから72時間以内に」と記述している[^20]。 **【事実】** さらに同資料は、NIS2第23条(3)の判定基準を「重大なインシデントの定義」という見出しのもとに掲げ、その内容を「事業体に**重大な**サービス運営上の混乱や経済的損失を引き起こすもの」「他の自然人又は法人に影響を与えるもの」と記述している[^20]。前者は第23条(3)(a)の "**severe** operational disruption of the services or financial loss" に対応する。 **【解釈】** すなわち、**同一の資料の同一の箇所において、significant incident が「重大なインシデント」と訳され、その定義中の severe operational disruption が「重大なサービス運営上の混乱」と訳されている。** 原文では入れ子の外側と内側で異なる語が用いられているが、訳文では区別されない。 **【解釈】** これは、本節が指摘する潰れが抽象的な可能性ではなく、**公的機関の資料において現に生じている**ことを示す実例である。なお同資料の(b)に対応する記述は「他の自然人又は法人に影響を与えるもの」であり、原文の "considerable material or non-material damage"（相当な物的または非物的損害）に含まれる程度の限定も現れていない。 **【解釈】** すなわち、**英語では異なる次元で書き分けられている二つの閾値が、日本語では同一の語に潰れている。** これは誤訳ではない。severe も significant も、日本語では自然に「重大」と訳される。資料の性格（概要説明のスライド）を踏まえれば、この訳し方は不合理ではない。 **【解釈】** 問題は三つある。 **第一に、判定基準が異なることが見えなくなる。** 同一の事業者がEU域内で製品を上市し、かつ事業体として重要インフラに関わる場合、CRA第14条とNIS2第23条の双方に服する。社内文書で「重大なインシデント」と記載されていても、どちらの閾値を指すのか判別できない。報告先も、期限の起算点も、判定基準も異なる。 **第二に、CRA第3条(38)の入れ子構造が同語反復に見える。** 「significant cybersecurity risk」を「重大なサイバーセキュリティリスク」と訳すと、その定義中の "severe negative impact"（深刻な負の影響）と区別がつかず、「重大なリスクとは重大な影響をもたらす高い蓋然性のあるリスク」という循環した文になる。原文は蓋然性と影響という**二つの次元を掛け合わせている**が、訳文ではそれが失われる。 **第三に、これは本レポートが扱う問題と同じ型である。** 日本語の「重大」は、程度を示す語と閾値を示す語を区別しない。「インシデント」が事象と状態を区別しないのと、同じ構造の問題である。**EU法が二次元で設計しているものを、日本語が一次元に潰す。** ### 9.3 三層構造は訳文で圧縮される **【事実】** 日本語の解説は、CRA第14条(3)の報告対象を「製品のセキュリティに影響を及ぼす重大なインシデント」と一括して訳す[^19]。 **【解釈】** この訳は正確である。しかし第2.1節で確認した三層——第3条(43)の incident、第3条(44)の②、第14条(5)の severe——が、一つの日本語句に圧縮される。**判定に必要な層が、訳文の表面から見えなくなる。** **【解釈】** 原文でも入口は参照の先にあり、読み手が③から読み始めやすい構造であった。日本語ではその傾向がさらに強まる。 ### 9.4 near miss と日本語の「ニアミス」 **【事実】** CRA第15条(2)およびNIS2の near miss について、日本語の解説はほとんど言及していない。任意報告であることが理由と推定される。 **【事実】** 日本語の「ニアミス」は、安全管理分野において「ヒヤリ・ハット」とほぼ同義として定着している。日本医療安全学会の用語集は、ニアミスを「インシデントのうち、患者に実施される前に気づいて、患者には実施されなかったもの」と定義したうえで、**日本のヒヤリ・ハットはニアミスと無害インシデント（no harm incident）の双方を含む**と明記している[^21]。 **【解釈】** したがって、NIS2第6条(5)の near miss を日本語の「ニアミス」で受けると、第4.1節で示した中央の帯——侵害あり・害なし——が、再びヒヤリ・ハット側に引き寄せられる。**訳語がずれを再生産する。** **【解釈】** EU法の near miss は「侵害が生じなかった事象」であり、日本語のヒヤリ・ハットは「害が生じなかった事象」である。侵害と害は同じではない。 ### 9.5 権威的な訳が存在しない **【事実】** 本調査の範囲では、CRAおよびNIS2について、日本の公的機関による日本語全訳を確認できなかった。訳語は、法律事務所・コンサルティング会社・セキュリティベンダーの解説記事を通じて事実上定着している。 **【解釈】** 権威的な訳が存在しない状態では、訳語の統一を図る主体がいない。各社が独立に「重大」を選んだ結果として衝突が生じており、**誰も誤っていないのに全体として区別が失われる**という構造になっている。 **【事実】** 本レポートが内容を確認したCRAの解説記事3件は、いずれも「重大インシデント」または「重大なインシデント」と訳し、**原語（severe）を併記していない**[^19]。同一記事内で「重大インシデント」と「重大なインシデント」の表記が混在する例もあるが、いずれも「重大」を用いる点は共通する。 **【解釈】** したがって読者は、その「重大」がCRAの severe を指すのか、NIS2の significant を指すのかを、記事の文脈から推測するほかない。CRAのみを扱う記事では文脈で判別できるが、**社内文書に転記された時点で文脈は失われる。** **【解釈】** 実務上は、日本語で条文を扱う際に**原語を併記する**ほかない。「重大インシデント（severe incident、CRA第14条）」「重大なインシデント（significant incident、NIS2第23条）」のように、どの法令のどの語かを明示する。第11.1節で述べる「語を保持したまま体系を確認する」という原則の、具体的な適用形である。 --- ## 10. 日本法との比較 **【事実】** 重要電子計算機に対する不正な行為による被害の防止に関する法律（令和7年法律第42号。いわゆるサイバー対処能力強化法）は「インシデント」の語を用いず、次の三つの範疇を用いる[^11]。 | 語 | 条 | 位置づけ | 性質 | |---|---|---|---| | 特定不正行為 | 第2条第4項 | 定義規定 | **行為**（刑法第168条の2第2項、不正アクセス禁止法第2条第4項、刑法第2編第35章の三類型） | | 特定侵害事象 | 第2条第5項 | 定義規定 | **結果**（重要電子計算機に対する特定不正行為により、サイバーセキュリティが害されること） | | 特定侵害事象の原因となり得る事象 | 第5条 | 報告対象の範囲（主務省令に委任） | **前兆** | **【事実】** このうち第2条が定義規定として置いているのは前二者であり、「特定侵害事象の原因となり得る事象」は第5条が報告対象として主務省令に委任した範囲であって、法律上の定義規定ではない。 **【解釈】** 特定侵害事象は「サイバーセキュリティが害されること」であり、害の発生を要件とする。この点で、四要素の侵害を要件とするEU法の incident と同じ方向を向いている。ただし「害される」と「四要素の侵害」は同一ではなく、後者のほうが早い段階で成立しうる。 **【事実】** 同法は「コンピュータ」に相当する概念を一貫して「電子計算機」と表記する。一方で、第2条第1項は「サイバーセキュリティ」というカタカナ語を、サイバーセキュリティ基本法第2条を引く形で定義規定に置いている。すなわち**カタカナ語を一律に避けているわけではない**[^11]。 **【解釈】** したがって、用語選択の理由を「日本の法令がカタカナを避ける作法」に求めることはできない。**報告義務の外縁を確定するには、実務で多義的な「インシデント」を使えないという要請**に、論拠は一本化される。実際、同法は「特定不正行為」の内実についても、刑法第168条の2第2項や不正アクセス禁止法第2条第4項を条番号で参照する方式をとっており、既存の法概念に接続することで外縁を確定している。 **【解釈】** 両者に共通するのは、**報告義務の外縁を確定するために、多義的な「インシデント」の語の扱いに手当てをした**点である。日本法はこれを三分割し、EU法は語を保持したまま定義で絞った。手法は異なるが、動機は同じと読める。 **【解釈】** ただし、日本法が「特定侵害事象」という新語を作ったのに対し、EU法は "incident" という日常語をそのまま定義した。本レポートが扱っている問題は、この差から生じている。 **【仮説】** より一般化すれば、**日常語を定義で絞る立法手法は、読み手が定義を確認しない限り日常的語感で読まれるという構造的弱点を持つ**と考えられる。ただし本レポートが検証したのはCRAという一例のみであり、立法手法一般についての主張として確立したものではない。 --- ## 11. 実務への含意 ### 11.1 語を避けるのではなく、前提を持つ **【解釈】** 判定基準の文面から「インシデント」の語を外す対処は、有効でない。理由は三つある。 1. 参照先の条文には "incident" の語が残るため、社内文書と条文の間に対応関係のない語彙が挟まる 2. CSIRT・ENISAとのやり取り、他法令との整合、監査対応はすべて "incident" の語で行われる 3. 語を変えることは不通約性を解消せず、見えなくするだけである **【解釈】** 採るべきは、**語を保持したうえで「日本語のインシデントとEU法の incident は似て非なるものである」という前提を持つ**ことである。同じ語を使い続ける限り、「この文書の incident は条文のどれを指しているか」という問いが常に立てられる。語を変えれば、その問いは立てられなくなる。 **【解釈】** これは翻訳者の作法である。拡声器は語をそのまま伝えるが、翻訳者は「どちらの体系の語か」を問う。 ### 11.2 判定の順序を条文の構造に合わせる **【解釈】** 判定基準は、第14条(5)から書き始めてはならない。次の順序を固定する。 | 順序 | 問い | 分岐 | |---|---|---| | 第一 | 事象が起きたか。元々そういう状態だったか | 状態なら脆弱性ルート（第14条(1)）へ | | 第二 | 四要素のいずれかが**現に**侵害されたか | 侵害なしと確認できれば near miss（第15条(2)） | | 第三 | 製品の保護能力に悪影響があるか（第3条(44)） | なければ対象外 | | 第四 | 第14条(5)(a)(b)のいずれかに該当するか | 該当すれば義務的報告 | **【解釈】** 第二の問いにおいて、**「侵害されていないと確認できた」と「どちらとも言えない」を区別する**。理由の不在と、否定の根拠は違う。24時間の時点で痕跡の検証が終わっていないことは普通にあり、そのとき「侵害されていないと判断する理由がない」のは、単に判断材料がないからである。 | 状態 | 判断 | |---|---| | 侵害されたと判断できる理由がある | 報告 | | 侵害されていないと確認できた | 報告不要（記録は残す） | | **どちらも言えない** | **報告** | **【解釈】** 三行目を報告側に置くか否かで、運用の性格が決まる。制裁の非対称（第4.2節）を踏まえれば、報告側に置くのが合理的である。 ### 11.3 起算点は「認識」であり、①の成立ではない **【事実】** 第14条(3)の義務は「認識した場合（becoming aware）」に生じる。①の事実が発生した時点でも、それを検知した時点でもない。 **【事実】** 委員会ガイダンスは、疑わしい事象を「直ちに（immediately）」評価すべきものとし、「初期評価を実施する速やかな行動（prompt action to carry out the initial assessment）」に力点を置くべきだとしている[^10]。 **【解釈】** したがって、封じ込めを優先することは条文と矛盾しない。ただし、**封じ込め完了まで初期評価を先送りしてよいとは書かれていない。** むしろガイダンスの「直ちに」は、本レポートが述べる水準より強い。 **【解釈】** 実務的な帰結は、インシデント対応（封じ込め・隔離・痕跡保全）と製品セキュリティ評価（この侵害は製品にどう及ぶか）を**並行させる体制**が要る、ということである。同じチームが順番に処理すると24時間に間に合わない。 ### 11.4 二重該当を見落とさない **【事実】** 同一の事象が第14条(1)（脆弱性ルート）と第14条(3)（インシデントルート）の双方に該当することがある。最終報告の期限は両ルートで異なる[^1]。 | ルート | 最終報告の期限 | |---|---| | 脆弱性（第14条(2)(c)） | 是正・緩和措置が利用可能となってから14日 | | インシデント（第14条(4)(c)） | 72時間通知の提出から1か月 | **【解釈】** 24時間・72時間は共通のため、初動では差が出ない。**ずれが顕在化するのは最終報告の段階**であり、気づくのが遅い箇所である。両ルートを立てて報告する運用が安全側である。 ### 11.5 記録を残す **【解釈】** 本レポートが扱った差異は、最終的には解釈の問題である。委員会ガイダンスは非拘束であり、EU司法裁判所の判断もない。**判断の正しさを事後に立証する唯一の手段は、判断過程の記録である。** 受領時刻・評価開始時刻・判定時刻と、判定の根拠を残す。 --- ## 12. 事実・解釈・仮説の整理 | 区分 | 内容 | |---|---| | 事実 | NIS2第6条(6)の incident は `an event compromising...` であり、侵害の発生を要件とする | | 事実 | NIS2第6条(5)の near miss は `could have compromised ... but ... did not materialise` であり、侵害の不発生を要件とする | | 事実 | CRA第15条(2)は、near miss を任意報告の対象としている | | 事実 | CRA第14条の判定において、可能性を示す文言は第3条(44)と第14条(5)にのみ存在し、第3条(43)が参照するNIS2第6条(6)には存在しない | | 事実 | 第3条(44)と第14条(5)(b)は「機微または重要な」という限定を置いていないが、第14条(5)(a)は置いている | | 事実 | JIS Q 27000:2019の「情報セキュリティインシデント」は「侵害する確率が高いもの」と定義され、侵害の発生を要件としない | | 事実 | 厚生労働省医療安全対策検討会議（2002年）は、インシデントを患者に影響を及ぼすに至らなかった事例と定義している | | 事実 | ICAO Annex 13はincidentを「accident以外の事象」と定義し、両者の違いは結果のみにあるとする | | 事実 | ISO 45001ではincidentが上位概念であり、accidentはその部分集合である | | 事実 | JPCERT/CCおよびNIST SP 800-61r3のincident定義は、害の発生を要件としていない | | 事実 | CRA第3条(40)のvulnerabilityは製品の属性であり、incident／near missの系列とは別に定義されている | | 事実 | CRA第17条(4)により通知自体で責任は加重されず、第14条違反は第64条の最上位区分に置かれている | | 事実 | NIS2第6条(6)の incident それ自体は報告義務の対象ではなく、NIS2第30条により任意報告にとどまる | | 事実 | CER指令第2条(3)の incident 定義は、侵害対象が異なるうえ、可能性を示す文言（has the potential to）を定義そのものに含む | | 事実 | ISO/IEC 27000とNIS2は、compromise という同じ動詞を用いるが、確率修飾の有無に加えて目的語も異なる（事業運営・情報セキュリティ／データ等の四要素） | | 事実 | ISO 45001が規格本文で定義しているのはincidentのみで、accidentとnear-missは注記で「呼ばれることがある」と述べられるにとどまる | | 事実 | CRA第64条(10)(a)は、零細企業・小企業について24時間の早期警告に係る制裁金を免除している。同項柱書は官報初出時に第2項を除外対象から落としており、2025年7月2日付の正誤表で訂正された | | 事実 | サイバー対処能力強化法第2条第1項は「サイバーセキュリティ」というカタカナ語を定義規定に置いており、同法はカタカナ語を一律に避けていない | | 事実 | 同法第2条の定義規定は「特定不正行為」「特定侵害事象」の二つであり、「特定侵害事象の原因となり得る事象」は第5条が主務省令に委任した報告対象の範囲である | | 事実 | CRA第3条(38)は significant を「severe negative impact をもたらしうるインシデントの high likelihood があるリスク」と定義しており、significant の定義の内側に severe が組み込まれている | | 事実 | NIS2第23条(3)の significant incident の判定基準にも severe（severe operational disruption）が現れる | | 事実 | CRA本文で severe は incident と impact を、significant は risk を修飾する用法に分かれている | | 事実 | 重要製品の分類において、前文(43)は severe と significant risk を併記するが、第7条(2)(b)は significant risk のみを条文化しており、条文本文に severe は現れない | | 事実 | 日本語圏では、CRAの severe incident もNIS2の significant incident も「重大（な）インシデント」と訳されている。経済産業省の資料もNIS2について同じ訳を用いている | | 事実 | 同資料は、significant incident を「重大なインシデント」と訳すと同時に、その定義中の severe operational disruption を「重大なサービス運営上の混乱」と訳している | | 解釈 | 訳語の潰れは抽象的な可能性ではなく、公的機関の資料において現に生じている | | 事実 | 本調査の範囲では、CRAおよびNIS2の日本の公的機関による日本語全訳を確認できなかった | | 事実 | 内容を確認したCRA解説記事3件は、いずれも「重大（な）インシデント」と訳し、原語 severe を併記していない | | 解釈 | severe は影響の程度を、significant は蓋然性と影響を掛け合わせた水準を指す。両者は次元が異なる | | 解釈 | 語の選択は規制対象の違いを反映している。CRAは製品への影響の性質を、NIS2はサービス提供への有意性を問う | | 解釈 | 日本語の「重大」は程度の語と閾値の語を区別しない。「インシデント」が事象と状態を区別しないのと同じ型の問題である | | 解釈 | 日本語の「ニアミス」はヒヤリ・ハットとほぼ同義であり、EU法の near miss を受けると本レポートが指摘するずれを再生産する | | 解釈 | 権威的な訳が存在しないため、各社が独立に「重大」を選んだ結果として、誰も誤っていないのに全体として区別が失われている | | 事実 | 委員会ガイダンス附属書の全文に `near miss`、`Article 14(5)`、`sensitive or important` はいずれも出現しない | | 事実 | 同ガイダンスは、報告義務が製品のサポート期間終了後も適用され続けると明記している | | 事実 | 同ガイダンスは、疑わしい事象を直ちに評価すべきものとし、初期評価を実施する速やかな行動に力点を置くとしている | | 事実 | 同ガイダンスは「認識」の解釈をNIS2実施規則前文31およびGDPRガイドライン9/2022と整合させた旨を明記している | | 事実 | 同ガイダンスは、第三者コンポーネント由来の脆弱性が自社製品で悪用されえない場合（脆弱なコードが到達可能でない場合を例示）、義務的報告の対象とならないとしている | | 事実 | 英語圏の学術文献は、CRA第14条(5)およびNIS2第23条(3)の「capable of」について境界画定の問題を指摘している。うちNIS2第23条(3)についてはガイダンスが存在しないと明記し、CRA第14条(5)については解釈の帰趨を今後に委ねている | | 事実 | 同文献はNIS2の incident 定義をNISTの定義と比較しており、ISO/IEC 27000の定義との差は論じていない | | 事実 | DIGITALEUROPEは、インシデントが確認された時点で報告期限が起算されるようトリガー時点の調和を求めている | | 事実 | 同団体は、CRAの報告義務を宣言されたサポート期間内に限定することも求めている | | 事実 | Digital Omnibusの単一エントリポイント構想は、各法令の現行要件に実質的変更を加えないとされている | | 事実 | ORC WGのホワイトペーパーは、報告対象の重大インシデントの例として、ITインフラへの侵入、アカウント乗っ取り、署名鍵の漏洩、インフラの長期利用不能を挙げている | | 解釈 | EU法は法令ごとにincidentの定義が異なり、可能性を含むものと含まないものがある。NIS2の厳格さはEU法全体の特徴ではなくNIS2固有の設計である | | 解釈 | 委員会ガイダンスは「いつ認識したことになるか」という時点の問いに答えたが、「何が重大インシデントに当たるか」という範囲の問いには答えていない | | 解釈 | EU法において incident は報告義務の単位ではなく、義務を画定するための基礎概念である | | 解釈 | 「EU法における incident」という単一の概念は存在しない。どの法令のどの条文かを特定しなければ範囲は定まらない | | 解釈 | 「現実／潜在」の境界問題は英語圏でも認識されているが、ISO/IEC 27000との定義の差は英語圏でも論じられていない | | 解釈 | 差異の現れ方が異なる。英語圏では条文解釈の問題として、日本語圏では語感の問題として、境界問題以前の段階で現れる | | 解釈 | 業界団体が「確認された時点で」への変更を求めていることは、現行条文がそう読めないことを業界が認めていることを意味する | | 解釈 | 実務指針が挙げる具体例はすべて事象であり、状態は含まれない。判定の第一の問いは明文化されていないが実務では機能している | | 解釈 | 学術は範囲の問題、業界団体は時間の問題、日本語話者は語感の問題として、同じ①の層に別々の角度から到達している | | 解釈 | 語感の問題は他の二つの前提となるが、英語圏の議論では所与とされている | | 解釈 | 安全工学の内部でも用語法は一枚岩ではないが、いずれも「おそれ」を incident の内包に含める点は共通する | | 解釈 | 日本語話者が「インシデント」に「おそれ」を含めるのは、複数の体系がそれぞれ独立にその方向の定義を与えているためである | | 解釈 | サイバー分野のincidentが広いのは、害の有無が事後にしか判定できないという認識論的制約による | | 解釈 | EU法のincidentは、日本の実務感覚でいうアクシデントより広く、インシデントより狭い。両者は包含関係になく部分的に重なる | | 解釈 | 食い違う領域（侵害あり・害なし）が、サイバーセキュリティ事案の大半を占める | | 解釈 | 日本語の語感は、過大・過小の両方向の誤りを生じさせる。制裁の非対称により、過小のほうが危険である | | 解釈 | 「事象が起きたか、元々そういう状態だったか」が判定の第一の問いである | | 解釈 | EU法には「事象は起きたが侵害の有無が未確定」の状態を指す語がない。実務が立つのは常にその場所である | | 解釈 | 判定基準から「インシデント」の語を外す対処は、不通約性を隠すだけで解消しない | | 仮説 | ISMS認証を取得した組織では、社内の「情報セキュリティインシデント」の定義と法令上の incident が同じ語で呼ばれたまま範囲を異にして並存する。この状態の実務上の帰結は未検証である | | 仮説 | 日常語を定義で絞る立法手法は、読み手が定義を確認しない限り日常的語感で読まれるという構造的弱点を持つ | --- ## 13. 残された論点 - ISO/IEC 27035（情報セキュリティインシデント管理）の定義とJIS Q 27000の関係。同一体系内での整合 - ITIL（ITサービス管理）における incident 定義との関係。サービス中断を基準とする別系統 - CRA第3条(38)の significant cybersecurity risk が、日本語圏でどう訳されているか。第9.2節で指摘した循環が実際に生じているか - 他のEU法（DORA の major incident、GDPR の personal data breach 等）の閾値語が、日本語でどう訳し分けられているか - 「情報セキュリティ事象（event）」と「情報セキュリティインシデント」の二段構えが、実務でどの程度運用されているか。多くの組織で事象とインシデントが区別されずに扱われている可能性 - **ISMS認証を取得した組織において、社内の「情報セキュリティインシデント」の定義と法令上の incident の範囲の差が、実務上どのような帰結を生んでいるか。** 第8.5節で述べたとおり、この論点は英語圏でも論じられておらず、空白のままである。実証的な調査（アンケート・インタビュー）の対象となりうる - CER指令第2条(3)の incident 定義とNIS2第6条(6)の差の具体的内容。両者がどう異なり、なぜ異なるのか - near miss を「誤検知（false positive）」と読むか「阻止された攻撃」と読むかで、第15条(2)の任意報告の対象範囲が変わる。この点についての当局の見解 - 原子力（IAEA国際原子力事象評価尺度）、鉄道・海事（運輸安全委員会）における用語法。本レポートでは未確認 - Digital Omnibusの立法過程で、トリガー時点の調和が最終的に採用されるか。採用されれば①の判定にかかる実務負担は大きく変わる - CRA第14条(8)の利用者通知の運用から、各社の判定閾値を間接的に観測できるか - 本レポートが扱った差異が、2026年9月11日以降の実際の事案でどう現れるか。とくにCOTS部品への依存が深く製品寿命の長いOT／産業機器の分野では、判定の負担が大きくなることが予想される --- ## 脚注 [^1]: Regulation (EU) 2024/2847（サイバーレジリエンス法）官報版。第3条(40)(41)(42)(43)(44)、第14条、第15条、第17条(4)、第64条、第69条(3)、第71条(2)および前文68を参照。 https://eur-lex.europa.eu/eli/reg/2024/2847/oj （2026-08-27 参照）。**なお、CRAは官報掲載後に複数の正誤表が公表されており、条文を参照する際は注意を要する。** **英語版に影響するものとして確認できたものは次のとおり。** (1) 32024R2847R(01)（OJ L, 2024/90780、2024-12-05、英語版のみ）、(2) 32024R2847R(02)（OJ L, 2025/90555、2025-07-02、全言語版） https://eur-lex.europa.eu/eli/reg/2024/2847/corrigendum/2025-07-02/oj 、(3) 32024R2847R(04)（OJ L, 2025/90828、2025-10-17、全言語版） https://eur-lex.europa.eu/eli/reg/2024/2847/corrigendum/2025-10-17/oj （いずれも 2026-08-27 参照）。訂正内容はそれぞれ次のとおりで、いずれも原典により確認した。(1)は表題における「Regulations (EU) No 168/2013 and (EU) **No** 2019/1020」から "No" を削除する訂正。(2)は第64条(10)柱書の「第3項から第9項」を「第2項から第9項」に改める訂正。(3)は第67条（Directive (EU) 2020/1828 の附属書Iに追加する項目）の項目番号を「69」から「72」に改める訂正。このほか、特定の言語版のみを対象とする正誤表として 32024R2847R(05)（OJ L, 2026/90148、2026-02-23、スロバキア語版のみ）がある。また R(03) は本調査では特定できなかった。**以上より、本レポートが参照した英語版の条文（第3条・第14条・第15条・第17条・第69条・第71条および前文43・68）に及ぶ訂正は存在しない。** 英語版で影響があるのは第64条(10)のみである。また、CRAは2025年2月11日の欧州健康データスペース規則（EU）2025/327（官報掲載 2025-03-05）により改正されている [^2]: Directive (EU) 2022/2555（NIS2指令）第6条(5)(6)。CRA第3条(43)が参照するインシデントの定義。 https://eur-lex.europa.eu/eli/dir/2022/2555/oj （2026-08-26 参照） [^3]: ICAO Annex 13（国際民間航空条約第13附属書）における定義。オーストラリア運輸安全局（ATSB）による用語解説 https://www.atsb.gov.au/avdata/terminology （2026-08-26 参照）。およびマルタ航空事故調査局（BAAI）掲載の定義 https://baai.gov.mt/important-definitions-taken-from-icao-annex-13/ （2026-08-26 参照） [^4]: ISO 45001:2018「労働安全衛生マネジメントシステム－要求事項及び利用の手引」3.35（incident）およびその注記1・注記2。規格本文は有償のため、文言は複数の独立した引用元の一致により確認した。規格の書誌情報は https://www.iso.org/standard/63787.html 、関連解説として欧州労働安全衛生機関（EU-OSHA）OSHwiki "Accidents and incidents" https://oshwiki.osha.europa.eu/en/themes/accidents-and-incidents （2026-08-27 参照） [^5]: 厚生労働省医療安全対策検討会議（2002年）によるアクシデント・インシデントの定義。厚生労働省「医療安全対策について」 https://www.mhlw.go.jp/topics/2001/0110/tp1030-1y.html （2026-08-26 参照）。関連資料として厚生労働省医療安全対策検討会議資料 https://www.mhlw.go.jp/shingi/2005/03/dl/s0324-15d2.pdf （2026-08-26 参照） [^6]: JIS Q 27000:2019「情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－用語」3.31（情報セキュリティインシデント）および3.30（情報セキュリティ事象）。規格本体は日本規格協会より入手。 https://webdesk.jsa.or.jp/books/W11M0090/index/?bunsyo_id=JIS+Q+27000%3A2019 （2026-08-26 参照） [^7]: ISO/IEC 27000:2018（第5版、情報セキュリティマネジメントシステム－概要及び用語）における information security incident の定義。JIS Q 27000:2019 の序文は、本規格を基とし箇条3の用語及び定義については技術的内容及び構成を変更することなく作成した旨を明記している。 https://www.iso.org/standard/73906.html （2026-08-27 参照） [^8]: JPCERT/CC「インシデントとは」 https://www.jpcert.or.jp/aboutincident.html （2026-08-26 参照） [^9]: NIST SP 800-61 Revision 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile", April 2025. 同文書の cybersecurity incident 定義には出典として [FISMA2014]（2014年連邦情報セキュリティ近代化法）が付されている。 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf （2026-08-26 参照） [^10]: European Commission「Commission publishes new guidance to support timely Cyber Resilience Act implementation」（2026-07-27公表）。C(2026) 5252 通達および附属ガイダンス。 https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation （2026-08-26 参照）。あわせて欧州委員会「Cyber Resilience Act - Reporting obligations」 https://digital-strategy.ec.europa.eu/en/policies/cra-reporting （2026-08-26 参照）。本レポートにおける「認識」の基準（初期評価を経た合理的な程度の確実性）は同ガイダンス附属書9.1節パラ213、初期評価の速やかさはパラ214、サポート期間終了後の報告義務の継続はパラ210、他法令との整合はパラ212、非拘束性はパラ8による。語句の出現状況の走査は、図表を除く本文257段落を対象とした。 [^11]: 重要電子計算機に対する不正な行為による被害の防止に関する法律（令和7年法律第42号）第2条、第5条。 e-Gov法令検索 https://laws.e-gov.go.jp/law/507AC0000000042/ （2026-08-26 参照） [^12]: 欧州委員会「FAQs on the Cyber Resilience Act」第5章「Reporting obligations of manufacturers」。ゼロデイの扱い（5.2）、上市済み製品への適用（5.3）、統合コンポーネント由来の脆弱性（5.4）。非拘束。原典PDF https://ec.europa.eu/newsroom/dae/redirection/document/122331 、HTML版 https://cra.orcwg.org/faq/official/reporting/ （2026-08-26 参照） [^13]: Jukka Ruohonen, Kalle Rindell, Simone Busetti, "From Cyber Security Incident Management to Cyber Security Crisis Management in the European Union", Computers & Security, 2025, vol. 159, p. 104689. EU法における incident 類型の整理、CRA第14条(5)およびNIS2第23条(3)の「capable of」に関する境界画定の問題、near miss の解釈、CER指令との定義の不一致を扱う。 https://doi.org/10.1016/j.cose.2025.104689 、著者版 https://arxiv.org/abs/2504.14220 （2026-08-26 参照） [^14]: Directive (EU) 2022/2557（重要事業体レジリエンス指令、CER指令）第2条(3)。 https://eur-lex.europa.eu/eli/dir/2022/2557/oj （2026-08-26 参照） [^15]: DIGITALEUROPE「Digital omnibus: a first step and what must come next, now」。インシデント報告のトリガー時点の調和、報告のサポート期間内への限定、単一エントリポイントの範囲についての要求。 https://www.digitaleurope.org/resources/digital-omnibus-a-first-step-and-what-must-come-next-now/ （2026-08-26 参照） [^16]: EU理事会（欧州連合理事会）事務局が回付した欧州委員会の説明資料「Omnibus VII: Digital Omnibus – Presentation by the Commission」（WK 16586/2025 REV 1、2025-12-02）。単一エントリポイント（SEP）が各法令の現行要件に実質的変更を加えない旨の記載。 https://data.consilium.europa.eu/doc/document/WK-16586-2025-REV-1/en/pdf （2026-08-26 参照）。後続文書として WK 2399/2026 INIT（2026-02-13） https://data.consilium.europa.eu/doc/document/WK-2399-2026-INIT/en/pdf （2026-08-26 参照） [^17]: Open Regulatory Compliance Working Group「Open Source Software Stewards and CRA Whitepaper V1.0」（2026年1月）。スチュワードが報告すべき重大インシデントの例示。 https://orcwg.org/files/cra/resources/white-paper-on-open-source-software-stewards-and-cra.pdf （2026-08-26 参照） [^18]: ENISA「Single Reporting Platform (SRP)」。CRA第14条に基づく報告に用いる技術基盤。義務的報告と任意報告の双方に対応。 https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp （2026-08-26 参照） [^19]: CRA第14条の severe incident に関する日本語解説の例。いずれも2026-08-27に内容を確認した。(1) Jones Day「EUサイバーレジリエンス法：24時間以内の報告義務が2026年9月11日より適用開始」 https://www.jonesday.com/ja/insights/2026/07/eu-cyber-resilience-act-24hour-reporting-duties-start-september-11-2026 、(2) TMI総合法律事務所「EUサイバーレジリエンス法（CRA）の全体像と日本企業がとるべき対応」 https://www.tmi.gr.jp/service/global/europe/2025/17691.html （「製造業者が脆弱性又は重大なインシデントを認識してから遅滞なく、いかなる場合でも24時間以内に」等）、(3) PwC Japanグループ「欧州サイバーレジリエンス法（EU CRA）―製造業が今取るべき対策―」 https://www.pwc.com/jp/ja/knowledge/column/awareness-cyber-security/eu-cyber-resilience-act05.html （「積極的に悪用された脆弱性や重大インシデントを把握する上での経路」等）。3件とも原語 severe を併記していない。 [^20]: NIS2第23条の significant incident に関する日本語表記の例。経済産業省商務情報政策局サイバーセキュリティ課「EU NIS2指令概要 ※NIS2指令：改正ネットワーク及び情報システム指令」（2023年5月）。資料本体を2026-08-27に確認した。「重大なインシデントの定義」および「報告の流れ」のスライドを参照。**出典については次の点に留意を要する。** 同日時点で経済産業省サイトにおいて当該資料の所在を確認できず、本レポートが参照したのは第三者サイトに置かれた写しである。 https://www.jsima.or.jp/national/EU_NIS2%E6%8C%87%E4%BB%A4%E6%A6%82%E8%A6%81.pdf （2026-08-27 参照）ほかにセキュリティベンダー各社の解説が同じ訳を用いている。 [^21]: 一般社団法人日本医療安全学会「用語集：ニアミス」。WHOによる分類および日本の「ヒヤリ・ハット」との関係についての記述を含む。 https://www.jpscs.org/?p=1766 （2026-08-27 参照）