Codexでブログを管理していると、記事本文以外の情報も少しずつ増えていきます。
記事の公開状態、サイトの方針、内部リンク、作業履歴、次にやること。最初は同じファイルへまとめても大きな問題はありませんでしたが、運用を続けると「これは現在の情報なのか」「過去の記録なのか」「これからやることなのか」が分かりにくくなりました。
そこで現在は、管理情報をKnowledge・Weekly・Next Actionsに分けています。この記事では、なぜ分けているのか、記事を公開した後に何を更新するのかを、個人ブログ運営での使い方としてまとめます。
なぜ管理情報を3つに分けているのか
管理情報を1つのファイルへ追記し続けると、情報は保存できます。ただし、時間が経つほど、最新の状態と過去の記録が同じ場所に並びます。
たとえば、公開済み記事の正式URL、以前の作業メモ、まだ着手していない改善案を同じ一覧で管理すると、次のような確認が必要になります。
- 今も有効な情報はどれか
- すでに終わった作業はどれか
- 次回に残っている作業はどれか
この状態では、Codexへ前提を渡すときにも、現在の状態と履歴を読み分ける必要があります。実際の運用で記事公開後の更新が増えたことで、役割ごとに分けた方が確認しやすいと判断しました。
Knowledgeには「現在の状態」を残す
Knowledgeは、現在有効な情報を確認するための場所です。記事の公開状態、サイトの運用方針、内部リンクの状況、確認済みの事実など、今の作業で前提にしたい情報を置いています。
このプロジェクトでは、たとえば次のようなファイルを使っています。
| ファイル | 確認する内容 |
|---|---|
article_registry.md |
記事の状態、記事フォルダ、公開済み記事の正式URL |
internal_links.md |
公開済み記事のURLと、内部リンクの設置状況 |
evidence_log.md |
確認済みの事実と、まだ確認していない項目 |
site_concept.mdなど |
サイトの方針や読者へ提供する内容 |
たとえば、現在の記事台帳では、公開済み記事と作成中の記事を区別して管理しています。公開済み記事の正式URLは、記事台帳と内部リンク台帳から確認できます。
Knowledgeは「今どうなっているか」を見る場所なので、古い状態を時系列で残し続ける場所にはしていません。状態が変わったら、現在の情報を更新し、変更の経緯が必要な場合はWeeklyへ残します。
Weeklyには「変更の履歴」を残す
Weeklyは、その日に何を変更したかを後から追えるようにする履歴です。Knowledgeが現在の状態を示すのに対して、Weeklyは「なぜ今の状態になったのか」を確認する手がかりになります。
実際の運用では、2026年7月30日のWeeklyに、記事を公開したこと、正式URLや公開日、記事台帳・内部リンク台帳・公開メモ・Next Actionsなどを同期したことを記録しています。同じ記録の中に、PC・スマートフォン表示やリンク遷移、アクセスなどは未確認として残しています。
このように、Weeklyには完了した変更だけでなく、その時点で確認できていない項目も書きます。後から見返したときに、「公開した」ことと「表示や効果まで確認した」ことを混同しないためです。
Next Actionsには「次にすること」を残す
Next Actionsは、次回Codexを開いたときに、何から始めるかを判断しやすくするための情報です。現在の状態や過去の履歴を置く場所ではなく、次に進める作業を整理します。
現在のnext_actions.mdでは、今週行う作業や次の優先作業、保留中の作業などを分けて記録しています。たとえば、記事の本文レビュー、アイキャッチ要否、公開前確認など、次に判断が必要な作業を置いています。
記事の作成や公開後同期が終わったら、Next Actionsも次の作業に書き換えます。過去の作業を蓄積し続けるTODO一覧ではなく、次回の入口として使うことを重視しています。
ただし、Next Actionsに書かれているからといって、作業が自動的に実行されるわけではありません。優先順位や確認が必要な作業を見つけやすくするためのメモであり、完了判断は人間が行います。
記事公開後は3つをどう更新するか
記事公開後の情報同期を例にすると、3つの役割の違いが分かりやすくなります。現在の運用では、はてなブログでの公開操作と、Codex側の管理情報の更新を別の作業として扱っています。
- 人間がはてなブログで記事を公開する
- 公開状態、公開日、正式URLを人間が確認する
- 記事台帳や内部リンク台帳など、Knowledge側の現在状態を更新する
- Weeklyへ、その日に公開後同期で何を変更したかを残す
- Next Actionsを、次の記事や表示確認など次の優先作業へ変更する
この分け方なら、現在の公開状態・公開に至った経緯・次の作業を切り分けて確認できます。現在の公開状態を知りたいときは記事台帳、公開に至った経緯を見たいときはWeekly、次の作業を始めたいときはNext Actionsを見ればよくなります。
3つに分けても人間の確認は必要
Knowledge、Weekly、Next Actionsを分けても、Codexが必ず正しい状態を判断できるわけではありません。ファイルが更新されていても、元になった情報が未確認なら、記録だけが先に進む可能性があります。
公開状態や正式URL、実際に表示が崩れていないか、次に進めてよい作業かどうかは、人間の確認が必要です。特に、公開後のアクセス、検索順位、回遊、収益への効果は、公開しただけでは判断できません。
そのため、確認できていない項目を完了扱いにしないことを重視しています。ファイルを分ける目的は完全自動化ではなく、確認すべき情報の種類と場所を整理することです。
まとめ
私のブログ運営では、Knowledge・Weekly・Next Actionsを次のように使い分けています。
| 管理場所 | 役割 |
|---|---|
| Knowledge | 現在どうなっているかを確認する |
| Weekly | いつ何を変更したかを振り返る |
| Next Actions | 次に何をするかを決める |
ファイル数を増やすこと自体が目的ではありません。現在の状態、そこに至るまでの経緯、これからすることの役割を分けることで、次回の作業時に前提を整理しやすくするための方法です。
ブログの規模や運用方法によっては、最初から3つに分ける必要はないと思います。情報が増えて、現在・履歴・次の作業が混ざり始めたときに、役割を分ける方法を検討すると取り入れやすいはずです。