Anthropicが6時間で攻撃コード生成｜日本企業のOSS防御策への影響

米アンソロピック（Anthropic）の研究プレビューモデル「Mythos」が、公開済みパッチの差分解析から数時間で実証コードを自律生成できる実態が判明しました。サプライチェーンの9割以上でオープンソースソフトウェア（OSS）を採用する日本企業にとって、上流の正規パッチ配布を待つ従来の受動的セキュリティ運用は成立しなくなっています。

パッチ公開から悪用までの猶予が「数週間」から「数時間」へ短縮

2026年6月8日、米Anthropicは公開済み脆弱性（N-day）に対するLLMの悪用能力を検証した調査レポートを発表しました。同社の大規模モデル「Claude Mythos Preview」を用いた実験では、ソフトウェアのセキュリティ修正パッチを読み込ませるだけで、攻撃コード（エクスプロイト）が自律的に出力されました。

検証結果によると、ウェブブラウザ「Firefox」のJavaScriptエンジンであるSpiderMonkeyにおいて、パッチ18件中8件でリモートコード実行（RCE）につながる攻撃コードの生成に成功しました。最初の攻撃コード生成にかかった時間は1時間未満であり、最終的に約12時間で8件の攻撃コードを作成しました。

また、Windowsカーネルのセキュリティパッチ21件を対象としたテストでは、18件においてブルースクリーン（BSoD）を引き起こす脆弱性実証（PoC）コードを6時間以内に自律作成しました。従来、高度なリバースエンジニアリング技術と数週間から数カ月の期間を要していたパッチ解析が、半日足らずの計算資源で完結することが実証された形です。

過去の著名なサイバー攻撃事例と比較すると、脆弱性修正情報の公開から攻撃コードが流通するまでのタイムスパンは劇的に短縮されています。

脆弱性・攻撃事象	パッチ公開年	パッチ公開から実悪用までの所要期間	解析・開発の主因
WannaCry（MS17-010）	2017年	59日	人手によるリバースエンジニアリング
Citrix Bleed（CVE-2023-4966）	2023年	約2週間	標的型攻撃グループによる手動解析
一般的なN-day悪用（Mandiant調査）	2020年	1カ月以上（調査対象25件中16件）	セキュリティ研究者・攻撃者の手作業
Claude Mythosによる実証実験	2026年	1時間未満〜6時間以内	AIによるパッチ差分解析の完全自律化

Anthropicの研究チームは、攻撃の量と生成速度の急激な変化を指摘しています。単独の攻撃者が午後の数時間と数千ドル規模のAPI利用コストを投じるだけで、1カ月分のセキュリティアップデートを実行可能な攻撃コードへと転換できる環境が現実のものとなりました。

この事態を受け、Anthropicは2026年4月の段階でMythosの一般公開を見送りました。悪用リスクを低減するため、同社はAmazon Web Services（AWS）、Apple、Google、Microsoftなどが参加する防衛的コンソーシアム「Project Glasswing」を組織し、限定的な環境下で防御側の検証にのみモデルを提供しています。

しかし、攻撃コードの量産能力はすでに防御側の処理能力を大幅に超過し始めています。Microsoftでは、2026年4月だけでコラボレーションツール「SharePoint」に対してMythosが「緊急（Critical）」90件、「重要（Important）」141件のバグを検出しました。エンジニアリング部門がパッチ作成と検証に追われ、社内会議で対応の遅れに対する警告が発せられるなど、人的リソースの枯渇が表面化しています。

さらに深刻な影響を受けているのがOSSエコシステムです。AnthropicがMythosを用いて1,000件以上のOSSを走査した結果、2万3,019件の脆弱性候補が発見されました。そのうち深刻度が「重大（Critical）」および「高（High）」に分類されたものは6,202件に達します。

同社は5月22日時点で281のOSSプロジェクトに対して1,596件の脆弱性を報告しました。メンテナーによって1,451件が有効な脆弱性として承認されたものの、実際にパッチ提供まで至ったのは97件（約6.7%）にとどまりました。善意と余暇に支えられたボランティアベースの保守体制では、AIが短時間で量産する脆弱性報告をレビューし、修正コードを安全にマージする作業負荷に耐えきれなくなっています。

参考記事: Anthropic「Model 2」の全貌と非公開の理由｜最上位Mythos 5を超える性能と2つの技術的リスク

パッチ差分解析の自動化と「攻防の不均衡」を生む技術的要因

AIによるエクスプロイト生成がこれほど短期間で実用域に達した背景には、パッチ差分解析（patch diffing）とLLMのコード推論能力の結合があります。

従来のリバースエンジニアリングでは、ベンダーが提供した修正前後のバイナリやソースコードを比較し、変更箇所を特定する作業から始まっていました。人間のアナリストは、追加された境界値チェックやポインタの検証処理から「修正されたバグの根本原因」を逆算し、どのような入力値を与えれば脆弱性をトリガーできるかを推論していました。このプロセスには深い専門知識と長時間の試行錯誤が不可欠でした。

Claude Mythosをはじめとする最先端モデルは、数万行に及ぶコードベース全体をコンテキストウィンドウに保持したまま、変更箇所の影響範囲を追跡できます。修正箇所から呼び出し履歴（コールスタック）を逆方向にシンボリック実行のようにトレースし、外部からの入力値が脆弱な関数に到達するパス（到達可能性）を高速に算出します。

さらに、生成されたPoCコードを実行環境（サンドボックス）で動的にテストし、期待通りのメモリ破壊やクラッシュが発生したかをAI自身が判定する「フィードバックループ」が確立されました。エラーが出力されれば、スタックトレースを読み取ってエクスプロイトコードのペイロードを自己修正します。人間が介在することなく「コード解析→仮説構築→エクスプロイト作成→検証実行→修正」のサイクルが数分単位で自律回転します。

防御側がこのスピードに対抗できない根本的な理由は、修正プロセス特有の非対称性にあります。

攻撃側は、ソフトウェア内の無数にある実行パスのうち、たった1つの侵害ルートを見つければ目的を達成できます。PoCコードが対象環境の特定バージョンでのみ動作すれば十分であり、システムの安定性や後方互換性を考慮する必要はありません。

一方、防御側がパッチを1件リリースするためには、多くの技術的条件をクリアしなければなりません。

修正コードが他の機能に影響を与えないことを保証する回帰テストの実行、APIの後方互換性の検証、多様なハードウェアやOS環境での動作確認が必要です。さらに、OSSプロジェクトでは複数人のメンテナーによるコードレビューや、CI/CDパイプラインによる厳密なビルド検証を経る必要があります。どんなにAIでパッチ生成を支援しても、パッチ適用によるシステム障害（リグレッション）を防ぐための検証プロセスは圧縮できません。

脆弱性を悪用する側が「1本の針」を刺すだけでよいのに対し、修復する側は「布地全体の強度」を担保しなければならない構造が、決定的な時間差を生み出しています。

参考記事: アンソロピック自律AIハッキング事故の教訓｜プロンプト制御の限界と物理サンドボックスの必須化

日本企業が直面するOSS運用の破綻と自律防御への移行

この構造的変化は、無償のOSSコンポーネントを基盤として組み込んできた日本のエンタープライズシステムに直接的な脅威を与えます。

しかし、多くの企業では「上流のコミュニティがパッチを公開したら適用する」という受動的な運用手順が固定化しています。

パッチが公開された瞬間、攻撃側はAIを用いて数時間でエクスプロイトを作成できるようになりました。パッチ公開直後から、世界規模でのスキャンと無差別攻撃が開始されることを意味します。コミュニティのパッチ作成そのものが遅延している現状では、公開を待つ姿勢そのものが重大な脆弱性放置につながります。

日本企業が直面している構造的障壁は、セキュリティ人材の不足だけではありません。自社システムが依存しているOSSの正確な依存関係（ソフトウェア部品表：SBOM）をリアルタイムで把握できておらず、緊急時に暫定パッチを適用できるビルドパイプラインが整っていない点にあります。

この状況を打破するためには、従来の「パッチ待ち運用」から脱却し、以下の防御モデルへ段階的に移行することが求められます。

第一に、実世界のリスクに基づく脆弱性の選別（トリアージ）です。共通脆弱性識別子（CVE）のスコア（CVSS）の高さだけで一律に対処することは、脆弱性報告が爆発的に増加する環境下では運用破綻を招きます。悪用予測スコアリングシステム（EPSS）やCISAの悪用確認済み脆弱性カタログ（KEV）を連携させ、AIによって兵器化される確率が高い脆弱性を特定し、リソースを集中させる体制が必要です。

第二に、正規パッチのリリースを待たずに防御の空白期間を埋める「仮想パッチ（バーチャルパッチ）」の配備です。Webアプリケーションファイアウォール（WAF）やエンドポイント検出応答（EDR）、ランタイム・アプリケーション・セルフプロテクション（RASP）を活用し、パッチ未適用の脆弱性をネットワークやランタイムの層で暫定的に遮断します。これにより、上流のパッチ開発が難航している場合でも、数時間で開始される初期攻撃からシステムを隔離できます。

第三に、基幹システムにおける商用サポート付きOSSディストリビューションへの回帰です。無償OSSの利用には、自社で修正パッチをバックポートするか、コミュニティの遅延を許容するという「隠れたリスクプレミアム」が発生します。Red HatやCanonicalなどの商用ベンダーが提供する、パッチ検証とSLAが保証されたディストリビューションを採用し、サプライチェーンの維持コストを固定化する判断が合理性を持つようになります。

参考記事: 脆弱性エクスプロイト管理の基礎から実装まで｜実世界のリスクに基づく優先順位付けとパッチ自動化のロードマップ

参考記事: セキュアバイデザインとは？CISA基準のSDLC構築とサプライチェーン防衛の実務