Codexで記事を書き、内容を確認して、はてなブログで公開する。ここまで進むと、ひとまず作業が終わったように感じます。
ただ、次の記事を作るときに「前の記事は公開済みだったか」「正式URLはどれか」「次に何をする予定だったか」を毎回説明し直していると、少しずつ管理に手間がかかります。
私が個人ブログの運営で取り入れているのは、記事を公開した後に、Codexプロジェクト側の管理情報を更新する作業です。この記事では、公開操作そのものではなく、公開後に実際のブログの状態を管理情報へ反映する流れを紹介します。
記事を公開しただけでは、管理情報は更新されない
Codexで作成した原稿や公開用HTMLは、ローカルのプロジェクト内に残っています。一方、はてなブログで貼り付け、表示を確認し、公開した結果は、管理ファイルへ自動的に書き戻されるわけではありません。
たとえば、原稿を作った時点では、カスタムURLが最終決定していなかったり、アイキャッチや本文画像の使用状況が変わったりすることがあります。公開後に初めて確定する情報には、次のようなものがあります。
- 公開状態
- 公開日
- 正式URL
- 実際に使用したアイキャッチや本文画像
- 公開時に確認した表示や、残った課題
そのため、記事原稿を作成した時点の情報と、実際に公開されたブログの状態は分けて扱う必要があります。チャット上で公開済みと共有しただけでは、Codexプロジェクト内の記事台帳や公開メモまで自動的に更新されるわけではありません。
公開後にCodexへ同期している情報
公開後の同期では、すべてのファイルを細かく更新することを目的にしていません。役割の違う情報を、それぞれの管理場所へ反映することを重視しています。
| 管理情報 | 主な役割 |
|---|---|
| 記事台帳 | 記事の公開状態、公開日、正式URLを確認する |
| 公開メモ | 公開時のタイトル、カスタムURL、画像、公開後に確認する項目を残す |
| 内部リンク台帳 | 公開済み記事の正式URLと、関連記事として使える文脈を管理する |
| Next Actions | 表示確認、リンク確認、分析など、次に行う作業を引き継ぐ |
| Weekly | その日に公開後同期で何を変更したかを履歴として残す |
| Evidence Log | 公開や確認について、事実と未確認事項を分けて記録する |
たとえば、記事台帳は「公開済みかどうか」を探す場所です。公開メモは、その記事の公開時に何を確認したかを振り返る場所です。Next Actionsは次の作業を決める場所で、Weeklyは変更履歴です。同じ情報をすべてのファイルへ繰り返し書くのではなく、役割に合わせて必要な範囲を更新します。Knowledge・Weekly・Next Actionsをなぜ分け、どう使い分けるかは、管理情報の役割と使い分けで詳しく整理しています。
公開操作と同期作業を分けている理由
はてなブログへの貼り付け、表示確認、公開するかどうかの判断は、人間が行っています。公開前には、管理ファイルだけでは分からないことがあるからです。
- 貼り付けたHTMLが意図した表示になっているか
- PCとスマートフォンで表やコードが読めるか
- アイキャッチや本文画像が正しく表示されているか
- タイトル、カテゴリ、公開範囲に問題がないか
これらを確認する前に、公開後同期まで同じタスクへ詰め込むと、公開前に確定していない情報を先に管理することになります。そこで、記事作成・レビュー・公開・公開後同期を別の作業として扱っています。
この分け方は、作業を複雑にするためではありません。公開が完了したという事実と、Codex側の管理情報を更新したという作業を分けることで、どこまで終わったのかを確認しやすくするためです。
実際の公開後同期の流れ
現在の運用は、次のような順番です。
- Codexで記事原稿と公開用HTMLを作成する
- 人間が本文、タイトル、リンク、画像、公開前の注意点をレビューする
- はてなブログへHTMLを貼り付ける
- PCとスマートフォンで表示を確認する
- 人間が公開する
- 公開日、正式URL、使用画像などの確定情報を確認する
- 確認した情報をCodexへ伝える
- 記事台帳、内部リンク台帳、記事別の公開メモ、Next Actions、Weeklyを更新する
- 次の記事作成や、公開済み記事への内部リンク作業へ進む
実際の記事公開後にも、公開済みへの状態変更や正式URLの登録を別途行っています。アクセスや検索順位などは公開直後に判断せず、後日の分析対象として分けています。
同期しておくと、次の作業が始めやすい
公開後同期を始めて、最も助かっているのは、次回の依頼で前提を説明し直す量を減らせることです。
公開済み記事と正式URLを探しやすい
記事台帳と内部リンク台帳に正式URLを残しておくと、次の記事から関連記事を追加するときに、公開済みかどうかを確認しやすくなります。URLを記憶だけで管理する必要も減ります。
次に行う作業を引き継ぎやすい
公開した時点で作業が完全に終わるとは限りません。表示確認やリンク遷移の確認が残っている場合は、Next Actionsに残します。次回の作業で「何をする予定だったか」を思い出すための手がかりになります。
ChatGPTで決めた方針と、Codex側の記録を近づけられる
相談の場で決めたタイトルや構成と、実際に公開した記事の状態が離れていくと、後から見返したときに分かりにくくなります。公開後に確定情報を記録することで、相談時の方針と現在の管理情報を近づけられます。
複数ブログの情報を区別しやすい
対象サイトの記事台帳へ公開情報を反映しておくと、次の記事作成や内部リンク追加のときに、別サイトのURLを参照する間違いを減らしやすくなります。
公開後同期で残っている課題
便利になった一方で、手作業が残っている部分もあります。
- ChatGPTで相談した内容と、Codexプロジェクト内の管理情報が自動的に同期されるわけではない
- 公開完了後に、人間が正式URLや公開日を伝える必要がある
- 更新対象の管理ファイルが増えると、同期漏れの確認が必要になる
- ファイル構成を変えた場合は、運用ルールも見直す必要がある
そのため、管理ファイルを増やせばよいとは考えていません。記事台帳だけで足りる段階もありますし、内部リンクや公開後の確認項目が増えたときに、公開メモやWeeklyを使うこともあります。運用の規模に対して記録が重くなりすぎないよう、今後も調整していく予定です。
まとめ
Codexで記事を作成しても、はてなブログで公開した結果がCodex側へ自動的に反映されるわけではありません。公開日、正式URL、使用画像など、公開後に確定する情報があります。
私の運用では、人間が公開と表示確認を行った後、正式URLなどをCodexへ伝え、記事台帳、内部リンク台帳、公開メモ、Next Actions、Weeklyを役割に応じて更新しています。
この方法は、管理ミスを完全になくす仕組みでも、公開作業まで自動化する方法でもありません。それでも、公開済み記事を探しやすくし、次の作業を引き継ぎやすくするという点では、個人ブログの運営に取り入れやすい方法だと感じています。