CodexとGitHub PR。AI変更を本番前で止める5手順
合同会社Leadfive 山下です。
Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。
さて、CodexにWebサイトや業務ツールの修正を頼む時、怖いのはAIが間違えることだけではありません。怖いのは、確認前の変更がそのまま公開や本番反映へ近づくことです。ブランチとGitHub PRを使うと、AIの作業を新人スタッフの下書きとして受け取り、責任者が見るまで金庫の鍵を渡さない流れにできます。
ブランチは、新人スタッフに渡す作業机です
ブランチは、AIに本番とは別の作業机を渡す仕組みです。
店のレジ締めで考えると分かりやすいです。新人スタッフに練習用の台帳で確認してもらい、正式な金庫には触らせない。GitHubの公式ドキュメントでも、ブランチは標準の場所に影響させず作業するための空間として説明されています。
Codexに修正を頼む時も同じです。いきなり本番ページを書き換えるのではなく、codex/fix-contact-copy のような短いブランチ名を作り、そこにだけ変更を入れてもらいます。ブランチ名は、社内の作業メモにもなります。
OpenAIのCodex changelogでは、2026-07-06のChatGPT iOS更新で、Codexタスクの作成、検索、フォーク、管理、ブランチ比較、変更フィルタが追加されています。スマホからAI作業を管理しやすくなるほど、どの変更をどこで止めるかのルールが大事になります。
出典:
PRは、店頭に出す前の確認トレイです
Pull Requestは、AIが作った変更をいきなり採用する場所ではなく、確認トレイです。
GitHubの公式ドキュメントでは、Pull Requestは変更を提案、レビュー、マージするための仕組みとして説明されています。小さい会社の運用に置き換えると、AIが作ったPOP、料金表、LP文言を、店頭に出す前に責任者の机へ置く動きです。
PRで見る場所は多くありません。
- 何を直したか
- どのファイルが変わったか
- テストやビルドは通っているか
- 画像、リンク、CTAに事故がないか
- 本番へ入れる前に人間承認が残っているか
この5つだけでも、AIに頼んだ作業を見失いにくくなります。
Codexに頼む時は、ブランチ名まで指定します
Codexへの依頼文には、作業内容だけでなく、ブランチ名、PRの出し方、止める操作まで入れます。
たとえば、LPの見出しを直すなら次のようにします。
このLPの見出しとCTA文言を改善してください。
作業ルール:
- 新しいブランチ `codex/lp-copy-review-20260708` で作業する
- 変更後はPull Request用の要約を作る
- 変更ファイル、意図、確認したこと、未確認のことを書く
- 公開、デプロイ、SNS投稿、広告、タグ変更は実行しない
確認してほしいこと:
1. 見出しが読者の悩みに合っているか
2. CTAが強すぎないか
3. 既存の内部リンクや画像を壊していないか
4. 差分に依頼外の変更が混ざっていないか
この形なら、Codexは作業係です。PRは確認トレイです。公開ボタンは責任者が持ったままです。
AGENTS.mdに、マージしてよい条件を書いておきます
AGENTS.mdは、AIに渡す入社初日の業務マニュアルです。
ブランチとPRを使う場合、AGENTS.mdには次のような条件を書いておくと、毎回の説明が短くなります。
mainやmasterへ直接変更しない- 公開、本番反映、SNS投稿、広告、タグ変更は人間承認で止める
- PR本文には変更理由、確認方法、未検証項目を書く
- 未公開URL、仮リンク、秘密情報、顧客情報があれば
blockとする - テストやプレビューが未実行なら、推測で
passにしない
AGENTS.mdの基本は、公開済み記事の AGENTS.mdを会社の業務マニュアルとして作る方法 でも整理しています。ブランチとPRは、その業務マニュアルを実際の変更管理に使う場面です。
公開前レビューとセットで使うと事故が減ります
PRは差分を見る場所で、公開前レビューは外に出す前の最終点検です。
この2つを分けると、AIに頼む仕事が整理されます。PRでは、どのファイルが変わったか、意図と差分を見ます。公開前レビューでは、リンク、画像、出典、CTA、公開後の導線を見ます。
Webサイト更新の全体像は CodexでWebサイト更新を頼む手順 と相性が良いです。外に出す直前の確認は Codex公開前レビュー に分けておくと、作業手順と最終確認が混ざりません。
そのまま使えるPR確認プロンプト
PRができたら、Codexや別のAIにレビュー係として見てもらいます。
このPull Requestを公開前の確認トレイとしてレビューしてください。
目的:
AIが作った変更を本番へ入れる前に、差分、リンク、画像、CTA、未検証項目を確認すること。
確認してほしいこと:
1. 変更内容が依頼と合っているか
2. 依頼外のファイル変更がないか
3. 未公開URL、仮リンク、秘密情報、顧客情報が混ざっていないか
4. テスト、ビルド、プレビュー確認の結果が書かれているか
5. 公開、デプロイ、SNS投稿、広告、タグ変更が実行されていないか
出力:
pass / revise / block のどれか。
blockの場合は、責任者が見るべき箇所を短く出してください。
公開前レビューの考え方は、Codex公開前レビュー。出す前に見る5項目 の応用です。PR確認は、外に出す前の事故を減らすための1段目です。
FAQ
GitHubが分からない経営者でも使う意味はありますか
意味はあります。細かいGit操作を覚えるより、AIの変更を本番とは別の場所で受け取り、PRで確認してから入れる感覚を持つことが先です。
CodexにPR作成まで任せてよいですか
PR作成までは任せやすい仕事です。ただし、マージ、本番反映、公開、SNS投稿、広告、タグ変更は人間承認で止めます。
小さい修正でもブランチを分けるべきですか
公開ページ、問い合わせ導線、価格、申込フォーム、広告に関わる修正は、小さく見えても分ける方が安全です。社内メモや一時資料なら、リスクに応じて軽くできます。
今日の作業: 次に頼む修正をPRで止めます
まずは次に直したい1ページだけで十分です。ブランチ名を決め、PRで確認し、公開や本番反映は人間承認で止める。この1回を作ると、AIに任せる仕事を増やしても事故を減らしやすくなります。
AIにすべてを任せるのではなく、作業机と確認トレイを分ける。小さい会社がCodexを実務に入れる時は、この距離感が一番現実的です。
出典
- OpenAI Codex Changelog
-
[Codex OpenAI Developers](https://developers.openai.com/codex/) - GitHub Flow
-
[About pull requests GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
このシリーズの順番
ブランチを作業机、PRを確認トレイとして使い、公開や本番反映を人間承認で止められる。次の作業は、次に頼む小さな修正を、ブランチ名とPR確認項目つきで依頼することです。