
- OpenAIが防御向けAI「Daybreak」を2階層化し、特化モデルGPT-5.6-Cyberを投入した
- 95.0%という数字は脆弱性発見力ではなく、高リスク依頼への応諾率の高さを示す指標である
- 会議録音や議事録データの保有量を減らし、権限階層と初期設定の安全側化でAI利用を制御する備えが実務上有効だ
米OpenAIは8月10日(現地時間)、サイバーセキュリティの防御者向けに提供してきた取り組み「Daybreak」を拡張したと公式ブログで発表した。承認ユーザー向けに「Daybreak Blue」と「Daybreak Red」という二つのアクセス階層を新設し、Daybreak Red経由でサイバーセキュリティに特化した新モデル「GPT-5.6-Cyber」の提供を始める。攻撃者がAIを使った攻撃を大規模に、しかも完全自律的に展開できるようになる前に、信頼できる防御側へ最先端の能力を届ける必要があるとOpenAIは説明している。日本語ではITmedia NEWSも8月11日に報じた。
通常のChatGPTやAPIは、悪用を防ぐためサイバーセキュリティ関連の要求を選別する仕組みを持つ。ただしOpenAI自身が明かしている通り、この仕組みは脆弱性診断やインシデント対応といった正当な防御作業まで一緒に断ってしまうことがある。Daybreak Blueは、審査を通過したユーザーに対してこの選別を外し、汎用の最先端モデル「GPT-5.6 Sol」を脆弱性発見・セキュアコードレビュー・マルウェア解析・インシデント対応・パッチ検証に使えるようにする階層で、OpenAIはこれを「大半の防御者にとっての出発点」と位置づけている。Daybreak Redはさらに一段階踏み込み、承認された脆弱性研究やエクスプロイト(脆弱性を実際に悪用する手順)の検証、セキュリティテストを対象に、専用学習済みのGPT-5.6-Cyberを提供する。外側の選別を審査で緩めても、モデル自身が拒む依頼は残るという二重の設計になっている。
数字が示しているのは、能力の高さというより拒否の少なさである。OpenAIは、複数の脆弱性を連続して悪用し最終的に大きな権限を奪う一連の手順(以下、エクスプロイトチェーン)の開発や、認証の回避、権限昇格といった高度な依頼にモデルがどれだけ応じるかを測る社内指標「Advanced Cybersecurity Completion Rate」を公表した。この指標でGPT-5.6-Cyberは95.0%の依頼に応じたという。GPT-5.6 Sol単体では1.5%、Daybreak Blue経由でも2.0%にとどまり、前世代のGPT-5.5-Cyberでさえ57.3%だった。旧モデルは正当な依頼まで拒み続けるという、セキュリティ研究者からの不満に応えた格好だ。
実績も具体的に示されている。ChromeのJavaScriptエンジン「V8」にGPT-5.6-Cyberを向けたところ、未知の脆弱性が2件見つかった。OpenAIの説明によれば、うち一つは数値を整数に変換する処理でコンパイラが安全確認を一つ飛ばしてしまう不具合で、未定義の値が本来ありえないほど大きな数値に化け、それが配列の添字に使われると本来効くはずの境界チェックをすり抜けてしまう。もう一方の脆弱性と組み合わせるとメモリを破壊し、ヒープサンドボックス(プログラムの被害範囲を区切る隔離壁)を脱出できるエクスプロイトチェーンになる。OpenAIの研究者が検証したうえでGoogleに報告し、修正されて「CVE-2026-15903」が割り当てられた。ほかにもモバイルOSで5件以上、データベースで3件、OSカーネルで400件超の重大な脆弱性が見つかったというが、製品名はいずれも明かされていない。
安全性についても評価を公表している。自社の安全性評価の枠組み「Preparedness Framework」でGPT-5.6-Cyberのサイバー能力を測ったところ、GPT-5.6 Solと同じく上から2番目の「High」段階に達し、最上位の「Critical」には届かなかったという。そのうえでアクセス制御の中身にも踏み込みがある。OpenAIは、身元確認・アカウントセキュリティ・監視・利用目的の誓約という複数の管理を組み合わせて利用者を絞ると説明したうえで、2026年9月1日からDaybreakの個人アカウントすべてにハードウェアセキュリティキー(USBに挿す物理的な認証デバイス)の導入を義務付けると発表した。あわせて、コーディング支援ツール「Codex」を使うDaybreak利用者には、確認なしに操作を実行する「フルアクセスモード」ではなく、強い権限を必要とする操作を実行前に評価し、破壊的な結果になるリスクが高いものはブロックできる「自動レビューモード」への切り替えを強く推奨している。先行提供を受けたセキュリティ企業SpecterOpsのCTO、Jared Atkinson氏は「実際のエクスプロイトの制約についてより正確に推論し、複雑な状態を的確に追跡できる。従来のモデルなら断続的な作業で数週間かかっていたものを1日足らずで終わらせた」とOpenAIに寄せたコメントで評価している。強力な能力を渡すのと同時に、事故が起きたときの被害をどこで止めるかをセットで設計する姿勢がうかがえる。
このニュースが働き方に関わってくるのは、業務で扱う録音・文字起こし・議事録の類が「守るべきデータ」として、これまでより具体的な攻撃想定の対象になったという点だ。OpenAIが報告したOSカーネルの権限昇格経路400件超やモバイルOSの権限連鎖は、スマートフォンやクラウド上に置かれたファイルへ到達する経路そのものである。会議の録音・文字起こし・議事録データがどこに何件残っているか把握できていない状態は、攻撃側が同種のAIを使い始める前提に立つと、そのまま被害範囲の広さに直結する。まず着手すべきは保有量を減らすことだ。文字起こし後に音声データを残す運用になっていないか、共有リンクの権限が期限なく開いたままになっていないか、録音に使う端末がOSアップデートの対象から漏れていないかを棚卸しする。守る対象が小さいほど、防御側が高性能なAIを使う意味も大きくなる。
もう一つ、今回の発表全体が示す論点がある。OpenAIは能力そのものを制限するのではなく、「誰が」「どの階層で」使えるかという身元と用途で制御し、そのうえで既定の安全度を引き上げる方式を選んだ。個人アカウントへのハードウェアキー義務化も、Codexの既定モードをフルアクセスから自動レビューへ寄せる判断も、便利さより先に「間違えたときの被害をどこで止めるか」を決めている点で共通する。これは組織がAIをどう権限づけて使わせるかという設計にそのまま応用できる考え方である。議事録や商談記録を扱うAIツールを導入する場合も、全員が同じ権限で同じモデルにアクセスするのではなく、役割や案件の機密度に応じてアクセス階層を分け、初期設定そのものを安全側に振っておく発想が実務上は現実的だ。権限設計と既定値の安全側化を後回しにしたまま便利さだけを先に導入すると、あとから絞り込む調整はほぼ必ず摩擦を生む。




