Codexでブログ記事を作り始めたころは、記事ファイルを置く場所が決まっているだけでも十分でした。
しかし、記事が増え、はてなブログの設定、Search ConsoleやGA4のデータ、分析レポート、Knowledgeまで扱うようになると、「これはどこに保存するものか」が少しずつ曖昧になりました。
さらに2つ目のブログを同じプロジェクトで管理することになり、1サイト目だけがルート直下に残る構成へ違和感を持つようになりました。そこで、実際のブログ運営ファイルを移動し、共通ルールとサイト固有情報を分ける構成へ変更しました。
そもそも何を管理するための構成か
ここでいう「ブログをCodexで管理する」とは、記事本文だけでなく、ブログ運営に関係するファイルを目的ごとに分けて保管することです。Codexを記事作成・管理・分析・改善へどう使っているかは、前回の記事で全体像を整理しています。
たとえば、次のような情報を同じプロジェクトで扱います。
- 記事の下書き、公開用HTML、記事台帳
- はてなブログの設定やCSS
- Search ConsoleやGA4から取得したデータ
- 分析レポートと、そこから決めた改善作業
- Codexが守るルール、Knowledge、ワークフロー
記事だけなら articles/ だけでも始められます。今回は、記事・設定・分析データ・レポート・Knowledgeなどが増えたため、それらの置き場所を見直しました。
最初は1ブログ前提で管理していた
最初の構成では、1つのブログを運営するためのフォルダをプロジェクト直下に置いていました。記事、はてなブログの設定、外部サービスから取得したデータ、レポート、SNSのメモ、Knowledge、ワークフローなどです。
blog-operations/
├─ AGENTS.md
├─ workflows/
├─ articles/
├─ settings/
├─ exports/
├─ reports/
└─ knowledge/1サイトだけで、ファイル数も少なければ、この形が必ず悪いわけではありません。問題は、同じプロジェクトで別のブログを追加しようとしたときでした。
2つ目のブログを追加すると構成が不自然になった
一度は、既存ブログをルート直下に残し、新しいブログだけを別フォルダへ追加する案を考えました。
blog-operations/
├─ articles/
├─ settings/
├─ reports/
└─ second_blog/
├─ articles/
├─ settings/
└─ reports/動作上は問題がなくても、同じ役割のブログが異なる階層に置かれる状態です。実際に並べてみると、この構造へ違和感がありました。
どのルールが共通で、どのKnowledgeがサイト固有なのかも分かりにくくなります。そこで、ブログを追加する前に、サイトを並列に置ける構成へ変えることにしました。
最終的にcommonとsitesへ分けた
blog-operations/
├─ AGENTS.md
├─ common/
│ ├─ knowledge/
│ ├─ workflows/
│ ├─ templates/
│ └─ scripts/
├─ sites/
│ ├─ main_blog/
│ │ ├─ AGENTS.md
│ │ ├─ knowledge/
│ │ ├─ articles/
│ │ ├─ settings/
│ │ ├─ exports/
│ │ └─ reports/
│ └─ second_blog/
│ ├─ AGENTS.md
│ ├─ knowledge/
│ ├─ articles/
│ ├─ settings/
│ ├─ exports/
│ └─ reports/
└─ archive/common/ は複数サイトで共有するルールやテンプレートの置き場です。sites/ はサイトごとの領域で、記事や分析データを混ぜないための境界になります。
commonに置くもの
common/ に置くのは、サイト名や記事固有の情報を含まないものです。
- 複数サイトで使うワークフロー
- 記事管理やレポートのテンプレート
- 分析の共通手順
- Codex利用ルール
- Weeklyの共通ルール
- 複数サイトで使うスクリプト
同じルールを各サイトへコピーすると、修正箇所が増えます。片方だけ古い状態になることもあるため、共通部分を1か所に置いています。
各サイトに置くもの
サイト固有領域には、そのブログだけに関係する情報を置きます。
- 記事本文と記事フォルダ
- 公開URLと記事台帳
- サイト固有のKnowledge
- Search Console・GA4の入力データ
- 内部リンク、Next Actions、Weekly
- はてなブログの設定内容やCSS、サイト別レポート
目的は、記事IDやURL、分析期間、別サイトの改善課題を混同しないことです。Codexへ対象サイトを明示するときも、参照範囲を分けやすくなります。
AGENTS・Knowledge・Weeklyの役割
| 置き場 | 役割 |
|---|---|
AGENTS.md |
Codexがその場所で守る参照範囲や変更ルール |
knowledge/ |
サイト設定、運営方針、記事状態など、現在参照する情報 |
weekly/ |
いつ何を変更したかを残す日付ごとの履歴 |
next_actions.md |
次回以降に行う作業や保留事項 |
article_registry.md |
記事ID、状態、公開URL、保存先 |
exports/ |
Search ConsoleやGA4などから取得した元データ |
reports/ |
元データを分析して整理した結果や改善方針 |
現在の状態、過去の変更、次に行う作業を別々に管理することで、Codexが情報の役割を区別しやすくなります。exports/ は取得した元データ、reports/ はそこから作成した分析結果として分けておくと、元データと判断内容を後から確認しやすくなります。
Knowledge・Weekly・Next Actionsをそれぞれ何のために使っているかは、管理情報の役割と使い分けで詳しく整理しています。フォルダ全体の構成と、個々の管理情報の役割を分けて確認したい場合に参考になります。
実際の移行で行ったこと
- 現在のファイルを一覧化
- 旧パスと移動先のマップを作成
- 新しいディレクトリを作成
- 既存ブログをサイト固有領域へ移動
- 共通ルールを
common/へ分離 - 新ブログの管理領域を作成
- Markdownやスクリプトの旧パスを更新
- ファイル数と主要ファイルを確認
- 旧パス参照を検索
- はてなブログ側や公開記事を変更していないことを確認
移行前の確認では、記事関連フォルダ内にMarkdown、HTML、メモ、管理ファイルなどを含む319ファイルがありました。これは公開記事数ではなく、記事に関係するファイルの合計です。
ほかにも、はてなブログ設定50ファイル、エクスポート12ファイル、レポート9ファイル、KnowledgeやSNS関連のファイルが移行対象でした。これらは移行作業の規模を確認するための数値であり、アクセス増加や収益、作業時間短縮の実績を示すものではありません。
この構成にして良かったこと
- 対象サイトをパスで明示しやすくなった
- 共通ルールを1か所で管理できる
- サイトごとのNext Actionsを分けられる
- 記事、分析、公開後の記録の保存先が決まった
- 公開用情報と非公開情報を分けて管理する意識を持ちやすくなった
ただし、この構成にしただけでアクセスが増えた、収益が伸びた、必ず効率化できた、とは判断していません。構成は運営を支える土台であり、記事内容や分析、公開後の改善まで自動で解決するものではないからです。
まだ改善したい点
- Codexで使うスキルと対象サイトの対応整理
- サイト横断で使える分析スクリプトの共通化
- 画像や匿名化したスクリーンショットの管理
- 過去の作業指示やプロジェクト外のメモに残った旧パスの整理
- 共通化の範囲と、サイト固有情報の境界
共通化しすぎるとサイトごとの違いが見えにくくなり、分けすぎると同じ修正を繰り返すことになります。今後も実際に使いながら、必要な部分だけ調整する予定です。
最初からここまで作る必要はない
1ブログで数記事を管理する段階なら、最初からマルチサイト構成にする必要はありません。
blog/
├─ AGENTS.md
├─ knowledge/
├─ articles/
└─ reports/記事、分析データ、サイトが増えて保存先に迷い始めたときに、common/ と sites/ へ分ければよいと思います。フォルダ構成を作ること自体が目的にならないよう、困っている部分から導入するのが現実的です。
Codexへ依頼するときの簡易プロンプト
ここまで紹介した構成を、Codexに作成してもらうときの簡易プロンプトです。既存ファイルがある環境では、いきなり作成を依頼せず、最初に現在のファイルとディレクトリを確認させます。
ブログ数や運用方法によって必要なフォルダは異なります。掲載例を唯一の正解と考えず、最初は必要な最小構成から始め、既存環境で実行する場合はバックアップや差分確認を行ってください。
【タスク名】ブログ運営用ディレクトリの初期構成を作る
現在のプロジェクト内に、個人ブログ運営用のディレクトリ構成を作成してください。
最初に既存のファイルとディレクトリを確認し、すでにある構成を削除・上書きしないでください。
基本構成は次の考え方にします。
- common/：複数サイトで共通して使うルール、テンプレート、スクリプト
- sites/：ブログごとの記事、設定、分析、管理情報
- 各ブログはsites/配下で同じ階層にする
- サイト固有の情報を別サイトへ混在させない
例：
project-root/
├─ common/
│ ├─ knowledge/
│ ├─ templates/
│ └─ scripts/
└─ sites/
└─ example_blog/
├─ articles/
├─ knowledge/
├─ reports/
└─ hatena_settings/
実行時は以下を守ってください。
- 必要な最小構成だけを作る
- 既存ファイルを削除・移動・上書きしない
- 不明な用途のファイルは推測で変更しない
- ローカル絶対パスや個人情報を公開用ファイルへ書かない
- Git操作を行わない
- ブログへの投稿・公開操作を行わない
- 作成前に、追加・変更する予定の項目を確認する
- 作成後に、追加したディレクトリと未確認事項を報告する
既存構成と競合する場合は作業を止め、変更案だけを提示してください。まとめ
個人ブログをCodexで管理するためのフォルダ構成は、見栄えよりも「Codexが参照する情報を迷わせないこと」を優先しました。
- 共通ルールは
common/に置く - 記事や分析データは
sites/配下で分ける - 複数サイトは同じ階層に置く
- AGENTS、Knowledge、Weekly、台帳、レポートの役割を分ける
- 移行時はインベントリ、移行マップ、旧パス検索で確認する
- 1ブログ・数記事なら小さな構成から始める
この構成も、まだ改善途中です。運用しながら、共通化する部分とサイトごとに分ける部分を調整していきます。