［開発者向け］OpenAIがCodexのコードレビューに「独自ルール」を追加——AGENTS.mdでチームの暗黙知を明文化する方法

2026-07-22

はじめに

　OpenAIは2026年7月20日、開発者向けブログでCodex Code Reviewの新機能を発表しました。リポジトリのAGENTS.mdに独自のレビュールールを記述できるようになり、チーム固有の判断基準をAIレビューに反映できます。本稿ではこの仕組みと、ルールを書く際のポイントを解説します。

参考記事

タイトル: Custom Code Review rules for Codex
著者: Hari Srikanth
発行元: OpenAI Developers(公式開発者ブログ)
発行日: 2026年7月20日
URL: https://developers.openai.com/blog/custom-code-review-rules-for-codex

要点

Codex Code Reviewは、リポジトリのAGENTS.mdに記述した独自ルールを参照し、根拠を示しながら指摘できるようになった
OpenAIによれば、社内の週次PR件数はQ4以降倍増しており、レビューが開発のボトルネックになりつつある
評価では、ルールを与えた構成が必要な指摘の98%を検出し、ルールなしの58.3%を大きく上回った
推奨されるルールは「一般論」ではなく、後方互換性やデータ境界など再現性の高い判断基準に絞ったものである
ルールはリポジトリ直下と個別ディレクトリの両方に配置でき、変更されたファイルに応じて適用範囲を絞り込める

詳細解説

なぜ「暗黙知」がレビューのボトルネックになるのか

　OpenAIによれば、コーディングエージェントが大きな変更を長い時間軸で担えるようになったことで、開発チームがコードとして形にできるアイデアの量そのものが増えています。同社内では週次のPR件数がQ4以降倍増しており、多くの顧客企業でも同様の傾向が見られるといいます。コードが増えること自体は歓迎すべき変化ですが、その分レビューを担う人の負荷が急激に高まり、レビューが開発全体の速度を左右するボトルネックになりつつあります。

　特に厄介なのは、差分だけを見ても問題だと気づきにくいケースです。レスポンスのフィールド名を変更するような一見単純なリファクタリングでも、既にその名前に依存している別のクライアントを壊してしまうことがあります。経験豊富なレビュアーであれば「この項目は変更してはいけない」という経緯を覚えていますが、その領域に初めて触れる新しいメンバーやエージェントには、そうした背景は見えません。こうした 暗黙知 は、通常はドキュメント化されず数人のレビュアーの頭の中にとどまりがちで、チームの規模が大きくなるほど継承しにくくなると考えられます。

AGENTS.mdをレビューのルールブックにする

　この課題に対しOpenAIは、コーディングタスクの指示に使われてきたAGENTS.md（リポジトリ内に置く、コーディングエージェント向けの設定・指示ファイル）を、レビュー用のルールブックとしても使えるようにしました。チームが繰り返し説明してきた注意点を簡潔にまとめておけば、Codex Code Reviewが変更内容に応じて該当するルールを適用し、指摘の根拠として明示してくれます。同じ説明をプルリクエストのたびに書き直す必要がなくなり、ルールをコードの近くに置いたまま運用できる点が特徴です。

　OpenAIのCodexリポジトリ自身も、この仕組みを使ってAGENTS.mdにレビュールールを記載しており、外部から見えるインターフェースの互換性や、破壊的変更に関する注意点などを管理しているとのことです。リポジトリ全体に関わるルールはルート直下に、特定のサービスにのみ関係するルールはそのディレクトリ内に置くという使い分けにより、無関係な変更にまでルールが適用されて指摘が増えすぎる事態を避けられると考えられます。

評価結果が示す効果と限界

　OpenAIは、既知のルール違反と、違反に見えて実際は問題のない安全なケースの両方を含む評価スイートで検証を行いました。その結果、ルールを与えた構成では必要な指摘の98%を検出できたのに対し、ルールなしの通常構成では58.3%にとどまったと報告されています。これは、チーム固有の判断基準を明文化するだけで、レビューの見落としを大きく減らせる可能性を示すデータだと言えます。

　ただし、検出できることと、不要な指摘を出さないことは別の観点です。OpenAIは「カバレッジ(意図した違反を検出できるか)」「抑制(問題のない変更や正当な例外を誤検知しないか)」「保持(ルールと無関係な通常のバグも引き続き検出できるか)」「実行可能性(指摘が根拠・場所・優先度を示せているか)」という4つの観点で評価したといい、範囲を絞らないルールは無関係な変更にまでノイズを生みやすいことも分かったとのことです。

ルールを書く際に押さえておきたいポイント

　OpenAIは、有効なルールの書き方として次のような指針を挙げています。まず、レビュアーが何度も同じ説明を繰り返しているような、後方互換性の要件やデータ境界など「重要で見落としやすい不変条件」から着手すること。そのルールを外しても指摘内容が変わらないなら、そもそも書く必要はないとしています。次に、リポジトリ全体に関わるルールはルート直下、特定サービスに限定されるルールは該当ディレクトリに置き、適用範囲を絞ること。さらに、問題となる条件だけでなく「代わりにどうすればよいか」という安全な選択肢もあわせて書くことが推奨されています。

　この設計思想は、テストやリンターとの役割分担にも通じる部分があると考えられます。フォーマットなど機械的に判定できるチェックはCIに任せ、AGENTS.mdのルールにはレビュアーが判断に迷いがちな観点だけを残す、という切り分けが実務では有効だと思います。関数名など変わりやすい実装詳細ではなく、守るべき「結果」を記述しておくことも、ルールを長く使い続けるうえで重要だと考えられます。