>
>
公開日
最終更新日
Codex CLIは、OpenAIが提供するターミナル上のコーディングエージェントです。一方、Codex Security CLIは、コード中の脆弱性の検出・検証・修正支援に使うCLIとTypeScript SDKです。
導入時は、通常版の@openai/codexとセキュリティ検査用の@openai/codex-securityを区別します。
本記事は、導入を判断する開発責任者と情報システム部門を対象に、料金、アクセス条件、実行権限、コマンド、ログ管理を整理します。記事更新日は2026年10月29日です。結論として、CLI本体はApache-2.0で入手でき、費用はChatGPTプランまたはAPIの請求先で別に発生し、アクセス可否は契約する認証経路で決まります。導入可否は「Codex Securityの料金・OSS・アクセス条件」と「最短導入・必須確認・本番ゲート化の判断」で段階ごとに決め、その後に「Codex CLIとCodex Security CLIの導入・主要コマンド」「CI/CDの終了コードとリリース判定」「導入可否の判断と4週間のPoC計画」の順で解説します。
導入前の必須5項目：認証方式と請求先、送信・保持条件、検査対象のリポジトリ、レポートの保存先、1回あたりの費用上限
PoCで確認する項目：既存検査に対する追加検出、完了率、レビュー時間、終了コード別の分岐
本番移行後の運用項目：CLI版の更新、例外承認の期限管理、レポートの削除
判断項目 | 最短の判断 | 条件に合わない場合 |
|---|---|---|
認証経路 | 組織の管理者が利用権限と請求先を特定できる認証経路を使う | 特定できない場合は、個人アカウントで社内コードを解析しない |
コード送信可否 | 契約上の送信・保持条件と、対象データの区分が一致するリポジトリだけを検査する | 一致しないリポジトリは検査対象から除外する |
費用上限 |
| 月額は、実行回数・同時実行数・再実行回数も含めて管理する |
CI条件 | 終了コード0のうち、重大度の基準を設定して合格したものだけを次工程へ進める | 1はマージ停止、2は検査未完了として停止し、原因別に再実行する |
Codex CLIとは
コードを作成・変更するための通常版エージェントと、セキュリティ検査を実行するためのCLIおよびSDKは、役割の異なる別の道具です。
本記事のポイント
通常版は
@openai/codex、セキュリティ検査用は@openai/codex-securityで、導入するnpmパッケージが異なります。OSSライセンス、ChatGPTの利用枠、API推論の課金は別々に管理します。
SASTはコードの静的解析、SCAは依存関係の既知脆弱性管理を担当し、AI推論型の検査は文脈を伴う分析に追加します。
CIでは検査の完了と検出結果を分け、終了コード
2を「問題なし」ではなく「検査未完了またはエラー」として扱います。
通常のCodex CLIとセキュリティ検査用CLIの違い
両者は目的が異なるため、同じ端末で使う場合も認証情報、対象リポジトリ、出力先を分けて管理します。OpenAIのCodex CLI公式リポジトリは、ターミナルで動くコーディングエージェントとChatGPTアカウントによる利用を案内しています。
比較軸 | Codex CLI | Codex Security CLI |
|---|---|---|
主な目的 | コードの生成、修正、調査、テスト | 脆弱性の検出、検証、修正支援 |
npmパッケージ |
|
|
主な成果物 | コード変更、回答、テスト結果 | 所見、検証結果、スキャン状態、レポート |
CIでの主な用途 | 開発作業の自動化 | 検査結果と完了状態による判定 |
OpenAIのセキュリティ検査用パッケージの公式READMEでは、リポジトリ、特定パス、コミット差分、ワークツリーを対象にするCLIとTypeScript SDKを案内しています。通常版のコーディングエージェントに「安全かどうか見て」と指示する運用と、スキャン状態や終了コードを管理する運用は分けます。後者をリリース判定へ接続する場合は、検出内容と検査の完了状態を機械的に取得する構成にします。
Codex Securityの料金・OSS・アクセス条件
料金は、パッケージの利用許諾と、推論に使うアカウントやAPIの費用を分けて見積もります。npmのCodex Securityパッケージ情報ではApache-2.0ライセンスと表示されています。
通常のCodexを含むChatGPTプランについて、OpenAIの料金案内はPlus、Pro、Businessの各プランを地域の通貨で掲載しており、金額は地域と時点で変わります。Businessは2席以上が対象です。ChatGPTプランの価格を、そのままセキュリティ検査用CLIの全スキャン料金や無制限利用の価格に読み替えません。費用台帳には、契約プラン、推論の請求先、対象リポジトリ、実行回数を別の列に記録します。
セキュリティ検査機能へのアクセスは、CLIのインストール成功だけでは判断しません。ChatGPT認証、APIキー、Trusted Accessなどの利用条件は、組織が契約するアカウントと利用経路に合わせます。組織管理者が利用権限と請求先を特定できる場合は管理下の認証で進め、特定できない場合は個人アカウントで社内コードを解析しない運用にします。
OSS利用とセキュリティ実績の区別
OSSとして利用する場合は、CLI自体のライセンスと、解析対象のOSSリポジトリに対する権限を区別します。公開リポジトリでも、検証で外部サービスへアクセスしたり、攻撃を再現したりする場合は、対象システムの管理者が認めた範囲に限定します。
IPAの2026年3月資料は、OpenAIのCodex Security、旧称Aardvarkについて、ベータテストでアラートを84％削減し、誤検知率を50％以上低下させ、OpenSSH、GnuTLS、GOGSで脆弱性を特定した実績を取り上げています。これは同ベータテストに関する実績で、個々のCLI実行で同じ削減率を保証する値ではありません。自社では追加検出数、確定した脆弱性数、担当者のレビュー時間を別々に測ります。
最短導入・必須確認・本番ゲート化の判断
導入判断は、起動できる段階、データを扱える段階、リリースを止められる段階に分けます。各段階で承認する担当者を決めると、開発担当だけで契約や情報管理の判断を抱えずに進められます。
段階 | 実施内容 | 次へ進む条件 |
|---|---|---|
最短導入 | 管理環境へ導入し、バージョンとヘルプを記録 | 対象パッケージと実行環境を特定できる |
必須確認 | 認証、送信先、保持、ログ、費用を整理 | 社内のデータ区分と契約条件が一致する |
本番ゲート化 | 終了コード、通知、例外承認をテスト | 未完了を検知し、再検査や代替レビューへ回せる |
Codex全体の法人利用やアカウント管理は、OpenAI Codexの情シス向け完全ガイドでも整理しています。本記事では、CLIの実行からCI判定までを中心に扱います。
▶ 関連記事: Codexとは？2026年最新の料金・機能と安全な企業導入策
▲ 通常版のCodex CLIとセキュリティ検査用CLIの目的・成果物・費用管理の比較。
CLI公開の背景と検査対象の選定基準
検査対象はコード量だけで選ばず、認証・認可・決済など、変更が業務上の権限や信頼境界に及ぶ領域から選びます。
AI活用に伴う検査対象の増加
開発チームがAIで作成する変更を増やす場合は、生成速度とレビュー可能な量を別々に測ります。コードの作成が早くなっても、権限判定やデータの公開範囲を担当者が確認する時間まで同じ割合で短くなるとは限りません。
認可処理を例にすると、API単体でのログイン確認が正しくても、別組織のデータをID指定で取得できれば問題が残ります。検査対象には、入口の認証処理、オブジェクトの所有者判定、バックグラウンド処理、管理画面を含めます。設計文書がある場合は「誰が、どの組織の、どのデータを操作できるか」を先に整理し、検出結果をその仕様と照らし合わせます。
AI生成コードの不具合率や脆弱性率を比較する場合、評価対象の言語、モデル、プロンプト、正解データの定義をそろえます。他社の比率を自社の脆弱性件数へ直接掛け合わせるのではなく、同じ変更を複数の検査へ通し、どこで何を検出したかを記録します。
2026年の脅威動向とガバナンス
情シスは、AIがコードを調べる能力と、そのAIツール自体の実行リスクを別の台帳で管理します。IPAの2026年9月資料は、Pillar SecurityがCursor、Codex CLI、Gemini CLI、Google Antigravityの4製品で計6件のサンドボックスエスケープ脆弱性を公表した動向を取り上げています。
この件数は4製品の合計であり、すべてがOpenAIのコーディングエージェントの脆弱性という意味には読み替えません。また、公表件数だけで利用中のバージョンが影響を受けるかは決まりません。運用担当は製品名、導入版、影響条件、更新状況を対応付け、影響する版が稼働している場合は更新または実行停止へ進みます。サンドボックスがある場合も、端末の権限、ネットワーク、認証情報を追加で制限します。
IPAのAIセキュリティ関連の公開情報には、2026年9月10日のOpenAI Codexに関するPwn2Own経由のRCE脆弱性4件も含まれます。これらはAI開発ツールを資産管理と脆弱性管理の対象へ入れる判断材料です。開発支援ツールとして利用を許可した後も、バージョン更新とインシデント対応の担当を残します。
組織全体の脅威分類はIPAの情報セキュリティ10大脅威、経営層の責任との接続は経済産業省のサイバーセキュリティ経営ガイドラインで整理できます。AI用の例外ルールを増やすより、既存の資産管理、変更管理、事故報告へCLIを追加する形にします。
国内外の企業事例と適用範囲
企業事例は、コーディング支援の成果とセキュリティ検査の成果を分けて読みます。通常版による業務改善を、セキュリティ検査用CLIの検出精度として紹介しないようにします。
企業・対象 | 公開時期 | 課題と施策 | 成果・対象範囲 |
|---|---|---|---|
LINEヤフー／ワークショップでの体験 | 2026年4月 | Codex CLIのスキル機能で問い合わせへの自動一次回答を生成する仕組みをワークショップで体験 | 約600名が参加したワークショップでの体験 |
Ramp／プルリクエストへのフィードバック | 2026年公開の事例 | GPT-5.5を備えたCodexを活用 | フィードバック時間を数時間から数分へ短縮 |
LINEヤフーの技術ブログは、約600名が参加したワークショップで、Codex CLIのスキル機能を使った問い合わせへの自動一次回答の仕組みを体験する内容を紹介しています。OpenAIのRamp事例では、GPT-5.5を備えたCodexによってプルリクエストへのフィードバックが数時間から数分へ短縮しています。
自社で同様の活用を行う場合は、生成された回答や変更をレビューする担当まで割り当てます。セキュリティ検査のPoCでは、これらの時間短縮とは別に、確定所見、見逃し、未完了、レビュー負荷を評価します。
他社AIセキュリティ製品の比較基準
AnthropicやGoogleを含む他社製品との比較では、同じリポジトリ、同じ差分、同じ判定基準を使います。製品ごとに得意なテストだけを選ぶと、導入後の費用やレビュー負荷を比較できません。
検査の条件：対象コミット、除外パス、設計文書、検査時間をそろえます。
データの条件：送信範囲、保持期間、処理経路、閲覧者を記録します。
判定の条件：重複除外後の所見、確定した脆弱性、誤検知、未完了を分けます。
運用の条件：再実行、停止、キー失効、レポート削除を担当者が実行できるか試します。
社内で他のAIエージェントの利用実態も整理する場合は、AIエージェント比較記事と併せて管理対象を洗い出せます。ただし、製品数ではなく、コードと認証情報が通る経路ごとに承認を付けます。
▶ 関連記事: 【2026年8月最新】Claude Code 企業利用の統制ガイド｜APIキー管理・MCP連携・シャドーAI対策
Codex CLIとCodex Security CLIの導入・主要コマンド
導入時はパッケージを選び、実行環境と認証を整えた後、対象範囲を限定したスキャンを実行します。
通常のCodex CLIのクイックスタート
コードの生成や修正を始めたい場合は、セキュリティ検査用ではなく通常版のコーディングエージェントを導入します。OpenAIの公式リポジトリは、npmとHomebrewによるインストール、およびChatGPTアカウントによるサインインを案内しています。
初回は検証用リポジトリで起動し、構成説明など、ファイルを書き換えない依頼から始めます。たとえば「このリポジトリの構成を説明し、テスト方法を挙げてください。ファイルは変更しないでください」と指示します。次に小さな修正を依頼し、差分とテスト結果を人が確認します。サインインできることと、組織が社内コードの利用を承認していることは分けて管理します。
セキュリティ検査用CLIの動作要件
セキュリティ検査用の実行環境は、Node.jsとPythonの両方をそろえます。OpenAIのCodex Security公式READMEでは、Python 3.10以降を案内しています。Node.jsは、READMEが指定する22.x系の22.13.0以降、24.x、26.xのいずれかから版を選んで固定します。
Python 3.10を使う構成では、READMEにあるtomliの条件も環境定義へ含めます。端末で動いた組み合わせをそのままCIへ持ち込むのではなく、OS、Node.js、Python、CLI、追加依存関係を一組の構成として保存します。OSごとの差異を検証できる体制なら複数環境へ展開します。維持できる環境が一つだけなら、その環境を社内標準として固定します。
再現性が必要なCIでは、検証済みのパッケージ版を依存関係ファイルとロックファイルへ保存します。通常ジョブで最新版を取り直す運用を避け、更新用の変更として差分レビューを通します。更新記録にはパッケージ版、実行日、公式READMEの参照箇所、検証結果を残します。記事の日付だけを、社内環境の検証日の代わりに使いません。
npmスコープとパッケージ識別
セキュリティ検査用CLIは、初回実行でも@openai/codex-securityというスコープ付き名で指定します。npmの公開元、パッケージ名、バージョン、依存関係、ライセンスを導入記録にまとめます。
npx codex-securityのようにスコープを省略すると、意図したパッケージと識別できなくなります。未導入環境では別名のパッケージ取得につながるおそれがあるため、社内テンプレートでは省略形を使いません。名称が似ている製品や検索時の誤記を手掛かりに、インストールコマンドを推測しない運用にします。MicrosoftのCodex-CLIなど、同じCodexを含む別実装も、OpenAIの二つのパッケージとは分けて扱います。
ChatGPT認証とAPIキー運用
ローカルで対話的に利用する場合と、CIで無人実行する場合は、認証情報の所有者を分けます。公式READMEは、OPENAI_API_KEYまたはCODEX_API_KEYによる認証を案内しています。
人が使う認証は退職・異動時に停止できる組織管理へ寄せ、CIのAPIキーはシークレットストアから対象ジョブだけへ渡します。キーをコマンドへ直接書くと、シェル履歴やジョブログに残るため避けます。複数の認証情報を同時に渡す構成も避け、ジョブの請求先を一つに決めます。認証の選択とアクセス条件は冒頭の判断に集約し、後続ジョブが個人アカウントへ自動的に切り替わらないようにします。
コマンドと主要オプション
スキャンの再現に必要な引数は、対象、範囲、予算、補足資料、出力先に分けて記録します。次の一覧は、運用上の用途ごとに整理したコマンドとオプションの例です。導入したバージョンの--helpに表示されないオプションは、CIテンプレートへ入れず、代替の絞り込み方法を決めてから使います。
コマンド・オプション | 用途 | 実務上の使い分け |
|---|---|---|
| CLI版の取得 | ジョブ開始時に実行記録へ保存 |
| 対話的な認証 | 管理端末でのローカル利用 |
| 対象のスキャン | リポジトリのパスを明示 |
| 基準コミット等との差分指定 | プルリクエストの変更を検査 |
| 対象パスの限定 | 認証や決済などの領域別検査 |
| 作業ツリーの変更を指定 | コミット前のローカル検査 |
| 設計資料などの追加 | 認可仕様や脅威モデルを入力 |
| 推定費用に基づく停止上限 | 実行単位の費用増加を抑制 |
| 出力先の指定 | リポジトリ外の保護領域へ保存 |
| 違反とする重大度の設定 | CIのポリシー判定へ接続 |
| 完了済み結果の出力 | JSON・CSV・SARIFを用途別に連携 |
--knowledge-baseには、検査対象のコードと対応する版の設計資料を渡します。古い仕様を混ぜると、廃止済みの権限やAPIを前提に所見を読むことになります。資料の所有者、更新日、対象サービスをそろえられる場合に追加し、対応する版がない場合は、PoCの制約として記録します。
差分スキャンと費用上限
通常のプルリクエストでは差分を対象にし、全体検査は別のスケジュールへ分離します。次の例では、--max-costに社内で決めた1回あたりの上限額を指定します。
実費は実行履歴と請求データから集計し、実行回数、同時実行数、再実行回数も制御して、単発ジョブの上限だけで月額を管理しません。
▶ 関連記事: 【2026】Claude（クロード）とは？読み方・料金と企業活用
CI/CDの終了コードとリリース判定
CI/CDでは「スキャンが完了したか」を先に判定し、その後に「設定したセキュリティ基準へ合格したか」を判定します。
終了コードの分類と判定基準
終了コードは、検出結果と実行障害を分けるために使います。本記事では、完了、ポリシー違反、未完了・エラー、中断を次の表のとおり運用上の分類として割り当てます。130と143は、CLIリファレンスが中断・終了シグナルによる停止として挙げる値で、シェルが付ける128＋シグナル番号と同じです。
終了コード | 運用上の分類 | 本番向けの処理例 |
|---|---|---|
| 完了したレポート専用スキャン、またはポリシー合格 | 必須の判定条件を設定済みなら次工程へ進行 |
| スキャン完了後のポリシー違反 | マージを停止し、所見をレビュー担当へ通知 |
| 入力不備、実行時エラー、検査対象の変更、必須出力の失敗 | 検査未完了として停止し、原因別に再実行 |
| 中断 | キャンセルを記録し、新しい検査の有無を判定 |
| 終了シグナルによる停止 | ジョブ停止の理由と再実行先を記録 |
その他 | 想定外の終了 | ツール障害として停止し、運用担当へ通知 |
0であっても、レポート専用で実行した場合と、重大度の基準を設定して合格した場合では意味が異なります。本番ゲートでは、使用したポリシー、対象コミット、検査範囲を結果と一緒に保存します。単に終了コードがゼロだったという記録だけでは、どの基準を通過したかを後から説明できません。
シェルでの安全な分岐例
シェルでは、失敗時に即終了する設定と、終了コードを取得する処理の順序をそろえます。次はBashで、スキャン失敗をifの条件として受け取り、その後に分岐する例です。
この例は、origin/mainが取得済みで、SCAN_ROOTがリポジトリ外の許可済み領域を指す構成を前提にしています。浅い取得で基準コミットがない場合は、スキャン前にCIのGit取得設定を直します。SCAN_ROOTの存在を調べるだけでなく、対象リポジトリやその親ワークツリーの外にあるかをジョブ作成時にテストします。
パイプでteeへ渡す構成では、取得する終了コードがスキャナーのものかを区別します。また、|| trueを付けてジョブを成功させる方法は、本番ゲートには使いません。レポートのアップロードはスキャンの成功・失敗とは別の後処理にし、アップロード成功をセキュリティ検査の合格と混同しない構成にします。
未完了・中断・再実行の振り分け
終了コード2を受けたジョブは、入力の問題、実行環境の問題、解析の未完了に分類します。同じ設定のまま無制限に再実行せず、原因に対応する修正を一つ加えてから再検査します。
症状 | 担当者の処理 | 再開の条件 |
|---|---|---|
基準コミットや対象パスがない | 開発基盤担当が取得設定と引数を修正 | 対象コミットとパスを解決できる |
認証・接続に失敗 | 認証管理担当がキーや接続許可を調査 | 承認済みの経路で認証できる |
時間・予算・カバレッジの不足 | セキュリティ担当が範囲分割や再検査を判断 | 未検査範囲と次の検査計画が決まる |
新しいコミットによる旧ジョブの取消 | 開発担当が新ジョブへ対応付け | リリース対象コミットの検査が完了する |
出力・エクスポートに失敗 | 基盤担当が保存先と容量を修正 | 必要な結果と状態を保存できる |
中断されたジョブを、新しいジョブがあるという理由だけで合格へ変更しません。リリースするコミットに対応する検査が完了した時点で判定します。外部の停止シグナルでシェルの後処理自体が実行されない構成では、CIサービス側の終了イベントと実行履歴も使い、未完了のまま通知が消える状態を防ぎます。
監視モードから必須ゲートへの移行条件
初期段階は通知のみで観測し、完了率とレビュー体制が安定した対象から必須ゲートへ移します。移行前には、正常完了、ポリシー違反、入力エラー、キャンセルを検証用ジョブで発生させ、分岐先を確かめます。
本番向けの例外は、終了コードを書き換える方法ではなく、期限付きの承認として残します。承認記録には対象コミット、未検査範囲、代替レビュー、承認者、有効期限を含めます。緊急修正で検査を待てない場合も、セキュリティ担当が代替手順を承認し、リリース後の再検査チケットを同時に作成します。日常的に例外が増える場合は、ゲートの対象や処理時間を見直し、担当者が毎回迂回する設計を放置しません。
▶ 関連記事: Claude Enterprise認証管理 完全ガイド｜Enterprise-Managed AuthorizationによるMCPガバナンス
▲ CI/CDにおけるCodex Security CLIの終了コードに応じた処理とリリース判定フロー。
情シスが確認すべき5つの統制ポイント
情シスは、利用者、実行環境、外部送信、保存レポート、CI判定を対応付け、誰がどのコードを処理したか追跡できる状態にします。
シャドーCLIの検知
シャドーCLIは、SaaSの利用者一覧だけでは把握しきれないため、端末、CI、接続先の記録を組み合わせて検知します。インストールの有無と、実際に社内コードへ使った事実も分けて記録します。
端末管理ではnpmパッケージや実行プロセス、CIではワークフローとシークレットの参照、ネットワークでは許可済み接続先を対象にします。短時間だけ起動するnpxやコンテナ内の実行は、常設アプリの一覧に現れない場合があります。利用者、端末、対象リポジトリ、実行時刻、請求先を突合し、個人キーで実行している場合は組織管理の経路へ移します。
検知した利用を一律に不正と扱うのではなく、未申請、承認済みだが台帳未登録、禁止データの処理に分類します。禁止データの送信が疑われる場合は、認証情報の停止とログ保全を先に行います。単なる登録漏れであれば、申請と所有者登録を済ませて継続可否を判断します。
スキャンログの非マスキングリスク
スキャン結果は、コード抜粋や悪用手順を含む機密レポートとして保存します。OpenAIのCodex Securityの公式リポジトリは状態の保存先を環境変数で指定できる構成を案内しており、所見、状態、レポート、ログ、SARIFの保護は自社の機密区分に沿って設計します。
出力は自動マスキング済みとみなさず、共有前に秘密情報と個人情報を点検します。保存先は--output-dirやCODEX_SECURITY_STATE_DIRで管理し、端末のクラウド同期、一般共有フォルダ、公開CI成果物へ流れない構成にします。CLIリファレンスには、OpenAIの認証情報の保存先として$CODEX_SECURITY_STATE_DIR/codex-homeや$CODEX_HOME/state/plugins/codex-security/codex-home配下を使う案内があるため、出力フォルダ以外の保存先も棚卸しします。
保管ルールには、成果物名、機密区分、所有者、閲覧グループ、保存期間、削除担当を記載します。SARIFをコードスキャン画面へ連携する場合は、その画面を閲覧できる人まで対象にします。コード断片を渡せないチケットシステムには、所見ID、重大度、対象コミット、承認済み保管先への参照だけを連携します。
CI/CDにおける未完了コードの遮断
CI管理者は、前節の終了コード表を共通テンプレートへ実装し、各リポジトリが独自に合格条件を緩めない構成にします。必須チェックの名前と、実際に走るジョブを対応付けます。
統制の対象は終了コードだけではありません。対象パスが空だった、基準ブランチを誤った、古いコミットの結果を再利用した、といった状態でも見かけ上の成功が生じます。ジョブは対象コミット、差分の基準、検査範囲、ポリシー設定を成果物へ残し、リリース判定側は現在の変更に対応する結果を使います。設定変更の承認者とコード変更の承認者を分けられる場合は、ゲートの無効化を別レビューにします。
データ送信と保持条件の統制
学習への不使用と、送信データを保存しない契約条件は別々に扱います。OpenAIのEnterprise Privacyは、ビジネス向け製品のデータを既定でモデル学習に使用しない方針を示しています。
保持期間は、学習利用の設定とは別の条件として管理します。適用対象、アカウント、エンドポイント、機能ごとの扱いは、OpenAI APIのデータ管理ドキュメントと契約条件を組み合わせて判断します。ChatGPT認証の利用条件をAPIの条件へ置き換えたり、APIの条件を他のモデルプロバイダーへ広げたりしません。
社内基準が「学習に使わない」である場合：対象サービスの契約と設定がその条件を満たせば、承認したデータ区分で検証します。
社内基準が「保持期間ゼロ」である場合：利用経路がZero Data Retentionの対象に入る場合だけ、その要件のデータを扱います。
処理地域や再委託先にも制約がある場合：契約条件がすべて一致する経路を選び、一致しなければ対象データを除外します。
顧客契約が外部送信を禁止している場合：モデル学習の設定にかかわらず、顧客の承認なしに送信しません。
この判断はリポジトリの所有部門と法務・セキュリティ担当が一度まとめ、利用申請から参照できるようにします。保持条件が合うリポジトリは許可範囲へ登録し、合わないものは除外します。各ジョブの担当者が毎回契約を読み直す運用にはしません。
実行環境の標準化
実行環境は、CLIだけでなくGit設定、実行ファイル、環境変数まで含めて標準化します。セキュリティポリシーが扱うローカルOS権限やサブプロセスの影響を前提に、専用の実行領域を用意します。
検査用ジョブには、デプロイ用のクラウド認証情報や書き込み権限を渡しません。外部プルリクエストから組織のシークレットへ到達できない構成をテストし、Gitフックやフィルター、PATH上の実行ファイルも管理対象にします。コンテナを使う場合は、ホストの広いディレクトリやソケットを不用意にマウントしません。検査と修正パッチ作成はジョブを分離し、書き込みは承認後の処理にします。
認証設計を他のエージェントと共通化する場合は、Claude Code企業利用の統制ガイド、Claudeの解説記事、Claude Enterprise認証管理ガイドの管理項目も比較できます。MCPやAPIでIssue管理やクラウドへ接続する場合は、MCP企業導入の完全ガイドと照らし、接続先ごとに最小権限と失効手順を設定します。
▶ 関連記事: ChatGPT Work・Gemini Spark・Claude Cowork徹底比較｜情シスが押さえる選定基準と統制ポイント
SAST・SCAとの比較と多層防御の構成
既知脆弱性と定型的なコード検査を先に実行し、文脈を伴う高リスクな変更をAI推論型で分析する順序にします。
検査方式ごとの担当領域
SCA、SAST、AI推論型は、製品名ではなく検査対象で比較します。複数機能を持つ製品もあるため、導入済みの機能と有効化している検査を分けて表へ記入します。
比較軸 | SCA | SAST | AI推論型 |
|---|---|---|---|
主な対象 | 依存ライブラリとパッケージ | ソースコードの構文・データフロー | コード、差分、設計資料の文脈 |
主な用途 | 既知脆弱性、影響版、更新候補の管理 | ルールに基づく危険な処理の検出 | 攻撃経路の分析、所見の検証、修正支援 |
人が補う範囲 | 実際の利用箇所と業務影響 | 仕様上の許可・禁止や例外 | 結果の妥当性と網羅性の判断 |
実行の配置例 | 依存関係変更時と定期検査 | コミット・プルリクエスト | 前段通過後の差分や高リスク領域 |
費用評価の単位 | 契約対象、リポジトリ、機能 | 契約対象、利用者、解析範囲 | 推論、実行回数、処理時間、レビュー時間 |
代表例 | Snyk Open Source、Dependabot | Semgrep、SonarQube、GitHubのコードスキャン機能 | Codex Security CLI |
表は検査対象ごとに整理した運用上の分類で、各製品の全機能を列挙するものではありません。GitHub Advanced Security、略称GHASのような製品群は、単一のSASTと同一視せず、コードスキャン、秘密情報検出など、実際に使う機能へ分けます。Snykも、ここでは依存関係検査を担うSnyk Open Sourceを例にしています。
料金を比較する場合は、同じリポジトリ数、同じ利用者、同じ検査頻度の条件で見積もります。非公開の法人料金は要問合せとして扱い、無料のCLIと有料サービスをライセンス価格だけで並べません。担当者が所見を確認する時間や、CIが待機する時間も含めて評価します。
重複を減らすパイプライン
多層防御では、各段階の検出結果を別々に保存しつつ、同じ問題を担当者が何度も処理しないようにします。検査を重ねる目的は、レポート件数を増やすことではなく、前段が扱わないリスクを後段で調べることです。
秘密情報検出：コミット前とCIで、キーやトークンの混入を検査します。検出した場合は、追加の外部解析より先に失効と除去へ回します。
依存関係検査：Snyk Open SourceやDependabotなどで、既知CVEと更新候補を管理します。
静的解析：Semgrep、SonarQube、GitHubのコードスキャン機能などで、組織のルールに沿うコード検査を実施します。
AI差分検査：認証・認可、決済、外部公開APIなど、文脈を伴う変更をセキュリティ検査用CLIへ渡します。
人手判定：重大な所見と仕様依存の所見を担当者が確認し、修正または期限付き例外へ振り分けます。
定期全体検査：差分だけでは追いにくい信頼境界や複数サービス間の処理を別枠で評価します。
依存関係の既知脆弱性、たとえばLog4jに関係する問題の管理は、SCAの台帳と更新運用に残します。反対に、組織IDの照合漏れや管理者権限への到達経路は、設計資料を伴う検査と人手レビューへ回します。検査順序を変える場合も、それぞれの担当範囲が空白にならないよう、リリース基準へ記載します。
所見の重複排除と修正管理
検出結果は、ツール固有のIDだけでなく、対象箇所と根本原因で関連付けます。別ツールが同じ問題を報告した場合は、一つの修正チケットに複数の検出元を紐付けます。
チケットには対象コミット、ファイル、問題のあるデータフロー、成立条件、担当サービス、修正期限を記録します。AIが生成した修正案は、そのまま自動マージせず、関連するテストと権限仕様をレビューします。修正後は元の検査と回帰テストを実行し、問題が消えたことと既存機能を壊していないことを別々に判定します。
誤検知の除外も、理由と対象版を残します。「以前も問題なかった」という判断だけで恒久除外すると、仕様変更後も検査されない領域が残ります。例外には所有者と見直し日を付け、認証方式や公開範囲が変わったときは再評価します。検出元ごとの件数は保持しながら、修正件数は重複を除いた単位で数えます。
送信対象と知識ベースの整理
AI推論へ渡す情報は、検査対象に関係するコードと仕様へ絞ります。リポジトリに存在するという理由だけで、顧客データ、運用ログ、過去の障害資料をまとめて知識ベースへ追加しません。
認可検査なら権限表とデータ所有関係、決済検査なら状態遷移と再実行の仕様、公開APIなら入力検証と信頼境界を選びます。資料の中に実データや秘密情報がある場合は、解析に必要な仕様へ書き換えてから登録します。資料を管理する担当がいる場合は更新手順を作り、担当がいない場合はPoCの固定資料として版を保存します。これにより、検出の変化がモデルやコードの変更によるものか、入力資料の差によるものかを追跡できます。
▶ 関連記事: MCP企業導入のセキュリティ完全ガイド｜ガバナンスとリスク対策
▲ 前段の定型検査からAI推論型による文脈分析を経て人手判定に至る多層防御パイプライン。
導入時のデメリットと失敗パターン
導入初期は、費用上限、検査範囲、レポートの共有先、更新手順、実行権限を明示しないと運用が崩れます。
毎回のフルスキャンによる費用増加
すべてのプルリクエストでリポジトリ全体を解析すると、変更と無関係な領域にも処理時間と費用を使います。モノレポでは、対象サービスを分けないまま再実行が重なると、同じ範囲を繰り返し解析します。
費用が想定を超えた場合は、対象の広さ、実行頻度、同時実行数、再実行理由を切り分けます。差分行数だけでなく、追加した設計資料や検証処理の違いも記録します。費用削減のために必要な検査を無条件で飛ばすのではなく、通常差分、高リスク変更、定期全体検査の実行条件を分けます。月次では予算と実費の差を見て、対象選定を調整します。
AI検査だけで合格とする過信
AIのレポートに所見がないことを、システム全体が安全である証明として扱いません。検査対象外のコード、依存関係、IaC、コンテナ、実行時の設定には、別の検査が残ります。
たとえばソースコードの認可処理が正しくても、ストレージの公開設定やCIの権限が過大なら、別経路でデータが漏れるおそれがあります。リリース基準では、コード、依存関係、設定、秘密情報、実行環境の担当を分けます。AI検査を追加する変更と、既存検査を廃止する変更は、同じ承認として処理しません。
所見の文章が詳しい場合も、成立条件、影響範囲、再現性を担当者が検証します。攻撃の再現が必要な場合は隔離環境を使い、本番環境や第三者サービスへ無断で試験しません。修正案が生成された場合は、権限を緩めてエラーを消していないか、入力検証を迂回していないかまでレビューします。
レポート共有による二次漏洩
レポートには、攻撃者が利用できる再現手順やコード断片が含まれるため、通常のビルドログと同じ公開範囲には置きません。JSONやSARIFへ変換しても、内容の機密度は下がりません。
よくある失敗は、レビューを早めるために全文をチャットへ貼る、公開Issueへ添付する、成果物の閲覧権限をリポジトリより広くする、といった操作です。共有先が機密情報を扱える場合は必要な部分だけ渡し、扱えない場合は所見IDと要約に留めます。すでに誤共有した場合は、投稿の削除に加え、閲覧範囲、ダウンロード、キャッシュ、含まれた秘密情報の失効まで事故対応へ含めます。
最新版への自動追随による再現性の低下
CIが毎回異なるCLI版を取得すると、検出結果の変化がコード変更によるものか、ツール変更によるものか分からなくなります。更新は、通常の実行ジョブから分離して検証します。
検証用の変更では、代表的なリポジトリを使い、引数、出力構造、終了コード、所要時間、認証を比較します。JSONを読む後段処理は、必須項目の欠落や形式変更をエラーとして扱い、空の結果を「所見なし」へ変換しません。旧版へ戻す場合も、脆弱性修正を取り消す影響をセキュリティ担当が判断します。最新版か固定版かの二択ではなく、版を固定しながら定期的に更新する計画にします。
個人キーと過大権限による被害拡大
検査ジョブへ開発者個人のキーやデプロイ権限を渡すと、退職時の停止、費用分離、事故時の影響限定が難しくなります。検査に不要な認証情報は、ジョブの環境から取り除きます。
OpenAIのCodex Securityのセキュリティポリシーは、スキャンが利用者のローカルアカウント権限で動くことや、Deep Scanのワーカーが隔離されたオフライン環境ではないことなど、ローカル実行環境をセキュリティ上の対象として扱っています。GITHUB_TOKENやクラウド認証情報が存在する環境では、それらを検査処理へ引き継ぐ理由を一つずつ説明できる状態にします。読み取り検査と書き込み処理を分離できるなら別ジョブへ移し、分離できない場合は、隔離環境で必要最小限の権限だけを発行します。
未完了を放置する通知運用
通知のみのPoCでも、失敗を誰も見ない状態にはしません。リリースを止めない設定と、未完了を記録しない設定は別です。
通知には、対象コミット、終了状態、再実行の担当、期限を含めます。脆弱性のレビュー通知と、認証切れやタイムアウトの運用通知を同じチャンネルへ大量に流すと、担当者が対応を選べなくなります。セキュリティ担当は所見、開発基盤担当は実行障害、リポジトリ所有者は対象範囲を担当する形で振り分けます。未完了が一定期間残る場合は、PoCの対象を広げず、まず原因を解消します。
導入可否の判断と4週間のPoC計画
PoCは社員数ではなく、データ区分、CIの共通化、認証管理、レビュー担当の有無に合わせて設計します。
運用体制による開始範囲の選定
導入範囲は、対象を管理できる担当者と、検査後に行動できる体制から決めます。企業規模だけでリポジトリ数や必須機能を割り当てる方法は使いません。
現在の体制 | 開始方法 | 先に整える項目 | 拡大の条件 |
|---|---|---|---|
CIがなく、担当者が手動レビュー | 管理端末で固定対象を手動検査 | 実行記録、保存先、所見の担当 | 同じ手順を別の担当者が再現できる |
複数チームが独自CIを運用 | 代表的なCIで監視モード | 認証、出力、終了コードの共通化 | 共通テンプレートを維持できる |
共通CIとセキュリティ担当が存在 | 高リスク変更の差分検査 | レビュー期限、例外承認、費用配賦 | 未完了と所見を期限内に処理できる |
顧客契約や処理地域の制約が強い | 承認済みデータだけを隔離検証 | 契約、送信経路、保持、再委託先 | 対象データの処理条件がすべて一致する |
複数チームへ広げる場合は、件数の多いチームだけを選ばず、実行環境やコード構成が異なる対象も含めます。モノレポ、複数言語、外部プルリクエストなどの条件を代表対象へ入れると、展開後に初めて例外が発生する状況を減らせます。対象を増やす前に、結果を処理する担当者の稼働を確保します。
4週間の実行タイムライン
PoCでは、環境準備、並行検査、CI分岐、継続判断を週ごとに分けます。次は社内検証の計画例で、製品の導入期間を保証するものではありません。
期間 | 主担当 | 実施内容 | 週末の成果物 |
|---|---|---|---|
第1週 | 情シス・リポジトリ所有者 | 対象、認証、送信範囲、予算、保存先を設定 | 対象台帳と承認記録、環境定義 |
第2週 | 開発・セキュリティ担当 | 同じ差分をSCA、SAST、AI検査へ投入 | 重複・追加検出・誤検知の評価票 |
第3週 | 開発基盤担当 | 成功、違反、未完了、中断と後処理を試験 | CIの分岐テストと通知の記録 |
第4週 | 開発責任者・情シス | 効果、費用、待ち時間、運用負荷を集計 | 継続、対象限定、延期の判断書 |
第1週に契約条件が整わない場合は、準備済みの公開OSSや検証用コードを使い、社内機密コードの投入を待ちます。第2週は新しい問題だけでなく、過去に修正した問題を許可済みの環境で再現し、検出できるかを試します。第3週は意図的なエラーを使って通知先まで確かめます。第4週には、担当者が処理できない量の所見が出た場合も含めて、次の対象範囲を決めます。
再利用できる評価票
評価票は、検査1回の記録と、問題1件の記録を分けます。一つのスキャンが多数の所見を出すため、両者を同じ行だけで管理すると完了率や重複数を誤って集計します。
実行の記録：リポジトリ、コミット、基準コミット、対象パス、CLI版、OS、認証経路、開始・終了時刻、終了コード、推定費用を記載します。
所見の記録：検出元、所見ID、根本原因、重大度、再現可否、既存検査との重複、誤検知理由、修正担当を記載します。
レビューの記録：初回確認時間、確定までの時間、修正チケット、例外承認、再検査結果を記載します。
情報管理の記録：送信対象のデータ区分、成果物の保管先、閲覧グループ、保存期限、削除結果を記載します。
モデルや設定を変更した場合は、その前後を別の条件として集計します。途中から設計資料を追加した実行を、資料なしの実行とまとめて平均しません。費用が増えた代わりに確定所見が増えたのか、単に対象が広がったのかを、条件ごとに判断します。
効果測定の計算例
評価では、追加検出、完了率、レビュー負荷を同時に見ます。以下は計算方法を示す仮定例で、実在する企業の結果や、このCLIの検出性能を示す数値ではありません。
対象50回のうち45回が完了し、5回が未完了なら、初回完了率は90％です。AI検査が出した12件のうち、既存検査との重複が4件、誤検知が3件、追加で確定した問題が5件なら、追加の確定所見は5件として数えます。未完了5回を分母から外して完了率を高く見せたり、12件すべてを新しい脆弱性として数えたりしません。
費用評価では、推論費用に担当者のレビュー時間を足します。追加の確定所見が得られても、低リスク変更のレビュー待ちが大きい場合は、高リスク領域へ対象を絞ります。完了率が低い場合は全社展開より実行環境の改善を先に行い、追加検出が少ない場合は設計資料や対象選定が適切かを見直します。事前に成功条件を合意し、結果を見てから都合のよい指標へ変更しません。
本番移行前のチェックリスト
本番移行は、次の項目を担当者が証跡付きで説明できる対象だけに限定します。未完了の項目が残る場合は、その項目を解消する作業と所有者を決めます。
利用者、認証情報、請求先、リポジトリ所有者が台帳で対応しています。
契約上の送信・保持条件と、対象データの区分が一致しています。
CLIと依存関係を再現でき、更新と差し戻しの手順があります。
対象コミット、差分、ポリシー、検査状態を結果と一緒に保存できます。
終了コード別の分岐、通知先、再実行担当を試験しています。
レポートの閲覧者、保存期間、削除処理を設定しています。
重大な所見をレビューする担当者と期限を割り当てています。
緊急時の例外承認と、代替レビューの記録方法があります。
すべてそろった対象は、監視モードから限定的な必須ゲートへ移します。データ条件が合わない対象は解析対象から外し、運用条件だけが未整備の対象は監視を継続します。継続判断には、次の見直し日と停止条件も書き込みます。
ID・端末・SaaS管理の役割分担
利用の可視化は、一つの管理製品だけで完結させず、ID、端末、CI、SaaSの記録を分担します。どの経路が見えるかを先に整理してから、追加する管理手段を選びます。
IDaaS連携は組織アカウントの認証と失効、端末管理はCLIやプロセス、CI管理はジョブとシークレット、SaaS管理ツールは対応サービスのアカウントや連携状況を担当します。マネーフォワード Adminaを含むSaaS管理ツールを比較する場合も、CLIプロセスを直接検知できるか、APIキー利用を追えるか、既存のIDaaSと記録を突合できるかを同じ条件で評価します。OAuth連携が見えることを、すべてのCLI利用が見えることへ読み替えません。
既存ツールで利用者と対象ジョブを追える場合は、その記録を台帳へ集約します。追えない経路が残る場合に、端末監査や接続ログなどの追加手段を検討します。管理製品の追加より先に、何を検知したいのか、誰が対応するのか、何日分を保持するのかを決めます。
まとめ
Codex Security CLI運用の最初の一歩
通常版でコードを作成・変更し、セキュリティ検査用CLIで検出・検証を行う場合は、権限と成果物を分けます。最初の作業として、リポジトリ所有者と情シスで検証対象を一つ選び、認証、送信条件、保存先、予算、レビュー担当を台帳に記録します。その後、版を固定した環境で差分スキャンを実行し、既存検査との追加検出と完了状態を記録します。CIへ進む前に、終了コード別の分岐と例外承認まで試験します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
