能動的サイバー防御の企業対応、届出期限までにやるべき3ステップ
2026年10月1日、能動的サイバー防御の中核となるサイバー対処能力強化法のうち、基幹インフラ事業者の届出と報告の義務などを定めた規定が施行されました。基幹インフラ15分野258事業者には、インシデント報告の義務が既に発生しています。ただし制度は段階的に施行されており、政府による通信情報の利用に関する規定は2027年11月22日まで（政府資料では2027年秋）の施行予定として残っています。
出典：国家サイバー統括室「サイバー対処能力強化法等の施行について」
そして今まさに動いている期限は、2027年3月31日です。施行時点で導入済みの特定重要電子計算機について、この日までに届出を終える必要があります。
この記事は、基幹インフラ事業者とその取引先の情報システム責任者・CISO に向けて、「自社が直接の対象か、サプライチェーン側か」を切り分け、残された期限に向けた作業の優先順位を整理するものです。結論から書くと、優先度が最も高いのはログの保全と資産の棚卸しです。届出もインシデント報告も、この2つが揃っていなければ成立しません。
能動的サイバー防御法をわかりやすく
- 正式名称は「重要電子計算機に対する不正な行為による被害の防止に関する法律」（サイバー対処能力強化法）。2025年5月23日に整備法とあわせて公布され、2026年10月1日に届出と報告の義務などの規定が施行された。
- 基幹インフラ15分野の事業者に対し、基幹業務を支える「特定重要電子計算機」の政府への届出と、サイバー攻撃を認知した際の報告を義務づける。報告は速報を速やかに（ランサムウェア等は認知から3〜5日以内）、詳報を認知から30日以内に、事業所管大臣と内閣総理大臣へ提出する。
自社はサイバー対処能力強化法の対象か。3つの質問で切り分ける
「うちは258事業者に入るのか」という問いは、次の順番で切り分けられます。
Q1. 自社の事業は基幹インフラ15分野に該当するか？
├─ NO → Q3 へ（サプライチェーン側の対応）
└─ YES
│
Q2. 経済安全保障推進法の基幹インフラ制度で、
主務大臣から特定社会基盤事業者の指定を受けているか？
├─ YES → 直接の対象。報告義務は既に発生している。
│ 届出は2027年3月31日まで
└─ NO → 現時点では直接の対象外。ただし新規指定は
随時行われるため、Q3 とあわせて備える
│
Q3. 基幹インフラ事業者にシステム・運用・保守を
提供しているか？
├─ YES → 取引先経由で説明・情報連携を求められる可能性が高い
└─ NO → 直接の要請は想定しにくいが、
ログ保全・資産棚卸しは平時のリスク対策として有効基幹インフラ15分野
分野
電気 / ガス / 石油 / 水道
鉄道 / 貨物自動車運送 / 外航貨物 / 港湾運送 / 航空 / 空港
電気通信 / 放送 / 郵便
金融 / クレジットカード
なお、2026年6月17日に、対象分野に医療を加える経済安全保障推進法の改正法が公布されました。公布から1年6か月以内の政令で定める日に施行され、施行後は16分野になります（出典：内閣府「経済安全保障推進法の特定社会基盤役務の安定的な提供の確保に関する制度について」）。
分野に該当することと、事業者として指定を受けていることは別です。258という数字は、分野に属する全企業ではなく、規模や社会的影響度の基準で主務大臣が指定した事業者の数を指します（2026年7月1日時点。出典：内閣府「特定社会基盤事業者として指定した者」）。
直接の対象でなくても問われること
対象事業者と取引がある場合、届出やインシデント報告の一環として、次のような照会を受ける可能性があります。
- 納入している機器・ソフトウェアの製品名、型式、バージョン、再委託先の情報
- 障害やインシデントを検知した際の連絡ルートと連絡先
- 攻撃を受けた場合に提供できるログの種類と保管期間
- 脆弱性情報を把握した際の通知プロセス
- リモートアクセス用アカウントの認証方式と棚卸しの状況
いずれも「調べればわかる」ものではなく、「平時から整理していないと出せない」情報です。ここが残された期限までの実務のポイントになります。
届出・報告の準備で、実は一番効くのはログ
届出とインシデント報告は、性質の異なる作業に見えて、必要な材料は共通しています。
届出は、特定重要電子計算機の製品名・製造者名などを、システムの概略を示す資料とあわせて事業所管大臣に届け出るものです。施行時点で既に導入済みの機器は2027年3月31日まで、施行後に新規導入する機器は原則として導入日から4か月以内が期限とされています（出典：内閣府ほか「サイバー対処能力強化法に基づく特別社会基盤事業者による特定侵害事象等の報告等に関する制度の解説」）。つまり届出そのものは、資産台帳が正確であれば書き写す作業に近くなります。逆に台帳が古ければ、期限までの数か月を棚卸しに費やすことになります。
報告は「認知した時点」から数え始める
インシデント報告は、速報を速やかに（DDoS 攻撃は認知後可能な限り速やかに、ランサムウェアやその他の攻撃は認知から3〜5日以内）、詳報を認知から30日以内に提出します。報告先は事業所管大臣と内閣総理大臣です。国家サイバー統括室（NCO）が公開する統一様式（DDoS・ランサムウェア・その他の3種類）を使い、報告者の概要、業務への影響、影響を受けたシステム、攻撃の技術情報、対応方針を記載します。
ここで重要なのが、30日の起算点が「事象の発生」ではなく「事業者が認知した時点」であることです。報告対象には、マルウェアの実行や不正アクセス、業務妨害に加えて、特定重要設備そのものや同じセグメントの機器については、マルウェアの受信、不正アクセスの試行、認証情報の窃取といった兆候の段階も含まれます。
つまり、攻撃を認知した日から30日のあいだに、「いつ侵入され、どこまで広がり、何が持ち出された可能性があるか」を整理して報告することになります。制度の解説では、その時点で分からない事項は分かる範囲で書き、後から判明したことは続報で補うことも示されています。ただ、続報で補うにしても、説明の材料はログしかありません。
4か月前の侵入を、ログなしで説明できるか
アスクル株式会社が2025年12月12日に公開したランサムウェア攻撃の調査報告（第13報）は、この点を具体的に示しています。同社の報告によると、侵入は2025年6月5日、ランサムウェアによる暗号化は同年10月19日。攻撃者は約4か月のあいだ段階的に行動範囲を広げ、複数サーバーへのアクセスと権限昇格を進めていました。流出が確認された顧客・取引先などの情報は約74万件です。
侵入に使われたのは、業務委託先に付与していた管理者アカウントの ID とパスワードでした。このアカウントには、例外的に多要素認証を適用していなかったと報告されています。
そして調査報告には、次の記載があります。
- 侵害が発生したデータセンターのサーバーに EDR が未導入で、24時間監視も行われていなかった
- 当時のログが削除・消失しており、原因の完全な究明や閲覧された情報の範囲の特定が困難だった
- オンラインバックアップはあったものの、ランサムウェアを想定した環境ではなく、バックアップも暗号化・削除された
アスクルはサイバー対処能力強化法の対象事業者ではありませんが、認知してから30日で詳報を出すという要件に、この状態で向き合えるかどうかを考えてみてください。EDR のないサーバーで検知が遅れ、ログの一部も失われていると、侵入から4か月分の経緯を30日で説明しきるのは難しくなります。実際、同社は初期侵入の日付と使われたアカウントまでは特定したものの、認知から54日後の第13報の時点でも、そのアカウントの ID とパスワードがどのように漏れたのかと、攻撃者が閲覧した可能性のある情報の範囲は特定しきれていないと報告しています。
ログの取得状況を確認すべき箇所
AWS CloudTrail は、証跡を作成していない状態ではイベント履歴で直近90日分の管理イベントしか参照できず、データイベントも記録されません。長期保管には、証跡を作成して S3 バケットへ保存する設定が必要です。VPC フローログや ELB のアクセスログも、明示的に有効化していなければ記録が残りません。攻撃を認知してから「あのログは取っていましたか」と確認する流れになると、30日のうち数日がそこで溶けます。
もう一点、ログが分散していることも報告を遅らせる要因になります。インフラ、アプリケーション、認証基盤、ネットワーク機器がそれぞれ別のツールに記録を吐いている状態では、時系列を突き合わせるだけで工数がかかります。
優先順位を整理すると、次のようになります。
| 優先度 | 作業 | 理由 |
|---|---|---|
| 高 | ログの取得設定と保管期間の確認 | 後から遡って取得できない。今日設定しなければ今日の記録は残らない |
| 高 | 資産の棚卸し（製品名・型式・バージョン・委託先） | 届出の記載内容そのもの。期限は2027年3月31日 |
| 高 | 委託先アカウントの認証方式と例外運用の棚卸し | 侵入経路になりやすく、取引先からも問われる |
| 中 | ログの集約先の一本化 | 30日以内に詳報を書く際の時系列突き合わせの工数を左右する |
| 中 | 検知から報告までの連絡フローの明文化 | 部門をまたぐため、平時に決めておかないと動かない |
| 低 | ダッシュボード・可視化の作り込み | 上記が揃ってから着手すれば足りる |
支援の現場で見る、取ってあるのに使えないログ
KDDIアイレットは情報セキュリティの国際規格 ISO/IEC 27001 と、クラウドサービス向けの ISO/IEC 27017、IT サービスマネジメントの ISO/IEC 20000-1 を取得しています。あわせて2025年10月には、AI マネジメントシステムの国際規格である ISO/IEC 42001 の認証を取得しました（認証登録日：2025年10月15日、参考：AI マネジメントシステムの国際規格「ISO/IEC 42001」を取得）。
セキュリティ事業部で、お客様のログ基盤やセキュリティ対策の導入を支援している田邊は、現場の状況を次のように話します。
「ログは取ってあるだけでは使えません。探せて、時系列に並べられて、初めて説明の材料になります」
田邊がお客様の環境で目にするのは、ログ自体は取っているのに、置き場所と形式がシステムごとに違い、時刻の表し方もそろっていない状態です。キーワードで探すしかなく、調べたいことにたどり着けないこともあります。必要になったときには、既定の保持期間を過ぎて消えている場合もあります。こうした状態に気づくのは、インシデントの調査で、いつ何が起きたのかを追おうとしたときです。
認知から30日で詳報を出すには、ログが取れているだけでは足りず、調べたいときに探せて、時系列で突き合わせられる状態にしておく必要があります。そのため田邊は、取得の設定を確認したあと、ログを1か所に集めて、同じ形で検索できるようにしておくことを勧めています。
ログを1か所に集めて調べる。Google SecOps の場合
前の節で書いたとおり、ログが分散していると、時系列を突き合わせるだけで工数がかかります。この手間を減らす方法の1つが、ログを1か所に集めて検索できる基盤です。KDDIアイレットは、その基盤として Google Security Operations（Google SecOps）の導入を支援しています。
Google SecOps は、CloudTrail、VPC フローログ、ELB、WAF、Microsoft Entra ID のサインインログなどを、標準のパーサー（ログを読み取って項目に分ける仕組み）で取り込みます。取り込むときに UDM（統合データモデル）という共通の形式にそろえるので、形式の違うログも同じ項目名で検索できます。
取り込んだログは標準で12か月保持され、最長5年まで延ばせます。アスクルの事例で、侵入から暗号化まで約4か月かかったことを考えると、さかのぼれる長さは足ります。ただし、取り込む前に消えたログは調べられないので、ステップ1で取得の設定を確認したら、早めに集め始める必要があります。
届出期限までの3ステップ
ステップ1. ログの取得設定を確認する（所要1日）
まず確認するのは、以下の4点です。
- CloudTrail の証跡が全リージョンを対象に作成され、S3 に出力されているか。保管期間は何日か。保管先は改ざん・削除から保護されているか（S3 オブジェクトロックや別アカウントへの集約など）
- VPC フローログ、ELB アクセスログ、WAF ログが有効になっているか
- OS・ミドルウェア・アプリケーションのログがどこに出ているか。EDR の監視対象外のサーバーが残っていないか
- 認証基盤（Microsoft Entra ID など）のサインインログが保管されているか
- Entra ID のサインインログは既定で最長30日（無料版は7日）しか残らないため、ストレージなどへ転送する設定まで確認する
取れていないものが見つかったら、その場で有効化します。過去には遡れませんが、明日以降の記録は残ります。報告義務は既に発生しているため、この確認を後回しにする理由はありません。あわせて、ログの保管先やバックアップを管理者権限でも削除・変更できない状態にしておくことも重要です。T'sファーマ株式会社様の事例では、AWS Backup の Vault Lock 機能で管理者でも削除・変更できないバックアップ環境を構築し、ランサムウェア対策を強化しています（参考：T'sファーマ株式会社様 導入事例）。
ステップ2. 資産台帳を届出項目に合わせて作り直す（所要は台帳の状態により数週間〜数か月）
届出で求められるのは、製品名、製造者名、システムの概略を示す資料などです。バージョン情報や資産の管理主体（委託先など）は任意記載ですが、政府から絞り込んだ脆弱性情報を受け取るためにも記載が推奨されています。なお、アプライアンス以外の機器は OS・ミドルウェア・アプリケーション単位での届出となり、Windows と Windows Server は汎用品として届出不要とされています。既存の資産管理台帳がある場合も、この粒度で情報が揃っているかを確認します。特に抜けやすいのが、再委託先を含む委託関係と、機器・ソフトウェアのバージョン情報です。制御系システムからクラウドへデータを連携している構成は、制度の解説でもシステム概略図の典型パターンとして示されており、接続口となる機器やクラウドサービスを含めて洗い出す必要があります。
あわせて、委託先に発行しているリモートアクセス用アカウントを洗い出し、多要素認証が適用されているかを確認します。「運用上の例外」として残っているアカウントは、侵入経路になりやすい箇所です。
期限は2027年3月31日。残りは半年足らずですが、棚卸し自体に数か月かかるため、着手していなければ今が最後のタイミングになります。
ステップ3. 検知から報告までの連絡フローを1枚にまとめる（所要1週間）
誰が検知し、誰が判断し、誰が事業所管大臣と内閣総理大臣に報告するのか。この流れを1枚の図にします。個人情報保護法や業法に基づく報告も並走するため、それぞれの期限と様式を同じ図に書き込んでおきます。情報システム部門だけで完結せず、法務・広報・経営層をまたぐため、平時に決めておかないと動きません。
3つのステップに共通するのは、いずれも「ツールを買う前にできる」ことです。
よくある質問
Q. 15分野に該当すれば、自動的に届出義務が生じますか。
いいえ。分野への該当と、事業者としての指定は別です。経済安全保障推進法の基幹インフラ制度で主務大臣から指定を受けた事業者が対象となり、その数が2026年7月1日時点で258事業者です。自社が指定を受けているかは、所管省庁からの通知のほか、内閣府が公表している指定事業者一覧でも確認できます。
Q. インシデント報告の期限は何日以内ですか。
速報は認知後に速やかに（DDoS 攻撃は可能な限り速やかに、ランサムウェアやその他の攻撃は3〜5日以内）、詳報は認知から30日以内です。報告先は事業所管大臣と内閣総理大臣になります。30日の起算点は事象の発生日ではなく、事業者が認知した日です。
Q. 10月1日を過ぎてしまいましたが、今から何をすべきですか。
報告義務は既に発生しているため、まずログの取得状況を確認してください。これは1日で終わります。そのうえで、2027年3月31日の届出期限に向けて資産の棚卸しに着手します。順序を逆にすると、棚卸しの最中にインシデントが起きた場合に報告が書けません。
Q. 対象事業者ではない取引先ですが、何を準備すべきですか。
納入している製品の型式・バージョン・再委託先の一覧、インシデント時の連絡先と連絡ルート、提供できるログの種類と保管期間の3点です。あわせて、自社が預かっているリモートアクセス用アカウントの認証方式も確認しておくべきです。これらは取引先から照会を受ける可能性が高く、答えられない状態は取引条件の見直しにつながる場合があります。
Q. 政府が攻撃元のサーバーを無力化する仕組みはもう動いていますか。
はい。整備法による警察官職務執行法・自衛隊法の改正が2026年10月1日に施行され、警察と自衛隊によるアクセス・無害化措置が可能になりました。実施には原則としてサイバー通信情報監理委員会の事前承認が必要です。一方、攻撃サーバー等を検知するための通信情報の利用に関する規定（第3章〜第7章）は2027年11月22日まで（政府資料では2027年秋）の施行予定で、まだ動いていません。
まとめ
サイバー対処能力強化法の届出と報告の義務などの規定は2026年10月1日に施行され、15分野258事業者のインシデント報告義務は既に発生しています。次の期限は2027年3月31日の届出です。
- 自社が直接の対象なら：ログの取得状況を今日確認し、資産の棚卸しを2027年3月31日から逆算して進める
- サプライチェーン側なら：製品情報・連絡フロー・提供可能なログ・委託先アカウントの認証方式の4点を整理しておく
- どちらの場合も：詳報の期限は認知から30日。その30日で説明できる材料があるかどうかが分かれ目になる
やることは「取る」「揃える」「決める」の3つです。ツールの選定はその後で構いません。
KDDIアイレットでは、セキュリティ設計から運用監視、ログの収集・分析までを一貫して支援しています。ログの取得状況が分からない、何から手をつけるべきか整理したい、という段階からのご相談も承ります。
Google AI Threat Defense 導入支援サービス（構成要素の Google Security Operations で、CloudTrail、VPC フローログ、ELB、WAF、Microsoft Entra ID のサインインログなどを1か所に集めて検索できます。ログは標準で12か月保持。設計・導入を伴走支援）
インシデント対応サービス（インシデント発生直後の対応から、対応力強化の仕組みづくりまで支援）
AWS アカウント診断サービス（AWS 環境のセキュリティ設定を低コストで診断）
Google Cloud プロジェクト診断サービス（情報漏洩などのインシデント発生を防ぎ、セキュアな運用を支援）
ページ監修者
インフラエンジニアとしての経験を土台に、クラウドセキュリティとブラウザセキュリティを中心に活動。クラウド基盤を構築・運用する視点を活かし、実運用に即したセキュリティに取り組む。
旅行と温泉が好き、各地の湯処を巡る。