ブログを1つだけ運営しているうちは、Codexのプロジェクトに記事やKnowledgeをまとめて置いていても、あまり困りませんでした。
ところが、2サイト目のブログを作った頃から、少しずつ管理が難しくなりました。ファイルが増えたこともありますが、それ以上に「この情報はどのブログのものか」を毎回確認する必要が出てきたからです。
最初からマルチサイト構成を作るべきだった、という話ではありません。私の場合は、1サイト構成で運用してみた結果、ブログごとの情報が混ざりやすくなったため、現在の構成へ見直しました。
1サイトで運営している間は問題に気づきにくかった
最初はペットブログの記事、Knowledge、Weekly、記事管理、はてなブログのCSS、分析データなどを、1つの管理領域で扱っていました。
1サイトだけを見ている間は、ファイルを探す範囲が決まっているため、多少フォルダが増えても名前や記憶でたどれました。
その後、同じCodexプロジェクトにCodexブログの管理を追加すると、記事、内部リンク、CSS、分析レポートなど、同じ役割のファイルがブログごとに必要になりました。その結果、「似た名前のファイルをどちらのブログで使うのか」を確認する場面が増えました。
以前は複数の管理対象を同じプロジェクトに置いていた
以前のイメージは、次のような1サイト前提の構成です。
blog-operations/
├─ AGENTS.md
├─ workflows/
├─ articles/
├─ settings/
├─ exports/
├─ reports/
└─ knowledge/この中に、次のような情報が入っていました。
- ペットブログの記事と記事管理
- Codexブログの記事と記事管理
- ブログ運営のKnowledge
- Weeklyの記録
- はてなブログの設定やCSS
- Search ConsoleやGA4のデータ
- 分析レポートや改善メモ
記事本文だけでなく、記事作成前のメモ、公開後の台帳、分析の元データまで扱うようになると、1サイト用の置き場所をそのまま広げるだけでは整理しにくくなりました。
2サイト目を追加して、情報の境界が必要になった
困ったのは、単にファイル数が増えたことだけではありません。ブログごとに内容が違う情報と、共通して使える情報が同じ階層に並んでいたことです。
たとえば、次のような混在が起きやすくなりました。
| 混ざりやすかった情報 | 困ったこと |
|---|---|
| Knowledge | どのブログの方針・読者情報か確認が必要になる |
| CSS・はてなブログ設定 | 一方のブログの見た目を別ブログと取り違えやすい |
| 内部リンク台帳 | 記事URLや関連記事の範囲を分けて確認しにくい |
| 記事台帳 | 公開状態や次の対応が見づらくなる |
| 分析データ・レポート | サイトや期間を取り違えない確認が必要になる |
| Codexへの指示 | 対象サイトと参照ファイルを毎回詳しく指定する必要がある |
特に、Codexへ修正を依頼するときに、対象ブログを明示しない場合、別ブログのファイルも参照候補になり得る構成だったため、対象範囲を詳しく指定する必要がありました。
また、修正対象が曖昧なままだと、本文の修正だけを頼んだつもりでも、関連する管理ファイルや設定まで確認範囲が広がります。大きな事故が起きたという意味ではありませんが、毎回の確認コストが増えていました。
1サイト用の構成をそのまま増やす案も考えた
最初は、既存ブログをルート直下に残し、新しいブログだけを別フォルダへ入れる案も考えました。
blog-operations/
├─ articles/
├─ settings/
├─ reports/
└─ second-blog/
├─ articles/
├─ settings/
└─ reports/この形でもファイルは保存できます。ただ、同じ役割のブログが異なる階層に置かれます。既存ブログだけが特別扱いに見え、今後ブログを追加するときの基準も分かりにくくなります。
そこで、既存ブログを含めて、ブログごとの領域を同じ階層にそろえることにしました。
現在はcommonとsitesに分けている
現在は、プロジェクト全体をおおむね次の考え方で分けています。
project-root/
├─ common/
│ ├─ workflows/
│ ├─ templates/
│ └─ scripts/
└─ sites/
├─ pet_game_blog/
│ ├─ articles/
│ ├─ knowledge/
│ ├─ reports/
│ └─ hatena_settings/
└─ codex_blog/
├─ articles/
├─ knowledge/
├─ reports/
└─ hatena_settings/common/には、複数サイトで共有するルール、テンプレート、ワークフロー、スクリプトなどを置きます。一方、sites/の下にはブログごとの記事、Knowledge、分析データ、記事台帳、内部リンク、設定を置きます。
この分け方で重視したのは、フォルダの見た目よりも、情報の境界です。共通化できるものは共通領域へ、ブログの判断や記事に関係するものはサイト固有領域へ置く、という基準を持てるようにしました。
再編して良かったこと
再編後に感じている良さは、アクセス数や収益のような成果ではなく、日々の確認と指示がしやすくなったことです。
ブログごとに情報を整理できる
記事、Knowledge、内部リンク、CSS、分析レポートがブログごとの領域にまとまります。どこを見ればよいかが決まるため、ファイル名だけで判断する場面が減りました。
Codexへの指示範囲を明確にしやすい
「Codexブログの記事を修正する」「sites/codex_blog/だけを対象にする」のように、対象サイト、参照範囲、変更範囲を先に示しやすくなりました。プロンプトが必ず短くなるというより、どこを見て、どこを変更する作業なのかを明確にしやすくなったことが重要でした。
新しいブログを追加する基準ができた
新しいサイトを追加するときは、sites/の下に同じ役割の管理領域を作る、という基準を使えます。既存ブログだけがルート直下に残る状態を避けられます。
別ブログを編集するリスクを下げやすい
完全に間違いを防げるわけではありませんが、対象サイトのフォルダを明示できると、確認範囲を狭くできます。記事本文を直すときに、別ブログのKnowledgeやCSSまで一緒に確認する必要が減りました。
ただし、マルチサイト構成にしただけで作業時間が必ず短くなった、アクセスが増えた、収益が伸びた、とは考えていません。構成は管理を支える土台であり、記事の内容や分析結果まで自動で改善するものではないからです。
マルチサイト構成が向いている人
次のような状況なら、マルチサイト構成を検討しやすいと思います。
- 複数のブログを同じCodexプロジェクトで管理している
- これからブログを増やす予定がある
- Knowledgeや記事台帳が増えて、保存先に迷うことがある
- サイトごとにCSS、内部リンク、分析データが異なる
- Codexへ依頼するたびに、対象サイトや変更範囲を細かく指定している
反対に、ブログが1つだけで記事数も少ないなら、無理にマルチサイト構成へ再編しなくてもよいと思います。最初から大きな構成を作ると、フォルダを維持する作業そのものが増える可能性があります。
まずは1サイト用の小さな構成で始め、次のようなサインが出たときに見直す方が現実的です。
- 同じ種類のファイルがサイトごとに必要になった
- どのブログの情報か確認する時間が増えた
- 指示のたびに対象範囲を細かく説明している
- 記事台帳や内部リンク台帳が見づらくなった
まとめ
個人ブログをCodexで管理する方法として、マルチサイト構成が常に必要なわけではありません。私の場合は、1つのブログを管理している間は問題が表面化せず、2サイト目を追加したことで、Knowledge、CSS、内部リンク、記事台帳などの境界が必要になりました。
現在は、複数サイトで共有するものをcommon/に、ブログ固有の情報をsites/の下に分けています。これにより、ブログごとの情報を整理しやすくなり、Codexへの指示や管理ファイルの確認もしやすくなりました。
最初から完璧な構成を作るより、運営しながら必要になったタイミングで見直す方が、私の運用には合っていました。ブログが1つだけなら小さく始め、管理対象やサイトが増えて混乱し始めたら、マルチサイト構成を選択肢に入れるのがよいと思います。