Codex Security CLIが登場。脆弱性を見つけて、直ったかまで確認する方法

2026年7月29日更新日: 2026年7月29日AIコラム

OpenAIが、コードの脆弱性を探し、見つかった問題を検証し、修正できたかまで確かめる「Codex Security CLI」を公開しました。Codexの画面で行うセキュリティスキャンに加えて、ターミナルからリポジトリを調べたり、過去のスキャン結果を比較したり、CI/CDに組み込んだりできます。

この記事では、Codex Security CLIが普通のコードレビューと何が違うのか、手元のリポジトリで試す手順、見つかった問題を直すときの注意点を、AIじてんの制作環境に当てはめながら整理します。情報は2026年7月29日時点のものです。

今回の発表はこちらです

今回の発表は、CodexチームのTibo氏とOpenAI公式アカウントから案内されました。

Codex Security CLIは、脆弱性を見つけて終わらない

セキュリティチェックと聞くと、危険そうなコードを機械的に指摘するツールを想像しがちです。Codex Securityは、リポジトリのコードを読み、脆弱性として報告する価値があるかを確認し、根拠と修正方針をまとめるところまでを一つの流れとして扱います。

OpenAIの説明では、スキャン結果には問題が起きる条件を示す証拠や、再現できる場合の手順、修正の方向性が含まれます。単に「この行が危険です」と言われるより、どの入力がどこへ流れ、なぜ悪用できるのかを追いやすいのが特徴です。

さらに、修正パッチを作った後に、同じ問題が再現しなくなったかを検証できます。見つける・直す・直ったかを確かめる、という作業を分けずに追えるわけです。

Codex CLIから使う基本手順

CLIとSDKはベータ版で、利用にはアクセス権が必要です。アクセスがある場合は、OpenAIが案内するインストール方法に従ってセットアップします。CLIの実行にはNode.js 22以降、スキャンや結果の書き出しにはPython 3.10以降が必要です。

スキャン対象のリポジトリと、結果を保存する非公開ディレクトリを用意する
npx codex-security --version と npx codex-security --help で動作を確認する
npx codex-security login でChatGPTアカウントにログインする（CIなどの自動実行ではAPIキーを利用）
npx codex-security scan /path/to/repository --output-dir /path/to/results を実行する
完了後に report.md と構造化された結果を確認する

いきなり本番リポジトリで実行するのではなく、まずは --dry-run で対象と出力先を確認できます。結果にはソースコードの抜粋や脆弱性の詳しい情報が含まれることがあるため、出力先はGit管理外の安全な場所にし、保存期間も決めておくのがおすすめです。

Codex SecurityのプラグインをCodex CLIから使う場合は、codexでリポジトリを開き、/pluginsからCodex Securityをインストールして、新しいチャットを開始します。そのうえで次のように依頼します。

Run a Codex Security scan on this repository.

公式ドキュメントでは、スキャン品質を重視する場合は gpt-5.6-sol と xhigh 推論の組み合わせが案内されています。利用できるモデルやアクセス条件はアカウントによって異なるため、実際の画面に表示される選択肢を確認してください。

結果はreport.mdから読み、finding単位で判断する

出力先には、まず人間が読むための report.md が作られます。加えて、深刻度・確信度・該当箇所・根拠・修正案を持つ findings.json、調査した範囲や保留した範囲を記録する coverage.json などが保存されます。

ここで大切なのは、件数だけを見て「問題なし」と判断しないことです。カバレッジが partial や unknown になっていないか、調査されなかった範囲や未解決の問いがないかを確認します。スキャンが完了していても、リポジトリ全体を同じ深さで調べられたとは限りません。

修正は差分を確認してから。検証で安心材料を増やす

問題が見つかったら、いきなり自動適用するのではなく、findingを一件ずつ受け入れ、提案された差分を確認します。Codex Securityには、脆弱性が再現しなくなったかを検証する流れも用意されています。

修正後の検証では、再現手順をもう一度実行したり、修正前には失敗して修正後には通る回帰テストを追加したりします。安全にテストできない場合は、検証できなかった理由と、代わりに行った確認方法が記録されます。検証が終わってもfindingが自動で閉じるわけではないため、差分とテスト結果を人間が見てからクローズします。

スキャンと修正は分けて運用するのが安全です。調査だけのスキャンではチェックアウトを変更しないように依頼し、修正は作業ブランチで行います。CIから修正を任せる場合も、findingごとに独立したタスクに分け、レビューを通してからマージします。

通常のコードレビューやClaude Securityとの違い

Codexの通常のコードレビュー（たとえば作業中の差分を対象にした /review）は、変更内容のバグや設計上の気になる点を短時間で確認する用途に向いています。一方、Codex Security CLIは、リポジトリ全体や指定したパスを対象に、脆弱性の可能性を検証し、証拠・カバレッジ・修正後の確認まで残すための道具です。

Claude Securityも、コードの脆弱性を探して根拠を確認し、修正を支援するという近い目的を持っています。ただし、対応する環境や出力形式、利用できるモデル、導入条件は異なります。すでにClaude Codeを中心に運用しているならClaude Security、Codex CLIとGitHubの流れを使っているならCodex Security CLIというように、普段の開発環境に合わせて選ぶのが現実的です。両方を同じリポジトリで試す場合は、結果の重複や異なる判定を比較し、最終判断は人間が行います。

AIじてんの制作環境で導入するなら

AIじてんでは、WordPressテーマや自作プラグインをローカルで編集し、Gitで変更を管理しています。この構成なら、公開前の大きな改修や、認証・ファイル操作・外部APIを追加したタイミングでCodex Security CLIを試す価値があります。

最初は公開前のブランチで通常スキャンを実行し、report.mdとカバレッジを確認します。問題が見つかったら、修正ブランチで差分をレビューし、検証が通ったものだけをマージします。WordPressの本番環境や、秘密情報が入った wp-config.php、APIキーを含むファイルをそのまま対象にするのは避け、必要なら秘密情報を除いた作業用コピーを用意します。

毎回フルスキャンを行う必要はありません。リリース前はリポジトリ全体、普段の変更では --diff origin/main --head HEAD や --working-tree --base HEAD のような差分スキャン、という使い分けができます。コミット前にチェックしたい場合は、公式CLIの install-hook でGitフックを追加する方法もあります。