Codexでアプリを修正していると、突然「Pull Request」「Create PR」「Merge」といった言葉が出てくる。
正直、最初はかなり分かりにくい。
「Codexが修正してくれたなら、もう終わりじゃないのか？」「プルリクエストを作ったらサイトに反映されるのか？」「Mergeを押して大丈夫なのか？」と不安になる人も多いはずだ。
しかし、結論から言えばそれほど難しい話ではない。
プルリクエストとは、Codexが作った変更をいきなり本番コードへ入れず、「この変更を採用していい？」と確認するための仕組みだ。
しかも、これはCodex専用の機能ではない。GitHubにもともとある重要な仕組みである。GitHub公式も、Pull Requestを「あるブランチの変更を別のブランチへ統合する提案」と説明している。
Codexを本格的に使うなら、プルリクエストは避けて通れない。
逆に、ここさえ理解すればCodexでのアプリ開発はかなり安心して進められる。
Codexのプルリクエストとは？
プルリクエストは「変更を入れてください」という申請
プルリクエストは英語で「Pull Request」、略して「PR」と呼ばれる。
GitHubでは、通常いきなりメインのプログラムを書き換えるのではなく、別の場所で変更を作る。
たとえば、現在動いているアプリが次の状態だったとする。
main
↓
現在公開しているアプリ
ここでCodexに、
ログイン画面にパスワード再設定機能を追加して
と依頼したとする。
Codexが直接mainを書き換えるのではなく、別のブランチで作業する場合は次のような形になる。
main
├─ 現在のアプリ
│
└─ feature/password-reset
└─ Codexが修正したコード
まだmainは変わっていない。
そこでCodexが、
「feature/password-resetで作った変更をmainへ入れてもいいですか？」
とGitHub上で提案する。
これがプルリクエストである。
人間社会は何かを変更するだけでも申請書が必要だが、プログラムの世界でも似たようなことをやっている。ただし、こちらはかなり意味がある。
変更内容を確認してから採用できるからだ。
GitHubではプルリクエスト上で変更されたファイル、コミット、レビュー、チェック結果などを確認できる。
PRを作っただけではプログラムは変わらない
ここはかなり重要だ。
プルリクエストを作成しただけでは、通常mainのプログラムは変更されない。
まだ「変更してもいいですか？」と申請している段階だからだ。
つまり、
Codexがコードを書く
↓
Pull Requestを作る
↓
変更内容を確認する
↓
Mergeする
↓
mainへ変更が入る
という流れになる。
私なら、Codex初心者ほどこの流れを使ったほうがいいと思う。
Codexはかなり高度な修正までできるが、AIが変更したコードを何も確認せずmainへ直接入れるのは危険だからだ。
Codexでよく出てくる「ブランチ」とは？
mainはアプリの本体だと考えると分かりやすい
GitHub初心者がプルリクエストで混乱する原因の一つが「ブランチ」である。
難しく考える必要はない。
mainを現在の完成版だと考えればいい。
main
＝現在採用しているコード
そして、新しい機能を作るときにコピーを作る。
main
│
├─ login-fix
├─ new-dashboard
└─ payment-update
このコピーがブランチである。
Codexはブランチ側を自由に変更できる。
たとえ変更に問題があっても、mainを直接変更していなければ元のプログラムは残る。
これがかなり強い。
Codexの変更を隔離できる
たとえばCodexへ、
「投資管理アプリの現在地画面を全面的に作り直して」
と依頼したとする。
かなり大きな変更になる。
mainを直接書き換えた場合、途中でレイアウトが壊れたり計算機能に問題が出たりすると面倒だ。
しかし、別ブランチなら話は簡単になる。
main
正常に動いている
↓
codex/redesign-dashboard
Codexが大規模修正中
Codex側で何が起きてもmainには影響しない。
完成後に確認して問題なければPRを作る。
そのため私は、ある程度大きな修正ほどPR方式と相性がいいと考えている。
Codexでプルリクエストを作ると何が起こる？
Codexの変更内容がGitHubへ送られる
CodexはGitHubと連携することで、作業結果からGitHubのプルリクエストを開くことができる。OpenAIもCodexの機能として、結果を確認したあとGitHubのPull Requestを作成できると案内している。
PRを開くと、GitHub上では主に次の情報を確認できる。
| 項目 | 意味 |
|---|---|
| Conversation | PRの説明やコメント |
| Commits | 行われた変更の履歴 |
| Checks | 自動テストなどの結果 |
| Files changed | 実際に変更されたコード |
| Merge | 変更をmainへ統合する操作 |
特に初心者が見るべきなのは「Files changed」である。
Codexがどのファイルを変更したのかが分かる。
プルリクエストには変更履歴が残る
PRを使うメリットは、単に安全なだけではない。
「なぜこのコードを変更したのか」が残る。
たとえば数か月後、
このログイン処理、なんでこんなコードになっているんだ？
という事態が起きる。
開発を続けていると、本当に普通に起こる。
PRが残っていれば、
ログイン処理のエラー修正
↓
Codexが○○を変更
↓
テスト実施
↓
問題がなかったためMerge
という流れを確認できる。
一人でアプリを開発する場合でも、この履歴はかなり役に立つ。
Codexの「Merge」とは？
Mergeすると変更がmainへ入る
プルリクエストを確認し、問題がなければ「Merge」を実行する。
Mergeとは「統合する」という意味だ。
つまり、
Codexが変更したブランチ
+
main
↓
統合
となる。
ここで初めてCodexが作った変更がmainへ入る。
Pull RequestとMergeを混同すると危ない。
整理するとこうなる。
Pull Request
＝変更を提案する
Merge
＝変更を採用する
この違いだけでも覚えておくべきだ。
Mergeしたら本番サイトも変わる？
これは開発環境による。
GitHubのmainへMergeしただけで、自動的にWebサイトが更新される環境もある。
たとえばGitHubとVercelなどを自動連携している場合だ。
一方で、
Merge
↓
サーバーへアップロード
↓
本番反映
という追加作業が必要な環境もある。
そのため、
「Merge＝必ず即公開」ではない。
GitHubとサーバーの設定次第だ。
逆に自動デプロイを設定している場合は、Mergeした直後に本番へ反映される可能性がある。
だからこそ、Merge前の確認は重要になる。
Codexはプルリクエストのレビューもできる
Codex自身にPRを確認させることも可能
現在のCodexはコードを書く側だけではない。
Pull Requestをレビューする機能も用意されている。
OpenAIはCodexのコードレビューについて、PRの目的と実際の変更内容を比較し、コードベースや依存関係も確認しながら問題を探せるとしている。
GitHub上で、
@codex review
と依頼してレビューさせる方法も案内されている。
つまり、
Codexに修正させる
↓
PRを作る
↓
Codexにレビューさせる
↓
人間も確認する
↓
Merge
という運用もできる。
AIが書いたコードを同じAIに確認させるのは少し不思議に見えるが、レビュー時には別の視点でコード全体を調べられるため意味はある。
ただし、最後まで人間が確認する仕組みは残したほうがいい。
特に、
- 課金処理
- ログイン
- データベース
- 個人情報
- データ削除
- 管理者権限
などを変更した場合は慎重に確認するべきだ。
Codexでは毎回プルリクエストを作るべき？
小さな修正なら必須ではない
すべての変更でPRを作らなければならないわけではない。
たとえば、
ボタンの文字を修正
誤字を修正
余白を少し変更
程度なら、直接変更してしまう運用もある。
個人開発なら特にそうだ。
PRを毎回作ると管理作業が増える。
安全性は高くなるが、何でもPRにすればいいわけではない。
大きな変更ではPRを使ったほうがいい
一方、私は次のような変更ならPRを使うほうが安心だと思う。
ログイン機能変更
決済機能変更
データベース変更
大規模UI変更
複数ファイルの修正
新機能追加
API変更
こうした変更は、一つのミスでアプリ全体へ影響する可能性がある。
PRなら変更内容をまとめて確認できる。
問題があればMergeしなければいい。
この「採用しない」という選択肢を残せるのが強い。
CodexでPRを使うおすすめの流れ
1.Codexへ修正内容を伝える
まずCodexへ普通に依頼する。
たとえば、
ログイン画面にパスワード再設定機能を追加してください。
既存のログイン機能は壊さないでください。
実装後にテストしてください。
くらいでいい。
2.Codexに実装とテストをさせる
Codexにコードだけ書かせて終わりにしない。
可能なら、
変更後に既存テストを実行してください。
今回追加した機能についてもテストしてください。
まで指示したほうがいい。
GitHubのPull Requestでは自動テストやビルドなどのChecksを確認することもできる。
3.Pull Requestを作成する
Codex側からPRを作成する。
ここではまだmainには入らない。
慌ててMergeする必要もない。
変更内容を確認する。
4.Files changedを確認する
最低限、
変更ファイル数
削除されたコード
追加されたコード
関係ないファイルが変更されていないか
くらいは確認したい。
特にCodexへ大きな指示を出した場合、想定していなかったファイルまで変更されることがある。
ここは見るべきだ。
5.必要ならCodexへ修正させる
PRを確認して問題が見つかったら、すぐMergeする必要はない。
さらにCodexへ、
この部分は変更しないでください。
元の処理に戻してください。
などと依頼すればいい。
PRは作成して終了ではない。
修正を追加しながら完成させるためにも使える。
6.問題がなければMergeする
テストと変更内容を確認して問題がなければMergeする。
これでmainへ変更が入る。
GitHub公式でも、Pull Requestはレビューや必要なチェックが完了したあとMergeする流れとして説明されている。
Codex初心者ほどプルリクエストを使ったほうが安全
Codexを使い始めると、AIが想像以上に多くのコードを変更してくれる。
これは便利だ。
ただ、便利すぎる。
人間が数時間かけて行う変更を短時間で進めるため、何を変更したのか把握しないまま作業が進むこともある。
そこでPRが役に立つ。
Codex
「修正しました」
↓
Pull Request
「実際に何を変えた？」
↓
人間
「問題なさそう」
↓
Merge
「採用」
この一段階を入れるだけでも事故はかなり防ぎやすくなる。
個人開発では「自分しか触らないからPRはいらない」と考えたくなる。
私も合理性だけなら、小さな変更ではそれで問題ないと思う。
しかし、Codexへ大規模な修正を任せるなら話は別だ。
AIが作業する速度が上がるほど、人間側には「確認する場所」が必要になる。
PRはその確認場所として非常に使いやすい。
まとめ｜Codexのプルリクエストは「変更を採用する前の確認場所」
Codexのプルリクエストは難しい機能に見えるが、本質は単純だ。
Codexが変更したコードをmainへ入れる前に、一度確認するための仕組みである。
覚える順番もこれだけでいい。
Codexが修正
↓
ブランチへ変更
↓
Pull Request
↓
変更内容を確認
↓
Merge
↓
mainへ反映
特に重要なのは、
PRを作っただけでは、通常mainは変更されない。
という点だ。
そしてMergeすると、その変更がmainへ入る。
私なら、誤字修正のような小さな変更まで無理にPR化する必要はないと考える。一方、ログイン、データベース、決済、新機能追加、大規模なリファクタリングなどはPRを使う。
Codexの性能が高くなるほど、この考え方は重要になる。
「AIがコードを書けるから確認しなくていい」のではない。
AIが大量のコードを書けるようになったからこそ、変更を確認してから採用できる仕組みが必要なのだ。
GitHub公式ではPull Requestを、変更を提案・議論・レビューしてからMergeする仕組みとして説明している。Codexもその仕組みを使ってGitHub上で変更を安全に扱える。
公式情報：GitHub Docs「About pull requests」
公式情報：OpenAI「Codex が登場」
公式情報：OpenAI「Introducing upgrades to Codex」
コメント