CMS要件を設計する
このページで学ぶこと
Section titled “このページで学ぶこと”- CMS製品を選ぶ前に整理する業務・コンテンツ・技術要件
- コンテンツモデルを画面項目ではなく再利用可能な情報構造として設計する方法
- 権限、承認、予約公開、プレビューの設計
- 移行、環境分離、Webhook、検索連携、バックアップの確認事項
- CMS比較表と要件定義書へ落とし込む方法
CMS要件は、入力欄の一覧ではありません。
flowchart TD
B[業務・運用] --> M[コンテンツモデル]
M --> W[公開ワークフロー]
M --> F[表示・検索・多言語]
W --> R[権限・承認]
M --> I[移行]
M --> A[API・Webhook]
A --> H[フロント・ホスティング]
B --> O[保守・契約・バックアップ]
CMS製品を先に決めると、その製品の機能へ要件を合わせることになります。
まず、誰が何を、どの頻度で、どのように公開し、どこで再利用するかを整理します。
1. CMS化する範囲
Section titled “1. CMS化する範囲”すべてのページをCMS化する必要はありません。
CMS化の価値が高いもの
Section titled “CMS化の価値が高いもの”- 頻繁に更新する
- 同じ形式のページが増える
- 一覧・検索・絞り込みに使う
- 複数の場所へ再利用する
- 公開日時・カテゴリ等を管理する
- クライアント側で更新する
CMS化の価値が低い場合があるもの
Section titled “CMS化の価値が低い場合があるもの”- 更新しない単発ページ
- 高度な演出で個別実装が必要
- 数年に一度だけ制作会社が更新
- CMS入力へ置き換える方が複雑
- 法令・外部システム等の別管理が正本
「更新できるようにする」だけでなく、誰が更新し、構築費と運用効果が見合うかを判断します。
2. コンテンツ棚卸し
Section titled “2. コンテンツ棚卸し”既存サイトや必要コンテンツを一覧化します。
| 項目 | 確認内容 |
|---|---|
| 種類 | ニュース、製品、施設、FAQ等 |
| 件数 | 現在・年間増加・最大想定 |
| 更新頻度 | 毎日、月次、年次等 |
| 更新者 | 部門、店舗、制作会社 |
| 公開期限 | 常設、期間限定 |
| 関連 | カテゴリ、製品、施設等 |
| 多言語 | 言語数、翻訳単位 |
| 移行 | 自動・手動、品質 |
| 再利用 | 一覧、トップ、アプリ等 |
| 正本 | CMSか別業務システムか |
同じ「お知らせ」でも、IR開示と店舗臨時休業では運用・項目・承認が異なる場合があります。
3. コンテンツモデル
Section titled “3. コンテンツモデル”コンテンツモデルは、どの種類の情報を、どの項目と関係で管理するかを定義します。
erDiagram
FACILITY ||--o{ EVENT : 開催する
FACILITY }o--o{ FEATURE : 備える
EVENT }o--|| CATEGORY : 属する
FACILITY {
string name
string address
number latitude
number longitude
}
EVENT {
string title
datetime startAt
datetime endAt
}
画面単位だけで作らない
Section titled “画面単位だけで作らない”「トップページ用CMS」「右カラム用CMS」のように見た目だけで分けると、リニューアル時に再利用しにくくなります。
まず「施設」「イベント」「製品」「著者」等の意味のある情報単位を作り、表示側で組み合わせます。
ただし、キャンペーンページの自由編集等、ページ構成を管理するモデルが必要な場合もあります。
各項目について決めます。
- 項目名
- 説明
- データ型
- 必須・任意
- 文字数
- 初期値
- 選択肢
- 複数可否
- 検索対象
- API利用
- 多言語
- 入力例
- 公開後の用途
「備考」のような自由入力欄へ多くを詰め込むと、将来の検索・出し分けが難しくなります。
イベントから施設を選択する、記事から著者を選択する等、コンテンツ同士を関連づけます。
利点：
- 同じ情報を重複入力しない
- 関連一覧を作れる
- 一括変更できる
- APIで意味を保てる
注意点：
- 参照先を削除した場合
- 非公開の関連データ
- 循環参照
- 取得回数・深さ
- 編集者が関係を理解できるか
4. 画像・ファイル
Section titled “4. 画像・ファイル”画像管理では次を決めます。
- 推奨サイズ・比率
- 最大容量
- 形式
- トリミング
- 代替テキスト
- キャプション
- 著作権
- 利用期限
- ファイル名
- 重複
- 削除時の影響
- 画像加工API
- CDN
PDFでは、タイトル、公開日、カテゴリ、ファイル容量、改訂版、アクセシビリティ等を管理します。
メディアを削除したとき、公開ページ・過去記事・外部利用が壊れないか確認します。
5. 多言語
Section titled “5. 多言語”多言語の管理方式には次があります。
一つのコンテンツに言語別項目
Section titled “一つのコンテンツに言語別項目”- 日本語タイトル
- 英語タイトル
- 日本語本文
- 英語本文
言語対応関係が分かりやすい一方、言語数が増えると編集画面が大きくなります。
言語ごとに別コンテンツ
Section titled “言語ごとに別コンテンツ”柔軟ですが、対応関係、公開状態、URL、未翻訳時の扱いを管理します。
外部翻訳サービス
Section titled “外部翻訳サービス”機械翻訳・翻訳管理と連携する場合、正本、再翻訳、固有名詞、承認、翻訳反映を決めます。
言語ごとに公開日時が違うか、未翻訳時に日本語を出すか、非表示にするかを要件化します。
役職名だけでなく、操作単位で整理します。
| 操作 | 例 |
|---|---|
| 閲覧 | コンテンツ・設定を見る |
| 作成 | 新規下書きを作る |
| 編集 | 自分・他人の内容を変更 |
| 公開 | 公開状態へ変更 |
| 削除 | コンテンツを削除 |
| メディア | 画像・PDFを管理 |
| スキーマ | 項目構成を変更 |
| APIキー | 発行・権限変更 |
| メンバー | 招待・削除 |
| Webhook | 連携先変更 |
編集者にスキーマ変更やAPIキー管理は不要な場合が多いです。
部門・店舗・コンテンツタイプごとに制限できるか確認します。
契約プランによって細かな権限機能が異なるため、無料・低価格プランだけで比較しません。
7. 承認ワークフロー
Section titled “7. 承認ワークフロー”実際の組織フローを書き出します。
flowchart LR
A[担当者が作成] --> B[部門確認]
B --> C[広報・法務確認]
C --> D[公開承認]
D --> E[予約・即時公開]
確認事項：
- 承認段階数
- 並列・順番
- 差し戻し
- コメント
- 通知
- 承認期限
- 代理承認
- 緊急公開
- 修正公開
- 公開取消
- 監査記録
CMS標準機能で足りない場合、Backlog、Slack、メール等を併用することがあります。
二重管理で漏れが起きないよう、どこを正式な進行状態とするか決めます。
8. 公開日時と予約
Section titled “8. 公開日時と予約”- 公開開始
- 公開終了
- タイムゾーン
- 日付だけか時刻までか
- 予約変更
- 公開後の差替え
- 一覧の並び順
- 未来記事のAPI取得
- 期限切れ後のURL
- キャッシュ更新
予約公開がCMS内で成功しても、静的サイトのビルドが起動しなければWebサイトは更新されません。
CMSと公開基盤を通した確認が必要です。
9. プレビュー
Section titled “9. プレビュー”プレビュー要件を具体化します。
- 一覧・詳細のどちらか
- 下書き・予約記事
- 関連データ
- 多言語
- デスクトップ・モバイル
- OGP
- ログイン
- 検索結果
- 期間限定URL
- 共有範囲
- 本番データとの組み合わせ
- プレビューURLの失効
ヘッドレスCMSでは、下書きを取得するAPIキー・識別子がURLへ露出しないよう設計します。
プレビューURLが検索エンジンへ登録されないよう、認証等を使います。
10. 開発・検証・本番環境
Section titled “10. 開発・検証・本番環境”CMSのスキーマ変更は、フロントエンドを壊す可能性があります。
本番環境で直接項目を削除・型変更しないよう、環境分離を検討します。
flowchart LR
DEV[開発CMS] --> DEVF[開発フロント]
STG[検証CMS] --> STGF[ステージング]
PROD[本番CMS] --> PRODF[本番サイト]
確認事項：
- CMS環境を複製できるか
- スキーマ差分を管理できるか
- 本番データをコピーしてよいか
- APIキーを分けるか
- Webhook誤発火を防げるか
- 設定をコード管理できるか
- 変更手順・承認
環境機能が有料プランの場合、費用を見積に含めます。
11. Webhookと公開連携
Section titled “11. Webhookと公開連携”Webhookは、CMSの公開・更新・削除を別システムへ通知します。
利用例：
- サイトをビルド
- 特定ページを再生成
- 検索インデックスを更新
- Slackへ通知
- キャッシュを削除
- 外部DBへ同期
- どの操作で発火するか
- 下書きでも発火するか
- 内容変更・削除・公開終了
- 通知先認証
- 失敗時の再送
- 重複
- 順序
- ログ
- 手動再実行
- 複数環境の誤接続
「Webhookを設定した」だけではなく、受信側が失敗した場合を設計します。
12. 検索連携
Section titled “12. 検索連携”外部検索を使う場合、CMSと検索インデックスの整合を保ちます。
flowchart LR
C[CMS公開] --> W[Webhook]
W --> I[検索インデックス更新]
I --> S[サイト内検索]
- 新規公開
- 修正
- 非公開
- 削除
- カテゴリ変更
- URL変更
- 全件再構築
- 失敗・再送
- 反映時間
を決めます。
CMSは更新済みでも検索結果が古い、という状態が起こり得ます。
13. 移行
Section titled “13. 移行”- 現行データを取得
- 新モデルへ変換
- 画像・PDFを移行
- テスト投入
- 目視・自動検証
- 初回本番投入
- 差分更新
- 公開直前の更新停止
- 最終差分
- 公開後確認
確認する品質
Section titled “確認する品質”- 件数
- タイトル・本文
- 公開日・更新日
- カテゴリ
- リンク
- 画像・PDF
- 文字化け
- HTML構造
- 代替テキスト
- URL
- 公開状態
- 多言語
- 関連データ
移行後に現行CMSをいつ停止し、どこを正本とするか決めます。
14. バックアップと復元
Section titled “14. バックアップと復元”「CMS事業者がバックアップしている」という説明だけでは不十分です。
確認事項：
- コンテンツが対象か
- メディアが対象か
- スキーマ・設定が対象か
- 保持期間
- 復元単位
- 任意時点へ戻せるか
- 利用者側で復元できるか
- 依頼費用・時間
- 誤削除からの復旧
- 契約終了後
- フロントエンド・検索は別途必要か
APIで定期エクスポートを取る場合、秘密情報、保存場所、復元手順を管理します。
バックアップは、復元できることを確認して初めて有効です。
15. ベンダーロックインと終了時対応
Section titled “15. ベンダーロックインと終了時対応”CMSを変更するときに必要なものを確認します。
- コンテンツの全件出力
- 画像・PDFの原本
- コンテンツID
- 関係性
- 公開状態
- 履歴
- 利用者
- スキーマ
- Webhook
- API仕様
- 独自フィールド
- リッチテキスト形式
- 画像URLの継続性
独自のブロックやリッチテキスト形式を多用すると、移行変換が増えます。
ロックインを完全になくすことより、得られる価値と退出コストを理解して採用します。
CMS比較表の作り方
Section titled “CMS比較表の作り方”製品の機能有無だけではなく、案件での重要度と代替方法を記載します。
| 要件 | 重要度 | 製品A | 製品B | 代替・注意 |
|---|---|---|---|---|
| 承認2段階 | 高 | 標準 | 上位プラン | 外部運用は漏れに注意 |
| プレビュー | 高 | 要実装 | 標準連携 | 対象ページを確認 |
| 多言語 | 中 | 言語別項目 | ロケール | 未翻訳時を設計 |
| 環境分離 | 高 | 上位プラン | 標準 | スキーマ変更に必要 |
| 全件出力 | 高 | API | エクスポート | メディア・関係性確認 |
| Webhook | 高 | あり | あり | 再送・ログ確認 |
「○」「×」だけでは、実際の運用可否を判断できません。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”ニュース・コラム・プレスリリース
Section titled “ニュース・コラム・プレスリリース”似ていても、承認、公開日時、PDF、カテゴリ、一覧表示、訂正表示等が異なることがあります。
一つのモデルにまとめるか、別モデルにするかを、運用と表示から判断します。
多言語水族館サイト
Section titled “多言語水族館サイト”生き物、イベント、ニュース、営業案内等で翻訳単位・公開時期が異なります。
日本語更新時の翻訳通知、未翻訳表示、固有名詞、画像内文字、外部自動翻訳との責任分界を設計します。
住宅展示場サイト
Section titled “住宅展示場サイト”展示場、モデルハウス、メーカー、イベント、設備等の関係を構造化します。
住所・施設名を本文に重複入力せず参照関係を使うと、検索・SEO・予約・CRM連携へ利用しやすくなります。
PMチェックリスト
Section titled “PMチェックリスト”- CMS製品選定前に業務とコンテンツを棚卸ししている
- CMS化範囲と更新者・頻度を明確にしている
- コンテンツタイプ・項目・参照関係を図示している
- 項目ごとの用途、必須、型、多言語を定義している
- 画像・PDFの権利、代替テキスト、削除影響を決めている
- 操作単位の権限を定義している
- 実際の承認フローとCMS機能を照合している
- 予約公開とサイト反映の両方を確認している
- プレビュー対象と共有・認証を定義している
- 開発・検証・本番の環境分離を確認している
- Webhookの失敗・再送・手動復旧を決めている
- 検索インデックスの更新経路を設計している
- 移行件数・変換・差分・品質確認を計画している
- バックアップ対象と復元手順を確認している
- 契約終了時の全データ出力を確認している
- プラン料金と将来の利用者・コンテンツ増加を試算している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「画面デザインが完成してからCMS項目を決めればよい」
Section titled “「画面デザインが完成してからCMS項目を決めればよい」”コンテンツモデルは一覧、検索、関連、多言語、移行へ影響します。情報設計・デザインと並行して決めます。
「編集者の自由度は高いほどよい」
Section titled “「編集者の自由度は高いほどよい」”自由度が高いほど、品質のばらつき、崩れ、教育、テストが増えます。必要な範囲だけ提供します。
「権限は管理者と編集者の二つで十分」
Section titled “「権限は管理者と編集者の二つで十分」”部門・店舗・公開・スキーマ・APIキー等の権限を分ける必要がある案件があります。
「予約公開機能があれば静的サイトも自動で更新される」
Section titled “「予約公開機能があれば静的サイトも自動で更新される」”CMSの公開予約と、ビルド・デプロイの起動を連携する必要があります。
「バックアップがあるので誤削除しても安心」
Section titled “「バックアップがあるので誤削除しても安心」”保持期間、対象、復元単位、依頼時間が要件に合わない場合があります。復元試験が必要です。
理解度チェック
Section titled “理解度チェック”Q1. コンテンツモデルを画面単位だけで作る問題は何ですか。
Section titled “Q1. コンテンツモデルを画面単位だけで作る問題は何ですか。”回答と解説
レイアウト変更や別チャネル利用で再利用しにくくなります。施設、イベント等の意味ある情報単位を基本にします。Q2. CMSの権限要件を「編集者・管理者」だけで決めてはいけない理由は何ですか。
Section titled “Q2. CMSの権限要件を「編集者・管理者」だけで決めてはいけない理由は何ですか。”回答と解説
公開、削除、スキーマ変更、APIキー、部門別編集等、操作ごとのリスクが異なるためです。Q3. ヘッドレスCMSのプレビューURLで注意することは何ですか。
Section titled “Q3. ヘッドレスCMSのプレビューURLで注意することは何ですか。”回答と解説
下書き用秘密情報を露出しない、認証・期限を設ける、検索登録を防ぐ、本番データとの混在やキャッシュを制御することです。Q4. CMS移行で初回一括投入だけでは不十分な理由は何ですか。
Section titled “Q4. CMS移行で初回一括投入だけでは不十分な理由は何ですか。”回答と解説
移行準備中にも現行CMSが更新されるため、公開前の差分移行、更新停止、最終確認が必要です。Q5. ベンダーロックインを評価するとき、何を確認しますか。
Section titled “Q5. ベンダーロックインを評価するとき、何を確認しますか。”回答と解説
全コンテンツ、メディア、関係性、スキーマ、履歴等の出力可否と、独自形式を別CMSへ変換する費用を確認します。- Contentful「Content modeling basics」
https://www.contentful.com/help/content-models/content-modelling-basics/
コンテンツタイプと項目を、開発者と編集者の両方で反復設計する考え方。 - Contentful「Data model」
https://contentful.com/developers/docs/concepts/data-model
コンテンツタイプ、エントリ、メディア、多言語設定等の構造を確認する公式資料。 - microCMS Documentation「ロール」
https://document.microcms.io/manual/roles
管理画面操作、コンテンツ、APIキー等の権限を分ける具体例。 - microCMS Documentation「複数環境」
https://document.microcms.io/en/manual/environments
本番へ影響せず設定変更を検証する環境分離の具体例。 - microCMS Documentation「API Preview」
https://document.microcms.io/en/manual/api-preview