Codex Security は「正しい挙動」と「確かめ方」を先に渡す
OpenAI DevDay Exchange Tokyo（2026-10-20）での Codex Security の使い方のコツ。「脆弱性を見て」だけではうまくいかない。アプリの仕様や正しい挙動を先に定義して渡し、直したあとに他の箇所が壊れていないかを確かめるプロンプトも一緒に渡す。
どんな場面で使う？
- Codex Security（クラウドでも CLI でも使える）でリポジトリの脆弱性スキャンと修正を回すとき
- AI のレビューやスキャンで大量の指摘が出て、どれから手を付けるか迷うとき
手順
- 仕様を先に渡す: 誰が何をできるべきか（権限）、入力の許容範囲、外部に出してよいデータなど「正しい挙動」を短く書いて渡し、今の実装がそれに合っているかを検証させる
- 修正には検証の指示を添える: 「修正したら、攻撃経路を再現して塞がったことを確かめ、関連する他の箇所がデグレしていないか、通常の操作が正しく動くかまで確かめて」と渡す
- 指摘を整理させる: 検出結果のラベリング・分類を任せる。自分で数えるなら「構造的な欠陥」と「端のケースの不具合」に分けて数える欄を最初から作っておくと、何に時間を使うか決めやすい（PostgreSQL 19 で LLM レビュー由来の指摘が約40件に積み上がり、機能を差し戻した事例からの教訓）
- 一度で終わらせない: 脆弱性は新しく生まれるので、スキャンと修正を継続して回す。公表が日本時間の夜中でも気づけるよう、検知は自動化しておく。直してもマージ・反映までに時間がかかる点にも注意
注意点
- 発表スライドの内容を参加者がまとめた投稿が元。具体的な設定画面やプロンプト全文はスライド画像側にあり、ここでは要点だけを書いている
- 権限まわり（認可）の不具合は今も影響の大きいバグの多くを占める、という GitHub の研究者の話もある。仕様に「誰が何をできるか」を必ず入れる
- 関連: Claude Code チームのコードレビュー運用を自分のチームに入れる（REVIEW.md・リスク階層・ラウンド上限）