AIが脆弱性を見つけて直す時代へ — OpenAI Codex Security の仕組みと実践的な向き合い方
はじめに — 「誰がセキュリティを見るのか」という問い
Vibe Codingという言葉がエンジニアリングの世界に定着してしばらく経ちます。Claude CodeやCursor、GitHub Copilotといったツールを使えば、数百行のコードを数分で生成できる。それ自体はすごいことだし、開発速度が上がっているのは事実です。
ただ、ちょっと考えてみましょう。
コードが 10 倍のスピードで増えているとき、セキュリティレビューも同じ速度で追いついているでしょうか。正直に言いましょう — 追いついていないことが多いと思います。AI が書いたコードだから安全ということにはならないし、むしろ「なんとなく動いている」コードが大量に積み重なっていく状況は、それ自体がリスクになり得ます。
2026 年 3 月 6 日、OpenAI はこの問いに対して一つの答えを出しました。アプリケーションセキュリティエージェント 「Codex Security」 のリサーチプレビュー版です。
Codex Security は、ソフトウェアのコードを分析して脆弱性を検出し、検証し、修正パッチの提案までを自律的に行うエージェントです。コードを書く AI がいるなら、セキュリティを見る AI もいる。そういう時代になってきたということです。
この記事では、Codex Security の仕組み、実績数値の読み方、実際に類似の仕組みを理解するためのコード例まで、丁寧に解説していきます。「リサーチプレビューだからまだ関係ない」と思っている人にも、セキュリティとAIの関係性について考えるきっかけになればと思います。
第1章: 従来のセキュリティツールに何が足りなかったのか
セキュリティの話をするとき、まず多くのエンジニアが思い浮かべるのは静的解析ツールではないかと思います。Python なら Bandit 、JavaScript なら ESLint のセキュリティプラグイン 、そして汎用的なものとして Semgrep や SonarQube などが代表的です。
これらのツールは確かに役に立ちます。パターンマッチングで既知の脆弱性パターンを検出してくれるし、CI/CD パイプラインに組み込めば自動でチェックも走ります。
ただ、現場でこれらのツールを実際に使ったことがある人は、おそらくこんな経験をしているのではないかと思います。
「1000 件のアラートが出た。でも、そのほとんどは自分たちのユースケースでは問題ない。どれが本当に重要なのかわからない...」
これがいわゆる「アラート疲れ」です。ルールベースの静的解析は、コードの文脈を読みません。「eval() を使っている = 危険」というルールがあれば、内部ツールのスクリプトでも本番 API でも関係なく同じアラートを出します。
たとえば、こんな状況を想像してみましょう。
# 内部管理ツールの設定ファイル読み込み（管理者のみアクセス可能な環境）
import ast
config = ast.literal_eval(config_string) # eval ではなく literal_eval を使っているのに警告が出るケースも
コンテキストを無視したツールは「eval 系の関数を使っている」という事実だけを見て警告します。でも実際の影響度は環境や設計によって全然違う。誰がこのコードを実行できるのか、そのデータはどこから来るのか——そういう「文脈」を読めないと、本当に危ない脆弱性が大量のノイズに埋もれてしまいます。
もう一つの問題として、AI が生成したコードへの対応 があります。AI が書くコードは、既存のパターンにとらわれない構造になることがあります。新しいフレームワーク、複雑な依存関係、特殊なデータフロー——こういった場合、既存のルールセットでは検出できない脆弱性が生まれることがあります。
Codex Security が目指しているのは、まさにこの「文脈を読む」というところです。ルールの照合ではなく、システム全体を理解した上で「ここが本当にやばい」という判断をする。そのアプローチが、従来ツールとの根本的な違いです。
第2章: Codex Securityの3段階動作フロー
Codex Security の動作は、3 つのステップで構成されています。これを順に見ていきましょう。
Step 1: リポジトリ解析 → 編集可能な脅威モデルの生成
最初に Codex Security がやることは、リポジトリ全体を解析することです。単純にファイルを読むのではなく、「このシステムは何をするシステムで、どんな信頼関係があって、どこが攻撃面になるのか」 を整理した「脅威モデル」を生成します。
脅威モデルという言葉は難しく聞こえるかもしれませんが、イメージとしては「コードの設計図から作るリスクマップ」です。このシステムに外部から入ってくるデータはどこか。認証はどこで行われているか。データベースやファイルへのアクセスはどこで発生するか——そういった情報を整理したものです。
重要なのは、この脅威モデルが 編集可能 であるという点です。AI が自動生成したモデルが実態と合っていない場合、人間が修正できます。「このエンドポイントは内部向けなので外部からのアクセスは考慮不要」といった調整ができます。このフィードバックが積み重なることで、次回以降の精度が向上していく仕組みになっています。
Step 2: 脅威モデルベースの脆弱性探索とサンドボックス検証
脅威モデルができたら、次はそれをコンテキストとして使いながら脆弱性を探索します。「このシステムの攻撃面から考えると、ここに SQL インジェクションのリスクがある」というように、システム固有の文脈に基づいた探索になります。
さらに、検出した脆弱性はサンドボックス化された環境で検証されます。「本当にこれは悪用可能なのか」を実際に確認することで、誤検知を削減します。ルールベースのツールが「パターンが一致したから警告」を出すのとは異なり、「実際に問題になるかどうか」を確かめてから報告するアプローチです。
検出結果は実際の影響度に基づいて優先順位付けされます。クリティカルなものと低リスクなものを分けて提示してくれるので、エンジニアは本当に重要な問題に集中できます。
Step 3: システムの意図と整合するパッチ案の提示
最後のステップが、修正パッチの提案です。ここで重要なのは 「システムの設計意図と整合するパッチ」 を提案するという点です。
たとえば、ある認証の脆弱性を修正するとき、単純にトークン検証を追加するだけでは既存の設計と噛み合わないことがあります。Codex Security は、システム全体を理解した上で「この修正を入れると、このフローにどう影響するか」を考慮したパッチを提案します。
もちろん、最終的な適用判断はエンジニアが行います。Codex Security が提示するのはあくまで「提案」であり、承認フローを経てから適用するという設計になっています。「AI が勝手にコードを変更した」ということにはなりません。
第3章: 実績数値を正直に読む
OpenAI は Codex Security について、いくつかの具体的な数値を公開しています。ここでは、その数値を少し慎重に読んでみましょう。
公開されている数値
| 指標 | 改善値 |
|---|---|
| 不要なアラート（ノイズ）の削減 | 84%削減 |
| 重大度の過大評価の削減 | 90%以上削減 |
| 誤検知率の低下 | 50%以上低下 |
| 直近30日間のスキャンコミット数 | 120万件以上 |
| 重大問題があったコミットの割合 | 0.1%未満 |
| 発見・報告したOSSの重大脆弱性 | 14件のCVE |
数値としては非常に印象的です。ただ、いくつかの点で注意が必要だと思います。
まず、これは OpenAI 社内での導入事例と、プライベートベータ参加者のデータに基づいています。 自社製品の評価を自社が公開している数値なので、独立した第三者による検証ではありません。これは Codex Security に限らず、多くのツールの自己評価に共通する注意事項です。
次に、「84%削減」という数値は、特定のリポジトリでの結果です。 全てのリポジトリで同様の結果が得られるとは限らない。プロジェクトの構造や技術スタック、既存のセキュリティ設定によって、効果は大きく変わる可能性があります。
それを踏まえた上でも、「重大問題があったのはスキャンコミット全体の 0.1% 未満」 というデータは興味深いです。これは「ほとんどのコードは問題ない」という安心感ではなく、「120 万件のコミットの中から本当に重要な問題を絞り込める」という精度の高さを示しています。大量のコードから本質的なリスクだけを抽出できる、という方向性は正しいと思います。
OSS 支援の実績も注目に値します。OpenSSH、PHP、Chromium といったインフラの根幹を担うプロジェクトに 14 件の CVE を発見・報告したということは、Codex Security が実際の高難度ケースでも機能していることを示しています。
リサーチプレビューという現実
現時点では、Codex Security は ChatGPT Enterprise / Business / Edu のユーザー向けに、Codex Web 経由で段階的に展開中です。個人向けプランや API 単体では利用できません。
「自分のプロジェクトで今すぐ使える」という状況ではないことは、正直に伝えておきたいと思います。ただ、方向性を理解しておくことは、近い将来に向けた準備になります。
第4章: Pythonで類似の仕組みを理解する
Codex Security 自体はまだ限られた環境でしか使えませんが、「コード脆弱性の自動検出」という概念を Python で手元で試してみることはできます。いくつかのアプローチを紹介します。
4-1: Bandit による基本的な静的解析
まず、Python の代表的なセキュリティチェッカーである Bandit を使ってみましょう。
# インストール
pip install bandit
# スキャン（レポートをJSON形式で出力）
bandit -r ./your_project -f json -o bandit_report.json
# 高・中リスクのみ表示
bandit -r ./your_project -ll
# bandit_report.json を読んで重要なものだけ抽出する例
import json
def filter_high_severity(report_path: str) -> list[dict]:
"""高・中重大度の脆弱性のみ抽出する"""
with open(report_path) as f:
report = json.load(f)
results = report.get("results", [])
# 重大度 HIGH / MEDIUM かつ 信頼度 HIGH のものだけ
filtered = [
r for r in results
if r["issue_severity"] in ("HIGH", "MEDIUM")
and r["issue_confidence"] == "HIGH"
]
return filtered
issues = filter_high_severity("bandit_report.json")
for issue in issues:
print(f"[{issue['issue_severity']}] {issue['filename']}:{issue['line_number']}")
print(f" {issue['issue_text']}")
print()
Bandit は便利ですが、前述のようにコンテキストを読みません。出力されたアラートをそのまま鵜呑みにするのではなく、フィルタリングしながら使うことが現実的なアプローチです。
4-2: Semgrep でカスタムルールを作る
Semgrep はルールを自分で書けるのが強みです。プロジェクト固有のリスクパターンをルールとして定義できます。
# インストール
pip install semgrep
# 既存のルールセットでスキャン
semgrep --config=p/python ./your_project
# カスタムルールでスキャン
semgrep --config=./security_rules.yml ./your_project
# security_rules.yml: カスタムルールの例
rules:
- id: raw-sql-format-string
patterns:
- pattern: |
$CURSOR.execute("..." % $USER_INPUT)
- pattern: |
$CURSOR.execute(f"...{$USER_INPUT}...")
message: |
SQLクエリにユーザー入力を直接フォーマットしています。
パラメータバインディングを使用してください。
languages: [python]
severity: ERROR
- id: hardcoded-secret-pattern
patterns:
- pattern: |
$VAR = "...password..."
- pattern: |
$VAR = "...secret..."
message: |
ハードコードされた認証情報の可能性があります。
環境変数または秘密管理ツールを使用してください。
languages: [python]
severity: WARNING
4-3: LLM を使った「文脈付き脆弱性チェック」の概念
Codex Security の核心は「コンテキストを理解する」という点でした。LLM を組み合わせることで、静的解析ツールの結果に文脈を加えるアプローチが考えられます。
import json
import subprocess
from openai import OpenAI
client = OpenAI()
def analyze_security_with_context(
file_path: str,
project_description: str
) -> str:
"""
Bandit の結果と LLM を組み合わせて、
プロジェクト固有の文脈でリスクを評価する
"""
# Step 1: Bandit でスキャン
result = subprocess.run(
["bandit", "-r", file_path, "-f", "json"],
capture_output=True,
text=True
)
bandit_output = json.loads(result.stdout) if result.stdout else {"results": []}
# Step 2: LLM に文脈を加えて評価してもらう
issues_summary = "\n".join([
f"- {r['issue_severity']}: {r['issue_text']} ({r['filename']}:{r['line_number']})"
for r in bandit_output.get("results", [])
])
if not issues_summary:
return "Banditによる検出結果はありません。"
prompt = f"""
以下はPythonプロジェクトのセキュリティスキャン結果です。
## プロジェクトの概要
{project_description}
## 検出された問題
{issues_summary}
このプロジェクトのコンテキストを踏まえ、以下を評価してください：
1. 本当に対処が必要な問題はどれか（優先度: 高/中/低）
2. プロジェクトの性質上、無視できる問題はどれか
3. 最も早急に修正すべき問題とその修正方針
簡潔かつ実践的に答えてください。
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
return response.choices[0].message.content
# 使用例
if __name__ == "__main__":
analysis = analyze_security_with_context(
file_path="./src",
project_description=(
"社内向け管理ツール。外部インターネットからはアクセス不可。"
"利用者は全員社員で、管理者権限で動作する。"
"PostgreSQLに接続してレポートを生成する。"
)
)
print(analysis)
このコードは概念的なものです。実際の運用では、ファイルの読み込みやプロンプトの最適化が必要になります。ただ、「静的解析の結果をそのまま使う」のではなく「プロジェクトの文脈を加えて評価する」という Codex Security の考え方を手元で試す出発点になります。
4-4: CI/CD への組み込みイメージ
本番では、こういったチェックを GitHub Actions などに組み込むのが現実的です。
# .github/workflows/security-check.yml
name: Security Check
on:
pull_request:
branches: [main, develop]
jobs:
bandit-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: "3.12"
- name: Install Bandit
run: pip install bandit
- name: Run Bandit
run: |
bandit -r ./src \
-ll \
-f json \
-o bandit-results.json || true
- name: Parse and filter results
run: |
python3 - << 'EOF'
import json, sys
with open("bandit-results.json") as f:
report = json.load(f)
# HIGH severity のみ失敗扱いにする
high_issues = [
r for r in report.get("results", [])
if r["issue_severity"] == "HIGH"
]
if high_issues:
print(f"高重大度の問題が {len(high_issues)} 件見つかりました:")
for issue in high_issues:
print(f" [{issue['filename']}:{issue['line_number']}] {issue['issue_text']}")
sys.exit(1)
else:
print("高重大度の問題は見つかりませんでした。")
EOF
「全ての Warning で PR をブロックする」のではなく、「HIGH severity だけを失敗扱いにする」というアプローチが、アラート疲れを防ぎながらセキュリティを担保する現実的な方法だと思います。
第5章: 誰が使えて、どう試せるのか
2026 年 3 月時点での Codex Security の利用状況を整理しておきましょう。
現在使えるユーザー
| プラン | Codex Security |
|---|---|
| ChatGPT Pro（個人） | 利用可能（Codex Web 経由） |
| ChatGPT Enterprise | 利用可能（段階的展開中） |
| ChatGPT Business | 利用可能（段階的展開中） |
| ChatGPT Edu | 利用可能（段階的展開中） |
| OpenAI API 単体 | 現時点では非対応 |
最初の 1 ヶ月は無料で利用できます。
Codex for OSS
OpenAI は Codex for OSS という枠組みも立ち上げています。オープンソースのメンテナーに対して、ChatGPT Pro / Plus の無料アカウントと Codex Security を提供し、依存度の高い OSS のセキュリティ改善を支援するプログラムです。
OpenSSH や PHP、Chromium といった多くのシステムが依存するプロジェクトに対して、すでに 14 件の CVE 発見・報告を行っています。
個人・スタートアップへの今後
現時点では Enterprise 向けが中心ですが、Codex Security のアプローチが証明されれば、より広いユーザーへの展開も考えられます。
現状では「仕組みを理解しておく」「代替ツールを整備しておく」という準備期間として活用するのが現実的だと思います。前章で紹介した Bandit + Semgrep + LLM の組み合わせは、Codex Security が広く使えるようになるまでの橋渡しになるはずです。
おわりに — セキュリティとAIの「協働」について
Codex Security の登場が示しているのは、「AIがセキュリティを担当する」という単純な話ではないと思います。
AIはコードレビューの 「目」 になる。大量のコードの中から本当に重要な問題を見つけ出し、優先順位をつけて提示する。修正案を提案する。でも最終的な判断は、システムを知っているエンジニアがする。
これは、今まで「誰かがやらなければいけないけど、時間がなくてできていなかった」ことを、AI が肩代わりしてくれるということです。セキュリティの専門チームがいない個人開発者やスタートアップにとって、AI が 24 時間自動でセキュリティレビューをしてくれる世界は、決して小さな変化ではありません。
「AIが書いたコードをAIがレビューする」という構図は、少し不思議に見えるかもしれません。でも考えてみれば、人間だって自分が書いたコードを自分でレビューすることはあります。大事なのは、見落としを減らすための仕組みが存在しているかどうかです。
コードの量が増えれば、セキュリティのリスクも増えます。その増加スピードに対応するために、AI をセキュリティの目として活用していく方向性は、自然な流れだと思います。
Codex Security がどれだけ普及するかはまだわかりません。ただ、「コンテキストを読んでセキュリティを評価する」というアプローチは、方向性として正しいと感じています。
今日からできることとして、手元のプロジェクトに Bandit や Semgrep を導入してみることをおすすめします。ノイズとの戦いにはなりますが、「セキュリティを継続的に見る」という習慣を作っておくことは、Codex Security が広く使えるようになったときに、その恩恵を最大限に受けるための準備になるはずです。
まとめ
| ポイント | 内容 |
|---|---|
| Codex Security とは | AI が脆弱性検出・検証・修正提案を行うエージェント（2026/3/6 リサーチプレビュー公開） |
| 従来との違い | ルールベースではなく「コンテキストを読む」文脈依存の評価 |
| 3段階フロー | 脅威モデル生成 → 脆弱性探索・サンドボックス検証 → パッチ提案 |
| 実績数値 | ノイズ84%削減、誤検知50%以上低下、14件のOSS CVE発見 |
| 現在の利用対象 | ChatGPT Enterprise / Business / Edu（個人向けは段階的展開中） |
| 今日からできること | Bandit + Semgrep の導入、CI/CD への組み込み |
AI が書くコードの量が増える時代に、AI がセキュリティの目になる。この流れを理解しておくことは、これからのエンジニアリングにとって重要だと感じています。