a-blog cms ブログ or カテゴリー問題 2025
このエントリーは「a-blog cms Advent Calendar 2025」の 4日目の記事です。
CMSでサイトを作るということは、エントリーの種類を分類することから始まります。来年度から弊社に入社予定の新人エンジニアさんへの課題として、新規サイト制作のサイトツリーを作る、というのがありまして、私は来週月曜がその担当なので、エントリーの分類をどう考えるべきか、という記事を書いてみようと思いました。
a-blog cms を長く使ってらっしゃるユーザーさんには釈迦に説法なエントリーになってしまいそうです。すみません。
弊社では上図のようなサイトツリー図を、制作前に作ることが多いです。上図の場合は、ブログが緑、カテゴリーが黄色、エントリーが青、静的なページが白で示されています。エントリーの分類方法としてまず「ブログかカテゴリーか問題」を最初に考えます。
ブログで分けるべき場合とは
- その領域だけを扱うユーザーが必要
- デザインがめちゃめちゃ違う
- コンセプトがめちゃめちゃ違う
- エントリーがすごいたくさんあって、しかもどんどん増える
- 時系列でエントリーを並べたい
- その領域のエントリーにだけ持たせたいカスタムフィールドがたくさんある
- その領域だけを対象にした検索をやりたい
- カテゴリーだけで作るとカテゴリー階層が深くなりそう
こんな感じかなと思います。
まず1番。これは問答無用でブログ。カテゴリーではユーザーを分けることはできない（はず）。
この1番以外は、カテゴリーでやろうと思ったらなんとかなるかも、な感じだけど、ブログで作った方がずっといいだろう、という項目です。
2番の「デザインがめちゃめちゃ違う」場合はテーマも分けてテーマとブログを一対一対応にすると実装が楽。
3番の「コンセプトがめちゃめちゃ違う」場合には実装者も運用・更新者も、ざっくり大きな塊として捉えやすいブログが向いてる。
4番の「エントリーがすごいたくさんあって、しかもどんどん増える」だと、管理画面でもそのブログのエントリーがざっと見渡せるのが良いし、5番の「時系列でエントリーを並べたい」も同じ感じ。
6番の「その領域のエントリーにだけ持たせたいカスタムフィールドがたくさんある」場合、もちろんカテゴリーでもカスタムフィールドを別にすることはできるんだけど、ブログの方がちょっと楽だと思う。運用・更新者がパッとエントリーを作ったときに、ブログだったらカスタムフィールドはきっちり揃った状態だけど、カテゴリーを選ばないでエントリーを作成し始めちゃった場合には、カテゴリーのカスタムフィールドは編集画面に揃ってないことになる。そしてエントリーのカテゴリーを変更すると別のカスタムフィールドのセットが出てくることになる。
もちろんカテゴリーであっても管理メニューをカスタマイズしておくとか、そのカテゴリー専用のエントリー作成ボタンを用意しておくとか、いろいろやりようはあるんだけど、ブログで分けた方が良いかなーと私は思います。
7番の検索対象としてくくりたい場合というのは上図で言うとお知らせとかイベントとかですよね。お知らせとかイベントとかは、ほぼ例外なくブログで分けています。
8番に関しては、私は「カテゴリー階層はできればひとつ。多くてふたつ」ということをモットーにしています。カテゴリー階層が深いといろいろと実装が面倒になることがあります。
じゃあどんなときにカテゴリーで分けるの？
上記の条件にあんまり当てはまらないな〜という場合は、全部カテゴリーでいいです。カテゴリーにしておいた方が扱いやすい。
特に私は、表示順（ソート順）として「表示順（昇順）」「表示順（降順）」を選びたい領域にはカテゴリーを使うのが好きです。表示順を時系列ではなく管理画面から操作したい場合は、その領域に属するエントリーの数は限られているものだし、どっちにしろ管理メニューをカスタマイズしておいてあげた方が、運用・更新者に喜ばれるからです。こんな感じ。
実は a-blog cms では実装途中でブログをカテゴリーに変えたり、カテゴリーをブログに変えたりすることもそんな難しくないです。でもやっぱり、実装を始める段階で決めてしまっておいたほうが、いろいろとスムーズです。
今日はブログとカテゴリーの選び方について書きました。近いうちにサブカテゴリー、タグ、カスタムフィールドの考え方についても書きたいと思います！
a-blog cms、「もうぶっちゃけほぼカテゴリでよくない？？」と思っていたのでこのエントリーはとても参考になる！！
静的書き出しする時はブログ単位になるので、可能な限りブログの数は減らしておきたい派。
たしかに、ユーザーを分けたい場合以外は、カテゴリーでどうにでもなります。どうしてもブログの場合を除いてカテゴリーでやる、というのは一貫した方針ですし、管理画面の問題も工夫次第でどうにでもなりますよね。静的書き出しをやると決まっている場合など、ブログの数を減らすということもメリットかと思います！
弊社代表 山本一道@アップルップル さんからのコメント
2) デザインがめちゃめちゃ違う のところで_top.htmlとindex.htmlで分けて運用したい「ブログ」トップと検索結果が違う時にブログにするかなぁってところ。個人的に「親カテゴリー＞子カテゴリー」のような SELECT が好きじゃないので、極力「子カテゴリー」を作らないようにブログにする。
カテゴリー階層をあまり深くしたくない、というところに私も同意です！
弊社エンジニア うい。 さんからのコメント
個人的にはCMS = 管理画面付きDB だと思っているので、カスタムフィールドの設計が同じ場合はカテゴリーで異なる場合はブログだと思っています。
ブログはコンテンツタイプや投稿タイプ的使い方をしたい。
なるほど。これはスッキリした方針ですね！
あらためてまとめ
- ブログもカテゴリーも階層に制限はない
- カテゴリーの下にブログが作れないというのが唯一のルール
- ブログとカテゴリーが決まるとスムーズに実装に入れるのできちんと方針を立てたいところ
というわけで、実装前のサイト構成を考える上で、まずはブログか、カテゴリーかを考えて決めるとサイトの全体像が見えてきます。
