同じ変更差分を確認しているはずなのに、担当者によって指摘の深さが変わることがあります。ある人は障害につながる条件分岐を重点的に見ますが、別の人は命名や書式の確認に時間をかけます。レビュー経験の差だけが原因とは限りません。確認範囲、指摘の優先順位、期待する出力形式が共有されていなければ、経験者同士でも結果はそろいにくいものです。



中小規模の開発チームでは、レビュー専任者を置けないことも珍しくありません。開発者が実装、問い合わせ対応、リリース作業を兼任する環境では、忙しいときほど確認項目が抜けやすくなります。チェックリストを文書化しても、レビューのたびに探してコピーし、対象範囲を書き換える運用では定着しないでしょう。そこで役立つのが、Codex CLIの「/presets」にレビュー指示を登録し、同じ入口から繰り返し呼び出す方法です。

この記事で扱う業務課題は、コードレビュー基準の標準化に絞ります。Codexに最終判断を任せるのではなく、確認観点を毎回同じ順序で提示し、見落としの候補を人へ返す補助役として使う考え方です。定型指示を用意しても、指摘の正しさや修正の要否まで自動的に保証されるわけではありません。標準化する対象は「何を確認させるか」と「どの形式で報告させるか」であり、採否を決める責任は引き続き担当者が持ちます。

OpenAIの公式変更履歴によると、2026年10月23日に公開されたCodex CLI 0.164.0では、再利用可能なプロンプトとスラッシュコマンドを10個の番号付き「/presets」スロットへ保存し、キーボードメニューから呼び出せる機能が追加されたと案内されています（出典: OpenAI Developers）。この記事が参照する資料の取得日は2026年10月29日です。10月27日には0.165.0も公開されていますが、「/presets」の追加は0.164.0の更新事項です。古い発表を最新機能として扱わないため、導入日と資料取得日を分けて理解しておく必要があります。



「/presets」に保存するのは、毎回変わらないレビュー方針です。たとえば、重大な不具合を優先すること、根拠となるファイルや箇所を示すこと、確証のない内容を断定しないことなどが該当します。変更対象のファイル、今回の仕様、関連するチケット、特に不安な処理といった情報は案件ごとに変わるため、プリセットを呼び出した後に追加する形が扱いやすいでしょう。これは活用方法の提案であり、変数展開など資料に記載のない機能を前提にはしていません。

プロジェクト全体の規約は、プリセットだけへ詰め込まないほうが管理しやすくなります。OpenAIの開発ワークフロー例では、任意の「AGENTS.md」にリポジトリの目的、コーディング規約、テスト基準、境界などの継続的な指針を記録できると説明されています（出典: OpenAI Developers）。役割を分けるなら、AGENTS.mdには長く維持するプロジェクト規約を置き、「/presets」にはレビューを開始するための短い定型指示を置きます。Codexの出力に対して、人は仕様との一致、指摘根拠、再現可能性、修正時の影響を確認します。この分担が曖昧なままでは、定型化してもレビュー品質の判断基準はそろいません。

プリセットを作る前に、現在のレビューで本当に困っていることを一つ挙げます。「指摘漏れがある」だけでは広すぎるため、「例外処理の抜けを確認できていない」「仕様と無関係な書式指摘が多く、重要な指摘が埋もれる」「指摘箇所を探し直す時間がかかる」など、観察できる状態まで具体化します。今回の中心課題は基準のばらつきなので、最優先事項を「障害やデータ不整合につながる問題を先に示すこと」と定める例が考えられます。これは導入案であり、各社の障害傾向や品質基準に合わせて調整してください。



レビュー観点は、多くても一度に判断できる範囲へ絞ります。例として、仕様との不一致、入力値と境界条件、エラー処理、権限や機密情報の扱い、既存テストへの影響を候補にできます。ただし、すべてのリポジトリで同じ優先順位になるわけではありません。社内ツールなら操作ミスからの復旧を重視する場合があり、受注や請求を扱うシステムなら金額計算や更新の整合性が上位に来るでしょう。レビュー対象外も「命名だけの好みは、規約違反でない限り重大指摘にしない」のように決めておくと、出力の焦点を保ちやすくなります。

導入環境については、対象機能が追加された0.164.0以降のCodex CLIであることを、社内の通常のバージョン管理手順に沿って確認します。公式変更履歴には0.164.0を指定して導入するコマンドとして `npm install -g @openai/codex@0.164.0` が掲載されています（出典: OpenAI Developers）。ただし、この記事ではNode.jsなどの前提条件や組織ごとの導入権限までは資料で確認できないため、環境管理者の手順を優先してください。リポジトリへのアクセス範囲、機密情報を含むファイル、実行を許可する操作も事前に整理します。

最後に、期待する成果物を決めます。単なる感想ではなく、各指摘に「優先度」「該当箇所」「問題となる理由」「確認方法」を含める形が実務では確認しやすいでしょう。指摘がない場合にも、確認した範囲と未確認の範囲を分けて書かせる案が有効です。ここまでを一度チームで合意してから登録すれば、プロンプトの文面変更がレビュー基準の変更であることも認識しやすくなります。

「/presets」には10個の番号付きスロットがあるため、用途を無計画に増やすより、最初は一つのレビュー指示から始めます。公式資料で確認できるのは、再利用可能なプロンプトやスラッシュコマンドを保存でき、キーボードメニューで素早く呼び出せることまでです（出典: OpenAI Developers）。メニュー内の文言や細かなキー操作は記事中で推測せず、利用中のCLIに表示される案内に従ってください。運用上は、空いている番号と用途をチーム内の文書へ記録しておくと、同じ番号へ異なる指示を入れる混乱を避けられます。



以下は、コードレビュー標準化のために登録するプロンプト例です。OpenAIが提供する公式テンプレートではなく、業務で試すための提案例です。実際の規約、テスト方法、扱うデータに合わせて書き換えてください。

```text
現在指定されている変更範囲をコードレビューしてください。
修正は行わず、指摘候補の報告に限定してください。

優先して確認する観点:
- 仕様と実装の不一致
- 入力値、境界条件、例外時の処理
- 権限、機密情報、データ更新の安全性
- 既存機能やテストへの影響

出力形式:
1. 優先度: 重大、要確認、提案のいずれか
2. 該当するファイルと箇所
3. 問題となる理由
4. 再現または確認する方法
5. 判断に不足している情報

根拠を確認できない内容は断定せず、未確認と明記してください。
書式や好みだけの指摘は、共有規約への違反がある場合に限ってください。
最後に、確認済みの範囲と未確認の範囲を分けて示してください。
```

登録作業では、Codex CLIで `/presets` を開き、表示されたキーボードメニューから使用する番号付きスロットを選びます。その後の入力や保存は、画面に表示される案内を確認しながら進めます。保存後は、本番の変更へすぐ使わず、内容を把握している小さな差分で呼び出してください。意図した観点と出力形式が再現されるかを人が確認し、不要な一般論が多ければ対象外を追記します。重大度の基準が曖昧なら、「利用者データを誤更新する可能性があるものを重大とする」など、プロジェクトに即した条件へ置き換えるとよいでしょう。

実際のレビューでは、プリセットを呼び出す前に対象範囲を確定します。作業途中の変更とレビュー対象が混在していると、指摘が今回の変更に関係するのか判断しにくくなります。対象のファイル、関連する仕様やチケット、実行済みのテスト、既知の制約を短く整理してください。Codexが参照してよいファイルと、機密性などの理由で対象外にする場所も明示します。ここは自動化せず、レビュー依頼者が責任を持って準備する工程です。



操作の流れは次のように整理できます。これは「/presets」の保存・呼び出し機能を業務へ当てはめた推奨手順であり、公式に定められたレビュー手順ではありません。

1. レビュー対象となる差分と関連資料を確定します。
2. 対象リポジトリでCodex CLIを起動し、`/presets` を開きます。
3. 標準レビュー用として登録した番号付きスロットを、表示されたキーボードメニューから選びます。
4. 今回だけの対象範囲、仕様、制約を追加で入力します。
5. 出力を受け取ったら、コードを変更させる前に指摘候補を人が確認します。
6. 採用する指摘を決め、修正とテストは別の作業として扱います。

案件ごとに追加する入力例は、「上記の定型レビューを使い、`src/orders/` と関連テストにある今回の変更だけを確認してください。注文取消時に在庫が戻る仕様です。修正は行わず、各指摘に該当箇所、理由、確認方法を添えてください」のように書けます。この文面も提案例です。実在するパスと仕様へ差し替え、資料にない情報をCodexが推測しなくて済むようにします。

出力を受け取った直後に修正を依頼すると、誤った指摘まで実装へ反映されるおそれがあります。レビュー工程では「候補の抽出」と「採否の判断」を分けるほうが安全です。対象外のファイルを参照していないか、仕様書と矛盾していないか、既存テストで確認できる内容かを見てから、必要な修正だけを次の依頼へ渡します。指摘がゼロでも、確認範囲が十分だったとは限らないため、未確認項目の有無を必ず読み取ってください。

Codexの出力は、レビュー完了の証明ではなく、確認候補の一覧として扱います。もっとも注意したいのは、文章が具体的に見えても、参照箇所や前提が誤っている場合です。ファイル名が存在するか、示された処理が実際にその場所にあるか、変更前から存在した問題ではないかを確かめます。今回の差分と無関係な既存問題を見つけた場合は、現在の変更を止める理由にするのか、別課題として記録するのかを人が決めなければなりません。



確認時には、次の五点を順番に見ると整理しやすくなります。

- **対象との一致**: 指摘が今回の差分と依頼範囲に含まれているかを確認します。
- **根拠の所在**: ファイル、該当箇所、条件分岐などを実際のコードで追えるかを見ます。
- **仕様との一致**: Codexが置いた前提ではなく、承認済みの仕様や業務ルールを基準にします。
- **再現可能性**: 指摘された問題がテスト、入力例、操作手順で確認できるかを検討します。
- **修正時の影響**: 提案どおり変更した場合に、互換性や別の処理を壊さないかを調べます。

セキュリティや権限に関する指摘は、もっともらしい説明だけで採用しないことが大切です。認証の前提、公開範囲、データの流れを確認し、社内ルールに照らして判断します。反対に、Codexが指摘しなかったから安全だとも判断できません。重要な変更では、既存の人手レビュー、テスト、静的解析、運用上の承認を省略せず、プリセットはそれらへ入る前の確認漏れを減らす補助線として位置づけます。

誤指摘や不足が見つかったら、その場限りの追加指示で終わらせず、定型部分に戻すべき内容かを検討します。たとえば、毎回書式の細部ばかり指摘されるなら、対象外の条件をプリセットへ追加する候補になります。ただし、一件の特殊事例だけで共通基準を変えると、別案件で必要な確認まで消えかねません。複数のレビューで繰り返す傾向か、特定リポジトリだけの規約かを見分けてから更新してください。

導入初日から全リポジトリへ展開する必要はありません。最初は、仕様と修正結果を担当者が把握している過去の変更や、小さな内部ツールの差分を対象にします。たとえば三件程度を試す案なら、各回について「有用だった指摘」「誤っていた指摘」「不足した観点」「確認に時間がかかった表現」を記録できます。この件数は推奨値や実測値ではなく、負担を抑えて比較するための例です。効果を判断するときも、改善率を推測せず、採用された指摘と見送った理由を事実として残します。



プリセットの正本となる文面は、CLI内だけでなく、チームがレビューできる文書にも保存する運用が考えられます。OpenAIの開発ワークフロー例では、「PROMPTS.md」を再利用可能なプロンプトの置き場所とする構成が紹介されていますが、これはCodexが必須とするファイルではなく、推奨される任意の慣例です（出典: OpenAI Developers）。採用する場合は、プリセット番号、用途、本文、更新理由、確認者を記録し、CLI側の内容と食い違わないようにします。既存の文書管理方法がある企業は、新しいファイルを増やさず、現在の手順書へ組み込んでも構いません。

標準化の判断では、出力が毎回同じかどうかだけを見ないでください。異なる変更に同じ結論を返すことが目的ではなく、同じ観点から確認を始められることが目的です。適切な指摘が案件によって変わるのは自然です。変更すべきなのは、重要な観点が繰り返し抜ける、根拠のない断定が多い、担当者が出力形式を読み解けないといった場合でしょう。文面を更新したら、何を解決する変更なのかを記録し、再び小さな差分で確認します。

最初の一歩として、次回のレビューで使う観点をチームから三つ集め、一つのプリセットへまとめてみてください。そのうえで、Codexの指摘を採用したかどうかではなく、「根拠を人が追えたか」「未確認範囲が分かったか」を振り返ります。この二点が確認できれば、プリセットを増やす前に、標準レビューの入口として使えるかを具体的に判断できます。

- ChatGPT & Codex changelog | ChatGPT Learn
- Iterating Development Workflows with Codex