オウンドメディアのCMSはどう選ぶ？｜移行で後悔しない判断

公開から半年、記事が40本を超えたあたりで更新のペースが落ちてくる。カテゴリを整理したいのに管理画面にその項目がない、過去記事に内部リンクを1本足すだけで制作会社への依頼と見積もりが必要になる、公開の手順が担当者の手元のメモにしかない——オウンドメディアのCMSへの不満は、立ち上げ直後ではなく記事がある程度たまってから、運用側から出てきます。この段階で必要なのは、機能一覧のより多い製品に乗り換えることではありません。これから3年どう運用するのかを先に言葉にし、その運用に耐える仕組みを選び直すことです。本記事では、CMSの型の違いを整理したうえで、要件の棚卸し→型の比較→候補の評価→移行計画という順序で選定を進める手順を解説します。編集のしやすさ、SEO要件、保守の責任範囲、5年でかかる総コスト、既存サイトへ相乗りする判断、そして移行の実務までを、公開されている価格帯や統計とあわせて具体的に見ていきます。

記事が増えてから、CMSの不満は運用側に出る

CMSへの不満は、サイトを立ち上げた直後には出てきません。テンプレートが用意され、最初の数本を公開しているうちは、どの製品でも大きな差を感じないからです。問題が姿を見せるのは、記事が数十本たまり、カテゴリの整理やタイトルの一括変更、関連記事の出し方といった運用の都合が発生してからです。このとき初めて、選んだCMSが自社の運用に合っているかどうかが試されます。

現場から出てくる訴えは、どの会社でも似た形をとります。カテゴリを増やしたいのに管理画面に項目がない。過去記事に内部リンクを1本足すだけで依頼票と見積もりが必要になる。公開手順が特定の担当者しか知らず、他の人が代われない。下書きの見た目を関係者に共有する方法がなく、確認がスクリーンショットの往復になる。いずれも機能不足ではなく、運用の詰まりとして現れる点が共通しています。

この詰まりを放置すると、記事本数の伸びが止まります。1本の公開に社外との往復が2回入るだけでリードタイムは週単位に伸び、改善のサイクルは月1回しか回らなくなります。CMSの選定は、更新の速さを買い直す作業だと捉えると、判断の軸がぶれません。以降では、型の違いを押さえたうえで、要件の棚卸しから移行計画までを順に進めていきます。

ミニ用語解説：CMSの型を5つに分けて捉える

候補を比べる前に、CMSがどう分類されるのかを押さえておくと議論が早く進みます。法人サイトの選択肢になるのは、大きく5つの型です。用語が混ざったまま比較表を作ると、そもそも比べられないものを同じ列に並べてしまうため、最初に言葉をそろえておきます。

この5つは優劣ではなく前提の違いです。ヘッドレスCMSは表示速度とセキュリティの面で有利とされますが、画面側の開発が前提になるため、非エンジニアには見たまま編集ができず扱いにくいという弱点を抱えます。逆に従来型は編集のしやすさで勝る一方、本体や拡張機能の更新責任が自社に残ります。SaaS型は立ち上がりが最速でも、サービスが終了したときの移行難易度は高くなります。

自社が「どの型でも運用できる体制」を持っているのかは、選定の入口で確かめるべき点です。開発者が社内にいないのにヘッドレスを選ぶ、サーバーを触る権限がないのに自前運用の従来型を選ぶ——こうした体制と型のねじれが、移行後に運用が止まる最大の原因になります。型を選ぶのではなく、自社の体制で回る型に絞り込む、という順序で考えてください。

シェアの実態：WordPressが選択肢の中心にいる理由

型の話をすると必ず出るのが「結局WordPressでいいのか」という問いです。世界のシェアを見ると、W3Techsの集計（2026年7月27日時点）ではWordPressは全ウェブサイトの41.2%、CMSが判明しているサイトのうち59.1%で使われています。バージョン別では7系が52.3%、6系が40.4%という分布で、更新自体は比較的進んでいます。

一方、国内シェアについては調査ごとに母集団も集計方法も異なるため、特定の数値を断定できる公開資料は限られます。実務ではシェアの高さそのものより、その副産物のほうが効きます。制作会社が扱えること、記事納品の形式が揃うこと、拡張機能で不足を埋められること、担当者の採用や引き継ぎのときに経験者が見つかりやすいこと——シェアは機能ではなく、周辺の調達しやすさとして評価するのが実態に合います。

ただし、広く使われていることは攻撃対象になりやすいことと表裏です。同じW3Techsの集計では、WordPressサイトのうちElementorが31.5%、WooCommerceが19.8%で使われており、普及した拡張機能は脆弱性が見つかったときの影響範囲も大きくなります。シェアの高さを採用理由にするのなら、本体と拡張機能の更新を誰が持つのかを同時に決めておく必要があります。

手順1：要件を棚卸しし、5つの数字に落とす

選定の第一歩は、製品を見ることではなく自社の運用を数えることです。次の5つを数字か固有名詞で埋められれば、候補は自然に絞れます。埋まらない項目があるなら、それは仕様が決まっていないという意味なので、比較を始める前に社内で決めるべき論点です。

1. 月に何本公開するか（過去3か月の実績と、来期の目標本数）
2. 編集に関わるのは誰か（社内の編集者、外部ライター、監修者の人数と所属）
3. 公開の承認は誰が出すか（承認は何段階か、法務や広報のチェックが入るか）
4. 記事以外に何を出すか（導入事例、資料ダウンロード、セミナー告知、用語集など）
5. 3年後の規模はどうなるか（記事数、月間の閲覧数、多言語や別サイトの予定）

この5つのうち、選定を最も強く縛るのは公開本数と編集者の人数です。月2本を1人で出す運用と、月20本を外部ライター5人と回す運用では、必要な権限管理も承認フローも別物になります。前者ならSaaS型でも自社サイトへの相乗りでも足りますが、後者は下書きの受け渡しと差し戻しが管理画面の中で完結しないと破綻します。

あわせて、記事以外に何を出すかも先に決めておきます。記事とは違う型のページが増えるほど、テンプレートの数と権限の設計が重くなります。資料ダウンロードのフォームを持つなら入力データの保管先や連携先も要件に入り、セミナー告知を出すなら公開予約と期限切れ後の扱いが要件になります。棚卸しの結果は1枚にまとめ、候補選びの間ずっと参照できる状態にしておいてください。

評価の中心は「担当者が自分で公開できるか」

要件が揃ったら、次は編集のしやすさを見ます。ここが選定の中心になる理由は単純で、更新の速さがそのまま改善の速さになるからです。見出しの入れ替え、画像の差し替え、表の追加、内部リンクの追加——記事を良くする作業のほとんどは細かい編集です。1回あたり数分で終わる作業に社外との往復が挟まると、改善は事実上止まります。

確認するのは、画面の見た目より権限と承認フローです。ライターは下書きの投稿だけ、編集者は公開まで、外部の監修者はコメントのみ——といった単位で権限を分けられるか。差し戻しの状態を管理画面上で表せるか。公開予約ができるか。編集画面で完結しない作業は、必ず誰かの待ち時間になります。とくに承認が2段階以上ある組織では、この設計の有無で運用の重さが大きく変わります。

見落とされやすいのがプレビューです。下書きの実際の見た目を、社内の非編集者に共有できるかは日々の確認速度に直結します。共有用のURLが発行できず、確認がスクリーンショットの往復になっている現場は珍しくありません。あわせて、スマートフォン表示の確認、目次の自動生成、装飾のパターンが再現できるかも試しておくと、公開後の手戻りが減ります。

SEO要件のチェックポイント

編集のしやすさと並ぶ判断軸がSEO要件です。まずURL設計の自由度から確認します。記事のURLに日付やIDが強制されないか、カテゴリの階層をURLに含めるかを選べるか、後から一部だけ変更できるか。日本語のスラッグしか使えない、あるいはURLを一切変えられない仕様だと、後の整理で身動きが取れなくなります。

次にリダイレクトを自分で設定できるかです。URLが変わる場面では、旧URLから新URLへ301リダイレクトを設定して評価を引き継ぎます。ここで注意したいのは、クラウド型の一部では無料プランでリダイレクト機能が制限されること、そしてサービスによってはリダイレクト自体が用意されておらず、URL変更のたびに記事の手作業コピーが必要になることです。加えて、meta refreshやJavaScriptで転送する方式はステータスコード200を返すため、評価が引き継がれにくい点も押さえておく必要があります。管理画面から一括で対応表を取り込めるかどうかは、移行の工数を大きく左右します。

残りの要件は一度に確認できます。構造化データを記事・パンくず・よくある質問の単位で出せるか。サイトマップが自動生成され、更新時に反映されるか。noindexとcanonicalをページ単位で制御できるか。ページの表示速度が実測でどの程度か。多言語を将来使うなら、URLの持ち方と言語指定の出し方が決まっているか。これらは製品仕様で決まる部分が大きく、あとから足せない項目が混ざっています。デモの時点で実際の出力を見せてもらうのが確実です。

セキュリティと保守：責任の在りかを先に決める

運用が始まると、機能よりも保守が効いてきます。型ごとに責任の在りかが違うことを、契約前に文字にしておきましょう。オンプレミス型や自前サーバーの従来型は、サーバー管理・OSの更新・脆弱性対応を自社で行う必要があります。SaaS型はサーバー保守とセキュリティ対策を提供元に任せられますが、その代わり独自の改修には限界があります。ヘッドレスは管理画面と公開サイトが分離しているため、公開側への攻撃リスクは小さくなります。

従来型を選ぶ場合、最も現実的なリスクは拡張機能への依存です。広く使われている拡張機能は、脆弱性が公表されたときに狙われる件数も多くなります。導入する拡張機能を数え、それぞれの更新頻度と開発の継続性を見ておく。使っていない拡張機能は消す。拡張機能の棚卸しを四半期に1回の作業として運用に組み込むだけでも、事故の確率は下がります。

あわせて決めておくべきなのが、テスト環境とバックアップです。本体の更新を本番でいきなり当てるのか、複製環境で試してから当てるのか。バックアップは誰がどこに、どのくらいの頻度で取り、復元の手順を試したことがあるか。ここが空欄のままだと、更新を怖がって放置し、結果として古い状態で運用が続くという最悪の形になります。保守を委託するなら、更新作業と障害対応のどちらが契約に含まれるかを明記してもらってください。

費用の見え方：5年で並べると順位が変わる

費用は月額だけを見ると判断を誤ります。ある比較資料では、5年間の総額としてクラウド型が約100万〜600万円、オンプレミス型が約350万〜2,500万円、ヘッドレスCMSが600万〜3,000万円、ハイブリッド型が800万〜3,200万円、フルスクラッチの自社開発が8,000万円〜数億円という幅を示しています。初期費用の安さと5年の総額は、必ずしも同じ順序になりません。

実際の製品価格にも幅があります。国内のSaaS型では初期33,000円から月額11,000円台で始められるものから、月額49,800円〜99,800円の帯、クラウド版で初期20万円・月額10万円という水準まで並びます。買い切りのパッケージでは88万〜352万円という価格帯もあります。ヘッドレスCMSは無料プランを持つ製品が多く、上位プランで月額13万円前後から30万円台に達するものもあります。同じ型の中でも10倍以上の価格差があるため、型だけで予算を見積もらないことが大切です。

そして総コストで最も差が出るのは、月額でも初期費用でもなく都度の改修費と社内の人件費です。テンプレートを1か所直すのに見積もりと数日の待ちが発生する体制では、年間の改修費と待ち時間が積み上がります。逆に社内で触れる範囲が広ければ、月額が高くても総額は下がります。次の表の質問を、見積もりを受け取る前に投げておいてください。

費用の種類	見落としやすい点	契約前に投げる質問
初期費用	デザイン制作と移行作業が別見積もりになる	初期費用にデータ移行とリダイレクト設定は含まれるか
月額・ライセンス	利用者数や記事数、閲覧数で段階的に上がる	3年後の規模だとどのプランになるか
保守・サポート	更新作業と障害対応の範囲が曖昧なまま契約される	本体と拡張機能の更新は誰が行うか
都度の改修費	小さな変更ごとに見積もりと待ち時間が発生する	テンプレート1か所の変更でいくら・何日かかるか
社内の人件費	内製できない作業がそのまま待ち時間になる	記事1本の公開に何人が何分関わるか

手順2：型ごとの向き不向きを同じ表に並べる

要件と費用の見方が揃ったら、型を横に並べて比較します。ここで大事なのは、機能の数ではなく自社の体制で回るかを列にすることです。次の表は、BtoBのオウンドメディアという用途に絞って整理したものです。自社の棚卸し結果を照らし合わせ、消える型から落としていってください。

CMSの型	編集のしやすさ	SEO要件の自由度	必要な体制	BtoBメディアでの向き
従来型（WordPress等）	見たまま編集・拡張機能で補える	URL・リダイレクト・構造化データまで自由	更新と脆弱性対応を持つ担当か保守委託	記事中心で月数本以上を内製する場合の標準解
SaaS型	管理画面が整い教育コストが低い	設定できる範囲が製品仕様に依存	社内は編集のみ・保守は提供元	専任がいない・早く立ち上げたい場合
ヘッドレス	見たまま編集は弱く構造化入力が中心	画面側を自作するので制約が少ない	フロントエンドの開発者が必須	サイト以外にも配信する・速度を最優先する場合
静的サイトジェネレータ	公開前にビルド待ちが挟まる	出力を握れるため自由度は高い	ビルドと配信を設計できる人	更新頻度が低く堅牢さを重視する場合
自社サイトに相乗り	既存の編集画面と権限をそのまま使う	コーポレートサイトの仕様に縛られる	情報システム部門との調整	月数本まで・まず小さく試す場合

表を埋めると、たいてい2つの型が残ります。残った型の間で迷ったときの決め手は、3年後に増える作業がどちらで軽いかです。記事が3倍になったとき、編集者が2人増えたとき、別サイトを立てたとき——その未来で運用が重くなる側を落とす。今の快適さではなく、増えたときの伸びしろで選ぶほうが、選び直しの回数が減ります。

自社サイトのCMSに相乗りするという判断

見落とされやすい選択肢が、新しいCMSを入れずに既存のコーポレートサイトのCMSにメディアを載せることです。追加費用が小さく、管理が1つにまとまり、既存の権限と承認フローをそのまま使えます。すでに社内に運用の型があるなら、これが最も早く始められる道になることも珍しくありません。

一方で、相乗りには固有の制約があります。更新のたびに情報システム部門や制作会社の承認が必要になる、記事運用に必要な機能——カテゴリやタグ、関連記事、目次、著者情報——が用意されていない、コーポレートサイトのデザイン制約から記事らしい見た目にできない、といった詰まりです。相乗りの可否は、費用ではなく承認の速さと記事機能の有無で決まると考えると判断しやすくなります。

目安としては、月の公開本数が数本にとどまり、承認が1営業日以内に回り、記事に必要な機能が既存CMSに揃っているなら相乗りで十分です。逆に、月10本以上を出す、外部ライターが関わる、記事の型を増やしていく予定がある——このいずれかに当てはまるなら、はじめから記事運用向けの仕組みを別に用意したほうが結果的に安く済みます。なお、独自ドメインとサブドメイン、サブディレクトリのどれを選ぶかは相乗りの可否とは別の論点なので、ここでは切り離して考えてください。

手順3：候補を2〜3に絞り、実記事で試す

型が決まったら製品を2〜3に絞り、必ず自分の手で触ってから決めます。資料と機能一覧だけで契約すると、思っていた操作感と違うという後悔につながります。無料プランや無料トライアルを用意している製品は多く、たとえば14日間の試用を掲げるヘッドレスCMSもあります。試用期間は感想を集める場ではなく、決められた作業を通す場だと位置づけてください。

試すべきは、自社の実記事1本を最後まで入稿することです。すでに公開している記事のうち、装飾が多く画像も表も入っているものを選び、入稿から公開予約までを通します。このとき見るのは、画像の入れ方と代替テキストの設定、表の作りやすさ、内部リンクの貼りやすさ、目次の出方、装飾パターンの再現度、プレビューの共有方法、そして公開予約の挙動です。1本通すだけで、比較表では見えない詰まりがほぼ全部出てきます。

あわせて、出口の条件も試用期間に確認しておきます。記事データを本文・画像・メタ情報ごとに書き出せるか、その形式は何か、契約は月単位か年単位か、最低利用期間があるか。SaaS型はサービス終了時の移行難易度が高いと指摘される型なので、入口の使い勝手だけでなく、抜けられる条件まで見ておくと選定の失敗が致命傷になりません。複数人で触って、担当者以外にも扱えそうかを確かめておくのも忘れないでください。

CMS選定の要件チェックリスト

ここまでの判断軸を、そのまま社内で使えるチェックリストにまとめました。稟議に添える判断根拠としても使えますし、関係者それぞれに同じ項目で候補を採点してもらうと、感覚のズレが表面化して議論が具体的になります。

• 月の公開本数・編集者の人数・承認の段数を数字で書き出したか
• ライター・編集者・監修者の権限を分けられ、差し戻しが管理画面で完結するか
• 下書きのプレビューを、編集権限のない関係者に共有できるか
• URLを自社で設計でき、301リダイレクトを管理画面から一括で設定できるか
• 構造化データ・サイトマップ・noindex・canonicalを制御できるか
• 本体と拡張機能の更新、バックアップと復元の責任者が決まっているか
• 初期・月額・保守・都度改修・社内人件費を含めた5年総額で比較したか
• 記事データを本文・画像・メタ情報ごとに書き出せるか
• 自社の実記事1本を、入稿から公開予約まで実際に通して確かめたか

手順4：移行計画を立てる

製品が決まったら、移行の段取りに入ります。ここで守るべき原則は1つで、評価を落とさないためにURLを維持することです。移行した記事のURLは極力変えない。どうしても変わる場合は、旧URLから新URLへ301リダイレクトを漏れなく設定する。これを怠ると外部からのリンクも内部リンクも切れ、それまで積み上げた評価が引き継げなくなります。

実務は次の5段階で進めます。とくに新旧URLの対応表は移行作業の心臓部なので、制作会社に任せる場合でも自社で内容を確認してください。

移行計画でもう1つ大事なのが、CMSの入れ替えとデザインの刷新を同時にやらないことです。国内の解説でも、CMS導入と同時にサイトリニューアルを行うのではなく、移行を終えてからリニューアルに進むよう勧められています。同時に変えると、順位や流入が動いたときに原因を切り分けられなくなるからです。まず同じ見た目で器だけを載せ替え、安定を確認してから見た目に手を入れる——この順序が、移行を静かに終わらせるコツです。

移行でやりがちな失敗一覧

最後に、CMS移行の現場で実際に起きやすい失敗を挙げます。どれも作業の直前に確認すれば防げるものばかりですが、スケジュールが押した局面で省略されがちな項目でもあります。

• 新旧URLの対応表を作らずに移行し、リダイレクトの抜けを公開後に発見する
• リダイレクトをmeta refreshやJavaScriptで実装し、評価が引き継がれない状態にする
• CMSの入れ替えとデザイン刷新を同時に行い、指標が動いた原因を切り分けられなくなる
• 本文だけを移行し、画像の参照先や独自装飾が崩れたまま公開する
• canonicalや内部リンクに旧URLが残り、転送を経由し続ける導線になる
• テスト環境で検証せず本番で切り替え、旧サイトを先に停止してしまう

これらの多くは、公開前の点検を1人で抱えていることから生まれます。対応表の確認、装飾の再現確認、リダイレクトの検証は、作った人とは別の人が見るだけで発見率が上がります。移行の当日にまとめて確認するのではなく、段階ごとに区切って検収する進め方にしておいてください。

AIの使いどころと、任せてはいけないところ

CMS選定と移行は、生成AIを使える工程がはっきり分かれています。まず要件の言語化です。現行の不満を思いつくまま並べたメモを渡し、要件の文へ書き換えてもらう。「カテゴリが増やせない」を「記事カテゴリを管理画面から追加・並べ替えでき、URL構造に反映できること」といった検証可能な条件に変換する作業は、AIが得意な整理です。提供元へ投げる質問リストの下書きにも使えます。

次に移行データの整形とタグ付けです。書き出したデータの見出し構造を点検して階層の崩れを洗い出す、旧カテゴリから新カテゴリへの割り当て候補を作る、タイトルと本文からタグの候補を出す。そしてリダイレクト対応表の下書き点検——抜けている旧URL、重複、転送のループ、相対パスと絶対パスの混在といった機械的なミスを見つけるのに向いています。プロンプトの例を挙げます。

あなたはCMS移行を担当するWeb運用の実務者です。
添付は旧URLと新URLの対応表です（1行1組、タブ区切り）。
1. 転送先が空欄・重複している行を抽出してください。
2. 転送先がさらに別の行の転送元になっている多段リダイレクトを抽出してください。
3. 相対パスと絶対パスが混在している行、末尾スラッシュの有無が不統一な行を指摘してください。
4. 旧URL側にあって新URL側に対応がない行を一覧にしてください。
5. 推測でURLを補完しないでください。判断が必要な箇所は理由をつけて質問として返してください。

一方で、任せてはいけない領域もはっきりしています。製品の料金・機能・仕様は変わるため、AIの回答をそのまま比較表に転記しないこと。実際にリダイレクトが正しいステータスコードを返しているかは、AIの説明ではなく自分で確認すること。データベースの直接操作や本番環境への適用を任せないこと。AIは整理と点検の下ごしらえ、判断と検証は人という分担を守れば、選定と移行の工数は確実に軽くなります。

• 各製品の料金・機能・提供形態は変動するため、最終判断は必ず提供元の最新の公式情報で確認する
• 移行前に必ずバックアップを取り、旧サイトはリダイレクトの検証が済むまで停止しない
• AIに移行データやURLの対応表を渡すときは、顧客の個人情報や非公開の情報が混ざっていないかを先に確認する

まとめ

オウンドメディアのCMS選定は、機能一覧を比べる作業ではなく、これからの運用に耐える器を選び直す作業です。記事がたまってから出てくる不満の正体は運用の詰まりであり、月の公開本数・編集者の人数・承認の段数という数字に落とすところから始まります。型は従来型・SaaS型・ヘッドレス・静的サイトジェネレータ・ハイブリッドの5つ。体制と型がねじれていないかを最初に確かめ、編集画面と権限・承認フロー・プレビュー、URL設計とリダイレクトなどのSEO要件、保守の責任範囲、そして5年総額を同じ表に並べて比べます。既存サイトへの相乗りは、費用ではなく承認の速さと記事機能の有無で判断する。移行はURLの維持と新旧の対応表が本番で、CMSの入れ替えとデザイン刷新は分けて進める。選ぶべきは高機能なCMSではなく、自社が毎日触り続けられるCMSです。まずは過去3か月の公開本数と、1本を公開するまでに関わった人数を数えるところから始めてください。その2つの数字が、次に選ぶべき型をほとんど決めてくれます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。