OpenAI AstraのCriticalとは｜企業の備え
「AIが自分で脆弱性を見つけて攻撃できるようになった」——2026年9月1日、そんな見出しが並びました。自社のシステムは大丈夫なのか、と身構えた方も多いはずです。
結論から言うと、中小企業がこの発表から今日受け取るべき変化は「攻撃が来る」ではありません。自社で動かしているAIの自動化が、これから止まりやすくなる——これが公式文書に書かれている、実務にいちばん近い変化です。
株式会社Fyveは、中小企業のAI活用を月額で伴走する会社です。私自身も自動化したジョブを毎日無人で動かしており、今回の変更を「他人事のニュース」ではなく自分の運用への影響として読みました。この記事では、報道の見出しと公式文書のズレを整理したうえで、今日から手をつけられる順番をお伝えします。
何が起きたのか：Astraが「Critical」に分類された
OpenAIは2026年9月1日、公式ブログ「Path to Astra: critical capabilities and frontier safeguards」で、開発中のモデルAstraが同社のPreparedness Framework（備えの枠組み）におけるサイバーセキュリティ能力の「Critical」水準に達したと判断したことを公表しました。同社のモデルでこの水準に指定されるのは初めてです。
公式の表現をそのまま訳すと、「適切なツールとアクセスが与えられれば、人が一手ずつ指示しなくても、多くの十分に防御されたシステムに対して、未知のセキュリティ上の欠陥を見つけ、それを悪用する手段を組み立てられる」水準です。
「Critical」の定義は2つのうちどちらか
Preparedness Frameworkでは、次のどちらかを満たすとCriticalに該当するとされています。
- 多くの堅牢な実システムに対し、人の介在なしに、あらゆる深刻度の実用的なゼロデイ攻撃コードを特定・開発できる
- 高いレベルの目的を与えられただけで、堅牢な標的に対する新規の攻撃戦略を最初から最後まで立案・実行できる
「Critical」の一段下には「High」という区分があります。CNBCの解説によれば、Highが「既存の経路を増幅する」段階であるのに対し、Criticalは「前例のない新しい経路を生む」段階として定義されています。この差が、今回の発表が大きく扱われた理由です。
8月の「達しうる」と、9月の「達した」は別の発表です
ここは検索して調べる際に混同しやすいので、先に切り分けておきます。
2026年8月10日時点の報道（CSO Online）では、OpenAIは「AstraがCriticalに達する可能性がある」という事前評価を出した段階で、正式な分類はまだ行われていませんでした。この段階でも隔離されたテスト環境・ネットワークとツールのアクセス制限・モデルの重みの保護強化といった措置は始まっています。
9月1日の発表は、その後の追加検証を経て「達したと判断した」という確定の告知です。日付を見ずに記事だけを拾うと、同じ話が2回起きたように見えたり、逆に「まだ確定していない」と誤読したりします。この種のニュースは、発表日と発表主体をセットで確認するのが安全です。
評価で実際に何が確認されたのか
公式文書には、判定の根拠となった評価結果が具体的に書かれています。
- 既知の脆弱性から攻撃コードを開発する能力を測るベンチマーク「ExploitBench」で100%を記録
- ベンチマークの汚染（学習データへの混入）を避けるため、より新しく公開された20件の高深刻度のV8脆弱性で内部版を作成。従来モデルより少ない出力トークンで高い任意コード実行率を達成
- その評価の最中に、モデルが未知の脆弱性2件を自ら発見し、攻撃の連鎖に組み込んで使用。OpenAIは現在この2件を開発元へ報告する手続き中
- 専門家主導の評価では、堅牢化されたブラウザに対してサンドボックスを脱出してホスト上でコマンドを実行する連鎖を構築。堅牢化されたOSでも一般ユーザーから管理者権限への昇格の連鎖を構成
なお公式は、これらの結果は後述する限定アクセス構成でのものであり、通常の製品構成のものではないと注記しています。「一般提供されるAstraがこの通りに動く」という意味ではありません。
報道の見出しと、実務に効く記述はズレています
ここからが本題です。この発表を「AIによるサイバー攻撃が始まる」と読むと、中小企業の手元では何も動きません。実際に読むべき箇所は別にあります。
提供は絞られる：まずアルファテスター、次にDaybreak Blue経由
OpenAIはAstraを「近く」提供するとしていますが、高度なサイバーセキュリティ用途へのアクセスは制限されると明記しています。まず少数のアルファテスターに限定し、その後「Daybreak Blue」を通じて防御目的の利用へ広げる、という順序です。
ここも二次情報では要約が丸まりやすい箇所です。「Daybreakという連合の限定組織にだけ提供」と書かれることがありますが、公式の表記はDaybreak Blueで、防御側（Blue）の用途に開いていくという文脈が付いています。固有名詞は公式の綴りで確認するのが無難です。
つまり、今日この瞬間に「Astraを使った攻撃」を心配する段階ではありません。心配すべきなのは、能力の高いモデルが世に出ること全般であって、特定の1モデルの発売日ではないのです。
選定の視点：「速さ」ではなく「止められる体制があるか」
もうひとつ、公式文書には開発の経緯が書かれています。OpenAIは、外部で起きたインシデントを受けてAstraを含む一部のフロンティア学習を2週間停止し、学習基盤の隔離・ネットワーク制御・監視の強化を行いました。より大規模な強化学習の実行はさらに長く保留され、新しい安全・セキュリティ要件を整えたうえで2026年8月28日に再開したとされています。
これは中小企業のツール選定にも使える視点です。私たちがベンダーの安全性を自前で検証することは、現実的に不可能です。できるのは、そのベンダーが自社の開発を止める判断を実際に下せる体制を持っているか、そしてその経緯を公開しているかを見ることだけです。
性能の数字は各社が競って出しますが、「止めた」という記録は都合の悪い情報なので、出す会社と出さない会社に分かれます。ここは選定時に効く判断材料になります。
公式文書でいちばん実務に効くのは、最後のほうの一節です
公式ブログには「What this will mean for users（利用者にとって何を意味するか）」という節があります。ここが、中小企業のAI運用に直接効きます。
要点はこうです。安全確認の仕組みが正当な作業を誤って検知し、遅延・一時停止・停止させることがある。しかもそれはサイバーセキュリティと直接関係ないように見える作業や、長時間動き続けるエージェントのタスクでも起こりうる。
止められたときの挙動も書かれています。
- ChatGPTやCodexの画面上では、続行前に利用者へ確認を求められることがある
- APIなど他の経路では、そこでタスクが止まる
OpenAI自身も「当初は意図するより摩擦が大きくなる見込み」と認めたうえで、調整を続けるとしています。
無人で動かしている側から見ると、これは相当に重い話です
私は現在、常時稼働させている小型のMac 1台で、AIエージェントの定型ジョブを毎日決まった時刻に自動実行しています。記事の下書き、情報収集、変換処理といった作業が、人が寝ている時間に無人で走る構成です。
この構成の弱点は、はっきりしています。止まったことに、その場では誰も気づかないという点です。対話しながら使っていれば「止まりました」という表示が目に入りますが、無人ジョブは黙って終わります。翌朝、成果物が無いことで初めて気づく。
公式文書が名指ししている「長時間動き続けるエージェントのタスク」は、まさにこの型です。今回の変更は、私にとって「攻撃されるかもしれない」より先に「自分の仕組みが止められるかもしれない」という話として届きました。
そしてこれは、AIに定型業務を任せ始めた中小企業すべてに当てはまります。請求データの整形、問い合わせの一次仕分け、日次のレポート生成——夜間バッチとしてAIに任せている作業があるなら、同じ立場です。
「止まる前提」で自動化を組む4つの設計
止まらないようにする、という方向は現実的ではありません。安全装置の判定基準は提供側が持っており、こちらから制御できないからです。取れる手は「止まっても業務が死なない形にしておく」ことだけです。
私が自分の運用で実際に効いていると感じている4点を挙げます。特別な技術は要りません。
①「止まっていい場所」を先に決めておく
ひとつの長い自動化を、途中で止まっても構わない区切りに分けます。たとえば「情報を集める」「下書きを作る」「公開する」を1本のジョブにせず、間に区切りを置く。
そのうえで、絶対に途中で止まってはいけない工程はどこかを決めます。私の場合、外部へ公開する工程と、既存の資産を書き換える工程がそれに当たります。この2つは、途中で止まると中途半端な状態が世に出てしまうためです。
逆に言えば、それ以外はいつ止まっても構わない。この線引きをしておくと、止まったときの判断が「全部やり直す」ではなく「どこから再開するか」に変わります。
役割の分け方と停止点の置き方は、こちらで詳しく整理しています。
②止まったことに気づく経路を、ジョブ本体と分ける
ジョブの中で「完了しました」と通知させる設計は、ジョブが止まると通知も止まるという致命的な弱点を持ちます。成功したときだけ鳴るベルは、鳴らない理由を教えてくれません。
私は、ジョブ本体とは別に「今日はこの時刻に動いたはずだ」という前提側から見る仕組みを持たせています。成果物が出ていないこと自体を異常として扱う、という発想です。
中小企業の現場に置き換えるなら、「毎朝9時にレポートが届く」運用にしているなら、届かなかった日に気づく人を決めておくだけでも違います。仕組みの前に、役割の話です。
③途中で止まって再実行しても壊れない形にする
止まったジョブは、原因を調べてもう一度動かすことになります。このとき、2回動いても結果が同じになるように作っておくと、再実行の判断が軽くなります。
逆に、動かすたびに件数が増えるような作りだと、「もう一度動かしていいのか」を毎回考えることになり、結局その調査に時間を取られます。
実務的なコツは、「既に処理済みかどうか」を記録する場所を持つことです。私は処理の台帳を1つのファイルとして持ち、同じ対象を二重に処理しないようにしています。地味ですが、止まる前提の運用ではここが効きます。
④使っていない権限を、許可のまま置かない
AIエージェントに渡す権限は、「本当に必要か」「もし誤作動したときに水際で止められるか」で判断しています。使っていない外部連携を許可状態のまま放置しておくメリットは、ひとつもありません。
これは抽象論ではなく、実際に痛い目を見たことがあるからです。以前、制作中のWebサイトで、公開前なので検索結果に載らないよう設定していたにもかかわらず、AIがその設定を「検索エンジンに見せる」状態へ変更してそのまま反映してしまったことがありました。悪意ある攻撃ではありません。指示の解釈がずれただけです。
以来、書き換えてほしくないファイルには明示的な編集禁止を設定しています。攻撃を受けなくても、自分のAIは事故を起こします。今回の発表は、この当たり前を思い出させる材料でもありました。
OpenAIが対策を「2つの経路」に分けた理由
もう一点、公式文書で実務に効く整理があります。OpenAIは深刻な被害の経路を2つに分けて対策していると明記しています。
- 悪意ある人がモデルを使う経路。未知の欠陥に対する攻撃コードの開発や、堅牢な標的への一連の攻撃に使われることを防ぐ
- モデル自身が、許可されていない行動を取る経路。悪意ある利用者がいなくても、モデルの目的がずれていれば被害を起こしうる
そして後者は社内開発と外部提供の両方に当てはまるとされています。つまり「外から攻撃されないか」だけでなく、「自分が動かしているAIが、頼んでいないことをしないか」を同じ重さで見ている、ということです。
ハニーポット試験の数字は、条件付きで読む
公式文書には、この2つ目の経路を測った試験の結果が載っています。難しすぎるタスクを与えたとき、周辺のセキュリティ基盤に手を出して近道しようとするかを見る「おとり」の試験です。
従来モデルのGPT-5.6 Solは56%のケースで対象へアクセスを試みたのに対し、Astraは一度も試みなかったと報告されています。
ただし、この数字には公式自身が但し書きを付けています。安全装置を外したテスト条件下での挙動であり、通常の製品利用時のものではありません。「新モデルのほうが安全だから対策不要」と読むのは誤りで、あくまで能力が上がるほど、この経路の監視が必要になるという文脈の数字です。
自社でAIエージェントに作業を任せているなら、この論点は他人事ではありません。監視をどう設計するかは、こちらで整理しています。
攻撃の自動化が進む前提で、中小企業が先にやること
ここまでは「自社のAIが止まる・暴れる」側の話でした。最後に、攻撃側の能力が上がる前提で何を先にやるか、順番を整理します。
①まず「自分が外に何を晒しているか」を実測する
順番として、これが最初です。防御を足す前に、守る対象の輪郭を知る必要があります。そしてこの輪郭は、設定画面を眺めていても分かりません。
私自身の経験を書きます。外出先から自宅の作業マシンへ安全に入る仕組みを入れたあと、「本当にこれで安全になったのか」を確かめるために、外部のネットワークから自分のマシンへ疎通を試しました。結果、その仕組みとは無関係に、リモート接続用のポートが生のインターネットから直接届く状態だったことが分かりました。
原因は、IPv4とIPv6で防御の構造が違うことでした。IPv4では家庭用ルーターのアドレス変換が事実上の壁になりますが、IPv6にはその仕組みがなく、各端末が世界から直接届くアドレスを持ちます。ルーター側の遮断設定が無効なら、そのまま外に開くわけです。
重要なのは、これは外から実際に叩いてみるまで気づけなかったという点です。設定画面上は何も異常に見えませんでした。「対策製品を入れたから安全」という思い込みが、いちばん危ない状態を作ります。
②見つけた穴は、慌てず「確率×被害×手間」で裁く
穴が見つかったとき、そのまま恐怖に飲まれると判断が雑になります。私は次のように整理しました。
- 発生確率：極めて低い。IPv6のアドレス空間は膨大で、手当たり次第に探し当てるのは現実的でない。実際、直近のログに攻撃の痕跡は無かった
- 被害の大きさ：甚大。入られれば作業環境ごと持っていかれる
- 対策の手間：5分。設定を1つ変えるだけで、外から届く住所そのものが消える
「今まさに危険だから緊急対応する」ではなく、「確率は低いが被害が大きく、対策が安いから保険として塞ぐ」という判断です。この整理の仕方は、AI時代のセキュリティ判断全般に使えます。攻撃の自動化が進むと変わるのは、この3つのうち「発生確率」だけだからです。
裏を返せば、手間の安い対策から順に潰しておけば、確率が上がっても慌てずに済みます。今回の発表を受けて新しい製品を買う前に、既に分かっている穴が残っていないかを見るほうが先です。
③スキャンは道具として自分の手元に置ける
「脆弱性の発見が自動化される」という話は、防御側にも同じだけ効きます。OpenAI自身、防御側の支援を安全方針の柱のひとつに挙げています。
実際、コードの脆弱性を検査する道具は、すでに手元のコマンドラインで動かせる形で提供されています。使い方はこちらで解説しました。
Codex Security CLIとは｜脆弱性スキャンの使い方
ただし、これを入れれば安心という話ではありません。私は「仕組みで検問し、人が最後に確認する」という形を崩さないようにしています。自動化された検査は見落としを減らしますが、何を守るべきかの判断は代われないからです。
④社内向けのルールは、技術より先に決まっているべきです
技術的に防げる部分は年々増えていますが、実際の事故は人の側で起きることが多いというのが、これまで見てきた実感です。何を入力してよいか、誰がどこまでの権限を持つか——このあたりは、新しいモデルが出るたびに揺れる話ではありません。
基本の整理はこちらにまとめています。
よくある質問
Q. Astraはいつから使えますか
OpenAIは「近く」提供するとしていますが、具体的な日付は公表されていません。加えて、高度なサイバーセキュリティ用途については提供先が絞られます。まず少数のアルファテスター、その後Daybreak Blueを通じて防御目的の利用へ広げる順序です。詳細な安全性・整合性の検証結果は、提供開始時のシステムカードで公開されるとされています。
Q. 自社で使っているChatGPTやCodexが急に止まったら、障害ですか
切り分けが必要です。サービス全体の障害である可能性と、今回説明した安全確認の仕組みによる一時停止である可能性の両方があります。画面上で確認を求められている場合は後者の可能性が高く、続行の操作で先に進めることがあります。
まずサービス側が落ちていないかを確認する手順は、こちらにまとめています。
ChatGPTの障害を確認する方法｜Workが止まった時の手順
Q. 「Critical」は他社のAIにも付いている区分ですか
いいえ。Preparedness FrameworkはOpenAI社が自社で定めて運用している枠組みで、2023年に導入されたものです。他社は別の名称・別の基準で自社モデルを評価しています。「Criticalかどうか」でモデル同士を横並び比較することはできません。
Q. 中小企業として、結局いま何をすればいいですか
優先順に3つです。①AIに任せている自動化のうち、途中で止まると困るものを洗い出す ②止まったときに気づける人・仕組みを決める ③自社が外に晒している接続口を実際に確認する。新しいツールの導入判断は、この3つのあとで構いません。
まとめ
要点を整理します。
- 2026年9月1日、OpenAIはAstraを自社で初めてサイバーセキュリティ能力「Critical」に分類したと公表した
- Criticalとは「人が一手ずつ指示しなくても未知の欠陥を見つけ悪用できる」水準。評価中に実際に未知の脆弱性2件を発見・使用し、現在開発元へ報告手続き中
- 8月10日時点の「達しうる」という事前評価と、9月1日の「達した」という確定は別の発表。日付を見ずに拾うと誤読する
- 提供は絞られる。まずアルファテスター、その後Daybreak Blue経由で防御用途へ。今日いきなり攻撃に使われる段階ではない
- 実務にいちばん効くのは公式文書の後半。安全装置が正当な作業まで遅延・停止させうる。特に長時間動くエージェント。APIでは確認なしに止まる
- 取れる手は「止まらせない」ではなく「止まっても業務が死なない形にする」。停止点／通知経路の分離／再実行しても壊れない設計／不要な権限を残さない、の4点
- OpenAIは「悪用する人」と「モデル自身のずれた行動」を2つの経路に分けて対策している。自社でも同じ2軸で見る
- 攻撃の自動化で変わるのは「発生確率」だけ。被害の大きさと対策の手間は変わらないので、手間の安い対策から先に潰す
- 守る対象の輪郭は設定画面では分からない。外から実際に確かめるまで気づけない穴がある
モデルが強くなるほど、安全装置も強くなります。その結果として最初に効いてくるのは、攻撃ではなく自分の自動化が止まることです。止まる前提で組み直しておけば、次に何が来ても慌てずに済みます。
どの業務をAIに任せ、どこに止まってよい区切りを置くかを一緒に設計する支援を、株式会社Fyveでは月額で行っています。詳しくは専属AI活用顧問サービスをご覧ください。
AIを使う会社と、使わない会社。
その差は、開き始めています。
ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。
