Codex GitHub PR
Codex作業をGitHub PRで確認するには
PRは、Codexが変えた内容を本番やmainへ入れる前に確認する場所です。
まず一言でいうと
Codexで作業し、GitHubで確認します
PRは、Codexが変えた内容を本番やmainへ入れる前に確認する場所です。
| 用語 | 一言でいうと | 何を見るか |
|---|---|---|
| Codex | 作業を頼むAI | ファイル修正・確認・報告 |
| Git | 変更履歴の仕組み | commit・branch・差分 |
| GitHub | 変更を保管して見る場所 | PR・diff・履歴 |
| PR | 変更を入れる前の確認場所 | 内容・差分・未確認事項 |
| diff | どこが変わったか | 追加行・削除行・変更ファイル |
このページで整理すること
Codexで作業した後に、GitHubやGitで何を確認すればよいかを初心者向けに整理します。GitHub公式やOpenAI公式の案内ではなく、実務で事故を避けるための確認メモとして読んでください。
Codexでできること
- 作業内容を報告する
- 触ったファイルを明記する
- 触っていないファイルを明記する
- 公開前チェック結果を出す
GitHub / Gitで確認すること
- 変更ファイル一覧
- 追加・削除された行
- PR本文の説明
- 未確認事項と停止条件
- merge前の安全確認
実際の作業フロー
- Codexに作業を頼む対象URL、対象ファイル、やること、やらないことを明確にします。
- 変更ファイルを見る作業対象以外のファイルが変わっていないか確認します。
- GitHubで差分を見る追加行、削除行、変更理由を確認します。
- Secretsや余計なファイルを確認するAPIキー、認証情報、ログ、.env が混ざっていないか見ます。
- PR本文を読む未確認事項、停止条件、確認結果を把握します。
- 人間がmerge判断するmain直pushや勝手なmerge、本番deployは軽く扱いません。
1人でもPRを挟む意味
PRは複数人でレビューするための仕組みですが、1人で運用する場合にも使う理由があります。
| 直接反映する | PRを挟む | |
|---|---|---|
| 変更内容の把握 | 作業しながらなので流れてしまう | まとめて差分として見られる |
| 確認のタイミング | 作業と確認が同時になり雑になる | 手を止めて確認する場が生まれる |
| 取り消し | すでに反映済み | 反映前なので破棄できる |
| 後から見返す | 変更単位が分かりにくい | 作業のまとまりとして残る |
1人運用で効くのは2行目です。作業と確認を同じ流れの中でやると、自分の作ったものを疑いにくくなります。PRという区切りがあると、「作る人」から「確認する人」へ意識を切り替える機会になります。
PRに書いておくと後で助かること
1人運用なら説明文は不要に思えますが、数か月後の自分のために書いておくと役立ちます。
- 何を変えたか：一行で構いません。差分を読み直さなくても思い出せます。
- なぜ変えたか：後から「これは何のための変更だったか」と迷わなくなります。
- 確認したこと：どこまで検証済みかが分かれば、不具合時の切り分けが早くなります。
- 確認していないこと：これが最も価値があります。書いてあれば、後で疑う場所が分かります。
最後の項目を書く習慣をつけると、「確認済み」と「未確認」が区別された記録が残ります。何も書かれていないと、確認したのか忘れただけなのか判断できません。
やってはいけないこと
PRを見たからといって、すぐmergeしてよいとは限りません。Secrets、想定外ファイル、本番影響を確認してから人間が判断します。
- GitHub上の重い操作は、人間が範囲と結果を確認してから判断する。
- main直push、勝手なmerge、本番deployを軽作業扱いしない。
- APIキー、トークン、秘密鍵、GitHub Secrets、認証情報を本文に出さない。
- DB、cron、.htaccess、AdSense、Search Console確認タグ、robots.txt、ads.txtを触らせない。
- 成果や検索順位、安全性を約束する表現を書かない。
| 場面 | 見ること | やらないこと |
|---|---|---|
| 外出先 | 報告書、URL、差分 | 本番deploy |
| スマホ | 表示確認、軽い指示 | merge判断の即決 |
| 別PC | PR確認、差分確認 | 認証情報の表示 |
| 移動中 | 次の指示整理 | 危険ファイル変更 |
関連ページ
FAQ
Codexにcommitやpushを任せていいですか？
作業範囲やチームルールによります。初心者向けには、まず差分とPRを人間が確認し、main直pushや勝手なmergeを避ける方が安全です。
GitHub Secretsの値をCodexに貼ってもいいですか？
貼らないでください。Secrets、APIキー、トークン、秘密鍵、認証情報は具体値を出さず、必要になった時点で停止条件にします。
スマホでPRをmergeしてもいいですか？
スマホでは差分や報告の確認までに留め、mergeやdeployのような重い判断はPCで落ち着いて確認するのが安全です。
Gitの危険なコマンドも覚える必要がありますか？
初心者ページでは危険なコマンド例を扱いません。戻し作業が必要な時は、対象を確認して別作業として慎重に進めます。
GitHub IssueでCodex作業を管理する
Codex作業をIssueに整理すると、作業依頼、停止条件、PR差分、報告書、未完了タスクをつなげて確認しやすくなります。秘密情報はIssueに書かず、PRや報告書で差分を確認します。
CodexとClaude Codeを勝ち負けではなく使い分ける
CodexとClaude Codeは、どちらが上かではなく、Web制作、GitHub作業、指示書、報告書、安全確認のどこで使うかを分けて考えると実務で扱いやすくなります。