AIエージェント攻撃は日本企業を「セキュリティ勝ち組」と「セキュリティ負け組」に分ける
AIエージェントによるサイバーセキュリティ攻撃は日増しにエスカレートしており、リアルタイムで専門家が状況報告をするXでは、高市首相までが警告投稿を出した「PHP2Shell」の「次」に相当するものがいくつか現れてきています。社会的経済的に大きな影響を持つものについては、いずれNHKニュースでも取り上げるでしょうから、個々の現象・事案については列挙しません。
目についたものとしては、
・米国の複数の大手銀行の特定の口座の中で、特定の個人顧客が特定の目的を持って放ったAIエージェントが「自律的に」ふるまって資金移動などをやりだし、放った顧客の目的にはない行動を始めた。
・ある日本の最大手FX取引自動化サービス提供会社の顧客口座において（FX自動取引を行うプログラムが動作する専用サーバーの中において）、ある目的を持ったハッキング集団がハッキングを行い、そのサーバー内で「意図的にFXトレードの損失を出す」プログラムを設置した。それにより実損を被るFX顧客が複数出始めている。
があります。
端的には、
- AIエージェントが、薬にもなれば毒にもなるという、厄介な存在になりつつあり、
- 悪意を持つ人々がAIエージェントを犯罪の武器にし始めた
訳です。
これに関連して、AIセキュリティ業界の出世株筆頭という位置づけのGMO Flatt Security CTOの米内貴志氏（今ではAIセキュリティ業界では知らない者はいない方）が、昨日の世界規模PHP対処事態が一段落した後で、非常に興味深い長文の提言を出しておられました。
これは日本にとって社会的経済的にきわめて意味のある提言ですので、末尾で全文を引用します。リンクしてもXアカウントがないと読めないので。
短く圧縮すると、
これからAIエージェントを駆使しまくる無数の「敵」との戦争の時代が来る。日本企業はそれに備えた方がいい。少なくともCTO（技術投資の意思決定権がある人）、CISO（サイバーセキュリティ総責任者）はそれを重々認識して、事態がよくのみこめていない社長との議論をリードすべき。
ということを言っています。
また彼は「AIエージェント悪用時代においては、セキュリティ資源が枯渇する」ということも明確に指摘しています。一昨日のPHP世界規模対処事案を経験した上で、「ああ、こういうことが起こるんだ。これからは...」と理解したのでしょう。
セキュリティ事案に対処する担当者の「体力」「忍耐」「時間」が枯渇する。 → 日増しに増大するAIエージェント攻撃に、早晩、対処しきれないフェーズが来る。
セキュリティ事案に対処するための「お金」が枯渇する。ひとつの企業の経営資源には限りがあるから、セキュリティに割ける予算は限られている。 → 日増しに増大するAIエージェント攻撃に、早晩、対処しきれないフェーズが来る。
その延長で、AIエージェントによる攻撃事案が幾何級数的に増えることを関係者全員が指摘しているから、これに対処できるか、対処できないかは、「事業継続性」そのものに関わる問題になってくる。
これまでのビジネス・コンティニュイティは10年に1度起こる地震とか、3年に1度起こる自然災害とか「年単位」の被災を考えていればよかったが、これからのAIによる被災は毎日膨大な件数になり得る。その企業が企業としてやっていけるか、やっていけないかという死活問題になってくる...ということも、示唆しているように読めました。
米内氏は聡明な方です。彼の経歴書をご覧ください。
私は、昨年末から今年初めにかけて、アサヒグループやアスクルが辛酸を嘗めていたランサムウェアに対処するための方策を経営企画の方々向けにセミナーで講釈させていただいた時期に、「日本のセキュリティ要員は絶対数が少ないから、必ず、受託容量がひっ迫する」「ランサムウェアの最終回答であるゼロトラスト・アーキテクチャを本格実装するためには、必ず、インド4大SIerの力を借りなければいけなくなる」と読んで、セミナーの落しどころとして、インドの4大SIerを使うにはどうすればいいか？を教えていました。
そういう「セキュリティ対応人員のひっ迫」が、これからもっともっとひどくなるということです。
日本企業は、アメリカ企業の売上高比1/3～1/5のIT予算しか付けない。
さらにサイバーセキュリティに割り当てる予算の比率はもっと少ない。
アサヒグループが導入する「本家・米国式ゼロトラスト」は日本のなんちゃってゼロトラストとは決定的に違う
日本企業がアサヒグループ並みの米国本家ゼロトラストを導入するには今の3〜5倍のIT予算が必要
なぜ米国企業はゼロトラスト導入で「大手SIer」を使わないのか？調査でわかった日米のITの構造的な違い
米国シリコンバレー目線で見る -> 日本のIT成熟度の低さと「セキュリティの空白」
アサヒが"そこそこの予算の他社"の3倍をかけてランサムウェア対策「ゼロトラスト」を徹底した理由
こういう状況が20年続いてきたなかで、そもそもサイバーセキュリティ要員の絶対数が少ない。また、やっている仕事のわりに見返りが少ないというインセンティブ問題もあります。
そういう中で、個々の事案に対処している方々は、ほんとうに、疲弊していると思います。
これはひとえに、社長がわからんちんだからです。
今後何が起こるか？
一昨日のPHPでも、パッチ公開直後に観測されたAI攻撃が数千万件に膨れ上がっていました。以下の投稿でも触れたように、1人の攻撃者が千単位の攻撃を同時並行で行うことができる時代です。
AIツール Cairn ケルン は1人のハッカーが1,000サイトを長時間繰り返し自律的に攻撃できる（そういう時代になった）（2026/10/21）
一つの企業が手当できるセキュリティ資源には限りがあります。
特に「人」が払底します。
日本ではそれが見つからないのでインドに求めると、インド4大SIerもいずれは奪い合いとなり、結局は払底します。
AIエージェント型サイバー攻撃（A2B攻撃）の対策をTCS（タタコンサルタンシーサービシズ）に依頼するためハンドブック
AIエージェント型サイバー攻撃（A2B攻撃）の対策をInfosysに依頼するためハンドブック（インフォシス）
AIエージェント型サイバー攻撃（A2B攻撃）の対策をWipro（ウィプロ）に依頼するためハンドブック
またインド4大SIerを使えない企業の方が大多数でしょう。お金の面で（インドだから安いということは絶対にありません。国内最大手SIerと同水準かそれよりも高いと思うべきです。提供サービスの中身に付加価値が付いているからです）、外注管理の面で。
最終的に、日本企業は「セキュリティ勝ち組」と「セキュリティ負け組」に分かれて行きます。
「セキュリティ負け組」の企業は、事業継続性が担保できないですから、市場から退出していかざるを得ない...。
これが2026年10月に突如として日本企業の前に現れた新しい経営課題です。
GMO Flatt Security CTOの米内貴志氏 X投稿
（Xアカウントをお持ちでない経営の方々がお読みいただけるように、全文引用します。）
【PHP脆弱性対応の「後」にむけて】
みなさん、昨晩からのPHP対応お疲れ様です。一晩中連絡鳴り止んでおらず、一部の個別メッセージに返せてなくて申し訳ないです。
一括して、今、世の中の CTOs/CISOs に届いてほしいことを４つ書き残しておきます↓
（まとまりない部分もあるのですが、投稿しないよりマシかなと、このまま投げちゃいます）
Point 1: これからは、ソフトウェア業界全体で、高負荷の続くタイミングになります。意図してセキュリティに時間をあて、チームが「休息」が取れる体制を。
・我々は脆弱性リサーチに数年間継続的に取り組んできてました。だからこそ感じますが、ここ一年（体感では GPT-5.6 Sol 以後）が、最も「本当に？」みたいな脆弱性が掘り出されていく一年になると思います。こんなのまだあったの？という驚きとともに。
・特に複雑なメモリバグの類（memory safe でない言語製のものを中心に）、あるいは認可バグの類が中心になると思われます。
・少なくともここから年末までは、このクラスの脆弱性がまだまだ出てくると考えておく必要があります。（僕が読み外しているかもしれませんが、恐らく高い確度でこうなります。直近のPHP脆弱性すら、いま世界中の研究者が Variant Analysis をしていて、多分まだ出てくるでしょう）
・このご時世では、新規機能の開発に割く時間を明確に落とすしかありません。あくまで経営者である CTO には取りにくい判断なのは重々承知です（僕もそうなので）。
・「対応AIで」と思うかも知れません。これは技術的には正しいです。ただ、組織的には正しくないです。確実になんとかならず、組織は疲弊していきます。
・なんせセキュリティ対応は大抵自分にタイミングが御せないからです。深夜の対応、急な対応、計画の変更、デグレへの不安、脆弱性情報過多（そもそも自社に影響があるかも分からないものが大半なのに）... と、ストレスの強度がぐんぐん高まっていきます。昨日〜今朝のPHP対応のようなものが、毎週あれば、チームは比較的簡単に壊れてしまうでしょう。
・敢えてリーダーが、セキュリティへの、時間・お金（・トークン）にアロケしてください。これは経営者にしか取れない択で、かついま技術経営者に求められることです。
Point 2: 「必要なら予防的にサービス停止」の覚悟を決め、予めできる調整を重ねたい。止められない場合は、仮想パッチ・監視へのリソースアロケを。
・前提、今回のPHPの件のような脆弱性の対応では、「顧客の保護のためならサービスを止めざるを得ない場面」が訪れます。今回も様々なビジネスがそれに直面しました。今後も訪れるでしょう。
・今回の経験を旨に、本当に止めてはならないのか、止めらるのか、止めうる期待値調整がお客様と出来ているか、を徹底的に見直しておきましょう。
・直近の流れをうけての、お客様への事前連絡（スタンス表明）も有効だと思います。（弊社 GMO Flatt Security 製品についても、これからそれをし、リリースノートとして掲示予定です。我々のサービスの侵害、特に Takumi Guard の侵害は、ソフトウェサプライチェーンの最悪な侵害につながるからです。）
・勿論、止めてはならないビジネスも様々存在します。ビジネスドメインに由来する規制/制約（特に金融・医療セグメント）もあれば、顧客とのSLAもあるでしょう。ただし、現代においては、それらに反するリスクと、セキュリティ被害にあうリスクを天秤にかける必要がでてきています。少し前まではサービス停止でのデメリットは容易に考えられても、セキュリティ侵害など考えにくい、という時代でしたが、今はそうではありません。この天秤を再考する必要があります。（なお、「もう何がなんでも止めてはならない」ビジネスは、相当に限定的だと思います。）
・どうしても止めてはならない（もう何がなんでも止めてはならないもの。限定的であれ存在。人命に関わるもの中心）という場合、厳しい戦いになりますが、WAFレイヤなどで緩和策を施しては祈り、監視する、という流れになります。必要なコンポーネント（WAFなど）と運用リソースがあるならば、苦しい時代ですが、休息うまく取りながらやっていきましょう。なければ、これもしんどいですが、整えましょう。
Point 3: もし平時があれば、システムのモダナイズ（Rebuild and Retire）を検討されたい。
・もし自社での緊急対応が落ち着いているならば、レガシーコンポーネント（数年塩漬けのシステム）、誰がメンテできるのか分からないオーパーツ的存在から順に、作り直し（Rebuild）と旧システムの廃止（Retire）を試みてください。新規開発の代わりに、ここにリソースを充てることが CTO/CISO の仕事です。（他の誰もそれを決められないので。）これは追々自分たちを助けてくれる（ついでにAI-native 開発に移行できて改善しやすくなる）とも思料。
・どのシステムからモダナイズしていくかですが：「XXXで書かれているとまずい」というのは燃えるし言いにくいものの、memory unsafe な言語、type safety があまり確保されていない言語の実装は、モダナイズを検討すべきでしょう。（僕はPHP好きですが、C/C++ で書かれた php-src は、やはりメモリバグ類に対して見通しに限界がありますね。好きなんですが...）
・また経験上、開発当時に DevOps プラクティスすら整っていなかった時代のソフトウェアも、モダナイズを検討したほうがよいです。「セキュリティ診断」をしても、取り返しのつかない量の脆弱性が出てきて、作り直したほうが早い、となる傾向にあります。（弊社でも診断/ペネトレしてますが、こうなると、どうしようもありません。）
・ただし Rebuild には、強いソフトウェア開発力が必要で、AI-native なスタイルに移行することは必須です。この意味で CTO の力がいります。かつ、どこからレガシーの追い出しをするか、どうレキュリティ的なレジリエンスを確保するかは、CISO 的な感性が求められます。既製品（とくに SaaS）を買って処理したほうがいいな、というような判断には CIO 的センスが求められます。総力戦だと思ってください。
Point 4: CTO/CISO の総力戦を。
・Point 3でも述べた通り、直近のくだりには、CTO/CISO の総力戦が必要です。ボードがセキュリティに向かって一致団結する必要があります。
・結構これらロールの間にサイロがあるケースがありますが、そんなことを言っている場合ではありません。
・団結を！