結論: custom code review rulesは「レビューで毎回口頭共有していた暗黙知」をAGENTS.mdへ固定する仕組み
2026年7月20日にOpenAI Developersで公開された「Custom Code Review rules for Codex」によると、Codex Code Reviewはリポジトリ内のAGENTS.mdに書いたルールを参照し、差分に応じて関連ルールをレビュー指摘へひも付けられます。狙いは、古いAPI契約の維持、ログへ顧客データを出さない境界、他サービス連携を壊すrename防止など、人間レビューで何度も繰り返してきた注意点を機械的に拾いやすくすることです。
7月20日公開で確認できた3つのポイント
第1に、Codex側のレビュー対象は「diffだけでは分からないが、壊すと痛い不変条件」です。OpenAIは例として、古いレスポンス契約の維持、顧客データのログ流出防止、既存連携が依存するイベント名の保持を挙げています。第2に、ルールは短く限定的であるほど効きやすく、リポジトリ全体向けはルートのAGENTS.md、特定サービス向けは該当ディレクトリ配下へ置く設計が推奨されています。第3に、CodexはテストやCIの代わりではなく、レビューでしか拾いにくい判断を補う追加レビュアーとして位置付けられています。
AGENTS.mdに先に書くべきルールは「互換性」「データ境界」「安全な代替手段」
最初に追加すべきなのは、削るとレビュー品質が落ちるが、書けば再現性が上がるルールです。具体的には「外部公開APIやWebhook名を勝手に変えない」「個人情報や顧客データをモデル可視ログへ出さない」「例外時は旧イベント名を残すか後方互換の別経路を追加する」といった形です。OpenAIは、ルール本文に不変条件だけでなく safe path まで書くことを勧めています。つまり『何を守るか』だけで終わらせず、『変えるならどう安全に変えるか』まで1行で示すのが重要です。
実際に効く差分の例: rawResponseItem/completed を done へ変えるrename
OpenAIの記事では、Codex app-serverの internal notification `rawResponseItem/completed` を `rawResponseItem/done` にrenameする想定差分が紹介されています。コードは通っても、既にその wire name を購読している消費側は通知を受け取れなくなります。ここでAGENTS.mdに『rawResponseItem/* は experimental でも外部連携面として壊さない』と書いてあれば、Codexは単なる cleanup ではなく breaking change として指摘できます。実務では webhook event、監査ログ名、CSV列名、外部公開JSON field なども同じ考え方で守る対象です。
社内のレビュー基準をAIレビューへ落とし込みたい場合は、 HelloCraftAIに相談してください。
導入手順は「繰り返し出る指摘」を2〜3個だけ先に固定する
導入順はシンプルです。まず、レビューで毎週のように繰り返される指摘を棚卸しします。次に、その中から見落とすと影響が大きいものだけを2〜3個選びます。たとえば『監査対象のフィールド名を変えない』『SSO前提の権限分岐を削らない』『本番ログへ秘密情報を書かない』のように、非自明で重大なものです。その後、ルールを担当範囲に合わせてルートまたはサブディレクトリのAGENTS.mdへ配置し、違反する差分・違反しない差分・無関係な差分の3パターンで試すと、ノイズの有無を早く見極められます。
なぜ今やるべきか: OpenAIの評価では custom findings の再現率が 98% まで上がった
OpenAIは既知のルール違反と安全な反例を含むeval suiteで検証し、rule-guided variants が required custom findings を98%回収した一方、baseline control は58.3%だったと説明しています。もちろん、この数字だけで全リポジトリへそのまま当てはまるとは限りません。ただし、レビューで毎回説明している暗黙知を明文化すると、レビュー速度と抜け漏れ防止の両方に効く、という方向性はかなり強い示唆です。PR数が増えてレビュアーがボトルネックになっているチームほど、先に効く部分だけ文章化する価値があります。
よくある失敗は「広く書きすぎる」「CIで見るべき項目まで混ぜる」こと
失敗しやすいのは、抽象的な心得を大量に書いてしまうケースです。『品質を高く保つ』『安全性に注意する』では、レビュー時に何を止めるべきか伝わりません。逆に、整形ルールやlintで見られる項目までAGENTS.mdへ入れると、レビューの注意が散ってノイズが増えます。OpenAIも、機械的なチェックはCIへ、レビューでしか拾いにくい判断は repository rules へ分けるべきだと明示しています。つまり、AGENTS.mdは万能規約ではなく、レビューで人が毎回口にする高価値ルールだけを置く場所と考えるのが現実的です。
FAQ: 企業導入前に確認したい3つの疑問
Q. まずどのチームから試すべきですか。A. 既にPR数が多く、レビュー観点が属人化しているバックエンド基盤や社内共通APIチームから始めるのが無難です。Q. ルールは何本くらいが適切ですか。A. 初回は2〜3本で十分で、違反時の影響が大きいものを優先します。Q. ルールを書けば人間レビューは不要になりますか。A. なりません。OpenAIも、Codex Code Reviewは追加レビュアーであり、テスト、branch protection、required approvals を置き換えないとしています。
Codex導入と合わせて、レビュー基準、権限境界、ログポリシーまで整えたいなら、 HelloCraftAIの問い合わせ窓口 から相談できます。AIレビューを先に安全運用へつなげる設計まで含めて検討しておくと、あとからルールを継ぎ足すより運用がぶれにくくなります。
