サイバー対処能力強化法で激変するインシデント対応〜システム運用の現場に求められる備えとは？【CTCシステムマネジメント様勉強会レポート】

2026年9月15日、CTCシステムマネジメント株式会社の社内セミナーに、弊社代表の金築 敬晃が登壇しました。テーマは、2026年10月1日から主要部分が施行される「サイバー対処能力強化法」です。

同法では、直接の対象となる特定社会基盤事業者だけでなく、そのシステム開発や運用を支えるIT企業にとっても実務上の大きな影響が及ぶと見られています。 そこで本記事では、法施行によってインシデント対応がどう変わるのか、システム会社が優先すべき準備、そして現場の課題を支える「Incident Lake」の役割について、講演内容をもとに紹介します。

システム会社も他人事ではない～サイバー対処能力強化法の影響

サイバー対処能力強化法を巡る報道では、通信情報の取得や攻撃元サーバーの無害化など、「能動的サイバー防御」に注目が集まっています。しかし、民間企業の実務に大きく影響するのは、むしろ「官民連携」の部分だと、金築は指摘します。

具体的な変化は2点あります。まず情報資産の届出が義務化される点です。自社がどのような情報資産を保有し、そのうち何が重要なのかを国に届け出る必要があります。また、届出内容に変更があった場合には、改めて届出が必要です。

次に、認知を起点とした報告義務です。従来、DDoS攻撃やランサムウェアなどのインシデントでは被害確定後の報告が中心でした。しかし今後は「インシデントが生じた可能性を認知した時点」から報告義務が発生します。加えて、従来のインシデントレポートの様式や報告基準は、各社・各チームに委ねられていました。しかし、同法の施行後は、対象事業者に対し、DDoS攻撃やランサムウェアを認知した時点から報告義務が生じます。報告様式も定められており、発生を認知してから数日以内に、所定の形式で報告することが求められます。

同法の直接の対象となる「特定社会基盤事業者」は、電気、水道、ガス、通信、金融、鉄道など、国民生活や経済活動を支える全国258社に限られています。しかし、こうした事業者のシステムは一社だけで成り立つものではありません。重要インフラ事業者に法的な届出義務や報告義務が発生する場合、当然ながらそのIT実務を担う委託先のシステム会社に対しても、同等の基準に沿った運用と迅速な情報提供が求められることになります。さらに、サプライチェーン攻撃では、比較的守りの弱い取引先が侵入の踏み台にされる恐れがあります。このように、同法はシステム開発・運用を担うIT企業に、大きな影響をもたらすのです。加えて金築は、将来的に同法の対象が拡大する可能性も指摘します。施行後3年を目途とする制度の見直しが予定されており、過去の法改正の通例に照らし合わせても、一定規模以上の民間事業者へ対象が拡大されることは十分に考えられます。したがって、現在は直接の対象外であっても、早期に制度への理解と準備を進めておく必要があると、金築は訴えます。

違反企業には刑事罰も！システム会社が優先して取り組むべき実務対応とは？

ここからは、インシデント対応のライフサイクルに沿って、「準備」「検知・対応」「封じ込め・復旧」「事後活動」の各フェーズにおける変化を解説します。

1. 準備

最初の義務は、資産の届出です。対象事業者は、サーバー構成やデータベースに使用している機器の製品名・型番などを事業所管大臣に届け出る必要があります。導入時だけでなく変更時にも届出が必要です。経過措置として、施行時に導入済みの機器は2027年3月31日まで、新規導入・変更の場合は原則4カ月以内の届出が求められます。違反すると是正命令の対象となり、従わない場合は200万円以下の罰金が科されます。重要な点は、これが刑事罰を伴う法的義務であり、違反すれば企業のレピュテーションリスク（風評被害）をもたらしかねないことです。

届出の対象は基幹システムだけではありません。ファイアウォール、VPN機器、認証サーバー、物理的なキーなども広く対象となります。こうした情報資産を漏れなく台帳化し、常に最新の状態を維持する運用が必要です。

複数の会社がシステムを分担して管理している場合は、全体像の把握も課題になります。例えば、A社が顧客管理データベース、B社が在庫管理データベースを担当していれば、個別の構成を把握していても、システム間の依存関係までは疎かになっている可能性があります。資産を正確に届け出るには、こうした依存関係を含むシステム全体を把握・管理することが、事業者と受託側の双方に求められます。

2. 検知・分析

検知・分析の段階で最も大きな変化は、報告義務の起点です。サイバー対処能力強化法では、被害の確定や調査の完了ではなく、インシデントを認知した時点から報告義務が生じます。そのため、実害が確認されていない段階でも報告対象となる可能性があるのです。

インシデント対応は、アラートの発生を起点に始まります。その後、インシデントか単なる誤検知かを判断するトリアージを行います。この時点でインシデントが発生している可能性が高いと認知した場合、本格的なインシデント対応が始まりますが、同時に法的な報告義務も発生するのです。ただし、ランサムウェアのように明確なアラートが出ず、数カ月後にシステムの遅延や不審な痕跡から侵入が発覚するケースもあります。この場合は、異変を認知した時点から報告期限のカウントが始まります。

従来は、トリアージ後の対応を中心に手順を定め、初期判断を特定の担当者に委ねている組織も少なくありませんでした。今後はトリアージを迅速かつ一定の基準で行い、その判断を記録できる体制が重要になります。

注意が必要なのは、SOC（Security Operation Center）やMDR（Managed Detection and Response）などの委託先と事業者の間で「認知」の基準が異なる場合です。委託先が様子見と判断しても、報告義務を負うのは事業者側であり、情報共有の遅れが報告漏れや遅延につながる可能性があります。特に複数社が関わる大規模なプロジェクトでは、このようなリスクが高まります。そのため、運用を受託する側には、顧客と認知基準をすり合わせること。そして、調査が完了していない段階でも重要な兆候を速やかに共有できる仕組みを、契約と運用の両面で整えておくことが求められます。

3. 封じ込め・復旧

封じ込め・復旧の段階では、自社だけでなく、取引先が攻撃の踏み台となるケースも想定する必要があります。直接の規制対象ではない企業でも、サプライチェーンを通じて基幹インフラ事業者に影響を及ぼす可能性があれば、将来的に報告などの対応を求められる可能性があります。

4. 事後活動

事後活動でも、業務の進め方は変わります。報告書では、事案の概要や発生経緯、影響を受けた機器、システムの稼働状況、攻撃に関する技術情報などを整理する必要があります。なかでも作成負荷が高いのが、影響範囲とタイムラインです。

SlackやTeamsのスレッド、個人メモ、チケットに情報が散らばっていれば、対応を続けながら報告書の材料を集め直さなければなりません。一方、検知時刻、認知時刻、判断、措置、影響範囲などを対応しながらまとめておけば、その記録を整理するだけで報告書をまとめることができます。

こうした記録は、法令対応のためだけのものではありません。類似障害が起きた際に過去の判断や手順を検索できれば、封じ込めと復旧の迅速化にもつながります。つまり報告書は、対応が終わってから儀式的に作るものではありません。対応中に記録を残し、次の対応と再発防止に使える資産にしていく必要があるものです。

最優先は、インシデント記録の棚卸しとトリアージ基準の文書化

これらの法対応はいずれも必要ですが、すべてを一度に整備するのは容易ではありません。そこで、金築は企業が最優先で取り組むべき準備を、次の2点に絞り込みます。

(1)資産台帳とインシデント記録をつなげる
過去のインシデント記録が断片的にしか残っていない場合は、まず棚卸しを行い、どの情報資産でどのようなインシデントが発生したのかを整理する

(2)「認知」の定義とトリアージの基準を文書化する
特定の担当者に頼らず、誰でも一定の基準で判断できる仕組みを整える

まずこれらに優先的に対応したうえで、今後1年程度を掛けて、以下のポイントに対応することを金築は勧めます。

(3)対応タイムラインを自然に残す
対応の最中に人が記録を残そうとしても、いつ検知し、認知し、どのような判断を下したのかが抜け落ちやすいため、できる限り自動化することが重要

(4)当局報告をインシデント指揮体制と訓練に組み込む

(5)委託先・グループ会社との報告フローを、契約と運用の両面で設計する

インシデント記録の自動化がなぜ重要なのか？

現在のインシデント報告は、自社や部署ごとに独自のフォーマットを用い、記載する項目や情報の粒度、対応速度について明確な基準がないケースが少なくありません。しかし今後は、国が定めたフォーマットに沿って報告する必要があります。特に重要なのが「影響範囲」と「タイムライン」です。

影響範囲については、届け出た重要資産のうち、どの範囲が影響を受けているのかを記載します。タイムラインについては、誰がいつ検知し、どのような対応を行ったのかを記録する必要があります。報告までの時間も、検知した時点を基準に考える必要があります。ランサムウェアの場合は検知から3〜5日以内、DDoS攻撃の場合はなるべく速やかな報告が求められます。さらに速報を提出した後に、詳細なレポートを30日以内に提出する必要もあります。

ここで注意したいのが、休日や長期休暇中の対応です。例えば連休直前の深夜にインシデントが発生して、対応作業の長期化や報告の遅延が起きれば、それだけで期限を超えてしまう可能性があります。そのため、夜間や長期休暇中でも記録を止めない体制が必要です。

とはいえ、記録を残すことや当局対応の必要性は分かっていても、実際にどう対応するかは別の問題です。現場に目を向けると、インシデント対応には属人化という根深い課題があります。

SIGQが2026年に実施した実態調査では、インシデント対応の72％が特定の個人に依存し、89％の組織がキーパーソンの離脱を事業リスクとして認識していることが明らかになりました。そんな中で、チャットや個人メモに記録が散在する状況を放置すれば、誰が何を判断し、どのような対応を行ったのかという記録が失われてしまいがちなのは当然です。

「対応しながら記録を残す」を仕組み化するIncident Lake

こうした課題を解決するためにSIGQが提供しているのが、インシデント対応プラットフォーム「Incident Lake」です。Incident Lakeは、現場が使い慣れた運用監視ツールを置き換えるのではなく、その上に「AIレイヤー」を重ねることで、既存の業務フローを生かしながらインシデント対応を支援します。

具体的には、AIエージェントがTeamsやSlackなどのチャットと直接連携し、インシデント対応に関するやり取りを自動的に集約します。検知・認知した時刻や、その後の判断、実施した措置を時系列で記録するとともに、チャットや社内ツールに分散した情報をAIが横断的に整理し、現在の状況を要約します。また、構成管理データベースとの連携により、影響範囲の特定も支援します。インスタンスやシステム間の依存関係を図で可視化し、障害が発生した際に、届け出た重要資産のうち、どこまで影響が及んでいるのかを速やかに把握できます。さらに、インシデント対応で属人化しやすいトリアージや担当者の選定もAIが支援します。人によって判断が分かれやすい重大度の判定を支援するほか、他の運用監視ツールなどに蓄積された過去のデータを分析し、対応経験のある担当者を推薦したり、類似したインシデントとその解決策も提示することも可能です。

報告書の作成についても、サイバー対処能力強化法で定められた必須項目に対応するテンプレートを用意しています。AIエージェントが状況を整理して対応方針や報告書のドラフトを作成し、人間がその内容をレビューして承認することで、担当者が休暇や不在の場合でも迅速に対応できる仕組みです。

検証可能な記録が、企業の事業継続と信頼を支える

最後に金築は、サイバー対処能力強化法への対応を単なる法令遵守で終わらせるのではなく、インシデント対応の属人化を解消し、組織全体の対応力を高める契機にすべきだと総括しました。

インシデントへの対応を進めながら、その過程を検証可能な記録として自然に残せる体制を整えること。それが法令遵守だけでなく、自社の事業継続性や社会的な信頼を守り、サプライチェーン全体のセキュリティを高めることにもつながります。