OpenAIは2026年11月5日、セキュリティ研究向けモデル「GPT-6 Cyber」を発表しました。ソフトウェアの弱点である脆弱性を探し、実際に問題が起こるか検証し、修正案を作る作業を支援します。当初の提供先は、同社の審査を通ったDaybreak Red顧客の一部で、APIとCodexから利用する形です。OpenAIの発表
事業者が注目したいのは、AIの役割が「コードの怪しい箇所を指摘する」段階から、「影響を確かめ、修正まで進める」工程へ広がっていることです。自社の保守や診断で、見つかった問題を誰が検証し、誰が修正するかを考える材料になります。
画像はAIと人による調査・検証・修正の概念イラストです。製品の画面や性能を示すものではありません。
FirefoxやLinuxで何を確かめたのか
OpenAIは、Firefoxで新たに81件の高深刻度の脆弱性を見つけたと報告しています。これらの件数や性能評価は提供元による発表です。公式発表
Mozilla側も、Firefox 159で修正した問題をセキュリティ勧告として公表しています。ただし、修正一覧の全件を今回のモデルの成果と結び付けたり、81件すべてが同じ版で修正されたと解釈したりするのは適切ではありません。利用者は自分の製品・更新系統に対応する公式案内を確認してください。Mozillaの修正情報
Linuxの研究では、候補の発見から再現確認、影響評価、修正案の作成、人による確認までを一連の工程にしました。報告によると、1,724件の問題を再現し、948件について一般ユーザーが管理者権限を得られることを検証しています。これは「ローカル権限昇格」と呼ばれ、そのコンピューター上で動くプログラムなどが、許された範囲を超える権限を得る問題です。Linux研究の詳細
948件という数字は、遠隔から誰でも侵入できる件数や、すべてが新発見であることを意味しません。研究中にも別の貢献者による修正・報告が進んでいました。また、隔離した検証環境での結果なので、この数字だけで自社サーバーの該当や侵害を判断することはできません。研究方法と修正状況
「見つける」と「直ったと確認する」は別の作業
今回の研究を業務で考えるうえでは、AIの指摘件数より、その後の扱いが重要です。
たとえば「この処理から情報が漏れる可能性がある」という指摘が出ても、事業への影響を判断するには、次の確認が必要になります。
- 外部の利用者が、その処理に到達できるか。
- ログインや特別な権限など、問題が起きる条件は何か。
- 実際に漏れる情報や、停止する機能は何か。
- 修正後に問題が起きなくなり、通常の業務も動くか。
AIが修正案を出す場合も、担当者が内容を確認し、検証してから反映する工程が必要です。自社でAI診断を使う場合も、外部に依頼する場合も、「何件見つかったか」に加えて、再現条件・影響・修正後の確認結果が残るかを見ておくと、対応の優先順位を付けやすくなります。
一般のChatGPT契約ですぐ使えるわけではない
発表時点では利用対象が限られています。API利用では原則として接続元IPアドレスの許可リストが必要です。また、Zero Data Retentionを使うAPI顧客も、原則として顧客側ストレージに30日保存する暗号化記録を自動検査するPSPの対象になります。通常の保存設定が標準であり、利用を検討する場合はデータの扱いを個別に確認する必要があります。提供範囲と安全対策
「ログを残さない契約だから、コードや検証記録もどこにも残らない」とは判断できません。自社・顧客のコードや情報を使う前に、利用できる契約、入力してよい情報、保存場所、アクセスできる人を確認しましょう。この記事では個別契約の可否や価格までは確認していません。
自社の保守で今確認したいこと
モデルの利用を待つ間にも、既存の保守体制は点検できます。
- 更新対象と担当者を明確にする。 Webアプリだけでなく、サーバーのOSや実行環境、共通部品を誰が更新するか確認します。
- 検証できる場所を用意する。 実際の顧客データや本番の認証情報を持ち込まず、許可した対象だけを調べられるようにします。
- 指摘から修正まで追えるようにする。 影響条件、優先度、担当者、修正後の確認を一緒に管理します。
AIによる調査を取り入れるなら、まずは対象を一つに絞り、担当者が結果を確認できる範囲で試すのが現実的です。調査の速さだけでなく、修正につながったか、確認の負担が減ったかを評価すると、導入の効果を判断しやすくなります。
更新範囲の考え方は、Node.jsと共通部品の更新に関する解説、検証環境の管理は、開発環境と本番環境を分ける理由でも整理しています。
情報確認日：2026年11月7日。提供範囲・利用条件は変更される場合があります。