GitHubでCodexにレビューを頼む

GitHubのプルリクエスト（PR）は、変更を取り込む前に内容を確認する場所です。Codexにレビューを頼むときも、対象のPR、返ってきた指摘、修正後の確認を分けて進めます。この記事はGitHub上のレビューが対象で、手元の差分を見る方法は変更確認の基本をご覧ください。

先に対象と接続を確かめる

公式手順では、対象リポジトリのCodex cloudを準備し、コードレビュー設定へアクセスできる必要があります。リポジトリのCode reviewを有効にしたうえで依頼します。自動レビューの設定にはGitHub側のpushまたは管理権限も関わります。公式GitHub連携ガイド

始める前に次を確認します。

• PRが自分の確認したいリポジトリにあること。
• 変更元と取り込み先のブランチが意図どおりであること。
• Files changedで、無関係な変更が混ざっていないこと。
• 組織の手順上、レビュー連携を利用できること。

他の人が使っている本番のPRで練習するより、目的を絞った小さなPRから始めると結果を読みやすくなります。

各段階で確認してから、次の操作へ進みます。

1. 1対象を確認リポジトリとPRの変更範囲を確かめます。
2. 2レビューを依頼レビューの反応と結果を分けて確認します。
3. 3指摘を検証根拠を見て修正し、再度テストします。

具体的な依頼と、結果の確かめ方は本文にあります。

レビューへの反応が出た段階と、結果が投稿された段階は別です。

PRのコメント欄から依頼する

準備済みの対象PRで、次のコメントを投稿します。

@codex review

これはGitHubへ実際に投稿する操作です。Codexが反応した後、レビュー結果を待ちます。手元のチャットへこの文字を書いただけでは、GitHub上のレビュー依頼になりません。

GitHubのCodexレビューは重大度の高いP0・P1に絞って指摘する仕様です。指摘がない場合も、文章表現や軽微な不具合を含めてすべて問題なしとは判断しません。テストや必要な人のレビューを続けます。

指摘を根拠と一緒に読む

次は読み取り方の例で、実際のレビュー結果ではありません。

分からない指摘を、ただ正しそうだからと修正しないようにします。まず再現条件を説明してもらい、必要な検査を決めます。

修正の依頼はレビューと分ける

レビュー後に修正を頼むと、権限に応じてクラウドの作業が開始され、ブランチへ変更が送られることがあります。自分で修正するか、Codexへ任せるかを決めてから進めます。

手元で指摘を検討するための依頼例です。

このレビュー指摘について、根拠のコードと再現条件を確認してください。
まだ修正やコミットはしないでください。
正しい指摘か、追加確認が必要か、対象外かを理由付きで整理し、
必要なら最小の検証方法を提案してください。

修正後は、差分が意図した範囲かを見てテストを行います。レビューコメントへ返答しただけで修正済みとは扱いません。

反応がないとき

Code reviewが対象リポジトリで有効か、Codex cloudの対象と合っているか、PRのコメントで正確に依頼したかを確認します。自動レビューの場合は、そのPRイベントが設定の対象かも確認します。短時間に同じコメントを何度も投稿する前に、設定とタスクの状態を見ます。

この記事は公式手順の説明と確認用の依頼例です。GitHubへの接続設定変更やレビューコメント投稿は実施しておらず、連携の実機動作は未検証です。