Codex Security ── 脆弱性発見から修正PRまで、人間の承認はどこで挟まるか

OpenAIの「Codex Security」は、リポジトリの脆弱性を見つけ、サンドボックス内で再現を試み、パッチを提案するところまでを一気通貫でやるセキュリティエージェントだ。公式ドキュメントを2026年8月27日時点で確認したところ、範囲は「脆弱性を見つける・確かめる・直す」の3語(find, confirm, fix)で説明されており、パッチの自動適用は明確に否定されている。「自動でセキュリティが直る」というのは正確な理解ではなく、実際には「人が最終確認して初めて閉じられる」設計になっている。この記事では、公式ドキュメントの原文で確認できた仕様と、CLI/CIで実際に運用する際に引っかかりやすい点を整理する。

3行まとめ

1. Codex Securityは「脅威モデル構築→コミットスキャン→サンドボックス内検証→パッチ提案」の4段パイプラインで動き、公式FAQは「Codex Security does not auto-apply changes to the repository」と明記している
2. GitHub PRに差し込む「Codex Security Review」はResearch Preview機能で、ChatGPT Plusでは使えずEnterprise/Business/Edu/Proのみ対応。導入時の初期設定と閾値の選び方を間違えると、脆弱性の詳細が公開リポジトリのPRコメントとしてそのまま公開される
3. CLI/CIでは認証の優先順位・終了コード・コスト上限がそれぞれ独特の挙動を持ち、公式ドキュメントは「見積もりであってハード上限ではない」「終了コード2はseverityポリシーがなくても返る」と注意書きしている

三段+αのパイプライン ── 「見つける」「確かめる」「直す」を分けている理由

Codex Security cloud FAQは、分析パイプラインを次の4段階として説明している。

"1. Analysis builds a threat model for the repository. 2. Commit scanning reviews merged commits and repository history for likely issues. 3. Validation tries to reproduce likely vulnerabilities in a sandbox to reduce false positives. 4. Patching integrates with Codex to propose patches that reviewers can inspect before opening a PR."

まず対象リポジトリの「脅威モデル」(エントリポイント、信頼境界、認証前提、リスクの高いコンポーネントをまとめた要約)を自動生成し、それを文脈にしてコミット履歴をスキャン、疑わしい脆弱性が見つかったら隔離されたコンテナ内で実際に再現を試みる。この「サンドボックスで再現できたものだけをvalidatedとする」という2段構えが、公式が謳う誤検知削減の仕組みだ。FAQは「How does Codex Security reduce false positives」の項で、モデルがまず疑わしい問題をランク付けし、次にクリーンなコンテナで再現を試み、再現に成功したものだけをvalidatedとマークする、と説明している。

パッチ生成についても明確な線引きがある。「Does Codex Security auto-apply patches?」への回答は次の通りだ。

"No. The proposed patch is a recommended remediation. Users can review it and push it as a PR to GitHub from the findings UI, but Codex Security does not auto-apply changes to the repository."

修正フローの文書(Fix and verify security findings)でも、検証が完了しても「finding」は自動でクローズされないと重ねて書かれている。

"Verification doesn't automatically close a finding. Review the commands, results, and remaining proof gap, then close the finding with an accurate reason or keep it open for more work."

修正パッチには可能な限り「fixの前は失敗し、fixの後は通る」回帰テストを添える設計だが、そのテストが安全に書けない・現実的でないケースでは、テストの代わりに「proof gap(証明できなかった範囲)」を記録し、代替の検証証跡を残すとされている。つまり「テストで守られていない部分がある」ということ自体を、隠さず記録として残す仕組みだ。

GitHub PRに刺さる二つの経路 ── ローカルdiffスキャンと「Codex Security Review」は別物

Codex SecurityがGitHub PRに関わる経路は、公式ドキュメント上で少なくとも2つに分かれている。混同すると設計の意図を読み違えるので分けて書く。

一つ目は「Review code changes」($codex-security:security-diff-scan)。これはCLIやCodexの会話から、未コミットの変更・単一コミット・base/headの差分を指定してレビューする、ローカル/CI実行のワークフローだ。「Codex reviews each changed source-like file and its directly supporting code. It doesn't expand the review into a full repository audit.」と説明されており、リポジトリ全体監査には広がらないスコープ限定型である。

二つ目は「Codex Security Review」。こちらはCodex cloudに接続したGitHubリポジトリ向けの自動レビュー機能で、公式ページはResearch Preview段階だと明記した上で、対象プランを次のように限定している。

"It is available to ChatGPT Enterprise, Business, Edu, and Pro customers; it is not available on Plus."

起動方法は2通りで、リポジトリ設定で「PR作成時」「pushのたび」「Code Review実行時に同時実行」のいずれかを選んで自動化するか、PRコメントに @codex security review と書いて手動で呼び出す。報告される重大度の閾値もデフォルトが決まっている。

"By default, automatic Codex Security Reviews report High and Critical findings, while manually requested reviews report Medium, High, and Critical findings."

ここで実務上とても重要な一文がある。

"Findings posted to a pull request inherit that pull request's GitHub visibility. Anyone who can view the pull request can view those findings, including on public repositories or pull requests from contributors outside your workspace."

つまり、公開リポジトリのPRで自動レビューを有効にすると、見つかった脆弱性の内容(攻撃経路や再現条件を含む)がそのままPRコメントとして誰でも読める場所に出る。OSSやパブリックリポジトリで導入する場合は、閾値をむやみに下げず、報告対象の範囲を事前に決めておく必要がある。なお「Code Review」機能(通常のPRレビュー)もセキュリティ系の指摘を出すことがあり、公式は「occasional overlap between findings」があり得るとも書いている。

CLIとCIで踏みやすい落とし穴 ── 認証の優先順位、終了コード、コストは「上限保証ではない」

CLI(@openai/codex-securityパッケージ)をCIに組み込む際、公式ドキュメントが明示的に注意を促している点がいくつかある。

認証の優先順位が直感に反する。CLI FAQには「Why does a scan use an API key after sign-in」という項目があり、環境変数にOPENAI_API_KEYまたはCODEX_API_KEYが設定されていると、非対話実行やJSON/JSONL出力のスキャンはChatGPTへのログインが成功していてもAPIキーの方を優先して使う、と書かれている。ChatGPT側の保存済み認証を使いたいなら--auth chatgptを明示する必要がある。

終了コードは「エラー」だけを示すわけではない。CLI FAQは「Scans with partial or unknown coverage return exit code 2, even without a severity policy.」と明記している。つまりseverityの閾値を超える問題を見つけていなくても、スキャン範囲が不完全(coverageがpartialまたはunknown)なら終了コード2が返る。CIのゲートを「exit code 1だけ見て落とす」設計にしていると、カバレッジ不足を静かに見逃す。

コスト上限・時間上限は"見積もり"であってハード制限ではない。--max-costについて公式は「The limit is an estimate, not a hard spending cap. Requests already in progress can finish above it.」と書いている。deep scanの--max-time-hoursもデフォルトは96時間で、期限に達すると未完了のワーカーは打ち切られるが、完了済みの標準スキャン結果は集約されて最終レポートに残る。予算・時間の上限は「そこで即座に止まる保証」ではなく「そこを境に段階的に打ち切る目安」だと理解しておく必要がある。

ローカルスキャンは承認を挟まず、環境変数をそのまま引き継ぐ。CLIクイックスタートは「Scans use your local operating-system permissions and don't pause for approval. Scan processes can inherit your environment, so remove unrelated credentials before you start.」と注意している。CIランナーで動かす場合も、スキャン用のAPIキー以外の無関係なトークンや認証情報をジョブ環境から極力外しておくべきだとCI向けガイドは重ねて書いている。

再スキャンの非決定性。「Why can repeat scans return different findings」という項目があり、「AI-assisted scans can vary, even with the same scan configuration.」と明記されている。同じ設定で再実行しても検出結果が変わり得るため、「前回見つかった問題が今回出てこない」ことは修正の証明にならない。公式は、修正確認のためにはscans compareで対象範囲のカバレッジが欠けていないことを確かめた上で、validateコマンドで該当箇所を個別に再チェックするよう案内している。

誤検知(false positive)の申告は、そのルール自体を消さない。CLIで理由を添えて誤検知登録しても、「A dismissal doesn't suppress a rule, path, or vulnerability class.」とあり、以後のスキャンはその説明を文脈として使いつつ、現在のソースを独立に再チェックする。同じ指摘が形を変えて再浮上する可能性は残る。

公式ドキュメントに記載を見つけられなかったこと

今回確認できたページの範囲では、以下は記載を見つけられなかった。推測で埋めずに明記しておく。

• Codex Security cloud/CLIのスキャン自体の具体的な料金体系(1スキャンあたりの費用感やクレジット消費量)。「Codex Security Review」(PR向け機能)については「導入期間中はChatGPTクレジットを消費しない」との記述があったが、これはPRレビュー機能限定の記述であり、cloudスキャンやCLIスキャン全般の課金体系は確認できなかった。
• 対応言語の具体的な一覧やベンチマークスコア。FAQは「language-agnostic」で「performance depends on the model's reasoning ability for the language and framework」とだけ述べており、言語別の精度データは見つけられなかった。
• フルリポジトリスキャンに必要とされる「Trusted Access for Cyber」の認証要件・審査基準・所要期間。
• 「Codex Security cloud」「Codex Security Review」がResearch Previewを終えて一般提供になる時期・条件。
• Security Review(PR向け自動レビュー)が内部で使用するモデル名。ローカルスキャンについては「For the best scan quality, use gpt-5.6-sol with xhigh reasoning effort」という推奨記載があったが、これがクラウド側のSecurity Reviewにもそのまま適用されるかは明記されていなかった。

社内のOSS支援プログラム「Patch the Planet」でこのCodex Securityが実際に使われた事例(19プロジェクト・64件のPR提出・37件マージという自社発表の実績)は別記事OpenAI「Patch the Planet」始動で扱っている。エージェント実行の基盤(ハーネス)そのものの仕組みはOpenAIがCodexの実行の仕組みを丸ごと公開を参照してほしい。