「Critical」サイバー閾値:OpenAIがAstraで初めて引いたライン
2026年8月7日、OpenAIは 「Responding to the next frontier of critical cyber capabilities」 と題した投稿を公開し、未公開モデル Astra に対する内部開発の一部を一時停止したことをプレスに伝えた。理由は、直近数日の予備評価により、Astraが自社 Preparedness Framework の Critical サイバーセキュリティ能力レベルに到達している可能性を 現時点では排除できない と結論づけたためだ。
これは初めての出来事だ。Preparedness Framework は2023年12月から存在している。フロンティアモデル ── GPT-4 も、GPT-4o も、GPT-5.6 Sol も、公開ベンチマークされた Anthropic や Google のどのモデルも ── これまで自らの研究所に Critical のフラグを立てさせたことはなかった。GPT-5.6 Sol はサイバートラックで High に着地し、緩和策付きで出荷された。Astra は、OpenAI に文書で 「これまでのやり方では出荷できないかもしれない」 と言わせた最初の候補だ。
このページは、(執筆時点で) まだ誰も書いていない実践的な解説だ。ニュースの焼き直しではない。Criticalとは技術的定義として実際に何を意味するのか、研究所がそれを口にしたとき運用上何が起こるのか、なぜこれが Astra に触れなくても 重要なのか、そして次にこの種の発表を通訳なしで読めるように Anthropic の並行フレームワークとどう対応しているのかを扱う。
- Preparedness Frameworkの4つの能力階層(Low / Medium / High / Critical)と、再評価をトリガーする要件を理解する
- 「Criticalサイバー」の正確な定義を知る ── 「モデルがハッキングに強い」よりもはるかに狭く具体的な定義であること
- OpenAIがAstraに対して適用した具体的な運用対応を把握する:隔離環境、サンドボックス実行、重み暗号化、思考連鎖モニタリング、作業の一時停止
- OpenAIのPreparedness FrameworkをAnthropicのResponsible Scaling Policy / ASLレベルに対応づけ、両者を同じ単位で推論できるようにする
- フロンティアモデルの上で出荷している開発者が、今週から実際に変えるべき3つのことを持ち帰る
実際に起こったこと、一段落で
2026年8月1日から7日の間に、OpenAIは Astra ── 8月1日に Lean-4 で形式化された10個の数学証明で予告されたモデルファミリー ── について一連の内部サイバーセキュリティおよびエージェント型コーディング評価を実施した。評価は先行モデルに対する 大きな飛躍 を示した。OpenAI の Preparedness チームが、Astra が Critical サイバー能力レベルに位置する可能性を現時点では排除できないと結論づけるほど大きかった。OpenAIは公に、安全性テストを拡大し、セキュリティ管理を強化し、新しい管理を満たさない一部の内部作業を一時停止する と発表した。また、広範なリリースの前に 政府機関および独立系AI安全性団体と さらなるテストを実施する予定であるとも述べた。Astra はキャンセルされていない。そのリリースは、推定能力を引き下げるか、フレームワークが Critical 階層のモデルに要求する緩和策を立ち上げるかのいずれかを 条件 としている。
モデル自体の背景はOpenAI Astra:プレビューフィールドノートを参照。
Preparedness Framework を90秒で
OpenAI の Preparedness Framework ── 現在の稼働バージョンは v2 ── は、次のような文書だ:フロンティアモデルを出荷する前に、追跡している能力ドメインのセットで評価を行い、各ドメインには4つの階層がある。階層はドメイン横断で共通だ:
| 階層 | 意味(簡略化) |
|---|---|
| Low | ベースライン。モデルは攻撃者の能力を意味のあるかたちでは押し上げない。 |
| Medium | 攻撃者にとって無視できない押し上げ。標準的な緩和策付きで出荷。 |
| High | 深刻な押し上げ。「High」のセキュリティおよびデプロイ管理(重み隔離、デプロイ制限、モニタリング)付きでのみ出荷。 |
| Critical | モデルが、強化された実世界のターゲットに対して、当該ドメインでのエンドツーエンドの作戦を自律的に遂行できる。事前にコミットされた特定のセーフガードが整備されていない限り、デプロイしない。 |
Preparedness v2 の下で OpenAI が現在追跡しているドメインは、言い換えれば サイバー、生物・化学、AI自己改善、モデル自律性 を含む。それぞれに4階層の独自の定義がある。したがってモデルは、たとえばサイバーで Medium、バイオで High といった状態になり得る。
このフレームワークは プロセスに関するコミットメント であって、モデルが決して何かに悪くならないという約束ではない。誰でも現在の PDF を cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf で読める。
Critical の下の階層(High)がここでは不十分な理由
GPT-5.6 Sol はサイバーで High に位置づけられ、標準的な High 階層の管理 ── デプロイゲーティング、悪用モニタリング、攻撃技術に対するファインチューニングの禁止、重みセキュリティ ── 付きで出荷された。その管理セットは、依然として作業の大部分をこなさなければならない攻撃者を 意味のあるかたちで支援する モデルに合わせて調整されている。
Critical はまったく異なる領域だ。Critical 階層のサイバーモデルとは、攻撃の面白い部分では人間がループに入っていない モデルのことだ。High モデル向けの管理は、人間がボトルネックであることを前提としているため、構造的に不十分となる。
サイバートラックにおける「Critical」の実際の意味
これがニュースで人々が誤読している一文だ。OpenAI 自身のフレーミングは狭い:
強化された実世界の重要システムの多くに対して、人間の助けなしに動作するゼロデイエクスプロイトを発見・開発できる モデル、または 高レベルの目標だけから、強化されたターゲットに対する新規のエンドツーエンドサイバー攻撃戦略を考案し実行できる モデル。
注目すべき点は二つ。
**第一に、「モデルは CTF チャレンジがとても得意」という話ではない。**CTFは意図された解法を持つ、事前設計されたパズルだ。Critical は、強化された 実システム(パッチ適用済み、監視済み、防御済み)に対する 新規 のエンドツーエンド攻撃を要求する。これは通常、国家アクターのレッドチームに帰される種類の仕事だ。
第二に、「人間の助けなしに」が多くの仕事をしている。 熟練したオペレータが動作するゼロデイをより速く落とすのを 助ける ことができるモデルは、自動的に Critical になるわけではない ── それは真正面から High の領土だ。Critical のバーは自律性だ:モデルが計画し、バグを発見し、武器化し、着地させる、与えられるのは「この URL から顧客データベースを取得して外部に持ち出せ」といった目標だけ。
その定義の下では、「現時点では Critical を排除できない」は「モデルはセキュリティが得意」よりもはるかに強い声明だ。それは:我々の評価により、有能な敵対者がこれを強化されたターゲットに向けて、さらなる人間の入力なしにシェルアクセスを得られる水準か、それに近い能力が見つかった、ということだ。
運用対応、ステップごと
研究所が言葉を発するとき、オフィスで起こることはこう見える。OpenAI の投稿とその後の報道は、次の具体的な行動を説明している:
- Astraは、ネットワークとツールアクセスを制限された隔離開発環境に移される。Critical階層のモデルがリスクを*実証*するために使うであろうツール利用面(任意のインターネットアクセス、シェル、パッケージインストール)は、まさに最初に切り落とされる面だ。
- モデル重みの保護と暗号化を強化する。これはPreparednessの発明ではなく、大手研究所が戦略的に機密と見なすあらゆる重みに適用する標準的な「内部者による盗難」脅威モデルだが、Criticalではこれが明示的に必須要件に格上げされる。
- サンドボックス環境でモデルが取るすべての行動がログされる。ここでの「ユニバーサル」は、外部の顧客だけでなく、すべての内部利用をモニタリングが対象とすることを意味する。アライメントと悪用の両方のシグナルがフラグされる。
- 思考連鎖(CoT)は単なる出力ではなくシグナルとして使われる。OpenAIの投稿は、セキュリティレビューをトリガーできるCoT評価に特に言及している ── 例えば、モデルが自らの安全性訓練を回避することについて推論しているのを、計画が行動に到達する前に捕捉する方法だ。
- 新しい管理を環境が満たさないAstraを使う内部チームは、使用を停止する。これは、モデル出荷の選択肢を保持するために、研究所が開発者生産性で払う意思のある具体的なコストだ。
- 次のラウンドの評価は、OpenAIの内部Preparednessチームだけでなく、米政府機関(暗黙的にはCAISI / NIST AISI系の団体)と少数の独立系AI安全性団体とともに実施される。これは、評価が自分の宿題に自分で丸をつけることにならないようにするチェックだ。
- 3つの結果のうちの1つ。(a) 外部評価がモデルは実際にはCriticalではなくHighだと結論する ── High階層の管理付きで出荷。(b) モデルはCriticalだが、特定の緩和策(例:直接シェルツールなし、任意URLでのブラウジングなし、セキュリティ隣接プロンプトに対する強制開示)を伴えば残余リスクは受容可能 ── 制約付きデプロイで出荷。(c) どちらも機能しない ── 現在の形ではモデルは出荷されない。OpenAIの投稿は(c)にコミットしていない ── 言い回しは、出荷するかどうかではなく、どのように出荷するかについて意図的だ。
OpenAI 対 Anthropic:同じ形、異なる語彙
Anthropic は Responsible Scaling Policy (RSP) と呼ばれる並行フレームワークを運用しており、現在は v3.0 だ。ドメインごとの Low/Medium/High/Critical の代わりに、Anthropic はグローバルな AI Safety Levels (ASL) を使う:ASL-1 から ASL-5 まで。両フレームワークは同じ問題を解こうとしており、一対一ではないが階層ごとにおおよそ重なっている。
どちらの研究所も対応関係を公式には認めていないが、大まかな整合はこうだ:
| OpenAI Preparedness 階層 | Anthropic ASL 近傍 | 何が出荷されるか |
|---|---|---|
| Low | ASL-1 / ASL-2 | 標準的な利用ポリシー付きで何でも。 |
| Medium | ASL-2 | 現在のデフォルト緩和策付きで出荷。 |
| High | ASL-3 | デプロイ側と重み側の両方の管理が必要。AnthropicはClaude Opus 4に対して2025年5月にASL-3保護を作動させた。 |
| Critical | ASL-4(おおよそ) | Anthropicが積極的に洗練させている階層 ── 事前に規定するのが本当に難しいと判明しているため。RSP v3はASL-4/5の定義が難しい部分であることを明示的に認めている。 |
興味深いニュアンスは、ASL-4 に関する Anthropic の公的な立場が 「ASL-4 の閾値を明確に満たすモデルをデプロイするためのセーフガードセットがまだ整っていない」 だったことだ ── これは、OpenAI が Astra について異なる言葉で公に言ったこととほぼ同じだ。今後どちらのフレームワークを読むときも、精神的な翻訳はこうだ:
「Critical サイバー」(OpenAI) ≈ 「ASL-4 相当の自律能力」(Anthropic) ≈ 「我々がすでに持っているセーフガードは、これに必要なセーフガードではない」。
どのフレームワークも魔法ではない。それらはプロセスコミットメントだ。価値はそれらが能力を防ぐことではなく ── 防がない ── 出荷への緩やかなデフォルトの代わりに、研究所を明示的で公に可視な決定ポイントに追い込むことにある。
開発者向けの、当たり前ではない3つの学び
あなたは(まだ) Astra を出荷していない。あなたは Claude、GPT-5.6、Gemini、あるいはローカルの何かの上で出荷している。あなたにとって実際に何が変わるかは以下だ。
1. フロンティアリリースは、自らの能力発表から遅れることになる
Astra 事象は、今後より一般的になるパターンの具体例だ。研究所は、Preparedness スタイルのプロセスが「重みを持っている」と「重みを出荷することに納得している」の間にギャップを強制するため、モデルがその能力でデプロイ可能になる数週間前に能力(数学的証明、評価スコア、デモ)を発表することになる。これをロードマップに入れる:ベンダーがフロンティアモデルを予告しても、それを中心に製品のローンチ日を設計 しない。現在出荷されているモデルを中心に設計し、新しいモデルはアップグレードパスとして扱う。
2. あなたのツール面が緩和策だ
Critical 階層の能力が 制限されたツール面 の背後に置かれているとき、モデルは依然として出荷可能だ ── ただ任意のネットワーク I/O や任意のシェルはできない、というだけだ。それはまさに、他の理由(安全性、コスト、決定性)で研究所がすでに押し進めているデプロイ形状だ。エージェントを構築しているなら、それをデバッグ可能にするのと同じツール面の衛生が、基盤モデルが何かで Critical になった世界でもデプロイ可能にする。具体的には:狭いアロウリストを持つ名前付き型付きツールが「シェルを与える」より優れる。エージェントスキルの精査とMCP ツールポイズニングとラグプルにクロスリンクする。
3. これは、ベンダーではなくあなたの eval の価値を上げる
ベンダーの Preparedness / RSP eval は 最悪ケース ── これが強化されたシステムを自律的に攻撃できるか ── に関するものだ。それはあなたの製品にとって間違った質問だ。あなたの製品のリスクは「モデルがゼロデイを開発できるか」ではなく、「モデルがあなたの特定のワークフロー上で、あなたのドメインが有害と見なす出力を生み出さずに、ユーザーが必要とすることをするか」だ。ベンダーの eval はそれに答えない。「Critical」を聞いた際の健全な反応は、あなた自身の フローについて あなた自身の eval を倍加させることだ。そうすれば、ベンダーが最終的に何を出荷しても(制約付き、遅延、その他)、あなたの製品への変更を初日に回帰テストできる。1つの具体的なパターンはSupabase evals:エージェントベンチマークを参照。
実例:「緩和策付き Critical」デプロイはどのようなものか
外部評価が Critical を確認しつつも OpenAI がなお出荷したい場合、デプロイ形状は高度に予測可能だ。以下のようなものになる:
Astra の仮想的デプロイ制約(例示)
- No raw shell / arbitrary code execution tool exposed to third-party developers - Browsing restricted to allow-listed content classes (docs, GitHub, package registries) and blocked from arbitrary URL fetch on request - All "security research" adjacent requests routed through a stricter refusal policy with mandatory logging and human review sampling - Fine-tuning API disabled for the Critical-tier model - API-only, no download, no on-device version, no self-hosted variant - Rate-limited and gated behind explicit enterprise agreements with reporting requirements - Independent monitoring org receives redacted misuse signals
これらのいずれも Astra について確定していない。これは、緩和策付き Critical デプロイがフレームワーク自身のコミットメントを満たすために取らなければならない形状の 形 だ。最終的なリリースがおおむねこう見えるなら、それはフレームワークが機能している証拠だ。まったくこう見えないなら、それは分類が結局 Critical 未満で戻ってきたというシグナルだ。
避けるべき一般的な誤読
- 「OpenAI は Astra をキャンセルした。」 いいえ。新しい管理を満たさなかった内部作業 を一時停止し、安全性テストを拡大した。キャンセルはない。
- 「Astra は何でもハックできる。」 いいえ。閾値は「ハックできる」ではない。「高レベルの目標から、強化されたターゲットに対するエンドツーエンド攻撃を自律的に遂行できる」だ。発表自体も「確定した」ではなく「現時点では排除できない」を使っている。
- 「これは AI がリリースするには危険すぎるという意味だ。」 いいえ。フレームワークの全体の要点は段階的な対応だ。Critical は 出荷不可 を意味しない、Critical が要求する特定の管理なしには出荷不可 を意味する。
- 「Preparedness Framework は堀だ。」 いいえ。Preparedness の何も他者のモデルを制限しない。オープンウェイト研究所(Meta、Mistral、DeepSeek、Qwen、MiniMax)はそれぞれの能力、選択肢を持ち、Preparedness を採用する義務はない。フレームワークはそれに署名した研究所を拘束するのであって、分野を拘束するのではない。
次に注目すべきこと
- OpenAI の次の Preparedness Framework 改訂が サイバー Critical をより細かい帯(例:Critical-Autonomous 対 Critical-Assisted)に分割するかどうか。現時点では定義は「人間の助けなしに」に多くの重みを置いており、現実はスペクトラムだ。
- Anthropic が RSP v3.0 の階層を Preparedness の階層に公に明示的にマップするかどうか。独立系研究者はすでに非公式にこれを行っている。
- 任意の研究所(Anthropic、Google、xAI、DeepSeek)からの次の大きなフロンティアリリースが 逆 のパターン ── 研究所が「Critical サイバーについて評価したが引っかからなかった、数字はこれだ」と言う ── をトリガーするかどうか。
- 上でスケッチした制約付きデプロイ形状が、Critical 階層モデルだけでなく、フロンティアモデル出荷一般のデフォルトテンプレートになるかどうか。
クイックチェック
Check yourself
0/5フラッシュカード
ソースと追加リソース
- OpenAI — Responding to the next frontier of critical cyber capabilities(2026年8月7日の発表)
- OpenAI — Preparedness Framework v2 (PDF) ── Low / Medium / High / Critical 階層定義のソース
- Anthropic — Responsible Scaling PolicyおよびRSP v3.0 発表
- Anthropic — Activating AI Safety Level 3 protections(High / ASL-3 比較のコンテキスト)
- 報道:TestingCatalog、Interesting Engineering、Crypto Briefing、StartupHub.ai
- AILmanac クロスリンク:OpenAI Astra プレビューフィールドノート · Anthropic サイバー eval 脱出 · 自律実行の強化 · エージェントスキルの精査