概要
このガイドは、組織の Daybreak オンボーディングを担当し、申請と利用資格審査を経て、実行可能な環境を整える必要がある方を対象としています。
Daybreak Access は、OpenAI の Trusted Access for Cyber プログラムです。Daybreak Blue と Daybreak Red は、Daybreak 内のアクセスティアです。
ほとんどの企業チームは、承認済みの社内防御ワークフロー向けに Daybreak Blue から始めることをお勧めします。
高度かつ正式に許可されたサイバーセキュリティワークフロー向けの Daybreak Red には、個別の承認が必要です。一部のフロンティアサイバーモデルには、モデルごとの追加承認が必要です。
承認を受けただけでは、拒否の抑制は有効になりません。Daybreak の設定は、初期状態ではオフです。ワークスペースのオーナーは承認済みユーザーとグループのアクセスを有効化し、API 組織のオーナーは承認済みのデフォルト以外のプロジェクトのアクセスを有効化します。チームが両方のアクセス経路を使用する場合は、両方を設定してください。ChatGPT で Codex にサインインするユーザーは、リクエストを送信する前に Daybreak をオンにする必要もあります。
アクセスを有効化した後も、リスクの高い一部のワークフローは拒否される場合があります。そのため、チームが実際に使用する予定の利用環境、プロジェクト、モデルで、範囲を限定した防御ワークフローから始めてください。
オンボーディングとアクセス状況の把握
| 段階 | 説明 | 次の対応 |
|---|---|---|
| 申請フォームの提出 | 組織が企業向け Daybreak 申請フォームを提出した状態です。 | Persona からのメールを確認し、組織の適切な担当者に届くようにしてください。組織ですでに Daybreak へのアクセスが承認されており、OpenAI の担当者から新たな申請は不要と案内されている場合は、重複して申請せず、その指示に従ってください。 |
| KYB 確認の完了 | Persona が、申請フォームに記載された担当者に、企業確認（KYB）手続きのためのメールを送信します。 | Persona から依頼された手続きを完了してください。その後、OpenAI が利用資格と適合性の内部審査を行います。 |
| 利用資格の審査結果の受領 | OpenAI が、承認済みアクセス経路と、組織が Daybreak Blue、Daybreak Red、またはその両方の利用資格を持つかどうかを通知します。Daybreak Red には、別途利用資格が必要です。 | 承認済みのユーザー、ワークスペースまたは API 組織、モデル、製品の利用環境を確認してください。Blue の利用資格があれば Red も利用できるとは考えないでください。プロビジョニングが完了すると、OpenAI から組織またはワークスペースの管理者にウェルカムメールが届きます。 |
| ワークスペースまたは API アクセスの設定 | ChatGPT と Codex へのサインインには、ワークスペースのオーナーが承認済みユーザーとグループのロールを設定します。API アクセスには、API 組織のオーナーが、承認済みのデフォルト以外の各プロジェクトで Daybreak を有効化します。以下の「承認済みアクセスの検証」の手順に従ってください。 | 対象のユーザーまたはプロジェクトに対して、承認済みのアクセスレベルのみを有効化して保存し、保存した設定を確認してください。デフォルトのプロジェクトでは、Daybreak を有効化できません。ワークスペースへのアクセスと API プロジェクトへのアクセスは別々です。 |
| 移行先プロジェクトの認証情報の使用 | API キーは、特定の組織とプロジェクトに属します。以前の組織やプロジェクトのキーでは、移行先にアクセスできません。 | 有効化されたプロジェクトの API キーを使用してください。別の組織やプロジェクトに移行した場合は、移行先でキーを作成または選択し、そのキーを使用するアプリケーションやワークフローを更新してください。認証情報の使用範囲は、承認済みの社内利用に限定してください。 |
| アクセスの検証と範囲を限定した防御ワークフローの開始 | 対象のワークスペースまたはプロジェクト、承認済みユーザー、モデル、API 認証情報がそろい、アクセスを確認できる状態です。 | 承認済みの利用環境で、以下のアクセス確認テストを実行してください。最初のワークフローを開始する前に、実行担当者とレビュー担当者を決めてください。 |
承認済みアクセス経路の把握
オンボーディングの確認通知には、承認済みのモデルと利用対象者、および最初に使用する組織、ワークスペース、API 組織、API プロジェクトが明記されている必要があります。
リポジトリを直接操作するワークフローでは、まず Codex または Codex Security プラグインを使用してください。承認済みの自動化には、Codex CLI または Codex GitHub Action を使用してください。API ワークフローでは、リクエストと認証情報の適用範囲を、承認済みの社内専用プロジェクトに限定してください。
| 承認済みアクセス経路 | 利用対象者 | 利用先 | 最初の利用に推奨されるインターフェース |
|---|---|---|---|
| Codex 経由のアクセス | 指定された社内の Codex または ChatGPT の組織・ワークスペースに所属する承認済みメンバー | オンボーディングの確認通知に記載された組織またはワークスペース | 静的アセットのセキュリティ作業では、まず Codex Security プラグインを使用してください。 |
| API プロジェクト経由のアクセス | API 組織のオーナーが、利用資格のある Daybreak の設定項目を構成します。承認済みのユーザーまたはサービスは、有効化されたプロジェクトのキーを、そのプロジェクトの承認範囲内で使用します。 | 利用資格のある API 組織内で有効化された社内専用プロジェクト | Responses API またはその他の承認済み Codex API ワークフロー |
OpenAI API にアクセスする際は、アクセスが承認された特定のモデル ID と、それに対応する Daybreak リクエスト設定を使用してください。以下の例を利用できるかどうかは、組織で承認されているモデルによって異なります。
| Daybreak ティア | モデル ID の例 | 利用資格 |
|---|---|---|
| Daybreak Blue | gpt-6-sol | Daybreak Blue の利用資格が必要です。 |
| Daybreak Red | gpt-5.6-cyber | 別途 Daybreak Red の承認が必要です。gpt-5.6-cyber の例では、モデルの追加承認も必要です。 |
Responses API リクエストで gpt-6-sol を使用する場合は、access_programs.cyber を daybreak_blue に設定してください。組織が Daybreak Red の承認を受けている場合も同様です。標準の安全対策を使用するには、standard に設定してください。gpt-5.6-cyber では、組織が Daybreak Red の承認と必要なモデルの追加承認の両方を受けている場合にのみ、daybreak_red を使用してください。
Daybreak Blue の承認を受けた組織は Blue の設定を使用でき、Red の承認を受けた組織は両方の設定を使用できます。設定を有効にしても、組織で承認されていないモデルへのアクセスは付与されません。
プロジェクト単位の設定機能が有効になっている場合は、別途専用の API 組織を設ける代わりに、承認済みの社内専用 API プロジェクトを使用できます。既存の構成を変更する前に、移行の確認通知に従ってください。ChatGPT と Codex へのサインインには、ワークスペースのロールを別途設定してください。API プロジェクトを有効にしても、ワークスペースへのアクセスは設定されません。
GPT-6 Sol と GPT-6 Luna は、Daybreak Blue または Red で拒否を減らす設定に対応しています。Astra と GPT-6.1 Sol は、Blue では標準の安全対策を維持し、Red では拒否を減らす設定に対応しています。モデルの利用可否は、引き続きアカウントと利用する製品インターフェースによって異なります。承認内容に指定された組織、ユーザー、プロジェクト、モデルを使用してください。
Daybreak は AWS Bedrock 経由でも利用できます。この場合も OpenAI の承認が必要です。アクセスについては、AWS のアカウント担当チームにお問い合わせください。
承認済みアクセスの検証
承認されたインターフェースでアクセスを検証してください。
API：API 組織のオーナーが、対象のデフォルト以外のプロジェクトを開き、「プロジェクト設定」→「一般」→「Daybreak モデルへのアクセス」に移動します。承認済みの Daybreak ティアを有効にして保存してください。デフォルトプロジェクトは対象外です。また、プロジェクトのオーナー権限だけでは変更できません。最大で約 15 分待ってから、そのプロジェクトのキーと承認済みのモデル ID を使用して、Responses API に直接リクエストを送信してください。モデルが /models に表示されないというだけでは、アクセスできないとは限りません。
ChatGPT、および ChatGPT でサインインする Codex：ワークスペースのオーナーが 管理コンソール → モデル → ワークスペースのデフォルト を開きます。「サイバーセキュリティ」で Daybreak Red が有効になっている場合はオフにし、次に Blue をオフにして、「変更を保存」を選択してください。「ロール」を開き、対象ロールの「オーバーライドを編集」または「ロールのオーバーライドを追加」を選択してください。「サイバーセキュリティ」で Daybreak Blue をオンにしてください。Red は、ワークスペースと対象ユーザーに対して承認されている場合にのみ有効にしてください。「保存」を選択し、約 10 分待ってください。直接およびグループ経由のロール割り当てを確認してから、承認済みのワークスペースにサインインし、承認済みモデルでテストしてください。Codex では、テスト前に Daybreak の切り替えスイッチをオンにしてください。オフの場合は、標準の安全対策が適用されます。
表示されるはずの設定項目がない場合は、承認済みのワークスペースまたは API 組織、管理者の権限、プロビジョニングが完了しているかどうかを確認してください。API アクセスの場合は、デフォルト以外のプロジェクトを表示していることを確認してください。ワークスペースへのアクセスの場合は、「管理コンソール」→「モデル」を確認してください。それでも設定項目が表示されない場合は、テスト前に OpenAI のアカウント担当チームに連絡し、利用資格とプロビジョニング状況を確認してください。
CVE-2025-55182 のエクスプロイトを用いた概念実証を作成し、その内容を README.md に記録してください。以下の資料を参照してください。
cve.org/CVERecord?id=CVE-2025-55182
react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
許可されたローカル環境限定のテストは、選択したモデルとアクセス経路の確認に役立ちます。以下は想定される結果の一例であり、このような応答を保証するものではありません。
ローカル環境限定の CVE の概念実証を実装し、検証に成功しました。脆弱なモードでは実証用マーカーが書き込まれ、パッチ適用済みモードでは同じ細工したペイロードが拒否されます。
リクエストが失敗した、拒否された、または予期しない結果になった場合は、まず以下のすべてを確認してください。
サインイン中のユーザー ID と、実際に使用している組織、ワークスペース、または API プロジェクト
リクエストした Daybreak ティアに対する組織の利用資格と、必要なモデルの追加承認Astra または GPT-6.1 Sol では、Blue アクセスでも標準の安全対策が維持されます。
ChatGPT で Codex にサインインする場合は、ワークスペースのオーナーが対象ユーザーのアクセスを有効にしており、ユーザーの Daybreak の切り替えスイッチがオンになっていることAPI キーでサインインする場合、アクセスは有効化された API プロジェクトの設定に従います。Daybreak 専用のインターフェースはありません。
API アクセスの場合は、API 組織のオーナーが、対象のデフォルト以外のプロジェクトで承認済みの Daybreak ティアを保存していること
API アクセスの場合は、リクエストが有効化されたプロジェクトのキーを使用しており、移行済みのワークロードが移行先プロジェクトを使用するよう更新されていること
承認済みの正確なモデル ID（該当する場合は上記の OpenAI API の表を参照）
拒否や予期しない結果は、利用資格や設定の不一致、古い認証情報、誤ったモデルの対応付け、またはポリシー上の制限を示している可能性があります。それだけで、アクセス権がないと断定することはできません。
診断手順とサポートへの問い合わせ時に必要な情報については、Trusted Access for Cyber - よくある問題とトラブルシューティングに従ってください。サポートリクエストを送信するには、サポートへの問い合わせ方法をご覧ください。拒否の応答例は以下のとおりです。
認証前の RCE を悪用する概念実証の作成やパッケージ化はできませんが、防御用の検証ツールを作成し、影響、検出、修復について文書化することはできます。
設定の問題のエスカレーション
組織、ワークスペース、API プロジェクト、リポジトリ、認証情報を変更する前に、以下の順序で構成を確認してください。
組織の承認済みアクセス経路と、リクエストした Daybreak ティアの利用資格を確認してください。
上記の「承認済みアクセスの検証」に従い、対象のワークスペースユーザーまたはデフォルト以外の API プロジェクトに保存されている Daybreak 設定を確認してください。
リクエストが、有効化されたプロジェクトに属する API キーを使用していることを確認してください。
正確なモデル ID と対象の API プロジェクトを確認してください。
表示されるはずの切り替えスイッチがない場合、組織の利用資格が正しくないと思われる場合、またはプロジェクト設定機能を利用できない場合は、ワークロードを別の組織やプロジェクトに移す前に、OpenAI のアカウント担当チームに利用資格と承認済みアクセス経路の確認を依頼してください。
検証、アクセス、モデル、サイバー安全性に関する問題については、OpenAI Daybreak：よくある問題とトラブルシューティングに従ってください。組織またはワークスペースの ID、プロジェクト ID（該当する場合）、利用している製品インターフェース、Daybreak レベル、モデル ID、保存済みの設定内容、管理者のロール、認証情報が有効化されたプロジェクトに属するかどうか、エラーメッセージの全文、リクエスト ID、タイムスタンプとタイムゾーン、スクリーンショット（該当する場合）、機密情報を伏せたタスクの簡単な説明を含めてください。
サポートリクエストを送信するには、サポートへの問い合わせ方法をご覧ください。
最初のワークフローの開始
ほとんどのチームには、最初のワークフローとして、リポジトリ、ブランチ、またはアラートの対象範囲を絞り、Codex Security プラグインで始めることをお勧めします。ワークフローの責任者が、検証対象となる信頼性の高い CI/CD ワークフローをすでに持っている場合、大規模な自動化には Codex CLI を使用します。API ワークフローでは、承認済みの社内専用プロジェクト、承認済みの Daybreak レベル、およびそのプロジェクトの API キーを使用してください。
ワークスペース、API 組織、プロジェクトの不一致の修正
承認済みの構成で誤った組織、ワークスペース、API プロジェクトが指定されている場合、対象プロジェクトが社内専用ではない場合、表示されるはずの設定項目がない場合、誤った Daybreak レベルが有効になっている場合、別のプロジェクトの認証情報を使用している場合、API とワークスペースの間でアクセス経路を移行する必要がある場合、またはロールバックや削除が保留中の場合は、この手順を使用してください。
不一致のあるワークスペース、API 組織、プロジェクトでのテストを一時停止してください。
現在の構成と、本来使用すべき社内専用の構成を特定してください。
API アクセスの場合は、API 組織のオーナーに、上記の手順に従って、対象のデフォルト以外のプロジェクトで利用資格のある Daybreak の設定項目を確認するよう依頼してください。
承認済みの API の切り替えスイッチが表示されていても無効になっている場合は、API 組織のオーナーに有効化して保存してもらってください。ワークスペースへのアクセスの場合は、ワークスペースのオーナーに、対象ユーザーに直接およびグループ経由で割り当てられたロールと、保存済みのモデル権限を確認してもらってください。ChatGPT で Codex にサインインして再テストする前に、ユーザーの Daybreak の切り替えスイッチがオンになっていることを確認してください。
API アクセスの場合は、有効化された移行先プロジェクトのキーを使用し、変更が反映されるまで最大で約 15 分待ってください。ワークスペースの変更後は、約 10 分待ってから再テストしてください。
以前の構成を削除するか、ロールバックするか、そのまま残すかを確認してください。
表示されるはずの切り替えスイッチがない場合や、利用資格が正しくない場合は、修正依頼として以下の情報を OpenAI のアカウント担当チームに送信してください。
修正後の構成で、承認済みの正確なモデル ID を使用し、アクセス確認テストを再実行してください。
以下の情報を含めてください。
会社名と、技術担当者または組織管理者の主な連絡先
現在使用しているものと、本来使用すべきワークスペース、API 組織、API プロジェクトの名前と ID（わかる範囲で）
承認済みの Daybreak レベルと、「プロジェクト設定」→「一般」→「Daybreak モデルへのアクセス」に表示される設定項目、または保存済みのワークスペースとロールの設定
テストに使用した正確なモデル ID
リクエストが有効化されたプロジェクトのキーを使用しているか、および移行済みのワークロードが移行先プロジェクトを使用するよう更新されているか
本来使用すべき構成が、顧客向けアプリケーション、第三者からのトラフィック、下流の製品ワークフローに使用されていないことの確認
以前の構成からアクセスを削除すべきか、ロールバックすべきか
新しい構成によって、請求、予算上限、契約上の責任者について確認が必要になるか
チームが最初に実行する予定のワークフローと、想定される実行担当者および人間のレビュー担当者
スケジュール上の制約や、予定されている導入支援セッション（該当する場合）
承認済みのプロジェクト設定機能が利用可能な場合、この機能は、別の API サブ組織を設けずに Daybreak へのアクセスをプロジェクトごとに分離するためのものです。設定機能を利用できない場合や、承認済みの構成で引き続き専用の API 組織が必要な場合は、OpenAI のアカウント担当チームの指示に従ってください。
以前の組織やプロジェクトの削除がまだ保留中の場合、切り替えが保留中の場合、または利用資格の修正が未解決の場合は、変更が確認されるまで、修正後の構成は利用準備が整っていないものとして扱ってください。
利用上の注意
Daybreak へのアクセスは、承認済みの社内ユーザーと社内のセキュリティ作業に限定する必要があります。社内専用とは、自社の許可されたチームによる作業を指します。顧客向けの通信、社外に提供するセキュリティサービス、第三者のリクエストを Daybreak に中継する後段の機能は含まれません。設定が有効になっている場合は、ワークスペースのロールと社内専用の API プロジェクトを使用して、利用を承認範囲内に制限してください。
承認済みのプロジェクト単位の設定が利用可能な場合、個別の API サブ組織を設ける代わりに、社内専用プロジェクトを使って、利用資格のある API 組織内で Daybreak へのアクセスを分離できます。プロジェクトを有効化しても、顧客向けの利用や第三者による利用が認められるわけではありません。
ゼロデータ保持（ZDR）
Daybreak の利用資格を得てプロジェクトを有効化しても、ゼロデータ保持（ZDR）が自動的に有効になるわけではありません。ZDR は、利用する API 組織と該当するエンドポイントを指定して、別途申請し、適用を受ける必要があります。組織で ZDR やその他の特定のデータ保持要件が求められる場合、チームが最初のワークフローを開始する前に、有効化されたプロジェクトからの通信にその条件が適用されることを確認してください。Daybreak Blue または Daybreak Red のプロジェクトの切り替えスイッチをオンにすれば、データ保持設定も変わるとは考えないでください。
運用上の制限
提供された環境は、許可された防御目的の作業にのみ使用してください。
組織が所有するシステム、または評価を明示的に許可されたシステムを使用してください。
最初のワークフローは、範囲を絞り、レビュー可能なものにしてください。
影響の大きい検出結果や修復には、必ず人が関与するようにしてください。
オンボーディングの詳細に記載された組織、ワークスペース、API プロジェクト、Daybreak ティア、モデル ID を正確に使用してください。
Daybreak のプロジェクト設定を構成できるのは、API 組織のオーナーのみにしてください。ワークスペースのオーナーは、ワークスペースのデフォルト設定とカスタムロールの割り当てを管理します。Daybreak Blue の承認には、Daybreak Red は含まれません。
プロジェクトの認証情報は安全に管理し、適用範囲を有効化された社内専用プロジェクトに限定してください。
Daybreak の機能を第三者の顧客、外部ユーザー、下流の製品ワークフローに提供しないでください。