本書「VulnOps：AI時代の脆弱性管理」は、CSA本部が公開している「VulnOps: Vulnerability Management in the Age of AI」の日本語版で、リサーチノートです。

資料はこちらからダウンロードしてください。

AIによる脆弱性の自動発見でCVEの登録件数が急増する一方、米国のNVDは2026年4月に情報付与（エンリッチメント）の対象を一部に限定し、公表から悪用までの時間も数時間単位にまで縮まっています。本書は、定期スキャンと四半期ごとのパッチ適用を軸とする従来の脆弱性管理はもはや通用しないと指摘し、脆弱性への対応を絶え間ない流れとして回し続ける運用手法「VulnOps」を提唱しています。そのうえで、継続的な発見、リスクベースの優先順位付け、修正の自動化など6つの基本原則と、組織が最初に取り組むべき3つの施策を示しています。

本書の背景には、Anthropicの「Claude Mythos Preview」をはじめとする高性能なAIモデルが、未知の脆弱性を大量に発見できるようになったことがあります。これを受けてCSAは、SANS、OWASPなどと共同で2026年4月に「The AI Vulnerability Storm: Building a Mythos-ready Security Program」を公表し、AIによる脆弱性発見の時代に備えた「Mythosレディー」なセキュリティプログラムの構築を呼びかけました。「Mythosレディー」ではその柱の一つとして、VulnOpsを組織の恒常的な機能として立ち上げることを求めています。本書は、そのVulnOpsとは何か、なぜ必要なのかを掘り下げています。

また、VulnOps、CTEMの実装について、以下のブログを公開していますので、合わせてご覧ください。

「Mythosレディ」とは何か（続編-3）～　VulnOps と CTEM を実装する実施例

以上

2026年10月24日
AIWGメンバー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

エグゼクティブサマリー

• 何が起きたか：PHP本体に、認証なしで任意コード実行（RCE）に至る可能性がある2件の重大な脆弱性（CVE-2026-109618／109619、通称PHP2Shell、CVSS v4.0で9.2）が見つかった。PHP 5.4以降、修正版より前のバージョンが影響を受ける。本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない［1］［23］。
• AIの役割：Calif（OpenAIの「Patch the Planet」の中でGPT-5.6 Solを使用）、OpenAI、Wizが、それぞれAIを使って独立に発見した。欠陥自体は10年以上前からあった。Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している［1］［2］［3］。
• 防御側の窓は開いたが、早く閉じた：発見から公開まで約2か月半あったが、10月20日に情報がリークし、公開の4日前（10月17日）から悪用の試みが観測されていた。公開から1日足らずで、攻撃の試みは数百万件規模に達した［10］［11］。
• 国内外で予防停止が広がった：欧州では、複数の政府機関や公共サービスが予防的にサイトを停止した［17］［18］。日本でも首相と国家サイバー統括室が深夜に呼びかけ、省庁・自治体・銀行・交通まで停止が広がり、停止告知は502件を超えた。このうち285件は、調査対象のX上で再開告知を確認できなかったものであり、実際の停止継続件数とは一致しない可能性がある［26］［30］。
• 被害：2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった。CISAのKEV（悪用が確認された脆弱性の一覧）にも未登録である［12］［31］。
• 3層からの示唆：止める範囲と戻す速さには、第1層（資産管理・EOL管理）の成熟度が大きく影響したと考えられる。今回は、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。次は「攻撃側のAIが先に見つける」前提で、第2層（侵害前提の封じ込め）と第3層（VulnOps・CTEM）を同時に育てる必要がある。

1. Mythosレディの3層モデル

「Mythos」は、Anthropicが2026年4月に発表したAIモデル「Claude Mythos Preview」に由来する。このモデルが、脆弱性の発見から攻撃コードの作成までを機械の速度で行えることを示したことを受け、CSA・SANS・OWASPなどが2026年4月に緊急公開した文書「AI脆弱性の嵐（AI Vulnerability Storm）：『Mythosレディ』なセキュリティプログラムの構築」［36］が、「Mythosレディ」という言葉を広めた。同文書は言葉を明示的には定義していないが、AIによる脆弱性発見の急増に備えて、今すぐ取り組むべき対策を示している。

以前のブログ「Mythosレディとは何か」［33］は、同文書を踏まえ、これを「機械速度の攻撃が常態化した世界において、組織が生存できる状態を継続的に維持すること」と定義している。特定のAIモデルへの対抗策ではなく、その背後にある構造的なリスクに継続的に適応し続けられる組織の状態である。PHP2Shellでも、発見に使われたのはMythosではなく、他社のAIモデルだった［1］［3］。

同シリーズでは、Mythosレディの目的を「コントロール可能な状態」、すなわち攻撃を100%防ぐことは不可能でも、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することに置いている［33］［37］。そして、それを実現する道筋として、基本的なセキュリティ対策、ゼロトラスト、VulnOps・Agentic Control Planeの3層を定義している［37］。本書でも、この枠組みに沿ってPHP2Shellを評価する。

層	主な内容	役割
第1層 基本的なセキュリティ対策	資産管理、パッチ適用、ログ収集と保全、バックアップと復旧手順、インシデント対応手順	他の層が機能するための土台。守る対象が分からなければ何も守れない
第2層 ゼロトラスト	守るべき資産（プロテクトサーフェス）ごとに「信頼せず、常に検証する」設計。最小権限、セグメンテーション、継続的な監視	侵入される前提で、被害を封じ込め、攻撃者の難易度を構造的に上げる
第3層 VulnOps・CTEM・Agentic Control Plane	悪用される前に脆弱性を見つけ、事業への影響で優先順位を付けて直し続ける運用。AIを防御側にも組み込み、AIエージェントを統制する	攻撃側と同じ速度で動き、誰が見つけた脆弱性でも、攻撃者より先に塞ぐ

なお、3層モデルは続編［37］で定義したもので、基本対策の重要性は第1回［33］、第3層のVulnOpsとCTEMの具体的な実装は続編-2［34］で詳しく論じている。この3層は「順番に完成させる」のではなく「同時に育てる」。第1層のログ基盤が第2層の継続的検証を支え、第2層の守るべき資産の定義が第3層の優先順位を決め、第3層で見つかった脆弱性が第1層のパッチ適用と第2層のポリシーに反映される。この循環が回っている状態がMythosレディである［37］。

2. PHP2Shellの概要

2.1 何が起きたか

• 規模：PHP 5.4以降、修正版より前のバージョンが、2件のCVEの少なくとも一方の影響を受ける。影響を受けるCVEはバージョンによって異なる。PHPは世界のWebサイトの約70%で使われ、WordPress、Drupal、MediaWikiなどの土台になっている［1］。
• 性質：本脆弱性はPHP本体のリクエスト処理に起因するため、アプリケーション側の認証・入力検証だけでは根本的に解消できない。攻撃の成立条件やリスクは、PHPの実行方式（mod_php、PHP-FPMなど）や構成も踏まえて評価する必要がある［1］［23］。
• 影響：認証なしで任意コード実行（RCE）に至る可能性があるほか、他のリクエストのパスワード、トークン、APIキーを含むプロセスメモリを読み出せる可能性がある［1］。
• 修正：PHP 8.5.12、8.4.27、8.3.36、8.2.35で修正。PHPの開発チームによる更新の対象外だったが、7.4・8.0・8.1には例外的なソースのバックポートが公開された［23］。

「PHP本体に起因する」ことの何が問題か

通常の脆弱性はアプリ（WordPressやEC-CUBE、自社開発のシステムなど）のコードの中にあり、アプリ側の対策で守ることができる。PHP2Shellは、PHP本体がリクエストを受け取って処理する段階に原因がある。このため、次の問題が生じる。

1. アプリ側の対策だけでは防げない：入力チェック、ログイン認証、フレームワークのセキュリティ機能は、アプリのコードが動いて初めて効く。PHP2Shellは、構成によってはアプリのコードが動く前に成立し、PHPの開発チームは、セキュリティアドバイザリで、Apacheのmod_phpでそれを実証したと説明している［23］。アプリをどれだけ堅牢に作っても、それだけでは根本的な解決にならない［1］。
2. アプリを最新にしても防げない：WordPressやEC-CUBE、プラグインを最新にしても、サーバのPHPが古いままでは防げない［31］。「CMSは最新だから大丈夫」という判断が通用しない。
3. 直す責任がアプリの担当者の手を離れる：修正はPHP本体の更新でしか行えず、担当はサーバの管理者、レンタルサーバー事業者、委託先になる［31］。アプリの担当者やサイトの所有者が自分で直せない場合が多く、日本で「止める」以外の選択肢を持てなかった組織が多かった一因でもある。
4. 見つけにくい：PHP本体の処理で起きるため、アプリのログにはほとんど手がかりが残らない可能性がある［1］。異常なリクエストやメモリ上限エラー、PHPのワーカーの異常終了など、サーバやプロセスの単位で見張る必要がある。
5. 影響範囲が「PHPを使うものすべて」になる：特定のアプリの欠陥ではないため、PHPで動くものはアプリの種類を問わずすべて対象になる。PHPは他のソフトや機器に同梱されていることも多く、自社がPHPを使っていると認識していない場所まで影響が及ぶ［16］。

これを3層との関係でみると次のようになる。資産の把握をアプリやCMSの単位で止めず、その下で動く言語処理系やライブラリの単位まで持つ必要がある（第1層）。アプリの防御を越えられる前提で、サーバ上の権限やデータを最小化して被害を封じ込める（第2層）。検知もアプリのログだけに頼らず、サーバやプロセスの振る舞いで行う（第3層）。

2.2 発見から公開までの経緯

発見者は複数いる。最初に見つけたのはOpenAIの取り組みに参加していたCalif（8月1日）で、OpenAI自身とWizもそれぞれ独立に同じ問題にたどり着いた［2］［3］。

日付（2026年）	出来事
7月30日	Califが監査を開始［2］
8月1日	Califの説明による発見日［2］
8月11日	Califの研究者が無条件のRCEを報告。同日、OpenAIも同じ根本原因を独自に報告［2］［5］
8月14〜15日	CalifがRCEのPoCをPHPに共有し、PHPが確認［2］
8月19日	Wizが独自に発見（Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを使用）［1］
8月24日	WizがPHPに報告［1］
9月18日	OpenAIが追加の攻撃経路を報告［2］
9月21日	PHPが報告を受理し、協調した修正の開発に着手［1］
10月17日	最初の悪用の試みをAmazonが観測（公開の4日前）［10］
10月20日	脆弱性の存在とCVE番号がオンラインでリーク［7］［14］
10月21日	予定を1日前倒しして修正版を公開（日本時間22時台。予定は23時）［7］［26］
10月23日	PHPが、21日の修正版では直らない別のセッション処理の欠陥（CVE-2026-115560）を公表［12］（詳細は3.3）

OpenAIは、こうした最先端のAIが攻撃者より先に脆弱性を見つけたことで、PHPの開発チームやセキュリティ事業者が、公開前に修正と防御策を準備できる期間（「Defender’s Window」＝防御側の窓）が生まれたと説明している［3］［32］。Cloudflareは公開の9時間前に防御ルールを展開するなど、業界横断の準備が行われた［14］。

2.3 AIが変えたこと

• 欠陥は10年以上前からあり、2024年の監査でも見つかっていたが、悪用できることは示されていなかった［2］。
• Wizは、AIによる分析が脆弱性の理解や、実際に動作する攻撃コードの作成・標的ごとの調整を支援したと説明している。複数の欠陥をつなぎ、標的ごとのメモリ配置に合わせて調整する作業を、AIの支援で数時間のうちに行えたという。Wizによれば、1人の研究者が1週間で、以前なら一流チームが数か月かかる作業を終えた［1］。
• Wizは、AIによって攻撃コードの作成と標的ごとの調整の手間が下がり、複雑さはもはや防壁にならない可能性があり、「実際に悪用可能」の定義が変わると指摘している［1］。これを踏まえると、これまでの「人間が現実的な手間で攻撃コードを作れるか」という判断に加えて、「欠陥が存在し、外部から届くか」を重く見る必要があると考えられる。「悪用は困難」として後回しにされてきた脆弱性も、狙われる対象になりうる。

2.4 補足：CISAの「自動化可能性」評価

CISAは「Vulnrichment」というプログラムで、公開されたCVE記録に優先順位付けのための情報を追記している。その簡略版SSVCには「悪用状況」「自動化可能性（Automatable）」「技術的影響」の3つの判断項目がある。自動化可能性は、その脆弱性を自動で悪用でき、大量の攻撃が起こりうるかを問う項目である［9］。

PHP2Shellの公開時の記録では、悪用状況は「観測なし」、自動化可能性は「No」で、CVSSでも攻撃の複雑さは「高」とされていた［8］。これはメモリ破壊型の脆弱性として一般には妥当な評価である。ただし、Wizの研究で示されたように、AIが標的ごとの調整を支援できるようになったことは、従来の自動化可能性の評価の前提を見直す理由になる［1］。一方で、本件で攻撃全体の大量自動化が実証されたわけではなく、CISAの評価がAIによって無効になったと断定することはできない。

これらを踏まえて、公的機関の評価や点数は、公開時点の、人間の攻撃者を前提にしたスナップショットにすぎず、AIの時代には、それを鵜呑みにせず、自社の環境で継続的に評価し直す仕組み（CTEM）が必要であると考える。

3. 悪用の状況とAmazonの分析

3.1 Amazonの観測（MadPot）

Amazonは、自社の大規模なハニーポット網MadPotでの観測結果を公表した。毎分2,000億件を超えるイベントを分析し、MadPotからの脅威情報と組み合わせて攻撃を検知・遮断しているとしている［10］。

日時（UTC）	日本時間	観測内容［10］
10月17日	10月17日	最初の攻撃の試み。商用の匿名化ネットワークに関連するIPから。攻撃者による活動とみられるが、公開前に情報をどう入手したかは不明
10月21日 02:00	21日 11:00	最も早いPoCを確認
10月21日 02:00〜08:00	21日 11:00〜17:00	別の匿名化基盤からの攻撃が続く。ペイロードも手段もばらばらで、複数の攻撃者とみられる。成功したかは不明
10月21日 14:00	21日 23:00	情報公開の解禁とパッチ公開
解禁後 数時間	22日未明	追加のPoCが次々に現れ、ほぼ即座にセンサーへの攻撃に使われる

なお、Amazonは、識別した6つのIPアドレスを公表したが、これらは匿名化のための共有基盤であり、遮断ではなく、観測された場合の調査に使うよう求めている［10］。

3.2 Amazonが示した教訓と、見直すべき前提

教訓1：公開日まで情報を伏せておく取り決め（エンバーゴ）が防御側を守るのは、他の誰かが同じバグを見つけるまでに限られる。協調開示は今も正しいやり方だが、公開日を最も早い悪用の日と考えてはいけない。PHP2Shellでは、公開前に侵害されている可能性がある［10］。

教訓2：パッチから攻撃コードまでの時間は、構造的に縮んでいる。かつては少数の能力ある攻撃者が攻撃コードを作り、他はそれを待つ構造だったが、AIによる分析でパッチの差分やアドバイザリーから攻撃コードを作るのが簡単になり、数時間から数分で動ける攻撃者が増えている［10］。

見直すべき前提［10］	内容
修正期限は時間単位で測る	脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した［10］
調査は最も早い悪用の日から	公開日ではなく、最も早く悪用が確認された日から調査する。PHP2Shellなら少なくとも10月17日から
シグネチャに頼らない検知	最初の悪用は、特定のCVE向けのシグネチャができる前に来ることが多い

これを踏まえ、インターネットに公開された重大脆弱性では、攻撃が修正公開前または公開直後に始まる可能性を考慮し、従来の一律的な日数ベースの期限だけでなく、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。

3.3 公開後の状況

• Cloudflareは、公開から45分で数万件、2時間で数十万件、10月22日早朝には数百万件の攻撃の試みを観測した。23日時点で3,440万以上のPHPサービスがなお脆弱とみられる［11］。
• 攻撃者が管理するサーバ上で、PHP 8.4.26とApacheのmod_phpを狙った攻撃ツールと、標的のPHPのバージョン、サーバ構成、セッション設定、エラー表示の有無などが攻撃の前提条件を満たすかを調べるスクリプトが確認された。このツールは、メモリの漏えいを使ってASLR（メモリ上の配置をランダムにして攻撃を難しくするOSの防御機能）を回避する仕組みだった。報道によれば、調べられたサイトでは10月22日時点でシェルアクセスの証拠はなく、前提条件を満たしていなかったとみられる。この時点では、攻撃者のツールが成功するのは特定のバージョンや構成に限られていた可能性が高い［11］。
• 一方、VulnCheckの研究者は、PHPが推奨する本番向けの設定（エラーを画面に表示しない設定など）でも、ASLRを回避してRCEを成立させる手法を示した。攻撃者のツールより広い条件で攻撃が成立しうることを意味し、攻撃者が同様の手法を取り入れれば、成功する範囲が広がるおそれがある。ただし、確実なRCEは当初の想定より難しいとの見方もあり、状況は流動的である［11］。
• 10月23日時点で、CISAのKEVには2件とも未登録［12］。
• 10月23日、PHPは別のセッション処理の欠陥（CVE-2026-115560）について情報提供の告知を出し、次の定期修正版が出るまでアップロード進捗機能を無効にしておくよう勧めた［12］［13］。PHP自身はこのリスクを「起こりにくい」と評価しており、悪用には特殊なアプリの作りが必要で、悪用も報告されていない［35］。アップロード進捗機能は、ファイルのアップロード中に進み具合を表示するためのもので、多くのサイトでは使われておらず、無効にしても通常の動作に影響はない。ただしPHPの標準設定では有効になっており、サイトが使っていなくても外部からのリクエストで動かせてしまうため、設定を確認して無効にしておくとよい［1］［13］［15］。

4. 海外の対応

• 英国：NCSCの警告を受け、自治体やロンドン警視庁のサイトが停止。NCSCは、すぐにパッチや緩和策を入れられない場合はオフラインも検討するよう呼びかけた［17］。
• オランダ：行政ポータル［19］［20］、市民が自分の個人データを確認するポータル、下院、NCSC自身、データ保護当局のサイトなどが停止［18］。認証基盤DigiDも止まり［20］、ロッテルダム港、サッカー協会、多数の病院も停止した［19］。
• その他の欧州：フィンランドでは国のIT機関が政府の公開ウェブサービスを停止、フランスは内務省が自治体の行政サイトを停止、ドイツでも連邦のIT機関がサイトを停止［17］。デンマークでは全国の学校連絡プラットフォームにも影響［21］。スイスのホスティング事業者が顧客ポータルやWebメールを含めて停止し、Wikipediaも一時停止した［19］。
• 欧州以外：カナダの担当相が一部サイトの一時停止を公表し、オーストラリアではサイバーセキュリティセンター自身も影響を受けた［20］。
• 当局の方針：EUのCERT-EUは、すぐに更新できない場合は一時的にサイトを止めるよう助言［19］。米国のNSAと欧州のサイバーセキュリティ機関は即時対応を求め［6］、CISAもすぐにパッチを当てるよう呼びかけた［16］。
• 停止の意味：止めた組織は侵入の兆候はないと説明しており、停止の一覧は被害の数ではなく、各組織の慎重さを表している［18］。
• 資産把握の差：PHPの所在を把握している組織は必要な部分だけを止め、把握していない組織は全部を止めた結果、ウィーンではWebメールまで止まった、という指摘がある［18］。
• 保険：英国の保険業界は、多数の契約者が同時に影響を受ける「集積リスク」として注視し、侵害がないまま自ら止めた場合に事業中断の補償が出るかも論点になっている［17］。

5. 日本の対応

5.1 時系列（日本時間）

日時	出来事
21日 日中	IPAが同日23時の修正版公開を予告し、PHPの利用状況を確認して速やかに適用できるよう準備を要請。攻撃は確認しておらず予防的な発信と説明［25］
21日 14時〜19時	コドモンが14時ごろに全サービスを停止。BASEが15時50分、エックスサーバーが16時に公式サイトや管理画面を停止。19時にニコニコ、pixiv、ConoHa WINGなどが続く［26］
21日 21時44分／55分	国家サイバー統括室（NCO）、続いて高市首相がXで対応を呼びかけ。首相は「今夜に対応して頂きたい大至急のお願い」とし、すぐ適用できない場合はサイトの一時停止も有効策の一つとした［26］
21日 22時台	PHPの修正版が公開（予定は23時）［26］
21日深夜〜22日朝	pixivが23時30分、コドモンが3時22分、BASEが8時に再開［26］
22日 日中	国税庁が10時20分ごろに停止し16時10分ごろに再開［26］。気象庁なども一時停止［27］。官房長官は、政府系機関や基幹インフラの被害は現段階で報告されていないと述べた［26］
22日 13時11分	JPCERT/CCが注意喚起。パッチ適用に加えて侵害の有無の調査を要請し、痕跡がなくても攻撃を受けていないとは断定できないとした［26］
23日 14時	アシュアードの集計で停止告知は累計502件、再開告知を確認できたのは217件［30］

5.2 停止の規模と分野

• 件数：X上の停止告知は502件、うち285件（約6割）は再開告知が未確認。ただし再開してもXで告知していない組織や、Xで停止を告知していない組織は反映されておらず、全体を網羅した数字ではない［30］。
• 省庁：国税庁と気象庁のほか［27］、財務省と厚労省も一部サービスを停止［28］。
• 自治体：札幌市が公式ホームページを止めて簡易サイトに切り替え、大阪府も検索機能を制限［28］。三重県では26サイトの公開や一部機能を停止し、8市6町にも影響［29］。
• 金融：三菱UFJ銀行がネットバンキングの一部取引を停止し、地銀も一部アプリを停止、みずほ銀行も臨時メンテナンスを実施。一方、全国銀行協会は金融機関をつなぐオンラインシステムには影響がないと説明しており、止めたのは決済ではなく周辺サービスが中心だった［31］。
• 交通・インフラ：JALはWebサイトの一部を予防的に閉じ、予約や運航への影響はないとした。九州電力はホームページを停止し、再開予定を延期した［31］。
• サービス終了：古い仕組みで十分な対策が取れないとして、ゲーム2本がサービスを終了した［31］。

5.3 被害の状況

22日昼、バルテックが顧客情報流出の可能性を公表し、当初は原因を「PHPの脆弱性を標的とした攻撃」としていた［26］。しかしその後、これは誤報だったと訂正し、原因は自社サービスの脆弱性だと説明している。2026年10月23日時点で、確認した公開情報の範囲では、PHP2Shellを原因とする被害を公表した国内組織は確認できなかった［31］。

5.4 ホスティング事業者の対応の差

対応の型	例［26］
利用者のサイトを止めずに更新	さくらインターネット（21日23時からのメンテナンスで数秒程度の接続断のみ）、mixhost、カラフルボックス、Value-domain系、エックスサーバー（PHP 8.2〜8.5）
一時停止して更新し、再開	ロリポップ!、ヘテムル、ムームー（22日午後までに再開）
利用者に判断を委ねる	KAGOYA（事業者側では利用者のサーバーを止めず、修正版の適用を調整する間、利用者にサイトの公開停止やアクセス制限の検討を求めた。22日夕方時点）

PHPの開発チームは、Linuxディストリビューションなどに事前に修正を渡していたとされ、この準備を日頃の運用に組み込めていたかで、止める範囲が変わったと指摘されている［26］。

古いバージョンの扱いも分かれ、さくらインターネット、mixhost、カラフルボックス、ヘテムルなどは、サポートが終わったバージョンにも独自に修正を入れた。こうした修正ではバージョン番号が変わらない場合があり、番号だけでは修正済みか判断できない［26］。

6. 日本と海外の比較

この比較は、10月23日までに公開された報道や各組織の告知に基づくものであり、各国・各組織の対応能力を網羅的に測定したものではない。報道の多い事例に偏っている可能性がある点に留意されたい。

観点	日本	欧州	米国
トップの発信	首相とNCOがXで深夜に直接呼びかけ。サイト停止も有効策と明言［26］	英NCSC、CERT-EUが「更新できなければオフラインも」と助言［17］［19］	CISA、NSAが即時対応を要請［6］［16］
政府機関の停止	国税庁、気象庁、財務省、厚労省、自治体［27］［28］	オランダの行政ポータル、フィンランドの政府サービス全停止、英仏独の行政サイト［17］［18］	確認した範囲では、連邦政府サイトの大規模な停止の報道は見当たらなかった
民間の停止	502件超の告知。銀行、交通、EC、ゲームなど［30］［31］	病院、港湾、報道機関、ホスティング事業者、Wikipedia［19］	確認できず
悪用の観測	10月23日時点で、公的機関による国内の攻撃観測データの公表は、確認した範囲では見当たらなかった。民間では、独自の観測網での観測を公表した企業がある	オランダのNCSCは、公開前の時点では悪用を確認していないと説明した［18］	Amazonが公開4日前から、Cloudflareが公開直後から攻撃の試みを観測した［10］［11］
侵害調査の呼びかけ	JPCERT/CCが調査観点を提示［26］	確認できず	Amazonが「10月17日から遡って」と起点を明示［10］
確認された被害	PHP2Shellを原因とする被害の公表は確認できず（23日時点）［31］	停止組織は侵入の兆候なしと説明［18］	KEV未登録（23日時点）［12］
復旧	約6割はX上で再開告知が未確認（実際の停止継続件数とは一致しない可能性あり）。サービス終了も［30］［31］	確認できず	大規模な停止の報道が見当たらないため、比較の対象なし

比較から見えること

• 共通点：止めた範囲には、資産の把握度が大きく影響したと考えられる。欧州でも、PHPの所在を把握していない組織は全部を止めたと指摘されている［18］。日本でも、復旧が長引く要因として、自社や委託先で使っているPHPのバージョンの特定作業とEOL対応が挙げられている［30］。
• 日本の特徴1：「止める」は速く、「戻す」に時間がかかった。首相とNCOの呼びかけもあり予防停止は素早く広がったが、23日時点でX上の再開告知が確認できないものが約6割あった。実際に停止が続いている件数とは一致しない可能性があるものの、夜のうちに更新を終えた組織と、止めたまま長引く組織の差が大きい［26］［30］。
• 日本の特徴2：委託先・ホスティング事業者への依存。レンタルサーバーやCMS提供元の対応で、利用企業ができることが大きく変わった。自社で直せない組織は「止める」以外の選択肢を持てなかった。
• 日本の特徴3：国内の攻撃観測データの公表が少ない。海外では事業者が自社の観測データで「いつから、どれだけ」を示したが、確認した範囲では、日本の公的発信は「対応してください」が中心で、脅威の強さの判断を海外のデータに頼っている。

7. 3層に照らした評価

PHP2Shellは、3層のすべてを同時に試した事案だった。各層で何が試され、日本でどうだったか、今後どう変えるかを整理する。

層	PHP2Shellで試されたこと	日本の状況（観察）	今後の変え方
第1層 基本対策	PHPがどこで、どの版で動いているかを即答できるか。PHPは他のソフトや機器に同梱され、気づかない露出が生まれやすい［16］。CybelAngelの調査では、約224万のインターネット公開PHPホストのうち、バージョンを確認できた約150万台の59%が、修正版の公開前の時点で修正提供の見込めないバージョンを使用していた［15］。今回は、PHPの開発チームによるサポート終了版（7.4〜8.1）への例外的なバックポートや、OSの配布元・ホスティング事業者による独自の修正が提供されたが［23］［26］、こうした例外的な対応が次も得られるとは限らない	止めた後の再開に時間がかかり、X上で再開告知が確認できないものが約6割あった（実際の停止継続件数とは一致しない可能性あり）［30］。古い環境のサービスは終了に至った［31］。委託先・ホスティング事業者に依存	資産台帳を言語処理系・ライブラリ単位（SBOM）まで下げる。EOLは「修正が届くかどうかを自分で決められない資産」として扱い、撤去期限を設ける。外部公開の重大脆弱性は、日数ベースの期限に加え、露出状況・悪用情報・事業影響に基づく時間単位の対応基準を設ける。委託契約に緊急時の対応時間を入れる。ログを遡って調査できる期間保存する
第2層 ゼロトラスト	PHP本体に起因するため、アプリ側の防御だけでは防げない。メモリから資格情報が漏れる可能性がある［1］	封じ込めの主な手段が「サイトを止める」になった。GMO Flatt Securityは、侵害時に備えた権限とデータの最小化を推奨［22］	侵入される前提で、サーバ上のデータとIAM権限を最小化。シークレットを短命化しサーバに置かない。外向き通信の制限とセグメンテーションで横展開を止める。「止める範囲を小さくできる」設計にする
第3層 VulnOps・CTEM	数時間で判断し動けるか。シグネチャ前に検知できるか。CVSSや「自動化不可」の評価を鵜呑みにしないか［8］［10］	JPCERT/CCが侵害調査の観点を提示［26］。夜のうちに更新を終えた事業者とそうでない組織で差。国内の攻撃観測データは乏しい	CTEMで外部公開面と事業影響を常時評価し、外部ソフトの脆弱性は通知を受けたら数時間で塞ぐか止める。振る舞い検知と自動遮断。仮想パッチを即日配る経路。停止の基準と決裁者を事前合意。自社開発のコードはAIでリリース前に診断

3層の重心を、「パッチを早く当てる」（第1層）だけから、「パッチがない期間を生き延びる」（第2層・第3層）へ広げる。ただし、第2層・第3層は、パッチがない期間のリスクを低減するものであり、脆弱性の根本修正を代替するものではない。修正版が出たら速やかに適用することが前提である。また、止める範囲と戻す速さには第1層の成熟度が大きく影響したと考えられ、3層は同時に育てる必要がある。

8. 攻撃側のAIが先に見つける時代への備え

今回は防御側が約2か月半先行できた。しかし、異なる組織が、それぞれAIを使って同じ欠陥にほぼ同時期にたどり着いた事実は、攻撃側も同じものに到達しうることを示している。さらに、リークと公開前の悪用の試みで、その先行期間は想定より早く閉じた［10］。次は、攻撃側のAIが先に見つけ、パッチが存在しない期間に攻撃される前提で備える必要がある。

1. 露出を減らす：インターネットに出ている面を棚卸しし、不要な公開、EOL、管理外のサーバを消す。攻撃側のAIは面が広いほど有利になる。
2. ゼロデイ前提の封じ込め：最小権限、シークレットをサーバに置かない設計、外向き通信の制限。パッチがなくても「乗っ取られても被害はここまで」と言える状態にする。
3. 振る舞いで検知し、自動で止める：シグネチャのない攻撃に備え、サーバのプロセスの異常終了や再起動の多発、メモリ上限エラーやHTTP 500の多発、予期しないシェルの起動など、ふだんと異なる振る舞いを検知して遮断する。PHP2Shellでも、PHPのワーカー（リクエストを処理するプロセス）の異常終了が兆候として挙げられた［1］［10］［26］。
4. 仮想パッチを即日展開できる経路：WAFやCDNのルールを数時間で全体に配れるようにする。ただしWAFやIPSは本体の修正の代わりにはならない［23］。
5. 「止める判断」を事前に決める：停止の基準、決裁者、顧客への連絡手順、サイバー保険の条件を経営として事前に合意しておく［17］。
6. 自社のコードはAIで先に探す：自社で開発したシステムは、ソースコードを持つ防御側が有利であり、AIによる診断を開発の流れに組み込めば、リリース前に脆弱性を見つけられる可能性が高まる。一方、PHPのような外部のソフトウェアの脆弱性を自社で先に見つけることは現実的ではない。外部のソフトウェアについては、発見を待つのではなく、通知を受けたら影響範囲を即座に特定し、数時間で塞ぐか止められる状態にしておく。これが第3層の役割である。

振る舞いの検知と自動遮断を支える仕組み

上記3つ目の「振る舞いで検知し、自動で止める」は、次のような仕組みを組み合わせて実現する。

種類	役割	PHP2Shellとの関係
サーバ用のEDR・ランタイム保護	サーバ上のプロセスの動きを常時監視し、不審な動きを検知して、プロセスの停止やサーバの隔離を自動で行う	「Webサーバのプロセスからシェルが起動された」などの動きを直接捉えられる。中心となる仕組み
ログとメトリクスの監視	エラーログ、アクセスログ、メモリ上限エラーなどを集め、ふだんより急に増えたら警告する	ワーカーの異常終了やHTTP 500の急増に気づける。自動で止めるには、次の自動対応と組み合わせる
自動対応の仕組み	警告を受けて、該当サーバを切り離す、送信元を遮断するなどの対応を自動で実行する	気づいてから止めるまでの時間を縮める
OSの強制アクセス制御	Webサーバのプロセスがシェルを起動できないよう、あらかじめ制限する	検知ではなく予防。乗っ取られても攻撃者ができることを減らす
WAF	不審なリクエストの急増を検知して遮断する	未知の攻撃はシグネチャがないと見逃す場合があり、本体の修正の代わりにはならない［23］

PHP2Shellは構成によってはアプリのコードが動く前に成立するため、アプリの中に組み込む防御では捉えられない場合がある。サーバやOSの単位で見張る仕組みの方が向いている。

導入にあたっては2点に注意する。第一に、レンタルサーバーやISPにサーバの管理を任せている場合、これらの多くは利用者側では導入できない。事業者がこうした監視や自動遮断を行っているかを確認するのが現実的である。第二に、自動で止める仕組みは、誤検知で正常なサービスを止めてしまうおそれがある。最初は「検知して通知」から始め、誤検知の傾向を見てから自動遮断に進めるのが一般的である。

9. 対策を経営判断にする: PHP2Shellを使った経営層への説明

7.と8.で挙げた対策の多くは、現場の判断だけでは進められない。時間単位の対応基準を設けること、サービスを止める基準と決裁者を決めること、委託契約に緊急時の対応時間を入れること、そしてVulnOps・CTEMの体制に投資することは、いずれも経営の判断を必要とする。PHP2Shellでは、国内外の多くの組織が深夜に「止めるかどうか」の判断を迫られた。こうした判断を平時に済ませておくには、経営層の理解が欠かせない。

しかし、VulnOpsやCTEMという言葉は、一般にはわかりにくい。そこで本節では、用語から入るのではなく、PHP2Shellという具体的な事案を題材に、経営層に何を問い、何を報告してもらうかという形で説明する方法を示す。

出発点は、PHP2Shellの情報がリークした10月20日から23日までの約72時間で、経営に問われた3つの質問である。

#	経営に問われた質問	問われた力
1	うちでPHPが動いているサーバやサービスは、どこに、いくつあるのか？	可視化（資産把握）
2	そのうち、止まると売上や顧客に響くのはどれか？	事業影響の評価（優先順位付け）
3	何時間で直したのか。止める判断は誰がしたのか？	修正と意思決定の速さ

CTEMは「この3つの質問に、平時から常に即答できる状態を保つ経営の仕組み」、VulnOpsは「それを毎日回す運用チームと手順」と説明できる。

言い換えの例

• 健康診断から24時間モニタリングへ：年1回の脆弱性診断は健康診断にあたる。発見から悪用までが数時間になった今は、常時モニタリングと「即入院の判断基準」が要る。
• 点数ではなく、自社にとっての危険度で並べる：今回は、攻撃の複雑さが「高」、自動化可能性が「No」とされた欠陥でも、AIの支援で攻撃コードが作られ、公開直後から大量の攻撃の試みが観測された［1］［8］［11］。CVSSの点数順ではなく、「公開されているか」「重要業務か」「実際に悪用可能か」で順位を付ける。
• Amazonの発言を使う：脅威インテリジェンスを公表したAmazonは、7日・30日の修正期限では、インターネット公開システムの重大脆弱性への対応に十分な猶予を確保できないと指摘した［10］。自社の規程の修正期限と並べて示し、外部公開の重大脆弱性について、露出状況・悪用情報・事業影響に基づく時間単位の基準が必要なことを伝える。
• お金の言葉に置き換える：「数時間の計画停止のコスト」と「侵害されたときの情報漏えい・長期停止のコスト」を比べる。今回、予防的に止めた組織は前者を選んだ。

経営に報告してもらう指標（月次）

指標	意味
外部公開資産のうち台帳にあるものの割合	「どこに何があるか」を把握できているか（質問1）
重大脆弱性を修正・緩和するまでの時間	外部公開の重大脆弱性について、時間単位の対応基準を守れているか（質問3）
EOLソフトの残存数と撤去期限	修正が届くかどうかを他者の例外的な対応に頼っている資産がどれだけあるか
停止判断にかかった時間	止める決断を自社で速く下せるか（質問3）
停止から再開までの時間	戻す力。第1層の成熟度を反映しやすい指標

10. まとめ

PHP2Shellは、防御側のAIを活用した脆弱性発見と協調開示によって、修正準備の時間を確保できた事例である。ただし、攻撃側より防御側が常に先行できることを示すものではない。実際、リークと公開前の悪用の試みで、確保した時間は想定より早く失われ、国内外で大規模な予防停止が起きた。日本では、止める判断は速かったものの、戻すまでに時間がかかる組織が多く、資産把握とEOL管理という第1層の課題が表れたと考えられる。

次は攻撃側のAIが先に見つける前提で、第1層の土台を固めつつ、第2層の封じ込めと第3層のVulnOps・CTEMを同時に育てる必要がある。経営層には、「3つの質問に即答できる会社にしておく」ことを目標として示すのが有効である。

注：本書は2026年10月23日までの公開情報に基づいている。悪用状況や被害の報告は今後変わりうるため、判断の際は各機関・事業者の最新の発表を確認されたい。

参考資料

• ［1］ Wiz Research「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」2026-10-21　https://www.wiz.io/blog/php2shell-php-rce
• ［2］ Unite.AI「PHP Patches Two Critical RCE Flaws Found with Frontier AI Models」2026-10-21　https://www.unite.ai/?p=492046
• ［3］ PPC Land「OpenAI says GPT-5.6 Sol found a PHP flaw before attackers did」　https://ppc.land/openai-says-gpt-5-6-sol-found-a-php-flaw-before-attackers-did/
• ［4］ SmartScope「PHP2Shell: Roles of OpenAI, Calif, Wiz, and Human Involvement」　https://smartscope.blog/en/blog/php2shell-ai-really-find-php-vulnerability-roles-openai-2026/
• ［5］ OfficeChai「OpenAI’s GPT-5.6 Sol Helped Flag The Critical PHP Bug」　https://officechai.com/ai/openais-gpt-5-6-sol-helped-flag-the-critical-php-bug-flaw-thats-had-the-internet-scrambling/
• ［6］ ABC7 Chicago（AP）「Some websites shut down globally as operators address PHP issue after AI finds critical flaw」2026-10-22　https://abc7chicago.com/story/php-vulnerability-2026-websites-shut-down-globally-operators-address-ai-detected-flaw-web-programming-language/19968288/
• ［7］ Wikipedia日本語版「PHP2Shell」　https://ja.wikipedia.org/wiki/PHP2Shell
• ［8］ CyCognito「Emerging Threat: php2shell (CVE-2026-109618, 109619)」　https://www.cycognito.com/blog/?p=3031
• ［9］ heise「CVEs: More and better information on vulnerabilities from CISA」（Vulnrichment/SSVCの解説）　https://heise.de/en/background/CVEs-More-and-better-information-on-vulnerabilities-from-CISA-9845597.html?seite=all
• ［10］ Amazon Threat Intelligence（AWS Security Blog, CJ Moses）「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」2026-10-21（10-22更新）　https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• ［11］ The Hacker News「PHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware」2026-10-23　https://thehackernews.com/2026/10/php2shell-exploit-attempts-hit-millions.html
• ［12］ SOCRadar「PHP2Shell (CVE-2026-109618 & CVE-2026-109619)」2026-10-23更新　https://socradar.io/blog/php2shell-cve-2026-109618-cve-2026-109619/
• ［13］ Brandefense「PHP2Shell: Two Critical PHP Flaws Reported as RCE, CVE-2026-109618 and CVE-2026-109619」2026-10-21（10-23更新）　https://brandefense.io/blog/php2shell-php-rce-cve-2026-109618-109619/
• ［14］ SecurityWeek「PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors」　https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/amp/
• ［15］ CybelAngel「2.24M Internet-Facing PHP Hosts, 59% on Versions With No Fix Coming」　https://cybelangel.com/de/blog/critical-php-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/
• ［16］ SC World「CISA advises orgs to patch PHP2Shell bugs immediately」　https://www.scworld.com/news/cisa-advises-orgs-to-patch-php2shell-bugs-immediately
• ［17］ Insurance Business「UK councils and Met Police among sites pulled offline after NCSC alert」　https://www.insurancebusinessmag.com/uk/news/cyber/uk-councils-and-met-police-among-sites-pulled-offline-after-ncsc-alert-594424.aspx
• ［18］ Pasquale Pillitteri「PHP2Shell, Netherlands and Finland switch off government sites before the patch」　https://pasqualepillitteri.it/en/news/26110/php2shell-netherlands-finland-switch-off-government-sites-before-patch
• ［19］ blue News「The php2shell security vulnerability threatens websites—what does that mean?」2026-10-21　https://www.bluewin.ch/en/digital/security-vulnerability-threatens-millions-of-websites-what-does-that-mean-li.3643831
• ［20］ ITmedia NEWS「PHP脆弱性、海外では“政府サイトごと停止”も」2026-10-22　https://www.itmedia.co.jp/news/article/2610/22/2000002514/
• ［21］ Newsweek「PHP vulnerability sparks scramble as major websites face threat」2026-10-21　https://www.newsweek.com/php-vunerability-php2shell-issue-websites-hack-server-12601225
• ［22］ @IT「PHPの重大脆弱性「php2shell」、パッチ公開まで待てない GMOが示した暫定策と注意点」2026-10-21　https://atmarkit.itmedia.co.jp/ait/articles/2610/21/news072.html
• ［23］ ロケットボーイズ セキュリティ対策Lab「php2shell（CVE-2026-109618/109619）」　https://rocket-boys.co.jp/security-measures-lab/php2shell-cve-2026-109618-19/
• ［24］ lilting.ch「php2shellは設定変更では防げないので、PHPの修正版を当てる」　https://lilting.ch/articles/php2shell-official-patch
• ［25］ トラベルボイス「ウェブサイトを動かす「PHP」に重大な脆弱性、国が対応を呼びかけ」2026-10-22　https://www.travelvoice.jp/20261022-160720
• ［26］ zephel01（note）「PHP脆弱性で国内は何を止め、どう戻しているか。22日昼時点の整理」（首相・NCO・JPCERT/CC・IPAの発信、各事業者の告知へのリンクを含む）　https://note.com/zephel01/n/n308e32dbf49e
• ［27］ 日本経済新聞「PHP脆弱性対応で停止した主なサイト一覧 銀行や通信、国税庁・気象庁も」2026-10-22（会員限定記事。全文の閲覧には有料会員登録が必要）　https://www.nikkei.com/article/DGXZQOUC225Z90S6A021C2000000/
• ［28］ 財経新聞「【PHP重大脆弱性】財務省・厚労省も一部サービス停止」2026-10-23　https://www.zaikei.co.jp/article/20261023/874669.html
• ［29］ piyolog「PHPの2件の深刻な脆弱性（CVE-2026-109618、CVE-2026-109619）についてまとめてみた」　https://piyolog.hatenadiary.jp/entry/2026/10/21/174516
• ［30］ マイナビニュース TECH+「PHPの重大な脆弱性、国内で500件超のサービス停止告知、約6割は再開確認できず」2026-10-23（アシュアード調査）　https://news.mynavi.jp/techplus/article/20261023-5180045
• ［31］ Webセキュリティ診断センター「PHP脆弱性で停止・メンテナンス中の国内サービス一覧と被害の報告」2026-10-23更新　https://websec-center.com/blog/kokunai-kigyou-taiou/
• ［32］ Axios「The internet’s hidden security nightmare — and how AI exposed it」2026-10-22　https://www.axios.com/2026/10/22/php-vulnerability-security-update-websites
• ［33］ CSAジャパン ブログ「Mythosレディとは何か ～ 機械速度の攻撃時代における組織生存の条件」2026-05-26　https://cloudsecurityalliance.jp/newblog/2026/05/26/mythos%e3%83%ac%e3%83%87%e3%82%a3%e3%81%a8%e3%81%af%e4%bd%95%e3%81%8b%e3%80%80%ef%bd%9e%e3%80%80%e6%a9%9f%e6%a2%b0%e9%80%9f%e5%ba%a6%e3%81%ae%e6%94%bb%e6%92%83%e6%99%82%e4%bb%a3%e3%81%ab%e3%81%8a/
• ［34］ CSAジャパン ブログ「Mythosレディとは何か（続編-2）　～　VulnOpsとCTEM：継続的脆弱性管理の具体的な実装」2026-06-05　https://cloudsecurityalliance.jp/newblog/2026/06/05/mythos%e3%83%ac%e3%83%87%e3%82%a3%e3%81%a8%e3%81%af%e4%bd%95%e3%81%8b%ef%bc%88%e7%b6%9a%e7%b7%a8-2%ef%bc%89%e3%80%80%ef%bd%9e%e3%80%80vulnops%e3%81%a8ctem%ef%bc%9a%e7%b6%99%e7%b6%9a%e7%9a%84%e8%84%86/
• ［35］ The Hacker News「PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches」2026-10　https://thehackernews.com/2026/10/urgent-php-warns-of-another-unpatched.html
• 36］ CSA・SANS・[un]prompted・OWASP Gen AI Security Project「The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program」2026-04-12（2026-05-20更新）　https://labs.cloudsecurityalliance.org/research/ai-vulnerability-storm-mythos-ready-security-program/
• ［37］ CSAジャパン ブログ「Mythosレディとは何か（続編）　～　Mythosレディにゼロトラストが有効な理由」2026-06-03　https://cloudsecurityalliance.jp/newblog/2026/06/03/mythos%e3%83%ac%e3%83%87%e3%82%a3%e3%81%a8%e3%81%af%e4%bd%95%e3%81%8b%ef%bc%88%e7%b6%9a%e7%b7%a8%ef%bc%89%e3%80%80%ef%bd%9e%e3%80%80mythos%e3%83%ac%e3%83%87%e3%82%a3%e3%81%ab%e3%82%bc%e3%83%ad/

以上

2026年10月17日
AIWGメンバー　諸角昌宏

はじめに

2026年4月19日の本ブログで、CSA、SANS、[un]prompted、OWASP GenAI Security Projectなどが共同でまとめた緊急戦略ブリーフィング「AI脆弱性の嵐（AI Vulnerability Storm）：『Mythosレディ』なセキュリティプログラムの構築」の日本語版を紹介した［1］［2］。Claude Mythos Previewの発表を受けて、AIによる脆弱性の発見と悪用が加速する世界に、組織がどう備えるべきかを示した文書である。

この文書の特徴は、強い危機感と具体的な時間軸にあった。今週着手すること、45日以内、90日以内、12か月以内という区切りで優先アクションを示し、取締役会には「90日計画」を求めた。言い換えれば、「四半期の単位で動かなければ間に合わない」という見立てである。 それから約半年がたった。日本では9月下旬から、不正アクセスによる情報漏えいの公表が連日のように続き、10月にはJPCERT/CCが一連の事案の攻撃者によるAIの利用を確認したと公表した。本ブログでは、4月の文書が何を予測し、何を求めていたかを原文に沿って振り返り、この半年で何が現実になり、何が予測と違ったのかを整理してみたい。

1. 4月の文書は何を予測していたか

原文は、次のような見通しを示していた［2］。

論点	原文の記述（要旨）
能力の拡散	同等の攻撃能力は、他のフロンティアモデルには数か月以内に、オープンウェイトモデルには6か月から1年以内に現れる
悪用までの時間	脆弱性の公開から悪用までの時間は分単位に短縮されている。いわゆる「ゼロデイ・クロック」は2026年に1日を切った
脆弱性の量	脆弱性の公表の頻度と量は、これまでに経験したことのない水準になる
攻撃の担い手	平均的な犯罪者が、かつては国家レベルの資源が必要だった能力を持つようになる
インシデント	同じ週に複数の重大インシデントが同時に起きる事態を想定した机上演習を行うべき
影響	ただし、悪用までの時間の短縮は、まだ悪用の影響の比例的な増大にはつながっていない

最後の一文にも注目しておきたい。4月の時点では、「速度の変化はすでに起きているが、被害の規模にはまだ表れていない」という認識だった。この点が半年後にどう変わったかは、後述するとおり、事故の増加とAIとの関係が明確になっていない現時点では判断できない。

そのうえで文書は、11の優先アクションに着手時期と完了の目安を付けている。

優先アクション	着手	目安
1. コードとパイプラインにAIエージェントを向ける	今週	継続
2. AIエージェントの導入を必須にする	今週	継続
3. 自組織のエージェントを守る	今月	45日
4. イノベーションと加速のガバナンスを整える	今週	6か月
5. 継続的なパッチ適用に備える	今週	45日
6. リスクモデルと報告を更新する	今週	45日
7. アタックサーフェスを棚卸しし、縮小する	今月	90日
8. 環境を堅牢化する	今月	6か月
9. ディセプション（おとり）の能力を作る	90日以内	6か月
10. 自動対応の能力を作る	90日以内	12か月
11. VulnOpsを立ち上げる	6か月以内	12か月

4月から数えれば、45日の目安は5月末、90日の目安は7月中旬にあたる。9月下旬の時点で、アクション3、5、6、7はすでに目安を過ぎ、1と2は着手から5か月がたっている。さらに、6か月が目安のアクション4、8、9も、一連の事案のさなかの10月中旬に期限を迎えている。

2. この半年で現実になったこと

2.1 能力の拡散は、予測どおりか、それより早く進んだ

英国AI安全研究所（AISI）は4月30日、GPT-5.5の初期版の評価結果を公表した。専門家レベルのサイバータスクの平均合格率は、GPT-5.5が71.4%、Mythos Previewが68.6%で、ほぼ同水準だった［3］。IPAの「AIセキュリティ短信」2026年9月号は、AIのサイバー攻撃能力が初めてOpenAIの基準で「Critical」水準に達したことを取り上げている［4］。「他のフロンティアモデルには数か月以内」という予測は、ほぼそのとおりに進んだ。

より注目すべきは、攻撃の現場で使われているAIである。Gambit Securityが9月に公表した暫定報告では、攻撃者は3種類のオープンソースのAIエージェントツールを組み合わせ、脆弱性の探索から侵入、データの持ち出しまでの大部分を自律的に実行させていた。1標的あたりのコストは平均で約25ドルにすぎない［5］。AIエージェントを利用することで、一部の攻撃者が比較的低コストで大規模な攻撃を実行できることが示された。これは高度な攻撃能力の利用コストが低下していることを意味するが、平均的な犯罪者が同等の能力を獲得したとまでは断定できない。

2.2 自律的な攻撃が観測され始めた

Google Threat Intelligence Groupは9月、攻撃者のAI利用が「プロンプトで指示する段階から自律へ」移りつつあるとする報告を公表した［6］。IPAの9月号も、AIエージェント群による政府機関への自律的な侵入や、AIエージェントによって企業への侵入が10時間に短縮された事例を紹介している［4］。

そして国内でも、JPCERT/CCが10月15日、一連の不正アクセス事案で攻撃に使用された可能性のあるインフラを調査した結果、「攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました」と公表した［7］。同日の報道では、AIエージェントの使用や、標的の選定からデータの窃取までが自動化されていた可能性に言及している。ただし公表文書は「AIを利用して」という表現にとどまり、個別の事案との対応や、どこまで自律的だったかは示していない。

2.3 「同時多発」は、日本で起きた

4月の文書が机上演習の題材として挙げた「同じ週に複数の重大インシデント」は、9月下旬以降の日本で、ほぼそのままの形で現れた。Aioright Technologiesの集計では、7月1日から10月4日までに検知または公表された確認済みのサイバー攻撃126件のうち、公表月で見ると8月に47件、9月に57件が集中している［8］。なお、件数は公表単位で数えたもので、全数調査ではなく、公表の時期と発生の時期も一致しない。警察庁によれば、2026年上半期のランサムウェア被害の報告件数も123件で、半期として過去最多となった［9］。

委託先1社への侵害が複数の組織の被害につながる事例も目立った。問い合わせ管理システムの提供会社への不正アクセスでは、証券会社、保険会社、製造業者などが相次いで顧客情報の漏えいの可能性を公表している［10］。4月の文書は「サプライチェーンは影響を受ける」と書いていたが、それが具体的な形で表れた。ただし、こうした事案の増加とAIの利用との因果関係は、現時点では示されていない。

2.4 規制当局は「四半期」より速く動いた

金融庁と日本銀行は5月22日、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得るとして、金融機関等に9項目の短期的な対応を、概ね1か月程度を目途に進めるよう要請した［11］。優先システムの特定、技術負債の解消、リスクベースのパッチ適用、停止への備えなど、内容は4月の文書の優先アクションと大きく重なる。要請自身は、これらを「応急的措置」と位置付け、中長期的には脆弱性対応の自動化等への移行が必要としている。さらに金融庁は10月9日、委託先を含むサードパーティのリスク管理の再点検と、ICチップによる本人確認への早期移行を求めた［12］。

3. 予測と違ったこと

一方で、この半年の出来事は、4月の議論がそのまま現実になったわけではないことも示している。

3.1 機械速度は、最先端のAIを待たずに来た

4月の文書の中心にあったのは、機械速度で動く攻撃と、人間の速度で動く防御との非対称性だった。その速度をもたらすものとして想定されていたのは、Mythosのような最先端モデルによる脆弱性の発見と悪用の加速である。しかし、これまでに公表された攻撃で使われていたのは、オープンソースのエージェントツールや一般に利用できるAIだった。機械速度の攻撃は、最先端モデルの能力が広く行き渡るのを待たずに、手頃なAIと既存の手口の組み合わせで現実になった。

3.2 突かれたのは、多くが以前からある弱点だった

JPCERT/CCが確認したAIの用途は、既知の脆弱性のスキャンと、スマートフォンアプリを解析してその裏側にあるAPIの弱点を探す行為だった［7］。推奨している対策も、アプリに秘密鍵を埋め込まない、サーバー側で認証・認可を行う、レート制限と監視を行うといった基本的なものである。Gambit Securityの事例でも、使われたのはSQLインジェクションやファイルアップロード機能の不備、設定ファイルに残された認証情報だった［5］。注意喚起の対象には公開前に悪用された脆弱性に関わるものも含まれるが［13］、全体として見れば、AIが未知の脆弱性を見つけて侵入したというより、既知の弱点を探して突く作業が速く、安く、大規模になったと見る方が実態に近い。

3.3 入口は、自社の中心ではなく周辺にあった

金融分野では、9月下旬以降に公表された主な事案の入口が、自社の中心的なシステムではなく、委託先や周辺のシステムだった［10］［14］［15］。

事案（公表時期）	入口（公表時点）	5月の要請との関係
大和証券、損保ジャパン、オリックス生命（10月5〜8日）	問い合わせ管理を委託していたFAQシステムの管理サイトへの不正ログイン（アカウントの入手経路は未公表）	要請は優先システムを絞り込む構成で、周辺業務の委託先は対象に入りにくい
IDARE（キャッシュレスアプリ、10月中旬）	顧客対応などに使う外部ソフトウェアの脆弱性（ソフトウェア名は非公表）	要請には、外部のソフトウェアやサービスに預けた顧客データの扱いについての記述がない
内藤証券、大和総研（10月15日）	運用を委託しているネット取引システムのWebサーバー（侵入経路は調査中）	要請が最優先とした外部公開システム。ただし委託先に関する項目は、パッチ適用作業の契約と役割分担の確認にとどまる

5月22日の短期的要請では、脆弱性への迅速な対応や重要な外部公開システムの保護が重点的に取り上げられた［11］。一方、今回の事案は、委託先や周辺システムに預けた顧客データまで含めて、組織全体のアタックサーフェスとリスクを把握する必要性を改めて示した。なお、金融庁は別途、「金融分野におけるサイバーセキュリティに関するガイドライン」でサードパーティリスク管理を求めており［17］、5月の要請だけをもって委託先対策が欠落していたと評価することは適切ではない。10月9日の注意喚起でも、このガイドラインなどを踏まえ、委託先を含むサードパーティのリスク管理の再点検をあらためて求めている［12］。

一方で、筆者が確認した範囲では、それ以外の部分、つまり銀行の基幹系やインターネットバンキングなど、要請が最優先とした金融機関自身の中核システムが直接破られたという公表は見当たらない。公表がないことは被害がないことを意味しているわけではないし、これを要請の効果と断定する材料もないが、守りを固めるよう求められた中心部ではなく、その外側から入られたという構図ははっきりしている。4月の文書のアクション7（アタックサーフェスの棚卸しと縮小）は、自社のシステムだけでなく、委託先や外部に預けたデータまでを範囲に含めなければならない。

4. 「四半期の行動」は間に合ったのか

では、4月の文書が求めた行動は、この半年に間に合ったのだろうか。各組織がどこまで実行したかを示す資料はなく、実行した組織の被害が少なかったかどうかも検証できない。ただ、9月以降に突かれた弱点と、優先アクションを並べてみると、どの行動が問われたのかは見えてくる。

9月以降の事案で問われたこと	対応する優先アクション	4月時点の目安
既知の脆弱性の放置	5. 継続的なパッチ適用に備える	45日
公開されたAPI、アプリ、委託先のシステムの把握漏れ	7. アタックサーフェスの棚卸しと縮小	90日
認証情報の悪用、横展開	8. 環境の堅牢化（フィッシング耐性MFA、セグメンテーション）	6か月
影響範囲と復旧速度の評価	6. リスクモデルと報告の更新	45日
大量・短時間のアクセスの検知と遮断	10. 自動対応の能力	12か月

問われたのは、新しいAI防御の仕組みではなく、45日から90日で終えるはずだった基本だった。4月の文書が「基本への集中を強めよ」をKey Takeawaysの一つに掲げていたことを、改めて思い起こしたい。

まだ基本ができていない組織へ

この半年で最も大きく変わったのは、攻撃の費用である。1標的あたり約25ドルで自動化された攻撃を仕掛けられるのであれば［5］、「うちは狙われるほどの価値がない」という前提は成り立たなくなりつつある。警察庁の統計でも、2026年上半期のランサムウェア被害123件のうち79件は中小企業だった［9］。規模や業種にかかわらず、基本の穴がある組織は、手頃なAIによる網羅的な探索の対象になると考えるべきである。

4月の文書が45日から90日で求めた基本が、まだできていない組織は少なくないはずだ。そうした組織に必要なのは、次の四半期の計画を立てることよりも、今すぐ着手することであると考える。少なくとも次の点は、新しい製品を導入しなくても速やかに取り組める内容である。

• 外部から見えるものを棚卸しする：Webサイト、管理画面、API、スマートフォンアプリ、VPN機器に加え、委託先のシステムに預けている顧客データも対象に含める
• 既知の脆弱性を塞ぐ：特に、すでに悪用が確認されている脆弱性（KEV）を優先して修正する［16］
• 認証を固める：管理画面と特権IDに多要素認証を導入し、使われていないアカウントやテスト環境を削除する
• APIとアプリを見直す：アプリに秘密鍵や長期間有効な認証情報を埋め込まない。サーバー側で認証・認可を行い、レート制限と異常なアクセスの監視を設ける［7］
• 持たなくてよいデータを捨てる：退会者の情報や、目的を終えた本人確認書類の画像など、保有し続ける理由のないデータを削除する

この5項目は、全体として、JPCERT/CCが一連の事案を受けて推奨した対策や、4月の文書の優先アクション5、7、8と重なる。攻撃が機械速度で網羅的に行われる以上、守りの穴は「いつか見つかる」のではなく「すぐに見つかる」と考えて動く必要がある。

5. まとめ：短期の対応が必要だという見立ては裏付けられた

4月の文書が示した短期間での対応の必要性は、この半年に観測されたAI利用攻撃の進展によって、改めて裏付けられた。一方、日本で相次いだインシデントがすべてAIの普及によって引き起こされたと結論づけることも難しい。今回明らかになったのは、攻撃の自動化が進む環境において、従来から存在する脆弱性や認証・認可の不備への対応を先送りできなくなっていることである。問われたのは、先送りしてきた基本であった。

次の半年に向けて考えておくべきことが二つある。第一に、オープンウェイトモデルが同等の能力に達するという「6か月から1年」の時期に、いま入りつつある。攻撃の民主化はさらに進む前提で備える必要がある。第二に、4月の文書が6か月から12か月の目安としていたアクション、つまり環境の堅牢化、ディセプション、自動対応、そしてVulnOpsの立ち上げが、これから本番を迎える。

Mythosレディとは、一度到達すれば終わる状態ではない。次の四半期に何をするかを、四半期ごとに見直し続けることである。半年前の文書は、そのことを予告していたといえる。

参考資料

• ［1］CSAジャパンブログ「『AI脆弱性の嵐 (AI Vulnerability Storm)』：『Mythosレディ』なセキュリティプログラムの構築」を公開しました。（2026年4月19日）
  https://cloudsecurityalliance.jp/newblog/2026/04/19/%e3%80%80%e3%80%8cai%e8%84%86%e5%bc%b1%e6%80%a7%e3%81%ae%e5%b5%90-ai-vulnerability-storm%e3%80%8d%ef%bc%9a-%e3%80%8cmythos%e3%83%ac%e3%83%87%e3%82%a3%e3%80%8d%e3%81%aa%e3%82%bb%e3%82%ad%e3%83%a5/
  
• ［2］Cloud Security Alliance, The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program, v1.0（2026年4月）
  https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/mythosreadyv95.pdf
  
• ［3］AI Security Institute, Our evaluation of OpenAI’s GPT-5.5 cyber capabilities（2026年4月30日）
  https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities
  
• ［4］IPA「AIセキュリティ短信」2026年9月号
  https://www.ipa.go.jp/digital/ai/security/ai-security-bulletin.html
  
• ［5］Gambit Security, AI Agents Are Hacking Online Retailers for $25 a Company（2026年9月22日、暫定報告）
  https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company
  
• ［6］Google Threat Intelligence Group, GTIG AI Threat Tracker: From Prompting to Autonomy（2026年9月8日）
  https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai
  
• ［7］JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
  https://blogs.jpcert.or.jp/ja/2026/10/web_api_attacks.html
  
• ［8］Aioright Technologies「2026年7〜10月 国内サイバーセキュリティ事案143件の統計分析」（2026年10月6日）
  https://www.aioright.jp/resources/domestic-cybersecurity-incidents-jul-oct-2026/
  
• ［9］警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（2026年9月10日）
  https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08_kami_cyber_jousei.pdf
  
• ［10］piyolog「スカラコミュニケーションズへの不正アクセスについてまとめてみた」（2026年10月7日）
  https://piyolog.hatenadiary.jp/entry/2026/10/07/120750
  
• ［11］金融庁・日本銀行「『フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応』に係る要請について」（2026年5月22日）
  https://www.fsa.go.jp/news/r7/sonota/20260522-5/01.pdf
  
• ［12］JAPANSecuritySummit Update「金融庁、不正アクセス相次ぎ金融機関に対策強化を要請」（2026年10月10日）
  https://japansecuritysummit.org/2026/10/15034/
  
• ［13］piyolog「国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた」（2026年10月11日）
  https://piyolog.hatenadiary.jp/entry/2026/10/11/004353
  
• ［14］innovatopia「銀のさら運営会社・アエナ・IDAREなど不正アクセス15件、10月13〜14日の公表を整理」
  https://innovatopia.jp/cyber-security/cyber-security-news/118908/
  
• ［15］セキュリティ対策Lab「内藤証券のネット取引システムに不正アクセス、最大631名の個人情報漏えいの可能性」
  https://rocket-boys.co.jp/security-measures-lab/security-measures-lab-naito-securities-daiwa-research-unauthorized-access/
  
• ［16］CSAジャパンブログ「Mythosレディとは何か ～ 機械速度の攻撃時代における組織生存の条件」（2026年5月26日）
  https://cloudsecurityalliance.jp/newblog/2026/05/26/mythos%E3%83%AC%E3%83%87%E3%82%A3%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B%E3%80%80%EF%BD%9E%E3%80%80%E6%A9%9F%E6%A2%B0%E9%80%9F%E5%BA%A6%E3%81%AE%E6%94%BB%E6%92%83%E6%99%82%E4%BB%A3%E3%81%AB%E3%81%8A/
  
• ［17］金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」2.6 サードパーティリスク管理（2024年10月4日）
  https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf

以上

2026年10月16日更新
2026年10月9日更新
2026年10月7日初版
AIWGメンバー　諸角昌宏

【2026年10月16日 更新】10月16日分を赤色で示す。10月16日更新内容は、JPCERT/CCによる攻撃者のAI利用の確認（第4章、第12章）部分である。結論と3層の整理は変更していない。

【2026年10月9日 更新】初版の公開後に確認した情報を追記した（緑字で示す）。追記したのは、警察庁の2026年上半期の統計、AIの悪用を指摘する報道とGambit Securityの報告、金融庁・日本銀行の要請である。結論と3層の整理は変更していない。

2026年に入り、日本国内でサイバー攻撃や情報漏洩、ランサムウェア、不正アクセスなどの情報セキュリティ事故が相次いで公表されている。特に夏から秋にかけては、企業、大学、公共機関などさまざまな組織からインシデントが公表され、「最近、セキュリティ事故が増えているのではないか」と感じる機会が多くなった。一方、2026年は生成AIやAIエージェントの利用が急速に広がった年でもある。そこで気になるのが、「最近のセキュリティ事故の多発とAIの普及には関係があるのか」である。

本ブログでは、警察庁、IPA、Verizon、IBM X-Force、Google Cloud/Mandiantなどの公開情報、および国内の民間調査を基に、この問題を整理する。そのうえで、CSAジャパンブログに掲載された筆者の「Mythosレディ」シリーズで示した3層（基本対策、ゼロトラスト、VulnOps / CTEM）に沿って、対策をまとめてみる。

本当にセキュリティ事故は増えているのか

最初に注意しなければならないのは、「ニュースで目にする事故が増えた」ことと「実際のインシデント発生率が増えた」ことは同じではないという点である。デジタルアーツ株式会社が、対象組織による公開報告書およびマスメディアの報道資料を基に独自集計した「2026年上半期国内セキュリティインシデント集計」によれば、2026年1～6月に情報漏えい等のセキュリティインシデントによる被害・影響を公表した国内組織は727件であった。このうち「不正アクセス」が267件で最も多く、「マルウェア感染」が153件でこれに続いている［1］。ただし、この727件は727回の独立したサイバー攻撃を意味するものではない。同調査では、例えば委託先1社への攻撃によって複数の委託元企業が被害を公表した場合、それぞれの公表組織を1件として計上している。したがって、「国内で727回のサイバー攻撃が発生した」と読み替えることは適切ではない。

さらに、もう一つ注意すべき点がある。攻撃の発生日と公表日は一致しない、ということである。調査に数週間から数カ月を要した後に公表されるケースもあるため、特定の月に公表が集中したからといって、その月に攻撃そのものが急増したとは限らない。 警察庁のランサムウェア統計を見ても、この点は興味深い。企業・団体等から警察庁に報告されたランサムウェア被害は、次のとおりである。［6］

年	報告件数
2021年	146件
2022年	230件
2023年	197件
2024年	222件
2025年	226件

【10/9更新】2024年の222件から2025年は226件であり、大幅な増加ではない。したがって、「最近になって突然ランサムウェアが爆発的に増加した」というより、高い攻撃水準が数年間継続していると表現する方が正確である。［6］

【10/9更新】ただし、2026年に入ってこの水準はさらに上がっている。警察庁が2026年9月10日に公表した上半期の統計では、ランサムウェア被害の報告件数は123件で、統計を取り始めた2020年下半期以降、半期として最多となった［14］。2025年は上半期が116件、下半期が110件だったので、急増とまでは言えないが、高止まりから増加に転じた可能性がある。 被害組織の内訳は、規模別では中小企業79件、大企業31件、団体等13件である。業種別では製造業が37件で最も多く、卸売・小売業15件、情報通信業、不動産・物品賃貸業、医療・福祉が各9件、建設業8件、その他36件と続く［14］。特定の規模や業種に限られた問題ではないと思われる。

日本だけで起きている現象なのか

この傾向は日本だけに限らない。Verizonの「2026 Data Breach Investigations Report（DBIR）」では、31,000件を超えるセキュリティインシデントと22,000件を超えるconfirmed data breachが分析対象となった。前年の2025 DBIRではconfirmed breachは12,195件だったため、分析対象件数自体は大きく増えている［7］［8］。ただし、DBIRは世界中の法執行機関、セキュリティ企業、保険会社などから提供されたデータを集約している。そのため、この数字をそのまま「世界の侵害件数が約80%増加した」と解釈することはできない。重要なのは攻撃方法の変化である。2026 DBIRでは、脆弱性悪用が31%を占め、初期侵入経路として初めて盗用された認証情報を上回った。［8］

IBM X-Forceの2026 Threat Intelligence Indexでも、2025年には公開アプリケーションの脆弱性悪用を起点とした攻撃が前年比44%増加したと報告されている。また、活動しているランサムウェア／恐喝グループも増加している［9］。つまり世界的に、次の4つが引き続き大きな問題となっている。

• 脆弱性悪用
• ID・認証情報の悪用
• ランサムウェア／恐喝
• サプライチェーン攻撃

日本の最近の事故では何が狙われているのか

では、日本国内で2026年に公表された最近のインシデントでは、どのような侵入経路が使われているのだろうか。2026年夏以降については、Aioright Technologies株式会社が、2026年7月1日から10月4日までに国内で検知または公表された143件を公開情報に基づいて集計している［2］。このうち126件が確認済みのサイバー攻撃と分類され、不正アクセスが74件（58.7%）を占めている。さらに重要なのが初期侵入経路である。126件中、初期侵入経路を公開情報から分類できたのは58件であり、その内訳は次のようになっている。

初期侵入経路	件数	割合
脆弱性悪用	23件	39.7%
ID・認証関連	20件	34.5%
サプライチェーン	11件	19.0%
設定・実装不備	2件	3.4%
マルウェア感染	2件	3.4%
合計（分類できた事案）	58件	100.0%

つまり、侵入経路を分類できた58件に限れば、脆弱性悪用＋ID・認証関連＝43件、74.1%になる［2］。ただし、この数字についても注意が必要である。確認済みサイバー攻撃126件のうち68件（54.0%）は、初期侵入経路が不明または非公表である。そのため、「日本国内のサイバー攻撃の74.1%が脆弱性またはIDを原因としている」という意味ではない。あくまで、「公開情報から侵入経路を分類できた58件では、74.1%が脆弱性悪用またはID・認証関連だった」と解釈する必要がある。つまり、公開情報から侵入経路を分類できた事案では、脆弱性とIdentityが主要な侵入要因となっているということである。

これは警察庁の過去のランサムウェア調査とも整合する。2024年にランサムウェア被害を受けた企業等へのアンケートでは、侵入経路としてVPN機器が55%、リモートデスクトップが31%を占めていた［10］。ここから見えてくるのは、極めて「従来型」の問題である。VPNやネットワーク機器の脆弱性、盗まれた認証情報、弱い認証、過剰なアクセス権限、委託先やサプライチェーン。これらはAIが登場する以前から存在していた問題である。

ではAIは関係ないのか

ここが今回の問題を考えるうえで最も重要なポイントである。

【10/9更新】2026年に日本で公表された主要インシデントを確認しても、「攻撃者が生成AIやAIエージェントを利用したため侵害された」と明確に公表された事案は、確認した範囲では見つからなかった。したがって、「2026年に日本でセキュリティ事故が増えているのはAIのせいである」と結論づける根拠は、現時点では確認されていない。

【10/9更新】2026年10月に入り、相次ぐ情報漏えいの背景にAIの悪用があるとみる報道や専門家の指摘が増えている。しかし、筆者が確認した範囲では、これらは状況からの推測であり、被害組織がAIの使用を公式に認めた国内事案は見当たらない。指摘されていることと、確認されていることは区別しておきたい。

【10/16更新】その後、JPCERT/CCは2026年10月15日、一連の事案で攻撃に使用された可能性のあるインフラを調査した結果、「攻撃者がAIを利用して、既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました」と公表した［17］。一連の事案に関わる攻撃者がAIを利用していたことが、調査に基づいて確認されたことになる。

【10/16更新】ただし、この記述には限定がある。同記事は、調査したインフラと個別の事案との対応を示しておらず、調査対象の一部は「今回の攻撃とは直接関係しない別のサーバー」としている。また、一部の報道では「AIエージェント」の使用とも伝えられているが、JPCERT/CCの記事は「AIを利用して」とするにとどまり、AIが自律的に攻撃を進めていたかどうかには触れていない。したがって、「一連の事案はAIエージェントによるものだ」とまでは言えない。

【10/16更新】むしろ注目すべきは、AIが何に使われていたかである。JPCERT/CCが確認したのは、既知の脆弱性のスキャンや、スマートフォンアプリを解析してその裏側にあるAPIの弱点（SSRFなど）を探る行為だった。推奨している対策も、アプリに秘密鍵や長期間有効な認証情報を埋め込まない、サーバー側で認証・認可を行う、レート制限と異常なリクエストの監視を行う、といった基本的なものである［17］。AIは新しい攻撃を生み出したのではなく、既存の弱点を探し突く作業に使われていたということになる。

しかし、「AIはサイバー攻撃に関係していない」という結論も正しくない。IPAは2026年の「AIセキュリティ短信」などで、次のような動きを取り上げている［11］。

• AIエージェント群による自律的な侵入
• AIを利用した攻撃コード生成
• AI支援によるマルウェア開発
• LLMを利用した金融不正
• AIエージェントによる企業侵入時間の短縮

つまり、AIを攻撃に利用する動き自体はすでに現実のものとなっている［11］。

AIは「原因」ではなく「脅威増幅要因(Threat Multiplier)」

この状況を理解するには、AIを新しい攻撃手法そのものと考えない方がよいと思われる。AIが大きく変えようとしているのは、次の3点である。

• Speed（速度）
• Scale（規模）
• Automation（自動化）

例えば従来の脆弱性攻撃では、次のプロセスが必要だった。

AIやAIエージェントを利用すれば、この一部を自動化できる可能性がある。同じことはフィッシングにも当てはまる。生成AIを利用すれば、大量のメールを作るだけでなく、標的に合わせた自然な文章を短時間で作成できる。

【10/9更新】この変化を具体的に示す報告がある。Gambit Securityは2026年9月、ある攻撃者の中継サーバーを分析した暫定報告を公表した［15］。それによると、攻撃者は3種類のオープンソースのAIツールを組み合わせ、脆弱性の探索から侵入、データの持ち出しまでの大部分を自律的に実行させていた。260セッションで人間が入力した指示は1,951件にとどまる。6日間に105件の攻撃が開始され、少なくとも27社で侵害が確認された。1標的あたりのコストは、完了した101件の平均で約25ドルである。

【10/9更新】注目すべきは、そこで使われた手口である。SQLインジェクション、ファイルアップロード機能の不備、設定ファイルに残された認証情報など、いずれも以前から知られている弱点だった。変わったのは手口ではなく、それを試す速度と規模、そしてコストである。なお、これは1つの攻撃グループに関する暫定的な調査結果である。被害例には日本の旅行予約サイトも含まれるが、本ブログで見た国内の公表事案との関係は確認されていない。

つまりAIは、新しい脆弱性を生み出しているというより、既に存在する脆弱性を攻撃する能力を増幅していると考える方が現状を説明しやすい。この意味でAIは、Root Cause（根本原因）ではなく、Threat Multiplier（脅威増幅要因）と位置付けるのが適切である。

「AI普及」と「事故増加」の因果関係は証明されていない

ここでは相関関係と因果関係を区別する必要がある。現在、AI利用の拡大と同時に、次のような動きが観測されている。

• 脆弱性探索の高速化
• 攻撃コード生成支援
• フィッシング高度化
• マルウェア開発支援
• AIエージェントによる攻撃自動化

また日本では、不正アクセス、ランサムウェア、情報漏洩など多数の事故が公表されている。しかし、AI利用の増加→日本のセキュリティ事故件数の増加という因果関係を直接示す統計は、現時点では存在しない。

Mandiantも2026年のM-Trendsにおいて、2025年を「AIが直接breachを引き起こした年」とは位置付けていない。一方で、攻撃者が偵察、ソーシャルエンジニアリング、マルウェア開発などでAIを利用し、生産性を向上させていることは確認している。この区別は非常に重要である［12］。

本当に変わりつつあるのは「時間」である

AI時代のサイバーセキュリティで特に注目すべきと考えるのは、攻撃件数そのものよりも、攻撃に必要な時間の短縮であると考える。これまで防御側には、次のプロセスに充てる一定の時間があった。

しかし攻撃側の脆弱性探索、分析、攻撃コード生成、対象探索がAIによって高速化すると、脆弱性が攻撃可能になるまでの時間が短くなる。これは防御側にとって非常に大きな意味を持つ［8］［12］。「毎月脆弱性スキャンを実施する」「年に数回ペネトレーションテストを実施する」といった周期型の脆弱性管理では、攻撃側の速度についていけなくなる可能性がある。

対策をどう整理するか ― 「Mythosレディ」の3層

では、攻撃側の時間軸が変わりつつある状況で、防御側は何から手を付ければよいのか。ここでは、CSAジャパンブログに掲載した筆者の「Mythosレディ」シリーズ［3］［4］［5］で示した3層に沿って整理したい。

同シリーズは、Anthropicが2026年4月に発表したClaude Mythos Previewを契機に、機械速度の攻撃が常態化する世界で組織が取るべき対策を論じたものである。そこでは、「Mythosレディ」を特定のAIツールへの対抗策としてではなく、背後にある構造的リスクに継続的に適応し続けられる組織の状態として捉えた［3］。これは、AIを根本原因ではなく脅威増幅要因と見る本ブログの立場と一貫している。

【10/9更新】規制当局も同じ問題意識で動いている。金融庁と日本銀行は2026年5月22日、脆弱性の発見から攻撃に至るまでの期間が大幅に短縮され得るとして、金融機関等に9項目の短期的な対応を要請した［16］。優先的に対応すべきサービスやITシステムの特定、技術負債の解消、リスクベースのパッチ適用、パッチ適用以外の対策の強化、停止への備えなどであり、以下に示す3層と重なる内容である。

同シリーズで示した対策は、次の3層である。

この3層は、上から順に完成させていくものではなく、同時並行で育てていくものである。以下、順に見ていきたい。

第1層：基本対策 ：　まず基本の穴を塞ぐ

シリーズ第1回［3］では、Mythosレディへの第一歩を、新しいAI防御製品の導入ではなく、基本的なセキュリティの強化に置いた。その前提にあるのは、情報セキュリティの目的を「コントロール可能にすること」と捉える考え方である［3］。攻撃を完全に防ぐことはできなくても、影響を封じ込め、回復し、次に備えられる状態を保つことはできる。そして攻撃者は最も弱い点を狙うため、高度な対策より先に基本の穴を塞ぐ必要がある。 同ブログでは、今すぐ取り組む基本強化として5つの領域を挙げた。本ブログで見た国内事案と対応させると、次のようになる。

領域	主な内容	国内事案との関係
資産管理	IT資産、SBOM、シャドーIT、AIエージェント資産を継続的に把握する	把握していないVPN機器や公開サーバーは、修正も監視もできない
ネットワークセグメンテーション	機能・リスク別に分離し、横展開を遮断する	侵入後の被害拡大（ランサムウェアの全社展開など）を抑える
パッチ管理の継続化	CVSSではなくKEVなど実際の悪用状況で優先する。同ブログでは、クリティカルパッチについて24時間以内の適用を目標例としている	脆弱性悪用（39.7%）、VPN機器経由の侵入（55%）
IAM	最小権限の徹底、過剰権限の棚卸し、フィッシング耐性MFAの展開。AIエージェントにも最小権限を適用する	ID・認証関連（34.5%）、リモートデスクトップ経由の侵入（31%）
多層防御の再設計	単一の対策に依存しない設計、egressフィルタリング、継続的モニタリング	一つの防御が破られた後の検知と、情報持ち出しの抑止

上記「日本の最近の事故では何が狙われているのか」で見た「従来型」の問題は、ほぼこの5領域に収まる。AI時代だからといって特別な対策が先に必要になるわけではない。AIによって増幅されるのは既存の弱点への攻撃であり、だからこそ基本対策の価値はむしろ高まっている。

第2層：ゼロトラスト ：　 侵入されても到達させない

基本対策を講じても、脆弱性悪用 → 侵入、あるいは認証情報窃取 → 正規アカウントによる侵入そのものを完全になくすことは難しい。したがって、「侵入させない」だけではなく「侵入されても重要資産まで到達させない」設計が重要になる。

ここでZero Trustの考え方が生きてくる。プロテクトサーフェスを明確にし、Identity、Device、Network、Application、Dataを継続的に評価し、最小権限を適用する。さらにマイクロセグメンテーションなどによって、侵害されたアカウントや端末から重要資産への横展開を抑制する。

シリーズ第2回［4］では、Mythosレディにゼロトラストが有効な理由を説明した。ゼロトラストは攻撃を完全に防ぐ手段ではなく、攻撃の難度を引き上げ、侵入から被害拡大までの時間を引き延ばすことで、人間が対応できる時間を確保する戦略と位置付けられる。攻撃側の時間が短縮されるのであれば、防御側は侵入後の時間を取り戻す設計を持つ必要がある。 委託先やサプライチェーン経由の侵入（19.0%）のように、正規の経路や正規のアカウントが使われる場合にも、アクセスのたびに検証し、到達範囲を限定する設計は有効に働くと思われる。

第3層：VulnOps / CTEM ― 悪用される前に発見し、修復する

ゼロトラストが侵入後の被害を限定する層だとすれば、第3層は侵入される前のExposureを減らす層である。VulnOpsが脆弱性の継続的な発見・優先順位付け・修復を担うのに対し、CTEM（Continuous Threat Exposure Management）は脆弱性だけでなく、設定、権限、攻撃経路などを含むExposure全体を継続的に評価・低減する枠組みである。シリーズ第3回［5］では、この両者をMythosレディの中核に位置付けた。

「毎月スキャンする」「年に数回ペネトレーションテストを実施する」といった周期型の脆弱性管理は、攻撃側に時間がかかることを暗黙の前提としていた。従来型の脆弱性管理は、Find → Patchという考え方になりやすかったが、実際には、すべての脆弱性を直ちに修正することはできない。そこで必要になるのが、継続的な運用である。GartnerのCTEMは、Scoping、Discovery、Prioritization、Validation、Mobilizationの5フェーズで定義されている。次に示すのはその5フェーズそのものではなく、VulnOps / CTEMを実装する際の本ブログでの運用例である［13］。

CVSSだけを見るのではなく、次の点を評価して、修復の優先順位を決める必要がある。

• 実際にInternetから到達可能なのか
• 既に悪用されているのか
• 重要なプロテクトサーフェスにつながっているのか
• 攻撃経路として成立するのか
• どの程度の業務影響があるのか

これは、第1層の「パッチ管理の継続化」を、攻撃側の速度に合わせて常時回り続ける運用へ発展させたものと言える。AIによって攻撃側のサイクルが高速化するのであれば、防御側も同じように継続的なサイクルへ移行する必要がある。

まとめ：AI時代に変えるべきなのは防御側の「時間軸」

ここまでを整理すると、2026年に相次いで公表されている日本のセキュリティ事故について、AIが直接的な原因であることを示す証拠は現時点では確認できない。実際に確認できる主要な侵入経路は、脆弱性、Identity、サプライチェーンなど、以前から存在していたものである。

【10/16追記】JPCERT/CCが攻撃者によるAIの利用を確認した後も、この整理は変わらない。確認されたのは、AIを使って既知の脆弱性やAPIの弱点を探し突く行為だったからである［17］。AIが攻撃に使われていることは事実になったが、突かれているのは依然として以前から存在する弱点である。

一方で、AIが攻撃者の能力を増幅し、探索、分析、攻撃コード生成、ソーシャルエンジニアリング、侵入後活動などを高速化・自動化し始めていることも事実である［8］［9］［11］［12］。

したがって、「AIによってサイバー事故が増えた」と単純化するのではなく、「AIによって攻撃側の時間軸が変わり始めている」と捉える方が適切ではないだろうか。そして問題はAIそのものだけではない。攻撃側の時間軸が変わっているにもかかわらず、防御側が、月次スキャン、四半期レビュー、年次リスク評価という従来の時間軸のままでよいのか、という問題である。AI時代のセキュリティ対策で求められているのは、単に「AIを使ったセキュリティ製品」を導入することではない。「Mythosレディ」の3層に沿って言えば、次の3つを同時並行で進めることである。

Mythosレディは、一度到達すれば終わる状態ではない。攻撃側の速度に合わせて適応し続けられる状態を保つことであり、その出発点は、国内事案のデータが示すとおり、基本対策にある。

参考資料

民間調査

［1］デジタルアーツ株式会社「2026年上半期国内セキュリティインシデント集計」2026年7月28日公開

［2］Aioright Technologies株式会社 2026年7〜10月 国内サイバーセキュリティ事案143件の統計分析――攻撃種別・対象・侵入経路の全体像」　2026年10月6日公開

CSAジャパン ブログ（「Mythosレディとは何か」シリーズ）

［3］CSAジャパンブログ「Mythosレディとは何か ～ 機械速度の攻撃時代における組織生存の条件」　2026年5月26日公開

［4］CSAジャパンブログ　「Mythosレディとは何か（続編）～ Mythosレディにゼロトラストが有効な理由」　2026年6月3日公開

［5］CSAジャパンブログ　「Mythosレディとは何か（続編-2）～ VulnOpsとCTEM：継続的脆弱性管理の具体的な実装」　2026年6月5日公開

公的機関・ベンダー一次資料

［6］警察庁「令和7年におけるサイバー空間をめぐる脅威の情勢等について」

［7］Verizon, 2025 Data Breach Investigations Report（公表資料）

［8］Verizon, 2026 Data Breach Investigations Report（公表資料）

［9］IBM X-Force, 2026 Threat Intelligence Index

［10］警察庁「令和7年版 警察白書」第3項 ランサムウェアの情勢

［11］IPA「AIセキュリティ短信」

［12］Google Cloud / Mandiant, M-Trends 2026

［13］Gartner, Strategic Roadmap for Continuous Threat Exposure Management

［14］警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（2026年9月10日公表）

［15］Gambit Security, AI Agents Are Hacking Online Retailers for $25 a Company（2026年9月22日、暫定報告）

［16］金融庁・日本銀行「フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応」に係る要請について（2026年5月22日）

［17］JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）

補足資料

IPA「情報セキュリティ白書2026」

Google Threat Intelligence Group, AI Threat Tracker: From Prompting to Autonomy（2026-09-08）

以上