ガイド公開日
Codex をクラウドと GitHub の上で動かし、レビューを任せる

Codex 集中講座の第14回。手元を経由せずにクラウドで作業させる方法と、プルリクエストの画面から呼び出してレビューさせる方法を扱います。レビューの観点を AGENTS.md で指定する仕組みも整理します
ここまでは、手元で Codex を動かし、その結果を GitHub へ持っていく流れでした。
向きを変えます。GitHub の側に置いてある変更を、手元を経由せずに扱わせる方法です。第1回で挙げた5つの動く場所のうち、クラウドと GitHub の2つが、ここで出てきます。
クラウドは、使い捨ての環境で動く
Codex クラウドは、作業ごとにコンテナを立て、そこにリポジトリを取り出して作業する形です。手元のパソコンは関係しません。
手元との違いは2つあります。
ひとつは、手元を占有しないことです。数十分かかる作業を投げておいて、その間に別のことができます。パソコンを閉じても進みます。
もうひとつは、手元にしかないものが使えないことです。入れてある道具、置いてある設定ファイル、環境変数。これらは新しいコンテナには存在しません。公式ドキュメントによれば、リポジトリごとに環境を作り、必要な依存や道具や環境変数や準備の手順を設定しておくことになります。
この設定作業は、第13回の GitHub Actions のワークフローを書く作業とよく似ています。どちらも「きれいな環境から動く状態を作る手順」を書き出す作業だからです。片方を書いていれば、もう片方はほぼ同じ内容になります。
コマンドライン版からもクラウドの作業を扱えます。
codex cloud list # 走っている作業を並べる
codex cloud status <ID> # 状態を見る
codex cloud diff <ID> # 差分を見る
codex cloud apply <ID> # 手元へ取り込む
投げっぱなしにせず、diff で中身を見てから apply で手元に落とす。第3回で決めた「差分を読んでから受け入れる」の形が、ここでも同じように使えます。なお、この機能は実験的なものとして提供されています。
プルリクエストの画面から呼ぶ
もう1つの入口が、GitHub のプルリクエストです。
使うには先に設定が要ります。公式ドキュメントによれば、Codex クラウドの設定を済ませたうえで、Codex の設定画面で対象のリポジトリに対してコードレビューを有効にします。
有効にしたあとは、プルリクエストのコメントに書くだけです。
@codex review
受け付けられると、コメントに目のマークが付きます。作業が終わると、通常のレビューと同じ形で指摘が並びます。
review 以外の言葉を書いた場合は、そのプルリクエストを文脈にした会話が始まります。「この変更で影響を受ける画面はどこか」のような質問を、レビューの途中で投げられます。
レビューの観点を、リポジトリ側で決める
ここが一番使い出のある部分です。
公式の説明によれば、Codex はリポジトリの中の AGENTS.md を探し、そこに書かれたレビューの指針に従います。書いておく項目の例として、「個人情報を記録に出さない」「認証の処理が全部の経路を通っているか確かめる」のようなものが挙げられています。
つまり、第9回で作った規約が、そのままレビューの基準として働きます。規約を書く、Codex がそれに従って書く、別の Codex がそれに従って確かめる。同じ1つのファイルが、書く側と見る側の両方に効いていることになります。
観点を書くときの注意は、第9回と同じです。判定できる形で書いてください。「読みやすいコードにする」は指摘になりませんが、「この形式のログ出力に個人情報を含む項目が入っていないか」は指摘になります。
手元からもレビューできる
GitHub を経由せずに、手元でレビューを走らせることもできます。第6回で /review に触れましたが、コマンドライン版には対象を選ぶ引数があります。
codex review --uncommitted # まだコミットしていない変更
codex review --base main # main との差分
codex review --commit <SHA> # あるコミットが入れた変更
使い分けの目安は、プルリクエストを出す前か後かです。出す前なら --base で全体を見せ、出したあとに指摘を直したら --uncommitted でその部分だけ見せる。全体を毎回見せると、直っていない指摘が繰り返し出てきて読む気が失せます。
2つのレビューは別のものを見る
第13回の自動検査と、この回のレビューは、混ぜないでください。見ているものが違います。
自動検査は、答えが一意に決まるものを見ます。型、書式、テストの成否。落ちたら直すしかありません。
Codex のレビューは、答えが一意に決まらないものを見ます。この変更で振る舞いが変わる範囲、抜けているテスト、想定していない入力への対応。指摘は参考意見であって、判定ではありません。
この違いは、指摘への対応のしかたに出ます。自動検査が落ちたら直します。レビューの指摘は、読んで、納得したら直し、納得しなければ理由を書いて残します。
人が最後に見る場所は変わらない
3つの目を通す形になりました。自動検査、Codex のレビュー、そして人。
人が見る場所は、前の2つが通ったあとに残るところです。この変更は何のためにあるのか。利用者にとって意味があるのか。将来これを読む人に分かるか。どれも、機械が判定できません。
第8回で「なぜ変えたかは差分からは絶対に読み取れない」と書きました。3つの目を通してなお、最後に残る仕事はそこです。
次の回
確かめる仕組みができました。第15回で、確かめたものを公開します。Vercel で、プルリクエストごとの確認用URLと、本番への反映を扱います。
参照した公式情報
- OpenAI「Codex cloud」「Review GitHub pull requests with Codex」「Code Review」(developers.openai.com/codex、2026年9月時点)
codex cloudとcodex reviewの引数は codex-cli 0.154.0 を執筆環境へ導入して取得
よくある質問
- クラウドで動かすと手元と何が違いますか
- 作業ごとに使い捨ての環境が立ち、そこでリポジトリを取り出して作業します。手元のパソコンを占有しないので、時間のかかる作業を投げておけます。一方で、手元にしかない資材や設定は使えないため、環境の設定を先に済ませておく必要があります。
- レビューを頼むのに何が要りますか
- 公式ドキュメントによれば、先に Codex クラウドの設定を済ませ、Codex の設定画面で対象のリポジトリに対してコードレビューを有効にします。そのうえで、プルリクエストのコメントで `@codex review` と書くと開始します。コメントに目のマークが付くのが、受け付けられた合図です。
- レビューの観点を指定できますか
- できます。公式の説明によれば、Codex はリポジトリの中の AGENTS.md を探し、そこに書かれたレビューの指針に従います。「個人情報を記録に出さない」「認証の処理が全部の経路を通っているか確かめる」のような項目を書いておけば、その観点で見ます。



