Codex Security CLIとは？機能や使い方、料金を徹底解説

Codex Security CLIは、OpenAIが2026年7月28日にApache-2.0ライセンスで公開した、セキュリティ脆弱性のスキャン・検証・パッチ提案を担うCLIおよびTypeScript SDKです。

2026年3月にresearch preview化された脆弱性検出エージェント「Codex Security」を、開発者のターミナルとCIパイプラインから直接呼び出せる形にした位置づけになります。

本記事では、Codex Security CLIの主要機能、Aardvarkから続く提供モデルの系譜、インストール手順、CI/CD統合、料金体系とアクセス条件、Snyk・Semgrep・GitHub Advanced Securityとの位置関係、導入判断で見落とされやすい観点までを、2026年7月時点の一次情報で体系的に解説します。

Codex Security CLIとは？7月28日にApache-2.0で公開されたセキュリティ用CLI

Codex Security CLIとは、OpenAIが2026年7月28日にApache-2.0ライセンスで公開した、コードリポジトリの脆弱性を発見・検証・修正するためのCLIおよびTypeScript SDKです。

openai/codex-securityリポジトリで、CLI・TypeScript SDK・スキャン処理を担うバンドルプラグイン一式**が公開されており、内部ロジックの改変やフォークも可能です。

Codex CLIとCodex Security CLIの位置づけ

同じ「Codex」ブランドの中でも、Codex CLIとCodex Security CLIは目的・リポジトリ・利用シーンが分かれています。以下の表で両者の位置づけを整理しました。

ここでのポイントは、Codex CLIは開発者向けの汎用コーディングエージェント、Codex Security CLIはAppSec担当向けの脆弱性特化ツールで、別リポジトリ・別パッケージ・別コマンド体系、という点です。

この2つを混同すると「Codex CLIをアップデートしたら脆弱性スキャンが使えるようになったのか」といった誤解が発生します。それぞれ個別にインストールする前提で読み進めてください。

Codex Security本体の系譜—

Codex Security CLIの位置づけを正確に理解するには、その内部で動く「Codex Security本体」がどう育ってきたかを押さえておく必要があります。

このセクションでは、2025年10月のAardvark private betaから、2026年7月28日のCLI OSS化までの4節目を時系列で整理します。

4つの節目の全体像

以下の表で、Codex Security本体とCLIの提供モデルがどう変遷してきたかを整理しました。

この流れが示すのは、Codex Security単体プロダクトの機能追加というより、AI主体の脆弱性発見をどのように配布するかを段階的に広げてきたという設計の変化です。

Aardvark（2025年10月）——GPT-5ベースの自律型セキュリティリサーチャー

Aardvark発表時の公式キービジュアル（2025年10月・出典：OpenAI）

Codex Securityの元となったAardvarkは、OpenAIが2025年10月に発表した、GPT-5をベースとする自律型のセキュリティリサーチャーです。

Aardvarkはファジングやソフトウェア構成分析（SCA）に頼らず、LLMの推論とツール利用で「人間の研究者のようにコードを読み、分析し、テストを書いて実行する」アプローチを採ります。

OpenAIによる内部評価では、既知の脆弱性と合成的に埋め込んだ脆弱性を含む「ゴールデンリポジトリ」で92%の脆弱性を発見したと報告されています。

Aardvarkは4段階のパイプライン（Analysis→Commit scanning→Validation→Patching）で動作し、この骨格はCodex Securityにそのまま引き継がれています。

Codex Security（2026年3月）——ChatGPT Enterprise/Business/Edu/Pro向けresearch preview

2026年3月6日、OpenAIはAardvarkをCodex Securityに改名し、research previewとして公開しました。

提供対象はChatGPT Pro/Enterprise/Business/Educationの各プランで、Codex web経由から利用可能となり、発表時には翌月まで無料利用が案内されました。

OpenAIは30日間で外部リポジトリ120万件超のコミットをスキャンし、Critical 792件、High深刻度10,561件の発見を報告しています。

Codex Security research preview発表時の公式キービジュアル（出典：OpenAI）

同時に精度改善の実績として、「ノイズ84%削減、severity過大報告90%以上削減、false positive率50%以上削減」を挙げており、AIセキュリティエージェントの実用性を数値で示した節目のリリースになりました。

OSSプロジェクトへの適用でもGnuTLSやGOGSなど複数のCVE取得が確認されており、Aardvark時代の10件からCodex Security時点で14件へと着実に積み上がっています。

Daybreak（2026年5月）——Trusted Access for Cyber枠組みで再定義

2026年5月にはCodex Securityを中核に据えたサイバーセキュリティイニシアチブ「Daybreak」が始まりました（Marktechpostが5月11日にローンチを報じ、その後OpenAI公式が6月にDaybreak拡張を発表）。

Daybreakイニシアチブの公式キービジュアル（出典：OpenAI）


Daybreakでは、Codex Securityが利用できるモデルをTrusted Access for Cyberという3段階のアクセスレベル（OpenAI公式は「current trusted access levels」と表記・番号付けはない）で整理しています。

以下の階層番号は本記事の整理のためのものです。

Cloudflare・Cisco・CrowdStrike・Snyk・Semgrep・Socketなど20超のパートナーとの連携も同時に公表され、Codex Securityが「単体プロダクト」から「エンタープライズセキュリティ運用基盤」へと再定義された節目になっています。

競合の観点でも、AnthropicがClaude MythosとProject Glasswingを4月に発表した約1か月後のタイミングで、OpenAI側の対抗手を示した動きと読めます。

Codex Security CLI/SDK OSS化（2026年7月28日）

そして2026年7月28日、OpenAIのCodex teamリードThibault "Tibo" Sottiaux氏がX上で、Codex Security CLIとTypeScript SDKのApache-2.0公開を発表しました。

OSS化前には、proprietary扱いを疑問視するIssueも投稿されていました（OpenAI側はOSS化判断とIssueの関係を公式には説明していません）。

この改編で開発者は、「npm install @openai/codex-security」 の1行でCLI/SDK/プラグインをローカルへ導入し、CIパイプラインからも同じバイナリを呼び出せるようになりました。

Codex Security CLIの主要機能

ここからは、CLIとして実際に何ができるのかを、公式ドキュメントに載っている機能単位で整理します。

Codex Security CLIは大きく分けて、リポジトリスキャン、発見の検証、パッチ提案、履歴管理、CI/CD統合の5系統の機能を持ちます。

Aardvark（現Codex Security）が使う脆弱性検出ワークフロー。Git repositoryのスキャンからThreat model構築、Validation sandboxでの検証、Codexによるpatch生成、Human reviewを経てPull Requestに至る（出典：OpenAI）

上の公式ワークフロー図が示すとおり、「scan」コマンドはGit repositoryのスキャンからThreat model構築までを、「validate」コマンドはValidation sandboxでの再現検証を、「patch」コマンドはCodex連動での修正案生成を担当します。

公式のパイプライン設計がそのままCLIコマンド体系に落とし込まれている構造で、Aardvark時代から続く「Analysis→Validation→Patching」の骨格が変わっていない点が特徴です。

3つのコアコマンド——scan / validate / patch

Codex Security CLIの中核をなすのは、scanコマンドを中心とした3つのコマンド群です。それぞれの役割を以下に整理しました。

• scan コマンド
  リポジトリ全体・特定パス・Git差分に対して脆弱性スキャンを実行する主コマンド。「--diff origin/main」 でブランチ間差分、「--working-tree」 で未コミット変更、「--mode deep」 で深堀りスキャン、「--dry-run」 で試験実行が可能。
  
  

• validate コマンド
  発見された脆弱性候補について、隔離サンドボックス環境で実際に再現可能かをエージェントに検証させる。ノイズと真陽性を切り分ける役割で、false positive削減の要になる部分。
  
  

• patch コマンド
  検証済みの発見に対して、修正案（パッチ）を生成する。OpenAI公式ドキュメントによれば、生成されたパッチは必ず人間のレビューを経てから適用する前提で設計されている。

これら3つはAardvark時代から続く「Analysis→Validation→Patching」の骨格をそのままCLIコマンド体系に落とし込んだものです。

既存の静的解析ツール（SAST）が「発見して並べる」で止まりがちなのに対し、Codex Securityの特徴は検証と修正案までを一連のパイプラインとして扱う点にあります。

発見の履歴管理——scans list / show / match / rerun / compare

Codex Security CLIは、1回のスキャン結果をその場で終わらせず、時系列で追跡できる履歴管理コマンドを備えています。

この履歴機能があることで、「あるコミットで新たに入った脆弱性はどれか」「先週修正したはずのバグが再発していないか」といったベースライン管理が可能になります。

SASTツールにありがちな「毎回同じ警告が出続けて疲弊する」状況を、diff優先の運用に切り替えられる設計です。

標準成果物とエクスポート形式

スキャン結果には標準成果物とそこから生成できるエクスポート形式があり、両者を分けて考えると使い分けが整理しやすくなります。

• 標準成果物
  「findings.json」（severity・confidence・場所・証拠・修正案）／「coverage.json」（レビュー対象範囲・除外領域・保留項目・未解決の疑問）／「report.md」（人間が読む要約）
  
  
• エクスポート形式
  「export」コマンドで完了スキャンからCSV / JSON / SARIFを生成できる。CSVは表計算・BIツール取り込み向け、JSONは他システムとの構造的連携向け、SARIFはコードスキャニング系ツール標準

特にSARIFエクスポートは、GitHubのAdvanced Securityコードスキャニング機能に取り込んで、Pull Requestのチェックにコードスキャンアラートとして表示させる運用が可能です。

既存のGitHubワークフローに差し込みやすい設計になっている点は、「gh api」 経由でCI組み込みを検討する上での実用的なメリットです。

追加スキャンオプション——コスト制御と知識注入

CLIには、大規模リポジトリの実務運用を想定した細かいオプションも用意されています。

以下の表で、実務で押さえておきたい主要オプションを整理しました。

特に 「--max-cost」 は実務で必須級のオプションです。ただし公式ドキュメントが明記するとおり、これは推定値ベースの停止条件でハードキャップではありません——実行中のリクエストは指定額を超えて完了する可能性があるため、上限値ちょうどで止まる想定は避けてください。

deep modeで大規模リポジトリをフルスキャンするほど推定コストが膨らみやすいため、まずは小さな値で開始し、実測値を見ながら段階的に広げる運用が安全です。

Codex Security CLIのインストールと基本コマンド

このセクションでは、実際にCodex Security CLIを手元の環境に導入し、初回スキャンを走らせるまでの手順を整理します。

なお、ここで解説する内容は公式docs（learn.chatgpt.com/docs/security/cli）を一次ソースとしていますが、コマンド仕様の詳細は随時公式側の更新を確認してください。

前提要件——Node.js 22＋Python 3.10

Codex Security CLIを実行するための前提要件は以下のとおりです。

手元にNode.js 18や20が入っている環境では、「nvm use 22」 などで22系にアップグレードする必要があります。Python側もPython 3.9以下だと動かないため、pyenv等でバージョン管理している場合は事前確認が必要です。

インストール手順

インストールは非常にシンプルで、npmで1行で完結します。

npm install @openai/codex-security

インストール後、以下のコマンドでバージョン確認ができます。

npx codex-security --version

このコマンドがエラーなく実行できれば、CLI本体の導入は完了です。

3種類の認証方式

Codex Security CLIは、利用シーンに応じて3種類の認証方式を選べます。

• 対話型ログイン
  「npx codex-security login」 を実行するとブラウザが起動し、ChatGPTアカウントで認証。開発者ローカルでの利用が主。
  
  

• デバイス認証
  「npx codex-security login --device-auth」 でヘッドレス環境（SSH接続先のサーバー等）向けのデバイスコード認証。ブラウザが立ち上げられないリモート実行環境で使う。
  
  

• APIキー環境変数
  「export OPENAI_API_KEY="<key>"」 でOpenAI APIキーを環境変数に設定。CI/CD環境ではこの方式が標準。

OpenAIは公式ドキュメント上で、APIキーをリポジトリにコミットせずシェル環境変数またはシークレットマネージャで管理するよう強く推奨しています。

GitHub ActionsならRepository Secrets、GitLab CIならProtected Variables経由で渡すのが基本形になります。

初回スキャンの実行

インストールと認証が済んだら、実際にスキャンを走らせてみます。基本形は以下のとおりです。

# 現在のディレクトリを対象にスキャン
npx codex-security scan .

# 特定のブランチとの差分だけをスキャン
npx codex-security scan . --diff origin/main

# 未コミット変更のみスキャン
npx codex-security scan . --working-tree --base HEAD

# 深堀りモードでスキャン（コスト高）
npx codex-security scan . --mode deep

# コスト上限5ドル・アーキ図付き
npx codex-security scan . --max-cost 5 --knowledge-base ./docs/architecture.md

このアプローチの実務的な利点は、以下の2点に整理できます。

Codex Security CLIのCI/CD統合とpre-commitフック

Codex Security CLIが従来のAIコーディングエージェントと違うのは、CI/CDやpre-commitといった開発者ワークフローに標準で組み込まれる設計を持っている点です。

このセクションでは、GitHub Actions・GitLab CI・pre-commit hookそれぞれへの統合方法と、実務で使うときの注意点を整理します。

pre-commitフックによるコミット前ブロック

Codex Security CLIには、コミット前のステージ済み・未ステージ変更をスキャンして、high-severity発見があればコミットを止めるpre-commit hook機能が組み込まれています。

インストールは以下の1コマンドで完了します。

npx codex-security install-hook

このフックは、既存のpre-commitスクリプトがある場合は上書きせずエラーになる設計です。すでに他のpre-commit（ESLint・Prettier等）を運用している場合は、その仕組みと共存させるには手動での統合が必要になります。

コミットを止めるseverity閾値はデフォルトでhigh以上ですが、インストール時のオプションで変更できます。

npx codex-security install-hook . --fail-on-severity medium

CI/CDでの失敗exit codeによるゲート運用

CI/CD統合では、Codex Security CLIが 「--fail-on-severity」 で指定severity以上の発見でexit code 1を返す設計を活かして、既存のCIランナーに直接組み込めます。

GitHub Actionsの例を示します。

- name: Codex Security scan
  env:
    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
  run: |
    npx codex-security scan . \
      --diff origin/main \
      --max-cost 3 \
      --fail-on-severity high

この構成では、mainブランチとの差分に対してhigh以上の発見があると、CIが失敗する挙動になります。

SARIFエクスポートを組み合わせれば、GitHubのAdvanced Security機能と連携し、Pull Requestビュー上に発見件数と場所が直接表示されるため、レビュー体験も自然に統合できます。

Docker Composeによる隔離実行

アクセス付与にCodex Security Dockerイメージが含まれる場合は、大量スキャンや隔離要件が強い環境向けに、公式ドキュメントでhardened Docker Compose構成での実行がサポートされています。

Linux Dockerで非特権ユーザーネームスペース（unprivileged user namespaces）が有効になっている必要がありますが、CI Runner側のホストと分離した環境でスキャンを走らせられるため、社内セキュリティポリシー上「本番CIランナーから直接OpenAI APIを呼びたくない」場合の選択肢になります。

CI統合で詰まりやすい3つの落とし穴

Codex Security CLIをCIに組み込む際、実装で詰まりやすい典型パターンが3つあります。

• max-costの初期値不足
  「--max-cost」 を設定せずにdeep modeでフルスキャンすると、想定より高い推定コストが表示されることがある。初回導入時は必ず低めの値から始めて実測を取るのが基本。ただしこれは推定値ベースの停止条件で実行中リクエストは超過し得るため、上限ちょうどで止まる想定は避ける。
  
  

• APIキーの環境変数配布ミス
  CI Runnerが複数マシンにまたがっている場合、シークレット設定漏れで一部Runnerだけスキャンが失敗するケースがある。Runnerごとの環境変数一貫性をチェックする。
  
  

• 既存SASTツールとのexit codeバッティング
  Snyk・Semgrep・CodeQLなど既存SASTが同一CIジョブで動いている場合、Codex Securityのexit codeとバッティングし、どちらの警告で落ちたか分かりにくくなる。ジョブを分けて並列実行するのが実務的な解。

これらは公式docsには明記されていない、実際にCIへ組み込むときに出てくる典型的な運用上の落とし穴です。導入プロジェクトの初期段階で先回りしておくと、後戻りが少なくなります。

Codex Security CLIの料金と提供範囲

Codex Security CLIの料金体系は、OSS部分と実行アクセス部分を分けて考える必要があります。

CLI/SDK/バンドルプラグインはApache-2.0で公開されており無料で入手できますが、実際にスキャンを走らせるにはlimited beta下でのCodex Securityアクセス付与が別途必要です。
ChatGPTログインやAPIキーはあくまで認証手段で、それ自体では利用資格を得られません。

さらにフルリポジトリスキャンでは、アカウント条件によりTrusted Access for Cyberが要求される場合があります。このOSS公開／アクセス付与／TACの3層構造が実務判断の分かれ道になります。

OSS部分と実行アクセスの料金・条件

以下の表で、Codex Security CLIとscanner本体の料金・アクセス条件を整理しました。

OSS部分の無償化は「配布と改造を自由にする」意味が大きいものの、実行を伴う運用にはlimited beta下でのアクセス付与が別途必要になります。

既存のOpenAI API運用に組み込みやすい設計ではあるものの、「codex-security login」 や 「OPENAI_API_KEY」 を用意すればすぐスキャンが走るわけではなく、アクセス付与を受けているかどうかが運用可否を決める点は押さえておく必要があります。

認証経路の使い分け

Codex Security CLIへの認証は、大きく分けて2経路あります。ただしいずれも認証手段であって、Codex Security本体の利用資格を付与するものではない点に注意してください。

• ChatGPTログイン経由：ChatGPTアカウントで 「codex-security login」 を実行
• APIキー経由：「OPENAI_API_KEY」 を環境変数で渡す。CI/CD・スクリプト実行・複数マシンでの自動化向け

いずれの経路を選んでも、実際にスキャンを走らせるにはlimited beta下でのCodex Securityアクセス付与を受けていることが前提です。

個人開発者ならChatGPTログイン、CI組み込みならAPIキー、組織展開でSSO/監査要件があるならChatGPT Business/Enterprise、というのは認証手段の選び方の指針であり、アクセス付与を受けていない状態ではどちらの経路でもスキャンは走りません。フルリポジトリスキャンでのTrusted Access for Cyber要求も、いずれの認証経路でも共通で発生し得ます。

コスト表示と実際の請求

Codex Security CLIは、スキャン実行時に標準API価格を基準とした推定コストを表示します。

実際の料金・請求条件は付与されたアクセス条件（契約プラン・API契約・特別プログラム等）に従うため、公式一次情報から一元的に確定することはできません。正確な単価と請求経路は自組織のアクセス付与時の案内で確認してください。

「--max-cost」 オプションはCLIの推定コストが指定USD閾値を超えたらスキャンを止める目安の設定です。ただしこれは推定値ベースの停止条件でハードキャップではなく、実行中のリクエストは指定額を超えて完了することがあります。

「--mode deep」 を大規模リポジトリで走らせるほど推定コストが膨らみやすいため、初期導入時はdiffベース（「--diff origin/main」）で狭いスコープから始め、実測値を取ってから運用範囲を広げるのが安全です。

CI/CDに組み込む場合は、CLIの推定コストと実際の請求が乖離し得る前提で、月次予算枠に余裕を持たせておくのが実務では現実的です。

Codex Security CLIとSnyk・Semgrep・GitHub Advanced Securityの位置関係

Codex Security CLIを既存のセキュリティツール群のどこに位置づけるかは、導入判断で最も混乱しやすい論点です。

このセクションでは、代表的な既存SAST/SCA/DASTツールとの機能・料金・得意領域を比較し、置き換えではなく補完としての位置づけを整理します。

代表的SAST/SCA/DASTツールとの比較

以下の表で、Codex Security CLIと代表的なセキュリティツールの位置関係を整理しました。

この比較から分かるのは、Codex Security CLIは既存SAST/SCAツールの代替ではなく補完層として位置づけるのが実務的、という点です。

Snyk CodeやSemgrepは開発者フレンドリーな静的解析でPR体験に強く、GHASのCopilot AutofixはGitHubワークフロー完結を武器にします。

一方Codex Securityは、リポジトリ固有のthreat modelを構築した上でsandbox validationまで踏み込む点が独自で、汎用SASTでは拾いきれない業務ドメイン依存の脆弱性検出に強みがあります。

Codex Security CLIだけでは押さえきれない領域

一方で、StackHawk等が指摘しているように、Codex Security CLIには実行時の悪用可能性まで確定するには別ツールとの併用が必要な領域があります。

• DAST領域（動作アプリケーションのテスト）
  ソースコード上のヒントは検出できるが、実行時の挙動そのものはDASTで動かして確認する必要がある
  
  
• 認可制御の実装ミス
  Broken Object Level Authorization等の候補は静的側でも検出できることがあるが、悪用可能性の確定には実際のトラフィックを流すDASTが必要
  
  
• インフラ設定ミス
  CORS・TLS・逆プロキシ・キャッシュポイズニング等はソースコードスキャンだけでは把握しづらく、実環境のスキャンや設定監査で補完する
  
  
• ビジネスロジック欠陥
  候補として検出できる場合はあるが、コンポーネント間の相互作用による悪用可能性を確定するには実行環境での検証が必要

これらは「Codex Securityがカバー外」というより、候補検出は静的側でも可能だが実行環境での悪用可能性確認にはDAST等の併用が必要、と捉えるのが正確です。

Snykのような開発者フレンドリー系SAST、GitHub Advanced Security for Azure DevOps（GHAzDO）のようなGitHubワークフロー統合系、StackHawk等のDASTツール、実行時保護（WAF・RASP）を役割分担で組み合わせるのが実務的な設計です。

併用が現実解になる典型パターン

実務では、Codex Security CLIと既存ツールの併用が現実解になるケースが多くあります。

典型的なパターンは以下のとおりです。

• SASTはSnyk/Semgrep＋Codex Security CLIで二段構え：既存SASTで幅広く検出、Codex Securityで深いthreat model依存の発見をカバー
• DASTはStackHawk/OWASP ZAPで別途担保：実行時テストは別系統で
• 依存関係はSnyk SCA/GitHub Dependabot：ライブラリ脆弱性は既存の依存関係管理ツールで
• PR統合はGHAS Copilot Autofix：GitHubワークフローの完結性はGHASで

このように「置き換え」ではなく「役割分担」で組み立てるのが、既存投資を活かしつつCodex Security CLIの強みを取り込む現実的なアプローチです。

Codex Security CLI導入判断で見落とされやすい3つの観点

ここまでの機能・料金・競合ツール整理を踏まえ、実務で導入を判断する際に見落とされやすい3つの観点をSIerの支援経験から整理します。

いずれも「使えるかどうか」より「自社の運用体制と適合するか」を問う論点です。

アクセス付与の有無と認証経路の見立て

第一の論点は、Codex Security CLIへのアクセスが自組織に付与されているか、そしてどの認証経路で回すかです。

Codex Security CLIはOSSですが、実際にスキャンを走らせるにはlimited beta下でのアクセス付与が必要です。ChatGPTログイン／APIキーはあくまで認証手段で、アクセス付与を受けていない状態ではスキャンが走りません。

• 既にCodex Securityアクセスが付与されている企業
  ChatGPTログインまたはAPIキーの手元にある方でPoCを開始できる。SSO/監査要件があるならChatGPT Business/Enterpriseでログイン運用、CI組み込みが主用途ならAPIキーで自動化
  
  
• アクセス未付与の企業
  まずOpenAIのアカウントチーム経由でアクセス付与の申請ルートを確認する必要がある。CLIのインストール・「login」 の実行までは進められるが、スキャン実行段階でアクセス付与の有無が分岐点になる
  
  
• 個人開発者・小規模チーム
  現時点でCodex Security CLI/SDKはlimited beta段階のため、個人開発者が即座にアクセス付与を受けられるかは案内ルート次第。ChatGPT ProログインやAPIキーだけで即開始できる前提は避け、公式のアクセス案内を確認する

ここで判断を誤ると、「CLIをインストールしたのにスキャンが走らない」というPoC失敗パターンに陥ります。

アクセス付与の申請と認証経路の準備を並行して進めるのが安全です。フルリポジトリスキャンでのTrusted Access for Cyber要求も、アクセス付与後の別要件として想定しておく必要があります。

既存Snyk/Semgrep/GHAS投資との併用設計

第二の論点は、既に導入済みのセキュリティツールとの併用設計です。

Codex Security CLIを「置き換え候補」として評価すると、多くの既存ツールが持つ機能（IDE統合・PR体験・依存関係管理等）で見劣りし、導入判断が難しくなります。

以下のような視点で併用設計を組むのが実務的です。

• 既存Snyk投資がある：Snykは維持しつつ、Codex Security CLIをdiffベースでPR単位に追加。「深い発見だけ拾う」二段構え
• Semgrep自己ホスト運用：既存のカスタムルールセットは維持し、Codex Securityはリスクの高いリリース前スキャンに限定投入
• GHAS Copilot Autofix導入済み：SARIF出力を通じてGHASコードスキャニングに結果を流し込み、PR体験を統一
• 既存ツール未導入：Codex Security CLI単独ではなく、Snyk/Semgrepの無料枠と並行導入する方が守備範囲が広くなる

SIerとして企業のセキュリティ運用を見ていると、「既存投資を無視して新ツールに一本化する」判断は運用が回らないケースが多く、役割分担で組み立てるのが現実的な結論になります。

TACが必要な場合の想定運用

第三の論点は、自組織のアカウントやリポジトリでTrusted Access for Cyberが要求される場合にどう備えるかです。

Codex Security CLIのフルリポジトリスキャンは、アカウントやリポジトリの条件によってTACが必要になる場合があります（公式ドキュメントの案内どおり）。

TAC要否の確定基準は公式に一元化されていないため、まずは自組織の想定運用（フルスキャン中心か、diffスキャン中心か等）を整理したうえで、TAC要求の有無をOpenAI側と確認する流れになります。

TAC要求が発生した場合の承認待ち期間を無駄にしないために、以下は並行で進めておく価値があります。

• CLIの導入と小スコープ運用の準備：「--diff origin/main」 や 「--path」 で範囲を絞ったスキャンから始め、対象アカウント・リポジトリでTAC要求の有無を確認する
  
  
• 既存SAST（Snyk/Semgrep）でベースライン取得：先にSAST層の脆弱性件数を可視化し、Codex Security投入時の削減効果を測れる状態にしておく
  
  
• CIパイプラインのテンプレ準備：GitHub Actions/GitLab CIの雛形を先に用意し、承認と同時に切り替えられる形にしておく
  
  
• 社内トレーニング：セキュリティチーム・開発リードにCodex Securityの発見フォーマット・validation結果の読み方を先に共有

「承認要否が確定してから考える」のではなく、想定運用と承認要否を並行で整理しておくと、実運用への移行がスムーズになります。

Codex Security CLIを業務Agent基盤に載せて運用するなら

Codex Security CLIは開発者ターミナルとCIから呼べる強力な基盤ですが、実務ではそこから一段進めて、脆弱性レビュー結果の起票・トリアージ・修正案の承認フローまで、業務Agent側で運用に組み込む必要があります。

CLI単体の実行だけでは、発見件数が増えたときの人手対応が追いつかず、「レポートだけ積み上がる」状態になりやすいためです。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、Codex Security CLIを含むセキュリティAgentを業務プロセスに載せる運用基盤として機能します。

• Codex Security CLIをTeams上のAgentから起動
  Teams上で「今日のPRをCodex Securityでスキャンして」と自然言語で指示するだけで、CLIが起動しdiffスキャンを実行。結果は同じTeams画面で確認できます。
  
  

• モデル世代交代を吸収する管理層
  Codex Security本体がGPT-5.5→GPT-5.6→次世代モデルへ移行しても、業務Agent側の設計は不変。CLIコマンドの変更は基盤側で吸収します。
  
  

• Agent単位でセキュリティ統制を1画面管理
  コード・脆弱性情報を扱うAgentごとにアクセス範囲を設計。誰がどのAgentで何を照会したかを不変ログで残し、監査対応をそのまま提出できる形で保管します。
  
  

• データは100%自社Azureテナント内に保持
  コード・脆弱性・設定情報はAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、Codex Security CLIのPoCから業務Agent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、Codex SecurityやClaude Code Securityを含む脆弱性レビューAgentの実装例をご確認ください。

Codex Security CLIを業務Agent基盤に載せて運用する

AI主体の脆弱性レビューをTeams上のAgentから継続実行

Codex Security CLI単体は開発者ターミナル向けの実行基盤ですが、実務ではCIだけでなく業務Agent側からのオンデマンド呼び出しや、脆弱性レビュー結果の起票・トリアージまで運用に組み込む必要があります。AI Agent HubはCodex Security CLIを含むセキュリティAgentをTeams上から起動し、レビュー履歴・修正案・監査ログを1画面で統合管理できる自社Azureテナント内基盤として機能します。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Codex Security CLIについて、OSS化された範囲・提供モデル系譜・主要機能・インストール・CI/CD統合・料金・競合ツール比較・導入判断の観点までを、2026年7月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• 2026年7月28日にApache-2.0で公開されたのはCLI・TypeScript SDK・バンドルプラグイン一式で、実行にはlimited beta下でのCodex Securityアクセス付与が別途必要（ChatGPTログインまたはAPIキーが認証手段）となる
  
  
• scan・validate・patchのコマンド体系、標準成果物（findings.json/coverage.json/report.md）とSARIFエクスポートによるGitHub Advanced Security連携、pre-commitフック・「--fail-on-severity」によるCI失敗exit codeで既存の開発者ワークフローに標準で組み込める設計
  
  
• Snyk・Semgrep・GHASの代替ではなく補完層。実行環境での悪用可能性確認にはDAST等の併用が必要なので、既存ツール投資と役割分担して併用するのが現実的

導入を検討する立場からすると、Codex Security CLIは「明日から全社スキャンに切り替える」ツールではなく、既存のSAST/SCA投資と役割分担しながら、深いthreat model連動の発見だけをdiffベースで拾う二段構えとして位置づけるのが現実的です。

まずは自組織へのアクセス付与ルートをOpenAI側と確認し、認証経路（ChatGPTログイン／APIキー）の準備、CIテンプレ、Agent基盤側の運用設計を並行で進めておくのが、実用的な第一歩になります。