OpenAIが4月末に投入していた「automatic reviewer agent（自動レビュアーエージェント）」が、5月の更新でCodex CLIにも展開された。Codexがツールを叩く前に発生する承認プロンプトを、別のエージェントが構成済みポリシーに従って自動審査する仕組みで、「人間が画面に張り付いていなくても、雑な権限拡張だけは弾かれる」という安全網を組めるようになった。Codexを長時間任せたい開発者にとっては、半年以上くすぶっていた不満が現実的に解消する更新といえる。
自動レビュアーは「ツール実行の前に立つ門番」
機能の本質は、Codexがツールを実行する前に挟まる承認プロンプトを別のエージェントに通すことだ。レビュアーは構成済みの審査ポリシーに基づき、その実行を承認するか、拒否するか、停止するか、タイムアウトさせるかを判定する。要するに、ツール実行の前に立つ門番が一段増えた格好になる。
Codexアプリでは、レビュー結果が「Reviewing / Approved / Denied / Aborted / Timed out」の状態として可視化される。さらに、リスクレベルと、要求された操作のユーザー権限評価が併記される。これにより「権限的にやって良い操作なのか」を、人間が毎回判定する必要がなくなる。地味だが、長時間タスクではここが詰まりやすい。
既存の権限設計との関係を整理する
ここは用語が混乱しやすい。Codexにはもともと「permissions selector（権限セレクター）」があり、承認モードとして「都度確認 / 完全許可 / 拒否」を選んでいた。自動レビュアーの追加によって、ここに「automatic review（自動審査）」という選択肢が増えた格好になる。完全許可ではない、しかし都度確認でもない、中間状態を作れるようになったわけだ。
注意すべきは、サンドボックスの境界自体は変わらないという点だ。レビュアーが許可したからといって、Codexがサンドボックスの外に出ることはない。これは公式ドキュメントでも明示されている。逆に、サンドボックス内の操作を「人間に聞かずに通す」かどうかが、レビュアーポリシー側の問題になる。この2層を混同するとセキュリティ設計が崩れる。
検証ログ：承認プロンプトが7回から2回へ
筆者の手元では、Next.jsフロント+FastAPIバックエンドの社内ツールで検証した。Codex CLIに「ローカルサーバーを立てて、フォームのバリデーションを修正してテストまで通す」と指示し、自動レビュアー有無で比較したログが以下である。
- 自動レビュアー無効：承認プロンプトが7回、画面に張り付いていた時間は約12分
- 自動レビュアー有効：承認プロンプトが2回（本番URLを叩こうとした瞬間と、
.envを消そうとした瞬間）、所要22分のうち手を動かした時間は約3分
レビュアーが自動承認した5件の中身は、ローカルの読み取り操作とテストスクリプト実行が4件、tmp/配下の一時ファイル削除が1件だった。残りの2件、本番URLアクセスと.env削除は、レビュアーが「リスク高」と判定して人間に上げた。ポリシーに従った妥当な挙動である。
「人間が判定すべき決定」が、本当に人間が見るべきものだけに絞られる感覚がある。半自動承認としては実用的な水準に達したと判断していい。
落とし穴：ポリシーが緩ければレビュアーはザル化する
ただし楽観は禁物だ。自動レビュアーは「ポリシーに従う」だけで、ポリシーが緩ければ当然ザル化する。試しに「テスト環境のDB操作は無条件で許可」というポリシーを書いたところ、Codexは盛大にテストDBを書き換えた。これは想定通りの挙動なのだが、本番にも同じスキーマがあるシステムでは、テストでやらかした内容が本番に展開される導線が残る。「テスト環境だから安全」は文脈依存である。
OpenAIのドキュメントはレビュー対象を「sandbox boundaryは変えない」と明記している。サンドボックスの外には出ない、これは安心材料だ。しかしサンドボックスの中で何が起きるかは、ポリシー次第になる。レビュアー導入後、最初の1週間は「許可した内容」のログを毎晩眺めて、無意識に許してしまっている操作を炙り出す運用を推奨したい。筆者はこれで3つ、緩すぎる許可を見つけて引き締めた。
推奨アクション
- Codex CLIを最新版に更新し、permissions selectorで「automatic review」を選択可能にしておく
- 最初は厳しめのポリシーから始め、自動承認ログを毎日確認して緩めるかどうかを判定する
- 本番ドメイン・
.env系・破壊的なDB操作は明示的に「人間に上げる」分類へ固定する - サンドボックス境界とレビュアーポリシーは別レイヤである、という整理をチームで共有する
チーム導入で効くタイプの機能
Codexのこの構成は、「外注先に作業を投げて、PRをレビューエージェントが見て、明らかにヤバいやつだけ人間に上げる」という組織的な開発プロセスを、ツール内に閉じ込めた格好になっている。逆に言えば、レビュアーポリシーが組織のセキュリティ基準と合っていないと、ツールが便利な事故装置になる。個人開発よりも、チーム導入時に効くタイプの機能だと見ていい。
エージェント運用の最後の壁は、ポリシーの記述能力そのものだ。レビュアーログをSlack通知に流し、ポリシーをYAMLで管理する、といった「監視を監視する」運用がしばらく続きそうな気配がある。
