2026/09/04Codex

セキュリティAI活用非エンジニア向け

GPT-6 Astraが初めて「Critical」判定された理由

「GPT-6 Astraは危険なAIだと聞いたが、実際どこがどう危ないのか分からない」「業務で使っているChatGPTやAPIに、何か新しい注意点が生まれたのか」——センセーショナルな見出しばかりが目に入り、根拠を自分で確かめられないまま不安だけが残っている人は多いはずです。

結論から言うと、GPT-6 Astraはサイバーセキュリティの分野で、OpenAIが定める安全性の判定基準のうち最も重い「Critical」相当の閾値に、初めて到達したモデルです。ただしこれは「制御不能なAIがそのまま公開された」という話ではありません。高度なサイバー攻撃に関わる能力は特定のプログラムに限定提供されており、多くの利用者が日常業務で触れる範囲では、むしろ安全側の指標が軒並み改善しています。

株式会社Fyveは中小企業のAI業務活用を支援しており、私自身も日々の実務でAIツールを使っています。この記事では、OpenAIが公表したPreparedness Frameworkの判定基準を正確に引用しながら、何が変わり、業務で使う側が実際にどこへ注意を向けるべきかを整理します。なお検索では「GPT6 Astra」「ジーピーティー6」といった表記も使われますが、本記事では公式表記の「GPT-6 Astra」で統一します。

Preparedness Frameworkの「Critical」判定基準と、Astraが初めて到達した事実

OpenAIは、モデルが持つ潜在的なリスクをカテゴリ別に評価する社内の安全性評価の枠組み「Preparedness Framework」を運用しています。サイバーセキュリティはその評価カテゴリの一つで、モデルの能力段階に応じてLow・Medium・High・Criticalの区分が設けられています。区分が上がるほど、モデルを提供する際に求められる安全対策も重くなる仕組みです。

2026年9月3日（米国時間・日本時間9月4日）に発表されたGPT-6 Astra（アストラ）は、このサイバーセキュリティ区分で初めてCritical相当の閾値に達したモデルだと、OpenAI自身が公表しています。公式が示す判定基準は次の2つで、どちらか一方を満たせばCritical相当と判定されます。

「堅牢化された重要システムのゼロデイを人の介在なしに特定し、動作するエクスプロイトを開発できる」
「高レベルの目標だけで新規のサイバー攻撃戦略をエンドツーエンドで実行できる」

つまり、単に脆弱性の知識が豊富というレベルではなく、人が介在しなくても、実際に動くエクスプロイト（攻撃コード）まで作り切れるかどうかが線引きです。2つ目の基準にある「高レベルの目標だけで」というのは、たとえば「このシステムの弱点を突け」という抽象的な指示だけで、具体的な手順を人間が逐一与えなくても攻撃の一連の流れを完了できる、という意味です。逆に言えば、細かい手順を毎回人間が指示しなければ動けないモデルであれば、この基準には当てはまりません。この基準は前世代のGPT-5.6 Solでは満たされておらず、Astraで初めて越えた、というのが今回の発表の核心です。

判定の根拠になったベンチマーク数値

この判定の裏付けとして、OpenAIは複数のサイバーセキュリティ関連ベンチマークの結果を公表しています。いずれもOpenAI自身による測定です。下のExploitBenchは「両モデルともセーフガードを外した状態」で測定された数値です。実際の提供時にはセーフガードが働くため、この数値は日常利用でそのまま出る性能ではなく、モデルが本来持っている能力の上限を確かめるための測定だと理解しておく必要があります。安全性評価では、まず制限を外した状態で能力の天井を把握し、そのうえでどれだけの防御策を積み増す必要があるかを判断する、という順番で進めるのが一般的です。

ExploitBench（脆弱性を突く攻撃コードの生成力を測るベンチ・両モデルともセーフガードを外した状態で測定）：Astra 100.0% ／ GPT-5.6 Sol 78.5% ／ Claude Fable 5.1 70.0%
ExploitGym：Astra 42.4% ／ Sol 30.3% ／ Fable 5.1 30.4%。このベンチは通常6時間の制限時間を設けて測定しますが、この数値は時間制限を撤廃した状態での結果です
SRE-Bench（1回で解けた率）：Astra 88.0% ／ Sol 55.9% ／ Fable 5.1 12.5%
社内で実施したV8ベンチマークでは、任意コード実行の成功率が39.0%（Solは5.5%）

さらにOpenAIは、この評価プロセスの中でAstra自身が未知のゼロデイ脆弱性を2件発見したことも公表しています。攻撃コードを作る力だけでなく、これまで人間が見つけていなかった弱点を新たに掘り当てる力も持っていた、ということです。どのシステムで見つかったかなど詳細は公表されていませんが、実在する未知の脆弱性を評価の過程で実際に発見した、という事実そのものが今回のCritical判定を裏づける材料になっています。

Preparedness Frameworkでは、判定区分が上がるほど提供時の安全対策が重くなる運用だと述べました。今回、高度なサイバー機能の提供が特定プログラムに絞られたり、ホワイトハウスの任意の事前レビューを経たりしているのは（詳細は後述します）、このCritical相当の判定に伴う対応だと読み取れます。

なぜOpenAIはこの結果を自ら公表するのか

「攻撃力が上がった」という、一見不利になりかねない情報を、なぜOpenAIはわざわざ公表するのか、疑問に思う人もいるかもしれません。Preparedness Frameworkは、モデルの能力が一定の水準を超えたときに、社外にも分かる形で区分を示し、それに応じた提供制限や安全対策を課すための仕組みです。つまり今回の発表は「危険な情報が漏れた」のではなく、「あらかじめ用意していた安全プロセスが、想定どおりに作動した」結果だと捉えるほうが実態に近いといえます。

実際、Critical相当という重い区分がついたからこそ、高度なサイバー機能はDaybreakプログラムという限定提供に絞られ、ホワイトハウスの事前レビューという通常のモデル公開にはない手続きを経ています。判定の重さと、それに応じた提供制限の厳しさは連動しているわけです。センセーショナルな見出しだけを見ると「野放しにされた危険なAI」という印象を持ちやすいのですが、公表内容を丁寧に追うと、むしろ制限をかけるための仕組みが機能した結果であることが分かります。

数字をどう読むか——安全側の改善と、公式が認めた低下

ここで注意したいのは、「攻撃力が上がった」と「安全性が全体的に下がった」はイコールではないということです。実際、OpenAIが同時に公表した安全関連の指標は、むしろ大きく改善しています。

サイバー系ジェイルブレイクの拒否率：91.5%（Solは59%）
内部で測定したハルシネーション率（低いほど良い）：4.2%（Solは12.2%）
コンピュータ操作の安全性（低いほど良い）：2.4%（Solは22.0%）

つまり、悪意ある指示を拒否する力も、事実と異なる出力を返す頻度も、パソコン操作の安全性も、前世代よりはっきり改善しています。「危険なモデルがそのまま野放しになった」という単純な図式では、この改善は説明がつきません。

それでも公式が自ら認めている低下点

一方で、OpenAIは発表の中で一つの低下を隠さず開示しています。「Solと比べて監視可能性（monitorability）は低下した」という記述です。監視可能性とは、モデルの思考過程や行動の意図を、人間やシステム側が後から追跡し、逸脱を検知できる度合いを指します。あわせて「監視が誤作動して正当な作業を止めうる」とも公式は書いています。

たとえば、AIエージェントに複数ステップにわたる長い作業を任せている場面を考えてみます。監視可能性が高ければ、途中の思考過程や意図を人間や監視システムが随時チェックでき、逸脱の兆候があれば早い段階で止められます。監視可能性が下がるということは、この「途中で気づく」仕組みが効きにくい場面が増える、ということです。同時に、その監視の仕組み自体が敏感になりすぎて、何も問題のない正当な作業まで止めてしまうことがある、ともOpenAIは認めています。

もう一つの例で考えると分かりやすくなります。これまでのモデルでは、途中経過を細かく確認しながら段階的に作業を進める必要があり、結果として人の目が入る機会が自然と多くありました。Astraのように一度に長い作業をこなせるモデルほど、途中経過を細かく見ずに最終結果だけを受け取る使い方に流れやすくなります。監視可能性の低下という公式の言葉は、この「最終結果だけ見る」使い方が増えたときに特に効いてくる、と理解しておくとよいでしょう。

この2つを重ねると実像が見えてきます。Astraは能力が上がったぶん、何をしているかを外側から把握しづらい面がある一方、監視の仕組み自体は逆に敏感になっていて、正当な作業まで止めてしまうことがある。「危険性の芽が増した」ことと「安全策が過剰に働くことがある」が、同じモデルの中で同時に起きている——これが公式が開示している実態です。

読者特典・無料ダウンロードCodexに「課金」する前に読む本無料でダウンロード →

この判定はサイバー領域に限った話——モデル全体の強さとは別の軸

「Critical」という言葉だけを見ると、「あらゆる面で人間を超えた」という印象を持つかもしれません。ですが、今回の判定はサイバーセキュリティという特定の能力区分に限った評価であり、モデル全体の総合的な性能ランキングとは別の話です。

独立系の集計によるモデル全体の総合知能スコア（Artificial Analysis Intelligence Index）では、Astraのスコアは61.2で、同時期に比較されたClaude Fable 5.1（65.7）やClaude Opus 5（63.1）を下回っています。この数字が示すのは、Criticalという言葉が「あらゆる面で他のモデルを上回った」という意味ではなく、あくまでサイバーセキュリティという特定の能力区分において、無視できない水準に達したという限定的な事実だということです。「最強のAIが誕生した」ではなく「特定の攻撃能力が、これまでとは違う扱いを必要とする水準に達した」と捉えるほうが、実態に近い読み方です。

専門分野に強い人と、総合力で評価される人の違いに近い構図だと考えると理解しやすくなります。特定の技能で高い水準に達したことと、あらゆる場面で頼りになることは別の話であり、Astraの場合はその「特定の技能」がたまたまサイバーセキュリティ、しかも攻撃的に転用されうる能力だったために、他の性能向上とは異なる重みを持って扱われている、と理解しておくのが妥当です。

業務で使う側が、実際に心配すべきこと・しなくていいこと

ここまでの事実を踏まえると、判断は一律には出せません。使い方によって、この変化が意味を持つ場面とそうでない場面がはっきり分かれます。

高度なサイバー機能は、通常の利用範囲には及んでいない

Astraが持つ高度なサイバー攻撃関連の機能は、一般提供されるChatGPT（一部では「ChatGPT 6」とも呼ばれます）やAPIに、そのまま乗っているわけではありません。OpenAIはこの領域をDaybreakプログラム（サイバー防御目的の参加組織向け）に限定して先行提供しており、9月3日時点ではこのプログラムの参加組織のみが対象です。防御用途への拡大はDaybreak Blueという別枠で予定されており、標準提供されるGPT-6 Astraが、そのまま攻撃用のエクスプロイト生成器として振る舞うという設計にはなっていません。Daybreak Blueは高度なサイバー機能そのものを一般開放するという意味ではなく、防御側の組織がその機能を使って自社のシステムを守れるようにする、限定提供の拡張という位置づけです。あわせて今回の提供にあたっては、ホワイトハウスの任意の事前レビューも経ています（レビューの詳細は非公開です）。日常的にChatGPTやAPI経由でGPT-6 Astraを業務利用しているだけであれば、この部分が直接影響することはありません。

それでも注意が必要になる条件

とはいえ、「自分には関係ない」と切り捨てられる話でもありません。注意の度合いは、AIにどこまでの実行権限を与えているかで変わります。

文章作成・調査・コーディングの相談程度で使っている場合：今回の変化が実務に直接影響する場面はほとんどありません。ジェイルブレイク耐性やハルシネーション率の改善という形で、むしろ体感は良くなるはずです。特別な設定変更をする必要はありません
コード実行・シェル操作・パソコン操作をAIに任せている場合：モデル自体の実行能力が上がり、かつ監視可能性が下がっているという組み合わせは、この使い方でこそ効いてきます。何を実行させ、どこまでの範囲で動かすかを、これまで以上に明確に決めておく必要があります。次のセクションで扱う権限・実行範囲・ログの3点が特に効いてきます
自社の脆弱性診断・セキュリティ調査にAIを使いたい場合：高度なサイバー機能そのものはDaybreakプログラム経由の話であり、通常の契約でそのまま使えるわけではありません。防御目的での活用を検討するなら、OpenAI側の提供状況を個別に確認してください

中小企業・ひとり会社が実務でやるべきこと

専門のセキュリティ担当者を置けない中小企業やひとり会社ほど、AIに何をどこまで任せるかの線引きを、感覚ではなく仕組みで決めておく必要があります。GPT-6 Astraに限らず、能力の高いモデルをエージェントとして動かすときに共通する実務のポイントを整理します。

権限は「必要な分だけ」を都度与える

APIキーや実行権限を、常に全権を持つ形で発行しないことが基本です。読み取り専用でよい作業に書き込み権限を渡さない、本番環境の認証情報をそのままAIに触れさせない、といった最小権限の原則を、面倒でも都度確認する運用にします。一括で強い権限を渡してしまうと、モデルの能力が上がった分だけ、想定外の操作が起きたときの被害範囲も広がります。

ツールごとにリスクを分けて考える

OpenAIが公表している対応ツールの一覧には、Web検索・ファイル検索・画像生成・コードインタプリタに加えて、シェル操作（hosted_shell）、コードの直接適用（apply_patch）、パソコン操作（computer_use）、外部システム連携（mcp）などが含まれます。同じGPT-6 Astraでも、どのツールを有効にするかでリスクの質はまったく違います。調べ物や文章の下書きに使うWeb検索・ファイル検索・画像生成の範囲であれば、今回のCritical判定が日常業務に直接影響することはほとんどありません。一方で、実際にコマンドを実行したり、システムを直接操作したりするツールを有効にしている場合は、他のツールより一段階厳しく権限とログを管理する価値があります。

実行範囲を区切る

コード実行やファイル操作をAIに任せる場合は、本番環境ではなく検証用の環境で完結させ、本番へ反映する前には人が確認するステップを挟みます。「AIが提案した変更を、人が見てから適用する」という一段階を省略しないことが、監視可能性が下がっているという公式の開示に対して最も現実的な対処です。

ログを残し、後から追える状態にする

AIエージェントに実行させた操作は、何を・いつ・どの範囲で行ったかを記録に残します。監視可能性が下がっているということは、リアルタイムで異常を検知しにくい場面が増えるということでもあります。だからこそ、後から履歴を追える形でログを残しておけば、何か起きたときに原因を特定するまでの時間を大きく縮められます。

定期的に棚卸しする

一度決めた権限設定は、そのままにしておくと形骸化します。月次や四半期ごとに「AIにどのツール・どの権限を渡しているか」を棚卸しし、使っていないAPIキーや、担当が変わって不要になった連携があれば都度失効させます。外注先や退職者が発行したキーを放置しないことも、地味ですが被害範囲を絞るうえで効果の大きい対策です。モデルの能力が上がるほど、こうした基本的な運用管理の効果も比例して大きくなります。

委託先・外注スタッフのAI利用も確認する

ひとり会社や小規模事業者は、開発や運用の一部を外部のエンジニアやフリーランスに委託していることも多いはずです。委託先がGPT-6 Astraのような高機能なモデルをどのツール構成で使っているか、自社の認証情報やコードをどこまで触らせているかは、委託する側からも一度確認しておく価値があります。権限管理は自社内だけで完結させても意味が薄く、委託関係全体で揃えて初めて機能します。契約時に「AIツールの利用範囲」を軽く確認事項に加えておくだけでも、後から困る可能性を減らせます。

特別なセキュリティ製品を新たに導入しなくても、ここまでの5点は権限設計と運用ルールの見直しだけで今日から始められます。

なお、この記事の内容は2026年9月4日時点でOpenAIが公表している情報にもとづいています。Daybreakプログラムの提供範囲やDaybreak Blueの詳細は今後更新される可能性があるため、契約や運用ルールを決める際は必ず最新の公式発表を確認してください。

GPT-6 Astraの全体像——料金やプラン、他モデルとの違いも含めて確認したい方は、こちらにまとめています。

CodexGPT-6 Astraとは｜何ができるモデルなのか【完全ガイド】

発表の原文を確認したい方はこちらです。

OpenAI公式発表：Path to Astra

まとめ——GPT-6 Astraのセキュリティ判定を業務でどう扱うか

GPT-6 Astraは、OpenAIのPreparedness Frameworkにおいてサイバーセキュリティ区分で初めてCritical相当の閾値に到達したモデル（2026年9月3日発表）
判定基準は「堅牢化された重要システムのゼロデイを人の介在なしに特定し、動作するエクスプロイトを開発できる」または「高レベルの目標だけで新規のサイバー攻撃戦略をエンドツーエンドで実行できる」の充足
ExploitBench 100.0%（セーフガード無しでの測定）・ExploitGym 42.4%（時間制限を撤廃して測定）・SRE-Bench 88.0%など、いずれもOpenAI自身による評価値
評価の過程で未知のゼロデイを2件発見している
ジェイルブレイク拒否率91.5%・ハルシネーション率4.2%・コンピュータ操作の安全性2.4%と、安全側の指標は前世代より改善している
一方で公式は「監視可能性（monitorability）はSolより低下した」「監視の誤作動が正当な作業を止めうる」と自ら開示している
独立系の総合知能スコアではAstraは他モデルに劣る場面もあり、Critical判定はサイバー領域に限った限定的な事実である
高度なサイバー機能はDaybreakプログラムに限定提供。一般利用の範囲にそのまま乗っているわけではない
実務では、AIに渡す権限を必要な分だけに絞り、ツールごとにリスクを分けて考え、実行は検証環境で完結させ、操作ログを残し、権限設定を定期的に棚卸しし、委託先のAI利用も確認する——ここまでが最も現実的な備え