CMS設計の全体像――ページの洗い出しから実コンテンツでの検証まで

CMSは作って終わりではなく、5年、10年と運用が続く仕組みです。連載「CMS設計の実務指針」は、その長い期間にわたって運用者が迷わず、品質が保たれ、変更に柔軟に対応できるCMSをどう設計するかを扱っています。連載を通じて一貫しているのは、設計の段階で何を決めておくかが運用の数年先までを左右する、という考え方です。想定している読み手は、ある程度の規模のCMS構築・運用に実務として関わる人――導入プロジェクトのユーザー側責任者、Web担当者、運用部門のマネージャー、制作・開発会社のディレクターや設計担当――です。特定の製品や手法を推す内容ではありません。

このページでは、第0回から第7回までの全記事を横断し、連載の回の順ではなく、設計で判断していく順に並べ直しました。ページの種類を一覧にし、複数の場所に出る情報とその出る場所を洗い出し、ページ型ごとの作り方を決め、中身をパーツと項目に分け、仕組みに乗せないものを決め、最後に実コンテンツで確かめる、という順です。連載自身が述べているとおり、CMS設計に唯一の正解はなく、サイトの性質・運用体制・予算・運用期間によって最適な判断は変わります。個別の論点は、文中のリンクから各記事へ進めます。

設計の対象を4つに分ける

CMS設計の前に押さえておくべき4つの構成要素は、CMSの設計対象を次の4つに分けています。製品によって呼び方は違っても、本質的にはどのCMSもこの4つの単位を持っている、という整理です。

ページの中にパーツが並び、パーツは項目の集まりです。共通パーツも項目の集まりですが、同記事では、ページに直接配置されるのではなく、複数のページから参照されるものとされています。共通パーツは、CMSによって「実体」「マスタ」「コンテンツタイプ」などと呼ばれますが、機能としては同じものを指します。

構成要素を意識せずに設計すると、次のことが起きやすくなるとされています。

• 論点が混ざって決まらない。 「製品情報のページをどう作るか」という議論で、ページ全体の構成・パーツの種類・項目の名前が同時に飛び交うと、何を決めたのかがあいまいになる。
• 後から変更しにくい設計になる。 本来は「項目を追加すれば済む」話を、ページ全体を作り直す方向で議論してしまう。
• レビューで見落としが出る。 構成要素ごとに分けて確認すれば気づける問題が、混ざった状態では見えにくい。

製品情報を例にとると、「製品情報ページ（テンプレート）の中に、製品概要パーツ・添付文書パーツ・関連製品パーツが並ぶ」「製品情報そのものは共通パーツとして、複数のページから参照する」「製品情報の項目は、製品名・規格・薬価・添付文書PDF…」と分けて話すと、議論が前に進みやすくなります。設計レビューも構成要素の単位で行うほうが、網羅性が上がるとされています。

ただし、この4つの境目は、回によって引き方が少しずつ違います。共通パーツをページに「配置する」と書く回があること、「パーツ」が指す範囲が回ごとに違うことは、それぞれ該当する節で示します。

まず、サイトにあるページの種類を一覧にする

連載の中で「最初に」とされているものは一つではありません。第0回はページ（テンプレート）を「設計の出発点」とし、CMSのテンプレート一覧と命名規則は、何から手をつけるかは設計者によって違うと断ったうえで、筆者自身はサイト全体のテンプレート一覧を作るところから始める、と書いています。共通パーツの回は「設計の最初に、その共通パーツが表示されるすべての場所を洗い出す」、パーツの回は「最初に作るのは、ワイヤーフレームではなく実際のコンテンツが入ったモックアップ」としていますが、これらはそれぞれの回が扱う範囲の中での「最初」です。このページでは、ページの種類の一覧を起点に置きます。後の節で扱うページ構成方式は、ページ型ごとに決めるものだからです。

テンプレート一覧は、サイトに存在するページの種類を一覧にした表です。1つのテンプレートが1つのページの種類に対応します。「ホーム」「サービス詳細」「導入事例詳細」「お知らせ詳細」「会社概要」が、それぞれ別のテンプレートになります。一覧があると、設計レビューで網羅や重複を確かめられ、実装担当者は何を作ればよいかを一目で把握でき、運用開始後にページの種類を追加するときに既存のテンプレートとの整合を判断でき、リニューアルの引き継ぎ資料にもそのまま使えます。一覧を作らないまま設計が進むと、ページの種類が後から増えていったり、似たページが別々のテンプレートとして実装されたりして、サイト全体の見通しが悪くなります。

一覧に含めると役立つ項目として、識別コード、表示名、URL（パス）、パンくず、実装ファイル名、備考が挙がっています。実装ファイル名は技術寄りの情報なので設計段階では省く場合もありますが、運用ドキュメントとして使うなら、不具合報告が来たときに該当ファイルをすぐ特定できます。記事に載っているBtoBサービスサイトのサンプルから、一部を抜き出すと次のようになります。

システムの名前と、人が読む名前を分ける

テンプレートの名前は、システム上の識別子と、人が見る表示名の2系統に分けて持たせると運用が楽になる、とされています。識別コードは、実装ファイル名やデータベースのキー、ログ出力などで使う名前で、英大文字のスネークケース（HOME、SERVICE_DETAIL）にするとコード上で扱いやすくなります。表示名は、設計者と運用者が会話やドキュメントで使う名前で、自然な日本語にし、プレフィックスと組み合わせる（HM01 ホーム、SV02 サービス詳細）と設計書や運用マニュアルで参照しやすくなります。

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

この原則は、項目のレベルでも同じように効くとされています（CMSの項目（フィールド）設計）。「TITLE_MAIN」「DATE_PUBLISH」のような識別子を運用画面にそのまま出さず、運用者が見る項目名は「タイトル」「公開日」「メイン画像」のような自然な日本語にします。

プレフィックスと連番、フォームの有無、変更履歴

表示名の頭にプレフィックス（HM＝Home、SV＝Service、CS＝Case Study、NW＝News など）を付けると、名前を見ただけで何の系統のページかが分かります。テンプレートの数が30〜50を超える規模になると、プレフィックスの有無で設計レビューの効率がまったく違う、とされています。

連番にも意味を持たせられます。例として挙がっているのは、01〜09をそのカテゴリのメインのテンプレート（一覧、詳細など）、11以降をメインに従属する派生テンプレート（フォーム送信完了、検索結果、特殊な詳細など）とする使い分けです。サービス比較ページを後から足すなら SV03、サービス詳細から派生する「導入フロー」「料金プラン」のような子ページなら SV11、SV12 とします。ルールは厳密でなくてよく、設計時に何かしらのルールを決めて、テンプレートを増やすときに迷わないようにすることが大事だとされています。

テンプレートには、運用者がコンテンツを入力するフォームを持つものと、一覧表示や検索結果のように自動で生成されるフォームを持たないものがあります。備考欄に「フォーム無し」と書いておくと、フォーム有りのものは運用者が触る画面の設計が要り、フォーム無しのものは表示ロジックの設計だけでよい、という区別が一目でつき、設計時の見落としが減ります。サービス一覧はサービス詳細の情報を集めて自動表示するのでフォーム無し、サービス詳細は運用者が入力するのでフォーム有り、という具合です。

テンプレート一覧は運用が始まってからも更新され続けます。変更日、変更したテンプレート、変更内容（例：「2025-04-01 / SV02 サービス詳細 / 『導入企業数』項目を追加」）を一覧の中か別シートに残しておくと、ベンダーとの打ち合わせで「いつから何が変わったか」を確かめるとき、過去の運用トラブルの原因をさかのぼるとき、リニューアルで現行の仕様を漏れなく引き継ぐときに役立ちます。

複数の場所に出る情報は、出る場所から設計する

CMSの共通パーツ設計は、共通パーツを複数のページから参照される情報のかたまりとしています。BtoBサービスサイトなら、サービス情報、導入事例、セミナー情報、人物プロフィール、お知らせが候補です。これらは詳細ページに表示されるだけでなく、一覧ページ、ホームのセクション、関連表示など、サイトのあちこちに登場します。共通パーツとして一元管理すれば、1か所を更新するだけで参照しているすべてのページが更新されます。各ページに同じ情報をコピーして持たせていると、改訂のたびに全ページを手作業で直すことになり、直し漏れが起きます。

最初に「出し側」をすべて書き出す

同記事が共通パーツの設計でもっとも注意する点として挙げているのは、設計の最初に、その共通パーツが表示されるすべての場所（出し側）を洗い出すことです。詳細ページに必要な項目だけを見て設計すると、後で必ず破綻する、と書いています。よくあるのは、詳細ページで「これだけあれば十分」と設計し、運用が始まって一覧ページを作ろうとしたら「並び順のキーがない」「サムネイル画像のサイズが違う」「カテゴリで絞り込みたいのにカテゴリ項目がない」と気づくケースです。

サービス情報を例にとると、表示される可能性のある場所は最低でも次のとおりです。

1. サービス詳細ページ：すべての項目
2. サービス一覧ページ：タイトル、サムネイル、概要の冒頭、カテゴリ、並び順
3. ホームの「主要サービス」セクション：タイトル、サムネイル、ごく短い説明、リンク
4. 関連サービスの推奨欄：タイトル、サムネイル、ごく短い説明
5. 検索結果ページ：タイトル、概要の冒頭、URLパス
6. サイトマップ：タイトル、URLパス
7. お問い合わせフォームの「興味があるサービス」プルダウン：タイトルだけ
8. メールマガジン本文の関連サービス紹介：タイトル、ごく短い説明、URL
9. 管理画面の一覧表示：タイトル、公開日、ステータス

場所ごとに必要な情報は微妙に違います。一覧のサムネイルは、詳細ページのメインビジュアルとサイズや縦横比が違うかもしれません。ホームの主要サービス欄では短い説明文が欲しい一方、詳細ページの概要は500文字あるかもしれません。出し側をすべて洗い出すと、詳細ページだけを見ていては出てこない項目が見えてきます。サービス情報の場合は、次の項目が挙がっています。

• サービス名（フル）
• サービス名（短縮版、一覧やナビゲーション用）
• メインビジュアル（詳細ページ用、横長）
• サムネイル画像（一覧用、正方形）
• 概要文（詳細ページ用、500文字程度）
• 短い説明文（一覧用、80文字程度）
• 極短の説明文（ホーム・関連表示用、30文字程度）
• カテゴリ（絞り込み用）
• 並び順を決める数値項目
• 公開日（並び替え用）
• ステータス（公開・非公開）

表示場所ごとに長さや形を変えたいなら別々の項目を用意する、という考え方は、CMSのパーツ設計でも項目の粒度を決める観点の一つ（表示場所ごとに使い分けるか）として挙がっています。

表示パターンをセットで設計する

出し側が複数あるなら、それぞれの場所でどの項目をどう表示するか、つまり表示パターンも共通パーツとセットで設計します。サービス情報の例は次のとおりです。

• 詳細パターン：すべての項目をフル表示（メインビジュアル、サービス名（フル）、概要文、料金、関連資料リンクなど）
• カードパターン（一覧用）：サムネイル、サービス名（フル）、短い説明文（80文字）、カテゴリ、詳細ページへのリンク
• コンパクトパターン（ホーム・関連表示用）：サムネイル、サービス名（短縮版）、極短の説明文（30文字）、詳細ページへのリンク
• テキストパターン（サイトマップ用）：サービス名（フル）、URLパス
• プルダウン用パターン：サービス名（短縮版）と内部識別子だけ

表示パターンを決めずにおくと、実装担当者が表示場所ごとに自分の判断で使う項目や文字数を決めることになり、表示ルールがコードのあちこちに散らばります。後から「ホームの主要サービス欄の文字数を変えたい」となったとき、どこを直せばよいか追えなくなります。設計書に表示パターンを明記しておけば、表示ルールが一か所に集まります。

なお、一覧で使うサービス名については、記述がそろっていません。同じ記事の中で、項目リストは短縮版を「一覧やナビゲーション用」としている一方、一覧用のカードパターンはサービス名（フル）を使っています。項目設計の回の説明文サンプルも、「サービス名 - 短縮表示用」の使用箇所に「サービス一覧」を含めています。また、出し側にサイトマップを入れて表示パターンまで設計する考え方に対して、HTMLサイトマップはCMSで自動生成せず直書きにすることを勧める回があります。これは「仕組みに乗せない領域」の節で扱います。

並び順と絞り込みのキー、共通パーツどうしの関係

一覧に出る共通パーツには、並び順や絞り込みのキーになる項目を最初から含めておきます。並び順のキーとしてよく使うのは、公開日・更新日、カテゴリ・タグ、並び順専用の数値項目、人気度・閲覧数（自動集計）です。絞り込みのキーも、ほぼ同じカテゴリ・タグ系の項目になります。

同記事は、並び順専用の数値項目を最初から1つ持たせておくことを設計の原則として挙げています。「念のため」の項目ですが、運用が始まってから「主要サービスを上に固定したい」「キャンペーン中のサービスを目立たせたい」といった、公開日順や更新日順では応えられないニーズが出てくることが非常に多いためです。後から追加すると、既存のデータすべてに値を埋める作業が発生します。

共通パーツどうしが関係を持つこともよくあります（サービスと導入事例、サービスと関連資料、セミナーと登壇者、導入事例と業種など）。設計時の判断ポイントは3つです。

• 親子関係か、参照関係か。 サービスを削除したら関連する事例も削除されるべきか、孤立する事例として残すか。事例側がサービスを参照しているだけなら、削除時の影響はない。
• 1対多か、多対多か。 1つの事例が複数のサービスに紐づく可能性があるなら多対多で、関係を保持する別の仕組み（中間テーブル、タグ機能など）が要る。
• 双方向の参照が要るか。 事例からサービスを見る向きも要るなら、両側から参照できる仕組みが要る。

これらは技術寄りの判断に見えますが、運用フローに直結します。「サービスを廃止するときに関連事例をどうするか」は、最終的には運用ルールの話になります。関係を明確にしておかないと、運用開始後に廃止サービスの事例だけが孤児として残る、といったことが起きます。

ページ型ごとに、作り方の方式を決める

CMSのページ構成方式の選び方は、運用者がページを作るときの画面の形式を、次の4つの方式に整理しています。記事の出発点は、一つのサイトの中で、ページごとに違う方式を選んでよい、ということです。製品全体の特性を比べる場面では「このCMSはブロック積み上げ型」といった話でかまいませんが、自社のサイトを設計するときは視点を変えたほうがうまくいく、としています。サイト全体を一つの方式で統一しようとすると、必ずどこかに無理が出る、とされています。すべてを定型フォームにするとコラムや特設ページが書きにくくなり、すべてをブロック積み上げにすると製品情報のような構造化が必要なコンテンツで運用品質がばらつきます。

定型フォーム型は、入力のばらつきや表記揺れ、入れ忘れが起きにくく、一覧・検索・絞り込みを実装しやすい方式です。混合型は、必須情報の品質を保ちながら本文の自由度を確保でき、一覧に要るタイトル・日付・サムネイルが確実にそろいます。第0回の予告とこの記事のタイトルでは、定型フォーム型を「固定フォーム」とも呼んでいます。

ブロック積み上げ型の「ブロック」として挙がっている見出し・画像付きテキスト・引用は、第0回が「パーツ」の例として挙げているものとほぼ重なります。「パーツ」と「ブロック」の関係は、次の節で整理します。

選ぶときの3つの判断軸

• コンテンツの構成は決まっているか。 項目の構成があらかじめ決まっているなら定型フォーム型が第一候補、コンテンツごとに構成が変わるならブロック積み上げ型を検討する。
• 一覧・検索・関連表示の対象になるか。 他の場所でも使われるなら、定型フォーム型か混合型が向く。本文がブロックで分散していると、一覧で「本文の冒頭○文字」を取り出すのが難しくなる。
• 運用者のリテラシーと運用体制。 運用者が複数いてスキルにばらつきがあるなら、定型フォーム型のほうが品質がそろう。少人数で全員のリテラシーが高いなら、ブロック積み上げ型でも品質を保てる。

方式はページ型ごとに固定し、運用者に選ばせない

複数の方式を混在させるときは、ページ型ごとに方式を決めて固定します。同じページ型の中で運用者が方式を選べるようにすると、人によってページの作り方がばらつきます。方式の選択は、運用者ではなく設計時の判断にとどめます。そのうえで、テンプレートごとに「このページは定型フォームで作ります」と明示しておくと、運用者が迷いません。設計の初期段階で運用マニュアルの構成も合わせて考えておくと、後の運用が楽になるとされています。

エディタ単体型について、この回は、他の方式が使えない場合の選択肢として捉えるのが安全だとし、継続的に更新されるコンテンツや、複数ページに同じパターンが出るコンテンツには向かないとしています。一方で、この方式を例外用の「逃げ場」として最初から用意しておくことを勧める回もあります。これも「仕組みに乗せない領域」の節で扱います。

ページの中身をパーツに分ける

CMSのパーツ設計は、パーツ設計を「デザインを、適切な粒度の項目に分解する作業」と一言で表しています。デザイナーから上がってきたワイヤーフレームやモックアップをそのまま入力させようとすると、運用者は画像編集ソフトのような自由度を求められ、品質が保てません。画面に並ぶ要素を「タイトル」「画像」「本文」のような項目に分け、運用者は項目に値を入れるだけで画面ができあがる仕組みを用意するのが、設計者の仕事だとしています。

3つのステップ

1. 実コンテンツでモックアップを作る。 ダミーテキストで作ると、必要な項目を見落とすことが多い。実際のコンテンツを入れて初めて、「タイトルが想定より長い」「画像のサイズ感が一覧と詳細で違う」「複数行になるとレイアウトが崩れる」といった問題が見える。このモックアップが、後で分解するときの基準になる。
2. ページを大きなパーツに分ける。 サービス詳細ページなら、ヘッダー、パンくずリスト、サービス概要パーツ（メインビジュアル＋サービス名＋導入文）、サービス特徴パーツ、料金パーツ、導入事例パーツ、関連資料パーツ、お問い合わせCTAパーツ、フッター。この段階では中身の項目はまだ決めない。
3. 各パーツを項目に分ける。 サービス概要パーツなら、メインビジュアル（画像）、サービス名（1行テキスト、50文字以内）、キャッチコピー（1行テキスト、80文字以内）、導入文（複数行テキスト、500文字以内）。この段階で項目の数と大まかな入力の型を決め、詳細は項目設計で詰める。

粒度を決める3つの観点

粒度が粗すぎると入力の制御が効かず、細かすぎると運用者の負担が増えます。目安として挙がっている観点は次の3つです。

• その情報を独立して使うか。 都道府県で絞り込みたいなら、住所を分けて都道府県を独立した項目にする。表示するだけなら1項目でかまわない。
• 入力のばらつきを抑えたいか。 製品概要を1つの自由記述にするより、「特徴1・特徴2・特徴3」と分けると書き方がそろう。
• 表示場所ごとに使い分けるか。 詳細ではフル表示、一覧では短縮表示のように変えたいなら、「概要文（500文字）」「短い説明文（80文字）」と別の項目にする。

こうして決めると、画面の都合だけで項目を増やすのではなく、コンテンツに必要な粒度で項目を持てる、とされています。

種類を絞り、ネストさせず、デザインは決め打つ

パーツの設計には、3つの指針が挙がっています。

種類を意図的に絞る。 「見出し付きテキスト」「画像付きテキスト」「2カラムテキスト」は、項目で見ると「見出し（任意）＋画像（任意）＋本文＋レイアウト指定」という1つの構造にまとめられます。1つのパーツにして、項目の値で出力が変わる形にすれば、運用者は迷わずに済みます。目安は、サイトで使うパーツを10種類以内に抑えることです。種類が増えると、運用者は「どれを使えばいいかわからない」状態になり、結局1〜2種類しか使われなくなる、とされています。ページ構成方式の回も、ブロック積み上げ型の短所として、ブロックの種類が増えすぎると運用者が選べなくなることを挙げています。

ネストは原則として禁止する。 パーツの中にパーツを入れられると、運用者はどのレベルに何を入れるかを考えなければならず、階層が深くなるとページの構造を把握できなくなります。「カラム分割の中に他のパーツを入れたい」なら、最初からカラム分割込みのパーツ（「2カラムテキスト＋画像」など）として設計します。同記事は、ネストが必要に思えるケースは、たいてい共通パーツとして独立させるべきサインでもあるとし、「複雑な構造のものを共通パーツとして1つ作り、ページ内では1パーツとして配置する形にすると、ネストの問題が消えます」と書いています。第0回が、共通パーツは「ページに直接配置されるのではなく、複数のページから参照されます」としているのとは、書き方が異なります。共通パーツをページに置く部品として扱うのか、ページから参照される情報として扱うのかは、連載の中で整理されていません。

出力デザインは設計側で決め打つ。 文字色・文字サイズ・背景色・アライメントなどを運用者が選べる仕様は、人によって判断がぶれ、サイト全体の見た目がばらつくため、運用品質を下げるとされています。どうしても複数のデザインが要るなら、「カード型のCTAボタン」と「バナー型のCTAボタン」のように別のパーツとして用意します。同じパーツの中で型を選ばせるより、運用者は迷いません。

「パーツ」が指す範囲は、回によって違う

「パーツ」という語は、回によって指す範囲が違います。どれかに寄せず、使われ方を並べておきます。

パーツが運用者の積み上げる部品を指すのか、設計者が固定するページの区画まで含むのかは、記事の中で定められていません。ヘッダーのような共通領域は、第4回では共通領域と呼んだうえでパーツの一種として捉えるとされ、第6回では共通領域として扱われています。

項目の名前と説明文で、設計の意図を運用者に渡す

設計者は、項目がサイトのどこに表示されるか、どんな値を入れるべきか、上限は何文字か、他の項目とどう関係するかを、すべて頭の中に持っています。運用者に見えるのは、画面に並んだ項目名と説明文だけです。CMSの項目（フィールド）設計は、運用中の問い合わせの多くは項目名と説明文を丁寧に作り込めば防げるとし、この作業を、設計者の頭の中にある暗黙知を書き出す作業と位置づけています。

項目名：運用者の言葉で、用途が分かる名前にする

運用者が見る項目名は、説明されなくても何を入れる場所か想像できる自然な日本語にし、システムの識別子とは分けて持たせます（テンプレートの表示名と同じ原則です）。

同じ種類の項目が複数要るときは、主たる項目名の後ろに用途を示す接尾辞を付けます。例として挙がっているのは「サービス名」「サービス名 - 短縮表示用」「サービス名 - 法人名」「サービス名 - 通称」「サービス名（ふりがな）」です。「サービス名2」「サービス名B」のような番号や記号ではなく、名前から用途が分かる形にします。「タイトル」「タイトル2」「タイトル3」のような状態になっていたら、用途を明確にした名前に整理し直します。

説明文：何よりも「使用箇所」を書く

説明文に書く内容は、おおむね4つです。

1. 使い方（その項目に何を入れるか）
2. 具体例（実際の入力例）
3. 使用箇所（その値がサイトのどこに表示されるか）
4. 注意点（守ってほしいルール、ありがちなミス）

すべてを書く必要はありませんが、運用者が判断するのに要る情報はそろえておきます。書ける文字数や行数に制約があるときの優先順位は、使用箇所、具体例、注意点、使い方の詳細の順です。使用箇所が最優先なのは、運用者が「この項目を変えたらサイトのどこに影響が出るか」を把握していないと、怖くて編集できないからだとされています。基本形のサンプルは次のとおりです。

サービス名 - 短縮表示用
一覧やナビゲーション用の短縮形のサービス名をご設定ください。
例）「○○分析プラットフォーム」が正式名称の場合、「○○分析」のように短縮します。
使用箇所）サービス一覧、ホームの主要サービスセクション、グローバルナビ、
関連サービスの推奨欄など、限られたスペースで表示する場面で利用されます。
*正式名称をすべて表示できる場合は、「サービス名」項目の値が使われます。

ほかにも、選択肢のパターンが多い項目では、どの値を入れると何が起きるかを辞書のように引ける一覧にしておく、似た名前の項目（「自由HTML（上部）」「自由HTML（下部）」など）はそれぞれどんな場面で使うかを書き分け、「自由項目だから何でも入れていい」と運用者に判断させない、チェックボックスはチェックを入れたら何が起きるか（例：「準備中」にチェックすると関連サービス・関連事例の推奨欄に表示されない）を明確に書く、といった例が挙がっています。

型と文字数、必須・任意・初期値

入力の型（1行テキスト、複数行テキスト、リッチテキストエディタ、数値、日付・日時、選択肢、画像、ファイル、リンク）を適切に選ぶと、入力ミスが減ります。日付を1行テキストで入力させると「2026/1/15」「2026年1月15日」「1/15」のように形式がばらつきますが、日付型ならカレンダー入力になり形式がそろいます。

文字数の上限は、表示画面のレイアウトから逆算して決めます。一覧でタイトルが2行に収まるべきなら、その文字数が上限です。項目名の横に「（50）」のように最大文字数を出しておくと、運用者は入力しながら長さを意識できます。説明文に「全角40文字を超えると、一覧ページで末尾が省略されます」のような注意書きを入れておくと、表示崩れを防げます。

必須にするかどうかの判断軸は、その項目が空のときにサイトの表示が破綻するかどうかです。タイトル・公開日・メイン画像のような項目は必須、補足情報や任意の関連リンクのように、なくても表示が成立する項目は任意にします。必須項目が多すぎると、運用者は「とりあえず仮の値を入れておく」ようになり、データの品質がかえって下がる、とされています。初期値を設定できる項目には、公開日に「今日の日付」、ステータスに「下書き」、カテゴリに「未分類」のような値を入れておくと、入力の負担が減ります。

選択肢はマスタにする

プルダウン・ラジオボタン・チェックボックスの選択肢は、各ページで直接書かせず、カテゴリマスタ、タグマスタのような選択肢のマスタから選ばせる仕組みが勧められています。表記揺れ（「お知らせ」と「おしらせ」）が防げる、選択肢の追加・変更が一括でできる、選択肢が増えても既存ページを直さずに済む、後で選択肢ごとの集計がしやすい、という利点が挙がっています。選択肢が3〜5個で固定的なものは直接定義してもよく、運用中に増減しそうなものはマスタにしておくと後が楽になる、という線の引き方です。

ここでの「マスタ」は選択肢の一覧のことで、第0回が共通パーツの別名の一つとして挙げている「マスタ」とは別のものを指しています。

仕組みに乗せない領域と、型に収まらないページの逃げ場を決める

ここまでの節は、判断を設計の側に集め、運用者は値を入れるだけで済む仕組みを作る話でした。ヘッダー・フッターはCMS管理すべきかは、その仕組みに乗せない範囲を決める話です。

CMSの設計では「すべてを仕組みに乗せたい」という発想になりがちです。しかしサイトには必ず定型から外れるケースがあります。複数ドメインのまたぎ、特設サイトとの連携、外部サービスへのリンク、季節限定のキャンペーンページ、グループ会社のサイトとの連携。こうした変則ケースで、自動生成の仕組みは破綻しがちだとされています。同記事は、「自動化する範囲」と「自動化しない範囲」を意識的に線引きし、自動化しない領域を残しておくことが長期運用の柔軟性を支える、としています。

ヘッダー、フッター、HTMLサイトマップは直書きを勧めている

ヘッダー・グローバルナビ。 CMSの設定画面でナビ項目を編集できると便利に見えますが、実務では、一部のページだけナビの構成を変えたい、外部サイトへのリンクを混ぜたい、キャンペーンを一時的に目立つ位置に足したい、複数のサブドメインや別サイトと統合したい、ハンバーガーメニューの中だけ構成を変えたい、ログイン状態や属性で出し分けたい、といった要望が頻繁に出てきます。そのたびに自動生成の機能を拡張していくと設定画面が複雑になり、最終的には「何ができて何ができないのか、設計者しか分からない」状態になります。直書きにしておけば、HTMLを直接編集するだけで、CMSの仕様に縛られずに対応できます。同記事は、ヘッダーの「共通」は常に1つの定型に収まるという意味ではなく、サイト全体で見せたい情報を状況に応じて柔軟に組める領域と捉えたほうが、長期運用の実態に合う、としています。

フッター。 会社情報、関連リンク、SNSリンク、コピーライト、プライバシーポリシーへのリンクなど、入る情報はサイトによって様々です。認定マークや業界団体のロゴの追加、業界によって増えていく関連法令の注釈、多言語サイトでの切り替え、グループ会社のリンク、季節の挨拶や営業時間変更の一時的な告知など、追加・修正は想像以上に発生するとされています。CMSで管理したい背景には「運用者が編集できるようにしたい」という意図があるかもしれませんが、実態としてフッターの編集は頻度が低く、編集できるのは限られた担当者です。それなら、HTMLを直接編集できる体制を整えておくほうが実務に合う、という考え方です。

HTMLサイトマップ。 ページ一覧を取得して階層どおりに並べれば、技術的には自動生成できます。問題は、機械的に作ったサイトマップが人にとって見やすいとは限らないことです。人向けのサイトマップには、カテゴリの並び順が導線として自然である、階層が深すぎない、重要なページが目立つ位置にある、廃止されたページや古いページが出ない、外部サイトや関連サイトへのリンクも含まれる、といった特性が求められます。これらは人が判断して組むほうが品質が高くなり、機械任せにすると見せたい順序や強調が崩れる、とされています。更新の手間は「数ヶ月に一度の作業」程度で、見にくいサイトマップを放置するほうが長期的な品質を下げる、という比較です。

サイトマップについては、回によって扱いが異なります。

両記事とも互いのこの記述には触れておらず、どういう場合にどちらを採るかは連載の中で示されていません。ヘッダー・フッター・パンくずについては、パーツ設計の回が、設計上はパーツの一種として認識しておき、CMSで管理するか直書きにするかの判断はこの回で扱う、としています。ただし、この回が取り上げているのはヘッダー・フッター・サイトマップで、パンくずには触れていません。

型に収まらないページの「逃げ場」

ヘッダー・フッター・サイトマップ以外にも、定型のテンプレートに収まらないページが運用中に出てきます。特設ページ・キャンペーンページ、法務系ページ（プライバシーポリシー、利用規約、特定商取引法表記）、採用情報の特設ページ、お詫び・告知ページ、周年記念やブランドメッセージのページ、外部サービス連携用のページなどです。共通するのは、他のページと構造が違うか、1回限りの特殊なデザインが要ることです。これらを既存のテンプレートで無理に作ろうとすると、テンプレートが歪みます。

同記事は、エディタ単体型のテンプレートを「逃げ場」として設計時に最初から1つ用意しておくことを勧めています。常用するものではありませんが、想定外のページを作りたいというニーズが出たとき、既存のテンプレートを無理に拡張せずに済みます。逃げ場を用意しておくのは設計が雑であることの裏返しではなく、現実の運用に対応する設計判断であり、例外を例外として扱える設計のほうが長期運用に耐える、としています。

エディタ単体型の位置づけは、2つの回で力点が違います。ページ構成方式の回は「他の方式が使えない場合の選択肢として捉えるのが安全」と、なるべく使わない側から書いています。この回は、例外のために計画して用意しておくもの、として書いています。どちらも常用は勧めていません。

線引きの4つの観点

自動化するか直書きにするかを判断するときの観点として、次の4つが挙がっています。これらで自動化の利得と直書きの利得を比べ、領域ごとに判断します。

• 変則対応の頻度。 定型から外れる対応が年に数回でも発生するなら、直書きを基本にしたほうが楽。本当に定型だけで運用される領域は、自動化が向く。
• 編集者の人数とスキル。 編集する人がHTMLを書けるなら直書きで問題ない。書けない場合は自動化したくなるが、変則対応の頻度が低いなら、HTMLを書ける担当者に依頼する体制で運用するほうが、結果として柔軟になる。
• 自動化で生じる制約。 自動化すると、CMSの仕様に縛られた範囲でしか変更できなくなる。その制約が長期運用で困りそうなら、直書きを選ぶ。
• 例外ケースが想定されるか。 定型の構造で表せないケースが将来起こり得るなら、定型化せず、エディタ単体型での運用を視野に入れる。

設計を仕様として、実コンテンツで確かめる

CMS設計を実コンテンツで検証するは、テストを「仕様の通りに動作することを確認する作業」と定義し、「動かしてみて、何か問題がないか探す」作業ではない、としています。仕様があいまいなまま検証を始めると、テストの基準そのものが存在せず、見つかった問題が仕様の不足なのか実装のミスなのかを区別できません。

同記事は、第2回〜第6回で扱ってきた設計の成果物が、どれも「何が正しい状態か」を定める仕様だったと振り返っています。

テンプレート一覧があるから「すべてのページがいずれかのテンプレートで作れること」を確かめられ、項目の説明文があるから「運用者が説明文だけで自己解決できること」を確かめられる、という関係です。なお、この表は第2回〜第6回を挙げていて、ページ構成方式（第1回）は含まれていません。

一方で、ページ構成方式・パーツの回のテスト観点には、運用者役の人に触ってもらい、違和感や迷いをフィードバックとして集める、という確認も入っています。仕様どおりかを確かめる検証と、触ってもらって気づきを集める確認の両方が、連載の中にあります。

ダミーではなく実コンテンツを使う

ダミーデータは均等な長さで作られていることが多く、極端なケースが含まれません。実コンテンツには、ダミーが想定していない状態が含まれています。

• タイトルが極端に長い、または極端に短い
• 画像が用意されていない、または想定外の縦横比
• 任意項目が空のまま保存されている
• 特殊文字・絵文字・記号が含まれている
• 半角・全角の表記揺れがある
• 想定していない言語が混ざっている
• 過去のサイトから引き継いだ古い形式のデータ

共通パーツの回は、これに加えて、極端に古いもの・極端に新しいものも試すデータに挙げています。こうした状態は運用が始まれば必ず発生し、実コンテンツを入れた瞬間にレイアウト崩れ・項目不足・並び順の乱れなどとして見えてくる、とされています。パーツ設計の回も、ダミーテキストでモックアップを作ると必要な項目を見落とすことが多いとして、最初のステップで実コンテンツのモックアップを作るとしています。

階層ごとに確かめること

各回の末尾にあるテスト観点と、検証の回の観点を、設計の階層ごとにまとめると次のようになります。

テンプレート

• すべてのテンプレートに、最低でも3〜5件の実コンテンツを登録できるか。想定どおりのURLで公開され、パンくずが一覧の定義どおりに出て、一覧と詳細の関係が成り立っているか。
• サイトの全ページが、一覧にあるいずれかのテンプレートで作れるか。1ページでも「どのテンプレートで作るのか」となるなら、一覧が足りていない。
• 識別コードに重複がないか。
• 新しいテンプレート（例：採用詳細ページ）を1つ足すとして、プレフィックスと番号を迷わず決められるか。迷うなら、命名規則がまだ言語化できていない。
• 設計者でない人（他部署、ベンダー、新しく入ったメンバー）が、一覧だけを見てサイト構造を説明できるか。

ページ構成方式（検証の回の枠組みには入っていない、第1回の観点）

• そのページ型で作る予定のコンテンツを最低でも3〜5パターン想定し、選んだ方式で無理なく作れるか。
• 既存コンテンツがあれば実際に登録してみて、表現できるか。できない要素があれば、方式を見直すか、例外処理を設計に組み込む。
• 運用者役の人に試作で入力してもらい、フィードバックを受ける。

共通パーツ

• 洗い出した全表示場所（一覧、ホームの関連表示、検索結果、メールテンプレートなど）に実データを表示し、表示パターンごとに必要な項目がそろっているか。不自然な場所や足りない項目があれば、共通パーツの項目設計に戻る。
• 「特定の項目で並び替えたい」というニーズが出たとき、既存の項目で対応できるか。できないなら並び順のキーが足りない。
• 1件を削除または非公開にしたとき、参照しているページでリンク切れ・孤児データ・表示崩れが起きないか。共通パーツどうしの関係が、データの追加・削除で破綻しないか。

パーツ

• 用意したパーツの組み合わせで、想定される全ページが作れるか。長いタイトル・短いタイトル・画像なしなどでモックアップが崩れないか。
• 項目構成がほぼ同じパーツが複数ないか。「微妙にレイアウトが違うだけ」「項目が1つ違うだけ」のパーツは統合の候補（パーツの回）。検証の回は、似たパーツが複数ある場合に運用者がそれぞれの使い分けを理解できるか、パーツの種類が多すぎて運用者が迷わないかを確かめる、としている。
• 運用者役の人に「このコンテンツを作るならどのパーツを使うか」と聞く。迷ったり「どれでも作れる」と感じたりするなら、種類を絞る余地がある。
• 項目の粒度が細かすぎて負担になっていないか、粗すぎて品質がばらついていないか。出力デザインが想定したトーン＆マナーを保っているか。

項目

• 設計者以外の人に項目名だけを見せ、何を入れる項目か説明してもらう。
• 運用者役の人に説明文だけを読んで入力してもらい、「分からなくて手が止まった」「設計者に聞きたくなった」項目を洗い出す。
• 「タイトル」「タイトル2」のような似た項目を正しく使い分けられるか。
• すべての項目の説明文に使用箇所が書かれているかを棚卸しする。
• 文字数制限・必須と任意・初期値が、実コンテンツで適切か。

自動化しない領域

• 想定される変則ケース（「グループ会社のリンクを追加したい」「キャンペーンページのヘッダーを変えたい」など）を5つ書き出し、設計した仕組みで対応できるか。すべてを設計時に解決する必要はないが、対応できないケースでどう逃げるかは事前に考えておく。
• 直書きの領域を編集できる体制が整っているか。
• 自動化した領域を誰がどこまで編集できるか。「設計者しか触れない」状態と「想定外の変更ができてしまう」状態の両方を確かめる。
• エディタ単体型のテンプレートで実際に1ページ作り、「エディタはあるが実際には使えない」状態になっていないか。
• 自動化する領域としない領域の境界が、運用者に伝わるか。

見つかった問題は、まず仕様に戻す

検証で問題が見つかったときの出発点は、仕様の見直しです。たとえば「サービス情報の一覧で、業種別の絞り込みができない」と分かったら、実装に絞り込み機能を足す前に、「サービス情報という共通パーツに業種項目を追加する」という仕様の更新を行い、それに沿って実装を直します。このループを徹底すると仕様と実装が常に一致し、仕様書にない暗黙の機能が実装に紛れ込まず、後から仕様を見れば実装の状態が分かる、とされています。

検証は運用開始の直前に1回だけ行うものではなく、設計の各段階で繰り返します。

1. 仕様が一通りそろった段階で、最初の検証を行う
2. 見つかった問題を仕様に反映し、再度検証する
3. 実装が進んだら、実装と仕様の整合を検証する
4. 運用直前に、本番に近い実コンテンツで最終検証を行う
5. 運用開始後も、新しい問題が見つかれば仕様に戻して更新する

同記事は、「設計を終えてから検証する」のではなく「検証を通じて設計を完成させる」と捉えると設計の品質が上がる、としています。第0回も、設計時に「これをどうテストするか」まで考えておくと、後工程の手戻りを大きく減らせる、と書いています。

全体を通して見えること

このページで並べ直した順にまとめると、次のようになります。

1. サイトにあるページの種類を一覧にし、名前を付ける（テンプレート一覧）
2. 複数の場所に出る情報を見つけ、出る場所をすべて書き出す（共通パーツ）
3. ページ型ごとに作り方の方式を決め、固定する（ページ構成方式）
4. ページの中身をパーツに分け、パーツを項目に分ける（パーツ）
5. 項目に、運用者が読む名前と説明文を付ける（項目）
6. 仕組みに乗せない領域と、型に収まらないページの逃げ場を決める（自動化しない領域）
7. ここまでの成果物を仕様として、実コンテンツで確かめ、問題は仕様に戻す（検証）

方式・共通パーツ・パーツ・項目の各回には、判断を設計の段階で決めておき、運用者や実装担当者のその場の判断に任せない、という書き方が共通しています。方式はページ型ごとに固定して運用者に選ばせない、表示パターンを設計書に書いて実装担当者任せにしない、パーツの種類を絞りデザインを決め打つ、自由項目にも想定する用途を書く。そのうえで、自動化しない領域の回は、運用の中で出てくる例外を収める場所を設計の側に残しておくことを勧めています。

もう一つの軸は、表示する側から逆算することです。共通パーツの出し側、表示場所ごとに分ける項目、説明文の使用箇所、レイアウトから逆算する文字数、一覧や検索の対象になるかという方式の判断軸は、どれも「どこに出るか」を起点にしています。さらに、ページ構成方式・共通パーツ・パーツ・検証の各回は、ダミーではなく実際のコンテンツやデータで確かめることを求めています。

連載の結びにあるとおり、最適な判断はサイトの性質・運用体制・予算・運用期間によって変わり、連載はその判断の軸を作る材料として書かれています。