3行まとめ
最初はコード変更なしでレビューします。
バグ、例外、セキュリティ、運用、テストに分けます。
修正対象と見送りを人間が決めます。
指摘数ではなく、確認できる指摘を重視します。
- Codexに「バグやリスクを指摘して」と頼むなら、最初はread-onlyで、コード変更なしのレビューに限定します。
- 指摘は、バグ、例外ケース、セキュリティ、運用、テスト不足の5分類に分け、全部を同時に直さず優先度を決めます。
- AIレビューはセキュリティ診断の代替ではありません。secretや本番ログを渡さず、人間レビュー、テスト、承認境界と組み合わせます。
本文の事実確認には、Codex permissions、OpenAIの安全運用記事、Codex AGENTS.md guide、OWASP Cheat Sheetを使っています。Xで伸びていた「バグ・例外ケース・セキュリティリスクを先に指摘させる」系の投稿は需要シグナルとして扱い、本文の根拠にはしていません。
この記事でわかること
read-onlyレビューの型を作れます。
指摘を5分類に整理できます。
今直すものと見送るものを分けられます。
修正後の確認観点を固定できます。
AIレビューは人間の判断材料として使います。
- Codexに実装前レビューを頼む時の依頼文
- バグ、例外ケース、セキュリティ、運用、テスト不足の分類
- 直す指摘と見送る指摘の分け方
- 修正前後に必要なテストと再レビュー
- secretや本番ログを渡さないための境界
- AIレビューを過信しないための停止条件
前提知識
- 1対象設定
読む範囲と読まない範囲を決めます。
- 2レビュー
read-onlyで指摘を出します。
- 3分類
指摘を優先度つきで整理します。
- 4修正
選んだ指摘だけ小さく直します。
レビュー段階では、まだファイルを変更しません。
実装前レビューは、コードを書き始める前に壊れやすい場所を見つける作業です。Codexにこの作業を任せると、見落としていた例外ケースやテスト不足を拾えることがあります。一方で、Codexが出す指摘は、重要度が混ざりやすく、誤検知もあります。
大事なのは、Codexに「容赦なく指摘して」と頼むことではありません。対象範囲、変更禁止、分類、優先度、テスト、見送り理由を決めて、レビュー可能な形で出させることです。
実装前レビューと修正作業を分ける
最初のレビューでは、ファイル編集をさせません。Codexには、対象コードの役割、入力、出力、境界条件、例外、権限、外部通信、テスト不足を整理させます。
確認項目
対象ファイル、呼び出し元、公開API、入力値、エラー時の挙動、権限、外部通信、ログ、既存テストを確認します。根拠ファイルがない指摘は、修正対象にしません。
注意点
AIの指摘は、正しそうに見えても誤っていることがあります。指摘をそのまま修正せず、再現条件と影響範囲を確認します。
まずread-onlyでレビューさせる
| 項目 | 内容 | 見方 |
|---|---|---|
| 根拠 | 対象ファイルと行動理由を確認します。 | |
| 再現条件 | どの入力で起きるか見ます。 | |
| 影響 | ユーザー影響や運用影響を分けます。 | |
| テスト | 確認すべきテストを出します。 |
根拠なしの指摘は、修正対象にしません。
実装前レビューはread-onlyで始めます。Codex permissionsでは、filesystemやnetwork、approvalの境界を分けられます。最初からworkspace writeや外部通信を渡す必要はありません。
依頼文の型
まだファイルは変更しないでください。
対象コードについて、潜在的なバグ、例外ケース、セキュリティリスク、
運用リスク、テスト不足を分類して指摘してください。
各指摘には、根拠ファイル、再現条件、影響、優先度、確認すべきテストを付けてください。
secretや本番ログは読まないでください。根拠
read-onlyで始めると、Codexの指摘を人間がレビューしてから、修正対象を絞れます。権限を広げる前に、問題の棚卸しだけを行うのが安全です。
評価基準
指摘に根拠、再現条件、影響、優先度、テストがあるかを見ます。「危険です」だけの指摘は、修正対象にしません。
レビュー対象を狭くする
対象範囲は狭くします。repo全体を一度に見せるより、関数、component、API handler、permission boundary、入力検証のように切ります。
確認項目
レビュー対象、レビューしない対象、参照してよいファイル、読ませないファイル、外部通信の可否を明記します。
注意点
本番ログ、顧客データ、.env、credentials、private key、tokenはレビュー対象に入れません。必要な場合は、ダミーデータや抽象化した再現ケースを使います。
指摘を5分類に分ける
| 項目 | 内容 | 見方 |
|---|---|---|
| バグ | 再現条件と既存テストを見ます。 | |
| 例外ケース | 境界値や失敗系を見ます。 | |
| セキュリティ | 防御観点と認可境界を見ます。 | |
| 運用/テスト | ログ、監視、テスト不足を見ます。 |
分類できない指摘は、内容が曖昧な可能性があります。
Codexの指摘は、そのままだと粒度が混ざります。実務では、分類してから優先度を決めます。
5分類の表
| 分類 | 例 | 最初に見ること |
|---|---|---|
| バグ | off-by-one、null処理漏れ、状態更新漏れ | 再現条件と既存テスト |
| 例外ケース | 0件、空文字、timeout、重複 | 入力境界と期待挙動 |
| セキュリティ | 認可漏れ、入力検証不足、secret露出 | 悪用手順ではなく防御観点 |
| 運用 | ログ不足、監視不能、戻しにくい | 障害時の確認方法 |
| テスト不足 | 境界値、失敗系、権限系がない | 追加すべきテスト |
評価基準
各指摘がどの分類に入るか、人間が判断できることです。分類できない指摘は、内容が曖昧な可能性があります。
注意点
セキュリティ指摘では、攻撃手順を具体化しすぎないようにします。防御、確認、テスト、権限境界の観点で書きます。
優先度を付ける
優先度は、影響範囲、再現性、悪用可能性、修正量、テストの有無で決めます。Codexの主観だけで決めず、人間が確認します。
優先度の目安
P0は本番影響やsecret露出の可能性があるもの。P1はユーザー影響が大きいバグ。P2は条件付きで起きる例外ケース。P3は保守性やテスト不足です。
停止条件
secret露出、認可漏れ、本番データ破壊、課金や決済への影響が疑われる場合は、Codexに修正させる前に人間のセキュリティレビューへ戻します。
直す指摘と見送る指摘を分ける
再現でき、影響が明確で、テストできます。
設計判断や広い修正が必要です。
前提不明や誤検知の可能性があります。
認可、決済、secret、本番データに関わります。
見送り理由も作業ログに残します。
Codexに多くの指摘を出させると、全部直したくなります。しかし、全部を同じPRで直すと大差分になります。直すもの、見送るもの、別タスクにするものを分けます。
修正対象を絞る
最初のPRでは、再現条件があり、影響が明確で、テストを書ける指摘だけを選びます。設計改善や大きなリファクタリングは別タスクにします。
判断表
| 判断 | 条件 |
|---|---|
| 今直す | 再現できる、影響が明確、テストできる |
| 別タスク | 修正範囲が広い、設計判断が必要 |
| 見送る | 影響が小さい、前提が不明、誤検知の可能性 |
| 人間承認 | 認可、決済、secret、本番データに関わる |
注意点
AIが出した指摘をすべて正としないことです。誤検知、過剰防御、仕様誤読が混ざります。
見送り理由を残す
見送る指摘にも価値があります。なぜ見送ったかを残すと、同じ議論を繰り返さずに済みます。
例
「timeout時のretryは今回は見送る。対象APIはidempotentではなく、retry設計に仕様確認が必要なため別タスク化する。」
評価基準
PR descriptionや作業ログに、修正対象、別タスク、見送り、人間承認の分類が残っているかを見ます。
テストと再レビューを固定する
| 項目 | 内容 | 見方 |
|---|---|---|
| 再現テスト | バグが再発しないことを見ます。 | |
| 境界値 | 空、0件、timeout、重複を見ます。 | |
| 認可 | アクセス境界を確認します。 | |
| 未検証 | 確認できない点を残します。 |
再レビューでも、追加修正は勝手に進めません。
実装前レビューの価値は、指摘数ではなく、修正後に確認できることです。Codexに修正させる前に、テストと再レビューの流れを決めます。
テストゲート
npm run lint
npm run typecheck
npm test
npm run test:e2eプロジェクトによってコマンドは違います。大事なのは、指摘分類ごとに必要な確認を決めることです。
確認項目
バグは再現テスト、例外ケースは境界値テスト、セキュリティは認可・入力検証・secret露出なしの確認、運用はログや監視、テスト不足は追加テストを見ます。
注意点
テストがない指摘を無理に直すと、直ったかどうか分かりません。先にテストを書くか、手動確認手順を明記します。
再レビューの型
修正後に、Codexへ再レビューを頼む場合も範囲を絞ります。
今回修正した差分だけを対象に、指摘が解消されたか確認してください。
新しいリスクが増えていないか、実行したテストと未検証項目を確認してください。
まだ追加修正はしないでください。評価基準
再レビューが、元の指摘との対応表になっているかを見ます。新しい大きな改善提案が出ても、同じPRへ混ぜません。
関連
テストゲートと権限境界の考え方は、Claude Codeに依存更新を任せる前の記事でも確認できます。
セキュリティ・コスト注意
envやtokenは渡しません。
本番ログや顧客情報を除外します。
対象ファイルを狭くします。
指摘数を扱える量に絞ります。
AIレビューは、セキュリティ診断の代替ではありません。
AIレビューは便利ですが、セキュリティ診断の代替ではありません。特に認可、認証、決済、個人情報、本番データ、外部通信に関わる箇所は、人間レビューや専門的なセキュリティ確認と組み合わせます。
secretを渡さない
Codexにレビューさせる時、.env、credentials、private key、API token、顧客データ、本番ログは渡しません。必要ならダミー値に置き換えます。
確認項目
読ませるファイル、読ませないファイル、ログの加工、外部通信の可否、MCP toolの権限、保存される作業ログを確認します。
注意点
「レビュー精度を上げるために全部見せる」は危険です。必要最小限のコードと再現情報だけでレビューします。
コストは指摘の整理にも出る
Codexが大量の指摘を出すと、レビュー時間が増えます。指摘数が多いほど良いわけではありません。
評価基準
1回のレビューで扱う指摘は、修正可能な数に絞ります。10件出たら、P0/P1だけ先に扱い、残りは別タスクへ分けます。
改善方法
指摘の出力形式を固定します。分類、優先度、根拠、再現条件、テスト、修正案を表にすると、レビューがしやすくなります。
失敗点とハマりどころ
全部直すと仕様が変わります。
防御観点へ寄せて書きます。
修正とリファクタリングを混ぜます。
直ったか判断できません。
指摘は、分類してから扱います。
実装前レビューの失敗は、Codexの指摘が少ないことより、指摘をそのまま信じることから起きます。
誤検知を全部直す
AIの指摘には誤検知があります。誤検知を全部直すと、コードが複雑になり、仕様が変わることがあります。
セキュリティ指摘を攻撃手順に寄せすぎる
防御目的の記事やレビューでは、悪用手順を具体化しすぎないようにします。確認すべき入力検証、認可、ログ、テストへ寄せます。
修正とリファクタリングが混ざる
リスク指摘の修正と、ついでのリファクタリングを混ぜると、レビューが難しくなります。構造改善は別PRにします。
実務で使うなら
- 1日目
対象範囲と除外情報を決めます。
- 2日目
read-onlyレビューを実行します。
- 3日目
指摘を分類します。
- 4-5日目
P0/P1だけ修正し再レビューします。
最初は指摘数より、扱える運用を作ります。
実務では、Codexにレビュー、分類、優先度、テスト候補を出させ、人間が採用判断をします。最初の目的は、実装速度を上げることではなく、見落としを減らすことです。
1週間の進め方
1日目に対象範囲と読ませない情報を決めます。2日目にread-onlyレビューを実行します。3日目に指摘を分類します。4日目にP0/P1だけ修正します。5日目にテスト、再レビュー、見送り理由を残します。
スコアカード
| 評価軸 | 合格ライン |
|---|---|
| 範囲 | 対象ファイルと除外ファイルが明確 |
| 分類 | バグ、例外、セキュリティ、運用、テスト不足に分かれる |
| 根拠 | 指摘に根拠ファイルと再現条件がある |
| 優先度 | P0/P1/P2/P3の理由がある |
| テスト | 修正前後の確認方法がある |
| 安全性 | secretや本番ログに触れていない |
関連導線
リスク指摘を修正する時に大きな構造変更が必要なら、Codexリファクタリングの記事へ分けます。評価タスク化するなら、AI Coding Benchmark Kitの記事が使えます。
FAQ
根拠と人間レビューが必要です。
分類と再現条件が必要です。
対象を選んでから小さく任せます。
先に再現テストか手順を作ります。
迷ったら、人間が確認できる形へ戻します。
Codexのセキュリティ指摘は信用できますか？
参考にはできますが、診断の代替にはなりません。根拠、再現条件、影響範囲、人間レビュー、テストとセットで扱います。
指摘は多いほど良いですか？
多ければ良いわけではありません。分類、優先度、再現条件がない指摘は、レビュー時間を増やします。
修正までCodexに任せてよいですか？
修正対象を人間が選んだ後なら、小さな差分として任せやすくなります。認可、決済、secret、本番データに関わる場合は人間承認に戻します。
既存テストが少ない場合はどうしますか？
先に再現テストや手動確認手順を作ります。テストなしで修正すると、直ったかどうか判断できません。
更新履歴
- 2026年5月31日
Codex permissions、Running Codex safely、AGENTS.md guide、OWASP Cheat Sheetを確認して初版を作成しました。
実務導入時には最新の公式情報を確認してください。
2026年5月31日 JSTに、Codex permissions、Running Codex safely、Codex AGENTS.md guide、OWASP Cheat Sheetを確認して初版を作成しました。セキュリティ関連情報は更新されやすいため、実務導入時には最新の公式情報を確認してください。