GPT-6 Cyberを読む：評価値の意味と修正を検証する仕組み

OpenAIは2026年11月5日にGPT-6 Cyberを発表した。当初の対象は一部のDaybreak Red顧客で、APIとCodexから提供される。現場で問われるのは、発見を誰が検証し、修正をいつ利用者に届けるかだ。

公開されたものと利用条件

システムカードでは、許可されたセキュリティ業務に特化したGPT-6 Astraの派生モデルと説明されている。利用は制限される。発表されたからといって通常のAPIアカウントで使えるとは限らず、本稿でも推測のモデルIDやSDK呼び出しは掲載しない。

評価値の読み方

ExploitGymは32.1%から48.5%に上昇した。差は16.4ポイント、相対的な増加率は約51.1%だ。指定された脆弱性の悪用と、未知の欠陥の発見は別の課題である。

ソースコードを使わないWeb評価では再現率40.3%、Astraは32.0%と報告された。再現率だけでは誤検知による負荷は分からない。対象の分布、ツールの予算、再試行、人の介入、採用された発見あたりの費用を確認したい。本站はベンダーの評価を独立に再現していない。

LinuxとFirefoxの証拠を追う

Linuxの研究報告は、候補2,308件、動的に再現した脆弱性1,724件、動作するローカル権限昇格の実証948件を区別している。疑わしいコードと実際の権限境界突破は証拠の強さが違う。ローカル権限昇格は事前のローカルアクセスを前提とし、遠隔コード実行とは異なる。

この実行で使われたAPIクレジットは1,213,430米ドル、動作する権限昇格実証あたり約1,279米ドルだった。製品価格や人件費込みの総費用ではない。Firefoxのアドバイザリではコンポーネント、重大度、報告者、個別の問題を確認できる。日付は10月27日で、モデル発表より前だ。発見、開示、修正、発表を同じ出来事として扱ってはいけない。

モデルの回答から修正へ

以下は筆者が提案する工程で、OpenAI公式の構成図ではない。まずリビジョンと環境を固定する。モデルが仮説やパッチを出し、別の実行基盤が再現と修正の検証を担当する。

入力、ログ、コマンド、差分を残す。同じ再現ケースが修正前には失敗し、修正後には成功することを確認し、近接する正常動作も回帰テストする。機能を無効にしただけでもクラッシュは消えるため、それだけでは修正と認められない。

実行できる証拠チェック

次のコードをevidence-gate.tsとして保存し、bun run evidence-gate.tsで実行する。ネットワークやGPT-6 Cyberには接続しない。コミット、環境、修正前後の結果を持つローカル記録を検査する。

type Finding = {
  id: string;
  commit: string;
  environment: string;
  before: number;
  after: number;
  regression: number;
  reviewer: string | null;
};

function readyForReview(f: Finding): boolean {
  return (
    /^[a-f0-9]{40}$/.test(f.commit) &&
    f.environment.trim().length > 0 &&
    f.before !== 0 &&
    f.after === 0 &&
    f.regression === 0
  );
}

const finding: Finding = {
  id: "LAB-001",
  commit: "a".repeat(40),
  environment: "isolated-vm / fixture-v1",
  before: 1,
  after: 0,
  regression: 0,
  reviewer: null,
};

if (!readyForReview(finding)) {
  throw new Error("Evidence incomplete");
}
console.log(
  JSON.stringify({
    id: finding.id,
    readyForReview: true,
    approved: finding.reviewer !== null,
  }),
);

出力はreadyForReview: trueとapproved: falseになる。終了コードは信頼できる実行基盤から受け取る必要がある。この検査は悪用可能性、パッチの正しさ、審査者の本人性を証明しない。認証された承認と変更不能な証拠が別途必要で、架空のコミットも実際の検証対象に置き換える。

境界は実行層で強制する

発表の範囲遵守評価は、配備用プロンプトなしで99.93%、ありで100%だった。特定の試験結果であり、将来の全操作への保証ではない。システムカードはサイバー能力をCriticalと分類する。

対象の許可、通信先、認証情報はモデルの外で制御する。実行予算と破棄可能な環境を用意する。リポジトリや外部ページにある指示は分析対象のデータであり、権限を追加するものではない。

試験導入で測るもの

自分たちのリポジトリを使い、同じリビジョンと予算で従来のレビューと比べる。重複を除いた採用件数、再現性、レビュー時間、パッチの採用率、配備までの日数を測る。重複した警告も人の時間を使う。

到達不能な疑わしいコード、修正済みの問題、クラッシュを隠すだけのパッチ、許可外の対象も試す。証拠が不足すれば不確実性を残して停止すべきだ。筆者は、報告数よりも再現可能な発見から修正配備までの時間を重視する。

参考資料

執筆と翻訳にはAIの支援を使用した。出典の事実、実行例、筆者の提案を区別している。