Codex Security CLIで始めるAI生成コードの安全な検査

Codex Security CLIは何を自動化するのか

Codex Security CLIは、リポジトリ内の脆弱性を発見、検証、修正するためのCLIとTypeScript SDKです。OpenAIは7月29日（現地時間）に発表し、CI/CDへ組み込む機能も用意しました。OpenAI、脆弱性の発見・検証・修正を行う「Codex Security CLI」をオープンソース公開／CI/CDへ組み込むことも可能

AI駆動開発では、実装速度が上がるほどレビューの見落としも増えます。重要なのは、AIが作った変更をそのまま信頼することではありません。問題候補を見つけ、根拠を確かめ、修正案をテストできる単位にする。その工程をCIに組み込める点が、このCLIの価値です。

検出・検証・修正を分ける仕組み

まず、プルリクエストで変更差分をスキャンします。Codex Securityは特定パスの指定や、検出結果を根本原因で照合する比較に対応しています。新規、継続、解決済みを分けられるため、既存の問題によってCIが毎回止まる状態を避けやすくなります。OpenAI just open-sourced Codex Security

検出結果から作った修正案は、本番ブランチへ直接反映しません。専用ブランチや一時ワークスペースで、ユニットテスト、統合テスト、既存の静的解析を通します。テスト失敗、権限変更、依存関係の追加を伴う修正は、人間の承認へ戻す設計が必要です。

CIでの活用例：修正案をマージ候補へ絞る

検証済みの修正だけをマージ候補にします。CLIは人間向けのreport.mdに加え、構造化ファイルも出力します。CI側では、重大度や対象ファイルに応じて失敗判定を出したり、レビューを依頼したりできます。

つまり、AIに広い権限を渡して自動修正させるのではなく、検出と修正案の作成を自動化し、反映の判断は既存のレビュー工程へ残す使い方です。AI生成コードが増えるほど、この分離はレビューの負担を抑える土台になります。

導入の分岐点：権限と実行範囲を絞れるか

CIではログインの代わりにOPENAI_API_KEYまたはCODEX_API_KEYを使えます。環境変数で渡したキーは現在のスキャンに直接使われ、Codexの認証情報保存先やシステムキーチェーンには保存されません。CI用のキーはスキャン専用にし、マージやデプロイの権限とは分けるべきです。

推定モデルコストが指定額を超えると停止する--max-costも、無制限の実行を防ぐための実務的な制御になります。一方、コードを読み、コマンドを実行できる自動化に広い権限を渡すと、検査と修正の境界は崩れます。検出はCI、修正は隔離環境、反映は承認後という分業を守れない場合は、自動修正まで進めないほうが安全です。

まとめ

最初の一手は、AI生成コードを含むプルリクエストへ差分スキャンを追加し、結果をレビューの入口にすることです。自動修正を急ぐ前に、修正案をどの隔離環境でテストし、誰がマージを承認するかを決めましょう。AIに任せる範囲ではなく、人間が止める地点を先に設計できるかが、導入判断の基準になります。