CMSのテンプレート一覧と命名規則｜大規模サイトを支える設計の基盤

設計の最初に作るのは「テンプレート一覧」

CMS設計を進めるとき、最初に何から手をつけるかは設計者によって違いがあります。私の場合は、サイト全体のテンプレート一覧を作るところから始めます。

テンプレート一覧というのは、そのサイトに存在するページの種類を一覧化した表のことです。1つのテンプレートが1つのページの種類に対応します。たとえば「ホーム」「サービス詳細」「導入事例詳細」「お知らせ詳細」「会社概要」が、それぞれ別のテンプレートになります。

テンプレート一覧があると、次のような場面で役に立ちます。

• 設計レビュー時に「ページの種類は網羅できているか」「重複はないか」を確認できる
• 実装担当者が、何を作ればよいかを一目で把握できる
• 運用開始後に新しいページ種類を追加するとき、既存テンプレートとの整合性を判断できる
• サイトリニューアル時の引き継ぎ資料として、そのまま使える

逆に、テンプレート一覧を作らないまま設計が進むと、ページの種類があとから増えていったり、似たようなページが別々のテンプレートとして実装されていたりと、サイト全体の見通しが悪くなります。

テンプレート一覧に含める項目

テンプレート一覧に含めると役立つ項目は、次のようなものです。

• 識別コード：システム上の識別子。英大文字のスネークケース（例：HOME、NEWS_DETAIL）
• 表示名：人間が見て識別する名前。日本語ベース（例：HM01 ホーム、NW02 お知らせ詳細）
• URL（パス）：このテンプレートで生成されるページのURL
• パンくず：そのページがサイト構造のどこに位置するか
• 実装ファイル名：テンプレートを実装するファイル（JSP、PHP、HTMLなど）
• 備考：フォーム無しなどの特記事項

実装ファイル名は技術寄りの情報なので、設計フェーズの一覧では省略する場合もあります。逆に、運用ドキュメントとして使うなら実装ファイル名はあったほうが、運用者から不具合報告が来たときに該当ファイルをすぐ特定できます。

サンプルとして、BtoBサービスサイトのテンプレート一覧の一部を示します。

このような一覧があると、サイト全体の構造が一目で把握できます。

識別コードと表示名を分ける

テンプレートの名前は、システム上の識別子と、人間が見る表示名の2系統に分けて持たせると運用が楽になります。

識別コードは、システムで参照するための名前です。実装ファイル名やデータベースのキー、ログ出力などで使います。英大文字のスネークケース（HOME、SERVICE_DETAIL、NEWS_DETAIL）にすると、コード上で扱いやすくなります。

表示名は、設計者・運用者が会話やドキュメントで使う名前です。「ホーム」「サービス詳細」のような自然な日本語にします。プレフィックス（HM01、SV02など）と日本語名を組み合わせた表記にすると、設計書や運用マニュアルで参照しやすくなります。

両者を分けるのは、目的が違うからです。識別コードはシステムの安定性を優先して変更しないほうがよく、表示名は運用しやすさを優先して必要なら変更してよい性質を持ちます。たとえば「お知らせ詳細」を「ニュース詳細」に変更したい、となったとき、識別コードは NEWS_DETAIL のままで、表示名だけ「NW02 ニュース詳細」に変更すれば、システムへの影響を出さずに変更できます。

プレフィックスと連番に意味を持たせる

表示名の頭にプレフィックスをつけると、テンプレート一覧の見通しが格段によくなります。

サンプルで使ったプレフィックスを見てみます。

• HM = Home（ホーム）
• SV = Service（サービス）
• CS = Case Study（導入事例）
• NW = News（お知らせ）
• DL = Download（資料ダウンロード）
• SM = Seminar（セミナー）
• AB = About（会社概要）
• RC = Recruit（採用）
• CT = Contact（お問い合わせ）

プレフィックスがあるおかげで、テンプレート名を見た瞬間に「これはサービス系のページだな」「これはお知らせ系のページだな」と分類が見えます。テンプレートの数が30〜50を超える規模になると、プレフィックスがあるかないかで設計レビューの効率がまったく違います。

連番にも意味を持たせると、さらに整理しやすくなります。たとえば次のような使い分けが考えられます。

• 01〜09：そのカテゴリのメインのテンプレート（一覧、詳細など）
• 11〜：メインに従属する派生テンプレート（フォーム送信完了、検索結果、特殊な詳細など）

たとえばサービスのカテゴリで、SV01 が一覧、SV02 が詳細だったとして、サービス比較ページが後から追加されるなら SV03 とします。一方、サービス詳細から派生する「導入フロー」や「料金プラン」のような子ページは SV11、SV12 と分けます。こうすると、テンプレート一覧を見たとき「メインは1〜9、派生は11以降」と直感的に区別できます。

連番のルールは厳密でなくて構いません。大事なのは、設計時に何かしらのルールを決めて、テンプレートを増やすときに迷わないようにすることです。

フォーム有無の明示

テンプレートの中には、入力フォームを持つもの（運用者がコンテンツを編集するもの）と、持たないもの（一覧表示や検索結果など、自動生成されるもの）があります。

一覧の備考欄に「フォーム無し」と明示しておくと、設計時の見落としが減ります。フォーム有りのテンプレートは「運用者が触る画面（フォーム）の設計」が必要、フォーム無しのテンプレートは「表示ロジックの設計」だけでよい、という区別が一目でつきます。

たとえば「サービス一覧」はサービス詳細の情報を集めて自動表示するものなので、フォーム無し。「サービス詳細」は運用者がサービス内容を入力するので、フォーム有り。こういう区別を一覧に書いておきます。

変更履歴を残す

テンプレート一覧は、サイトの運用が始まった後も更新され続けます。新しいテンプレートが追加されたり、既存テンプレートの項目が変更されたりします。これらの変更履歴を、一覧の中に（または別シートに）残しておくと、後から「なぜこの変更がされたか」を追跡できます。

最低限残しておきたいのは、変更日、変更したテンプレート（識別コードまたは表示名）、変更内容です。たとえば「2025-04-01 / SV02 サービス詳細 / 『導入企業数』項目を追加」のような形式です。

変更履歴を残しておくと、次のような場面で役に立ちます。

• ベンダーとの打ち合わせで「いつから何が変わったか」を確認するとき
• 過去の運用トラブルの原因を遡って調査するとき
• リニューアル時に、現行サイトの仕様を漏れなく引き継ぐとき

この回のテスト観点

テンプレート一覧が実用に耐えるかは、次の観点で確認できます。

• すべてのページがテンプレートに紐づくか：サイトマップを引き出して、すべてのページが一覧にあるテンプレートのいずれかで作れることを確認する。1ページでも「これはどのテンプレートで作るんだ？」となるなら、一覧が不足している
• 識別コードに重複がないか：システム識別子なので重複は致命的。一覧をソートして目視確認するか、ツールでチェックする
• 新しいテンプレートを1つ追加してみる：仮に「採用詳細ページ」を追加するとして、どのプレフィックスを使い、何番をつけるか、迷わず決められるか。迷うようなら、命名規則がまだ言語化できていない
• 第三者が一覧だけ見て構造を理解できるか：設計者ではない人（社内の他部署、ベンダー、新しく入ったメンバー）に一覧を見せて、サイト構造を説明してもらう。スムーズに説明できれば、一覧が機能している

検証の方法論については第7回で詳しく扱います。

まとめ

テンプレート一覧は、CMS設計の最初に作る成果物です。識別コードと表示名を分け、プレフィックスと連番に意味を持たせ、フォーム有無を明示し、変更履歴を残す。一見地味な作業ですが、この一覧が運用の数年先までを支えます。

CMS設計には派手な作業と地味な作業がありますが、テンプレート一覧は地味な作業の代表格です。それでも、ここに時間をかける価値は十分にあります。設計レビューの効率、実装担当者への引き継ぎ、運用開始後のメンテナンスまで、すべての工程に効いてきます。

次回（第3回）は、複数のページから参照される情報をどう設計するか、共通パーツの話に入ります。

著者

STSD株式会社代表 鴻田孝雄。製薬企業のWebサイトを中心に、BtoB向けCMSの開発・設計に20年以上関わっている。長期運用を前提とした設計と、運用負担を最小化する仕組み作りに関心がある。