執筆者：CDO 髙𫞎 則行
前回、CFOの永見が「災害時に役立たない安否確認。なぜ社内の連絡先データは年22.5%以上劣化し、有事に沈黙するのか？」について書きました。
今回は、その裏返しとして「有事に効くログを持っているか」について書きたいと思います。
この夏、いくつか制度に関する文書が公表されました。読んで最初に思ったのは、「10月から義務化されます」という一文が、そのままでは誤りだということでした。義務になるものと、ならないものが、同じ日に、別々の文書で動き出します。ここを混ぜたまま投資判断をすると、必要のない急ぎ方をして、必要な備えを落とします。
1. セキュリティに関する、二つの文書
一つ目は、重要インフラのサイバーセキュリティ対策のための統一基準です。2026年7月31日にサイバーセキュリティ戦略本部が決定し、附則で「令和8年10月1日から施行する」と定められています[1]。サイバーセキュリティ基本法第25条第1項第3号に基づくもので、名前のとおり「統一的な基準」を定める文書です。
二つ目は、サイバー対処能力強化法（正式には「重要電子計算機に対する不正な行為による被害の防止に関する法律」、令和7年法律第42号）のうち、官民連携に関する部分です。施行期日を定める政令によって、2026年10月1日に施行されます[2]。資産の届出と、インシデントの報告が、ここで動き出します。
同じ日ですが、性格がまったく違います。前者には罰則がなく、事業者に対する直接の義務もありません。後者には罰則があります。
この記事では、まず何が義務ではないのか（統一基準）を整理し、次に何が義務なのか（強化法）を確認します。そのうえで、義務は軽いのに実装は重い、という一点に降りていきます。ログの保全です。
2. 三階建てとして読む
統一基準を「10月から守らなければならないルール」と読むと、話が合わなくなります。この文書は、政府機関が実施する施策についての統一的な基準であり、事業者への規範は所管省庁等が策定する「安全基準等」を経由して及ぶ建付けになっています。
三階建てだと思うと、整理がつきます。
1階：統一基準（2026年7月31日決定、10月1日施行） その第3部の見出しは「安全基準等において規定されるべき事項」です。つまり、基準の基準です。ここに罰則はありません。
2階：安全基準等策定ガイドライン（案） 正式には「重要インフラのサイバーセキュリティに係る安全基準等策定ガイドライン（案）」といいます。内閣官房 国家サイバー統括室が、所管省庁等——重要インフラ所管省庁と各分野の業界団体等——が安全基準等を策定するに当たって参照するための詳細事項を書いたものです。2026年8月5日に公示され、8月26日に意見募集が締め切られました（案件番号060260805）。本稿執筆時点（2026年9月2日）で、確定版もパブリックコメントの結果も公表されていません[3]。位置づけは参照資料であって、内容を必ず盛り込まなければならないものではありません。
3階：各分野の安全基準等（省令・業界基準） 規範的な拘束力が生まれるのは、ここに落ちてからです。 統一基準は、旧来の「安全基準等策定指針」を再構成・更新したものだと政府の資料は説明しています[4]。その旧指針をどう扱うのかについて、7月31日の決定文書に廃止の規定は見当たりませんでした。そして、分野別の安全基準等をいつまでに改定するかについても、決定文書に日付の規定は見当たりません。
ただし、この三階建ての外に、もう一本の系統があります。監督指針の系統から出ている文書です。例えば、金融分野では、2024年10月の金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」が、2.3.4.2で「ログの改ざん防止」をすでに求めています[5]。重要インフラの「安全基準等」とは別の建付けですが、従わなければ監督上の対応があり得るという点では、罰則より早く効きます。
実際、金融機関の現場では、監査ログを本番データベースの外に保管したうえで、保管された側には運用として誰も手を触れられないようにする、という実装を何度も目にしてきました。制度の議論が始まる前から、そこでは動いています。分野によっては、要求はすでに言葉になっています。 しかも同じガイドラインは「基本的な対応事項」と「対応が望ましい事項」を区別しています。何が求められていて何がそうでないかという区別を、金融庁は2年前にやっているわけです。
もう一つ、10月1日から変わることがあります。重要インフラの対象分野が15分野から16分野になり、郵便が加わります。あわせて「政府・行政サービス」が「行政サービス」に改称されます[6]。本稿執筆時点ではまだ15分野で、10月1日から16分野です。
3. 義務になる側 ―― 届出と報告
罰則を伴う義務は、強化法の側にあります。
対象は特別社会基盤事業者です。この法律に独自の指定制度があるわけではなく、経済安全保障推進法で指定された特定社会基盤事業者のうち、特定重要電子計算機を使用する者が該当します（法第2条第3項）。特定社会基盤事業者は、2026年7月1日時点で258者が指定されています[7]。
届出（法第4条）。特定重要電子計算機を導入したとき、製品名・製造者名などを所管大臣に届け出ます。期限は法律本文ではなく、8府省共同の命令に書かれています。導入または変更から4か月以内です[8]。施行の直後に導入するものについては、命令の附則で「この命令の施行の日から六月以内」と読み替える経過措置が置かれています。施行日が10月1日ですから、2027年3月31日までの猶予です。
報告（法第5条）。ここで一つ、押さえておくことがあります。報告そのものは、10月1日に始まるわけではありません。 DDoS攻撃とランサムウェア事案については、2025年10月から共通様式の運用が先行していて、所管省庁・個人情報保護委員会・警察・国家サイバー統括室への報告はすでに一元化されています[9]。10月1日に加わるのは、その報告に法律の裏付けと是正命令の系統が付くこと、そして届出という新しい行為の方です。
そのうえで、法第5条です。特定侵害事象等の発生を認知したとき、所管大臣と内閣総理大臣に報告します。命令第4条第2項は、認知後速やかに速報を、認知した日から30日以内に詳報を提出する、と定めています。報告事項は7号あり、そのうち第5号が「特定侵害事象等に関する技術的な事項」です。報告の対象となる事象には、他人の識別符号を用いた不正アクセス、接続された他の電子計算機を経由した侵害、そして他人の識別符号が取得される事象が挙げられています。認証情報を盗まれたこと自体が報告対象になる、ということです。
罰則の構造は、少し込み入っています。 届出や報告を怠ったことに対する直罰はありません。所管大臣が是正命令を出せる（法第6条）ことになっていて、その命令に従わなかったときに初めて罰金が科されます。内閣官房 国家サイバー統括室の説明資料によれば200万円以下の罰金、資料提出等の求めに応じない場合は30万円以下の罰金です[10]。
なお、この法律には「2年以下の拘禁刑又は100万円以下の罰金」という条文もありますが、これは第82条で、行政職員や協議会構成員が秘密を漏らしたり盗用したときの罰則です。事業者の報告義務違反に対するものではありません。私も当初これを取り違えていました。
4. 30日以内の報告、事前に何を取得していたかで決まる
報告期限を各国と並べると、日本の位置がはっきりします[11][12]。
| 制度 | 第一報 | その後 | 最終・詳細 |
| 日本・サイバー対処能力強化法 | 認知後「速やかに」（時間数の指定なし） | — | 認知から30日以内に詳報 |
| 日本・個人情報保護法（既存） | 速報「速やか」（目安は概ね3〜5日以内） | — | 確報30日以内（不正アクセス等は60日以内） |
| EU・NIS2 第23条 | 24時間以内に早期警告 | 72時間以内にインシデント通知 | 通知から1か月以内に最終報告 |
| EU・DORA | 重大と分類してから4時間かつ認知から24時間以内 | 初報から72時間以内に中間報告 | 中間報告から1か月以内 |
| 米国・SEC Form 8-K Item 1.05 | 重要性の判断から4営業日 | — | — |
| 米国・CIRCIA | 72時間以内（身代金支払は24時間以内） | — | 最終規則が未公表のため義務は未発効 |
第一報を時間数で切っていないのは、この中では強化法だけです。ただし国内には、目安を持った制度がすでにあります。 個人情報保護法の漏えい等報告は、速報を「速やか（概ね3〜5日以内）」とし、確報を30日以内、不正アクセス等の場合は60日以内としています。つまり強化法の詳報30日は、国内の確報に揃えたと読むのが自然です。そして同じ事故で、両方の報告が走ります。「システムの停止」と「個人情報の漏えい」は別の判定軸だからです。
ここで実務の話になります。詳報には「技術的な事項」を書きます。侵入経路や手口に相当する内容です。これは事後に取りに行けません。 攻撃を認知した後で「あの日、あのアカウントが、どのデータにどうアクセスしたか」を調べようとして、ログが90日で消えていた、監査は主要なテーブルにしか設定されていなかった、SELECTは取っていなかった、という状態は珍しくありません。
30日という期限は、報告書を書く時間の話に見えて、実際にはその30日より前に何を保全していたかの話です。締切が守れるかどうかは、事前準備にかかっています。
そして、ここで二つの文書が合流します。強化法が出しているのは「30日で技術的な事項を書け」という時間の要求です。統一基準が出しているのは「ログが改ざん、消去されないよう管理せよ」という設計の要求です。別々の文書から出た二つの要求は、同じ一点に落ちます。事前にログを取り、守っておくことです。ここから先は、その一点の話をします。
5. 条文の2行が、データベースの現場で意味すること
1階に戻ります。統一基準の中に一つ、実装の重さと制度の軽さが釣り合っていない箇所があります。3.4.5「ログ取得」です。
① 情報システムのイベントログや運用担当者の作業ログ等、セキュリティの確保に必要なログを記録・管理する。
② ログが改ざん、消去されないよう管理する。
この2行です。しかし②を、データベースの中だけで満たすことはできません。
Oracleの統合監査は、この点をよく設計しています。監査証跡の実体であるAUD$UNIFIED表はAUDSYSスキーマにあり、INSERTしか許されません。直接TRUNCATE・DELETE・UPDATEを試みても失敗し、しかもその試行自体が監査記録として残ります。AUDSYSはディクショナリ保護されていて、ANY系の権限を持っていても手を出せず、そもそも誰もログインできません。監査データの削除は例外なく監査されます[13]。
それでも、消せます。AUDIT_ADMINロールを持つ利用者は、正規の手続きで監査証跡を変更し、古い監査データをパージできます。そしてSYSはこのロールを持っています。だからOracle自身が、ベストプラクティスとして「ローカルには必要最小限の監査データだけを残し、ソースDBの外の専用リポジトリへ移送する」ことと、AUDSYSスキーマをDatabase Vaultのrealmで囲むことを推奨しています[14]。
PostgreSQL側はもっと率直です。pgAuditは監査記録を標準のログ機構、つまりOS上のサーバログに書きます。そしてプロジェクト自身のドキュメントに、こう書かれています。「It is not possible to reliably audit superusers with pgAudit.」設定を変更できるのもスーパーユーザーだけです[15]。
つまり、「ログが改ざん、消去されないよう管理する」を満たそうとすると、ログをそれが生まれた場所の管理者の手が届かないところに置くという設計判断が要求されます。制度の側は2行しか書いていません。しかし、この2行を満たそうとすると、実装ではアーキテクチャの変更に行き着きます。
これは、規格の世界では以前から言われてきたことでもあります。ISO/IEC 27002:2022の8.15について、認証機関の解説は「自分が管理するシステム内のログには、特権利用者であっても手を触れられないようにすべき」という趣旨で説明しています[16]。一方で、ログ管理の技術ガイダンスの本家であるNISTのSP 800-92は2006年版が現行で、2023年10月に出た改訂草案は3年近く草案のままです[17]。この分野の制度整備は、思っているほど速く進んでいません。
6. 当社は、どこまで手を付けているか
こういう記事を自社サイトに書くと、最後は自社製品の宣伝になりがちです。誠実に、手を付けているところと、まだ付けていないところを、書きたいと思います。
データの棚卸しは、実績のある段階です。 Insight Catalogで、どのデータベースのどのテーブルに何があるかを可視化し、あわせて暗号化の実装状況を可視化する取り組みを進めています。暗号の実装状況の棚卸し（クリプトインベントリ）については、金融分野での実証にこれから入ります。CBOM形式での出力までを範囲に含めたものです。PDFやOffice文書、ログファイルといった非構造化ファイルの中の個人情報検知への拡張は、まだβの段階です。
監査ログについては、この1年、開発の中心は「保全」よりも「取得範囲の拡大」にありました。 マネージドデータベースの監査ログへの対応、対象外のデータベースについては標準監査ログをCSVで取り込む経路、Oracleに直接ログインしてエージェントを置かずに統合監査ログを取得する方式、複数の製品からのログを統合フォーマットに揃える設計。取れていなかったものを取れるようにする開発です。
改ざんに対する当社の現在の答えは、職務分掌による防御です。データベースから独立した基盤にログを収集し、データベースの管理者が消せない位置に置く。前節で書いたOracle自身の推奨と同じ考え方で、これは制度の要求に対して有効な答えだと考えています。
一方で、ハッシュチェーンや署名によってログそのものが改変されていないことを暗号学的に証明する仕組みについては、当社はまだ「プロトタイプ」段階です。保存先の候補として列指向データベースの評価や、独自エンジンの開発も進めていますが、まだ途上です。取れる数字が揃ったら、外部の場で実測値を出したいと考えています。
ちなみに当社は、データベースの移行検証に関する特許を保有しています（特許第7295541号、2023年6月13日登録）。監査のために取りたいログと、移行検証のために集めたいワークロードは、同じものです。 制度対応のために入れるログ収集装置は、そのまま次の更改の入力になります。
そして、この一致は机上の話ではありません。Oracleは2026年5月28日から、四半期ごとのCritical Patch Updateを補完する月次のCritical Security Patch Updateの提供を始めました[18]。AnthropicがClaude Mythos——サイバーセキュリティと生物学研究に強い、審査を経た利用者にのみ提供される制限付きのモデルです——を出して以降、脆弱性の発見と修正の供給は明らかに速くなりました[19]。速くなって追いつかなくなったのは、利用側の検証工程の方 です。実際、直接のお客様からも、代理店を通しても、「毎月当てるとして、検証をどう回せばいいのか」という相談を複数いただくようになりました。本番で流れたSQLを記録してあれば、それを新しい環境で再生して突き合わせられます。守りのために入れたログが、攻めの工程を回す入力になります。
私たちも「規制される側」に回る
最後に、供給者としての話を書きます。
安全基準等策定ガイドライン（案）の2.9、サプライチェーン・リスクマネジメントは、「講ずべき対策事項」として、契約書等に明記する項目の例を挙げています[3]。その中にこう書かれています。
インシデント又はサービス障害発生時の対応及び報告（通知・報告する事象の種類、通知方法、事象発生から通知までの時間等を含む。）
当社は重要インフラ事業者の供給者です。そして、供給者として名前が載ること自体は、すでに始まっています。2024年5月に施行された経済安全保障推進法の届出制度では、導入等計画書に、設備の供給者に関する事項——名称、設立の準拠法の国、議決権の保有者、役員の国籍といった事項——を記載する欄が設けられています[20]。
10月1日から加わるのは、時限付きの通知義務のほうです。この条項が分野別の基準に落ち、顧客の調達要件になれば、私たちは「事象の発生から何時間以内に知らせるか」を契約で決められる側になります。自社のCSIRTの体制、SaaS版での責任分界、更新契約の条件。売上の機会ではなく、コストとリスクの話です。
そして、制度がここから先に効いてくる経路は、罰則ではなく契約と調達だと思っています。統一基準に罰則はありませんが、分野別の基準は追って固まってくるでしょう。それに伴って、顧客のRFPに条項が一行入れば、実装は動きます。「義務ではない」ことと「要求されない」ことは、まったく別です。
10月1日は締切ではありません。要求が言葉になった日です。もっとも、分野によっては、すでに言葉になっていて、実行に移されていました。10月1日は、それが全分野に広がる起点です。何が義務で、何がまだ義務でないかを正確に区別したうえで、自分の判断で先に動くかどうかを決める。その材料として、この記事が役に立てば幸いです。
出典
[1] 重要インフラのサイバーセキュリティ対策のための統一基準（2026年7月31日 サイバーセキュリティ戦略本部決定、2026年10月1日施行）。本文で引用した3.4.5「ログ取得」は第3部 3.4（防御）にあります。 https://www.cyber.go.jp/pdf/policy/infra/jyuhurakijun_2026.pdf
[2] 重要電子計算機に対する不正な行為による被害の防止に関する法律（令和7年法律第42号、2025年5月23日公布） https://laws.e-gov.go.jp/law/507AC0000000042 施行期日を定める政令（令和8年政令第46号） https://www.cao.go.jp/cybersecurity/pdf/sekoukijitsu.pdf 10月1日に施行される範囲については「サイバーセキュリティ2026」（2026年7月31日 サイバーセキュリティ戦略本部） https://www.cyber.go.jp/pdf/policy/kihon-s/cs2026.pdf
[3] 重要インフラのサイバーセキュリティに係る安全基準等策定ガイドライン（案）（内閣官房 国家サイバー統括室）。意見募集は案件番号060260805、公示2026年8月5日、締切2026年8月26日。本文で引用した2.9（サプライチェーン・リスクマネジメント）は「講ずべき対策事項」に置かれています。本稿執筆時点で確定版は公表されていません。 https://public-comment.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=060260805&Mode=0 https://public-comment.e-gov.go.jp/pcm/download?seqNo=0000318964
[4] 内閣官房 国家サイバー統括室「重要インフラ統一基準等の検討について」（重要インフラサイバーセキュリティ研究会 資料） https://www.cyber.go.jp/pdf/council/cs/cip_suishin/cip_cs_kenkyu/dai03/03_shiryou03.pdf
[5] 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月4日）2.3.4.2 https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf
[6] 「重要インフラのサイバーセキュリティに係る行動計画」の一部改定について（2026年7月31日 サイバーセキュリティ戦略本部決定、2026年10月1日施行） https://www.cyber.go.jp/pdf/policy/kihon-s/260731decision3.pdf
[7] 内閣府「経済安全保障推進法の特定社会基盤役務の安定的な提供の確保に関する制度の概要」（2026年7月7日。2026年7月1日時点で258者） https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/doc/infra_gaiyou.pdf
[8] 重要電子計算機に対する不正な行為による被害の防止に関する法律に基づく特別社会基盤事業者による特定侵害事象等の報告等に関する命令（令和8年内閣府・総務省・法務省・財務省・厚生労働省・農林水産省・経済産業省・国土交通省令第4号、2026年5月28日公布、2026年10月1日施行）第2条・第3条・第4条・附則 https://laws.e-gov.go.jp/law/508M60000F5A004
[9] 個人情報保護委員会「サイバー攻撃時の報告様式の統一について（DDoS攻撃、ランサムウェア事案）」（適用は2025年10月1日から） https://www.ppc.go.jp/files/pdf/yousshikiichigennkagaiyou.pdf
[10] 内閣官房 国家サイバー統括室「サイバー対処能力強化法等について」。罰金額はこの資料の記載によります。根拠条文の逐語は確認できていないため、本文では条番号を記載していません。 https://www.cas.go.jp/jp/seisaku/cyber_anzen_hosyo_torikumi/pdf/setsumei.pdf
[11] NIS2指令（Directive (EU) 2022/2555）第23条 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02022L2555-20221227 DORAの委任規則（Commission Delegated Regulation (EU) 2025/301）第5条 https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202500301 SEC Form 8-K, Item 1.05 および General Instruction B.1 https://www.sec.gov/files/form8-k.pdf CIRCIA（CISA） https://www.cisa.gov/topics/cyber-threats-and-advisories/information-sharing/cyber-incident-reporting-critical-infrastructure-act-2022-circia
[12] 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」 https://www.ppc.go.jp/news/kaiseihou_feature/roueitouhoukoku_gimuka/
[13] Oracle AI Database 26ai Security Guide, Introduction to Auditing ／ Administering the Audit Trail ／ Configuring Audit Policies https://docs.oracle.com/en/database/oracle/oracle-database/26/dbseg/introduction-to-auditing.html
[14] Oracle「Unified Audit: Best Practice Guidelines」v2.0（2025年4月） https://www.oracle.com/a/tech/docs/dbsec/unified-audit-best-practice-guidelines.pdf
[15] pgAudit 公式ドキュメント https://github.com/pgaudit/pgaudit
[16] ISO/IEC 27002:2022 は有償規格のため原文を引用できません。ここで触れた趣旨は認証機関による解説記事に基づきます。
[17] NIST SP 800-92「Guide to Computer Security Log Management」（2006年9月）および SP 800-92 Rev.1 Initial Public Draft（2023年10月） https://csrc.nist.gov/pubs/sp/800/92/final
[18] Oracle「Update: Monthly Critical Security Patch Updates (CSPUs) Begin May 28, 2026」（2026年5月4日）。四半期ごとのCritical Patch Updateは廃止されておらず、その間の月をCSPUが埋める構成です。Oracle Database Server も対象に含まれます。 https://blogs.oracle.com/security/update-monthly-critical-security-patch-updates-cspus-begin-may-28-2026
[19] Anthropic「Claude Mythos」製品ページ。位置づけは「サイバーセキュリティおよび生物学研究のための最も高性能なモデル」で、審査を経た利用者に提供されます。2026年6月9日にMythos 5、9月1日にMythos 5.1。 https://www.anthropic.com/claude/mythos
[20] 内閣府「経済安全保障推進法の特定社会基盤役務の安定的な提供の確保に関する制度に関するQ&A（解説）」。導入等計画書の届出義務は2024年5月17日から。 https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/doc/infra_kaisetsu.pdf
