Codexでブログ記事を更新する：原稿・確認・公開を一つの作業場所で管理する

ブログの更新をCodex中心で進めたい場合は、原稿を作る場所と、確認結果を残す場所を揃えることから始めます。下書きを別のAIへ何度も受け渡す運用を、必須の工程にする必要はありません。

ここで紹介するのは、記事ファイルを管理できるプロジェクトでの運用案です。公開サーバーへの接続や予約実行までが、会話を始めただけで自動設定されるわけではありません。

作業を任せる準備はWindowsでCodexを始める手順、依頼内容の書き方はCodexへの依頼文ガイドで扱っています。Claude Codeでの各工程も比較したい場合は、Claude Codeのブログ運営ガイドを参照してください。

記事ごとに持っておきたい情報

本文に加えて、次の情報を一緒に管理します。

本文をMarkdown、これらの情報を別の管理ファイルに置く形なら、どこを変更したか比較できます。WordPressを使い続ける場合でも、更新前の控えと記事IDの対応を持つという考え方は同じです。

最初は料金、インストール、対応環境など、変わると読者がつまずきやすい記事を優先します。検索データが取れる場合は、読まれている入口記事も合わせて確認します。データがない段階で「アクセスが伸びる記事」と断定せず、優先順位の理由を残します。

OpenAIの公式案内では、アプリから選択したフォルダのファイルを扱えます。公式クイックスタートを踏まえ、原稿と参照記録を同じプロジェクトに置くと、次のような依頼にまとめられます。

更新候補の中から、読者への影響が大きい記事を一つ選んでください。
公式資料で古い記述を確認し、本文と参照先を更新してください。
URL、公開日、既存アイキャッチは維持してください。
原稿保存後、リンクとビルドを確認し、公開済みかどうかも報告してください。

これは依頼の例です。実機で試していない手順は、その点が分かる記述にします。公式資料との照合と実際の動作確認を、同じ「確認済み」にまとめないことが大切です。

更新は「原稿ができた」「公開前の確認が済んだ」「本番へ反映した」「公開先でも確かめた」の4段階に分けると、いま何が残っているか分かります。次の図は、確認で問題がなかった場合の流れです。

公開前は、本文の根拠、リンク、画像、表示、公開対象を確かめます。公開後は、対象URLに更新内容が出ているかを確かめます。ビルドに成功しても、サーバーに古い記事が残っている可能性はあります。

ビルドとは、原稿から配信用のページを作る処理です。本文の変更と、配信用ページの作成と、公開先への送信を分けて考えると、止まっている場所を見つけやすくなります。

今回更新した記事について、次の状態を分けて報告してください。
1. 保存した原稿のファイル名
2. 公開前に確認した項目と、残っている問題
3. 本番へ反映したか。反映した場合は対象URL
4. 公開URLで実際に確認できた変更内容
確認していない項目は「未確認」と記載してください。

例えば見出しと図を追加したなら、公開URLでその見出しと図の両方が見えることを確認します。「処理が成功した」という報告だけでなく、読者が読む内容まで確かめるのが終了の目安です。

大きな移行では、元サイトのバックアップと戻す手順を用意します。内容の大量変更とURL変更を重ねると、問題の原因を追いにくくなるため、変更単位を小さく分けます。

「今後も更新して」と伝えるだけで継続運用を完了扱いにせず、いつ動くか、どの記事を扱うか、公開できる範囲、失敗時の報告先を決めます。まず一回の更新が完了する流れを作り、その後で定期実行を組み込みます。

記事数を増やす場合も、同じ質問に答える似た記事を量産するより、既存記事で答えられない読者の疑問を一つずつ埋めます。依頼の書き方はCodex向けの依頼文ガイドで具体例を確認できます。

公開前の差分確認ややり直しは、Codexの変更を確認して戻す方法に整理しています。

具体的な制作へ進む場合は、毎回の編集方針をAGENTS.mdへ保存し、一記事のリライトとシリーズのアイキャッチ制作を順に確認できます。一回の公開確認まで通ったら、定期点検の登録と初回確認へ進んでください。