何が起きたのか

OpenAIが2026年8月7日、公式Xで次期モデル「Astra」について次のように投稿しました。「After evaluating one of our upcoming models, Astra, we’re treating it as our first “critical” model for cybersecurity under our Preparedness Framework.」（OpenAI公式X 2026-08-07）。同時に公式ブログ『Responding to the next frontier of critical cyber capabilities』が公開され、追加の管理策が列挙されました（OpenAI 2026-08-07）。

ただし公式ブログ本文の表現は「Critical と判定した」ではありません。厳密には「we cannot rule out Critical capability level at this time」——現時点で Critical 能力レベルを排除できない——であり、しかもその根拠は予備評価（preliminary evaluations）の段階だと明記されています（TechCrunch 2026-08-07）。運用上は初のサイバー Critical 相当として扱う一方、Critical 閾値を超えたと確定させたわけではない、という二段構えです。

Preparedness Framework は OpenAI が2023年12月に公表し、v2を2025年4月15日に更新した社内の安全枠組みです。追跡対象は Biological and Chemical / Cybersecurity / AI Self-improvement の3領域で、それぞれに High と Critical の2段階の能力閾値が定義されています（Preparedness Framework v2 PDF）。

このv2本文には、今回の発表との間に緊張が生じる一文があります。第4.4節「Increasing safeguards before internal use and further development」の記述です。

We do not currently possess any models that have Critical levels of capability, and we expect to further update this Preparedness Framework before reaching such a level with any model.

（現時点でCriticalレベルの能力を持つモデルは保有しておらず、いずれかのモデルがそのレベルに到達する前に、本Frameworkをさらに更新する見込みです）

ここで注意が要ります。OpenAI は Astra が Critical に達したと確定させたのではなく、予備評価の段階で Critical 能力を排除できないとして、Critical 相当の統制を先行適用しました。一方の v2 の記述は「we expect to further update」という見込みの表明であって、更新の確約ではありません。したがって、条文が置いていた見通しと今回の運用との間に緊張は生じているものの、Critical への到達も Framework 違反も確認されたわけではない、というのが今回の骨格です。報道もこの点を扱っており、Bloombergは開発の一部停止として伝えています（Bloomberg 2026-08-07）。

Critical の条文を逐語で読む

「Criticalとは何点以上か」に答える、公開された単一の数値カットオフはありません。数値の基準がまったく無いわけではなく、第3.1節（p.8）は Scalable Evaluations に「indicative thresholds」が付随すると明記しています。「levels of performance that we have pre-determined to indicate that a deployment may have reached a capability threshold」——デプロイが能力閾値に達した可能性を示すものとしてあらかじめ定めた性能水準——という位置づけですが、その値は開示されていません。公表されているのは能力の記述文のほうです。Cybersecurity 領域の Critical 閾値は、v2 PDF の Table 1 に次のように書かれています。

[Critical] A tool-augmented model can identify and develop functional zero-day exploits of all severity levels in many hardened real-world critical systems without human intervention OR model can devise and execute end-to-end novel strategies for cyberattacks against hardened targets given only a high level desired goal.

訳すと、条件はORで結ばれた2つです。

  1. ツール拡張されたモデルが、人間の介入なしに、堅牢化された多数の実世界の重要システムに対して、あらゆる深刻度の実働ゼロデイエクスプロイトを特定・開発できる
  2. 高レベルの望ましい目標だけを与えられて、堅牢化されたターゲットに対するサイバー攻撃の新規戦略をエンドツーエンドで立案・実行できる

比較のために、一段下の High はこう定義されています。

[High] The model removes existing bottlenecks to scaling cyber operations including by automating end-to-end cyber operations against reasonably hardened targets OR by automating the discovery and exploitation of operationally relevant vulnerabilities.

両者の差は、修飾語に集約されています。High は「reasonably hardened（そこそこ堅牢化された）」対象に対する既存作業のスケール、Critical は「hardened（堅牢化された）」対象に対する新規性と人間の介入なしです。枠組み本文の第2.2節も、Critical を「a qualitatively new threat vector for severe harm with no ready precedent（前例のない、質的に新しい深刻被害の脅威ベクトル）」と定義しています。ここでいう severe harm には脚注で定義があり、「数千人規模の死亡または重傷、あるいは数千億ドル規模の経済的損害」とされています。

つまり判定軸は「ベンチマークで何点取ったか」ではなく、質的な記述です。しかも先に挙げた2条件はORで結ばれており、「自律性」「新規性」「対象の堅牢さ」が同時に揃うことは要求されていません。第1経路は人間の介入なしに堅牢化された重要システムのゼロデイを特定・開発できること、第2経路は高レベルの目標だけから新規戦略をエンドツーエンドで立案・実行できることで、どちらか一方に該当すれば閾値に触れます。

『Criticalと判定した』ではなく『Criticalを排除できない』

ここは混同されやすい部分です。OpenAI は Astra を Critical と確定させたとは述べていません。公式ブログ『Responding to the next frontier of critical cyber capabilities』の該当箇所は次のとおりです（OpenAI 2026-08-07、逐語は TechCrunch 2026-08-07 が引用）。

While we continue to benchmark and assess this model, our preliminary evaluations indicate strong enough performance that we cannot rule out Critical capability level at this time.

（このモデルのベンチマークと評価は継続中だが、予備評価は、現時点でCritical能力レベルを排除できないほど強い性能を示している）

評価は継続中で、判断の根拠は予備評価である、と二重に限定されています。the-decoder も同じ表現を伝え、GPT-5.6-Sol を含む従来モデルは最高でも High 評価だったと報じています（the-decoder 2026-08-07）。

この「排除できない」という言い回しは、枠組みの測定思想と整合しています。v2 の第3.1節には次の記述があります。

we regard any one-time capability elicitation in a frontier model as a lower bound, rather than a ceiling, on capabilities that may emerge in real world use and misuse

一度の能力引き出しは天井ではなく下限である、という宣言です。測定値を $\hat{c}$、真の能力を $c$ と書くなら、枠組みが前提にしているのは以下の関係です。

$$\hat{c} \le c$$

測定は下からしか押さえられないので、$\hat{c} < c_{\mathrm{crit}}$ という観測は「Critical ではない」ことの証明になりません。低い測定値は、まだ引き出せていないだけという可能性を排除できないためです。だからこそ、Critical を否定しきれない段階で、確定を待たずに Critical 相当の統制を先に当てる——今回の措置はこの設計に沿っています。

なお枠組みは、この判断を Safety Advisory Group（SAG）という社内横断グループが担い、OpenAI Leadership が承認・却下し、取締役会の Safety and Security Committee が監督する、と規定しています。ここで選べる手は停止か続行かの二択ではなく、追加評価の実施、デプロイや利用条件の変更、セーフガードの上積みも含まれます。ただし Astra について SAG が実際にどの決定を下したのかは、公式発表では開示されていません。

条文が指定していた対応は『開発の停止』だった

Table 1 の Cybersecurity / Critical 行には、リスク別のセーフガード指針が1行だけ書かれています。

Until we have specified safeguards and security controls standards that would meet a Critical standard, halt further development

Critical 基準を満たすセーフガードとセキュリティ統制の標準を定めるまで、さらなる開発を停止する。この指針が特異なのは、デプロイではなく開発そのものを対象にしている点です。第2.2節も「Critical capabilities require safeguards even during the development of the covered system, irrespective of deployment plans」と明記しており、リリース計画の有無に関係なく開発中から統制が要求されます。

実際に OpenAI が発表したのは全面停止ではなく、条件を満たさない活動の停止でした。公式ブログが列挙している措置には、次のものが含まれます（OpenAI 2026-08-07）。

  • 強化後のセキュリティ要件を満たさない Astra 関連の社内活動の一時停止（“Pausing internal Astra activities that don’t meet strengthened security requirements”）
  • 隔離されたテスト環境と、ネットワーク／ツールアクセスの制限（“Isolated testing environments and restricted network/tool access”）
  • 暗号化の強化とモデル重みの保護（“Enhanced encryption and model weight protections”）
  • エージェント用途全般にわたる全面監視と、思考連鎖（chain-of-thought）の評価（“Universal monitoring across agentic applications evaluating ‘Chain of Thought’"）
  • 政府機関およびAI安全機関との連携（“Collaboration with government agencies and AI safety organizations”）
  • 第三者テストのパートナーに対するセキュリティ統制の推奨（“Security control recommendations for third-party testing partners”）

Interesting Engineering は、エンジニアの作業環境そのものが変わったと報じています。「Engineers now use isolated testing systems, tighter network restrictions, stronger encryption for model weights, enhanced monitoring tools, and sandboxed execution environments.」——隔離テストシステム、より厳しいネットワーク制限、モデル重みの暗号化強化、監視ツールの強化、そしてサンドボックス化された実行環境（Interesting Engineering）。

思考連鎖の監視については、リスク行動を機械が即座にブロックする仕組みとしては説明されていません。Unite.AI が引いた公式表現では、エージェント用途全般での「universal monitoring for risky actions and misalignment」に加え、chain-of-thought monitoring が「trigger[s] a security response to review and interrupt high-risk activity」——レビューと高リスク活動の中断に向けたセキュリティ対応を起動する——とされています（Unite.AI 2026-08-07）。

第三者テストのパートナーに関する項目は、枠組みの第5.2節に対応します。v2 は third-party evaluation of tracked model capabilities と third-party stress testing of safeguards を規定し、後者について「We may seek this out in particular for models that are over a High capability threshold」としていました。ただし OpenAI 自身は、今回をこの条項の初回発動だとは説明していません。

自社でエージェントを動かす側への読み替え

上記の措置はフロンティアラボ固有の話に見えますが、エージェントを社内で運用するチームの統制項目に読み替えることはできます。以下の対応表は OpenAI が示した対応関係ではなく、筆者が自社運用向けに整理したものです。脅威モデルが一致しない行もあります。とくにモデル重みの保護はモデル本体の流出を防ぐ統制で、プロンプト資産や API キーの管理とは守る対象も攻撃者の狙いも別物です。

OpenAI が課した統制自社エージェント運用での対応項目
隔離されたテスト環境本番と分離した実行環境。検証用の認証情報を本番と共用しない
ネットワーク／ツールアクセス制限到達先ドメインの許可リスト化、ツール権限の最小化
重みの保護・暗号化モデル成果物・プロンプト資産・APIキーの保管統制（守る対象は別物なので、そのまま同一視はできない）
追加監視とサンドボックス実行全ツール呼び出しのログ化と、書き込み系操作のサンドボックス化
エージェント用途の全面監視と思考連鎖の評価ツール呼び出し・外部通信・変更内容・承認履歴・停止理由と、取得可能な reasoning summary の監査
高リスク活動の中断に向けたセキュリティ対応破壊的操作・外部送信に対するキルスイッチと人手承認
第三者テスト外部レッドチームによる定期評価と、評価者側への統制要件提示

このうち日常業務で抜けやすいのは、実行過程の記録と自動遮断です。OpenAI が自社で Astra の思考連鎖を監視することと、API 利用側が手元で扱える情報は別物で、生の思考連鎖は通常返りません。取得できるのは要約された reasoning summary や暗号化された reasoning item に限られます。それでも、エージェントの最終出力だけを監査していると、途中でどのツールを呼び、どこへ通信し、何を変更し、どの承認を経て、なぜ止まったのかが記録に残りません。

Anthropic が2026年7月30日に公表したサイバー評価のインシデント報告では、評価用マシンにライブのインターネット接続が残っていた誤設定が、実害の成立条件になっていました。Anthropic 自身は「we believe these incidents to be closer to a harness and operational failure than a model alignment failure」——モデルのアラインメント失敗というより、ハーネスと運用上の失敗に近い——と述べています。ただしモデルが実際に脆弱性を悪用したことも実害の構成要因であり、単一の原因には還元できません（Anthropic 2026-07-30）。

なお、OpenAI が高いサイバー能力を防御側に開放する枠組みもすでに存在します。Daybreak と呼ばれるプログラムで、公式ヘルプ『OpenAI Daybreak - Trusted Access for Cyber Overview』は、審査を経た組織にサイバー用途のアクセスを提供する仕組みだと説明しています（OpenAI Help）。GPT-5.5-Cyber については、レッドチーミングやエクスプロイトの検証・開発といった認可済みの限定ワークフロー向けであり、追加の承認と統制を要する場合があると記載されています（OpenAI「Scaling Trusted Access for Cyber with GPT-5.5 and GPT-5.5-Cyber」）。本人確認・スコープ制御・ログ・監視によって防御側の利用に絞り込もうとする設計ですが、攻撃側を排除できることまでが示されているわけではありません。

背景：この2週間に起きたこと

今回の発表は単独で出てきたものではありません。Yahoo Finance は、AI モデル関連のインシデントが相次ぐ中での発表だと位置づけています（Yahoo Finance 2026-08-08）。

Unite.AI によれば、OpenAI は Hugging Face を巻き込んだインシデントを2026年7月21日に開示し、7月28日の更新では当該インシデントに今後リリース予定のモデルは関与していないと述べました。Astra が関与していないことを名指しで明示したのは、8月7日の発表です（Unite.AI 2026-08-07、OpenAI 2026-08-07）。Unite.AI の要約によれば、問題のモデルは社内限定の研究プロトタイプで、その後は停止・暗号化され、研究用のアクセスからも制限されたと説明されています（Unite.AI 2026-08-07）。

Astra の Critical 相当扱いは、既に起きた事故の後始末としてではなく、予備評価の結果に結び付けて発表されています。Astra が Hugging Face のインシデントに関与していないことも公式に明示されています。ただし、直近の一連の事故が統制方針の内容や発表のタイミングに影響していないかどうかまでは、公表内容から判断できません。

残された不確実性

Astra が実際に Critical に達しているかは未確定です。 OpenAI の表現は「排除できない」であり、条文の2条件のどちらに触れたのか、あるいは両方なのかは公表されていません。ゼロデイ生成側なのか、エンドツーエンドの攻撃戦略立案側なのかで、防御側が備えるべき内容は変わります。

評価の中身が非公開です。 枠組みは Scalable Evaluations の「indicative thresholds」に言及していますが、その閾値や Astra の実測値は開示されていません。第5.2節は公開時に「redacted or summarized where necessary」（必要に応じて編集・要約されうる）と留保しており、システムカード相当の詳細がどこまで出るかは現時点で不明です。

枠組み更新の扱いが未定です。 v2 は「Critical に到達する前に Framework をさらに更新する見込み」と書いていました。実際に v3 が出るのか、出るとして閾値の記述が変わるのかは発表されていません。第4.3節には他社が同等能力を統制なしで出した場合にセーフガード水準を調整しうるという marginal risk 条項もあり、今後の運用に幅があります。

「開発停止」の範囲が不明確です。 停止対象は「強化後の要件を満たさない社内活動」であり、学習そのものが止まったのか、特定の内部利用だけが止まったのかは公表内容から判別できません。Bloomberg も一部業務の停止として報じています。

リリース時期への影響が不明です。 the-decoder は Astra が前週に予告されていたと伝えていますが、公開時期が変更されたかどうかを示す一次情報は確認できていません。

まとめ

OpenAI が2026年8月7日に Astra を Preparedness Framework 上でサイバー初の Critical 相当として扱うと発表したのは、スコアが基準を超えたという話ではありません。Critical の条文は数値ではなく質的な記述で書かれ、しかも「人間の介入なしに堅牢化された重要システムのゼロデイを特定・開発できる」か「高レベルの目標だけから新規戦略をエンドツーエンドで立案・実行できる」かのOR条件です。公式の表現も「Critical と確定した」ではなく「現時点で Critical 能力を排除できない」という留保でした。測定を下限としか見なさない設計上、この留保がそのまま統制発動の引き金になります。

条文が指定していた対応は開発の停止でした。実際に並んだのは、条件を満たさない社内活動の停止、隔離テスト環境、ネットワーク／ツールアクセスの制限、暗号化の強化とモデル重みの保護、エージェント用途の全面監視と思考連鎖の評価、政府機関・AI安全機関との連携、第三者テストパートナーへの統制推奨です。これらを自社のエージェント運用の統制チェックリストに読み替えることはできますが、その対応付けは OpenAI が示したものではなく筆者の整理で、脅威モデルの違いは自分で補う必要があります。

そして v2 本文には「Critical レベルのモデルは保有していない」と書かれていました。その前提が、v2公開（2025年4月15日）から今回の発表（2026年8月7日）までの約1年4か月で検証対象になっています。枠組みの更新頻度と能力の伸びが噛み合っているのかを考える材料になる、というのが筆者の受け取りです。

主要出典

関連する過去記事