CMS はもう不要か — サイト運用を 5 層に分けて判断する

本記事のポイント

• CMS が不要になったかどうかは、サイト全体では決まりません。CMS が担う仕事は「入力画面」「表示制御」「公開・配信」「権限・承認・監査」「資産管理」の 5 層に分かれていて、生成 AI が置き換えたのはこのうち入力画面と表示制御の一部だけです。残りの 3 層は、CMS を外しても仕事そのものは消えず、担う道具が変わるだけです
• 判断は「CMS を入れるか、入れないか」ではなく「5 層のどれを何で満たすか」で決めます。本記事では 6 つの質問で自社を 3 類型 (CMS なし / 併用 / フル CMS) に振り分ける基準を示します
• 世界のウェブサイトのうち、すでに 30.4% は CMS を使わずに運用されています (W3Techs、2026-08 時点)。不要論は新しい主張ではなく、どちらの側にも実例があります

「AI でページが作れるなら、リニューアルで CMS は入れなくていいですよね」。サイトの作り直しを検討している担当者から、この半年でよく聞くようになった質問です。ところが自分で調べてみると「CMS はもう不要」と「大規模なら CMS は必須」が両方出てきて、判断できないまま止まってしまう。

原因は情報が足りないことではありません。

CMS という一語が 5 つの別々の仕事を指しているのに、判断が「入れるか、入れないか」の 2 択になっていることが原因です。

本記事では CMS を 5 層に分解し、AI が代替できた層とできない層を切り分けたうえで、自社がどこに着地すべきかを 6 つの質問で判定する手順を解説します。専門知識は必要ありません。判断の単位を分けるだけで、発注前に自分で決められるようになります。

1. 「CMS は不要」と「CMS は必須」が両方正しく見える理由

「読んだ記事によって結論が真逆で、どっちを信じればいいのか分からない」。相談の場でそのまま口に出されることが多い困りごとです。

この食い違いは、書き手が間違っているから起きているのではありません。論じている側が、それぞれ自社の主戦場から逆算した結論を書いているからです。

どちらの記事も、その会社の顧客層のなかでは正しいことを言っています。問題は、読者の自社がどちらの顧客層に属しているかを、記事のほうが教えてくれないことです。だから読むほど迷います。

数字で見ると、不要論はそもそも目新しい主張ではありません。W3Techs の調査では、世界のウェブサイトのうち何らかの CMS を使っているのは 69.6%、使っていないサイトは 30.4% です (2026-08 時点)。CMS を使うサイトの中では WordPress が 41.2% を占め、CMS 市場内では 59.1% になります。AI が登場する前から、3 割は CMS なしで動いていました。

humbulls の立場も先に開示しておきます。私たち humbulls は HubSpot のパートナーですが、CMS を販売してはいません。そして自社では、3 つのサイトを 3 通りの構成で運用しています。

同じ会社が、同じ時期に、3 通りの答えを選んでいます。サイトごとに満たすべき条件が違うからです。この記事はその判断の中身を分解したものです。

2. CMS を 5 層に分解する — AI が代替できたのは 1.5 層

「CMS って要するに、管理画面から記事を更新する仕組みですよね」。多くの担当者にとっての CMS 像はここで止まっています。そして不要論は、まさにこの像に対して立てられています。

実際には、CMS という 1 つの製品が引き受けている仕事は 5 つに分かれます。

生成 AI が本当に飲み込んだのは①です。文章を書き、HTML と CSS を組み、レスポンシブ対応まで済ませる。「HTML を書けない人のための入力欄」という CMS の出発点は、たしかに役目を終えつつあります。

②は半分です。1 ページのデザインを整えるところまでは AI でできます。ただし「新しい記事を足したら一覧ページとカテゴリページにも自動で並ぶ」「ヘッダーを直したら 100 ページすべてに反映される」という部分は、AI に毎回頼むのではなく仕組みで担保する話です。ここは実装の設計次第で、CMS でも静的サイトジェネレーターでも解けます。

問題は③④⑤です。

この 3 層は、CMS を外しても仕事が消えるのではなく、担う人が自社に移るだけです。

• ③ 公開・配信 — URL の一意性と過去の URL の行き先は、誰かが台帳として持ち続けることになる
• ④ 権限・承認・監査 — 「載せてよい」と決める権限は、社内にしか存在しない
• ⑤ 資産管理 — 画像とリンクの整合は、ページが増えるほど人どうしの取り決めになる

なかでも④は、AI の性能とは別の場所にあります。トップページに何を出すかは、アクセス数だけでなく営業方針や経営判断で決まるからです。この構造は AI が賢くなっても変わりません。

数え方を変えると、CMS の 5 層のうち AI が引き取れたのは 1.5 層です。不要論も必要論も、この 5 層のうち自分の見ている層だけを指して「CMS」と呼んでいます。噛み合わないのは当然でした。

3. 6 つの質問で自社の着地点を決める — CMS なし / 併用 / フル CMS

「うちは中小企業だから CMS なしで十分、でいいんでしょうか」。規模だけで決めようとすると、たいてい後から崩れます。判断すべきは規模ではなく、更新に関わる人の構造です。

次の 6 問に答えてください。「はい」の数ではなく、どの質問に「はい」が付いたかで決まります。

1. 公開ページ数は 50 を超えますか
2. 更新する人は 2 人以上いますか
3. 更新は月 1 回以上ありますか
4. 公開前に、書いた人以外の承認が要りますか
5. 掲載を決める人が部署をまたぎますか
6. 更新する人は、コードやファイルを直接触れますか

判定はこうなります。

[A] CMS なし (Git + 静的サイト)

1〜5 がすべて「いいえ」、かつ 6 が「はい」。更新する人が少数で、その人たちがファイルを触れる場合。制作は AI、公開は Git への反映で回ります

[B] 併用型 (CMS は配信と統制、制作は外)

1〜3 に「はい」があり、4・5 は「いいえ」。ページ数と更新頻度はあるが、承認が組織をまたがない場合。CMS を③④⑤の受け皿として残し、①②は外で持ちます

[C] フル CMS

4 か 5 が「はい」。承認が組織をまたぐ、あるいは掲載判断が部署間の調整を含む場合。この 1 問だけで [C] が確定します

4 と 5 は他の質問より重い、というのがこの判定の要点です。

ページ数が少なくても、広報と法務の承認を通さないと 1 行も直せない会社なら、承認フローを持つ仕組みが要ります。逆にページが 300 枚あっても、更新するのが 1 人でその人が自分で決めてよいなら、CMS がなくても運用は成立します。

図にすると次のようになります。

humbulls の 3 サイトを同じ 6 問にかけると、判定はこう分かれました。

数字は 2026-08-07 に各サイトの sitemap から実測したものです。humbulls.com だけが [B] になるのは、ページ数と更新頻度がある一方で、承認が組織をまたがないからです。もし将来、記事の公開前に外部の監修者チェックを挟むようになれば、同じサイトでも [C] に寄ります。判定は一度決めたら終わりではなく、体制が変わったときに引き直すものです。

よくある失敗は、この 6 問を「今」だけで答えてしまうことです。1 年後に更新担当が 3 人に増える計画があるなら、そのときの答えで判定してください。作り直しのコストは、最初に 1 段構えておくコストよりずっと高くつきます。

4. CMS が黙ってやっている仕事 — 外すと自分に返ってくる

「静的サイトにすれば、運用は軽くなると思っていました」。CMS を外して 1 年ほど経った会社から聞く言葉です。

原因は移行の失敗ではありません。

ページを作る手間ではなく、ページが増え続けたあとの整合性を保つ仕事が、そのまま社内に移ってくることが原因です。

CMS が管理画面の裏で黙ってやっている仕事を並べると、次のようになります。

このなかで見落とされやすいのがリダイレクトです。Google はサイト移転にあたって、リダイレクトをできるだけ長く、一般的には最低 1 年は維持するよう案内しています。恒久リダイレクト (301 / 308) をサーバー側で返すのが推奨で、リダイレクトの連鎖は 3 以下に抑えるべきとされています。

つまり URL は 1 本公開した瞬間に、1 年以上の管理義務が発生するということです。ページを作るコストは AI で下がりましたが、持ち続けるコストは 1 円も下がっていません。

よくある失敗は、「作れる人」で判断して「直せる人」で判断しないことです。

サイトを AI で作れる担当者が 1 人いれば、立ち上げは進みます。問題はその人が異動したあとです。ページが 200 枚あり、リダイレクト設定が数十本あり、画像の置き場所のルールがどこにも書かれていない状態を、次の担当者が引き継げるか。CMS の管理画面は、この引き継ぎのコストを下げるためにも存在しています。

5. 3 類型それぞれの運用の姿 — 誰が更新し、何が崩れるか

判定が出たら、次はその類型で実際にどう回るのかを見ておきます。3 つを同じ軸で並べます。

[A] を選ぶときに一番効くのは、費用ではなく「触れる人がいなくなったらどうするか」を先に決めておくことです。外部の制作会社に月数万円で更新枠を持ってもらう、という現実解もあります。

[B] の併用型は、CMS を①②の入力ツールとしてではなく、③④⑤の受け皿として使う設計です。humbulls.com がこれにあたります。

1. 原稿は手元のファイルで書く (AI と一緒に)
2. 検査スクリプトで表記や画像の参照先をチェックする
3. API で CMS に流し込む
4. 公開後、本番のページを実測して確認する

公開している記事は 70 本、サイト全体で 123 の URL を、この形で 1 人が回しています。管理画面で本文を書くことはほぼありません。

ただし、CMS から完全に逃げられるわけではないことも書いておきます。humbulls.com ではブログ一覧ページのテンプレートだけは API から編集できず、管理画面での操作が必須です。②の表示制御の一部は CMS 側に残ります。「全部を外に出す」ではなく「出せる層だけ出す」のが併用型の実像です。

[C] のフル CMS で誤解されやすいのは、費用の本体がライセンスだと思われている点です。実際に効いてくるのは運用設計と保守です。

WordPress を例にとると、2025 年に報告された新規脆弱性は 11,334 件で前年比 42% 増、そのうち プラグイン起因が 91% (10,294 件)、コア本体はわずか 6 件でした (Patchstack、2026-02 公開)。報告された脆弱性の 46% は、公開時点で修正が間に合っていません。

重さの正体は CMS 本体ではなく、後から積み増した拡張です。

[C] を選ぶなら、拡張を足す前に「この機能は本当に要るか」を通す関門を作る。ここが運用設計の中身です。

6. 発注前に決めること — RFP に「CMS 導入」と書かない

「制作会社に相談したら、見積もりが会社ごとに 3 倍違って比べられない」。リニューアルの相談でよく起きることです。

原因は各社の価格設定ではありません。

要件に「CMS を導入する」と書いた瞬間、5 層すべてが見積もりに入るからです。どの層まで作り込むかが各社の解釈に委ねられ、比較できない見積もりが並びます。

代わりに、層ごとに「この層は何で満たすか」を書きます。雛形は次の形です。

この 5 行があるだけで、提案の比較軸が揃います。④が「不要」と書いてあれば、承認ワークフローの構築費が見積もりから外れます。⑤を明記しておけば、画像がステージング環境を参照したまま公開される事故を仕様として防げます。

提案を評価するときは、次の 3 点を見てください。

1. 5 層のうちどれを CMS で、どれを別の手段で満たす提案になっているか — 全部を CMS で解く提案は、その理由が書かれているかを確認する
2. 更新担当が変わったときの引き継ぎ手順が書かれているか — 手順書の納品範囲が曖昧な提案は、後から必ず追加費用になる
3. リダイレクトの対応表を誰が作るか — 旧サイトの URL 棚卸しは発注側にしかできない作業で、ここが空欄の提案は移行後に検索流入を落とします

サイトを一度に全部作り直さず、段階的に公開していく進め方もあります。順序の組み方は サービスサイトの段階公開 — リード獲得と並走する 4 フェーズ設計 で扱っています。

7. よくある誤解

「AI で作れるようになったから、ページを持つコストが下がった」

下がったのは作る費用だけです。公開した URL には最低 1 年のリダイレクト管理義務が付き、画像の保管場所が必要になり、内部リンクの整合を保つ手間が発生します。

ページを増やすほど、この持ち分は積み上がります。作る費用と持ち続ける費用は、別の財布として見積もってください。

「AI で大量にページを作れば検索流入が増える」

Google はスパムポリシーで、検索順位の操作を主目的にしてユーザーの役に立たないページを大量生成する行為を「大量生成されたコンテンツの不正使用」として扱うと明記しています。生成 AI で多数のページを作り、価値を足さない例が挙げられています。

判断されるのは生成手段ではなく、そのページが読む人の役に立つかどうかです。AI で書くこと自体は違反ではありません。量を目的にした瞬間に線を越えます。

「ヘッドレス CMS を使えば CMS なしと同じ」

逆です。ヘッドレス CMS は①の入力画面と②の表示を切り離した構成で、④の権限管理も⑤の資産管理も CMS 側に残ります。

むしろ表示側を自前で作る必要があるぶん、実装の負担は増えます。「CMS を使わない」ことではなく「入力と表示を分ける」ことが目的の選択肢です。

8. よくある質問 (FAQ)

Q. AI があれば CMS は不要になりますか？

サイトによります。CMS が担う 5 層のうち、AI が代替できたのは入力画面と表示制御の一部です。公開・配信、権限・承認・監査、資産管理の 3 層は残ります。更新する人が少数でファイルを直接触れるなら CMS なしで運用できますが、公開前に他人の承認が要る組織では CMS 側の仕組みが必要になります。

Q. WordPress をやめて静的サイトにするべきですか？

更新体制で決まります。更新する人が 1〜2 人で、その人たちがファイルやコードを触れるなら、静的サイトへの移行は現実的です。逆に、管理画面から更新している人が複数いる場合、移行すると更新そのものが止まります。移行を決める前に、いま管理画面に入っている人が誰で、何を更新しているかを棚卸ししてください。

Q. ヘッドレス CMS は「CMS なし」と何が違いますか？

ヘッドレス CMS は CMS の一種です。入力画面 (ヘッド) と表示を切り離し、コンテンツを API 経由で取り出す構成を指します。権限管理や資産管理は CMS 側に残るため、5 層でいえば①③④⑤を CMS が担い、②を自前で作る形になります。「CMS を使わない」構成とは別物です。

Q. 更新頻度が低いサイトでも CMS は要りますか？

更新頻度だけでは決まりません。年に数回しか更新しなくても、更新のたびに広報と法務の承認を通す必要があるなら、承認の記録が残る仕組みは有効です。逆に、月に何度も更新していても担当者が 1 人で決裁できるなら、CMS なしで足ります。頻度より、更新に関わる人の数と承認の有無を先に見てください。

Q. 途中から CMS を入れる、または外すことはできますか？

できますが、URL 設計を変えると移行コストが跳ね上がります。Google は移転時のリダイレクトを最低 1 年維持するよう案内しており、対応表の作成と検証が必要になります。将来 CMS を入れる可能性があるなら、最初から URL 構造をシンプルに保ち、画像の保管場所を 1 か所に集約しておいてください。この 2 つを守っておくだけで、後からの移行はかなり楽になります。

まとめ — 「入れるか」ではなく「どの層を何で満たすか」

CMS が不要になったかどうかは、サイト単位では決まりません。CMS が担う仕事は入力画面・表示制御・公開配信・権限承認・資産管理の 5 層に分かれていて、生成 AI が引き取れたのはそのうち 1.5 層です。残りは CMS を外しても消えず、担う人が自社に移ります。

決めるべきは「CMS を入れるか、入れないか」ではありません。

5 層のどれを何で満たすかを、自社の更新体制から決めることです。

まずは第 3 章の 6 問に答えて、自社が [A] CMS なし / [B] 併用 / [C] フル CMS のどこにいるかを出してみてください。そのうえで第 6 章の 5 行を書き出せば、制作会社への相談の質が変わります。運用の実際については、次の 2 本も合わせてどうぞ。

• 記事の制作から公開までを 1 人で回す設計: オウンドメディアを 1 人 × AI で運用する — 編集部を再現する制作パイプライン
• CMS を含む HubSpot Starter の機能境界: HubSpot Starter の制限一覧 — 30 の壁と回避可否を全整理

サイトの構成をどう決めるか、リニューアルの要件をどう書くかで迷っている場合は、humbulls の Growth Partner サービス でご相談いただけます。

参考文献

• Usage statistics of content management systems — W3Techs (取得日: 2026-08)
• State of WordPress Security in 2026 — Patchstack & Monarx (2026-02 公開 / 取得日: 2026-08)
• URL の変更を伴うサイト移転 — Google 検索セントラル (取得日: 2026-08)
• スパムに関するポリシー — Google 検索セントラル (取得日: 2026-08)