CodexでGitHubのPR作成｜失敗を防ぐ手順

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexに修正を頼んでGitHubのPRができた。でも、どのIssueに対応し、何をテストして、どこが未確認なのかわからない。これでは、コードを書く時間が減っても、レビューする人の手間が増えてしまいます。

CodexでGitHubのPRを作るなら、最初に決めたいのは自動化するクリック数ではなく、受け取る変更と確認の証拠です。Issueの完了条件、作業ブランチ、テスト結果、コメント対応の担当をそろえると、PRを作った後まで見通せます。

この記事は2026年10月18日時点のOpenAI公式資料と、本文を確認できたXの公開投稿を調査してまとめています。osuke本人の実装体験や効果測定ではありません。登場するIssue番号、リポジトリ名、ブランチ名は説明用の架空例で、実際にGitHubへ変更を加えた結果ではありません。

記事のポイント

• Issueに完了条件と変更しない範囲を書く
• 作業ブランチとテストした状態を一致させる
• PRには確認結果と未実行の項目を残す
• レビュー対応とマージの判断を別工程にする

CodexでGitHubのPRを作る

Issueは依頼内容、ブランチは変更をまとめる場所、PRは変更を比較して相談する入口です。この三つを一つの仕事としてつなぎながら、書き込みや公開の許可は工程ごとに区切ります。まずは小さな不具合修正を例に見ていきましょう。

Issueに完了条件を書く

Issueのタイトルだけを渡すと、直してほしい範囲が広く解釈されることがあります。「入力チェックを改善して」では、画面の文言変更なのか、保存処理の修正なのか、仕様そのものの見直しなのかが曖昧ですね。まず、現在の挙動、期待する挙動、再現条件、変えない範囲をそろえます。IssueのURLを添える場合も、Codexがその内容を読めるとは限りません。読み取れないときは必要な本文を渡し、見えていない要件を推測で補わせないようにしましょう。

架空のIssue #42を「タスクのタイトルが空白だけなら保存しない」とします。完了条件は、空文字を拒否すること、半角スペースだけの入力も拒否すること、通常のタイトルは保存できることの三つです。既存のエラー表示方法を使い、画面の配色、データベースの構造、認証の仕組みは変えないと添えます。ここで全角空白や改行も対象にするか決まっていなければ、それは実装者が勝手に広げる項目ではなく、仕様として確認する項目です。

大切なのは、「きれいに直す」という感想を、合否を確認できる条件に変えることです。何ができれば終わりか決まっていないと、AIがコードを増やしても、依頼した人は完成を判断できません。最初の依頼は実装まで進めず、「Issueを読んで、完了条件と曖昧な点、変更候補を整理して」とする方法もあります。全体の使い方から確認したい場合は、Codexの総合ガイドも合わせて読むと、委任する仕事の切り方をつかみやすくなります。

• 現状：空白だけでもタスクが保存される
• 期待：決めた空白条件では保存せず、既存方式でエラーを返す
• 確認：拒否する入力と、引き続き保存できる入力を分ける
• 範囲外：配色変更、認証改修、データ構造変更などを明記

接続と作業環境をそろえる

GitHubの情報を読めること、手元のコードを変更できること、リモートへpushできることは別です。接続済みだからといって、すべてのリポジトリや操作が使えるとは考えないでください。対象のリポジトリに必要なアクセスがあり、コードとテストを動かせる環境がそろっているかを確認します。デスクトップアプリでの作業と、GitHub上のCodexレビュー連携も入口が違います。どちらを使う仕事なのかを先に区別すると、設定の取り違えを減らせます。

架空のdemo/todo-appなら、「このリポジトリの作業環境で、既存テストが動くかを確認し、結果を報告して。まだコード変更やpushはしない」と依頼できます。必要な依存関係やテスト用サービスが不足していたら、そこを解決してから修正へ進みます。画面上でファイルが見えるだけでは、テスト可能な状態とは限りません。ローカルと別の作業環境では設定が異なることもあるため、普段動いている環境と同じ前提だと決めつけないことが大切です。

現行の公式資料では、デスクトップのCodexに差分確認、コミット、push、PR作成などのGit操作が案内されています。ただし、利用中の環境や連携、権限によって進められる範囲は変わります。PR作成まで使えない場合でも、差分とPR説明文を受け取り、通常の手順で人が作成する形なら仕事を引き継げます。操作できないたびにアクセス範囲を広げるのではなく、「今できる工程」と「追加の判断が必要な工程」を分けて確認しましょう。

• 読み取り可能と、変更・push可能を混同しない
• テスト用サービスが使えないなら、先に環境を整える
• PR作成が使えなければ、差分と説明文で引き継ぐ

ブランチと開始地点を確認する

修正を始める前に、どのリポジトリの、どの状態から変更するかを確かめます。対象外の変更が混ざっていたり、別の作業ブランチを開いていたりすると、小さなIssueでもPRの差分が大きくなります。ブランチ名だけでなく、開始時のコミットと未コミットの変更も確認してください。既存の変更はユーザーや他の作業者のものかもしれません。作業しやすくするために勝手に消したり、今回のコミットへまとめたりするのは避けたいところです。

説明用の作業ブランチ名をfix/42-empty-titleとします。これは推奨の固定名ではなく、チームの命名規則に合わせて変える例です。同様に、取り込み先がmainとは限らないので、実際の対象ブランチを指定します。確認には、git status --shortで作業中の変更、git branch --show-currentで現在のブランチ、git rev-parse HEADでコミットを調べる方法があります。これらは確認用の例で、この記事で実リポジトリに対して実行した結果ではありません。

ほかの仕事と並行するなら、作業場所を分ける方法も検討しましょう。ただし、場所を分けても、テスト用の設定や依存関係まで自動的に同じになるとは限りません。分離した場所でも必要な確認を行うのが前提です。詳しい考え方はCodexのワークツリーの使い方で整理しています。開始地点が違っていたら、実装を続けるより先に止めて確認する。その一手間が、後から差分をほどく手間を減らします。

• リポジトリ：似た名前の別プロジェクトではないか
• 開始地点：指定したブランチとコミットになっているか
• 既存変更：今回の作業以外の変更が残っていないか
• 禁止：無断で変更を破棄、取り込み先へ直接push、強制pushしない

変更範囲とテストを結び付ける

実装では、Issueの完了条件を満たすために必要な変更へ絞ります。入力チェックを直すついでに画面全体を作り直すと、何が不具合に関係する変更なのか見分けにくくなりますね。最初に既存の書き方やテスト方法を読み、同じ方針で小さく直すよう依頼します。変更前に既存チェックが通るかを確認しておけば、変更後の失敗が最初からあったのか、今回の変更で生まれたのかも分けて考えやすくなります。

Issue #42では、拒否したい入力だけでなく、通常入力の保存も確認対象にします。禁止条件のテストだけが通っても、通常の保存を壊していたら目的を達成していません。新しいテストが旧コードの問題を検出でき、修正後に通るかも、実施できる範囲で確認します。ただし、まだ存在しないテストや、動かせないサービスを「確認済み」に含めてはいけません。次の表は確認方法の設計例であり、実際に実行して成功した結果ではありません。

一つのテスト結果を、アプリ全体の安全性へ広げないことも大切です。入力欄のチェックと保存処理のチェックでは、保証する範囲が違います。必要な回帰テストや型チェックなどは、リポジトリのルールと変更内容に合わせて選びます。詳しい確認の組み方はCodexのコードレビューとテストの記事も参考になります。テストの数を飾るより、「この条件を、この確認で確かめた」と対応を示すほうが、レビュー担当に伝わります。

• 条件と確認方法を一対一で結び付ける
• 禁止ケースと、引き続きできるケースを両方確認する
• 未実行、既存の失敗、今回増えた失敗を分けて報告する

ドラフトPRに証拠を残す

PRは変更の置き場であると同時に、レビューする人への引き継ぎ資料です。「Issue #42を修正」だけでは、何を変え、どこまで確かめたかが伝わりません。目的、変更内容、条件ごとの確認結果、未実行項目、残った判断を短く整理しましょう。OpenAIの公式ユースケースでも、範囲を定めたIssueに対し、実装だけでなく検証の証拠を含む変更を受け取る流れが示されています。差分と説明を一緒に読むことで、確認漏れを見つけやすくなります。

架空のPR説明なら、「目的：空白だけのタイトルの保存を防止」「変更：既存の検証処理と関連テスト」「確認：実行したコマンド、結果、対象コミット」「未確認：手元で起動できないサービスの結合試験」「担当への依頼：未確認試験と文言の確認」といった項目にします。結果欄には実際の確認後に内容を入れ、例の文章をそのまま成功報告にしないでください。追加の修正を入れた後は、以前のコミットの結果を最新の証拠として使い続けないことも重要です。

利用環境がPR作成に対応し、対象への書き込みが許可されているなら、最初はドラフトPRまでという区切りにできます。ドラフトであっても、push先の公開範囲や自動処理には注意が必要で、完全な非公開・無影響の保管場所ではありません。機能が使えない場合は、差分と説明文までで引き継げば大丈夫です。出典はOpenAI公式「Issueから検証済みPRへ進める手順」です。PR作成を、マージや本番反映の許可まで含む指示にしないようにしましょう。

• 目的と変更内容：Issueの条件と差分の対応
• 証拠：実行コマンド、結果、確認したコミットや作業状態
• 未完了：未実行テスト、残る疑問、人が判断する事項
• 作成後：PRのURL、取り込み先、作業ブランチを報告

CodexとGitHubのPR運用の注意点

PRができた後も、レビューを依頼する、指摘を直す、CIを確認する、取り込みを判断するという仕事が残ります。ここを「自動で続くはず」と曖昧にしないことがポイントです。どの操作で何が起きるかを分けて見ていきます。

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

GitHub上のCodexレビューを利用する場合、現行の公式ガイドでは、接続済みリポジトリとレビュー設定を確認し、PRコメントで@codex reviewと依頼する方法が案内されています。これは変更を確認して指摘を受け取る入口であり、指摘をすべて直してマージするところまでを一度に意味するものではありません。自動レビューを使う場合も、リポジトリ側と個人側の設定などを確認します。コメントを書けば、どの環境でも必ず反応するという保証ではありません。

指摘が出た後は、「この指摘の内容を確認し、Issueの範囲内なら同じ作業ブランチで修正。誤検知や仕様判断が必要なら根拠を示して止める」と、対応する仕事を指定します。たとえば空白チェックの修正に対し、無関係な認証処理の作り直しを提案されたら、そのまま変更範囲を広げる必要はありません。必要な改善でも今回のIssueと分けるべきかを判断します。レビューを受ける工程と、実装を許可する工程を分ければ、意図しない変更を抑えられます。

レビューの基準をAGENTS.mdに残すなら、「既存の入力検証の方針を維持する」など、プロジェクト固有の重要な条件を簡潔に書きます。形式的なチェックを大量に並べるより、何を守る必要があるかを説明するほうが役立ちます。ただし、AI向けの指示は、テスト、ブランチ保護、必要な承認の代わりにはなりません。「Codexが問題なしと言ったから、人の確認もCIも不要」と扱わないことが大切です。指摘がないことと、すべての不具合が存在しないことは別ですね。

• レビュー依頼：差分を見て問題点を挙げてもらう
• 修正依頼：対応する指摘と変更範囲を具体的に指定する
• 設定確認：接続リポジトリとレビューの利用条件を見る
• 最終判断：AIレビューをテストや必要な承認の代わりにしない

CIと未実行テストを確認する

CIが緑になったら一安心ですが、「緑の表示がある」だけで必要な確認が全部終わったとは限りません。どのチェックが動き、どのコミットを対象にし、何がスキップされたかを見ます。ローカルのテスト成功と、GitHub上のCI成功も別の記録です。環境が違えば結果が変わることがありますし、画面の動作を確認する試験が自動チェックに含まれていないこともあります。表示の色より、実際に何を確かめたかを確認するのが基本です。

Issue #42で、検証処理のテストは通ったものの、テスト用サービスが起動せず保存の確認をできなかった場合を考えます。この場合は「関連テストは成功、保存を含む結合試験は未実行」と分けて書きます。環境不足はコードの失敗と同じではありませんが、成功にもできません。また、変更前から失敗している別のテストを、今回の修正のために無断で削ったり、チェックを無効にして緑にしたりしないよう、依頼の段階で伝えておきましょう。

再実行を頼むときも、失敗したチェックとその状態を見てから対応します。必要なアクセスや仕様判断が欠けているなら、繰り返すだけでは進みません。機密情報を含まない範囲でエラーと確認済み事項を整理し、誰が何を用意すれば再開できるかを残します。修正が追加されたら、影響するチェックをもう一度行い、最新の変更と証拠をそろえてください。「テストを通す」ことではなく、必要な挙動が保たれていると判断できる状態を作ることが目的です。

• 成功：実行したチェック名と対象コミットを残す
• 失敗：変更前からか、変更後に発生したかを分ける
• 未実行：理由、必要な環境、次の担当を明記する
• 禁止：承認なくテストを削除・無効化して成功扱いにしない

コメント対応を同じPRで追う

PRにコメントが付いたことと、実装を担当するCodexのタスクがその内容を受け取ったことは同じではありません。連携や実行方法によっては、追加の指示が必要です。最初に「コメント対応まで誰が追うか」を決めておきましょう。レビュー側が指摘したまま、作成側は完了と思っていると、PRが止まってしまいます。自動で続くと確認できていない工程には、人が指摘を整理して渡す手順を用意しておくと、対応漏れを減らせます。

依頼例は、「このPRの未対応コメントを読み、今回のIssueに関係するものだけ整理してください。合意した指摘は同じブランチで直し、関連チェックを再実行。対応したコメントと修正コミットを報告してください。別PR作成やマージはしないでください」です。新しいタスクへ渡す場合も、PRのURL、作業ブランチ、最新コミット、対応済みと未対応の区分を渡します。「前の続き」だけでは、別の変更を見てしまう可能性があるためです。

途中で操作が止まっても、すぐ新しいPRを作り直すのは避けましょう。pushやPR作成が途中まで成功しているかもしれません。先に既存PRの有無、対象ブランチ、リモートの最新状態を確認してから再開します。また、コメントを解決済みにすることと、指摘の問題が実際に直ったことも分けて考えます。修正結果と確認の証拠がそろったうえで、チームの手順に沿って担当者が確認する流れにしてください。PRの数を増やすより、一つの変更を最後まで追えることが重要です。

• 引き継ぐ情報：PRのURL、ブランチ、最新コミット
• 対応記録：どの指摘を、どの修正で扱ったか
• 中断から再開：既存のPRとpush結果を確認してから進める
• 担当：コメントを拾う人と、最終確認する人を決める

Xの活用例とつまずきに学ぶ

Xでは、@rutinelaboの10月11日の投稿に、dotからCodexへ作業を渡しPRまで進める流れの紹介がありました。一方、@deyama_itの投稿では、画面遷移やデータ保持を手元で確認し、その内容をPRへ詳しく残し、見つかった問題をIssueにするという運用が書かれていました。これらは取得できた公開本文の要旨です。紹介動画の一連の動作を再現したわけではなく、自分の環境でも同じ条件で無人実行できることを証明するものではありません。

つまずきとしては、@kumadasuの10月14日の投稿に、作成したPRのコメントを自動で拾う方法への疑問がありました。レビューを出す側と、指摘を受けて直す側がつながらないという戸惑いです。また、@ikm_sanの投稿には、未使用コードの削除を短い観測だけで決めることへの注意がありました。後者は実際の削除事故の報告ではなく、判定条件への懸念です。個別の戸惑いや論評を、そのまま製品全体の不具合や仕様の根拠にはしません。

OpenAIの公式保守事例にも、削除候補の根拠を集め、人のレビューを含めて変更する流れが紹介されています。ここから参考にしたいのは削除量や速度の数字ではなく、変更理由と確認の証拠を示す姿勢です。今回の投稿群からも、PR作成の自動化だけでなく、検証と後続対応の設計が大切だと整理できます。ただし、少数の公開投稿から成功率は計算できません。現行環境で再現可能なPR作成障害の具体的手順も、今回の取得範囲では確認できていません。

• 活用紹介：自分の仕事へ取り入れる候補として読む
• 戸惑い：対象環境や連携が異なる個別の報告として読む
• 反対意見：事故の実証と、判断条件への懸念を分ける
• 記事の提案：PRの作成後に、証拠とコメント対応を引き継ぐ

CodexでGitHubのPRを始める

最初は、対象リポジトリの小さなIssue一件について、読み取りと計画だけを依頼してみてください。「このIssueを直してPRまで」よりも、「完了条件、変更候補、必要なテスト、不明点を整理して。まだ変更やpushはしない」と頼むほうが、対象が合っているかを確かめやすくなります。そこで条件がそろえば、実装と確認、許可したブランチへのpush、ドラフトPR作成という順に、必要な工程だけを追加していけます。

架空のIssue #42を使う依頼例は、「指定のリポジトリと開始コミットで、空白だけのタイトル保存を拒否する修正を検討してください。既存の検証方法を維持し、配色・認証・データ構造は変えません。先に受け入れ条件とテスト計画を報告してください。実装後は実行結果と未実行項目を残し、PR作成は私が許可した範囲だけ進めてください。マージ、本番反映、権限変更はしないでください」です。実際には、空白の定義や取り込み先を自分の仕様に置き換えます。

最後に受け取るのは、変更内容だけでなく、確認した状態と残った判断です。PRのURLがあれば取り込み先と作業ブランチを確認し、機能が使えなければ差分と説明文で引き継ぎます。コメントへの対応を誰が追い、誰がマージを判断するかも決めておきましょう。CodexとGitHubの連携は、PRを増やすためではなく、変更を確認して次へ進めるために使うものです。まず一件、条件と証拠がそろった仕事を受け取るところから始めるのがよいと思います。

• 今日の一歩：小さなIssue一件の条件と計画を整理する
• 実装前：環境、開始地点、変更範囲、必要なテストを確認する
• 引き継ぎ：差分、証拠、未実行項目、次の担当を残す
• 最終工程：PR作成、マージ、デプロイを別々に判断する