Codexローカル確認。スクリーンショットで失敗を減らす5手順
合同会社Leadfive 山下です。
Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。
さて、CodexにWebサイト更新を頼む時、文章だけで指示するとズレが残ります。とくにLP、問い合わせ導線、料金表、記事ページは、画面で見た時の余白、ボタン位置、スマホ幅の読みやすさで印象が変わります。ローカルプレビューとスクリーンショットを挟むと、AIの作業を店頭に出す前の試し開店として確認できます。
ローカルプレビューは、開店前の試し開店です
ローカルプレビューは、公開前のページを自分のPCだけで確認するための場所です。
店舗で考えると、看板やPOPを店頭に出す前に、バックヤードで並べて見る時間に近いです。文字は読めるか、価格の見え方は強すぎないか、導線は自然か。実際に置いてみないと分からない違和感があります。
CodexにWebサイト更新を頼む時も同じです。いきなり公開するのではなく、まずローカルでページを開きます。AIが直したファイルをブラウザで確認し、スクリーンショットを撮り、違和感を言葉ではなく画像で渡します。
OpenAIのCodexドキュメントでは、Codexをコードベースの作業に使う前提が整理されています。GitHub FlowやPull Requestの考え方と合わせると、作業、確認、公開を分ける運用にしやすくなります。
出典:
スクリーンショットは、新人スタッフへの現場写真です
スクリーンショットは、Codexに渡す現場写真です。
新人スタッフに口頭で、入口のPOPをもう少し見やすくしてと言っても、どのPOPか、どの距離から見た話かが伝わりません。写真に丸をつけて、ここが読みにくい、ここは残す、と渡す方が早いです。
Codexへの指示でも、スクリーンショットを使うと次の3点が伝わります。
- どの画面を見ているか
- 何がズレているか
- どこは変えないか
大事なのは、スクリーンショットを添えるだけで終わらせないことです。画像のどこを見るか、何を直すか、何を触らないかを短く書きます。AIは画像を読めますが、経営判断までは勝手に決めません。
PCとスマホ幅を、責任者確認の2画面にします
Webサイト更新では、PC幅とスマホ幅の両方を見るだけで事故が減ります。
中小企業のLPや記事は、作っている側がPCで確認しがちです。しかし読者の多くはスマホで見ます。PCでは整って見えても、スマホでは見出しが長すぎる、ボタンが押しにくい、画像の意味が小さくて伝わらない、ということがあります。
確認の順番は単純です。
- PC幅でページ全体を見る
- スマホ幅でファーストビューを見る
- CTAボタン、画像、見出し、内部リンクを見る
- 横スクロールや文字の重なりがないか見る
- 気になる箇所をスクリーンショットにする
この確認は、CodexでWebサイト更新を頼む手順 とセットにすると使いやすいです。Web更新の作業手順を決めたうえで、画面確認を別の工程として置きます。
Codexへの依頼は、画像と修正メモをセットにします
スクリーンショットを渡す時は、修正メモを短く添えます。
たとえば、ローカルプレビューでスマホ幅のCTAが詰まって見えた場合、次のように依頼します。
このローカルプレビューのスクリーンショットを見て、スマホ幅のCTAまわりだけを修正してください。
見てほしい箇所:
- 画面下部のCTAボタン
- ボタン上の説明文
- 画像と本文の余白
直したいこと:
- CTAボタンが窮屈に見えないようにする
- ボタン文言は変えない
- 画像、出典リンク、内部リンクは触らない
止めること:
- 公開、デプロイ、SNS投稿、広告、タグ変更は実行しない
- 依頼外のファイルを整形しない
- 修正後は、変更箇所と未確認項目を短く報告する
この書き方なら、Codexは新人スタッフとして作業できます。画面写真、直す場所、触らない場所、止める操作が揃っているからです。
PRと公開前レビューで、店頭に出す前に止めます
ローカル確認は、PRと公開前レビューの間に置くと機能します。
流れはこうです。Codexに作業を頼む。ブランチで変更を作る。PRで差分を見る。ローカルプレビューで画面を見る。スクリーンショットで追加修正を依頼する。最後に公開前レビューでリンク、画像、出典、CTAを確認する。
ブランチとPRの考え方は、CodexとGitHub PR。AI変更を本番前で止める5手順 で整理しています。外に出す直前の確認は、Codex公開前レビュー に分けておくと安全です。
ここで大事なのは、確認工程を増やすことではありません。公開事故が起きやすい場所だけを絞って、責任者確認を入れることです。価格、問い合わせ、申込、広告接続、顧客が見る画面は止める。社内メモや一時資料は軽くする。この線引きがあると、AI活用が重くなりません。
そのまま使えるローカル確認プロンプト
次のプロンプトは、Codexにローカル確認とスクリーンショット前提で作業を頼む時に使えます。
このページを公開前のローカル確認前提で修正してください。
目的:
公開前に、PC幅とスマホ幅で見た時の読みやすさ、CTA、画像、内部リンクのズレを減らすこと。
作業ルール:
- 作業はブランチ上で行う
- 公開、デプロイ、SNS投稿、広告、タグ変更は実行しない
- 依頼外の整形やリファクタリングはしない
- 修正後は、ローカルプレビューで見るべき箇所を3つ出す
確認してほしいこと:
1. PC幅で見出しとCTAが自然か
2. スマホ幅で文字や画像が重なっていないか
3. ボタン、内部リンク、出典リンクが壊れていないか
4. 未公開URLや仮リンクが本文に残っていないか
5. 公開前に人間が見るべき点が残っているか
出力:
変更内容、確認したこと、未確認のこと、次に撮るべきスクリーンショットを短く書いてください。
このプロンプトは、AGENTS.mdを会社の業務マニュアルとして作る方法 と相性が良いです。毎回の依頼文だけで止めるのではなく、会社ルール側にも公開前で止める条件を書いておくと、作業のたびに説明し直す量が減ります。
FAQ
ローカルプレビューは経営者本人が見るべきですか
問い合わせ導線、価格、申込、広告接続に関わるページは、責任者が一度見る方が安全です。社内メモや一時資料は、担当者確認でも足ります。
スクリーンショットだけでCodexに直してもらえますか
画像だけでは足りません。直したい箇所、残す箇所、触らない操作を短く添えると、修正範囲が安定します。
毎回PCとスマホの両方を見る必要がありますか
公開ページ、LP、記事、問い合わせ導線は両方見る価値があります。影響が小さい内部資料なら、リスクに応じて軽くできます。
今日の作業: 次に直す1ページを画面で確認します
まずは次に直したい1ページだけで十分です。ローカルプレビューを開き、PC幅とスマホ幅を見て、スクリーンショットを撮る。その上で、直す場所、残す場所、公開しない操作をCodexへ渡します。
AIにすべてを任せるのではなく、画面で見た違和感を材料にする。小さい会社がCodexを実務に入れる時は、この確認が一番現実的です。
出典
-
[Codex OpenAI Developers](https://developers.openai.com/codex/) - OpenAI Codex Changelog
- 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)
このシリーズの順番
PC幅とスマホ幅のスクリーンショットを使い、公開前のズレをCodexへ具体的に戻せる。次の作業は、次に直したい1ページをローカルで開き、スクリーンショットつきで修正依頼することです。