目次
- 2026年9月11日から具体的に何が始まるのか
- 実際に義務を負うのは誰か
- なぜ24時間の期限がアラートの問題なのか
- 24時間の早期警告には何を書くのか
- 24時間タイマーの前に、鳴る電話をどう置くか
- ステップ1 —— CRA候補専用の着信チャンネルを作る
- ステップ2 —— 各検知経路をチャンネルに向ける
- ステップ3 —— 条件を使い、妥当な候補だけを鳴らす
- ステップ4 —— メールしか送ってこないシステムを受け止める
- ステップ5 —— 登録済みの代表者を全員チャンネルに入れる
- ステップ6 —— 9月11日の後ではなく前にリハーサルする
- Echobellにできないこと
- よくある質問
- Echobellを使えばCRAに準拠できますか？
- 24時間タイマーは正確にいつ始まりますか？
- 当社は小規模です。免除されますか？
- セキュリティ用メールボックスは営業時間内は見ています。これで十分ですか？
- コンプライアンス、法務、エンジニアリングが同じアラートを受け取れますか？
- 第14条(8)のユーザー通知義務にも役立ちますか？
- すでにNIS2やDORAで報告しています。同じものですか？
- 本当におやすみモードを突破できますか？
- iOS専用ですか？
- webhookのペイロードには何を入れるべきですか？
- 関連記事
2026年9月11日、EUサイバーレジリエンス法（Cyber Resilience Act、CRA）の報告義務の適用が始まります。この日以降、デジタル要素を含む製品において能動的に悪用されている脆弱性を認識した製造者、あるいは当該製品に影響する重大インシデントを認識した製造者は、24時間以内に調整役CSIRTとENISAへ早期警告を送らなければなりません（欧州委員会、規則 (EU) 2024/2847）。
この期限には、多くのコンプライアンス期限にはない性質があります。実時間で進むのです。営業日だけを数える例外もなければ、週末の一時停止もなく、報告責任者が飛行機の中にいるあいだの猶予もありません。しかも提出先であるENISAの単一報告プラットフォーム（Single Reporting Platform、SRP）はWebフォームで、「現段階ではアプリケーション・プログラミング・インターフェースは提供されない」とされています（ENISA FAQ）。登録された個人がログインして提出する必要があります。
つまり24時間ルールは、事務手続きの問題である前にアラートの問題です。本記事では、Echobell を使って「認識した瞬間」を鳴る電話に変える方法を示すとともに、通知ツールでは手が届かないCRA対応の大部分についても正直に述べます。
2026年9月11日から具体的に何が始まるのか
デジタル要素を含む製品の製造者は、能動的に悪用されている脆弱性と重大インシデントを単一のEUプラットフォームで報告する義務を負い、そのタイマーは「認識した瞬間」から段階的に進みます。 CRAのそれ以外の部分——CEマーキング、附属書Iの必須要件、適合性評価——の適用は2027年12月11日からです。報告義務はその15か月前に到来し、しかもその日以降に出荷する製品だけでなく、すでに市場にある製品にも適用されます（cyberresilienceact.eu）。
第14条は、同じ形をした2つの並行トラックを定めています。
| 段階 | 能動的に悪用されている脆弱性——第14条(2) | 重大インシデント——第14条(4) |
|---|---|---|
| 早期警告 | 認識から 24時間以内 | 認識から 24時間以内 |
| 通知 | 認識から 72時間以内 | 認識から 72時間以内 |
| 最終報告 | 是正措置または緩和策が利用可能になってから 14日以内 | 72時間通知の後 1か月以内 |
条文の表現は「不当に遅滞することなく、いかなる場合も製造者が認識してから24時間以内に」です（第14条）。24時間は上限であって、目標ではありません。
第14条(5)は「重大」の基準を定めています。機微または重要なデータもしくは機能の可用性・真正性・完全性・機密性を保護する製品の能力に悪影響を与える、または与えうるインシデント、あるいは悪意あるコードの導入や実行につながった、またはつながりうるインシデントが該当します。この「〜しうる」が重要です。顧客に実害が出る前の段階で、すでに報告義務が生じている場合があります。
第14条(8)は、これと並行して走るもう一つの義務を課します。製品の影響を受けたユーザーに対して、当該脆弱性またはインシデントを、必要な場合には利用者側で取りうる是正措置についても知らせなければなりません。CSIRTとはまったく別の相手に対する、別経路の義務です。
実際に義務を負うのは誰か
設立地を問わず、デジタル要素を含む製品の製造者。加えて、より限定的な形でオープンソースソフトウェアのスチュワード。 EU域外の企業がEU市場に販売している場合も義務を免れません。規則は、関連する義務についてEU域内の経済事業者が責任を負うことを求めています（cyberresilienceact.eu）。
報告先は、EU域内の主たる事業所が所在する加盟国で調整役に指定されたCSIRTと、同時にENISAです。ただし提出は単一報告プラットフォームで1回だけ行い、プラットフォームが両者へ振り分けます（欧州委員会）。
オープンソースソフトウェアのスチュワードは、明確に限定された範囲で対象になります。第14条(1)の義務はデジタル要素を含む製品の開発に関与している範囲で適用され、第14条(3)および(8)の義務は、当該開発のために提供しているネットワーク・情報システムに重大インシデントが影響を及ぼす範囲で適用されます。広く使われるプロジェクトをスチュワードしているなら、どちらかの極端を仮定せず、第24条を第14条とあわせて読んでください。
第15条は任意報告も認めています。脆弱性、サイバー脅威、インシデント、ニアミスについて、製造者に限らず誰でも任意に報告できます。任意報告が新たな義務を生むわけではありませんが、プラットフォームは同じであり、「誰かが起きている必要がある」という問題も同じです。
なぜ24時間の期限がアラートの問題なのか
タイマーが動き出すのは「認識した」ときであり、認識が営業時間内に訪れることはめったにないからです。 トリガーは、組織が何かを決めることではなく、ある事実が組織に到達することです。
その事実がどこから来るかを考えてみてください。土曜の23時40分に、セキュリティ研究者が security@ にメールを送ってくる。下流の顧客が悪用の様子を書いたサポートチケットを起票する。自社が同梱しているコンポーネントについてCVEやKEVのフィードが点灯する。自社のEDRがビルドシステム上での実行を検知する。DLA Piperの準備状況に関する解説は、そのサプライチェーン版を明確に指摘しています。製造者は最初に知る立場にないことが多く、情報は輸入業者、販売業者、研究者、部品供給者を経て届きます（DLA Piper）。
これらの経路はいずれも、いまの設定ではおそらく無音で配信される通知に行き着きます。共有受信箱のメール、夜間は誰も見ていないSlackチャンネルのメッセージ、月曜まで放置されるキューのチケット。どれも失敗していません。正しく配信されています——誰もいないところへ。
このギャップを見た目以上に深刻にする要素が3つあります。
- APIがない。 ENISAは現段階で報告APIを提供しないと明言しています。全員が眠っているあいだにスクリプトが早期警告を提出しておく、という手は使えません。
- アクセス権は人単位で、事前に用意しておく必要がある。 授権代表者はEU Loginアカウントで登録し、指定された調整役CSIRTが初回アクセス後にその権限を検証します。主代表者と予備の副代表者が置かれ、副代表者への招待は7日で失効します（ENISA FAQ、cyberresilienceact.eu）。提出できる唯一の人物に連絡がつかなくても、期限は待ってくれません。
- 制裁は最上位の区分。 第64条は、第13条および第14条の義務違反を「最高1500万ユーロ、または違反者が事業者である場合は前会計年度の全世界年間売上高の2.5%のいずれか高い方まで」の行政制裁金の区分に置いています（第64条）。
最後の点には、小規模チームの判断を左右する正直な但し書きがあります。第64条は、零細企業または小企業に該当する製造者を、第14条(2)(a)または(4)(a)の期限を守れなかったこと——つまりまさに24時間の早期警告——に対する行政制裁金から除外しています。ただし報告義務そのものは残り、この除外は72時間通知や第14条の他の部分には及びません。自社がどちらに当たるかは、ブログではなく条文と専門家の助言で確かめてください。
24時間の早期警告には何を書くのか
ごくわずかです——そこが要点です。 ENISAのガイダンスは、早期警告段階の必須項目として小さな集合を示しています。通知種別（脆弱性かインシデントか）、通知レベル、報告時刻、報告者情報、製造者またはスチュワード名、製品、タイトル、そしてインシデントの場合は違法または悪意ある行為が疑われるかどうか。この段階の任意項目にはCVE IDやEUVD IDが含まれます。
より詳しい技術的な全体像——脆弱性や悪用手法の一般的性質、初期評価、是正・緩和措置——は72時間通知の内容であって、最初の24時間のものではありません。
つまり早期警告は調査プロジェクトではなく、準備のできた人なら数分で出せる短いフォームです。制約となるのはフォームではありません。登録済みで、権限があり、そして起きている人が間に合ううちに知るかどうかです。これは通知ルーティングの問題であり、今日から解決できます。
24時間タイマーの前に、鳴る電話をどう置くか
Echobellは、webhook呼び出しやメールを、着信のように鳴って振動するアラートに変えます。これがiOSの集中モードやおやすみモードを突破できる理由です（iOS集中モードの突破を参照）。以下の構成は、すでに運用しているチケットやPSIRTのプロセスと並行して働くもので、それらを置き換えるものではありません。
ステップ1 —— CRA候補専用の着信チャンネルを作る
アプリでチャンネルを作成し、通知タイプを着信に設定します（通知タイプ）。データソースではなく、それが引き起こす判断で名前を付けてください。「セキュリティアラート」よりも「CRA — 24時間タイマー開始の可能性」の方が適切です。
このチャンネルは静かなままでなければなりません。あらゆる勧告、あらゆるスキャン失敗、あらゆる依存関係更新で鳴るようになれば、人は出なくなり、唯一の「うるさい」経路をノイズに使い潰したことになります。それらは別に流してください——アラート疲れの解消ガイドが振り分け方を扱っています。
チャンネル詳細からwebhook URLをコピーします。形式は https://hook.echobell.one/t/<channel-token> です。これを持つ者は誰でもチームの電話を鳴らせるので、秘密情報として扱ってください（Webhookガイド）。
午前2時に半分眠ったままロック画面で読めるテンプレートにします。
タイトル：CRA報告の可能性 — {{product}}
本文：{{kind}} — {{summary}}（{{time}} UTC 時点で認識）
{{time}}、{{date}}、{{hour}} などのシステム時刻変数は常にUTCで注入されるため、送信側がタイムスタンプを付け忘れても通知には時刻が残ります。これは「いつ認識が始まったか」の法的証拠ではありませんが、後からタイムラインを再構成するときの有用な起点になります。
ステップ2 —— 各検知経路をチャンネルに向ける
webhookを呼べるシステムなら何でもチャンネルを起動できます。送ったフィールドはそのままテンプレート変数になります。
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"product": "Acme Gateway 4.x",
"kind": "能動的に悪用されている脆弱性",
"summary": "研究者からの報告、動作する実証コード添付",
"craCandidate": true,
"externalLink": "https://issues.internal.example/PSIRT-4412"
}'特殊変数 externalLink は通知記録内でクリック可能なリンクになるため、電話に出た人はワンタップで詳細のあるチケットに到達できます。
最初のシグナルになりやすい順に、つないでおく価値があるものは次のとおりです。
- PSIRTやセキュリティ受付キュー —— 課題にCRA候補ラベルが付いたときにwebhookを送る。
- 出荷製品をビルドするリポジトリのGitHubセキュリティアドバイザリとDependabotアラート（GitHub連携）。
- SIEM、EDR、WAF —— ビルド・リリース・署名インフラに対する検知。第14条(5)は悪意あるコードの導入につながりうるインシデントを明示的に含みます。
- すでに購読している脆弱性インテリジェンス —— 自社SBOMに現れるコンポーネントに絞り込んで。
ステップ3 —— 条件を使い、妥当な候補だけを鳴らす
チャンネルの信頼性を保てるかはこのステップで決まります。 Echobellの条件はテンプレートと同じ変数やHTTPヘッダーを評価し、式が真のときだけチャンネルが発火します。
craCandidate == true && confirmed == true
送信側がボディを整形できない場合は、ヘッダーで判定することもできます。
header["x-cra-severity"] == "reportable"
しきい値は「これは確実に報告対象だ」ではなく、「1時間以内に有資格者が目を通すべきだ」に置いてください。第14条が発動するかどうかの判断は、事実を把握した人間が行うべきものです。チャンネルの仕事は、その人を事実まで素早く連れて行くことです。ここで絞りすぎるのが高くつく間違いです。着手されなかった報告は、不要だった1本の電話よりずっと悪い結果を招きます。
ステップ4 —— メールしか送ってこないシステムを受け止める
社外からの最初の接触はたいていメールです。研究者、顧客、各国CSIRT、部品ベンダー。Echobellのチャンネルはそれぞれ専用のメールアドレスを持てるため、security@ に転送ルールを1つ設けるだけでそれらを電話に変えられます（メールトリガー）。
メールトリガーは from、to、subject、text、html を変数として公開するので、パースなしで絞り込めます。
subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")
常連の報告者や主要サプライヤーと件名マーカーを取り決め、それで一致判定してください。ささいな取り決めですが、構造のない受信箱をルーティング可能なシグナルに変えられます。
ステップ5 —— 登録済みの代表者を全員チャンネルに入れる
実際に提出できる人全員とチャンネルを共有します。主授権代表者、予備の副代表者、そして第14条の判断ができるセキュリティ責任者です。購読者ごとに通知タイプを選べるので、当番の人は着信、それ以外は時間指定重要にできます。
これこそがこの取り組みの核心です。SRPは登録・検証済みの自然人を要求します。社内で1人しか登録していないなら、あなたの24時間の期限は、スマートフォンのバッテリーに依存した単一障害点を抱えていることになります。
ステップ6 —— 9月11日の後ではなく前にリハーサルする
今月中にやる価値のあるリハーサルが2つあります。
- アラート経路。 おやすみモードを実際にオンにした状態で、本当に枕元に置く端末に対して上記の
curlを撃ちます。アプリで通話失敗時に再試行を有効にして、一度失敗した着信が再試行されるようにします。テストしていないエスカレーション経路は、単なる思い込みです。 - 提出経路。 ENISAの手順書（登録および提出のステップ別ガイド。2026年8月まで更新が続いています）を使い、机上で報告を一通りなぞります（ENISA SRP）。EU Loginアカウントを今のうちに作り、どのCSIRTが自社の調整役かを確認し、副代表者への招待は早めに出してください——7日で失効します。
2つ目のリハーサルには知っておくべき事情があります。ENISAの7月のガイダンス時点では、プラットフォームの公開URLはまだ「公開時に提供予定」と記されており、実環境でのエンドツーエンドのテストはできませんでした（cyberresilienceact.eu）。ENISAは2026年9月11日までにプラットフォームを稼働させると表明しています。自分でコントロールできる部分はすべてリハーサルし、プラットフォームの準備状況を自社の準備を遅らせる理由にしないでください。
Echobellにできないこと
主題が規制である以上、ここを具体的に述べることは普段以上に重要です。
- コンプライアンスを達成させるものではありません。 Echobellは通知チャンネルです。対象製品の棚卸し、脆弱性ハンドリングプロセスの運用、第14条が発動するかの判断、SRPへの登録、期限内の提出——すべて自社の仕事です。アラートツールが報告義務を果たしたことは一度もありません。
- 提出は行いません。 そもそも提出用のAPIはなく、あったとしてもそれを呼ぶのはEchobellではありません。電話を鳴らすところまでが役割で、残りは登録済みの人間が行います。
- 法的なタイムスタンプではありません。
{{time}}変数が記録するのは、トリガーがEchobellに届いたUTC時刻です。「いつ認識が始まったか」は自社に関する事実問題であり、それを裏づけるのはプッシュ通知ではなくインシデント記録です。 - エスカレーションポリシーも確認応答もありません。 「10分出なければ次の人に電話」も、ローテーションも、誰が何を確認したかの監査証跡もありません。それらが必要ならインシデント管理プラットフォームが要ります——Opsgenieの代替を参照してください。
- 配信を保証できません。 着信はプッシュ基盤、ネットワーク、充電された端末に依存します。事実の到達と人が知るまでの差を縮める層として扱ってください。監査で指し示せる統制ではありません。
- ローカル時刻を追いません。 組み込みの時刻変数はUTCのみで、夏時間には追随しません。時間帯を絞る条件は年2回の手動調整が必要です。
よくある質問
Echobellを使えばCRAに準拠できますか？
いいえ。CRAは製造者に義務を課しており、通知アプリがそれを肩代わりすることはできません。Echobellが対処するのは1つの具体的な失敗パターンです。提出できたはずの人が翌営業日まで気づかず、24時間の早期警告を逃す——という失敗です。実在する頻度の高い失敗ですが、はるかに大きなコンプライアンス体制の一部にすぎません。
24時間タイマーは正確にいつ始まりますか？
製造者が能動的に悪用されている脆弱性または重大インシデントを認識した時点です。規則は正確な瞬間を定義しておらず、認識は事実そのものと、その事実をどれだけ早く確定できるかに左右されます（DLA Piper）。実務上は、トリアージを速く、かつ記録に残して行うべきだということです。シグナルの到着と評価開始の間が空くほど、後から説明するのが難しくなります。
当社は小規模です。免除されますか？
報告義務は免除されません。第64条は、第14条(2)(a)または(4)(a)の24時間期限を守れなかったことに対する行政制裁金についてのみ、零細企業と小企業を除外しています。報告義務そのものは残り、72時間通知や最終報告には影響せず、零細企業・小企業の定義も自己判断で決められるものではありません。通行証ではなく、範囲の狭い緩和措置と捉えてください。
セキュリティ用メールボックスは営業時間内は見ています。これで十分ですか？
ふつうの週末に猶予の最大3分の2を失ってよいなら十分です。金曜18時に届いた報告の期限は土曜18時です。営業時間内の監視は他の多くの用途では妥当な既定値ですが、24時間タイマーはまさにそれが覆えない領域です。
コンプライアンス、法務、エンジニアリングが同じアラートを受け取れますか？
はい、そうすべきです。1つのチャンネルを共有すれば、同じトリガーで全購読者に通知が届き、緊急度は各自が選べます。悪用を確認するエンジニアと、フォームを提出する人は、順番にではなく同じ分に動き出す必要があります。
第14条(8)のユーザー通知義務にも役立ちますか？
間接的には役立ちます。第14条(8)は、影響を受けたユーザーに脆弱性またはインシデントを、必要な場合は是正措置も知らせることを求めます。これは顧客コミュニケーションであり、自社のチャンネルが必要です。Echobellは、その連絡を担う人と提出を担う人を同時に起こせるので、2つの作業を並行して開始できます。
すでにNIS2やDORAで報告しています。同じものですか？
いいえ。形は似ていますが別物です。NIS2とDORAは業種と重要度に基づいて主体に義務を課し、CRAはEU市場に投入する製品に基づいて製造者に義務を課します。1つの組織が3つすべての対象になることもあり、タイマーも受け手も異なります。これらも対象なら、DORAとNIS2のインシデント報告アラートをご覧ください。義務は別でも、アラート層は共有できます。
本当におやすみモードを突破できますか？
着信通知は通話形式で配信され、それがiOSで集中モードを突破できる理由です。ただし魔法ではありません。OS設定、ネットワーク、充電された端末に依存します。頼りにする前に、実機で、実際に集中モードをオンにしてテストし、通話失敗時に再試行を有効にしてください。
iOS専用ですか？
いいえ。EchobellはiOSに加え、Google Play経由のAndroidでも利用できます（Android版リリース）。着信型アラートの挙動はプラットフォームで異なるため、対応者が実際に持ち歩く端末でテストしてください。
webhookのペイロードには何を入れるべきですか？
起き上がるかどうかを判断できる最小限です。製品、シグナルの種類、背景を1行、そして詳細を保持するチケットへの externalLink。Echobellは通知内容と履歴を端末に保存し、サーバーにはアカウント・チャンネル・購読情報のみを保持しますが（プライバシーモデル）、セキュリティ上機微な素材を扱う際は、中身ではなくポインタを送る習慣が正解です。