目次
- 各制度が実際に求めている期限
- 報告期限とは、実のところ「起こしてもらう」問題である
- 週末なら少しは猶予があるのか
- 報告フローの手前に鳴る電話を置く方法
- ステップ 1 — 報告対象専用の Calling チャンネルを作る
- ステップ 2 — 検知基盤をその Webhook に向ける
- ステップ 3 — 条件を使い、妥当な候補だけを鳴らす
- ステップ 4 — メールしか送らないシステムを拾う
- ステップ 5 — 期限を背負う人を同じチャンネルに入れる
- ステップ 6 — おやすみモードをオンにしてテストする
- Echobell がやらないこと
- よくある質問
- Echobell を使えば DORA や NIS2 に準拠したことになりますか？
- DORA の 4 時間はいつから始まりますか？
- NIS2 の早期警告には詳細をすべて書く必要がありますか？
- 監視システムがすでにオンコール担当にメールを送っています。それでは足りませんか？
- コンプライアンスとエンジニアリングが同じアラートを受け取れますか？
- 電話は本当におやすみモードを突破しますか？
- iOS 専用ですか？
- Webhook ペイロードにはどんなデータを入れるべきですか？
- 関連記事
EU のインシデント報告期限はいずれも、機械が異常に気づいた瞬間から動き出し、チームが眠っている間も止まりません。その時計を動かすアラートが日曜の午前 2 時 40 分に届いた無音のプッシュ通知だとしたら、最初の人間がそれを読むより前に、DORA の報告ウィンドウの 4 分の 1 を使い切っていることになります。この記事では、Echobell を使って報告フローの手前に「本当に鳴る電話」を置き、時計と対応をほぼ同時に走り出させる方法を説明します。
この問題の規模は、いまや推測ではなく実測されています。2026 年 6 月 3 日、欧州三監督機構（ESAs）は DORA に基づく重大 ICT 関連インシデントについて EU 全体で初となる概観を公表しました。2025 年に報告された重大インシデントは 3,383 件、DORA 適用対象の金融主体 1 社あたり平均 0.18 件、そのうち約 3 分の 1 が国境を越えた影響を伴っていました（EBA、ESMA）。アラート設計にとって重要なのはこの一点です。サイバーセキュリティ関連はわずか 10% で、主因はシステム障害と外部要因でした。
つまり、規制上の時計を動かすのは圧倒的に「地味な出来事」です。失敗したデプロイ、落ちた依存サービス、プロバイダーの障害。あなたの監視がすでに午前 3 時に検知し、おやすみモード中の端末に届けている、まさにあの種の事象です。
各制度が実際に求めている期限
3 つの制度、3 つの異なるスタート地点。そしてどれも実時間で進みます。 現行テキストの定めは次のとおりです。
| 制度 | 最初の期限 | 次に | 最後に |
|---|---|---|---|
| DORA（EU の金融主体） | 重大と分類してから 4 時間以内に初期通知。かつ認知から 24 時間を超えないこと | 初期通知から遅くとも 72 時間以内に中間報告 | （最新の）中間報告から 1 か月以内に最終報告 |
| NIS2（EU の重要・重大主体） | 重大インシデントを認知後、遅滞なく、いかなる場合も 24 時間以内に早期警告 | 認知から 72 時間以内にインシデント通知 | インシデント通知から 1 か月以内に最終報告 |
| SEC 項目 1.05（米国上場企業） | 重要性を判断してから原則 4 営業日以内に Form 8-K を提出 | — | — |
DORA の期限は、インシデント報告の内容と時限に関する規制技術基準である委員会委任規則 (EU) 2025/301 に定められています。2025 年 2 月 20 日に公表され、規則 (EU) 2022/2554 を補完するものです（欧州委員会、第 5 条の条文）。DORA 自体は 2025 年 1 月 17 日から適用されています（ESMA）。
NIS2 の期限は指令 (EU) 2022/2555 第 23 条第 4 項にあり、加盟国は 2024 年 10 月 17 日までに国内法化する必要がありました（欧州委員会）。SEC の期限は 2023 年 7 月 26 日に採択されたサイバーセキュリティ開示規則に基づきます（SEC）。
報告期限とは、実のところ「起こしてもらう」問題である
どの時計もあなたの就業時間を基準にしていないからです。 DORA は分類と主体の認知から、NIS2 は主体の認知から、SEC は重要性の判断から測ります。ある瞬間が「認知」に当たるかどうかは、コンプライアンス部門が下す法的判断です。しかしこれらの条文のどこにも、「最初にアラートを見た人がたまたま寝ていたから測り直す」という規定はありません。
DORA の最も厳しい経路を逆算してみましょう。重大と分類された時点から 4 時間しかなく、その分類は人間が中身を見るまで始まりません。検知が 2 時 40 分、確認が 8 時、そこから調査に 90 分かけて分類が終わるとすると、初期通知の提出は 11 時ごろ。24 時間の上限内ではありますが、24 時間の予算のうち 8 時間以上を「眠っていた」だけで使ったことになります。確認までの空白を縮めれば、その後のすべての工程に余裕が生まれます。
これは「もっと多くの事象にアラートを出せ」という主張ではありません。むしろ逆で、報告対象になり得るごく限られた種類のアラートだけが物理的に寝過ごせない状態であるべきで、それ以外は静かなままにしておくべきだ、ということです。（すでにチームがアラートに溺れているなら、うるさいチャンネルを足す前にアラート疲れの解消から始めてください。）
週末なら少しは猶予があるのか
DORA では少しだけ。そしておそらくあなたには適用されません。 委任規則 (EU) 2025/301 は、期限が当該加盟国の週末または祝日に当たる場合、翌営業日の正午までの提出を認めています。しかし同じ条文は、信用機関、中央清算機関（CCP）、取引所運営者、および NIS2 上の重要・重大主体をこの緩和から明示的に除外しています。所管当局は、その他のシステム上重要な主体についても緩和を外すことができます（第 5 条、Advisera の要約）。
つまり、日曜の夜にインシデントを起こす可能性が最も高い組織こそ、週末の救済を受けられません。NIS2 第 23 条には週末の延長規定そのものがありません。土曜も火曜と同じように時計が進む前提で設計し、たまたま適用される緩和は「余裕」ではなく「おまけ」として扱ってください。
報告フローの手前に鳴る電話を置く方法
Echobell がやることは一つだけです。Webhook やメールを電話に変えること。家族からの着信のように、iOS の集中モードとおやすみモードを突き抜けて実際に鳴り、振動する電話です（重要アラートで iOS 集中モードを回避する方法を参照）。インシデントを検知するシステムと、時計を動かさなければならない人間の間に立ちます。
ステップ 1 — 報告対象専用の Calling チャンネルを作る
Echobell でチャンネルを作成し、通知タイプを Calling に設定します。これが、無音のプッシュではなく電話を鳴らす鍵です（通知タイプ）。「報告対象インシデント — 起こして」のように誤解の余地がない名前を付け、その用途以外には使わないでください。チャンネル詳細から https://hook.echobell.one/t/<channel-token> の形式の Webhook URL をコピーします。これは秘密情報として扱ってください。
ステップ 2 — 検知基盤をその Webhook に向ける
インシデントに気づいたシステムが、チャンネル URL に HTTP リクエストを送ります。Echobell には Grafana、Prometheus Alertmanager、Uptime Kuma、UptimeRobot の個別ガイドがあり、JSON を POST できるものなら何でも Webhook ガイドで対応できます。有用なペイロードとは、ノート PC を開かずに一次分類の判断ができるだけの情報を運ぶものです。
{
"title": "報告対象候補: {{service}}",
"message": "{{service}} が {{started_at}} から停止 — 顧客影響: {{client_impact}}",
"externalLink": "https://status.internal.example/incident/{{id}}"
}externalLink 変数は通知記録内でクリック可能なリンクになるため、電話に出た人はそのままインシデントページへ移動できます。
ステップ 3 — 条件を使い、妥当な候補だけを鳴らす
あらゆる警告で鳴る電話は、やがて電話ではなく背景ノイズになります。 Echobell の条件は変数値を AND/OR で組み合わせて絞り込めるので、たとえば severity == "critical" かつ client_impact == true のときだけ発信させられます。その基準に満たないものは、別の Time Sensitive または Normal チャンネルに回してください。報告対象チャンネルが鳴るのは年に数回で十分であり、毎週鳴るようではいけません。
ステップ 4 — メールしか送らないシステムを拾う
ベンダーのステータス配信、不正検知ツール、サードパーティ事業者の多くはメールでしか通知しません。プロバイダー側の障害が明確に適用範囲に入る DORA では、これが特に効いてきます。Echobell のチャンネルはそれぞれ専用のメールアドレスを持てるので、転送ルール一つでそれらを電話に変えられます（メールトリガー、メールから電話への設定）。
ステップ 5 — 期限を背負う人を同じチャンネルに入れる
インシデントを見つけるのはエンジニアリングですが、期限を背負うのはコンプライアンス、当直責任者、あるいは DPO です。チャンネルを共有すれば、購読者それぞれが緊急度を選べます。オンコールエンジニアには電話、第二対応者には時間指定通知、という構成が可能です。集中モードでブロックされた着信を再試行させるため、Retry Failed Call も有効にしておきましょう。
ステップ 6 — おやすみモードをオンにしてテストする
重要な端末すべてでおやすみモードを有効にしたうえで、少なくとも四半期に一度はテスト Webhook を送ってください。テストされていないエスカレーション経路はただの仮定であり、事後レビューはたいてい仮定でできています。
Echobell がやらないこと
規制対象のワークフローでは、ここを正確にしておくことが何より重要です。
Echobell がやること： Webhook やメールを、鳴る電話・時間指定アラート・通常プッシュに変える。Calling アラートで iOS の集中モードとおやすみモードを突破する。条件とテンプレートで絞り込む。共有チームチャンネルに同じアラートを届ける。
Echobell がやらないこと：
- インシデントの分類。 DORA の「重大」、NIS2 の「重要」、SEC 規則の「重要性」に当たるかどうかについて、Echobell は何の見解も持ちません。これらは該当条文の基準に照らして人が下す判断です。
- 当局への提出。 所管当局にも CSIRT にも SEC にも、何一つ提出しません。提出できる状態まで人を連れてくるだけです。
- 記録保持や GRC システムの代替。 これらの制度は文書、登録簿、証跡を要求しますが、アラートアプリはそれらを生み出しません。Echobell は通知内容と履歴を端末内にのみ保存し、サーバーにはアカウント・チャンネル・購読情報だけを置く設計です（プライバシーモデル）。データ最小化には良いことですが、監査証跡としては役に立ちません。
- コンプライアンス証明の提供。 認証も監査報告書も契約上の SLA もありません。規制対象のワークフローに組み込むなら、他のツールと同様にあなた自身の ICT サードパーティリスク手続きを通し、Echobell に依存しない経路も残してください。
- 配信の保証。 電話はプッシュ基盤、ネットワーク、充電された端末に依存します。確認までの時間を大幅に短縮する層として扱い、監査で示せる統制と見なさないでください。
率直に言えば、どのアプリが電話を鳴らそうと、あなたの規制上の義務は変わりません。電話が変えるのは、機械が気づいてから人が判断するまでの時間だけです。そして 4 時間の時計の下では、その時間こそが予算のほとんどを占めます。
よくある質問
Echobell を使えば DORA や NIS2 に準拠したことになりますか？
なりません。準拠はガバナンス、分類プロセス、文書、そして所管当局や CSIRT への実際の提出にかかっています。Echobell は検知から人間の確認までの空白を縮めるだけであり、プロセスへの入力の一つであってプロセスそのものではありません。
DORA の 4 時間はいつから始まりますか？
分類の時点からです。委任規則 (EU) 2025/301 では、初期通知はインシデントを重大と分類してから 4 時間以内、かついかなる場合も主体が認知してから 24 時間以内に提出する必要があります。これは 2 つの独立した制約で、両方を満たさなければなりません。だからこそ、素早いアラートと同じくらい素早い分類判断が重要になります。
NIS2 の早期警告には詳細をすべて書く必要がありますか？
いいえ。指令 (EU) 2022/2555 第 23 条第 4 項は、24 時間の早期警告を意図的に暫定的なものにしています。不法または悪意ある行為が疑われるか、国境を越えた影響がありうるか、を示せば足ります。より詳しい内容は 72 時間の通知で、根本原因分析は 1 か月後の最終報告で扱います。
監視システムがすでにオンコール担当にメールを送っています。それでは足りませんか？
誰かが起きて見ているなら足ります。メールと通常のプッシュ通知は集中モード、おやすみモード、睡眠スケジュールで消音されます。それはまさに、時計が最も容赦のない夜間と週末の状況です。ギャップは検知ではなく確認にあります。
コンプライアンスとエンジニアリングが同じアラートを受け取れますか？
はい。チャンネルを共有すれば購読者全員がトリガーを受け取り、各自が通知タイプを選べます。よくある構成は、オンコールエンジニアが Calling、当直のコンプライアンス責任者は報告対象チャンネルを Calling、それ以外を Time Sensitive にする形です。
電話は本当におやすみモードを突破しますか？
Echobell の Calling 通知タイプは iOS の集中モードとおやすみモードを鳴り抜けるよう設計されており、Retry Failed Call 設定は集中モードでブロックされた着信を再試行します。OS の設定やバージョンによって挙動は異なるため、依存する前に各対応者の実機で必ず確認してください。
iOS 専用ですか？
いいえ。Echobell は iOS に加え、Google Play 経由の Android でも利用できます（Android 版リリース告知を参照）。着信型アラートの挙動はプラットフォームによって異なるため、対応者が実際に持ち歩く端末でテストしてください。
Webhook ペイロードにはどんなデータを入れるべきですか？
できるだけ少なく。顧客情報やインシデントの詳細ではなく、識別子とリンクを送ってください。externalLink 変数でインシデント記録を指し示せば、その内容を保持するために作られたシステムに情報を置いたままにできます。アラートの仕事は人を起こすことであり、説明することではありません。