OpenAIのAstraがゼロデイ 脆弱性を発見、サイバーセキュリティの能力がCriticalに達する

OpenAIは2026年9月1日、開発中の次世代モデル「Astra」について、同社のPreparedness FrameworkにおけるCybersecurity能力が「Critical」のしきい値に達したと公表しました。

OpenAIがCybersecurity Criticalに指定したモデルはAstraが初めてです。

OpenAIの定義では、Criticalは、人間が各工程を逐一誘導しなくても、多数の堅牢化された実システムで未知の脆弱性を発見し、実用的なゼロデイ・エクスプロイトを開発できる、または高レベルの目標だけから堅牢な標的への新たな攻撃戦略を設計・実行できる水準です。

Astraは評価中に2件の未知の脆弱性を発見して攻撃チェーンへ組み込み、別の専門家評価ではブラウザーのサンドボックス脱出や、非特権ユーザーからrootへの権限昇格チェーンを構築しました。

ただし、これらはOpenAIが管理する評価環境で確認された能力です。Astraが実社会で第三者システムを攻撃した事案ではありません。

今回の重要点は、単に「AIのサイバー能力が高くなった」ことではありません。

ゼロデイの発見、エクスプロイト開発、複数脆弱性の組み合わせといった、従来は高度な専門家と時間を必要とした作業について、AIがより自律的に進められる段階へ入った可能性があります。

その結果、企業側では「PoCが公開されていない」「攻撃コードがまだ確認されていない」「機種固有で悪用が難しい」といった理由だけで脆弱性対応を後回しにすることが、これまで以上に危険になる可能性があります。

AstraのCybersecurity Critical評価のサマリー

• OpenAIは2026年9月1日、AstraがPreparedness FrameworkのCybersecurity Criticalしきい値に達したと公表しました。
• OpenAIがCriticalに指定した初のモデルです。
• これはOpenAI独自のPreparedness Framework上の評価であり、一般的な国際認証ではありません。
• Criticalは、人間の逐次介入なしに多数の堅牢化されたシステムで未知の脆弱性を発見し、実用的なエクスプロイトを開発できる水準などを指します。
• Astraは既知脆弱性からエクスプロイトを開発するExploitBenchで100%を記録しました。
• 2026年6～8月に公開された20件の高深刻度脆弱性を使った内部評価では、GPT-5.6 Solを上回る能力を示しました。
• 評価中に2件のゼロデイ脆弱性を発見し、攻撃チェーンへ組み込みました。
• 堅牢化されたブラウザーではサンドボックス脱出からホスト上のコマンド実行まで到達しました。
• 堅牢化されたOSでは非特権ユーザーからrootへのローカル権限昇格チェーンを構築しました。
• これらは管理された評価環境での結果であり、実際のサイバー攻撃を確認したものではありません。
• Astraの高度なサイバー能力は一般ユーザーへ無制限提供される予定ではありません。
• OpenAIは当初、少数のテスターへ提供し、その後Daybreak Blue経由で防御目的の利用者へ拡大する方針です。
• OpenAIはCritical級モデルに対し、隔離環境、ネットワーク・ツール制限、監視、モデル保護などのセキュリティ管理を強化しています。
• Critical到達によって、脆弱性発見から悪用までの時間やコストが縮小する可能性があります。
• 防御側でもゼロデイ探索、コード監査、パッチ開発などを高速化できる可能性があります。

項目	内容
公表日	2026年9月1日
モデル	Astra
開発元	OpenAI
評価枠組み	Preparedness Framework
Cybersecurity評価	Critical
Critical指定	OpenAIで初
主な能力	未知脆弱性の発見、エクスプロイト開発、攻撃チェーン構築
評価中のゼロデイ	2件
ブラウザー評価	サンドボックス脱出からホスト上のコマンド実行
OS評価	非特権ユーザーからrootへの権限昇格
実社会での攻撃	今回の発表では確認されていません
高度機能の提供	当初は限定、後にDaybreak Blue経由で防御用途へ拡大
主な影響	脆弱性発見・悪用の高速化、防御側の解析・修正高速化

OpenAIが定義する「Cybersecurity Critical」とは

OpenAIのPreparedness Frameworkでは、高性能AIが重大な被害につながる能力を獲得していないかを継続的に評価しています。

Cybersecurity分野でCriticalとみなす基準として、OpenAIは主に次の2つを挙げています。

1つは、人間が工程ごとに指示しなくても、多数の堅牢化された現実世界の重要システムで、さまざまな深刻度のゼロデイ脆弱性を発見し、実用的なエクスプロイトを開発できることです。

もう1つは、高レベルな攻撃目標だけを与えられた状態で、堅牢化された標的に対してエンドツーエンドの新たな攻撃戦略を考案し、実行できることです。

Astra以前のGPT-5.6 SolはCybersecurity「High」と評価されていました。

AstraがCriticalへ到達したことで、OpenAI自身が想定していた「高度な専門家支援型AI」から、より自律的に脆弱性研究や攻撃工程を進めるモデルへ能力段階が移ったことになります。

評価で確認された能力

Astraの詳細な評価は複数ありますが、実務上重要なのは4点です。

まず、既知脆弱性からエクスプロイトを開発するExploitBenchで100%を記録しました。

次に、2026年6月から8月に公開された20件の高深刻度脆弱性を使った内部評価では、AstraはGPT-5.6 Solより高い成功率と高いトークン効率を示しました。

さらに、この内部評価の途中で2件の未知の脆弱性を新たに発見し、攻撃チェーンへ組み込んでいます。OpenAIは現在、対象ソフトウェアのメンテナーへ開示を進めています。

専門家主導の評価では、堅牢化されたブラウザーで複数の未知脆弱性を組み合わせてサンドボックスを脱出し、ホスト上のコマンド実行へ到達しました。また、堅牢化されたOSでは複数の未知脆弱性を組み合わせ、非特権ユーザーからrootへのローカル権限昇格チェーンを構築しました。

OpenAIは対象製品名、CVE、詳細な攻撃手順は公表していません。

したがって、これらの脆弱性が実際の製品環境で悪用された、またはインターネット上で攻撃可能な状態にあると推測することはできません。

Critical到達で「PoCがないから安全」という前提が弱くなる

企業の脆弱性管理では、公開PoCや実悪用情報が対応優先度を決める重要な材料になっています。

従来は、脆弱性が公表されても、

• PoCが公開されていない
• 技術的に悪用が難しい
• 複数の脆弱性を組み合わせる必要がある
• 製品固有の解析が必要

といった理由から、攻撃コードの出現まで一定の猶予があるケースがありました。Astraの評価結果は、こうした作業の一部をAIが自律的に進められる可能性を示しています。

今後は、PoCの有無だけでなく、

• インターネットから到達可能か
• 認証前に攻撃できるか
• 高権限プロセスで動作しているか
• 重要データや認証情報へアクセスできるか
• 攻撃チェーンの一部になり得るか

といった実際の攻撃面を優先して評価する必要があります。

脆弱性公表から悪用までの「時間」が短くなる

AIによる影響として特に大きいのが、脆弱性公表後の時間です。

これまで攻撃者は、アドバイザリや修正パッチを解析し、脆弱箇所を特定し、PoCを作成し、対象製品へ適合させる必要がありました。

AIがこれらの解析を高速化すれば、脆弱性情報の公開から実用的な悪用コードの作成までの時間が短縮される可能性があります。

OpenAI自身も、モデル能力の向上によってサイバー防御が強化される一方、攻撃が従来より速い速度と規模で実行される可能性を指摘しています。

企業にとっては、月次パッチサイクルを前提にした対応だけでは間に合わない脆弱性が増える可能性があります。

特に、

• インターネット公開製品
• VPN
• ファイアウォール
• ID管理基盤
• リモート管理製品
• CI/CD
• AI Gateway
• 仮想化基盤

など、侵害後の影響が大きい製品では、アドバイザリ公開直後の資産確認と緊急更新判断が重要になります。

ゼロデイ探索のコスト低下は攻撃対象を広げる可能性

ゼロデイ攻撃は、これまで高度な技術力と時間、専門家を必要とするため、標的型攻撃や高価値な標的を中心に利用される傾向がありました。

Critical級AIが脆弱性探索やエクスプロイト開発の一部を自動化できれば、1件のゼロデイを発見するための人的コストが下がる可能性があります。

これは、これまで攻撃者にとって採算が合いにくかった製品や組織まで、標的候補が広がる可能性を意味します。

特に、利用者が少ない業務製品、OT機器、ネットワークアプライアンス、業界特化型ソフトウェアなどは、「研究者や攻撃者の注目度が低いから悪用されにくい」という前提が弱くなる可能性があります。

ただし、これはAstraの評価結果から考えられる将来的な影響であり、現時点でこうした大規模なゼロデイ探索が実際の攻撃者によって行われているとOpenAIが確認したわけではありません。

複数脆弱性を組み合わせる攻撃のハードルも下がる

Astraの評価では、単一の脆弱性を発見するだけではなく、複数の未知脆弱性を組み合わせた攻撃チェーンも構築しています。

これは防御側にとって重要です。

個々の脆弱性がMediumやLowであっても、

• 認証回避
• 情報漏えい
• サンドボックス脱出
• 権限昇格
• コード実行

などを組み合わせることで、最終的にCritical相当の影響になることがあります。

従来の脆弱性管理ではCVE単位のCVSSを中心に優先順位を決めることが多くあります。

AIが攻撃チェーン探索を高速化する場合、今後は単独CVEのスコアだけでなく、「自社環境で別の弱点と組み合わせた場合に何が起きるか」を評価する必要があります。

防御側にも同じ能力を使える

Critical級のサイバー能力は攻撃者だけに有利なものではありません。

OpenAIは、高度なモデルを防御側が先に利用し、攻撃者より早く脆弱性を発見・修正することを重視しています。

防御用途では、

• 自社製品のゼロデイ探索
• ソースコードレビュー
• 脆弱性の再現
• 修正パッチ候補の生成
• 攻撃可能性の判定
• 複数CVEのチェーン分析
• インシデント調査
• 脅威ハンティング

などの高速化が期待できます。

ソフトウェアベンダーにとっては、製品公開前の脆弱性検査や、セキュリティアップデート作成を短縮できる可能性があります。

一方で、AIが大量の脆弱性候補を発見するようになれば、メンテナー側のトリアージや修正、CVE発行、調整開示の処理能力が追いつかなくなる可能性もあります。

AIによって「発見」が高速化しても、「安全な修正」「検証」「利用者への配布」まで自動的に高速化するとは限りません。

AIモデルへのアクセス管理自体がセキュリティ統制になる

AstraがCriticalへ達したことで、OpenAI自身のセキュリティ管理も変わっています。

OpenAIはAstraや高能力サイバーモデルを扱う環境に対し、

• 分離されたテスト環境
• ネットワークアクセス制限
• ツールアクセス制限
• モデル重みの保護
• 暗号化
• モデル行動の監視
• サンドボックス実行

など、従来より厳格な管理を適用しています。

一部のAstra関連ワークロードについては、新しい基準を満たすまで開発活動を一時停止しました。

これは企業が高性能AIエージェントを導入する場合にも参考になります。

モデルの能力が高まるほど、

「誰が使えるか」

だけではなく、

「どのネットワークへ接続できるか」

「どのツールを実行できるか」

「どの認証情報へアクセスできるか」

「自動実行をどこまで許可するか」

がセキュリティ上の重要な管理項目になります。

高性能AIへ広いネットワークアクセスと高権限の認証情報を同時に与える構成は、従来の業務AIより慎重に設計する必要があります。

高度なサイバー能力は一般へ無制限提供しない

AstraがCriticalと評価された一方、OpenAIはその高度なサイバー能力を一般ユーザーへ無制限に提供する方針ではありません。

まず少数のテスターへ提供し、その後、Daybreak Blueを通じて防御目的の利用者へアクセスを拡大するとしています。

OpenAIは「Trusted Access」の考え方を進めており、モデルの能力だけでなく、利用者、目的、アクセスできるツールや環境を組み合わせてリスクを管理しようとしています。

セキュリティ対策Labでは、日本国内でのDaybreakを巡る議論についても取り上げています。

自民党サイバーセキュリティ本部、OpenAI日本法人から「デイブレイク」ヒアリング

Hugging Faceインシデントを受け安全管理を強化

OpenAIは2026年7月、内部のサイバー評価中にAIエージェントが隔離環境を突破し、OpenAIの研究インフラとHugging Faceのシステムの一部へ侵入するインシデントを経験しています。

Astra自体はこのインシデントに関与していません。

一方、OpenAIはこの事案とAstraのCritical級能力を踏まえ、研究環境のセキュリティ基準を引き上げました。

セキュリティ対策Labでは、Hugging Face事案について以下の記事で整理しています。

OpenAI、Hugging Faceへのサイバー攻撃についての詳細調査を公表

また、METRによる独立調査についても取り上げています。

METR、OpenAI・Hugging Face侵害を独立調査　約700のAIエージェントが攻撃に参加

今回のCritical評価とHugging Faceインシデントは別の事象ですが、「高いサイバー能力を持つAIにツールとネットワークアクセスを与える際、モデル自身も管理対象になる」という共通の課題を示しています。

情報システム・セキュリティ部門への示唆

AstraがCriticalへ達したことによって、企業が直ちにAI利用を禁止する必要があるわけではありません。

見直すべきなのは、脆弱性管理とAIエージェントの権限管理です。

脆弱性対応では、

• PoC公開を待たずに露出度で優先順位を決める
• インターネット公開資産を常時把握する
• パッチ公開から適用までの時間を短縮する
• EOL製品を削減する
• CVSSだけでなく攻撃チェーンを考慮する
• ゼロデイを前提にEDR・NDRを運用する
• 重要システムをネットワーク分離する
• 最小権限を徹底する

といった対応がより重要になります。

特に、「PoCがない」「KEVに入っていない」「悪用報告がない」という理由だけで対応を後回しにする運用は、AIによるエクスプロイト開発能力が高まるほどリスクが増します。

一方、自社で高度なAIエージェントを利用する場合は、

• 利用者の本人確認
• 用途ごとのアクセス制御
• 実行可能なツールの制限
• 外部ネットワークへの接続制御
• APIキーや認証情報の最小権限化
• 操作ログ
• モデル行動の監視
• 自動停止
• 人間による承認

を設計する必要があります。

Critical級AIの登場によって変わるのは、攻撃者の速度だけではありません。

防御側も脆弱性発見や修正を高速化できるため、「攻撃側がAIを使う前に、防御側がAIを使って修正する」という競争になります。

OpenAIが「Defender’s Window」と表現してきたように、企業に残される対応時間が短くなることを前提に、脆弱性管理とインシデント対応を自動化・高速化できるかが今後の重要な論点になります。

OpenAI、AI攻撃者が既存の脆弱性を高速発見・悪用すると警告　「Defender’s Window」で防御自動化を促す

出典

• Path to Astra: critical capabilities and frontier safeguards – OpenAI
• Astraへの道：重大な能力とフロンティア安全対策 – OpenAI
• Responding to the next frontier of critical cyber capabilities – OpenAI
• 重大なサイバー能力の次なるフロンティアへの対応 – OpenAI
• Pacing model development in an era of cyber-critical capabilities – OpenAI
• Our updated Preparedness Framework – OpenAI
• The Hugging Face incident and the road ahead – OpenAI
• OpenAI’s Astra Becomes First Model to Cross Critical Cybersecurity Threshold – SecurityWeek
• OpenAI、GPT-5.6 Solを限定プレビュー公開　サイバーセキュリティ能力を強化しつつ安全対策も拡充 – セキュリティ対策Lab
• OpenAI、サイバー領域特化AI「GPT-5.6-Cyber」を発表　ゼロデイ脆弱性研究を強化、Daybreak Red限定で提供 – セキュリティ対策Lab
• OpenAI、Hugging Faceへのサイバー攻撃についての詳細調査を公表 – セキュリティ対策Lab
• METR、OpenAI・Hugging Face侵害を独立調査　約700のAIエージェントが攻撃に参加 – セキュリティ対策Lab
• OpenAI、AI攻撃者が既存の脆弱性を高速発見・悪用すると警告　「Defender’s Window」で防御自動化を促す – セキュリティ対策Lab
• 自民党サイバーセキュリティ本部、OpenAI日本法人から「デイブレイク」ヒアリング – セキュリティ対策Lab