CMS選定：失敗しない判断軸｜リニューアル前に決めること

CMSは記事を入力する画面だけではありません。公開の承認、誤更新からの復旧、画像の管理、外部サービスとの連携、将来の移行まで含めて選ぶと、導入後に誰が何を担うかが見えてきます。

最初に決めるのは、誰が、何を、どの手順で更新するかです。旧サイトの不便さを具体的な操作へ置き換えてから、候補を同じ課題で試します。制作全体の予算・目的から整理する場合は、Web制作完全ガイドを先に参照してください。

30秒で要点

• CMSと表示方式を別々に選ぶ。 WordPressかHeadlessか、静的か動的かは、同じ分類軸ではありません。
• 更新・保守・退出の3場面で確認する。 記事を書けるだけでなく、戻せることと移せることも試します。
• 方式名だけで安全性・速度・費用を順位付けしない。 実装、契約、担当範囲をそろえて比較します。
• 必須条件を点数で相殺しない。 承認が必要なのに実現できない候補は、見た目が良くても再検討します。

1. 最初の要件表は機能名より担当者を書く

表が収まらない場合は、横にスクロールできます

「多機能」「誰でも簡単」のような言葉は、操作に置き換えて確かめます。更新頻度が少なくても、法務の承認や複数言語の整合が必要なら、運用は単純とは限りません。一方、少数ページの修正に複雑な承認や独自開発が不要なら、編集と配信がまとまったサービスを試す価値があります。

2. 製品、編集機能、配信方法を分ける

CMSは内容を管理する仕組みです。Headlessは内容管理と表示を分離する構成で、静的生成は公開用のファイルをあらかじめ作る配信方法です。静的サイトジェネレーターやWebフレームワークを、そのまま編集画面付きCMSと考えないでください。

WordPressも、テーマで表示する構成に加え、REST APIから別アプリへ内容を渡せます。「WordPressは一体型だけ、Headlessなら別製品」という二択ではありません。WordPress REST API公式説明

表が収まらない場合は、横にスクロールできます

表示を分けるほど必ず遅い・速いということはありません。画像やJavaScript、キャッシュ、外部API、ページ構成で体感は変わります。Webパフォーマンスの確認手順を使い、CMS名ではなく実際のページと操作で確認します。

3. 主要候補は公式条件と自社の責任で比べる

以下は2026年10月7日に公式資料を再確認した、比較を始めるための表です。料金の見積もりや製品の優劣を示すものではありません。

表が収まらない場合は、横にスクロールできます

根拠は、WordPressの保守責任、Contentfulの出力と制約、Strapiの配備・データ出力、Sanityの構成・Dataset出力、Wixの外部ホスティング制約です。

WordPress.orgのソフトウェア、自分で契約するホスト、WordPress.comのようなサービスは、同じ契約条件ではありません。各候補で「CMS利用料に何が含まれるか」を別々に確認します。無料のソフトウェアでも、サーバー・保守・制作・教育・移行まで無料になるわけではありません。

4. 安全性と費用を一律に格付けしない

セキュリティはリスクを減らす取り組みです。WordPress公式も、ホストとサイト所有者の責任分担、アクセス制限、更新、バックアップなどを組み合わせて説明しています。CMS名やプラグイン数だけで「安全」と判定する根拠にはなりません。Hardening WordPress

候補ごとに、管理者の強い認証と利用可能な多要素認証、権限の範囲、更新担当、バックアップと復旧、ログの取得、障害連絡を確認します。Headlessや静的配信でも、編集用アカウントやビルド経路、公開API、外部フォームの管理は残ります。

費用は同じ期間・範囲で見積もります。確認表には少なくとも次を含めます。

• 初期：内容構造と画面の設計、移行、外部連携、担当者の教育。
• 継続：契約料、ホスティング、利用量の追加料金、保守と更新作業。
• 変更・終了：項目追加、権限や言語の追加、書き出し、別基盤への再実装。

計算方法だけを示す架空例では、24か月の対象費用を次のように比べられます。実在サービスの料金や当社見積もりではありません。同じ保守範囲・利用上限を想定し、税、社内工数、追加開発、移行終了費は別欄とします。

表が収まらない場合は、横にスクロールできます

式は「初期費用＋月額費用×24」です。Bの小計が2.4万円低くても、必須の承認機能が不足したり移行の追加作業があったりすれば、判断は変わります。「月額が安い」だけでは比較が終わりません。

5. 同じ記事で試用する7つの課題

候補ごとに、実務を代表する記事を一つ用意します。長い見出し、画像、関連リンク、公開日、必要なら多言語や表も含めます。機密を含まない検証用データを使い、実サービスの公開操作は権限と環境を確認してから行います。

1. 下書き：日常の編集権限で記事を作れるか。必須項目の抜けが分かるか。
2. プレビュー：未公開内容を関係者だけが確認できるか。表示側と差がないか。
3. 承認・差し戻し：編集者が意図せず公開できず、承認者の不在時も処理できるか。
4. 公開と取り消し：配信への反映、キャッシュ、予約日時、失敗時の通知を確認する。
5. 日常の変更：画像差し替え、代替テキスト、URL変更、リンク更新を行う。
6. 誤更新からの復旧：何をどの時点まで戻せるか。本文以外の画像や設定も対象か。
7. 書き出しと再表示：出力した内容を別の検証先で開き、参照関係を確かめる。

これは読者の試用課題です。本記事では各製品の管理画面操作、実際の公開・復元・クラウド移行を実施していません。試用できない項目は「合格」とせず、提供者への確認事項として残します。

選定会議では、必須条件と希望条件を分け、同じ課題の結果を共有します。提案資料の見栄えや肩書きで評価が変わる場合は、権威バイアスと会議のルールも参考になります。

6. 移行の出口は件数だけでは足りない

旧サイトから新サイトへ移すときは、記事、画像の実ファイル、記事同士の参照、公開URL、下書き、履歴、権限、外部連携を棚卸しします。出力機能があっても、すべてが同じ形で戻るとは限りません。

ContentfulのCLIでは、履歴や予約リリース・タスク・ワークフローは移行対象外です。Strapiの出力では管理ユーザーとAPIトークンを別に扱います。SanityのDataset出力は、取得時に401・403・404となったアセットを警告付きで飛ばして処理を続ける場合があります。「コマンドが終わった」と「必要なものがそろった」は別です。 Contentfulの制約、Strapiの除外項目、Sanityの警告

架空の小さな移行練習で、記事12件と画像20個を移したとします。記事12件がすべて見つかっても、画像の実ファイルが19個なら1個不足しています。さらに記事中の参照先と画像の内容を照合します。件数が同じでも、重複や別ファイルへの置換は起こり得るためです。

切り替え前には、旧URLと新URLの対応、必要なリダイレクト、検索向け設定、フォーム、計測、権限を確認します。更新停止の時間、最後の差分を移す人、切り戻す条件も決めます。旧環境を消す前に、復旧と引き渡しが成立することを確かめてください。

7. 状況別に次の候補を絞る

以下は選定を考える架空の状況であり、導入成果の事例ではありません。

表が収まらない場合は、横にスクロールできます

Wixを含む編集サービスを検討するなら、Wixが向いている人・向いていない人へ。自社運用を選ぶなら、WordPress保守ガイドで責任と復旧の準備を具体化できます。

選定結果に残す一枚

選んだ製品名に加えて、「採用理由」「満たした必須条件」「未確認事項」「更新・保守・移行の担当」「追加費用が出る条件」を残します。実装に入る前にここが共有されていれば、後から条件が変わったときも再判断できます。

制作の土台はWebサイト作成入門、画面の品質はレスポンシブデザインとデザインシステム、公開後の検索設定はテクニカルSEOへ進めます。要件表や引き渡し条件から整理したい場合は、First byteへのご相談をご利用ください。