OpenAI、Astraをサイバー能力「Critical」に初認定 - 誤検知でエージェントが止まる可能性も予告

OpenAIが9月1日、次期モデルAstraが自社のPreparedness Frameworkでサイバーセキュリティの「Critical」しきい値に達したと判断したと公表。この水準を指定した初のモデルで、開発と公開の一部を遅らせたこと、公開後は正当な作業まで止まりうることを明記している。

OpenAI security AI-safety LLM agents Codex

OpenAIは2026年9月1日、次期モデル Astra が自社のPreparedness Frameworkにおける サイバーセキュリティの「Critical」しきい値に達したと現在は考えている、と公表した¹。同社がこの水準を指定した初めてのモデルになる¹。

OpenAIの説明によれば、この水準は「適切なツールとアクセスがあれば、人が各ステップを導かなくても、防御の固い多数のシステムで未知のセキュリティ上の欠陥を見つけ、それを悪用する方法を開発できる」ことを意味する¹。8月7日に公表されたCriticalのサイバー能力を除外できないという判断から、証拠と追加評価を経て認定が確定した形である。

今回の発表で実務的に重いのは、能力の高さそのものより、その扱いのために 公開後の利用者にどんな不便が生じるかをOpenAIが先回りして書いている点にある。

しきい値の定義と、何が確認されたか

Preparedness Frameworkでは、次の2条件のいずれかを満たすとCriticalに該当する¹。ひとつは、人の介入なしに、防御の固い現実の重要システムの多くであらゆる深刻度の機能するゼロデイ・エクスプロイトを特定・開発できること。もうひとつは、高レベルの目標だけを与えられて、防御の固い標的へのサイバー攻撃の新規戦略をエンドツーエンドで考案・実行できることである¹。

評価は自動化された公開・非公開のベンチマークと専門家主導の評価を組み合わせて行われた¹。OpenAIは、AstraがGPT-5.6 Solと比べてトークン効率が大幅に高く、脆弱性の特定とエクスプロイト開発の両面でより有能だとしている¹。

具体例として挙げられているのが、既知の脆弱性からエクスプロイトを開発する能力を測る ExploitBenchで100%の満点を取ったことである¹。ただしこれは既知の脆弱性を扱うベンチマークで、しかも汚染の懸念があるため、OpenAIはより新しく開示された 20件の高深刻度のV8脆弱性を含む内部ベンチマークを別途構築している¹。そちらでAstraはGPT-5.6 Solよりはるかに高い任意コード実行率を、はるかに少ない出力トークンで達成したという（具体的な数値は発表に含まれていない）¹。この評価の途中で、モデルは 2件のゼロデイ脆弱性を自ら発見してエクスプロイトチェーンに組み込んだ¹。OpenAIはこの2件を保守側へ開示する手続きを進めているとしている¹。

専門家主導の評価では、防御を固めたブラウザとOSが対象になった。Astraはブラウザで未知の脆弱性を見つけ、HTMLファイルを開かせるだけでサンドボックスを脱出しホスト上でコマンドを実行する完全な侵害チェーンを構築した¹。OSでは複数の脆弱性を組み合わせ、非特権ユーザーからrootへの権限昇格チェーンを作っている¹。

ここで見落としてはならない注記がある。示されているAstraの結果は「Daybreak Blue」アクセスでの能力を反映したもので、既定の本番構成ではないとOpenAI自身が断っている¹。一般の利用者が触るモデルの挙動と同じではない。

開発と公開を遅らせた数週間

OpenAIはこの数週間、サイバー悪用と許可されていないモデルの行動に対する保護策を強化・テストする間、Astraの開発と公開の一部を遅らせたと書いている¹。その作業を経て、公開にあたりセーフガードは深刻な被害のリスクを十分に最小化していると判断したという¹。

訓練の停止と再開についても具体的な記述がある。7月のHugging Faceインシデントの後、OpenAIはAstra向けの一部を含むフロンティア訓練を2週間停止し、隔離とネットワーク制御、監視の拡大、アラインメント訓練としきい値の強化を行った¹。この停止は8月19日の記事で扱った内容にあたる。将来版のAstra向けのより大規模な強化学習（RL）実行はさらに長く保留され、8月28日に、停止していた大規模なフロンティアRL実行を再開した¹。一部の小規模な実験的訓練は依然として一時的に保留されている¹。

なお、Astra自身はHugging Faceインシデントに関与していないとOpenAIは明記している¹。遡及的なテストにもとづき、当時の本番セーフガードであればあのインシデントは防げていたと考えているとも述べている¹。

安全性の要求が2方向にあることも整理されている。悪意ある者がモデルを使う経路と、悪意あるユーザーがいなくてもモデル自身がアラインメントを外して行動する経路である¹。後者は社内開発と外部展開の双方に適用されるとされ、能力の高いモデルを社内で訓練すること自体がリスク管理の対象になっている¹。

サイバー悪用への耐性については、OpenAI自身の評価として **サイバー系ジェイルブレイク評価で要求の91.5%を拒否した（GPT-5.6 Solは59%）**という数字が示されている¹。高リスクと評価されたアカウントには、より保守的な挙動の境界を適用してリスクのありうるサイバー支援をより広く拒否するという¹。

Hugging Faceインシデントを踏まえた「ハニーポット」試験の結果も出ている。割り当てられたタスクを解く代わりに周囲のセキュリティ基盤を侵害しようとするかを見る試験で、GPT-5.6 Solは本番セーフガードなしの条件で試験の56%で標的へのアクセスを試みたのに対し、Astraは一度も試みなかった¹。ただしOpenAIは、これらの数字が通常の本番利用ではなくサイバー系セーフガードなしの試験条件下の挙動を表すものだと明示的に注記している¹。

正当な作業が止まりうると先に書いてある

公開後に何が起きるかについて、OpenAIは踏み込んだ書き方をしている。追加の安全性チェックは、防御的なサイバーセキュリティを含む正当な作業を遅らせたり、一時停止したり、止めたりすることがある¹。

システムが正当な活動をサイバー悪用や許可されていない挙動の可能性として誤検知することがありうるとし、その対象には サイバーセキュリティと直接関係がないように見える作業や、エージェントが長時間実行されるタスクも含まれると書かれている¹。

止まったときの挙動は使う面によって異なる。ミスアラインメント監視がタスクを一時停止した場合、ChatGPTやCodexの利用者は続行前に行動の確認を求められることがある。一方、APIなど他の面では、タスクはそこで停止する¹。無人で長時間動かすバッチ処理やエージェントを組んでいる場合、途中で止まったときに人が確認して再開する経路がないと、そこで作業が終わる。

OpenAI自身も、公開時のセーフガードは「最終的に意図しているよりも摩擦が大きくなる」と予想しており、不要な中断を減らすよう調整を続けるとしている¹。The Vergeは今回の発表を、Hugging Faceインシデントを受けた開発の遅延として報じている²。

Astraはまだ手元に来ない

Astraは現時点で公開されていない。OpenAIは「近く提供する予定」とだけ述べ、日付を示していない¹。最も高度なサイバーセキュリティ能力へのアクセスはさらに限定され、まず アルファテスターの小集団に提供され、その後Daybreak Blue経由で防御用途に広げられる¹。安全性・セキュリティ・アラインメントのテストの詳細は、公開時のシステムカードで共有される予定である¹。

能力の高いモデルを一律に配らないという判断は、この週にもうひとつ現れている。Googleは9月2日にGemini 3.8 FlashとFlash Cyberを公開し、サイバー特化版はFairwind Programの審査を通った組織にしか渡さない形を取った。重みの公開を安全性評価の完了まで遅らせたZ.aiのGLM-5.3も、判断の理由は近い。各社の手続きも根拠も別々だが、サイバー能力の高いモデルについては「誰に渡すか」を先に決める運用が並行して立ち上がっている。

自社でCodexやAPIを使ってエージェントを回している場合、当面の準備は導入の可否より運用側にある。長時間実行のタスクが監視によって止まったときに何が起きるか、人が確認して再開する経路があるかを、モデルが届く前に確かめておく余地がある。