自社コードのセキュリティ点検にAIを使いたい開発者・運用担当者に向け、Daybreak Blueの申請から利用準備までを日本語で整理します。申請すること、承認されること、使う環境で有効になることを分けて確認するのがポイントです。

Daybreak Blueは何を申請するものか

Daybreak Blueは、OpenAIのTrusted Access for Cyberによる承認制アクセスです。防御目的のコードレビューや修正検証などに利用します。資格や第三者認証ではありません。

申請時には、対象システム、行いたい作業、利用する組織・環境を整理します。扱うのは、自分が所有する、又は明示的な許可を受けた対象です。

基本となる公式案内：Models and Trusted Access

1　個人と組織の申請経路を選ぶ

利用の形申請の入口準備すること
個人として申し込む個人向けTrusted Accessの申請画面使うアカウントと自分の利用目的を確認する
組織として申し込む企業向けTrusted Access申請フォーム組織の窓口と利用予定の環境を整理する

個人の入口はchatgpt.com/cyberです。組織の入口は、公式案内のTrusted Access for Cyber節から企業向け申請フォームへ進めます。

個人向けの入口には、次の3項目が表示されます。各項目の案内に沿って準備を進めます。

  1. 高度なアカウントセキュリティに登録：使用するアカウントのサインインと復旧方法の条件を確認します。
  2. 本人確認：申請画面で案内された確認手続きを行います。
  3. Daybreak用のキーをセットアップ：画面の条件に合うハードウェアセキュリティキーを準備し、指定します。

執筆時に確認したアカウントでは、「準備が完了しました」と、認証済みハードウェアセキュリティキーを使う案内が表示されていました。個人と組織の条件を混ぜず、ご自身の画面に表示される要件を確認してください。

体験談：本人確認とYubiKeyの設定はどうだったか

当社で個人向けBlueを申請した際、eKYC（オンライン本人確認）の画面で選べた書類は、運転免許証かパスポートの2種類でした。これは申請当時の選択肢です。現在利用できる書類は、ご自身の申請画面で確認してください。

ハードウェアセキュリティキーは、ヨドバシでYubiKeyを購入しました。設定は、端末にキーを挿し、画面の簡単なウィザードに沿って進めるだけで完了しました。実際に行った担当者の感想として、設定の難しさはほとんど感じませんでした。

担当者のこれまでの利用では、初回設定後にYubiKeyを再び操作する場面はありませんでした。ただし、今後も不要という意味ではありません。執筆時の画面には認証済みハードウェアセキュリティキーを使う案内があり、再認証を求められた場合はその案内に従います。

2　利用目的を具体的に書けるようにする

何を安全にしたいのかと、どこまでをAIに任せるのかを整理しておくと、申請後の運用にも使えます。対象、目的、許可範囲、確認方法を短くまとめます。

架空の自社システムでの整理例

  • 対象：自社が管理する業務アプリケーションのコード。
  • 目的：認証・権限の境界を点検し、修正が有効かを確認する。
  • 範囲：ローカルのコードと架空データの試験。顧客環境には接続しない。
  • 進め方：人が指摘を検収し、通常の回帰試験で修正前後の挙動を確かめる。攻撃の再現・exploit検証は、別途承認された範囲で扱う。

これは当社が作成した整理例であり、承認を保証する申請文ではありません。秘密情報や顧客の文書を説明のために貼り付ける必要はありません。

3　承認された範囲を確認する

申請・確認手続きの後は、承認の連絡と対象範囲を確認します。Blueの承認がRedの利用を含むわけではありません。使う人、組織、環境、利用方法を承認内容と合わせます。

記録は「申請」「確認手続き」「承認」「環境の有効化」「実際の利用」に分けると、どこまで終わったかが分かりやすくなります。

体験談：抜けの調査は進められたが、攻撃の再現には境界があった

当社では、Blueの承認・有効化後、自社コードの認可の抜けを調べる作業は進められました。一方、攻撃の再現まで進めようとすると、Redの別途承認が必要という案内を受けました。調査ができることと、攻撃を再現する利用範囲は分けて考える必要があると実感しました。

公式の区分でも、Blueは脆弱性の発見、コードレビュー、修正・パッチ検証などを対象とし、Redは管理された環境での脆弱性再現やPoC・exploit検証などを対象としています。Blueの承認だけでRedは利用できず、別途承認と利用設定が必要です。通常の回帰試験と攻撃の再現を一括りにせず、作業内容に応じた利用範囲を確認します。詳しくは公式のモデル区分を参照してください。

4　実際に使う環境の設定を確かめる

アプリでの利用とAPIでの利用は、設定する場所や利用経路が異なります。承認された環境で、必要な設定が有効かを確認してください。

ChatGPTデスクトップアプリでは /model でDaybreakの対象モデルを選ぶ

当社で使ったアプリでは、/modelからDaybreakの対象モデルを選び、明示的に切り替えて使いました。申請・承認・初期設定が終わったら、作業を始める会話でもモデル選択を確認することが大切です。表示されるモデルはアカウントや承認範囲によって異なります。

  1. 利用する会話で/modelを開く。
  2. 承認されたDaybreakの対象モデルを選択する。
  3. 選択後のモデル表示と、作業に使う権限設定を確認してから点検を始める。

公式の推奨構成にも、デスクトップアプリでの/modelによるDaybreakモデル選択が記載されています。アカウントと組織の条件を満たす場合、権限モードは「Approve for me」に切り替わります。そのモードを利用できない場合は、現在の権限モードが維持されます。モデルの選択と実行権限はそれぞれ確認してください。

APIでは組織・プロジェクトとリクエストを確認する

APIでは、組織・プロジェクトでプログラムとモデルの利用権限を確認し、そのプロジェクトのキーを使います。リクエストの指定だけで権限が付与されることはありません。

API側の指定と確認方法は、Use Daybreak in the Responses APIを参照してください。モデル別の挙動は現行の対応表で確認します。

当社での利用例 コードの点検から修正確認へ

当社では、Blueの承認と有効化の確認を受けた後、自社コードの認可境界の点検を再試行した記録があります。作業では、指摘をそのまま採用せず、対象コードと架空データの試験を突き合わせ、修正の要否を判断しました。

当時は、個別のリクエストへDaybreakの処理が適用されたことを示すmetadataまでは独立確認できていません。したがって、点検が進んだ事実と、Daybreakが適用されたことの技術的な証明を分けて扱っています。

  • 対象と禁止する操作を決める。
  • 指摘された問題が成立する条件をコードで確認する。
  • 架空データを用いた通常の回帰試験で、修正前後の挙動を確認する。
  • 実装、試験、反映後の確認をそれぞれ記録する。

ここで紹介したコード点検は、独立した第三者診断の代わりになるものではありません。調達や契約で求められる確認は、対象範囲と提出する証跡を別途整理します。

申請と、日々の改善をつなげる

利用を始めた後は、対象を限定した点検で作業の流れを確かめ、指摘の妥当性と修正後の状態を人が確認します。申請や承認は、その運用を始めるための一段階です。

当社の対策と継続改善については、SP-FAXのセキュリティ対策の歩みとセキュリティと信頼性にまとめています。