CRA脆弱性報告：タイ製造業の24時間対応とSRP実務

2026年9月11日、EU Cyber Resilience Act（CRA）の報告義務が適用開始となりました。タイで産業機械、IoT機器、組込みソフトウェアを開発しEU市場へ供給する企業には、CRA 脆弱性報告を24時間・72時間・最終報告へつなぐ実務が必要です。本稿は、適用範囲の一次判定からPSIRT、製品SBOM、ENISA Single Reporting Platform（SRP）、RFP、90日導入、受入試験までを一つの運用として整理します。

重要：本稿は2026年9月20日時点の公式情報に基づく実務整理であり、法的助言ではありません。CRAの適用可否、経済事業者としての役割、報告要否、提出先は、製品・契約・EUでの販売形態ごとに法務、適合性評価、サイバーセキュリティの専門家と確認してください。

CRA 脆弱性報告が「設計文書」だけでは終わらない理由

CRA対応というと、セキュア開発、技術文書、CEマーキング、適合性評価が先に思い浮かびます。しかし、2026年9月11日から先行して適用された報告義務は、実際のイベントを起点に時刻が進む運用です。製品セキュリティ担当者が「信頼できる悪用証拠」を認識した時点、または製品のセキュリティに重大な影響を持つインシデントを認識した時点から、遅滞なく、かつ最長24時間以内に早期警告が必要になります。

これは、一般的な製品セキュリティ要求の証拠を説明したETSI EN 303 645の記事とは焦点が異なります。また、操業継続と現場初動を中心にしたOTサイバーインシデント対応訓練の記事とも別の仕事です。本稿が扱うのは、EU市場に製品を供給するメーカーとして、製品イベントを法定報告へ変換する業務設計です。

工場のSOCやCSIRTが設備停止を処理できても、次の問いにすぐ答えられなければ製品報告は進みません。

• 影響を受けるのは自社工場の資産か、顧客へ出荷した製品か
• 対象型式、ファームウェア、ソフトウェア部品、販売国、ユーザーはどこまでか
• 単なる脆弱性か、「actively exploited vulnerability（積極的に悪用されている脆弱性）」か
• インシデントはCRA Article 14の「severe incident」に当たる可能性があるか
• どの法人がmanufacturerで、誰が社内判断を行い、誰がSRPへ提出するか
• どのCSIRT designated as coordinator（CDaC）を選ぶか
• 24時間で確定していない情報を、何を未確定として報告するか

したがって、CRA 24時間報告は「フォームを埋める作業」ではありません。製品台帳、製品SBOM、脆弱性監視、顧客・販売国台帳、PSIRTの判断、法務確認、経営エスカレーション、SRP提出を、一つの時計で動かす業務です。

2026年9月11日以降の法定タイムライン

EU規則2024/2847 Article 14とENISAのSRP FAQは、メーカーが認識してからの期限を次のように示しています。「within」は上限であり、いずれも「without undue delay（不当に遅れることなく）」が前提です。

法定の起算点は「CVEが公表された日」や「パッチが完成した日」ではなく、メーカーがAEVまたはSIを認識した時点です。一方、実務では見落としを防ぐため、最初の兆候や候補を受けた時点から社内時計を開始し、調査とエスカレーションを進めます。この社内時計は法定起算点を置き換えるものではありません。チケットには、最初の兆候を受けた時刻、信頼できる証拠を確認した時刻、AEVまたはSIを認識したと判断した時刻、経営・法務への通知時刻、SRP提出時刻を別々に残します。後から時計を一つの日時に丸めると、判断経緯を説明できません。

24時間報告で完成版を待たない

24時間の早期警告は、根本原因分析や完全な影響範囲が確定するまで待つ段階ではありません。ENISAのFAQでは、段階によって必須になる項目が異なり、24時間時点では不要でも72時間通知や最終報告で必要になる情報があると説明されています。実務では、確定事項、合理的な初期評価、未確定事項、次回更新予定を分けます。

ただし、「不明」と書けば準備不足が解消されるわけではありません。製品識別子、販売国、連絡責任者、認識時刻、初期の影響仮説は、平時から取得可能にしておくべきです。24時間のうち最初の18時間を台帳探しに使う設計では、承認や入力確認の時間が残りません。

AEVとSIを混同しない

CRA上のAEVは、悪意ある主体がシステム所有者の許可なく悪用したという信頼できる証拠がある脆弱性です。「悪用できそう」「PoCが公開された」「スキャナーが検出した」だけで直ちに同じ意味になるとは限りません。一方、SIは製品がデータまたは機能の可用性、真正性、完全性、機密性を守る能力に重大な影響を与えるか、悪性コードの導入・実行につながった、またはつながり得る事象を含みます。

分類は法務判断を伴い得ますが、技術チームが判断材料を用意することはできます。観測ログ、悪用経路、攻撃者の行動、影響を受けた製品・版、顧客環境での再現性、データ・機能への影響、侵害痕跡、暫定緩和策を、推測と事実に分けて記録します。

対象製品と自社の役割を最初の30分で切り分ける

タイの製造業では、一つの装置にPLC、産業PC、HMI、遠隔保守ゲートウェイ、クラウドダッシュボード、モバイルアプリ、OSSライブラリが組み込まれます。さらにOEM、ODM、ブランドオーナー、EU輸入者、販売代理店が別法人であることも珍しくありません。製品の範囲と経済事業者の役割を曖昧にしたまま、IT部門だけで報告主体を決めるのは危険です。

初動票には次の順で質問を置きます。

1. 対象は「products with digital elements」に該当する可能性がある製品か。
2. その製品はEU市場で利用可能にされているか。型式、ブランド、契約、販売経路は何か。
3. 自社は当該製品のmanufacturer、authorised representative、importer、distributorのどの役割を担うか。
4. 事象は自社の企業ITだけに閉じているか、それとも製品のセキュリティへ影響するか。
5. AEVまたはSIに該当する可能性を示す証拠は何か。
6. 影響する製品版、コンポーネント、EU加盟国、ユーザーをどこまで特定できたか。
7. 認識時刻を誰が、どの証拠に基づき記録したか。

このチェックは報告要否を自動判定するものではありません。目的は、PSIRT、法務、適合性評価責任者が短時間で判断できる事実を揃えることです。適用可否が微妙な製品では、通常運用から専門家へのエスカレーション条件を明記します。

ENISA Single Reporting PlatformとCSIRTルーティング

SRPは、ENISAが運営・維持するCRAの単一報告プラットフォームです。2026年9月11日に稼働し、メーカーはAEVとSIの必須通知を電子的に提出します。一つの事象についてEU各国当局へ個別送信するのではなく、SRPで関係するCDaCを選択し、一度提出する仕組みです。提出内容は原則としてENISAにも同時に利用可能となり、受領したCDaCが関係加盟国のCSIRT等へ伝達します。

タイ本社のメーカーはどのCDaCを選ぶか

ENISAの2026年9月17日更新FAQは、EU域外に親会社がある場合や複数EU拠点がある場合でも、一つのAEVまたはSIに対して必要な通知は一つであり、メーカーが社内調整する責任を負うと説明しています。

EUでの主たる拠点は、製品サイバーセキュリティに関する意思決定が主として行われる加盟国で判断します。それを決められない場合は、EU内で従業員数が最も多い拠点がある加盟国です。EUに主たる拠点がないメーカーは、Article 14(7)の順序に従い、利用可能な情報を基に次を評価します。

1. 最も多くの対象製品についてメーカーを代理するauthorised representativeが所在する加盟国
2. 最も多くの対象製品を市場へ置くimporterが所在する加盟国
3. 最も多くの対象製品を市場で利用可能にするdistributorが所在する加盟国
4. それでも決まらなければ、当該製品のユーザー数が最も多い加盟国

ここで注意すべき用語があります。SRPの提出ユーザーはENISA資料でAssigned Representative（AR）と呼ばれます。これはCRA上の経済事業者としてのauthorised representativeと同義ではありません。社内手順書では「SRP担当AR」と「EU法上の認定代理人」を別の役割として定義してください。

ENISAが公開するCDaC一覧は2026年9月10日に更新されています。販売国一覧だけで提出先を推測せず、判断根拠と選択したCDaCを事前レビューします。誤ったCDaCを選ぶと通知が無効化され、正しいCDaCへの再提出が必要になる可能性があります。

SRPアカウントを運用に組み込む

SRPは公開時点で英語のみです。Assigned RepresentativeはMFAを有効にした個人のEU Loginアカウントでアクセスします。Primary ARはメーカーとの最初の関連付けを作り、Secondary ARを招待できます。FAQではPrimary ARは1名、Secondary ARは最大20名と説明されています。どちらも権限の範囲内で通知の提出・更新ができ、同じメーカーに関連付けられたARは、ドラフトを除き通知を継続できます。

ENISAは、メーカー関連付けの検証が通知提出を妨げない仕組みとし、EU Loginがあれば登録自体は数分としています。一方で、登録画面を初めて見る状況で24時間対応を成功させるには、英語項目、MFA、休暇・退職時の代行、入力レビュー、証跡保存を手順化する必要があります。ENISAは必要時の登録を案内しているため、架空の通知を作る訓練ではなく、公開ガイダンスと画面項目に基づく机上演習にします。

製品SBOMを「作る」から「24時間で引く」へ

CRAはSBOMを、製品のソフトウェア要素に含まれるコンポーネントの詳細とサプライチェーン関係を記録する正式な記録と定義しています。しかし、ファイルを保管しているだけでは初動に使えません。報告運用では、脆弱な部品名から対象製品、版、顧客、販売国、保守状態、修正担当まで逆引きできることが重要です。

最低限つなぐべきデータ

OT資産管理・インベントリの記事で扱う工場内資産台帳は、出荷製品の製品台帳と同じではありません。前者は自社拠点の防御・保全に使い、後者は顧客へ供給した製品の影響範囲と報告に使います。共通の識別子設計は有効ですが、所有者、更新権限、保持期間を分けます。

第三者コンポーネントの脆弱性

OSSや購入モジュールでAEVが見つかった場合、「自社がコードを書いていないから対象外」と即断してはいけません。一方で、同じ部品を含む全メーカーが常に同じ結論になるとも限りません。組込み方、到達可能性、設定、製品版、悪用の信頼できる証拠、メーカーが認識した内容を調べ、Commission guidanceの第三者コンポーネントに関する説明と個別事情を照合します。

PSIRTのチケットには、上流アドバイザリの転載ではなく、自社製品へのマッピングを残します。具体的には、部品版、利用機能、呼出し経路、外部露出、コンパイル設定、緩和制御、影響する製品版、修正版の予定、上流サプライヤーへの照会、顧客に提供できる暫定策です。

PSIRTで回す24時間・72時間・最終報告

最初の24時間：早期警告を成立させる

この表の時刻は法令の配分ではなく、社内SLAの設計例です。待ち時間を吸収するための目安であり、報告が必要なら24時間ぎりぎりまで待つ理由にはなりません。

72時間通知：初期評価を更新する

72時間までに、製品と版、悪用またはインシデントの一般的性質、初期影響評価、実施済み・予定の是正または緩和措置、利用者が取れる措置、情報の機密性を更新します。修正版が未完成でも、遮断、設定変更、機能停止、監視強化、アクセス制限など、安全に検証済みの暫定策を明記します。

変更管理も重要です。24時間時点の仮説が否定された場合、古い記述を消して見えなくするのではなく、何が新しく判明し、評価がどう変わったかをケース内に残します。SRPのカウンターはリマインダーの参考であり、法的な起算点の責任を置き換えないとENISA FAQは注意しています。自社側で認識時刻と期限を計算し続けます。

最終報告：修正と原因を閉じる

AEVの最終報告は、是正・緩和措置が利用可能になってから14日以内です。脆弱性の重大度と影響、利用可能な場合は悪用主体に関する情報、セキュリティ更新やその他の是正措置を含めます。SIの最終報告は72時間通知から1か月以内で、詳細な事象、重大度と影響、想定される脅威または根本原因、実施済み・継続中の緩和措置を含めます。

「パッチ公開」でケースを閉じるのではなく、配布対象、署名、ロールバック、顧客通知、適用確認、残留リスク、SBOMと技術文書の更新、再発防止を完了条件にします。CDaCから中間報告を求められる可能性も、担当と期限管理に含めます。

タイ本社・EU販社・代理店の責任分担

非EUメーカーでは、情報がタイ本社、EU販社、輸入者、販売代理店、保守会社に分散します。責任表は「連絡先一覧」ではなく、判断・提出・技術修正・顧客連絡を分けて作ります。

A/R/C/Iは例であり、各社の法人構造に合わせて確定します。重要なのは、休暇や時差があっても一人の承認待ちで止まらないことです。タイと欧州の勤務時間が重なる窓を定義し、夜間は当番がケースを起動、次の欧州勤務開始までに判断材料を揃えるようにします。

RFPに入れるべきCRA報告運用の要求事項

PSIRTツール、SBOM基盤、脆弱性インテリジェンス、ケース管理、外部支援を調達するRFPでは、機能名だけで比較しないことが重要です。次の要求を、ベンダーが実演できる形で記述します。

データと追跡性

• 部品から製品・版・ビルド・顧客・EU加盟国への逆引き
• SPDXまたはCycloneDX等の受入形式と、欠損・重複・版表記揺れの検査
• CVEだけでなく、独自アドバイザリや悪用証拠をケースへ関連付ける機能
• 24時間、72時間、最終報告、利用者通知を同じケースで版管理する機能
• 事実、仮説、判断、承認、変更履歴を監査可能な時刻で保存する機能
• 製品寿命・サポート期間に沿った保持、アクセス制御、エクスポート

ワークフローと継続性

• AEV候補、SI候補、通常脆弱性を分けるトリアージ
• 認識時刻を起点にしたSLA計算と段階別アラート
• タイ本社とEU側の役割、代理承認、当番、エスカレーション
• SRPが英語であることを前提にした英語ドラフトと二者確認
• Assigned Representativeの個人アカウントに依存しすぎない引継ぎ
• SRP停止時の記録、CDaCへの必要な連絡、復旧後のSRP提出
• APIが初期公開時点で提供されていないことを前提に、内部自動化と人によるSRP入力を分離

セキュリティと証拠

• 脆弱性詳細、顧客情報、未公開パッチへの最小権限とMFA
• エクスポート、添付、承認、提出前後の改ざん検知または監査ログ
• テスト環境で実データを使わないマスキング
• バックアップ、復元、リージョン、委託先、インシデント通知条件
• 契約終了時にケース、SBOM、証跡を読み取り可能な形式で返却すること

RFPには「CRA compliant」という一文を求めるのではなく、シナリオ、入力データ、期待結果、証拠を添えます。法的判定はツールへ丸投げせず、人が判断し、システムは判断材料・期限・証跡を支える構成にします。

90日で実装するロードマップ

1〜30日：対象と時計を決める

最初の30日は、完璧なシステム導入より、誰が何を認識したら時計を開始するかを決めます。

• EU向け製品、型式、法人、ブランド、販売経路のスコープ表を作る
• manufacturer等の役割と、個別確認が必要な境界製品を整理する
• PSIRT責任者、当番、法務、適合性評価、EU側、SRP AR候補を指名する
• AEV/SI候補の受付チャネルと、認識時刻の記録ルールを統一する
• CDaC選択の事実データを集め、専門家レビューを予定する
• 24h、72h、最終報告のテンプレートと承認代替者を作る
• 代表製品1つについて、SBOMから製品・顧客までの逆引きを計測する

成果物は、スコープ台帳、役割表、初動票、期限計算表、連絡網、通知テンプレートです。対象外判断にも根拠と承認を残します。

31〜60日：データと手順を接続する

次に、製品SBOM、ビルド、販売・設置、サポート情報をケースIDでつなぎます。全製品のデータ整備を待たず、EU売上、接続性、脅威露出、サポート残期間を踏まえて優先製品群から着手します。

• SBOM品質ゲートを定義し、部品版・依存関係・成果物リンクを検査する
• 脆弱性情報から影響製品を検索する手順を試す
• importer、distributor、EU加盟国、顧客連絡先を更新する責任者を置く
• 24hから72h、最終報告へ情報を引き継ぐワークフローを設定する
• 英語提出文面の用語集とレビュー規則を作る
• SRPガイダンス、CDaC一覧、Commission guidanceの最新版確認を手順に入れる
• サプライヤーとの脆弱性通知SLAと、第三者部品の照会様式を整える

61〜90日：演習して受入証拠を残す

最後の30日は、会議室で手順を読むだけでなく、代表シナリオを通します。仮想事例であることを明示し、実在の脆弱性や顧客情報は使いません。

例として「EUへ出荷した産業ゲートウェイの第三者ライブラリについて、信頼できる悪用証拠をタイ時間14:00にPSIRTが認識した」という仮定を置きます。この場合、24時間の上限は翌日14:00、72時間の上限は3日後14:00です。これは単純化した演習上の計算であり、実案件では認識時刻と提出義務を専門家が確認します。

演習では、ケース起票、SBOM検索、対象版抽出、EU販売国抽出、AEV候補判断、経営エスカレーション、英語早期警告ドラフト、二者確認、提出証跡の模擬保存、72時間への引継ぎまでを計時します。結果は「できた／できない」ではなく、所要時間、欠損データ、手戻り、承認待ち、代替担当の成否で評価します。

受入試験：システムではなく報告能力を検証する

合格基準には「24時間以内」とだけ書かず、社内の目標時間を置きます。たとえば、ケース起票30分以内、代表製品の影響抽出2時間以内、早期警告ドラフト12時間以内などです。これらは各社が人員・製品複雑性に基づき定める内部目標で、法令が定める数値ではありません。

よくある失敗と修正策

失敗1：SOCインシデントと製品インシデントを同じキューだけで処理する

企業IT侵害と出荷製品のセキュリティ影響は重なることがありますが、必要な台帳と対外責任が異なります。共通窓口からPSIRTへ分岐する条件を決め、製品ケースIDを発行します。

失敗2：CVEが付くまで時計を始めない

CRAの定義と期限はCVE付与だけを起算条件にしていません。信頼できる悪用証拠とメーカーの認識を記録し、CVE/EUVDは関連識別子として追跡します。

失敗3：SBOMは納品ファイル、販売台帳はERPのまま分離する

24時間で必要なのは、ファイルの存在ではなく検索可能な関係です。部品→成果物→製品版→シリアル／顧客→加盟国をつなぐキーと更新責任を決めます。

失敗4：EU販社へすべて任せる

EU側は提出や当局対応に重要ですが、技術証拠、SBOM、修正計画はタイ本社にあることが多いです。一つの通知へ統合するケース責任者と、時差を越える引継ぎを設計します。

失敗5：24時間で完全な根本原因を要求する

早期警告は段階的報告の最初です。未確定情報を隠すのではなく、確定度を明示し、72時間と最終報告で更新します。同時に、平時に取得できる製品・販売・連絡情報まで未確定にしないよう整備します。

CRA 24時間報告に関するFAQ

CRA 脆弱性報告は通常の脆弱性をすべて24時間以内に出すのですか？

Article 14の必須報告は、メーカーが認識したAEVと、製品セキュリティへ重大な影響を持つSIが中心です。通常の未悪用脆弱性と同じキューで機械的に外部報告するのではなく、定義、証拠、製品影響を確認します。任意報告はSRPの将来フェーズとENISA FAQに記載されています。個別事象の義務判断は専門家へ確認してください。

CRA 24時間報告の起算点はいつですか？

メーカーがAEVまたはSIを認識した時点です。単なる受信時刻、CVE公開時刻、会議で承認した時刻のどれと一致するかは案件によります。受領、技術確認、判断、承認、提出を別時刻で保存し、起算点の根拠を残します。

タイ企業はENISAへ直接メールすればよいですか？

必須通知はSRPを通じ、適切なCDaCの電子エンドポイントを選んで提出します。SRPが一時的に利用できない場合、ENISA FAQは復旧を待って提出し、直ちに連絡が必要ならCDaCへ直接連絡しても、復旧後はSRP提出が必要と説明しています。

SRPのAssigned RepresentativeとEUのauthorised representativeは同じですか？

同じ意味として扱うべきではありません。Assigned RepresentativeはSRPを操作するPrimary／Secondary ARです。authorised representativeはCRA上の経済事業者・代理関係に関する用語です。社内の日本語訳でも役割名を分けてください。

第三者コンポーネントのAEVは誰が報告しますか？

自社製品への組込み、影響、悪用証拠、役割などで判断が変わり得ます。上流ベンダーの通知だけを転送したり、「上流が報告するから自社不要」と決めたりせず、自社製品へのマッピングを行い、Commission guidanceと専門家確認に基づいて判断します。

製品SBOMがあればCRA報告運用は完成ですか？

完成ではありません。SBOMを製品版、ビルド、販売国、顧客、修正、通知ケースへ結び、担当者が時間内に検索できる必要があります。期限、承認、SRP入力、利用者通知、最終報告も別途設計します。

90日でCRA対応を完了できますか？

全製品の法的・技術的対応を90日で終えられるとは限りません。本稿の90日は、優先製品を対象に報告能力の最小実働版を作り、演習と受入証拠まで到達する実装枠です。残る製品・データ品質・契約改定は、リスク順に継続します。

まとめ：CRA報告はPSIRT・SBOM・EU販売情報を一つの時計で動かす

CRA 脆弱性報告の成否は、24時間のフォーム入力速度だけで決まりません。対象製品と役割を切り分け、認識時刻を記録し、製品SBOMから影響製品を逆引きし、正しいCDaCへSRPで早期警告を出し、72時間通知と最終報告へ証拠を引き継ぐことが必要です。タイ本社とEU側の責任、Assigned Representative、法務・適合性評価、利用者通知まで含めて演習することで、初めて実務になります。

TOMAS TECHでは、タイの製造業・産業機器メーカー向けに、製品台帳とSBOMの連携、PSIRTワークフロー、RFP要求、90日導入計画、受入試験の整理を支援できます。適用可否の法的判断そのものではなく、専門家確認に必要な技術・業務証拠を整える検討段階から、お問い合わせください。

参考資料

1. European Commission, Cyber Resilience Act reporting obligations
2. ENISA, CRA Single Reporting Platform: Frequently Asked Questions
3. ENISA, Single Reporting Platform
4. European Commission, Cyber Resilience Act – Implementation
5. European Commission, Cyber Resilience Act summary
6. EUR-Lex, Regulation (EU) 2024/2847
7. ENISA, List of CSIRTs Designated as Coordinators
8. ENISA, CRA SRP Guidance – AR User Registration