CodexでWebサイト更新を頼む手順。公開前で止める5ステップ
合同会社Leadfive 山下です。
さて、 Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。Webサイト更新でCodexを使う時に大事なのは、早く直すことより、公開前で止める流れを先に決めることです。
ホームページの文章、ブログの内部リンク、料金ページの補足、問い合わせ導線の文言。こうした更新は小さく見えても、公開後は売上や信頼に触れます。Codexには、営業中の店頭を勝手に変えさせるのではなく、裏方で棚替え案を作ってもらい、責任者が確認してから表に出す。この順番で頼みます。
Webサイト更新は、営業中の店頭を直接変えない作業です
CodexにWebサイト更新を頼む時は、本番公開と下書き作成を分けます。
店舗でたとえるなら、営業中の店頭で商品棚を動かすのではなく、裏で新しい陳列案を作り、責任者が見てから店頭に反映する流れです。Webサイトも同じです。AIが文章を直せることと、公開してよいことは別です。
最初に分ける作業は5つです。
- 直したいページを決める
- Codexに下書きと修正案を作らせる
- ローカルまたはプレビューで確認する
- 差分と公開前チェックを人が見る
- 承認後だけ本番へ反映する
Codexの始め方と最初に設定すべきポイントを済ませた後は、この5ステップを1ページ更新の型として使います。
最初は、直すページを1枚だけ渡します
最初の依頼では、サイト全体ではなく1ページだけを対象にします。
新人スタッフに初日から店全体の陳列変更を任せないのと同じです。まず1つの棚、1つの商品説明、1つのPOPだけを任せる。Codexも、対象ページを絞るほど、変更理由と確認方法が見えやすくなります。
頼み方はこうです。
目的:
指定ページの文言と内部リンクを、読者が次に取る行動が分かるように改善してください。
対象:
- 対象ページ: ここにファイル名またはURLを書く
- 関連して読んでよい記事: 公開済み記事だけを書く
進めてよいこと:
- 対象ページを読む
- 修正案を作る
- 内部リンク候補を出す
- ローカル確認またはプレビューで見るべき点を整理する
止めること:
- 本番公開、予約公開、SNS投稿はしない
- git push、deploy、DB、env、secret、広告タグは触らない
- 未公開ページへの本文リンクは入れない
完了条件:
変更案、理由、確認したこと、未確認のこと、人間が承認すれば次に進める操作を報告してください。
この依頼文は、AGENTS.mdはAIに渡す会社の業務マニュアルがあるほど短くできます。毎回の禁止事項を、会社の業務マニュアル側へ寄せられるからです。
内部リンクは、公開済みの棚札だけを使います
内部リンクは、公開済みページだけに張ります。
Webサイトの中でリンクは棚札のようなものです。まだ店頭に出ていない商品へ棚札を置くと、お客さんは行き止まりに当たります。ブログでも同じで、未公開記事や仮URLを本文に入れると、公開後にリンク切れや誤誘導が起きます。
Codexには、次のように頼みます。
内部リンクのルール:
- 本文リンクは公開済みURLだけにしてください
- planned、pending、下書きの記事は本文リンクに入れないでください
- 未公開記事へつなぎたい場合は、Internal Link Candidatesに分けてください
- リンク文言は、リンク先で何が分かるかを書いてください
LeadfiveのAIエージェント記事では、公開済みの基礎記事、Codex記事、AGENTS.md記事、承認ゲート記事だけを本文リンクに使います。AIエージェントのルール設計のように、任せる仕事と止める仕事の境界がある記事は、Web更新前の安全確認にもつながります。
ローカル確認は、店頭に出す前の試し置きです
公開前には、できる範囲でローカルまたはプレビュー確認を挟みます。
文章だけなら問題なさそうに見えても、スマホ幅では見出しが長すぎる、画像が横にはみ出す、リンクの位置が不自然、CTAが早すぎる、ということがあります。Codexには、修正だけでなく確認項目の一覧化まで頼みます。
確認するのは、最低限この7つです。
- タイトルと本文の約束が合っているか
- スマホ幅で読みにくい見出しがないか
- 画像パスとaltが入っているか
- 本文リンクが公開済みページだけか
- 出典リンクが公式情報になっているか
- 誇張表現や断定しすぎた表現がないか
- 公開、投稿、広告、タグ変更が止まっているか
差分レビューは、何を変えたかを見る責任者確認です
Codexの作業後は、完成文だけでなく差分を見ます。
新人スタッフがPOPを作り直した時、完成品だけを見ると、元の大事な文言が消えていても気づきにくい。Web更新も同じです。何を足したか、何を消したか、どのリンクを変えたかを確認します。
Codexには、報告を次の形にしてもらいます。
報告形式:
1. 変更した場所
2. 変更した理由
3. 変更しなかった場所
4. 公開前に人間が見る点
5. 公開時に実行してはいけない操作
ここで大事なのは、Codexに公開判断まで任せないことです。AIは見落としを減らす担当、人間は公開判断の責任者です。Codex RemoteでスマホからAI作業を承認する方法も、この責任者確認を外出先から行う考え方です。
承認ゲートは、公開ボタンを押す前の金庫の鍵です
Web更新の最後は、人間承認で止めます。
公開ボタン、SNS投稿、広告タグ、問い合わせ導線、料金ページ、契約に関わる文言は、金庫の鍵に近い場所です。Codexが下書きや確認をできても、鍵を渡すかどうかは別です。
Webサイト更新でAI単独にしない操作は、最初に書いておきます。
- 本番公開、予約公開、デプロイ
- X、Threads、Instagramなどの投稿
- Googleタグ、GTM、GA4、広告、リマーケティング設定
- DB、env、secret、Webhook、DNS、決済まわり
- 顧客へのメール、LINE、DM、フォーム送信
この境界があると、Codexに頼める仕事はむしろ増えます。下書き、確認、差分整理、内部リンク候補、画像alt、出典確認はAIに任せる。公開判断だけは人が持つ。小さな会社ほど、この分け方が現実的です。
今日の作業: 1ページだけCodexに更新案を頼みます
まずは、会社のWebサイトで直したい1ページを選びます。
おすすめは、トップページではなく、ブログ記事、サービス説明、FAQ、問い合わせ前の案内ページです。売上導線に関係するが、公開前で止めやすいページから始めます。
そのページに対して、次の4点をCodexに頼みます。
- 読者が迷う箇所を3つ挙げる
- 文言修正案を出す
- 公開済み記事への内部リンク候補を出す
- 公開前に人間が見るチェックリストを作る
これだけで、Codexはただの文章生成AIではなく、Web更新の下準備を進める新人スタッフになります。最初から本番公開まで任せる必要はありません。公開前で止める設計があるから、会社の実務に入れられます。
よくある質問
Codexにトップページ全体を任せてもいいですか
最初は避けます。まず1ページ、1セクション、1つの内部リンク改善から始める方が確認しやすいです。
Web更新なら公開まで任せた方が早くないですか
早く見えて、事故時の確認コストが増えます。下書き、プレビュー、差分レビュー、人間承認に分けます。
未公開記事へ先にリンクを入れてもいいですか
本文リンクには入れません。未公開記事はInternal Link Candidatesとして残し、公開後に差し込みます。
出典
-
[Codex OpenAI Developers](https://developers.openai.com/codex/) -
[Codex CLI OpenAI Developers](https://developers.openai.com/codex/cli) -
[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) -
[GitHub Pages GitHub Docs](https://docs.github.com/en/pages)
このシリーズの順番
CodexにWeb更新案を作らせ、公開前チェックで止められる。次の作業は、直したい1ページを選び、下書きと確認リストを依頼することです。