OpenAI Daybreak とは｜Blue と Red の違いと申請の注意点

はじめに

2026 年 8 月 10 日、OpenAI は自社のサイバーセキュリティ向けアクセスプログラム「OpenAI Daybreak」を拡張し、Daybreak Blue と Daybreak Red という 2 つのアクセスレベルを公表しました。あわせて、Daybreak Red 経由で提供されるサイバーセキュリティ特化モデル GPT-5.6-Cyber も発表されています。

ニュースとしては目にしたものの、「結局これは誰が使えるものなのか」「個人のエンジニアが申請できるのか」「承認されたら何が変わるのか」が分かりにくいと感じた方も多いのではないでしょうか。公式情報がブログ、製品ページ、ヘルプセンター、Codex ドキュメントに分散していることも、全体像を掴みにくくしている一因です。

筆者自身も個人アカウントで Trusted Access for Cyber を申請し、本人確認を経て Daybreak Blue の承認を受けました。本記事では、公式ドキュメントで確認できる内容と、実際に申請して分かった内容を切り分けながら整理します。

先に結論を述べます。Daybreak は、料金を支払えば誰でも利用できるプランではなく、本人確認と OpenAI 側の審査を経た承認制のアクセスプログラムです。承認されても OpenAI の利用ポリシーが免除されるわけではなく、利用は承認された用途と承認された本人（または組織の内部業務）の範囲に限定されます。多くの防御業務では、まず Daybreak Blue が出発点として位置づけられています。

OpenAI Daybreak とは

OpenAI Daybreak は、フロンティアモデルをサイバー防御の実務に使えるようにするための取り組み全体を指す名称です。その中で、モデルへのアクセスを制御する枠組みが Trusted Access for Cyber であり、Daybreak Blue と Daybreak Red はそこで定義されたアクセスレベルにあたります。

Trusted Access for Cyber と Daybreak の関係

Trusted Access for Cyber は、2026 年 2 月 5 日に OpenAI がパイロットとして公表した、本人確認と信頼性評価に基づくアクセスの枠組みです。ヘルプセンターでは、Daybreak Access が Trusted Access for Cyber プログラムそのものであり、Daybreak Blue と Daybreak Red がそのアクセスレベルであると説明されています。

つまり、名称としては次のような関係になります。

• Daybreak: フロンティアモデル、Codex Security、パートナープログラムなどを含む取り組み全体の名称
• Trusted Access for Cyber: 誰にどのモデルを開放するかを審査・管理するガバナンスの枠組み
• Daybreak Blue / Daybreak Red: 審査を通過した利用者に付与されるアクセスレベル

ここを混同すると、「Daybreak に申し込む」という表現が申請フォームの話なのかアクセスレベルの話なのか分からなくなります。実務上は、申請するのは Trusted Access for Cyber であり、承認の結果として Blue または Red のアクセスレベルが付与される、と理解しておくと整理しやすくなります。

なお、アクセスは付与されたアクセスレベルだけで決まるものではありません。ヘルプセンターおよび Codex ドキュメントでは、承認と払い出しの対象が、利用者の identity、ChatGPT ワークスペースまたは API の組織・プロジェクト、承認されたモデル、そして利用できるプロダクト面（product surface）の組み合わせで決まると説明されています。同じアカウントでも、どの画面から使うかによって挙動が変わり得るということです。この点は実際に確認してみないと分かりにくいため、別記事で ChatGPT や Codex など各プロダクト面での確認結果を扱います。

Daybreak で想定される主なセキュリティワークフロー

Trusted Access for Cyber は、自分が所有・運用しているシステム、または明示的にテストや分析を許可されているシステムに対する、認可済みのサイバーセキュリティ業務を対象としています。ヘルプセンターでは、対象となる業務が次の 3 つのカテゴリに大別されると記載されています。

カテゴリ	含まれる業務の例
Secure SDLC / AppSec	継続的なコードスキャン、テスト環境のスキャン、検出結果の妥当性確認、セキュアコードレビュー、パッチ適用の自動化
Defensive operations	ブルーチーム業務、脅威モデリング、脅威インテリジェンス、脅威ハンティング、マルウェア解析、検知エンジニアリング、脆弱性トリアージ、パッチ検証
Authorized offensive testing	ペネトレーションテスト、レッドチーム演習、エクスプロイトの検証または開発、リバースエンジニアリング、認可された環境での検証

インフラ運用の観点で見ると、上の 2 カテゴリが日常業務に近い領域です。ログ解析、検知ルールの作成、脆弱性情報のトリアージ、パッチ適用計画の妥当性確認といった作業は、いずれも Defensive operations に含まれます。3 つ目の Authorized offensive testing は、認可された範囲での攻撃的テストを担当するチーム向けの区分で、後述する Daybreak Red の想定領域と重なります。

なぜ信頼ベースのアクセス制御が導入されたのか

背景には、防御的な依頼と攻撃的な依頼を文面だけで見分けることが難しい、という構造的な問題があります。OpenAI は Trusted Access for Cyber の発表時点で、「自分のコードの脆弱性を見つけてほしい」という依頼が、責任ある修正と協調的開示の一環である場合もあれば、システムを攻撃するための脆弱性特定に使われる場合もある、と説明しています。この曖昧さがあるため、悪用を防ぐための制限が善意の作業にも摩擦を生んできました。

参考: Introducing Trusted Access for Cyber（OpenAI）
“restrictions intended to prevent harm have historically created friction for good-faith work”
（訳）害を防ぐことを意図した制限が、これまで善意の作業に摩擦を生んできました。
https://openai.com/index/trusted-access-for-cyber/

Daybreak 拡張の発表では、この摩擦を減らすことがアクセスレベル導入の狙いとして示されています。通常の提供環境では、サイバーセキュリティ関連のリクエストをスクリーニングするシステムレベルのセーフガードが動作しており、これが正当な防御業務を妨げる場合があります。Daybreak Blue のアクセスでは、このシステムレベルのスクリーニングが認可済みの防御業務向けに調整され、不要な拒否が減るという位置づけです。公式ブログでは該当のガードレールを “removes” と表現していますが、対象はこのスクリーニング層であり、モデル自体の安全訓練、アカウント単位のアクセス制御、監視、そして OpenAI の利用ポリシーはいずれも適用され続けます。ヘルプセンターにも、Trusted Access for Cyber がすべてのセーフガードや拒否応答を取り除くものではないと明記されています。

実際、承認後も明らかに防御的な依頼が拒否されるケースは残り得ます。「承認を受ければモデルが何でも答えるようになる」という理解は正確ではありません。この点は、承認後の制約とあわせて後段で整理します。

Daybreak Blue と Daybreak Red の違い

Daybreak には Blue と Red の 2 つのアクセスレベルがあります。両者は上下関係というより、想定する業務の性質が異なる別のアクセスレベルです。Blue は日常的な防御業務全般を、Red は認可された環境での高度な脆弱性研究やエクスプロイトの検証を想定しています。Blue の承認を受けても Red が自動的に付与されることはなく、Red には別途の承認と有効化が必要です。

Daybreak Blue: 防御業務の標準的な入口

Daybreak Blue では、GPT-5.6 Sol を含む汎用のフロンティアモデルに、認可済みの防御業務向けに調整されたセーフガードを適用した状態でアクセスできます。OpenAI は、ほとんどの防御担当者にとってこれが推奨される出発点であるとしています。

ヘルプセンターおよび Codex ドキュメントで挙げられている想定用途は、次のとおりです。

• 脆弱性の発見とトリアージ
• セキュアコードレビューと脅威モデリング
• 検知エンジニアリングとインシデント対応
• 統制された環境でのマルウェア解析
• 修正対応とパッチの妥当性検証

一般的な防御業務の多くはこの範囲に含まれます。Codex ドキュメントでは Blue の作業例として、承認済みの検証用リポジトリを対象に認証まわりの弱点をレビューし、証跡と影響度で優先順位を付け、外部システムにアクセスせずに修正案を提示する、といった進め方が示されています。

Daybreak Red: 認可済みの高度な検証を想定したアクセスレベル

Daybreak Red では、サイバーセキュリティ向けに専用の訓練を施したモデル（現時点では GPT-5.6 Cyber）を利用できます。想定されているのは、認可されたペネトレーションテスト、レッドチーム演習、概念実証レベルのエクスプロイト開発とその妥当性検証、統制された環境での脆弱性研究です。

Codex ドキュメントは、Red が通常のセキュリティ業務における既定の選択肢ではないこと、そしてアクセスが自動的に付与されるわけでも、すべてのプロダクト面で使えるわけでもないことを明記しています。あわせて、これらのワークフローは認可された作業であるという文脈がなければ、外形上は攻撃活動と区別が付きにくいという注意も添えられています。そのため Red には、追加の承認に加えて、より強い本人確認、監視、アクセス制御、人によるレビューが求められます。

GPT-5.6 Cyber は GPT-5.6 Sol をベースに、ゼロデイ脆弱性の発見やエクスプロイトチェーンの構築といった専門タスクでの性能を高め、かつ高リスクなデュアルユース用途での拒否を減らすように訓練されたモデルです。OpenAI は Preparedness Framework に基づく評価で、GPT-5.6 Sol と同様にサイバー能力が High に達し、Critical のしきい値には達していないと判断したとしています。GPT-5.6 Cyber の詳細な評価は、後日公開されるシステムカードで示される予定です。

自組織の管理下でモデルを動かす選択肢との比較については、関連記事『オープンウェイトのセキュリティ向け AI モデル』もあわせて参考にしてください。

比較表

項目	Daybreak Blue	Daybreak Red
対象モデル	GPT-5.6 Sol（汎用フロンティアモデル）	GPT-5.6 Cyber（サイバー特化モデル）
何が変わるか	認可済みの防御業務向けにセーフガードがより精緻に調整される	高度な認可済みワークフロー向けの専門的な能力が利用可能になる
想定用途	脆弱性トリアージ、セキュアコードレビュー、マルウェア解析、検知エンジニアリング、インシデント対応、パッチ検証	認可されたペネトレーションテスト、レッドチーム演習、エクスプロイトの検証または開発、統制下での脆弱性研究
承認要件	Trusted Access for Cyber の申請と本人確認	上記に加えて別途の承認と有効化、より強い本人確認と監視、アクセス制御
API のモデル ID	エイリアス gpt-daybreak-blue / モデル ID gpt-5.6-sol	エイリアス gpt-daybreak-red / モデル ID gpt-5.6-cyber
位置づけ	ほとんどの防御担当者にとっての出発点	通常業務の既定の選択肢ではない

Amazon Bedrock 経由で利用する場合、モデル識別子は異なります。ヘルプセンターによると、Bedrock では Daybreak Blue が gpt-daybreak-blue-5.6-sol、Daybreak Red が gpt-5.6-cyber となり、gpt-daybreak-blue および gpt-daybreak-red のエイリアスは利用できません。

参考: OpenAI Daybreak – Trusted Access for Cyber Overview（OpenAI Help Center）
“Existing Trusted Access for Cyber or GPT-5.5-Cyber approval does not automatically include Daybreak Red.”
（訳）既存の Trusted Access for Cyber または GPT-5.5-Cyber の承認は、Daybreak Red を自動的に含みません。
https://help.openai.com/en/articles/20001258-openai-daybreak-trusted-access-for-cyber-overview

どちらを申請すべきか

判断の基準は、担当している業務が「守る側の分析」で完結するか、「認可された環境で実際に攻撃手法を再現・検証する」ところまで含むかです。

社内システムの脆弱性対応、ログ解析、検知ルールの整備、パッチ適用の検討といった業務が中心であれば、まず Daybreak Blue を検討するのが自然です。OpenAI 自身も Blue を出発点として推奨しています。一方、契約に基づくペネトレーションテストやレッドチーム演習を業務として担当している場合に、Daybreak Red の申請を検討する、という整理になります。

なお、以前の Trusted Access for Cyber や GPT-5.5-Cyber の承認を持っている場合でも、それが Daybreak Red のアクセスを含むわけではありません。ヘルプセンターでは、Daybreak Red には別途の承認と有効化が必要であると明記されています。既存の承認を持つ利用者は、承認されたモデルに対応する手順を引き続き参照することになります。

個人アカウントでの申請と本人確認の流れ

Daybreak は組織単位での申請だけでなく、個人でも申請できます。OpenAI は個人向けと組織向けで別の窓口を用意しており、個人は ChatGPT 上の申請ページから Trusted Access for Cyber を申請します。

• 個人: https://chatgpt.com/cyber
• 組織: OpenAI の enterprise 向け申請フォーム、および担当者との調整

以下は、筆者が個人アカウントで申請した際の流れです。手順や画面は変更される可能性があるため、実際に申請する際は公式ページで最新の内容をご確認ください。

審査で求められる場合がある情報

ヘルプセンターには、審査の過程で次のような情報の提出を求められる場合があると記載されています。

• 所属組織とそのサイバーセキュリティ上の能力
• 支援したい防御的なサイバーセキュリティのワークフロー
• 利用を想定している OpenAI の組織またはワークスペース
• 適格性を評価するために必要な本人確認・信頼性の情報

これらは「求められる場合がある」項目として記載されているもので、すべての申請で同じ内容が問われるとは限りません。筆者が個人アカウントで申請した際は、利用目的や担当業務を記述する入力項目はありませんでした。 組織単位での申請では、担当者とのやり取りの中で確認される可能性があります。

申請時に Daybreak Blue と Daybreak Red のどちらを希望するかを選択する項目もありませんでした。 筆者の場合は、本人確認の完了後に届いた承認メールで、Daybreak Blue に承認されたことを初めて把握しました。どのアクセスレベルが付与されるかは、申請者側で指定するのではなく、OpenAI 側の審査結果として通知される形になります。

本人確認で求められるもの

OpenAI の公式ドキュメントでは、アクセス制御の手段として identity verification（本人確認）、アカウントセキュリティ、監視、承認された用途の制限、法的な誓約が挙げられています。ただし、Daybreak および Trusted Access for Cyber に関する公式ページでは、提出する身分証明書の種類や検証事業者名までは明示されていません。この点は公式に確認できる範囲を超えるため、断定を避けます。

その上で、筆者が実際に申請した際は、政府発行の身分証明書として運転免許証を提示し、あわせてカメラによる本人確認を行いました。 パスポートやマイナンバーカードなど他の身分証で代替できるかどうかは、筆者の環境では確認していません。

申請が承認されるとは限らない

ここは事前に理解しておきたい点です。Codex ドキュメントには、申請の提出や本人確認の完了が承認を保証するものではないと明記されています。ヘルプセンターも、OpenAI が有効化の前にリクエストを審査し、承認は自動ではないとしています。

参考: Cyber Safety（ChatGPT Docs）
“Submitting an application or completing identity verification doesn’t guarantee approval.”
（訳）申請の提出や本人確認の完了は、承認を保証するものではありません。
https://learn.chatgpt.com/docs/cyber-safety

承認可否の判断材料としては、本人確認と信頼性の検証、リスク上の考慮、想定用途、そして申請者がより広いサイバーセキュリティのエコシステムを強化し得るかどうか、といった要素が挙げられています。また、Daybreak Blue の承認を受けたことが Daybreak Red のアクセスにつながるわけではない点も、繰り返し明記されています。

承認されたかどうかを画面上で確認する方法については、別記事で扱います。

承認後に適用される利用範囲と禁止事項

承認を受けた後の扱いについて、ヘルプセンターは「Trusted Access for Cyber がしないこと」を明示的に列挙しています。ここが実務上もっとも注意が必要な部分です。

承認された用途と内部利用に限定される

ヘルプセンターは、Trusted Access for Cyber の対象を承認された内部の利用者と内部のワークフローに限定しています。個人と組織で、読み替え方が少し異なります。

個人アカウントの場合、承認は申請した本人と、承認された用途に対して与えられたものとして扱うことになります。承認を受けたアカウントを他者に使わせることは、想定された利用の形ではありません。

組織の場合、対象は承認された内部ユーザーと内部ワークフローです。ヘルプセンターは、Trusted Access に使う組織やワークスペースを社内のセキュリティ業務専用とし、顧客向けアプリケーション、下流のプロダクトトラフィック、第三者からのアクセスを同時に扱わせないよう求めています。承認範囲を適切な従業員に限定したい場合は、内部専用の組織またはワークスペースを用意する方法が案内されています。

対象システムについての制限は、個人・組織のいずれにも共通します。自分が所有しているシステム、または明示的にテストや分析を許可されているシステム以外に対する活動は認可されません。これは Daybreak Blue であっても同様です。

再販、proxy、embed、第三者への提供は認められていない

ヘルプセンターの Limitations には、Trusted Access for Cyber が第三者顧客や外部利用者に対する再販、proxy、embed、下流でのアクセス提供を認めるものではない、と記載されています。

インフラエンジニアの立場で読み替えると、次のような使い方は想定外ということになります。

• 承認を受けたアカウントの API キーを、社外向けサービスのバックエンドに組み込む
• 承認を受けていない同僚や他部署に、自分のアクセス経由でモデルを使わせる
• 承認済みアクセスを中継する社内プロキシを立て、認可範囲外の利用者に開放する

外部向けのワークフローで Daybreak の能力を使いたい場合は、Daybreak Partner Program という別の枠組みが用意されています。パートナー向けの公式説明でも、モデルへのアクセスは承認されたパートナーの手元に留まり、顧客に直接移転されるものではないとされています。

利用ポリシーが免除されるわけではない

承認を受けても、OpenAI の Terms of Use と Usage Policies は引き続き適用されます。加えて、承認された利用者は Cyber Abuse Policy に同意する必要があります。これは、情報システムの完全性・機密性・可用性を侵害する行為への利用を禁じるもので、悪意を持って行われる、適切な認可を得ずに行われる、あるいは付与された認可の範囲を超えて行われるデュアルユースのサイバー活動も対象に含まれます。

「認可の範囲を超えた活動」も禁止対象に含まれる点は、実務上とくに意識しておきたいところです。契約上テスト対象に含まれるシステムと、たまたま同一ネットワークにあるだけのシステムを、作業の流れで混同しないための線引きが必要になります。

なお、API や組織単位で利用する場合、Zero Data Retention が既定で付与されるわけではない点もヘルプセンターに明記されています。

承認後もセーフガードが働く場合がある

Trusted Access for Cyber はすべてのセーフガードや拒否応答を取り除くものではありません。承認後であっても、防御的な依頼が拒否される場合はあります。

ヘルプセンターは、こうした場合にまず、承認された組織またはワークスペース、承認されたモデルまたはアクセス経路、想定されたプロダクト面を使用しているかを確認するよう案内しています。どの経路から利用しているかによって挙動が変わり得るため、承認直後は自分がどの状態で使っているかを把握しておくと切り分けが容易になります。実際の確認方法とプロダクト面ごとの挙動は、別記事で扱います。

安全に使うための運用と今後のアカウント要件

モデルを動かす環境については、利用者側で適切な隔離、権限設定、監視を設計する必要があります。Codex ドキュメントは、Trusted Access が承認済みのモデルアクセスを管理するものであって、利用者の環境設定や作業範囲の強制までは行わないと明記しています。ここでは、公式が推奨している運用と、今後予定されているアカウント要件を整理します。

sandbox による隔離

公式ブログが挙げるベストプラクティスの一つ目が、環境の隔離です。セキュリティ関連のワークフローは、機微な本番システムやインターネットへのアクセスを持たない統制された環境で実行し、その境界を定期的に検証することが推奨されています。

Codex ドキュメントはさらに踏み込み、認証情報、シークレット、永続的なアクセス、システムへの恒久的な変更を、書面上のスコープで明示的に必要とされない限り届かない場所に置くよう案内しています。あわせて、高リスクな作業を始める前にファイルシステムとネットワークの境界を実際にテストしておくこと、そしてモデルやレビュアーが個々の操作を承認した場合でもホスト環境の隔離を保つことが挙げられています。

スコープの明文化と権限の最小化

二つ目が、作業範囲の明文化です。モデルに作業を始めさせる前に、次の内容を文書化しておくことが推奨されています。

• 承認された対象システム、ホスト、環境
• 除外するシステム（本番環境や無関係なインフラを含む）
• 許可される操作と禁止される操作
• 作業期間とデータの取り扱い要件
• 脆弱性の開示、パッチ承認、メンテナーとの調整に関する取り決め
• 停止条件と、人の承認を必要とする操作

ここで重要なのは、文書化したスコープはそれ自体では何も強制しないという点です。Codex ドキュメントは、可能な限りファイルシステム、ネットワーク、identity、ツールの制御を独立して適用し、認可されていない操作を技術的に不可能にするよう求めています。Codex を使う場合は、permission profile によって最小権限の境界を設定できます。

Codex を使う場合、Full Access 系の設定（:danger-full-access や --yolo）は避けることが案内されています。これらを使うと、後述する自動レビューが前提としている sandbox の境界そのものが失われるためです。

human review と Codex の auto-review モード

三つ目が、操作のレビューです。OpenAI は Daybreak の利用者に対し、Codex を full-access モードから auto-review モードへ切り替えることを強く推奨しています。auto-review は、昇格した権限を必要とする操作を実行前に評価し、破壊的な挙動につながるリスクが大きいリクエストをブロックできる仕組みです。

ただし、Codex ドキュメントは auto-review の限界も明示しています。sandbox 内で既に許可されている通常の操作は検査されず、また自動レビュー自体も誤ることがあります。自動レビューは、隔離、書面上のスコープ、監視、人による明示的な監督を置き換えるものではないとされています。高リスクなワークフローほど、人の判断を挟む設計が求められます。

Responses API や Agents SDK など、Codex 以外のハーネスで組む場合は、ツール実行の境界に自前でレビューを実装する必要があります。Codex の auto-review は、外部のハーネスやカスタムツールを自動的に保護するものではありません。

2026 年 9 月 1 日以降のハードウェアセキュリティキー要件

アカウント側の要件として、期日が示されているものが一つあります。OpenAI は、2026 年 9 月 1 日以降、Daybreak のすべての個人アカウントにハードウェアセキュリティキーの採用を求めるとしています。

参考: Expanding Daybreak as the Cyber Defense Window Narrows（OpenAI）
“requiring all individual accounts in Daybreak to adopt hardware security keys”
（訳）Daybreak のすべての個人アカウントに、ハードウェアセキュリティキーの採用を求めます。
https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows/

個人で申請を検討している場合、この期日は事前に把握しておきたいところです。対応するキーの具体的な機種要件や、既に承認済みのアカウントで登録が完了していない場合の扱いについては、本記事の執筆時点で公式に確認できていません。実際に運用する際は、OpenAI の最新の案内をご確認ください。

このほか、2026 年 8 月 10 日時点の公式発表では、監視機能の改善を含む追加のセキュリティ施策を今後数週間のうちに展開するとされています。あわせて、今後の Daybreak リリースではアライメントの訓練とテストを優先することが表明されています。

インフラ運用の現場での位置づけ

インフラや社内システムを担当する立場から見ると、Daybreak Blue で扱える範囲は、日常的な防御業務の分析、検証、修正支援と重なります。脆弱性情報のトリアージ、ログからの異常の切り分け、検知ルールの検討、パッチ適用計画の妥当性確認といった作業です。

一方で、実際にどの業務でどこまで有効に使えるかは、対象システムの構成や、社内で許容される情報の取り扱い範囲によって変わります。この点は別記事で、インフラエンジニアの視点から具体的な適用場面を整理する予定です。

まとめ

OpenAI Daybreak は、料金を支払えば使えるプランではなく、本人確認と審査を経た承認制のアクセスプログラムです。個人でも申請できますが、承認は自動ではなく、承認後も利用ポリシーと認可範囲の制約が引き続き適用されます。

• Daybreak Blue と Red は上下関係ではなく別のアクセスレベル
• Blue は脆弱性トリアージや検知エンジニアリングなど幅広い防御業務が対象
• Red は認可済みのペネトレーションテストやエクスプロイト検証を想定
• Blue の承認を受けても Red には別途の承認と有効化が必要
• 個人申請では政府発行の身分証による本人確認が求められる
• 再販、proxy、embed、第三者への提供はいずれも認められていない
• 2026 年 9 月 1 日以降、個人アカウントにハードウェアセキュリティキーの採用が求められる予定

以上、最後までお読みいただきありがとうございました。