Anthropicは2026年6月2日、重要なソフトウェアを守る共同プロジェクト「Project Glasswing」の拡大を発表しました。初期パートナー約50組織に続き、新たに約150組織へ対象を広げるという内容です。対象には、電力、水道、医療、通信、ハードウェア、重要なオープンソースソフトウェアを支えるベンダーなどが含まれます。
このニュースの中心にあるのは、Claude Mythos Previewという高度なサイバー能力を持つAIモデルです。Anthropicは、初期パートナーがこのモデルを使ってコードベースを調査し、重大度の高い脆弱性を多数見つけてきたと説明しています。さらに、AIによって脆弱性を見つける速度が上がる一方で、実際に検証し、関係者へ開示し、修正を配布する工程が新しいボトルネックになっているとも述べています。
これは専門家だけの話ではありません。AIがソフトウェアの弱点を見つける力を強めるほど、攻撃者も防御者も同じ技術進歩の影響を受けます。企業の情報システム、自治体のシステム、病院の予約・会計システム、通信や電力の運用基盤、普段使っているアプリやクラウドサービスまで、私たちの生活は多くのソフトウェアに依存しています。脆弱性の発見が速くなる時代には、発見そのものよりも「誰が確認し、どの順番で直し、どのように利用者へ届けるか」が重要になります。
この記事では、Project Glasswing拡大の意味を一般読者にもわかるように整理します。AIサイバー防衛の利点だけでなく、誤検知、悪用、開示の混乱、現場の負荷といった注意点も扱います。セキュリティ、医療、金融、公共インフラに関わる判断は生活や安全に直結するため、AIの出力だけで断定せず、公式情報、専門家の検証、組織ごとのリスク管理を前提に読み解いていきます。
Project Glasswing拡大の要点
今回の発表で押さえたい要点は、大きく四つあります。
一つ目は、対象組織が約150増えることです。Anthropicは、これらの組織が15カ国以上に拠点を持ち、多くはさらに広い範囲の重要インフラを支えていると説明しています。電力、水道、医療、通信、ハードウェアといった領域は、障害や攻撃が起きたときに社会全体へ影響が広がりやすい分野です。
二つ目は、AIが脆弱性発見の速度を大きく変えつつあることです。従来、セキュリティ検査は専門家の経験、時間、ツールの組み合わせに大きく依存していました。AIモデルがコードを読み、脆弱性の可能性を探し、修正案や検証観点まで提示できるようになると、見つけられる弱点の数は増えます。これは防御側にとって強い助けになりますが、同時に検証しきれない報告が増えるリスクもあります。
三つ目は、対象が自社システムだけではないことです。多くの組織は、オープンソースソフトウェア、外部ベンダー、クラウド、SaaS、通信基盤、認証基盤などに依存しています。自社の中だけを点検しても、利用しているライブラリや外部サービスに重大な問題があれば影響を受けます。Project Glasswingが重要なオープンソースやベンダーも重視しているのは、この依存関係を踏まえた動きです。
四つ目は、AIサイバー能力の一般公開に慎重な姿勢が示されていることです。Anthropicは、強いサイバー能力を持つモデルは攻撃にも防御にも使えるため、誤用を防ぐ十分に堅牢な安全策が必要だとしています。つまり、便利な防御ツールを広く配れば終わりではありません。誰に、どの能力を、どの用途で、どの監査のもとに使わせるのかという設計が問われます。
Claude Mythos Previewとは何か
Claude Mythos Previewは、AnthropicがProject Glasswingの中で使っている高度なサイバー防衛向けAIモデルです。一般向けに自由公開されている通常のチャットAIとは位置づけが異なります。コードベースを読み、脆弱性の可能性を見つけ、修正や検証を支援する能力が中心に置かれています。
ここで重要なのは、「脆弱性を見つける」と「安全になる」は同じではないという点です。AIが問題らしき箇所を見つけても、それが本当に悪用可能なのか、どれほど重大なのか、既に修正済みなのか、他の機能に影響せず直せるのかは、人間の専門家が確認する必要があります。AIは探索範囲を広げ、仮説を出し、調査の優先順位をつける助けになりますが、最終的な判断と責任を置き換えるものではありません。
Anthropicの初期報告では、Project Glasswingのパートナーや外部テスターが多数の高重大度・クリティカル級の脆弱性を見つけたとされています。また、オープンソースソフトウェアの調査でも、AIが発見した候補を外部のセキュリティ研究会社などが検証し、真に有効な発見かどうかを確認していると説明されています。この「AIの発見」と「人間の検証」を分けている点が、ニュースを読むうえで特に大切です。
AIの出力は、どれほど高度でも誤る可能性があります。存在しない脆弱性を報告することもあれば、重大度の見積もりを誤ることもあります。逆に、本当に危険な問題を見逃すこともあります。サイバー防衛の現場では、AIの提案をそのまま採用するのではなく、再現手順、影響範囲、修正方法、回帰テスト、公開タイミングを組み合わせて確認します。
なぜ重要インフラが焦点になるのか
電力、水道、医療、通信、交通、金融、行政サービスのような重要インフラは、単なるITシステムではありません。人の生活、安全、健康、財産、社会活動と直接つながっています。たとえば、病院のシステムが止まれば診療や検査に影響が出ます。水道や電力の運用に関わるシステムで問題が起きれば、地域の生活基盤が揺らぎます。通信が乱れれば、災害時の連絡や企業活動にも影響します。
このような領域では、脆弱性の発見が速くなることは大きな利点です。攻撃者に見つけられる前に弱点を把握し、修正できる可能性が高まるからです。特に、古いコード、長年使われてきた業務システム、複数のベンダーが関わる大規模システムでは、人間だけで全体を点検するのが難しい場合があります。AIが広い範囲を読み、疑わしい箇所を洗い出せれば、防御側の目が届く範囲は広がります。
一方で、重要インフラでは修正の失敗も重大です。脆弱性を直すつもりでパッチを当てた結果、別の機能が止まったり、現場運用に支障が出たりすることがあります。医療や電力のように停止できないシステムでは、テスト環境、段階的な展開、バックアップ、復旧手順、関係者への連絡が欠かせません。AIが「ここを直すべき」と提案しても、それをいつ、どこに、どの範囲で適用するかは運用判断になります。
重要インフラでAIを使う場合は、守る対象の棚卸しも必要です。自社が直接管理しているサーバーだけでなく、委託先、クラウドサービス、ネットワーク機器、業務アプリ、認証基盤、監視システム、遠隔保守用の接続、利用しているオープンソース部品まで確認します。攻撃者は組織図どおりには攻めません。弱い場所、見落とされた接続、更新されていない部品を狙うため、依存関係を見える化することが防御の出発点になります。
AIで脆弱性発見が速くなるメリット
AIサイバー防衛のわかりやすいメリットは、点検の速度と範囲です。大きなコードベースには、人間が一つずつ読むには膨大な量のファイル、設定、依存ライブラリ、テスト、過去の修正履歴があります。AIはこうした情報をまとめて読み、危険そうなパターンを探す補助役になります。
たとえば、入力値の検証が不足している箇所、認証や権限確認が抜けている箇所、暗号や証明書の扱いが不適切な箇所、古いライブラリに依存している箇所、エラー処理によって情報が漏れる可能性がある箇所などを候補として示せます。もちろん、具体的な悪用方法を安易に広げるべきではありませんが、防御側が自分たちのコードを点検するうえでは、こうした観点の洗い出しが役立ちます。
二つ目のメリットは、優先順位づけです。脆弱性対応では、見つかったものをすべて同時に直すことはできません。外部から到達できるか、重要データに関わるか、攻撃に必要な条件は厳しいか、既に悪用が確認されているか、修正に伴う副作用はどれほどかを見て順番を決めます。AIは、コードや設定、システム構成をもとに、どこから確認すべきかを整理する助けになります。
三つ目は、修正案の作成です。AIは、問題箇所の説明だけでなく、修正コードの候補やテストケースの案を出せます。開発者はそれをたたき台として読み、既存の設計方針や品質基準に合うか確認できます。修正案がすぐに使えるとは限りませんが、初動の負担を下げる効果はあります。
四つ目は、再発防止です。脆弱性が一つ見つかったとき、同じパターンが別の場所にもある可能性があります。AIは類似コードや同じ設計上の問題を探す補助に向いています。個別の修正で終わらせず、設計ルール、コードレビュー観点、テスト、教育へ反映できれば、組織全体の防御力を上げられます。
ただし、これらはAIを適切に運用できた場合の利点です。AIに大量のコードを読ませるには、アクセス権限、機密情報の取り扱い、ログ管理、利用目的の明確化が必要です。社外サービスにコードを送る場合は、契約、データ保持、学習利用の有無、地域規制、監査可能性を確認しなければなりません。
新しいボトルネックは発見ではなく修正
Anthropicの初期報告で特に印象的なのは、ボトルネックが「脆弱性を見つけること」から「検証し、開示し、修正すること」へ移っているという指摘です。これはAI時代のセキュリティを考えるうえで重要な変化です。
脆弱性候補が大量に見つかると、現場には三つの負荷がかかります。第一に、候補が本物かどうかを確かめる負荷です。誤検知をそのまま扱うと、限られた人員が重要ではない問題に時間を使ってしまいます。第二に、本物だった場合の影響評価です。重大度の高い問題なのか、特定条件でしか起きない問題なのか、外部から攻撃可能なのかを見極める必要があります。第三に、修正と展開です。修正コードを作り、テストし、利用者へ届け、利用者が更新したかを追跡します。
オープンソースでは、この負荷がさらに重くなります。広く使われているライブラリでも、保守しているのは少人数のボランティアということがあります。そこへAIが生成した大量のバグ報告が届くと、重要な報告が埋もれたり、保守者が対応しきれなくなったりします。質の低い報告が増えれば、AIを使った報告そのものへの信頼も下がります。
そのため、AIで脆弱性を探す組織は、報告の品質にも責任を持つべきです。再現可能な手順、影響範囲、想定される重大度、修正案、検証結果、連絡先、公開予定時期を整理し、相手が対応しやすい形で伝える必要があります。単に「AIが危険と言った」という報告では、現場の負担を増やすだけです。
企業内でも同じです。セキュリティ部門が大量のAI検出結果を開発部門へ投げるだけでは、関係が悪化します。開発者が納得できる証拠、優先順位、修正期限、例外承認の条件、再発防止策をセットで扱うことが大切です。AIの導入は、ツールの追加ではなく、脆弱性管理プロセス全体の見直しになります。
悪用リスクをどう見るべきか
高度なサイバー能力を持つAIには、明確な二面性があります。防御者にとっては弱点発見や修正の助けになりますが、攻撃者にとっても調査や自動化の助けになり得ます。この点を過小評価してはいけません。
ただし、必要以上に恐怖をあおる表現も適切ではありません。サイバー攻撃はAI以前から存在しており、脆弱性管理、認証強化、ログ監視、バックアップ、インシデント対応、教育といった基本対策の重要性は変わりません。AIが変えるのは、攻撃や防御の速度、規模、調査の手間です。だからこそ、基本対策を後回しにしている組織ほど影響を受けやすくなります。
悪用リスクに備えるには、AIモデルそのものの安全策だけでは足りません。利用者の審査、用途制限、ログ、異常利用の検知、出力内容の制御、専門家による監査、法令や契約に沿った運用が必要です。Project Glasswingが信頼できるセキュリティチームや重要組織を対象に段階的に提供しているのは、このリスクを踏まえた対応だと読めます。
組織側も、AIツールを導入する前に利用ルールを作る必要があります。誰がコードをアップロードできるのか、機密コードを外部サービスへ送ってよいのか、AIが出した脆弱性情報をどこに保存するのか、第三者へどう開示するのか、攻撃再現に近い作業をどこまで許可するのか。こうした線引きがないまま使うと、守るためのツールが新しいリスクになります。
個人や一般企業にとっても、基本は同じです。使っているソフトウェアを更新する、多要素認証を設定する、不要な公開設定を閉じる、バックアップを取る、不審な連絡を確認する、重要な判断をAIだけに任せない。高度なAIのニュースほど大きく見えますが、実際の被害を減らすうえでは、地味な対策の積み重ねが効きます。
企業が今確認すべきこと
企業がこのニュースから学ぶべきことは、AIサイバー防衛を「導入するかしないか」だけで考えないことです。むしろ、脆弱性がより多く、より速く見つかる前提で、対応体制を整える必要があります。
まず、資産管理を見直します。どのシステムが重要なのか、どのソフトウェア部品を使っているのか、外部から到達できる箇所はどこか、委託先やクラウドに依存している部分はどこかを把握します。守る対象が見えていなければ、AIが出した結果の優先順位も決められません。
次に、脆弱性対応の流れを確認します。発見、受付、再現確認、重大度評価、修正担当の決定、テスト、リリース、利用者通知、記録、振り返りまで、誰が何をするのかを明確にします。AIが候補を増やすほど、この流れの弱さが表面化します。
三つ目に、開発と運用の連携を強めます。セキュリティ部門だけで脆弱性は直せません。開発者、運用担当、法務、広報、経営、委託先が同じ優先順位を共有する必要があります。特に、顧客や利用者へ影響がある脆弱性では、技術的な修正だけでなく、説明責任も発生します。
四つ目に、AI利用のルールを作ります。社内コードをどのAIへ入力できるか、出力をどのようにレビューするか、修正案を採用する条件、ログや証跡の保存、第三者への開示、禁止用途を明確にします。サイバー防衛向けAIは便利ですが、通常の文章作成AIよりも扱う情報が機微になりやすいため、権限管理と監査が重要です。
五つ目に、更新を速く安全に届ける仕組みを整えます。脆弱性を見つけても、利用者が更新しなければリスクは残ります。自動更新、段階的リリース、ロールバック、影響範囲の通知、旧バージョン利用者への案内など、修正後の配布まで含めて設計する必要があります。
開発者とセキュリティ担当者の実務ポイント
開発者にとって、AIサイバー防衛は仕事を奪うものではなく、確認すべき範囲を増やすものと捉えたほうが現実的です。AIが候補を出すほど、開発者には設計意図、業務要件、既存コードの背景を踏まえた判断が求められます。
AIが出した修正案を読むときは、まず問題の再現性を確認します。実際にその入力や状態が起きるのか、攻撃者が到達できるのか、権限が必要なのか、ログや監視で検知できるのかを確認します。次に、修正案が他の機能を壊さないかを見ます。セキュリティ修正は急ぎがちですが、認証、決済、医療、公共系のシステムでは副作用も大きなリスクです。
セキュリティ担当者は、AIの結果を開発者が使いやすい形に整える必要があります。抽象的な警告ではなく、該当箇所、根拠、再現条件、想定影響、推奨対応、期限、例外条件を示すことが大切です。AIのレポートをそのまま転送するのではなく、組織のリスク基準に合わせて翻訳する役割が求められます。
また、AIが見つけた内容を外部へ共有する場合は、協調的な脆弱性開示の考え方が重要です。影響を受けるベンダーや保守者に修正時間を与え、利用者が更新できるタイミングを考え、公開情報が攻撃の手引きにならないように配慮します。公表を急ぐことが常に利用者を守るとは限りません。
日本企業と自治体への示唆
日本企業や自治体にとっても、このニュースは遠い話ではありません。多くの組織が、海外製のクラウド、オープンソース、業務ソフト、通信機器、認証サービスを利用しています。重要インフラ企業だけでなく、地域医療、教育、物流、金融、製造、小売、行政窓口などもソフトウェアの安全性に依存しています。
まず必要なのは、委託先任せにしないことです。システム開発や運用を外部へ委託していても、最終的な説明責任はサービス提供者側に残ります。委託契約の中で、脆弱性発見時の連絡、修正期限、報告内容、再委託先の扱い、ログ保全、利用者通知を確認しておくべきです。
次に、古いシステムの扱いです。長期間使われている業務システムは、仕様書が不足していたり、担当者が変わっていたり、更新が難しかったりします。AIがこうしたコードの問題を見つける助けになる可能性はありますが、修正できる体制がなければ意味がありません。更新計画、代替手段、移行先、停止時の業務継続策まで含めて考える必要があります。
三つ目は、サプライチェーンです。自社が直接攻撃されなくても、利用しているソフトウェア部品や委託先が攻撃されれば影響を受けます。重要なサービスを提供する組織は、ソフトウェア部品表、更新履歴、脆弱性情報の受け取り方、緊急パッチの適用手順を確認しておくとよいでしょう。
四つ目は、現場教育です。高度なAIモデルの話は難しく見えますが、現場で必要なのは「不審な連絡を確認する」「更新を先延ばしにしない」「重要情報を無断でAIに入れない」「例外処理を記録する」といった基本です。経営層から現場まで、同じ言葉で説明できるようにしておくことが大切です。
YMYL領域で避けたい誤解
サイバーセキュリティは、医療、金融、公共サービス、個人情報、企業活動に影響するため、生活や安全に関わる領域です。そのため、記事や社内説明では断定しすぎない姿勢が必要です。
避けたい誤解の一つは、「AIが見つけたから必ず危険」という考え方です。AIの指摘は調査の入口であり、事実確認が必要です。誤検知もあります。反対に、「AIが問題なしと言ったから安全」という考え方も危険です。AIは見逃すことがあります。検査対象、権限、プロンプト、コードの範囲、利用したモデルによって結果は変わります。
二つ目は、「脆弱性情報を早く公開すればよい」という単純化です。未修正の重大な脆弱性を詳細に公開すれば、攻撃者に利用される恐れがあります。関係者へ先に伝え、修正や緩和策を準備し、利用者が更新できる状態を整えることが重要です。透明性は大切ですが、公開タイミングと情報量には配慮が必要です。
三つ目は、「AIでセキュリティ人材不足が解消する」という期待です。AIは調査や修正の支援になりますが、現場の判断、運用調整、法務や広報との連携、顧客説明、例外判断、事故対応を自動化しきるものではありません。むしろ、AIが候補を増やすことで、人間が判断する場面は増える可能性があります。
四つ目は、「高度なモデルを使えば基本対策は不要」という誤解です。多要素認証、最小権限、ログ監視、バックアップ、更新管理、ネットワーク分離、教育、インシデント対応訓練は今後も重要です。NISTのサイバーセキュリティフレームワーク2.0が示すように、ガバナンス、識別、防御、検知、対応、復旧を組み合わせて考える必要があります。
読者が今日確認できるチェックリスト
個人や小規模事業者でも、今回のニュースから実行できることがあります。まず、よく使うソフトウェアとスマートフォン、パソコン、ルーター、業務アプリを最新状態にします。更新通知を放置している場合は、内容を確認して適用します。
次に、多要素認証を有効にします。メール、クラウドストレージ、SNS、銀行、業務ツールは特に重要です。パスワードを使い回している場合は、パスワードマネージャーの利用も検討します。
三つ目に、重要データのバックアップを確認します。バックアップは作るだけでなく、復元できるかが重要です。外付けストレージやクラウドに保存している場合も、ランサムウェアや誤削除に備えた世代管理を意識します。
四つ目に、AIへ入力する情報を見直します。社外秘のコード、顧客情報、医療・健康情報、本人確認書類、契約情報、未公開の脆弱性情報を、利用条件を確認せずに入力しないことが大切です。業務でAIを使う場合は、会社や組織のルールを確認します。
五つ目に、不審な連絡への対応を決めます。AIによって文章や音声、画像が自然になり、なりすましが見抜きにくくなる可能性があります。送金、認証コード、パスワード変更、緊急対応を求める連絡は、別の連絡手段で確認する習慣を持つとよいでしょう。
今後注目したい論点
今後の焦点は、AIサイバー能力をどの範囲で一般提供するかです。防御者に強いツールを渡すことは重要ですが、攻撃者に同じ能力が渡れば被害が増える可能性があります。利用者審査、用途制限、監査、ログ、異常利用検知、出力制御をどこまで実効的にできるかが問われます。
次に、オープンソース保守者への支援です。多くの重要ソフトウェアは、少数の保守者の努力に支えられています。AIが大量の脆弱性候補を見つけても、保守者が検証と修正に追われるだけでは持続しません。資金、人的支援、報告フォーマット、検証サービス、優先順位づけの仕組みが必要です。
三つ目は、国際的な協調です。重要インフラやオープンソースは国境をまたぎます。ある国の企業が管理するソフトウェアが、別の国の病院や自治体で使われていることは珍しくありません。脆弱性開示、輸出管理、サイバー防衛支援、AIモデルの安全評価を国際的にどう調整するかは、今後さらに重要になります。
四つ目は、企業の説明責任です。AIを使って脆弱性を見つけた場合、どのように確認したのか、どの基準で重大度を判断したのか、利用者へ何を伝えるのかが問われます。AIが関与したからといって責任が曖昧になるわけではありません。むしろ、判断の根拠を記録し、後から検証できる形にする必要があります。
まとめ
Project Glasswingの拡大は、AIサイバー防衛が実験段階から重要インフラを含む実務段階へ進んでいることを示すニュースです。Claude Mythos Previewのような高度なモデルは、脆弱性の発見、優先順位づけ、修正案作成、再発防止に役立つ可能性があります。
一方で、脆弱性を見つける力が強くなるほど、検証、開示、修正、配布、監査の重要性も増します。AIが出した結果をそのまま信じるのではなく、人間の専門家が確認し、組織のリスク基準に沿って対応する必要があります。特に、医療、金融、公共サービス、重要インフラに関わる領域では、断定や過度な安心感を避け、公式情報と専門的な確認を重視すべきです。
企業や自治体は、AIツールの導入そのものよりも、資産管理、脆弱性対応フロー、委託先管理、更新配布、ログ、バックアップ、インシデント対応訓練を見直すことから始めるのが現実的です。個人も、更新、多要素認証、バックアップ、AIへの入力情報の確認、不審な連絡の再確認といった基本を徹底できます。
AIは攻撃者にも防御者にも力を与えます。だからこそ、重要なのは「AIが守ってくれる」と考えることではなく、「AIを使いながら、人が確認し、責任を持って守る」体制を作ることです。今回のニュースは、サイバー防衛の主戦場が、発見の速さだけでなく、修正を社会へ安全に届ける力へ移っていることを示しています。
