Codex Security CLIとは｜脆弱性スキャンの使い方

「AIに書かせたコードに、脆弱性は残っていないのか」——AIコーディングの速度に慣れるほど、誰もがこの不安を抱えます。

結論から言うと、Codex Security CLIを使えば、AIが書いたコードの脆弱性をコマンド1つでスキャンし、CI（変更のたびに自動でテストを走らせる仕組み）に「重大な問題が見つかったら止める関所」を組み込めます。ただし、検査ごとAIに丸投げするのは危険です。

株式会社Fyveは、無人でAIにコードを書かせる運用を日々続けています。私たちはその視点から、Codex Security CLIの使い方と、丸投げが事故につながる理由を実務目線で解説します。

Codex Security CLIとは

Codex Security CLIは、OpenAIが2026年7月29日にオープンソースとして公開した、コードの脆弱性を見つけ・検証し・修正するためのコマンドラインツールです。npmパッケージ @openai/codex-security として配布され、ライセンスは Apache-2.0、公開時点のバージョンは v0.1.1 です。

特徴は、従来の静的解析ツールのようなパターン照合だけに頼らず、AIモデルがコードの文脈を読んで脆弱性を判断する点にあります。リポジトリ全体のスキャン、変更差分（プルリクエスト）のレビュー、スキャン結果どうしの比較、そしてCIへの組み込みまでを、1つのツールでまかなえます。

OpenAIは公式Xで「これは early release（早期リリース）であり、フィードバックを受けながら改善を続けている」と明言しています。研究プレビューは2026年3月に始まり、今回のオープンソース公開に至りました。まだ発展途上のツールだという前提は、最初に押さえておくべきポイントです。

Codex Security CLIで何ができるのか

できることは大きく4つあります。いずれも「AIが書いたコードの脆弱性を、開発の流れのどこかで検問する」ための機能です。

• リポジトリ全体のスキャン：scan でコードベース全体を検査し、脆弱性を洗い出す
• 差分・プルリクエストのレビュー：変更した部分だけを対象に、コミット前・マージ前にチェックする
• スキャン結果の比較：scans compare で前回と今回を照合し、新規・継続・解消された脆弱性を根本原因ごとに突き合わせる
• CIへの組み込み：機械可読な構造化データを返すため、CIパイプラインに検査を自動で挟める

実務では、差分レビューと全体スキャンを使い分けられるのが効きます。日々の変更は差分レビューで軽く確認し、リリース前や月次の節目にはリポジトリ全体を深くスキャンする——この二段構えが組めると、検査コストと網羅性のバランスが取りやすくなります。

この記事を読んでいるあなたへ無料プレゼントCodexを使い始める前に、「絶対に」見直してほしい5つのこと学習の設定・確認なしの操作・戻せる状態など。Codexにそのまま貼れる頼み方つき（全9ページ）

仕事の画面や資料を、AIの学習に使わせない設定取り返しのつかない操作が確認なしになっていないか、Codexに調べさせる頼み方AGENTS.mdのいちばん上に書く「絶対にしないこと」の例

無料でダウンロード

中身のプレビューを見る ↓登録すると、過去の特典もまとめて受け取れます（PDF 19点・合計499ページ ＋ すぐ使えるzip素材 3点）

使い方：導入からスキャンまで3ステップ

1. インストール

npmで導入します。動作には Node.js 22.13.0 以降と Python 3.10 以降が必要です。

• npm install @openai/codex-security

すぐ試すだけなら、インストールせずに npx @openai/codex-security@latest --help でヘルプを見るところから始められます。

2. 認証

ChatGPTアカウントでサインインするか、CIなどの自動環境では環境変数でAPIキーを渡します。

• 対話的に使う場合：npx @openai/codex-security login
• 自動環境の場合：環境変数 OPENAI_API_KEY（または CODEX_API_KEY）を設定

環境変数で渡したAPIキーは、その場のスキャンにだけ使われ、認証情報として端末に保存されません。CIで使うときはこちらの方式が推奨されています。基本的な利用にChatGPT Plusの契約は不要ですが、本格的なスキャンにはOpenAI APIキーを使うのが確実です。

3. スキャン

対象ディレクトリを指定して実行します。

• npx @openai/codex-security scan .

より深く検査したいときは、モードや並列数を指定できます。たとえば --mode deep で検査を深く、--workers で並列度を、--effort high で分析の強度を上げられます。まずは既定のまま小さく試し、必要に応じてオプションを足すのがおすすめです。

CIに「重大度の関所」を組む

Codex Security CLIの真価は、単発のスキャンよりもCIに検査を常設できることにあります。プルリクエストが作られるたびに差分をスキャンし、構造化された出力を受け取って、重大度が一定のしきい値を超えていればビルドを失敗させる——この「関所」を1本挟むだけで、脆弱性を含んだコードがマージされる前に止まります。

ポイントは、検査を人の記憶や善意に頼らず、パイプラインの仕組みとして強制することです。人は忙しいと確認を飛ばしますが、CIの関所は飛ばせません。「あとで見ておく」がいつまでも実行されない問題を、仕組みで解消できます。

AIの安全運用という観点では、実行前に承認を挟むモードやサンドボックスの設計も併せて考える価値があります。関所は1種類でなく、いくつかの層で組み合わせるほど堅くなります。

CodexCodexの承認モードとサンドボックス｜安全運用

便利だが「丸投げ」は危険な3つの理由

ここまで読むと万能に見えますが、私たちは3つの理由から、このツールにすべてを委ねることを勧めません。

1. まだ早期リリースである

公開時点は v0.1.1、OpenAI自らが「early release」と表現する段階です。検出漏れも誤検知もある前提で、結果を鵜呑みにしないことが大切です。「見つからなかった＝安全」ではありません。

2. 新しい魔法ではない

AIが文脈を読む点は新しいものの、やっていることは「コードの脆弱性を探す」という既存のセキュリティスキャナの延長線上です。これを入れれば従来の対策やレビューが不要になる、という話ではありません。既存の仕組みに1枚重ねる層として捉えるのが正しい位置づけです。

3. AIの穴をAIで塞ぐほど、人の目が要る

AIが書いたコードを、AIが検査し、AIが修正案を出す——この輪を速く回すほど、どこかで人が最終確認しないと、AIの思い込みがそのまま本番へ流れます。取りこぼしを嫌うなら、最後の1手は人が押すべきです。自動化は「人を外すこと」ではなく「人が確認すべき点だけに集中できるようにすること」だと考えています。

コードレビュー自体を自動化する発想については、こちらの記事でも掘り下げています。

CodexCodexでコードレビューを自動化｜PR前チェックの実務

「仕組みで検問＋人が最後に確認」という設計

私たちが無人でAIにコードを書かせる運用で徹底しているのは、検証を"指示"でなく"仕組み"に落とすことです。「脆弱性を確認してね」とお願いするのではなく、CIの関所やフック（特定の操作の前後で自動実行される検査）で機械的に止める。そのうえで、公開・本番反映の最後だけは人が目を通す。この二段構えを崩さないようにしています。

Codex Security CLIは、この「仕組みで検問する」層をAIコーディングに1枚足すのにちょうどよい道具です。関所をどこに挟むか——差分は日常のプルリクエストに、全体スキャンは節目に、そして最終承認は人に——を先に決めてから導入すると、丸投げの事故を避けられます。ツールを入れる前に、自分の開発フローのどこを関所にするかを描いておくことが、遠回りに見えて一番の近道です。

同じ「コミット前に脆弱性を検出する」流れは、Anthropic側のツールでも実現できます。ベンダーを横断して比べると、自分の運用に合う関所が見えてきます。

Claude Securityプラグイン｜コミット前に脆弱性検出

まとめ

Codex Security CLIは、AIが書いたコードの脆弱性をスキャンし、CIに重大度の関所を常設できる実用的なツールです。導入はnpmで1コマンド、CIには環境変数のAPIキーで組み込めます。差分レビューと全体スキャンを使い分ければ、検査コストと網羅性のバランスも取れます。

ただし早期リリースであり、既存のセキュリティ対策を置き換える魔法ではありません。仕組みで検問しつつ、最後は人が確認する——この設計を守れば、AIコーディングの速度を落とさずに、事故の芽を仕組みで摘めます。