Codex Securityは、OpenAIが2026年7月14日にGitHubで公開したCLI/TypeScript SDKです。コードを一気に置き換えるツールというより、リポジトリを走査して脆弱性候補を見つけ、根拠付きで確認し、修正の優先順位を付けるための運用基盤として見ると理解しやすいです。特に、diff scan・working tree scan・pre-commit hook・SARIF exportまで一式そろっているため、『開発者がローカルで試す段階』から『CIや複数リポジトリの継続監査』までつなげやすいのが強みです。
Codex Securityとは何か
公式ドキュメントでは、Codex Securityは security team と engineering team が脆弱性を find, confirm, fix するためのCLIとSDKと説明されています。READMEでも、 scan repositories, review changes, track findings over time, run security checks in CI という用途が明示されています。つまり単発の診断より、変更差分の確認と継続レビューに向いた設計です。
導入前に先に確認したい前提条件
前提は軽くありません。CLI利用にはNode.js 22以降が必要で、スキャン実行やエクスポートにはPython 3.10以降も必要です。さらにCLI/SDKはbetaで、利用にはアクセス権が必要です。ローカル利用はChatGPTアカウントで login、ヘッドレス環境は --device-auth、CIは OPENAI_API_KEY を使うのが公式手順です。リポジトリ全体のスキャンでは、アカウントや対象リポジトリ次第で Trusted Access for Cyber が追加で必要になる点も見落とせません。
社内でAIセキュリティレビューの導入設計まで整理したい場合は、 お問い合わせはこちら 。PoCの進め方から権限制御まで一緒に詰めやすくなります。
最初のスキャンはどう始めるか
最短手順はシンプルです。インストール後に npx codex-security --version と --help で状態を確認し、npx codex-security login のあと、scan 対象リポジトリと output directory を決めます。公式は、結果保存先をリポジトリ外の private な場所に置くことを強く勧めています。理由は、結果にソース断片や脆弱性詳細が含まれうるからです。まずは --dry-run で対象・出力先・入力条件を検証し、問題がなければ通常スキャンへ進む流れが安全です。
実運用で効く3つのスキャン方法
1つ目は通常の repository scan です。全体像をつかみたい初回診断向きです。2つ目は --diff origin/main --head HEAD を使う diff scan で、PR前後の差分確認に向きます。3つ目は --working-tree --base HEAD で、staged/unstaged change を commit 前に見る使い方です。さらに install-hook を入れると pre-commit のたびに高severityやscan errorを止められるため、『本番ブランチに入る前に止める』運用へつなげやすくなります。
結果ファイルはどこを見るべきか
初回で見逃しやすいのは report.md だけを見て終えることです。公式は scan-manifest.json、findings.json、coverage.json、report.md の4点を示しています。findings.json では severity・confidence・location・evidence・remediation が整理され、coverage.json では reviewed surfaces や exclusions、deferred work、open questions を確認できます。coverage は complete / partial / unknown の3段階なので、partial や unknown のまま『監査完了』扱いにしないのが重要です。
CIと複数リポジトリ展開で確認すべき点
CIでは API key を前提にしつつ、--fail-on-severity や --max-cost を組み合わせて、コストとブロック条件を明確にしておくのが現実的です。Codex Securityは bulk-scan にも対応しており、GitHubログイン後に最近pushされたrepository群を発見して選択的に走査できます。CSV指定のバルク実行やDocker経由の運用も用意されているので、数本の重要リポジトリから始めて、監査対象を段階的に広げる進め方が合います。
導入で詰まりやすい4つのポイント
1. Node.jsとPythonの両方が要る点を見落とし、CLIは入ったのにscanが回らない。 2. output directoryをリポジトリ内に置いてしまい、機微な結果を一緒に管理してしまう。 3. coverageがpartialなのに、finding件数だけ見て安全と誤解する。 4. 通常scanだけで終え、diff scanやhookまでつながず、レビュー工程に埋め込めない。PoC段階でこの4点をチェックリスト化しておくと、導入後の空回りをかなり減らせます。
FAQ
Q. まず全社導入すべきですか。A. いいえ。まずは重要リポジトリ1〜3本で dry-run、通常scan、diff scan、hook の順に試し、開発フローにどこまで自然に入るかを確認する方が安全です。Q. 既存SASTを即置き換えるべきですか。A. そこは慎重で、既存のCIやチケット運用に findings と coverage をどう接続するかを先に決めるべきです。Q. どんな会社に向くか。A. 変更差分レビューを重視する開発組織、複数リポジトリを継続監査したい組織、高severityの流入をcommit前に減らしたい組織と相性が良いです。
HelloCraftAIの見立て
Codex Securityは『AIに全部任せる診断』ではなく、『変更差分にAIを噛ませてレビュー密度を上げる仕組み』として導入すると失敗しにくいです。要件はやや重めですが、report・findings・coverage が分かれているので、社内監査や開発ガードレールへ接続しやすい設計です。AI開発のスピードを落とさずにセキュリティ確認を増やしたい企業ほど、ローカルscanとpre-commitから試す価値があります。
AI開発のレビュー設計や導入支援が必要なら、 HelloCraftAIに相談する からどうぞ。運用フローまで含めて整理できます。
