blog
AIブログ
経産省「デントリネット」不正アクセス:政府サイトの侵入をAIで早期検知する方法
文:クリスタルメソッド編集部 監修:河合 継(代表取締役)

2026年10月、経産省サイトへの不正アクセスが明らかにした課題
2026年10月28日、経済産業省の電力・ガス取引監視等委員会は、同委員会の報告サイト「デントリネット」が10月27日未明に不正アクセスを受けたと発表した(ITmedia NEWS)。同サイトは電力・ガス小売事業者が取引状況等を定期報告するために使用しており、経産省は発覚後にサイト運用を停止し、電子メールでの受付に切り替えた。木原官房長官は2026年10月29日午前の会見でこのシステムは個人情報を扱っていないため、漏えいの恐れはないとの報告を受けていると述べた一方、詳細は確認しているところだとしている(ニューズウィーク日本版 オフィシャルサイト)。影響を受けた可能性のある関係者への丁寧な説明が引き続き求められる。
なお、約1か月半前の2026年9月11日には、別の事案としてデジタル庁が運用するシステムへの不正アクセスで政府職員ら約24万6000人分の個人情報が漏えいした可能性が発表されている(時事通信)。両者の関連は報じられておらず別の出来事だが、官公庁のサイトやシステムを監視する仕組みを見直す動機にはなる。
日本や海外で情報漏えいがどれだけ起きているかは、AIハッキングの日本・世界の主な被害一覧で解説しています。
なぜ政府・行政サイトへの不正アクセスは発見が遅れるのか
公共機関のシステム監視には、民間企業とは構造的に異なる弱点がある。問題を3点に整理する。
第一に、夜間・休日の監視空白だ。行政システムでは、調達・委託の仕組みによっては24時間365日の常時監視態勢を組みにくい場合がある。侵入が夜間に始まっても、翌営業日の朝まで気づかれない状況が生まれやすい。
第二に、ログ分析の自動化不足だ。大量のアクセスログを担当者が目視で確認する体制では、通常とは異なる通信パターンを見つけることが現実的に困難になる。PHPの脆弱性を巡り一部政府機関が予防的にサービスを停止した事例も報じられており(Yahoo!ニュース)、脆弱性の把握から対応までの速さが問われている。
第三に、横断的な可視化の欠如だ。省庁・外局・外部委託ベンダーにまたがる複数サイトのログが一元管理されていない場合、個別のサイト単位では正常に見えても、組織横断では異常なパターンが進行していても気づきにくい。
次に読む:AIセキュリティ対策とは?企業が知るべきリスクと対策
政府・自治体サイトへの不正アクセスをAIで早期検知する3つのアプローチ
官公庁・自治体の公開サイトでは、「弱点を先に見つける」「異常を監視する」「発覚後の初動を支える」の3つに分けて考えると、優先度を整理しやすい。
公開サイトの弱点を先に見つける:脆弱性スキャンとWAF
機械学習を活用した脆弱性スキャナは、CVE(共通脆弱性識別子)データベースと照合するだけでなく、既知の攻撃パターンから派生した亜種も検出できる。特にPHPやCMSのバージョン管理が遅れがちな公共システムでは、スキャンを定期自動化し、新たな脆弱性情報との差分をAIが重大度付きで担当者に通知する運用が有効とされている。WAF(Webアプリケーションファイアウォール)にAIベースのルール更新を組み合わせると、ゼロデイに近い未知の攻撃パターンへの対応速度も高まる。
サイト監視の中心:異常検知とログ自動分析
政府サイトへの不正アクセスをAI検知する実務で、最も直接的な効果をもたらすのがこの層だ。主軸となる2つの技術を示す。
異常ベースの侵入検知(Anomaly-based IDS)は、通常時のアクセスパターン(時間帯別リクエスト数・送受信バイト量・エンドポイントの組み合わせ等)をベースラインとして機械学習で習得し、そこから逸脱した通信を自動フラグ立てする。夜間に特定のAPIエンドポイントへのリクエストが急増する、通常使われないユーザーエージェントが集中するといった異常を、担当者が目視で確認する前に検出できる。異常検知の基礎となる機械学習の仕組みについては機械学習の基礎解説で体系的に整理されている。
自然言語処理(NLP)によるログ意味解析は、大量のサーバーログやSIEM(セキュリティ情報・イベント管理)ログをLLMに類似した技術で構造的に解析し、インシデントの兆候となるイベントシーケンスを自動抽出・サマリ化する手法として実績が積まれてきている。担当者が翌朝に何千行ものログを読む代わりに、「昨夜の特定時間帯における認証失敗の集中」「通常の3倍のデータ転送量」といった要約アラートを受け取れる状態を作れる。
発覚後の初動:停止・切り替えの判断を支える
不正アクセスが確認された後の初動対応にもAIは貢献できる。検知イベントをAIが重大度別(クリティカル/警告/情報)に自動分類し、どの対応手順(プレイブック)を起動すべきかを示すことで、深夜のインシデントでも初動判断のリードタイムを縮められる。自動的な通信遮断や隔離はルールベースのSOAR(セキュリティオーケストレーション)と組み合わせて実装されることが多く、AIは判断補助と優先度付けを担う位置づけにとどめる設計が現実的だ。
自治体・公共機関の規模別:AI監視の適用イメージ
技術として確立していても、どの現場にどう当てはまるかが見えなければ実装は進まない。国内の自治体・公共機関が直面しやすい状況を規模別に整理した。
| 対象 | 典型的な課題 | AIで補える部分 | 主な導入形態 |
|---|---|---|---|
| 中央省庁・外局 | 多数のサブサイト・外部委託ベンダーの管理が分散し、横断的な可視化が困難 | 全サイトのログを一元収集・異常スコアリング | SIEM+AIアナリティクス基盤 |
| 都道府県・政令市 | 専任セキュリティ担当が少なく、夜間・休日の監視が手薄 | 異常検知の自動アラートで担当者へのエスカレーション | クラウド型マネージドSOC |
| 市区町村(小規模) | 予算・人材ともに限られ、専用ツール導入が難しい | クラウドWAFのAIルール更新で基礎防御を自動維持 | SaaS型WAF・クラウドセキュリティ |
| 独立行政法人・公社 | 官民データが混在し、どちらの基準で管理するか不明確 | 機密度別のアクセスパターン分類・ポリシー適用補助 | IDaaS+UEBAツール |
規模が小さいほど「AIツールを入れれば解決する」という期待と現実のギャップが大きくなる点には注意が必要だ。AIは大量のログを処理する局面で威力を発揮するが、ログ自体が収集・保存されていなければ分析の土台がない。AI活用の前提として、まずログ収集の仕組みを整えることが順序として先行する。
AIセキュリティ監視の限界と見落としてはいけないリスク
AIを活用した不正アクセス対策には、現時点で明確な限界がある。「AIが監視している」という過信がかえって新たな盲点を生む。
誤検知と見逃しのトレードオフは避けられない。検知感度を高めると正常なアクセスもフラグが立つ(誤検知)ため、アラートが増えすぎて担当者がアラート疲れを起こす。感度を下げると本物の攻撃を見逃す。この調整は導入後も継続的なチューニングが必要で、一度設定すれば自動で最適化されるわけではない。
最終判断は必ず人が行う。AIは「これは異常かもしれない」という補助情報を提供するにとどまる。本当に不正アクセスかどうか、どのシステムを停止すべきか、外部への報告・公表が必要かといった判断は、セキュリティ担当者と管理職が担う。AIの出力に基づく自動遮断が正常なサービスを止めてしまう恐れもあるため、自動対応の範囲は慎重に設計する必要がある。
プライバシーと監視の境界線にも注意が必要だ。アクセスログには利用者の行動情報が含まれる。AIによる詳細なログ分析は不正アクセス対策に有効な一方、個人情報保護法(行政機関等に関する規律を含む)の観点から、どこまでのデータを何の目的で分析・保持するかを組織として明確にする必要がある。過剰な監視は利用者のプライバシーを侵害するリスクをはらむ。
内部不正への対応には別途の仕組みが必要だ。正規の権限を持つ内部者による不正な操作は、通常のアクセスと見た目が近いため、AIの異常検知モデルだけでは検出が難しい場合がある。アクセス権限管理・特権ID管理・監査ログの人的レビューで補う必要がある。
AIシステム自体が攻撃対象になる可能性も現実的なリスクとして認識されてきている。検知モデルのロジックが外部に漏れれば、そのモデルをすり抜ける攻撃パターン(敵対的サンプル)が設計されうる。AIシステム自体のアクセス制御とモデル管理もセキュリティ対策の範囲に含める必要がある。
明日から動ける実務の一歩:ログ収集の現状確認から始める
高度なAIツールの導入より先に、現在の環境で何が記録されていて何が記録されていないかを把握することが第一歩だ。確認すべき最低限の項目を示す。
ログ収集の現状確認:ウェブサーバー(Apacheであればaccess_log・error_log)、アプリケーションサーバー、データベースの接続ログが実際に記録・保存されているかを確認する。保存期間が短く、インシデント発生時に遡れないケースは珍しくない。
ベースラインの数値化:通常時の1日あたりのリクエスト数、ピーク時間帯、主なアクセス元の傾向を数値として把握する。これがなければ「異常」の判断基準が定まらない。既存のサーバーログを集計ツール(AWStats等)で可視化するだけでも、ベースラインの感覚をつかめる。
脆弱性スキャンの定期実行:OWASP ZAP(Zed Attack Proxy)など無償で使えるツールでも、既知の脆弱性の有無を自動スキャンできる。PHPバージョンの確認も含め、定期スキャンを組織のルールとして年間計画に組み込む。
インシデント対応手順の文書化:不正アクセスが検知されたとき、誰が最初に判断し、誰に報告し、いつサイトを停止するかの判断基準が文書化されていない組織は多い。AIツールの導入前に、この手順を1ページで整理しておくことが、実際のインシデント時の混乱を最も効果的に抑える。デントリネットの事案では、発覚後にサイト運用を停止して電子メール受付に切り替えたと報じられている(Yahoo!ニュース)。こうした判断を迷わず下せるよう、停止と代替手段の基準を事前に決めておきたい。
経産省のデントリネットの事案を受けて、官公庁・自治体のサイト運営者は、自らのログ収集と監視体制を点検する機会にできる。AIはその対応を効率化・高速化する有力な手段だが、その効果はログ収集・体制整備・人の最終判断という基盤の上にのみ成立する。
参考文献
- Yahoo!ニュース https://news.yahoo.co.jp/articles/31e960b1972adef30d02a40564ba49c1fa7a70b8
- ニューズウィーク日本版 オフィシャルサイト https://www.newsweekjapan.jp/articles/-/338418
- 時事通信 https://www.jiji.com/jc/article?k=2026091100453&g=pol
Read next
あわせて読みたい
-
AIハッキングで情報漏洩が相次ぐ?日本・世界の主な被害一覧【2026年7〜11月】
AIハッキングで情報漏洩が相次ぐ?日本・世界の主な被害一覧【2026年7〜11月】 2026年9月末時点で、日本国内の企業・自治体が公表した不正アクセス等の被害...
-
AIセキュリティ対策とは?企業が知るべきリスクと今すぐできる対策【2026年】
結論:AIセキュリティ対策とは、AIの利用で生まれるリスクから会社を守ること。まず5つから始める AIセキュリティとは、AIに関わるサイバーリスクから組織を守る...
-
AIによる情報漏洩とは?生成AIで漏れる原因・事例と、2つの経路・企業の対策【2026年】
結論:AIによる情報漏洩とは?経路は2種類ある AIによる情報漏洩とは、AIを使った結果、あるいはAIが関わった攻撃によって、個人情報や社内の機密情報が外部に出...
