制作会社がCodex Desktopを使う前に決めること: 差分レビュー、PR、公開確認

制作会社の公開前チェックで、差分画面、PR、ステージングURL、クライアント承認メモが別々に開いたままだと、Codexに「レビューして」と頼んでも公開事故は止まりません。今日まず直す1箇所は、Codex Desktopを使う前に、差分レビュー、PR対応、公開確認を3つの作業に分ける表です。

この記事では、制作会社がCodex Desktopと呼んでいる作業画面を、公式表記ではChatGPT desktop app上のCodex作業、Codex CLI、IDE extension、review pane、/reviewの組み合わせとして扱います。狙いは、AIに公開判断を丸投げする話ではありません。Webサイト、LP、採用ページ、キャンペーンページを公開する前に、Codexへ見せるもの、人が止めるもの、PRで直すものを分けます。

参考にした一次情報は、OpenAIのChatGPT desktop app、Code review、AGENTS.md、Subagents、Best practices、Agent approvals and securityです。Azure DevOps側の承認フローは制作会社のAzure DevOps公開フローでも扱いました。

この記事の要点

• Codex Desktopという呼び方をする前に、実際にはChatGPT desktop app、CLI、IDE extension、review pane、/reviewのどれを使うかを決める。
• 制作会社では、差分レビュー、PRコメント対応、ステージングURL確認、本番公開承認を同じチャットに混ぜない。
• Codexには差分要約、/review、抜け漏れ表、修正案作りを任せる。公開日時、料金表現、広告表現、クライアントOK、本番承認は人が見る。
• AGENTS.mdには、制作会社のPR期待値、スマホ確認、フォーム送信、計測タグ、戻し方を短く書く。
• 成果は「AIが直した行数」ではなく、手戻り件数、公開前差し戻し、問い合わせフォーム事故、クライアント確認時間で見る。

制作会社のCodex利用で起きる失敗シーン

ディレクターが見ている画面は、GitHubやAzure ReposのPR、ChatGPT desktop appのCodexチャット、ステージングURL、Figma、クライアントのチャットです。ここで「この差分レビューして」とだけ頼むと、Codexはコード上の問題は拾えても、クライアントが承認した文言、公開日時、広告配信との同時公開までは判断できません。

よくある失敗は、Codexのレビュー結果を「公開OK」と読み替えることです。/reviewは差分や未コミット変更を見て、優先度付きの指摘を返すためのものです。公式のCode reviewページでも、review paneは差分を見て、行ごとのフィードバックやstage、revert、commit、pushの判断を助けるものとして説明されています。公開承認そのものではありません。

もう1つの失敗は、作業チャットが長くなりすぎて、どの修正がPR用で、どれが公開前確認で、どれがクライアント確認なのか分からなくなることです。公式のSubagents説明では、複数エージェントは探索、テスト、ログ分析のような読取中心の作業に向く一方、書き込みが多い並列作業は衝突しやすいとされています。制作会社でも、差分確認は分けてよいですが、同じLPを複数エージェントに同時編集させるのは避けます。

Codexに任せる範囲と人が見る範囲

PR画面とステージングURLを前にして、Codexに任せるのは「見落としを表にする作業」です。変更ファイル、差分の目的、フォーム、リンク、画像、meta description、計測タグ、レスポンシブ崩れ、戻し方をリストにします。/reviewを使う場合は、base branch、未コミット変更、commit、custom instructionのどれを見るかを先に決めます。

人が見る範囲は、料金、法務・広告表現、医療や採用に近い表現、クライアント承認、公開日時、請求や納品範囲、本番反映です。Codexは「ステージングではフォームが送れた」と確認する補助にはなりますが、「この料金訴求で公開してよい」とは判断しません。制作会社では、この線引きを記事やAGENTS.mdに残す方が、毎回の口頭説明より強いです。

AGENTS.mdには長い理想論ではなく、実務の門だけを書きます。たとえば「LP修正ではスマホ幅390px、フォーム送信、主要CTA、OGP、計測タグ、戻し方を確認する」「本番公開は人が承認する」「クライアント文言は勝手に書き換えない」。公式Best practicesでも、AGENTS.mdはrepo layout、build/test/lint、PR expectations、constraints、doneの定義を置く場所と説明されています。

3つのUse case

Use case 1: 差分レビューを公開承認と分ける

• 入力: PR URL、base branch、変更ファイル、ステージングURL、修正指示、クライアント承認メモ。
• 出力: コード差分の指摘、公開前確認の指摘、クライアント確認の指摘を分けた3列表。
• 人の確認: 料金、広告表現、公開日時、クライアントOK、本番反映を見る。

制作会社で最初に作るのは、Codexへの長い依頼文ではありません。差分レビューと公開承認を分ける表です。Codexには、/reviewで差分を読ませ、フォーム、CTA、画像、リンク、meta情報、戻し方の抜けを表にさせます。人は、公開してよいかを最後に見ます。

Use case 2: PRコメント対応を小さく切る

• 入力: PRコメント、該当ファイル、対象行、直したい範囲、触らないファイル、検証コマンド。
• 出力: 1コメントごとの修正案、変更ファイル、検証結果、残した判断メモ。
• 人の確認: クライアント要望とのズレ、見積外作業、デザイン変更、公開日への影響を見る。

PRコメントをまとめて「全部直して」と投げると、制作会社ではスコープが膨らみます。Codexには、コメントごとに小さい修正案を作らせ、差分をreview paneで見ます。採用LPなら文言、キャンペーンLPなら計測タグ、料金ページなら価格表現を人が止めます。

Use case 3: ステージングURL確認をスクショと表に残す

• 入力: ステージングURL、確認幅、フォーム入力例、主要CTA、計測タグ、戻し方、確認者。
• 出力: PC/スマホの確認表、フォーム送信結果、リンク一覧、スクショ、公開前ブロッカー。
• 人の確認: クライアント承認、SNSや広告開始時刻、問い合わせ先、公開可否を見る。

CodexやBrowserを使ってページを開き、スクショやフォーム確認をさせるのは有効です。ただし、Browserが接続され、ステージングサイトへのアクセスが許可され、フォーム送信前の承認が取れている場合に限ります。Browserを使えない場合は、人が確認して証跡を渡します。画面が表示されたことと、クライアントが承認したことは別なので、公開判断とクライアント連絡は人が見ます。

コピペで使えるプロンプト

あなたは制作会社のCodex Desktop導入前レビュー担当です。
ここでいうCodex Desktopは、ChatGPT desktop app上のCodex作業、review pane、/review、必要に応じたCLI/IDE extensionを含む作業画面のことです。

入力:
- PR URLまたは差分範囲
- base branch
- ステージングURL
- 変更ファイル一覧
- クライアント承認メモ
- 公開前チェックリスト
- 戻し方メモ

出力:
1. Codexに任せる作業: 差分要約、/review、抜け漏れ表、修正案、検証コマンド
2. 人が見る作業: 料金、広告表現、法務確認、クライアントOK、公開日時、本番承認
3. PRで直すもの、ステージングで見るもの、本番前に止めるものの3列表
4. AGENTS.mdに入れる短いルール案
5. 今日30分で直す1箇所

制約:
- Codexのレビュー結果を公開OKとして扱わない
- クライアント文言、料金、広告表現を勝手に変えない
- 同じLPを複数エージェントに同時編集させない
- 最後にステージングURL、差分、戻し方の3つがあるか確認する

動く確認コード

次のコードは、Codexにレビューを頼む前の入力が足りているかを見ます。実GitHubやOpenAI APIには接続しません。制作会社の公開前チェックでは、まずdiff scope、/review、staging URL、PR URL、client approval、rollback noteが揃っているかを見ます。

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

空のtableが出れば、最低限の入力は揃っています。stagingUrl、clientApprovalReference、rollbackPlan、releaseOwnerのいずれかを空にすると、欠けた項目を表示して終了コード1になります。これは公開承認ではなく、レビュー資料の入力検査です。

Pitfall: よくある落とし穴

原因: /reviewの結果を本番公開OKと読む。直し方: /reviewは差分レビュー、ステージング確認は表示とフォーム、本番公開は人の承認に分けます。レビュー結果には「公開可否」ではなく「修正が必要な差分」と書かせます。

原因: AGENTS.mdに抽象的な理想だけを書く。直し方: 制作会社の現場語で、スマホ幅、フォーム送信、CTA、OGP、計測タグ、戻し方、クライアント文言を短く書きます。長い理念より、毎回見る項目の方が効きます。

原因: 複数エージェントに同じページを同時編集させる。直し方: 探索、リンク確認、テストログ確認のような読取中心だけを分けます。書き込みはメインの1人に戻し、差分をreview paneで見ます。

原因: ステージングURLを見ずにPR差分だけで判断する。直し方: PR差分、ステージングURL、スクショ、フォーム送信、戻し方を1つの公開前表に残します。コードが正しくても、見た目と導線が壊れていれば公開事故です。

よくある質問

Q. Codex Desktopという名前は公式ですか？ A. 公式ページではChatGPT desktop app、Codex CLI、IDE extension、review paneなどの表現が中心です。この記事では、制作現場で使う俗称としてCodex Desktopと呼び、実体はその作業画面の組み合わせとして扱います。

Q. 制作会社はまずCLIとDesktopのどちらを使うべきですか？ A. ディレクターが差分やPRを見たいならChatGPT desktop appのreview paneが入り口になります。実装担当がローカルで検証したいならCLIやIDE extensionが向きます。

Q. /reviewだけで公開前チェックは足りますか？ A. 足りません。/reviewは差分や未コミット変更の確認に強いですが、クライアント承認、広告開始時刻、料金表現、公開可否は人が見ます。

Q. subagentは制作会社でも使うべきですか？ A. 読取中心の作業なら使えます。リンク確認、テストログ確認、差分要約は分けやすいです。同じLPを同時編集させる使い方は避けます。

研修・相談につなげるなら何を見るか

制作会社でCodex Desktopを入れる相談は、ツールの使い方だけでは終わりません。PR template、AGENTS.md、/reviewの使い方、ステージングURL確認、クライアント承認、公開前チェック、戻し方を1枚で見る必要があります。ここが整うと、AIで作業が速くなるだけでなく、差し戻しや公開事故が減ります。

この運用を自社案件に合わせたい場合は、Claude Code研修・相談で、実際のPR、ステージングURL、AGENTS.md、公開チェックリストを題材にできます。相談前に持ってくるものは、直近のPR、ステージングURL、公開事故または差し戻しメモ、現在のチェックリストだけで十分です。

実際に試した結果

この記事では、OpenAI公式のCodex manual、ChatGPT desktop app、Code review、AGENTS.md、Subagents、Agent approvals and security、記事内JavaScript確認コード、内部リンク、CTA、frontmatter、slugを確認しました。コードはdiff scope、公式CLI構文、staging URL、PR URL、顧客承認参照、rollback手順、release ownerを検査します。今日まずやる1手は、直近のPRを開き、差分レビュー、PR対応、公開確認を3列に分けることです。