Codexの変更を公開前に確認する。GitHubの5手順
合同会社Leadfive 山下です。
Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。
さて、CodexにWebサイトや業務ツールの修正を頼む時、怖いのはAIが間違えることだけではありません。怖いのは、確認前の変更がそのまま公開へ近づくことです。GitHubは、変更を保存し、公開前に責任者が確認できるサービスです。本番と分けた作業場所を「ブランチ」、変更内容を責任者へ見せる確認画面を「Pull Request（プルリクエスト、略してPR）」と呼びます。
本番と分けた作業場所は、新人スタッフに渡す机です
GitHubで「ブランチ」と呼ばれる作業場所は、AIに本番とは別の机を渡す仕組みです。
店のレジ締めで考えると分かりやすいです。新人スタッフに練習用の台帳で確認してもらい、正式な金庫には触らせない。GitHubの公式ドキュメントでも、ブランチは標準の場所に影響させず作業するための空間として説明されています。
Codexに修正を頼む時も同じです。いきなり本番ページを書き換えるのではなく、codex/fix-contact-copy のような短いブランチ名を作り、そこにだけ変更を入れてもらいます。ブランチ名は、社内の作業メモにもなります。
OpenAIのCodex changelogでは、2026-07-06のChatGPT iOS更新で、Codexタスクの作成、検索、フォーク、管理、ブランチ比較、変更フィルタが追加されています。スマホからAI作業を管理しやすくなるほど、どの変更をどこで止めるかのルールが大事になります。
出典:
変更内容は、店頭に出す前の確認トレイで見ます
Pull Request（プルリクエスト、略してPR）は、AIが作った変更をいきなり採用する場所ではなく、確認トレイです。
GitHubの公式ドキュメントでは、Pull Requestは変更を提案、レビュー、マージするための仕組みとして説明されています。小さい会社の運用に置き換えると、AIが作ったPOP、料金表、LP文言を、店頭に出す前に責任者の机へ置く動きです。
PRで見る場所は多くありません。
- 何を直したか
- どのファイルが変わったか
- 動作確認や公開用の表示確認は通っているか
- 画像、リンク、問い合わせなどの案内に事故がないか
- 本番へ入れる前に人間承認が残っているか
この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は、AIに渡す入社初日の業務マニュアルです。GitHubでは、確認済みの変更を本番側へ取り込むことを「マージ」と呼びます。
ブランチとPRを使う場合、AGENTS.mdには次のような条件を書いておくと、毎回の説明が短くなります。
mainやmasterへ直接変更しない- 公開、本番反映、SNS投稿、広告、タグ変更は人間承認で止める
- 責任者の確認画面には変更理由、確認方法、未確認項目を書く
- 未公開URL、仮リンク、秘密情報、顧客情報があれば
blockとする - テストやプレビューが未実行なら、推測で
passにしない
AGENTS.mdの基本は、公開済み記事の AGENTS.mdを会社の業務マニュアルとして作る方法 でも整理しています。ブランチとPRは、その業務マニュアルを実際の変更管理に使う場面です。
変更確認と公開前の最終点検を分けると事故が減ります
責任者の確認画面は変更箇所を見る場所で、公開前レビューは外に出す前の最終点検です。
この2つを分けると、AIに頼む仕事が整理されます。変更確認では、どのファイルが変わったか、意図と変更箇所を見ます。公開前レビューでは、リンク、画像、出典、問い合わせなどの案内、公開後の導線を見ます。
Webサイト更新の全体像は CodexでWebサイト更新を頼む手順 と相性が良いです。変更箇所を見た後の画面確認は、Codexの公開前画面確認。スクリーンショットで失敗を減らす5手順 に分けておくと、パソコン幅とスマホ幅の違和感をAIへ戻しやすくなります。外に出す直前の確認は Codex公開前レビュー に分けておくと、作業手順と最終確認が混ざりません。
2026年7月9日の更新では、GitHub PRをCodexのサイドバーで差分とレビュー意見とともに確認できるようになりました。変更点はCodexのChatGPTデスクトップアプリ統合の解説で公式画面と一緒に整理しています。
そのまま使える変更確認の依頼文
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投稿、広告、タグ変更は人間承認で止めます。
小さい修正でもブランチを分けるべきですか
公開ページ、問い合わせ導線、価格、申込フォーム、広告に関わる修正は、小さく見えても分ける方が安全です。社内メモや一時資料なら、リスクに応じて軽くできます。
今日の作業: 次に頼む修正を公開前で止めます
まずは次に直したい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で差分を確認する前に、どの操作だけを人間が握るか決めたい場合は、CodexでAIに仕事を任せる前に、社長が決める4つのことも確認してください。
このシリーズの順番
本番と分けた作業場所と責任者の確認画面を使い、公開や本番反映を人の確認で止められる。次の作業は、次に頼む小さな修正を、本番と分けた作業場所と確認項目つきで依頼することです。