OpenAIのCodex Code Reviewに、リポジトリ独自のルールを設定できる機能が加わりました。AGENTS.mdというファイルにルールを書くだけで、AIが「このプロジェクト特有の問題」を自動で検出してくれるようになります。コードを書かない立場の方でも、この変化がチームの仕事の流れに何をもたらすか、知っておく価値があります。この記事では、機能の概要から実務への影響まで整理します。
「また同じ指摘だ」を解消する仕組み
コードレビューには、どのチームにも「あるある」な繰り返しの指摘が存在します。たとえば「関数名の命名規則を守って」「このAPIは直接呼ばないで」「エラーハンドリングを必ず書いて」といった内容です。ベテランのレビュアーは毎回同じコメントを書き、新しいメンバーは同じミスを繰り返す。この摩擦は、チームの規模が大きくなるほど深刻になります。
Codex Code Reviewは、GitHubのプルリクエストに対してAIが自動でレビューコメントを付ける機能です。今回の更新で、このAIが参照するルールを開発者自身がカスタマイズできるようになりました。方法はシンプルで、リポジトリのルートにAGENTS.mdというファイルを置き、チーム独自のルールを書くだけです。「このリポジトリではXXXをしてはいけない」「YYYの関数を使うときはZZZも確認する」といった内容を自然な文章で記述すると、Codexがそれを読んで判断基準に組み込みます。
OpenAIが公式ブログで強調しているのは「まずレビュアーが繰り返している指摘から始めよ」という点です。全部のルールを一気に書こうとすると、かえって精度が落ちます。チームで最も頻繁に出るコメントを1〜2個に絞り、簡潔に書くことが推奨されています。
なぜ「文脈の孤立」が問題だったのか
これまでのAIコードレビューには、根本的な限界がありました。AIは一般的なコーディングのベストプラクティスは知っていても、「このプロジェクト固有の事情」は知らないのです。たとえば、あるチームが過去の障害を受けて「このモジュールからは直接DBに触れない」というルールを設けていたとします。その背景はコードのどこにも書かれておらず、ベテランの頭の中にだけある状態です。こういった「サイロ化した文脈」をAIが拾えないのは当然でした。
AGENTS.mdはこの問題への一つの回答です。暗黙知をテキストとして明文化し、AIが参照できる場所に置く。それだけで、コードのどこに書いてあるかわからないルールをAIが判断材料として使えるようになります。ルールの書き方次第で精度は変わりますが、「文脈が孤立しているからAIには無理」という前提が崩れ始めているのは確かです。
この流れは、AIツールが「汎用的な賢さ」から「組織固有の知識を持つアシスタント」へとシフトしているサインとも読めます。汎用性だけで差別化できた時代は短く、次の競争軸は「いかに自社の文脈をAIに学習させるか」に移っています。
エンジニア以外が知っておくべき実務への影響
ここからは、コードを書かない立場の方——プロジェクトマネージャー、営業、経理、人事——にとって何が変わるかを考えてみます。
たとえば、30代のITプロジェクトマネージャーが開発チームを束ねているとします。毎週のスプリントレビューで「コードレビューに時間がかかっている」「ベテランが新人のレビューに追われている」という声が出ているとしたら、AGENTS.mdの導入はその詰まりを解消する手段になり得ます。AIが定型的な指摘を先に処理してくれれば、ベテランのレビュー時間はアーキテクチャや設計の判断に集中できます。リードタイムの短縮は、開発以外の工程にも波及します。
別の例として、SaaS企業の40代の事業部長が開発ロードマップの進捗を気にしているケースを考えてみます。「なぜ機能リリースが遅れるのか」の原因の一つがコードレビューのボトルネックだとすれば、AIによる自動化はリリース頻度に直接影響します。コストとしては、AGENTS.mdの設定自体は無料で、Codex Code ReviewはGitHub連携で動くため追加インフラも不要です。投資対効果を測るなら、「レビュー待ち時間の削減」と「指摘の見落とし率の変化」の2点を追うのが現実的です。
AGENTS.mdの書き方：精度を左右する3つの条件
AGENTS.mdに何を書くかで、Codexの検出精度は大きく変わります。OpenAIの推奨を整理すると、有効なルールには共通した特徴があります。
具体性：「コードを綺麗に書く」ではなく「関数の引数が4つを超える場合はオブジェクトにまとめる」のように、判断できる形で書く必要があります。AIは曖昧な指示を自分で解釈しようとするため、解釈の幅が広いルールは誤検知につながります。
スコープの限定：ルールを書くとき、どのファイルやディレクトリに適用するかを明示すると精度が上がります。「全体に適用」のルールより「/api配下のファイルに限り」のように範囲を絞ったほうが、Codexが判断しやすくなります。
更新のしやすさ：AGENTS.mdはコードと同じリポジトリに置かれるため、ルールの変更履歴がGitで管理されます。「いつ、なぜこのルールを追加したか」をコミットメッセージに残す習慣をつけると、後から参照しやすくなります。
以下は、AGENTS.mdのルール記述の粗い比較です。どちらが検出精度に貢献するかは明確です。
| 書き方 | 例 | 精度への影響 |
|---|---|---|
| 曖昧な表現 | 「エラー処理を適切に行う」 | 低い（AIが解釈を迷う） |
| 具体的な条件 | 「外部APIを呼ぶ関数では必ずtry-catchを使い、エラーをlogErrorに渡す」 | 高い（判断基準が明確） |
| スコープなし | 「命名規則を守る」 | 低い（どこに適用するか不明） |
| スコープあり | 「/services配下では関数名をcamelCase、クラス名をPascalCaseにする」 |
高い（対象が明確） |
Codexが「組織の記憶」になる可能性
AGENTS.mdの登場は、単なる機能追加以上の意味を持つかもしれません。これまで、チームの暗黙知は人の頭の中にありました。ベテランが辞めるとルールが消え、新人は同じミスを繰り返し、ドキュメントは更新されずに腐っていく。この問題はどの組織でも繰り返されてきました。
AGENTS.mdは、その暗黙知を「コードと一緒に管理するテキスト」として扱う仕組みです。ルールをAIが読む形式で書くことで、ドキュメントが実際に使われる状態になります。読まれないWikiに書くより、AIが毎回参照するファイルに書くほうが、ルールが生きやすい。この発想の転換は、開発チーム以外の組織運営にも応用できる考え方です。
プロンプトエンジニアリングの基礎でも触れているように、AIに何かをさせるときの精度は「指示の書き方」で決まります。AGENTS.mdはその原則をチームレベルで実装したものとも言えます。
また、こうしたAIツールの使いこなし方を学ぶことが、これからのキャリアにどう影響するかは、AIスキルを活かした副業ガイドでも整理しています。
まとめ
CodexのAGENTS.mdカスタマイズは、「AIが汎用的に賢い」時代から「AIが自分たちのルールを知っている」時代への移行を象徴する機能です。繰り返しの指摘をAIに任せることでレビュアーの負荷が下がり、暗黙知をテキスト化することで組織の知識が人に依存しにくくなる。この二つの効果は、コードを書くかどうかに関係なく、チームで仕事をしている人なら誰にでも関係します。
あなたのチームで「毎回同じ指摘が出ている場面」はどこにあるでしょうか。
