モデルに「エクスプロイトチェーンを書いて」と頼むと、たいてい断られる。安全のためにそう調整されているからだ。ところが8月11日にOpenAIが出したgpt-5.6-cyberは、その断り方を意図的に緩めてある。同じ種類の依頼に対して、ベースの汎用モデルGPT-5.6 Solが応じるのは1.5%なのに、Cyberは95.0%応じる。この数字が何を意味するのか、そしてなぜOpenAIがこれを一般公開せず「防御側だけ」に配るのかを整理したい。

日本語圏ではまだほとんど解説されていないが、これは単なる新モデルの話ではなく、AIベンダーが「攻撃能力の高いモデルを誰にどう渡すか」という統治問題に初めて正面から製品で答えた事例だ。

「拒否を減らす」がなぜ機能になるのか

前提を一つ。セキュリティの世界で言うゼロデイは、まだ修正パッチの出ていない未知の脆弱性を指す。そしてエクスプロイトチェーンは、複数の小さな穴を数珠つなぎにして実際に権限を奪うところまで持っていく攻撃の組み立てだ。この二つは、攻撃者が使えば凶器だが、防御側が自組織の製品を守るために先回りして探すときにも同じ手つきが要る。いわゆるデュアルユース(両用)だ。

問題は、汎用LLMの安全調整がこの「防御のための攻撃的作業」まで巻き添えで断ってしまうことだった。OpenAI自身、旧世代のGPT-5.5-Cyberでも該当タスクの完遂率は57.3%にとどまり、正規の脆弱性研究者が「まっとうな依頼なのに拒否される」不満を抱えていたと認めている。つまりCyber版で起きているのは能力の底上げというより、拒否そのものを剥がす調整だ。この違いは重要で、OpenAIも「エクスプロイト開発では上回るが、脆弱性レポートの作成はむしろ苦手で、記述が短く薄くなる」と説明している。攻撃の手を動かすのは得意になったが、報告書を書く力が伸びたわけではない。

数字で並べると差がはっきりする。指標はOpenAIのACR(Advanced Cybersecurity Completion Rate、高難度サイバー依頼の完遂率)だ。

モデル / アクセス	高難度サイバー依頼の完遂率(ACR)
GPT-5.6 Sol(汎用)	1.5%
Daybreak Blue 経由	2.0%
GPT-5.5-Cyber(旧)	57.3%
GPT-5.6-Cyber	95.0%

エンジニア目線で言い添えると、この95%は「賢さ」の指標ではない。権限昇格や認証バイパスといった依頼を、途中で断らず最後までやり切った割合だ。ベンチマークの得点表というより、安全弁をどこまで開けたかのメーターに近い。

Blueは入口、Redは審査つき

配り方が今回の肝だ。OpenAIはサイバー向けプログラムDaybreakを二段構えにした。

	Daybreak Blue	Daybreak Red
使えるモデル	GPT-5.6 Sol など汎用フロンティア	GPT-5.6-Cyber
想定ユーザー	ほとんどの防御担当者(推奨の入口)	経験を積んだ防御担当者
主な用途	脆弱性発見、セキュアコードレビュー、マルウェア解析、インシデント対応、パッチ検証	認可された脆弱性研究、エクスプロイト検証、セキュリティテスト
安全弁	防御作業向けに調整	高リスクの両用タスクで拒否を低減

Redは希望すれば誰でも使えるわけではない。本人確認や法的な誓約に加え、個人アカウントでは2026年9月1日からハードウェアセキュリティキーが必須になる。承認済みの提携先(Accenture、IBM、PwC、Palo Alto Networks、Sophos、CrowdStrike、Cloudflare、Fortinetなどが名を連ねる)を中心に、身元と用途を縛った上で初めて開く扉になっている。

APIの制約もこの思想を映している。gpt-5.6-cyberはResponsesエンドポイントでしか叩けず、Chat CompletionsやBatch、Fine-tuningは軒並み塞がれている。追跡しやすい単一の経路に絞った、と読める設計だ。

model:            gpt-5.6-cyber
endpoint:         v1/responses のみ(Chat Completions / Batch / Fine-tuning は不可)
context window:   400,000 トークン(入力上限 272,000)
knowledge cutoff: 2026-02-16
price / 1M tok:   入力 $12.50 / キャッシュ入力 $1.25 / 出力 $75.00

出力$75/百万トークンは汎用モデルより明確に高い。能力というより、アクセスを絞って監視するコストが乗った価格だと見るのが自然だろう。

実績と、OpenAI自身が認めるリスク

抽象論で終わらせないために成果も一つ。OpenAIはこのモデルでChromeのJavaScriptエンジンV8に未知の欠陥を見つけ、CVE-2026-15903(CVSS 8.8、境界外の読み書き)として修正に至ったと公表している。報道ベースではOSカーネルの権限昇格につながる不具合を400件超見つけたという数字も伝えられているが、こちらは提携先経由の集計で、OpenAIの公式記述はV8の事例を核にしている。裏取りの粒度が違うので、確実なのはV8のCVEの方だと押さえておきたい。

そしてOpenAI自身が留保をはっきり書いている。

Models running with reduced safeguards carry risks beyond standard model usage, whether from misuse or misalignment.
(安全弁を下げて動くモデルは、誤用であれミスアライメントであれ、通常利用を超えるリスクを負う。)

ここに今回の本質が凝縮されている。攻撃側がAIで自動化を進める以上、防御側にだけ手足を縛らせては非対称が広がる。だから拒否を外したモデルを渡す。ただし渡す相手と経路は徹底的に絞る。能力の解放とアクセスの封じ込めを、モデル調整ではなくプログラムの階層と本人確認で担保するという設計判断だ。

私の見立てを言えば、この「モデルは緩め、配布で締める」やり方は今後の業界標準になりうる。RLHFで一律に断らせる方式は、防御という正当なユースケースを巻き添えにするコストが大きすぎた。一方で、身元確認と単一APIへの集約が実運用でどこまで漏れを防げるかは未知数だ。ベンダーが誰を「信頼できる防御側」と認定するのか、その線引き自体が新しい攻撃対象になる。手元で試せる類の技術ではないが、AIの安全性が「モデルの中」から「配布の外側」へ移り始めた転換点として、エンジニアなら押さえておく価値がある。

一次ソースは以下。

補足の報道はSecurityWeekを参照した。

※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。