CodexレビューをGitHubに入れる前に決めること

3行まとめ

Cloud

対象repoと環境。

Review

手動か自動か。

Guide

AGENTS.mdの観点。

Fix

修正まで任せる条件。

最初から全部自動化せず、運用の境界を先に決めます。

• Codex code reviewをGitHubに入れるなら、まずCodex cloud環境、対象repository、setup、権限、レビュー開始条件を分けて決めます。
• 自動レビューは最初から全PRに広げず、@codex reviewの手動トリガーで信号を見てから対象を増やします。
• AGENTS.mdには「何を重大リスクとして見てほしいか」を短く書き、レビュー後の修正依頼はbranch protectionと人間レビューを残したまま扱います。

この記事では、OpenAI公式のCodex Enterprise admin setup、Cloud environments、Agent approvals & security、GitHub integration、Codex use casesを確認し、2026年6月1日時点の情報として整理しています。画面名、権限名、GitHub連携の細部は変わり得るため、導入直前に公式docsと管理画面を再確認してください。

この記事でわかること

Start

手動triggerから試す。

Scope

対象repoとPRを絞る。

Signal

重大指摘に寄せる。

Approve

修正権限を決める。

Codexをレビュアーに足す前に、何を任せないかも決めます。

• Codex code reviewをGitHub PRに入れる前に決める順番
• Codex cloud環境とGitHub repository接続で見るポイント
• @codex reviewとautomatic reviewsの使い分け
• AGENTS.mdにレビュー観点を書くときの粒度
• Codexに修正まで頼む場合の権限境界
• network access、secrets、setup scriptを混ぜない考え方
• 導入初週に見るべきレビュー品質の指標

CodexのGitHub code reviewは、PRにもう1つのレビュー視点を足せる便利な入口です。ただし、便利さだけで入れると、レビューコメントが増えただけ、誰も見ないbotになった、修正依頼まで任せてbranch運用が曖昧になった、という形で止まりやすくなります。

大事なのは、AIレビューを「人間レビューの代替」として置くのではなく、重大な見落としを先に拾う補助線として入れることです。公式docsでも、Codex code reviewはPR diffを見て、repository guidanceに従い、serious issuesに焦点を当てたGitHub code reviewを投稿するものとして説明されています。

すでにCodex活用をチームに広げる段階なら、先に公開済み記事のCodex活用をチームに広げる順番で、Slack依頼、PRレビュー、CLI化、Skill化を分けておくと整理しやすくなります。

前提知識

項目	内容	見方
Admin setup		workspaceとRBAC。
Cloud env		setupとsecrets。
GitHub		review trigger。
Security		sandboxとnetwork。

画面や権限名は更新されるため、導入直前に再確認します。

Codex code reviewを使うには、対象repositoryでCodex cloudが使える状態になっている必要があります。OpenAIのEnterprise admin setupでは、Codex localとCodex cloudを分けて説明しており、Codex cloudはGitHub上のrepositoryを対象に、hosted containerでtaskを実行するものとして扱われています。

GitHub code reviewの公式ページでは、事前にCodex cloudを対象repositoryへ設定し、Codex code review settingsへアクセスでき、必要ならAGENTS.mdを置くことが前提として書かれています。レビューを頼む場合はPR commentで@codex reviewを使い、自動レビューを有効にすると新しいPRに対してreviewが投稿されます。

公式情報で確認する範囲

確認先	見ること
Enterprise admin setup	workspace設定、Codex local/cloud、RBAC、管理者分離
Cloud environments	repository、setup script、environment variables、secrets、cache
GitHub integration	@codex review、automatic reviews、AGENTS.md review guidelines
Agent approvals & security	sandbox、approval、network access、allowlist
Codex use cases	GitHub PR reviewやSlack taskなどの使いどころ

注意点

この記事は、Codex code reviewを恒久的にこう設定すべき、という固定手順ではありません。GitHub連携、workspace設定、Codex cloudの管理画面、review trigger、権限の名称は更新されます。ここでは、導入時に迷いやすい判断を分けるための実務手順として扱います。

AIレビューは、万能な品質保証ではありません。仕様の意図、プロダクト判断、顧客影響、法務やセキュリティ上の最終責任は人間側に残ります。Codexの指摘は、PR authorとreviewerが見る入力の1つとして扱います。

まずCloud環境を先に整える

1. 1Repo

   GitHub connectorを接続。

2. 2Env

   環境を作る。

3. 3Setup

   依存関係を入れる。

4. 4Cache

   更新条件を決める。

レビュー精度は、読めるrepoと再現できる環境に左右されます。

Codex reviewだけを急いで有効にする前に、Codex cloud環境を整えます。レビュー対象のrepository、checkoutされるbranch、依存関係のinstall方法、cacheの扱い、network access、secretの渡し方が曖昧なままだと、レビュー結果も運用も安定しません。

OpenAIのCloud environments docsでは、Codexがcontainerを作り、選択されたbranchまたはcommit SHAでrepositoryをcheckoutし、setup scriptを実行する流れが説明されています。共通package managerを使うprojectではautomatic setupも使えますが、複雑なprojectではmanual setup scriptを用意します。

repository接続を確認する

最初に決めるのは、どのrepositoryでレビューを有効にするかです。GitHub organization全体に一気に広げるより、PR量が多く、テストがあり、ownerが明確で、レビュー文化があるrepositoryから始めます。

最初の対象に向くrepository

確認する項目は次の通りです。

項目	見ること
repository owner	導入判断と設定変更の責任者
PR volume	週あたりのPR数、緊急PRの割合
test command	Codexが失敗や未検証を理解しやすいか
branch protection	AI修正後も人間reviewが残るか
sensitive code	認証、課金、個人情報、権限周りの比率

PR量が少なすぎるrepositoryでは評価が進まず、逆に多すぎるrepositoryでは初週からノイズ処理に追われます。最初は、1週間で10から30件程度のPRを見られるrepositoryが扱いやすいです。

setup scriptとcacheを見る

Cloud environmentsでは、setup scriptとcacheがレビュー品質に効きます。依存関係が入らない、typecheckが動かない、monorepoの対象packageがわからない、といった状態では、Codexのコメントも浅くなります。

setup scriptには、レビューに必要な最小限のinstallと確認コマンドを寄せます。すべてのintegration testを必ず通す必要はありませんが、型、lint、unit test、packageごとの基本commandは読み取れるようにしておきます。

cacheは速くするために便利ですが、古い依存状態のまま評価されると混乱します。公式docsでは、setup script、maintenance script、environment variables、secretsを変えるとcacheが無効化されることが説明されています。dependency lockfileやtoolchainが変わったときに、誰がcacheをresetするかも決めておくと運用しやすくなります。

自動レビューは小さく始める

1. Step 1

   @codex reviewで手動実行。

2. Step 2

   対象repoを限定。

3. Step 3

   auto reviewを一部へ。

4. Step 4

   失敗条件を記録。

自動レビューは便利ですが、最初はレビュー量と信号を見ます。

Codex code reviewには、PR commentで@codex reviewを投げる使い方と、automatic reviewsを有効にする使い方があります。最初からautomatic reviewsを全PRへ広げると、評価前にコメント量だけが増えます。まずは手動トリガーで、どの種類のPRに効くかを見ます。

最初は手動トリガーから試す

1週目は、PR authorかreviewerが@codex reviewを明示的に投げます。対象は、バグ修正、認証周り、DB migration、外部API連携、権限変更、依存更新のように、見落としコストが高いPRから選びます。

見るべきなのは、コメント数ではありません。次のような観点で記録します。

観点	良い状態	悪い状態
重大度	P0/P1相当の見落としを拾う	styleや好みの指摘が多い
根拠	diffと周辺文脈に沿っている	変更外の推測が多い
行動可能性	authorが直せる粒度	抽象的で判断できない
重複	人間reviewと補完関係	同じ指摘を繰り返す

公式docsでは、CodexがGitHub上でhigh-signalなreview passを追加し、serious issuesに焦点を当てるものとして説明されています。導入初期は、この「重大な見落としに寄る」状態になっているかを見ます。

自動化するPRを絞る

手動レビューで信号が見えてから、automatic reviewsを検討します。自動化の対象は、全PRではなく、まず範囲を絞ります。

自動化しやすい変更

たとえば、次のような分け方です。

対象	自動化の向き不向き
認証、認可、課金	自動レビューの価値が高い
DB migration	影響確認の観点を固定しやすい
UI copyだけのPR	自動レビューの費用対効果が低い場合がある
dependency update	テストと権限境界を見たい
大規模refactor	コメント量が増えやすく、分割が先

自動レビューは、便利かどうかより、reviewerの集中力を守れるかで判断します。人間が見るべきPRに先に赤信号を出し、問題が薄いPRでは邪魔しない状態が理想です。

GitHub ActionsでAI修正PRを扱う運用も併用する場合は、公開済み記事のGitHub ActionsでAI修正PRを作る前にで、permissions、secrets、pull_request_targetの扱いも先に確認してください。

AGENTS.mdにレビュー観点を書く

Security

認証やPII。

Tests

回帰と未検証。

Domain

業務ルール。

Depth

近いpathに詳しく。

指摘してほしいリスクを、repoの近い場所に置きます。

Codex GitHub integrationの公式docsでは、Codexがrepository内のAGENTS.mdを探し、Review guidelinesに従うことが説明されています。ここは、AIレビューの質を上げる一番現実的な調整点です。

ただし、AGENTS.mdを長い社内規程の置き場にしないほうがよいです。Codexに見てほしいのは、PRで見落とすと危ない具体的な観点です。

重大リスクに寄せる

AGENTS.mdのReview guidelinesには、次のようなものを書きます。

Review guidelines:

- 認証middlewareを通らないroute追加をP1として扱う。
- 個人情報、token、email addressをlogへ出す変更をP1として扱う。
- 課金金額、権限role、tenant境界の変更はテスト不足を指摘する。
- migrationはrollback手順と既存dataへの影響を確認する。

styleや命名規則を大量に書くより、重大事故につながる観点を少なく置きます。Codexに「typoも全部見て」と頼むことはできますが、最初はレビューの信号を濁らせないほうが運用しやすいです。

packageごとに近い指示を置く

公式docsでは、Codexが変更fileに最も近いAGENTS.mdのguidanceを適用できることが説明されています。monorepoでは、rootだけに巨大な指示を書くより、packageごとに短いReview guidelinesを置きます。

例として、apps/admin/AGENTS.mdには管理画面の権限、packages/billing/AGENTS.mdには課金境界、packages/auth/AGENTS.mdには認証とsessionの観点を書く、という分け方です。

公開済み記事のチーム向けAGENTS.mdテンプレートでは、権限、テスト、レビュー基準をrepo側に残す型を整理しています。Codex reviewのguidelinesも、同じく「AIに毎回思い出させたい作業契約」として扱うと書きやすくなります。

修正依頼まで任せる条件を決める

項目	内容	見方
Comment only		人間が判断。
Fix request		P1だけ依頼。
Push		権限とbranch保護。
Merge		人間reviewを残す。

レビューと修正は別権限として扱うと、運用が崩れにくくなります。

CodexのGitHub integrationでは、Codexがreviewを投稿した後、コメントで修正を依頼できる流れも説明されています。たとえば、P1 issueを直すように依頼すると、Codexがpull requestをcontextにcloud taskを開始し、権限があればbranchへ修正をpushできます。

ここで混ぜてはいけないのは、レビュー権限と修正権限です。レビューコメントを出すことと、branchへ変更をpushすることは、運用上は別の権限です。

P1指摘の扱い

おすすめは、修正依頼の対象を最初はP1相当に限ることです。たとえば、認可漏れ、secret漏えい、テストが落ちる変更、migration事故、API互換性破壊のようなものです。

修正依頼に進める条件

軽微なstyle修正や命名変更までCodexに直させると、PRが小さな差分で揺れ続けます。レビュー後の修正依頼は、次の条件を満たすときに限定します。

条件	理由
指摘が具体的	修正差分を小さくできる
影響範囲が狭い	PRの目的から外れにくい
テストがある	修正後の確認ができる
authorが了承	PRの所有者が崩れない

branch protectionを残す

Codexが修正をpushできる場合でも、branch protectionとrequired reviewは残します。AIが直したからmergeしてよい、ではなく、AIが直した差分を人間が見る、という流れです。

特に、deploy、database migration、権限role、billing、security policy、外部送信、個人情報に関わる変更では、AI修正後の人間reviewを必須にします。これはAIを信用しないという話ではなく、責任の境界を明確にする話です。

networkとsecretsは別々に見る

項目	内容	見方
Setup		依存取得に使う。
Secrets		setup時だけ渡す。
Agent		通常は制限。
Allowlist		必要domainだけ。

外部通信や秘密情報は、便利さより範囲の小ささを優先します。

Codex cloud環境では、setup scriptのphaseとagentが作業するphaseを分けて考えます。Cloud environments docsでは、setup scriptの実行やagent phaseでのinternet access、environment variables、secretsの扱いが説明されています。

重要なのは、secretsとenvironment variablesを同じものとして扱わないことです。公式docsでは、secretsは追加の暗号化で保存され、task execution時だけ復号され、setup scriptsでだけ利用でき、security上の理由でagent phaseの前に取り除かれると説明されています。

setup phaseとagent phaseを分ける

setup scriptでは、private package registryやdependency installのためにsecretが必要になることがあります。一方で、agent phaseにsecretを渡す必要が本当にあるかは別問題です。

分け方は次の通りです。

phase	使うもの	注意点
setup	package install、tool install、private registry	secretを最小化する
cache	install済み依存、toolchain	古い状態を避ける
agent	diff確認、review、修正	secretを前提にしない
follow-up	maintenance script、branch checkout	cache更新条件を見る

この分け方をしておくと、「レビューに必要だからsecretを全部渡す」という雑な設定を避けられます。

internet accessを必要最小限にする

Enterprise admin setupでは、Codex cloud agentsのruntime internet accessはdefaultで無効であり、必要に応じてallowlistやHTTP methodを設定できることが説明されています。Agent approvals & securityでも、network accessやdomain policyの考え方が示されています。

レビューだけなら、常時広いinternet accessが必要とは限りません。依存関係取得はsetup phase、外部API仕様の確認は必要domainだけ、社内endpointやprivate IPへのアクセスは原則避ける、というように分けます。

Codexに外部通信を許可する設計は、公開済み記事のCodexにインターネットアクセスを許可する前にでも整理しています。GitHub reviewでも同じく、便利さより送信先とmethodの限定を優先します。

導入初週の進め方

1. 1日目

   repoとownerを決める。

2. 2日目

   手動reviewを試す。

3. 3日目

   AGENTS.mdを調整。

4. 5日目

   自動対象を限定。

5. 7日目

   継続条件を決める。

便利だったかではなく、レビュー品質と手戻りの減り方で判断します。

Codex review導入は、1日で全PRへ入れるより、1週間で段階的に見るほうが失敗しにくいです。

日	やること	見る指標
1日目	対象repositoryとownerを決める	setupが再現できるか
2日目	@codex reviewで手動実行	指摘が具体的か
3日目	AGENTS.mdのReview guidelinesを短く追加	重大リスクに寄ったか
4日目	P1指摘の修正依頼を1件だけ試す	差分が小さいか
5日目	automatic reviewsを限定repoで試す	コメント量が過剰でないか
7日目	継続条件を決める	手戻りや見落としが減ったか

初週に見るべきなのは、レビューの量ではありません。PR authorが「これは助かった」と言える指摘があるか、人間reviewerが見るべきポイントを早く見つけられるか、AIコメントの確認負荷が人間reviewを邪魔していないかです。

継続判断の基準

1週間試したら、次の4つで判断します。

判断	継続する条件
品質	重大リスクの指摘があり、誤指摘が少ない
速度	review開始から投稿までがPR運用に合う
負荷	authorとreviewerの確認負荷が増えすぎない
安全性	branch protection、network、secretの境界が残る

この4つを満たさない場合は、automatic reviewsを広げる前にAGENTS.md、対象PR、setup、network設定を見直します。AIレビューの導入は、botを増やすことではなく、レビューの質を上げることが目的です。

FAQ

Auto?

最初は限定。

AGENTS?

短く具体的に。

Fix?

条件つきで任せる。

Network?

必要分だけ許可。

迷ったら、PRレビューの目的と権限境界へ戻します。

Codex reviewは人間レビューの代わりになりますか

代わりにしないほうがよいです。Codex reviewは、PR diffとrepository guidanceをもとに高信号な追加レビューを返すものとして扱います。仕様判断、責任判断、merge判断は人間側に残します。

最初からautomatic reviewsを有効にしてよいですか

小さなrepositoryなら試せますが、一般には手動トリガーから始めるほうが安全です。まずは、どのPRで有効か、どの指摘が役に立つか、どのAGENTS.md guidanceが効くかを見ます。

AGENTS.mdにはどれくらい書けばよいですか

最初は短くします。認証、個人情報、課金、tenant境界、migration、外部送信など、重大リスクに絞るのが実務的です。styleや命名規則を大量に入れると、重要な指摘が埋もれます。

Codexに修正まで任せてもよいですか

条件つきで任せます。P1相当で、修正範囲が小さく、テストがあり、PR authorが了承している場合から始めます。branch protectionとrequired reviewは外さず、AIがpushした差分を人間が確認します。

secretsを渡せばレビュー精度は上がりますか

必ずしも上がりません。Cloud environments docsでは、secretsはsetup scriptで利用され、agent phase前に取り除かれる扱いが説明されています。レビューに必要なのは、多くの場合secretそのものではなく、依存関係が入った環境と、読めるcode、明確なguidanceです。

次に読むなら

参照した主な情報源

• https://developers.openai.com/codex/enterprise/admin-setup
• https://developers.openai.com/codex/cloud/environments
• https://developers.openai.com/codex/agent-approvals-security
• https://developers.openai.com/codex/integrations/github
• https://developers.openai.com/codex/use-cases

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

導入時には最新のCodex docs、GitHub設定、workspace設定を確認してください。

• 2026年6月1日: OpenAI公式Codex docsを確認し、Codex code reviewをGitHubに入れる前のCloud環境、自動レビュー、AGENTS.md、修正依頼、network、secretsの分け方として初版を作成しました。