AI対AIによる攻撃と防衛。セキュリティもAIに任せたらと思うけど、実態は・・・。

AIを使った日本企業への攻撃「ARTEX」や、PHPの重大脆弱性による大量のサイト停止をきっかけに、「セキュリティもAIにやらせればいいのでは？」という問いから始まった一問一答です。
AI対AIの攻防の実情、保守費用の捻出方法、これからのWEB制作のあり方まで掘り下げました。

AI対AIの防御は現実的か？ARTEXが示す攻撃の実態

　今回はセキュリティについて考えてみたい。何を考えるか、というと、ARTEXなど、AIを使って日本国内の企業のサーバーに攻撃や侵入を繰り返し、個人情報を盗んだり、操作したり、といった被害が出ている。AIの台頭によって攻撃方法もハードルが下がっている印象があるし、逆にセキュリティの難しさはハードルが上がっている感じがする。そこで、パッと思いつくのは、セキュリティもAIがやればいいんじゃ、という点なんだが、どう思う？

結論から言うと、方向性としては正しいし、実際もうそうなり始めている。でも「AIがやればOK」で安心できるほど単純でもない、というのが実感に近い。

まず今の実態から。ARTEXの件、GMOサイバーセキュリティ byイエラエが10月19日に発表した調査では、日本企業を狙った不正アクセスの攻撃元インフラを調べた結果、AIによる自律型ペネトレーションテストシステム「ARTEX」が使われていたことを確認し、標的は日本企業約20社、同種のAI攻撃インフラも6台見つかったという（出典：ビジネス+IT）。

さらに追加調査では日本企業約80社が標的となり、うち8社が情報漏洩を公表とも報じられている（出典：coki）。もともとは中国語話者の開発者が学習・研究目的でGitHubに公開したオープンソースの侵入テストツールで、MicrosoftやCrowdStrikeも悪用例を報告しており、作者は公開を停止したが改変版が増殖している状況（出典：ITmedia AI＋）。つまり「攻撃側がAIを使う」のはもう仮説ではなく現在進行形。

その上で「防御もAIで」という流れも、すでに実装フェーズに入っている。
NTTドコモビジネスは2026年5月にAI Advisorによるログ分析とマネージドSOARによる自動対処を組み合わせたAI SOCサービスを開始し、従来1〜2時間かかっていた相関分析を約10分で行えるとしている（出典：NTTドコモビジネス）。

CTCも10月からAIエージェントが脅威の検知・調査・対応案の提示までを自律的に行うAgentic SOC Platformの国内展開を開始した（出典：CTC）。業界全体としても、エージェント型AI SOCはアラートよりも攻撃そのものを自律的に優先順位付けし、閉ループでの封じ込めを実行する点が、従来の「AIが提案し人間が承認する」モデルとは異なると位置づけられている（出典：Elastic Security Labs）。

ここで考えておきたい論点が3つある。

1. 攻撃側と防御側は対称じゃない

攻撃側は無数の穴の中から「1つ」見つければ勝ちだけど、防御側は全部の穴を塞がないといけない。
AIで検知・対応のスピードを上げることはこの非対称性を緩和はするけど、ゼロにはしない。
むしろAIで攻撃の試行回数・速度が上がる分、防御側もスピードで追いつかないと差が開く、という構図。

2. 「AIに守らせる」こと自体が新しいリスクになる

自律的に判断・実行するAIエージェントは、裏を返せば攻撃対象が増えるということでもある。
プロンプトインジェクションのような「エージェント自体への攻撃」や、判断根拠が見えにくい「ブラックボックス化」が実務上の課題として挙がっていて、Cloud Security Allianceも自律的な意思決定には重大な制約があると指摘している（出典：Cloud Security Alliance（remio.ai））。完全に任せて終わり、ではなく「どこまで自律させるか」の設計が要る。
実際、業界の整理では自律対応はアラート通知のみの人間判断から、AIが提案し人間が承認、定型対応はAI自律で例外のみ人間、完全自律型まで段階があるとされていて、多くの企業は中間段階からスタートしている（出典：AI×サイバーセキュリティ完全ガイド2026）。

3. AI SOCは強力な武器だけど、土台がないと機能しない

中小規模だとEDRとメール対策はまず導入を検討すべきで、AI SOCや専門的な脆弱性診断はその基本対策を固めてから検討する順序が現実的という整理もある（出典：AIセキュリティ対策の仕組みとは）。
AIは「監視・検知・初動対応」のレイヤーでは強いけど、認証周り（多要素認証、権限の最小化）やパッチ運用といった地味な基礎がないと、そもそも検知する対象が穴だらけになる。

WEBディレクターの立場で現実的に効くのは、自社・クライアントサイトについて「AI SOCを自前で」というより、
①基本対策（MFA、WAF、定期的な脆弱性診断、CMSやプラグインのアップデート運用）をまず固める
②ホスティング先やセキュリティベンダーがAI SOC的な監視を提供しているなら活用する
③情報漏洩時の初動フロー（誰に連絡、どこまで公表、いつ）を事前に決めておく
あたり。今回のARTEXの件も、攻撃が「速く・広く」なっているのが本質で、検知スピードと初動対応フローの整備が一番効くところだと思う。

自動防御のリスクとコスト——誤遮断とトークン代の非対称性

　そう。確かにAIは凄いし、AI対AIでの攻防戦やればいいんじゃね？とは思うけど、実情そうはならない、というか。AIに自動防御させた際に、例えば、持ち主？自分も攻撃者として排除されかねない、という懸念もあるし。あと、「1. 攻撃側と防御側は対称じゃない」とも似ているけど、攻撃側は攻撃する瞬間にAIを使って攻撃をすればいいが、防御側は「いつ攻撃が来るか」という予測がつかないので、24時間常にフル稼働で防御（＝監視）をすることになるんだろうけど、そのトークン使用料は恐らく結構な金額になりそう。

どちらも的を射てる懸念で、実際に業界側も「ここが一番の壁」として認識してる話。

1つ目（自動防御が持ち主自身を排除するリスク）について

これはもう既知の論点になってて、ゼットスケーラーの取材記事でも「AIを入れれば安全になるわけではない。
セキュリティ対応では、誤検知によって正規のユーザーやシステムを止めてしまうリスクもある」と明言されている（出典：キーマンズネット）。具体的には業務上重要なプロセスの最中にエンドポイントを自動的に隔離してしまうエージェントが実際の業務停止や運用障害を引き起こしたり、誤検知の調査中に正当なユーザーアカウントをブロックしてしまい、サポート対応の負荷や事業への影響を生んだりする、という形で整理されている。

特に厄介なのは正規のアクティビティが攻撃に類似しているケース――正規の認証情報を悪用した横展開や、正規ツールを使った攻撃（Living-off-the-Land）――で、ここは人間のアナリストでも判断が割れるところなのでAIならなおさら誤爆しやすい（出典：Exaforce）。

だから実運用では「隔離・無効化・遮断」みたいな取り返しのつかないアクションは、事前に承認ルールが設定されていればエージェントが自律的に実行できる、という設計にはなっているものの、多くの現場では重大アクションほど人間承認を挟む形に留めている。さっき出た自律対応のレベル分けで言うと、Level 3（定型対応はAI自律、例外は人間）までが現実的な着地点で、Level 4（完全自律）はまだ事例としては少ない。
ここは「AIが速いから全部任せる」んじゃなくて、「取り返しのつく対応は自律化、取り返しのつかない対応は人間の承認を残す」という設計思想が前提になってる、ということ。

2つ目（24時間監視のコスト非対称性）について

これは構造的な指摘として正しい。
実際、AIエージェントは1タスクあたり標準的な生成AIチャットボットの5〜30倍のトークンを必要とし、単価が下がってもその分を利用量の増加が相殺してしまう、という傾向が指摘されている（出典：Gartner Japan）。「攻撃者は攻撃の瞬間だけAIを焚けばいい、防御側は四六時中焚き続けないといけない」という非対称性は、AI SOCの経済性の核心的な論点。

ただ実装の現場では、この非対称性をそのまま丸呑みしないように設計されてる。
NRIセキュアの事例だと1000以上のサードパーティ製品からのログを取り込み、2600以上のML（機械学習）モデルで分析を行うことで誤検知を排除し、優先して対応すべき重大なインシデントを的確に抽出・通知する、という構成になっていて（出典：NRIセキュア）、つまり「24時間フル稼働」なのは比較的安価な従来型ML（異常検知・相関分析）の層で、コストの高いLLM・エージェント的な推論は、そのMLがアラートを上げた「必要なとき」だけ呼び出す、という階層構造。常時フル稼働させてるのは安い部分、高い部分はトリガー起動、という節約の仕方。

とはいえこれで非対称性が消えるわけではなくて、むしろ形を変えて残る。
①監視対象のログ量・攻撃対象領域（アタックサーフェス）が大きいほど、常時稼働層のコストも、トリガーされる頻度も上がる。
②攻撃側は「成功するまで何度でも安く試行」できるのに対し、防御側は「見逃したら一発アウト」なので、閾値を安全側に倒さざるを得ず、結果的にアラート数＝LLM呼び出し回数が増えやすい。
③これは結局「守る資産の価値とコストが見合うか」という経済問題になるので、金融機関や大企業はAI SOCに投資できても、中小規模のWEBサイト運営だと同じ構えは取れない、という体力差がそのまま防御力の差になる。

なので「AI対AI」は間違った方向ではないけど、
①重大アクションは人間承認を残す設計
②安い常時監視層と高い精査層を分ける階層設計
という2つの工夫があって初めて現実的に回る、というのが実情に近い。
逆に言うと、この2つを端折って「全部AIに任せて24時間フル稼働」をやろうとすると、まさにご懸念の通り「身動きが取れなくなるほど誤遮断が起きる」か「コストが破綻する」かのどちらかに振れる、ということだと思う。

「落ちること」は悪なのか？保守を危機予防と捉える組織文化

　なるほどね。そうなると1番のセキュリティは日頃からのメンテナンスや脆弱性が明るみになった際の更新作業など、メンテナンス体制を整える、「こういうこと（＝サービスの停止やサイトの停止）が度々や定期的にある、ということが、「悪いこと」ではなく、「危機の予防」として捉えることが出来る風土や認識、考え方を企業やユーザーが持てるかどうかだね。

その視点、すごく本質的だと思う。
技術の話から最後は「組織文化・認知の話」に着地するのは、セキュリティの議論としては一番大事なとこに行き着いてる感じがする。

さっきのエーアイの発表、実はまさにその実践例になってて、「現時点で、当社サイトにおける情報漏えいの事実は確認されていません。
本措置は被害防止を目的とする予防的対応です」とわざわざ明言してる（出典：エキサイトニュース）。これ、何もしなければ「あの会社サイト落ちてる、やばいんじゃないか」って受け取られかねないところを、先回りして「これは失態じゃなくて予防です」と定義し直してる、っていう情報発信。つまり企業側の認識の持ち方だけじゃなくて、「それをユーザーにどう伝えるか」という発信の設計まで含めて初めて、”メンテナンス＝危機予防”という捉え方が社会的に成立する。

これ、他の業界だとすでに当たり前になってる文化でもあって。
飛行機の定期整備は「頻繁に止めて点検する航空会社」の方が信頼されるし、健康診断も「毎年受けてる人」の方が「久しぶりに検査して引っかかった人」より安心される。
むしろ”滅多に点検しない”方が危険信号。WEBサイトの保守も本来は同じ構造のはずなのに、なぜか「落ちる＝悪いこと」という逆の印象で受け取られがちなのは、裏側の保守活動が普段ユーザーから見えないせいで、「落ちたとき」だけが可視化されるからなんだと思う。平時の地道な更新作業がもっと見える・伝わる形になれば、この認識はズレを直せる気がする。

これ、開発の世界だと「ブレームレス・ポストモーテム（原因究明はするけど個人を責めない事後検証文化）」という考え方があって、インシデントを隠す・恐れるものじゃなく「仕組みを直すきっかけ」として扱う文化が、結果的に障害に強い組織を作るという話に近い。
企業の経営層やクライアントに対しても、「頻繁に小さく止めて直す会社」の方が「滅多に止めないけど一度崩れたら1000件規模で再開できない会社」より信頼できる、という逆転の説明ができると、保守費用や計画的なメンテナンス時間の確保も通しやすくなりそう。WEBディレクターとしてクライアントに保守契約や更新作業の意義を説明する場面でも、使える切り口だと思う。

保守費用はどこから出す？サイバー保険とセキュア・バイ・デザイン、そしてWordPress論争

　そうだよね。「保守」という考えにもっと理解がされる世界になってほしい。ただ、どうしても費用が気になるところではある。クラッカーによって、本来のあるべき姿が見直される、というのもなんとも皮肉な絵ではある。その費用の捻出を企業はどこから出すか、だね。保守運用側も、やたら危険性や脆弱性を伝えて金を無心するようなマッチポンプみたいにならなければいいが(笑)冗談はさておき、今後のセキュリティ、保守の常識は変わりそうだね。今の攻撃状況が恐らく今後のベースになりそうな予感はしている。そうなると、WEBサイトやWEBサービスの作り方も変わってくるのでは、と思う。「保守費用」が払えない企業はWEBサービスやWEBサイトを作ってもその後が続かなかったり、脆弱性が見つからない言語（そんなものはわるわけないが）で構築したり。WordPressはオワコンだ、という極論もあるし（僕はそうは思わないけど）これからは構築時に保守やセキュリティも考えた構築が必要になるね。

マッチポンプの懸念は笑い事じゃなくて、実はセキュリティ業界で昔からある構造的な緊張関係だと思う。
「脅威を煽って売る」FUD（Fear, Uncertainty, Doubt）商法は海外でも批判の的になってきた手法で、だからこそ信頼されるベンダーは「診断結果や根拠を開示する」「過剰な対策を売りつけない」という透明性で差別化してきた歴史がある。保守運用側として立つなら、「危険性を煽る」んじゃなく「何にいくらかかっていて、それが何を防いでるか」を淡々と可視化する方が、長期的な信頼では勝つと思う。

費用の捻出先については、今はサイバー保険という選択肢が中小企業にも現実的になってきてる。
フォレンジック調査費用だけで1件あたり300万〜1,000万円が相場とされる中、売上5億円以下・従業員100名以下の中小企業だと年間保険料15万〜40万円程度が目安という試算もある（出典：サイバー保険の選び方（gxo.co.jp））。保守費そのものじゃなくて「インシデント時の損失」をカバーする保険だけど、多くの保険会社はMFA（多要素認証）など一定のセキュリティ管理体制を加入条件にしてきているので（出典：beancount.io）、「保守をちゃんとやってる会社ほど保険にも入りやすく保険料も下がる」という構造になりつつある。これは保守投資へのインセンティブ設計としては悪くない流れだと思う。ちなみに日常の保守費自体は月額5,000円〜2万円の価格帯が全体の約6割を占めていて、平均は月額4.1万円・中央値1.1万円という調査もあり（出典：ホームページ保守運用の費用相場）、「保守費を払えない」企業が一定数いるのも頷ける水準感ではある。

「構築時にセキュリティ・保守を織り込む」という発想、業界的には「セキュア・バイ・デザイン」とか「シフトレフト」と呼ばれてる考え方で、まさにそっちに向かってる感じがする。後付けで防御層を積み増すより、設計段階で攻撃面を減らす方が結果的に保守コストも下がる、という理屈。

WordPress「オワコン」論、極論だとは思いつつ、実は今年に限って言うと無視できないデータもある。
WordPress本体の脆弱性は2024年が6〜7件、2025年が2〜6件でいずれも低優先度だったのに対し、2026年は9月までに27〜31件と桁が上がっている、という指摘がある（出典：インサイドセールス@AI BtoBマーケティング実践ラボ）。これまでは「危ないのはプラグインであって本体は安全」という前提が業界の共通認識だったのが、2026年はその前提が崩れた年だった、という見方。実際今回の9月のCVE-2026-87902（CVSS 9.2、未認証RCE）も（出典：セキュリティ対策Lab）、7月のwp2shell（CVSS最大9.8）もコア側の脆弱性（出典：piyolog）。

ただこれ、「WordPressが特別脆い」と断定するにはもう一歩情報が要ると思う。
AIによる脆弱性発見が業界全体で加速してる今年、同じ現象が他の主要言語・CMSでも起きてるのか（単にWordPressはシェアが大きいから標的にもされやすいし見つかりやすい、という選択バイアスの可能性もある）は見た方がいい。さっきのPHP本体の脆弱性も含めて考えると、「特定のCMSをやめれば安全」という単純な話ではなく、「シェアが大きい＝攻撃者にとってもAIにとっても investigate する価値がある対象」という構図の方が近い気がする。だから「言語やCMSの選び方」より「選んだ後、更新を止めずに回し続けられる体制があるか」の方が、結局は本質的な分かれ目になりそう。「オワコンかどうか」より「塩漬けにしてないかどうか」、という軸の方が実務的には正しい問いだと思う。

PHP脆弱性は”インターネットの地震”——保険と税制優遇という発想

　そう、流通数が多いから狙われやすいというのはあるね。適当に石を投げたらWordPressに当たるっていうくらいに多いはず。それにオープンソースだからなおのことね、狙われやすい。でも扱いやすいというメリットもあり、きっちりと更新をしていればそこまでは危険ではない（申込フォームは気をつけないといけないけど）。「サイバー保険」なんてのもあるのか。それは初耳だった。でも確かに自然災害ではないけれど、先日のPHPなんてインターネットの世界でいう巨大な自然災害（言うなれば世界規模の大地震）だもんね。そう考えれば、火災保険、地震保険があるように、攻撃を食らったならサイバー保険がおりる、という考えも確かにあるだろうね。そういった保険に入っているなら税制優遇あってもいいかもね。

まさにその通りで、オープンソース×シェアNo.1という組み合わせは「狙われやすさ」と「守りやすさ」が表裏一体になってる。
実際、さっき見た脆弱性一覧でもForminator Forms、Ninja Forms、Fluent Forms、GiveWPといった、フォーム・問い合わせ・決済系のプラグインが繰り返し名前を連ねてて（出典：KUSANAGI）、まさに「申込フォームは気をつけないと」という感覚は裏付けとしても正しい。フォームは「外部からの入力をデータベースやメール送信につなぐ」機能上、攻撃者にとって一番手を出しやすい入口になりやすいんだよね。

「PHP脆弱性＝インターネットの巨大自然災害」という喩え、すごくしっくりくる。
個社の過失じゃなくインフラそのものの欠陥で、しかも予告なく全世界同時に起きる、という点で本当に地震に近い。
そう考えると保険の発想が自然に繋がるのも納得で、実際さっき調べた資料でも国家サイバー統括室が緊急対策を要請するような事態を念頭に、想定総損失額は約800万円〜5,000万円超という試算が出てる（出典：パキラ合同会社）。火災保険・地震保険的な「備える保険」という位置付けは、もう実態として近い。

税制優遇については、調べた限りだと「サイバー保険に入ってたら減税」というそのものズバリの制度はまだ見当たらなかった。
ただ近い発想の制度はすでにいくつか動いてる。

• デジタル化・AI導入補助金の「セキュリティ対策推進枠」は、IPAが公表する「サイバーセキュリティお助け隊サービスリスト」掲載サービスの導入費用を、小規模事業者は2/3、中小企業は1/2補助（上限150万円）（出典：中小企業デジタル化・AI導入支援事業）。
• 東京都のサイバーセキュリティ対策促進助成金は、SECURITY ACTION二つ星宣言（IPAが推進する中小企業向け情報セキュリティ自己宣言制度）を申請要件にしていて、最大1,500万円の助成枠がある（出典：listing-partners.com）。
• そして前回触れた通り、保険会社側もMFAなど一定のセキュリティ管理体制を加入条件にしてきている（出典：beancount.io）。

つまり今の形は「税制優遇」じゃなくて「補助金＋自己宣言制度＋保険料の傾斜」という組み合わせで、”ちゃんと対策してる企業ほど得する”構造を作ろうとしてる段階。
ただセキュリティ対策投資を行っている企業は行っていない企業の約2倍の取引獲得率というデータもあるくらいで（出典：profectus-note.com）、信頼という形での見返りはすでに市場的に発生し始めてる。

税制優遇まで踏み込むかどうかは、今回のPHP／ARTEX騒動みたいな「国家が対応を呼びかける規模の事案」が繰り返されれば、政策として現実味が増してくる発想だと思う。地震保険も最初からあったわけじゃなく、大災害を経て制度として整備されてきた歴史があるので、同じ道をサイバー分野も辿る、というのは十分あり得るシナリオに見える。

WEBサイト保守とセキュリティのこれから——規制・AI・評価軸の変化

　なるほど。ありがとう。よくわかったよ。僕個人的には補助金や助成金ではなく、きっちりと保守を実施している企業には税制優遇はあってもいいんじゃないかって思う。国がそれくらいに取り組まないと企業も本気にならないと思う。Claudeさんが思う、考える、これからのWEBサイト、WEBサービスの保守やセキュリティはどんな方向に向かっていくと思う？

いい締めの質問をもらったので、ちゃんと自分の考えとして答えてみる。

「保守を選べる」から「保守が前提」への移行は、たぶんもう不可逆だと思う。

EUの動きがわかりやすい指標で、サイバーレジリエンス法（CRA）は2026年9月11日から脆弱性の報告義務が先行適用され、2027年12月11日からセキュア・バイ・デザイン、SBOM（ソフトウェア部品表）、脆弱性対応プロセスなどが本格適用される（出典：TMI総合法律事務所）。これは設計段階のセキュア・バイ・デザインから販売後の脆弱性対応・無償セキュリティアップデート提供まで、製品ライフサイクル全体をカバーする規制で（出典：cvejp.com）、ソフトウェア開発企業もEU向け製品なら脆弱性管理とSBOM作成が義務化される（出典：jebridge.jp）。直接EUに売ってなくてもサプライチェーンの一部としてソフトウェアを供給していれば対応を求められる可能性が高い、とされてる（出典：note（Tatsuhiko.Hatakeyama））。

これ、日本には直接の強制力はないけど、「保守・脆弱性対応をライフサイクルの必須要件として法律で縛る」という発想自体が世界の潮流になりつつある、という点が重要だと思う。日本がここに税制優遇みたいな「アメ」で追随するのか、国としての規制義務化という「ムチ」で追随するのかはまだ分からないけど、今回のPHP／ARTEX騒動みたいな国家が対応を呼びかける規模の事件が繰り返されるほど、「任意でやってください」から「やらないと罰則」に寄っていく圧力は強まる気がしてる。おっしゃる通り、国が本気で関与しないと企業の行動は変わらない、というのは歴史的にもその通りだと思う。

その上で、個人的に見えてる方向性を3つ。

1つ目は、「作って終わり」から「作る＝保守契約を結ぶこと」への商習慣の変化。
これまでは制作費と保守費が別契約で、保守は「やってもやらなくてもいい付帯サービス」扱いされがちだった。
でも今回みたいな事態が繰り返されると、保守なしのWEB制作は「無保険で車を売る」くらいリスキーな商品に見えてくる。
制作会社側も「保守契約込みでなければ受けない」という流れに寄っていくと思うし、それが結果的に、さっき話した「保守費を払えない企業はサービスを続けられない」という淘汰にも繋がる。
これは残酷なようで、実は健全な方向だとも思う。

2つ目は、AI対AIの攻防が「監視の民主化」を進める一方で、格差も固定化すること。
AI SOCはコストが下がれば中小企業でも手が届くようになるだろうけど、脅威インテリジェンスの蓄積量で勝負が決まる構造上、大手ベンダー・大手企業への集約はむしろ進む。
個社が自前で頑張るより、「信頼できる少数のプラットフォームに乗る」という選択が主流になっていくと見てる。

3つ目は、「落ちない」より「早く気づいて早く直す」への評価軸の転換。
さっきのブレームレス文化の話の延長で、今後は「障害ゼロ」をアピールする企業より、「インシデント対応のSLA・開示姿勢」を公開してる企業の方が信頼される時代になっていくと思う。
実際、今回のPHP対応でも、素早く閉鎖して明確に経緯を説明した企業の方が、黙って放置した企業より評判を守れてるはず。

WEBディレクターとしての立ち位置で言うと、今後は「作る人」から「作り続けさせる人」への役割シフトが一番大きい変化になりそう。
クライアントに保守の必要性を説明し、ベンダー選定を手伝い、インシデント時の初動フローを一緒に設計する——この「見えない部分の設計」こそが、AIにコードは書かせられても代替しにくい価値になっていく気がする。