Project Glasswingの衝撃
2026年4月にAnthropicが発表した「Project Glasswing」の結果に業界は驚愕した。同社が開発した「Claude Mythos」（正式名称：Claude Mythos Preview。以下本稿ではMythosと表記する）が、主だったOSとブラウザの未知の脆弱性を数千件も自律的に発見したからだ。
Project Glasswingとは、Anthropicが主導して行われたサイバーセキュリティ強化プロジェクトの名称。参画企業はGoogle、Microsoft、Appleをはじめ、Linux Foundationなど主要IT企業が名を連ねる。このプロジェクトは、Anthropicが開発したMythosというソフトウェアの脆弱性発見に特化した新しいAIモデル。これを参画企業とともに広範囲のソフトウェアに適用し、未知の脆弱性を発見、対応することで防御力を高める狙いがあった。
しかし、予想以上の結果により、脆弱性発見の効果より悪用への懸念が無視できなくなり、Anthropic自らMythosを一部の企業などを除き、原則非公開としたため、大きなニュースとなった。
今回はこの問題の現状を整理してみる。ただし、騒動の本質は本稿で整理するように、AIによるサイバー攻防のパラダイムシフトであり、Mythos固有の問題ではない。Mythosを非公開にしたところで、他のAI強化によって、脆弱性発見と攻撃コード生成の自動化・高速化は止められるわけではない。
また、この変革もMythosによっていきなり引き起こされたものでもない。以前からその兆候を指摘する専門家も多かった。さらに状況は現在進行形であり、方向性や対応が固まっているわけでもない。
そして、もう一つ重要な観点として、Project Glasswingが示唆する状況、AIによる自動的なゼロデイ攻撃は現在のところ実際の攻撃として確認された事実は存在しない点を指摘しておく。AIによる類似の自動攻撃そのものは確認されているので、備えは必要だが、攻撃事例の有無はリスク評価分析において重要な事柄でもある。メディアのセンセーショナルな報道には注意が必要である。
国内外動向と「Project YATA-Shield」
脆弱性発見に高い能力を発揮するAIは、攻撃側にとっても強力なツールになる。Anthropicは、プロジェクトの成果を発表した直後、Mythosは危険でもあるとしてプラットフォーマーなどへの限定公開に踏み切った。
このことが騒ぎに拍車をかける形になった。国内では、政府の『AI性能の高度化を踏まえたサイバーセキュリティ対策に関する関係省庁会議』において、関係省庁との連携のもと『Project YATA-Shield』という対策パッケージが公表されている。YATA-Shieldでは、金融・電力・通信・医療など重要インフラ分野に対するAI活用防御態勢を整えることを目的としている。
同案の骨子は、AI活用で予想される未知の脆弱性の急増に対応すべく、NCO（内閣官房国家サイバー統括室）を司令塔とした重要分野の攻撃情報、脆弱性情報の共有・連携および人材育成を強化することとなっている。この部分に目新しさはないが、YATA-ShieldではAI活用による脆弱性の先回り発見と事前のパッチ運用体制の見直しが追加されている。パッチ運用体制については、攻撃発生中のリアルタイムでの修復作業、システム停止措置なども含めたものとなっている。これは、従来の脆弱性ハンドリングの枠組みでは対応できない部分だ。
前述したように、この問題はMythosによってもたらされたものではなく、むしろMythos騒動が可視化しただけで、問題の認知を一般レベルにまで押し下げたにすぎない。YATA-Shieldの発表もまずは問題提起と取り組みの表明であり、かかる問題の最適解というわけでもない。脆弱性ハンドリングやインシデント対応の枠組みの再構築は必要だが、その具体案はどの国、どの企業も模索中であるというのが実情だ。
脆弱性発見の爆発的拡大
Project Glasswingでは、50の企業・組織が参加している。各組織が自社システムに対して行った検証では、バグの発見率が10倍になったという報告もされている。3桁レベルで重大深刻度の脆弱性が発見されたところも多いという。オープンソースプロジェクトのスキャンでは、確認された1万件以上の脆弱性のうち6,200件以上が重大深刻度に分類された。
もはや脆弱性発見だけなら、熟練のホワイトハッカーを必要としない、少なくとも発見時間のコストはかぎりなくゼロになったといえる状況だ。
脆弱性発見が容易になるとどのようなことが起きるのか。その兆候は5年前からあった。NISTによれば脆弱性の報告に相当するCVE申請数は2020年から25年の5年間で263％増加しており、増加傾向は止まっていない。
現在、各国が連携している脆弱性ハンドリングのフレームワークでは、発見・報告される脆弱性はNVDというデータベースで一元管理されている。すべての発見や報告が正しいものとは限らないので、モデレーションが必要だからだ。NVDに登録された個別の脆弱性はCVE番号によって管理され、メーカーや開発者に情報が共有され、パッチや修正プログラムが作成される。対応策やパッチに目途がついた段階でCVEとして公開される。
CVEの採番や修正プログラム開発は人力である。AIによるCVE洪水はすでに問題になっており、パッチ対応は人力では対処できないレベルに達している。
ゼロデイ攻撃が常態化する時代での脆弱性ハンドリング
2020年以降増え続ける脆弱性発見に対処するためには、これまでのやり方では対応不可能として、2026年4月にCVEの運営方針を変更した。報告・採番された脆弱性すべてに対応するのではなく重大性の高いもののみにパッチ適用や公開スケジュールの策定などを行うようにした。公開されても「Not Scheduled」カテゴリに分類される未処理案件は2026年3月1日以降のもので約29,000件に上る。事実上の棚上げ案件が3万件近くあるという状況だ。
AI発見の脆弱性は、文字通り未知の脆弱性を新規に発見してくる。攻撃者が利用した場合、その攻撃はゼロデイではなく「tマイナス（起点より以前）攻撃」となる。用語としてのゼロデイ攻撃は、パッチが公開された後、つまり攻撃手法としては既知のものでも修正パッチを当てていない状態に発生する攻撃も含んでいる。
AI時代は、文字通りのゼロデイ、誰も知らない攻撃が普通に発生する前提が必要になっている。
さまざまな企業やオープンソースプロジェクトで、脆弱性対応やバグ改修の枠組みが崩壊の危機にさらされている。
CTF競技のパラダイムシフト
影響は競技ハッキング、CTF（Catch The Flag）大会にも及ぶ。CTFにおいて「旗」を探し出すのは、もはやハッカーの能力よりもAIエージェントを使いこなす技術によるところが大きくなっている。CTFがホワイトハッカー育成や防御スキルを高めるためのものだとすれば、脆弱性発見や侵入手法に長けたAIの登場は、CTF・競技ハッキングの在り方を変える存在だ。
もちろん、課題自体をAIが不得意とするものに変えて進化させていくこともできる。CTFが全面的に無価値になることはないとしても、企業としては人材育成の方法論を考え直さなければならない。善悪・正否はつけられないが、セキュリティ人材のスキルとして、脆弱性の発見を強化するために人間に投資するかAIに投資するかは、純粋にビジネス視点で評価されるだろう。
実際、HackerOneが主催するバグバウンティ（Internet Bug Bounty：IBB）プログラムの新規受付が4月から停止されている。HackerOneやその他のバグバウンティプログラムは、企業などが自社のみでの脆弱性発見やバグ改修に限界があるため、ホワイトハッカーやバグハンターの力を借りるというWin-Winのエコシステムが成立していた。しかし、AIによる脆弱性発見の氾濫（AI Slop：AIゴミ）が、このモデルさえ壊そうとしている。
共通する構造的課題：脆弱性ハンドリングにおける非対称性
AIによる脆弱性ハンドリングのカオスは、Mythosがどうこうという次元の問題ではなく、脆弱性の発見と修復プロセスが非対称になったことが根本的な問題だ。脆弱性の発見はほぼ自動化可能となった。それを利用した攻撃用のエクスプロイト、ツールの生成もほぼ自動化できる段階にある。これに対して防御側は基本的に受け身であり、事後対応、それも人力をベースとした既存の運用体制しか持っていない。
人力での対応に限界があるとすれば、防御側もAIを駆使し、脆弱性の先回り発見と対応の自動化で対抗するしかない。ただし、対応の自動化は残念ながら今のところかなりの制約があると言わざるを得ない。
脆弱性の発見とそれを利用したPoC（Proof of Concept）コードの生成は、作業の連続性も高く関連も深い。しかし、その修正コードはソースコード全体を把握する必要がある。関数呼び出しをセキュアバージョンに切り替える、データの汚染チェック・正規化を追加する、といった簡単な対応は、すぐにできるかもしれないが、プロトコルの実装に関わる問題や影響するコンポーネントが複数ある場合は、即応は難しいかもしれない。
そもそも、パッチ適用ポリシーや対策方法は、企業や組織によって異なる。CVSSなどの重大深刻度（攻撃発生時のインパクトを指標化したもの）だけでなく、業務ごとの優先度決定など、トリアージは人力に依存する部分が過半だ。
YATA-Shieldは、その枠組みやガイドラインの骨子となるべきものだが、今のところ明確な指針や方法論まで踏み込めていない。それでも、AIによる未知の脆弱性の自動攻撃には備える必要がある。組織ごとに対応方法や体制を構築しなければならない点は問題だが、少なくともセキュリティ担当者の現場レベルでは、月次で行っていたセキュリティアップデート以外に、攻撃発生または発見時の即応体制にもパッチ適用や、短時間のサーバー停止・回復・再起動についてもインシデント対応に組み込む必要はあるだろう。
