AI搭載CMS比較｜担当1〜2名の中小企業が3タイプから選ぶ判断基準

結論：AI搭載CMSは製品名より「3タイプ×工程カバー範囲」で選ぶ

AI搭載CMSは、製品名を並べる前に「既存CMS＋AI型」「ヘッドレスCMS＋AI型」「運用基盤型」の3タイプに分け、自社が自動化したい工程をどこまでカバーするかで選びます。記事生成の可否だけで決めると、検索意図設計と効果測定が手作業で残り、公開後に伸び悩みます。

本記事では、3タイプの早見表、工程ごとのカバー範囲を可視化する独自枠組み「カバレッジ3層診断」、収益がどの経路で動くかの試算式、条件別のシナリオ、そして「こういう場合は別タイプが向く」という切り分けまでを扱います。特定製品の料金・機能値は掲載せず、確認手順のほうを示します（理由は後述します）。

この記事は誰向けか：Web担当1〜2名で自社サイトを回している中小企業

この記事が想定しているのは、従業員20〜100名規模の製造業・士業（会計事務所や法律事務所）・EC事業者などで、Webマーケティング担当が1〜2名（多くは営業企画や情報システムとの兼任）という体制です。役職としては、マーケティング担当者、経営企画のリーダー、あるいは社長直轄でWebを見ている実務者を想定しています。

この体制には共通した条件があります。サイトはWordPressで、制作会社に作ってもらったまま数年が経過している。記事を書く時間は月に数時間しか取れない。デザイナーもフロントエンドエンジニアも社内にいない。それでも「問い合わせを増やせ」と経営から言われている——この状況に心当たりがあるなら、以下の判断軸はそのまま自社に当てはめられます。

逆に、社内に開発チームがあり、Web・アプリ・サイネージへ同時配信する要件がある組織は、この記事の結論とは別の答えになります（後半の「別タイプが向く場合」で扱います）。

なぜAI搭載CMS選びは失敗するのか：起きがちな3つの判断ミス

ミス1：記事生成の性能だけを比較して、設計と測定が外に残る

兼任担当がまず見るのは「AIで記事が何本書けるか」です。その基準でプラグインを選び、月に8本公開できる体制になったとします。ところが3か月後、Search Consoleを開くと表示回数は増えているのにクリックされていない。原因は、キーワードごとの検索意図（比較したいのか、手順を知りたいのか、業者を探しているのか）を整理しないまま、タイトルと見出しをAIに任せたことにあります。記事を作る工程だけ速くしても、その前工程が空いていれば流入は変わりません。

ミス2：無料プランや個人プラグインで始め、公開作業が属人化する

初期費用を抑えるために複数のプラグインを組み合わせると、記事生成はA、SEO設定はB、内部リンクはC、計測タグはD、というように管理画面が分散します。担当者が退職・異動した瞬間、どのツールがどの工程を担っていたか誰も説明できなくなる。ツールの数ではなく、引き継ぎ資料が1枚で書けるかどうかが運用継続の分かれ目です。

ミス3：CMS移行を前提に検討を始め、判断が半年止まる

「ヘッドレスCMSが最新らしい」と聞いて移行前提で見積もりを取ると、フロントエンド開発費と移行工数が想定を超え、社内稟議が通らずに検討が止まります。数か月分の記事公開機会をそのまま失うことになる。移行が必要かどうかは、いま埋まっていない工程を特定してから判断すべき順序です。

AI搭載CMSの3タイプ早見表

タイプ	主な形	カバー範囲	前提となる社内体制	向いているチーム
既存CMS＋AI型	WordPress等にAIプラグインを追加	記事の下書き生成が中心（設計・測定は別ツール）	WordPress運用の知識がある担当が1名以上	既存サイトを活かしてAI執筆から始めたい
ヘッドレスCMS＋AI型	構造化コンテンツ＋API配信にAIを併用	コンテンツ管理と多面配信（表示側は自作）	フロントエンド開発ができる内製チーム	多サイト・多言語・アプリ同時配信
運用基盤型	既存CMSと併用し工程全体を担う	検索意図設計→作成→公開→分析→改善	兼任担当1〜2名でも可	少人数で集客の仕組みごと回したい

3タイプの違いは「どこまでの工程を引き受けるか」であり、機能の優劣ではありません。自社に空いている工程が1つだけならタイプ1で足り、全工程が空いているならタイプ3が合理的です。

判断ツール：工程の空きを可視化する「カバレッジ3層診断」

この記事独自の枠組みとして、コンテンツ運用を「①設計層」「②生成・公開層」「③測定・改善層」の3層に分け、各タイプがどの層を埋めるかを対応させます。これを「カバレッジ3層診断」と呼びます。使い方は単純で、自社で手作業のまま残っている工程に印を付け、その層を埋められるタイプを選ぶだけです。

ステップ1：3層×8工程のカバー範囲を照合する

層	工程	既存CMS＋AI型	ヘッドレスCMS＋AI型	運用基盤型
①設計層	キーワード選定・検索意図の言語化	別ツールで補う	別ツールで補う	基盤側で担う
①設計層	見出し構成・内部リンク方針の設計	一部を補助	別ツールで補う	基盤側で担う
②生成・公開層	本文の生成・推敲	得意領域	得意領域	基盤側で担う
②生成・公開層	カテゴリ・タグ・アイキャッチ付与と公開	手作業が残りやすい	API連携で自作	自動公開で担う
②生成・公開層	多サイト・多言語への同時配信	不得手	最も得意	単一サイト運用が前提
③測定・改善層	表示回数・流入・順位の把握	別ツールで補う	別ツールで補う	GA4／Search Console連携で担う
③測定・改善層	問い合わせまでの追跡	別ツールで補う	別ツールで補う	基盤側で追跡
③測定・改善層	記事内CTAの改善・リライト判断	手作業	手作業	A/Bテストとリライト提示

※上表はタイプごとの一般的な設計思想の整理であり、個別製品の仕様を保証するものではありません。導入検討時は各製品の公式サイトで、上記8工程それぞれについて対応可否を確認してください。

ステップ2：チェックリストで自社の空き層を特定する

チェック項目	当てはまる場合の示唆
狙うキーワードを決める担当が社内にいない／属人化している	①設計層が空いている
公開作業（画像・タグ・内部リンク）に1本あたり30分以上かかる	②生成・公開層が空いている
どの記事から問い合わせが来たか説明できない	③測定・改善層が空いている
リライトすべき記事を勘で選んでいる	③測定・改善層が空いている
表示側（フロントエンド）を開発できる人が社内にいない	ヘッドレス型は候補から外す
CMSを移行できる予算・期間が確保できていない	既存CMS併用型で検討する

ステップ3：空いた層の数で候補を絞る

空きが1層なら既存CMS＋AI型で埋める、2層以上が空いているなら運用基盤型を検討する、というのが判断の目安です。3層すべてが空いた状態でプラグインだけを追加しても、埋まるのは②の一部にとどまります。

タイプ1：既存CMS＋AI型は「執筆だけが詰まっている」場合に効く

WordPressのような既存CMSに、AIで記事を生成・補助するプラグインを追加するタイプです。いまのサイト構成とドメイン資産をそのまま使えるため、着手までの時間が最も短いのが利点です。一方で、検索意図設計・効果測定・CTA改善は別ツールで補う必要があり、プラグインが増えるほど管理画面と更新作業が分散します。設計と測定は自社でできていて、執筆工程だけがボトルネックになっているチームに向きます。

タイプ2：ヘッドレスCMS＋AI型は開発チームの有無で決まる

コンテンツをデータとして管理し、Webサイト・アプリ・店頭端末など複数の出力先へAPI経由で配信する構成に、AIを組み合わせるタイプです。構造化コンテンツと多面配信では最も強い一方、表示側の開発と保守を自社または外注で継続できることが前提になります。兼任担当1〜2名の体制では、記事1本の見た目を直すだけでも開発依頼が必要になり、更新速度が落ちる場合があります。

タイプ3：運用基盤型は「工程をまたぐ持ち替え」をなくす

記事を置く場所を提供するのではなく、何を書き、いつ出し、どこを直すかまでを一続きで扱うタイプです。CMSを置き換えるのではなく、既存のWordPressと併用しながら「検索から問い合わせが届く仕組み」の運用そのものを担います。担当が1〜2名の場合、工程ごとにツールを持ち替えないことが、3か月以上続けられるかどうかの分かれ目になります。

運用基盤としてのATKは3層のどこを埋めるか

ATKはCMSの置き換えではなく、検索から問い合わせ・売上を作る運用基盤です。既存のWordPressを残したまま、①設計層と③測定・改善層を同時に埋めることを狙っています。

• 日本語の検索意図設計（①設計層）：狙うキーワードと意図、必要な見出し・内部リンクを提案
• カクンダーZ品質評価（②生成層）：生成記事を5カテゴリ100点で採点し、基準未満は自動で修正
• WordPress自動公開（②公開層）：カテゴリ・タグ・アイキャッチ・内部リンク付与まで一括（内部リンク最適化の考え方）
• GA4／Search Console連携（③測定層）：表示回数・流入・問い合わせまで追跡し、リライト候補を提示（GA4とSearch Consoleの連携）
• CRO Copilot（③改善層）：記事内CTAの文言・配置をA/Bテストし問い合わせ率を改善（CRO Copilotの活用）

AIライティング側のタイプ比較はAIライティングツールの3タイプ比較、ツール全体の組み方はコンテンツマーケのツールスタックもあわせてご覧ください。

収益はどの経路で動くのか：2つの試算式に自社の数字を入れる

AI搭載CMSの投資判断は、「粗利の増加」と「工数削減額」の2経路で計算し、その合計と月額費用を突き合わせるのが妥当です。以下の式に自社の数字を入れて再計算してください。本記事に置く数値はすべて計算の形を示すための仮の値であり、実績値ではありません。

経路1：問い合わせ経由の月間粗利

変数	意味	自社の数値	仮の値（置き換えてください）
A	記事経由の月間検索流入数	____ 件	1,000
B	問い合わせ転換率	____ ％	1.0％
C	問い合わせからの成約率	____ ％	20％
D	平均受注単価	____ 円	500,000
E	粗利率	____ ％	40％

計算式は「月間粗利 ＝ A × B × C × D × E」です。仮の値で計算すると、1,000 × 1.0％ ＝ 10件の問い合わせ、10 × 20％ ＝ 2件の受注、2 × 500,000円 × 40％ ＝ 400,000円/月の粗利となります。ここで効くのは、③測定・改善層を埋めてBを動かせるかどうかです。仮にBが1.0％から1.5％になれば同じ流入のまま600,000円/月、差分は200,000円/月です（いずれも仮の値による計算例）。

経路2：工数削減額と回収期間

変数	意味	自社の数値	仮の値（置き換えてください）
F	1記事あたり削減できる工数	____ 時間	4
G	月間の公開本数	____ 本	8
H	担当者の人件費単価	____ 円/時	3,000
I	ツール等の月額費用合計	____ 円	____（各社見積もりを記入）

「月間工数削減額 ＝ F × G × H」で、仮の値では4 × 8 × 3,000 ＝ 96,000円/月です。投資回収の判断は「I ÷（経路1の粗利増加分 ＋ 経路2の削減額）＝ 回収に必要な月数」で行います。Iには各製品の見積もり額を自分で入れてください。本記事では特定製品の金額を記載しないため、この欄は空欄のまま提示しています。

注意点として、Aは記事公開から順位が付くまで時間差があるため、回収期間の分母には初月から満額を入れないでください。3〜6か月の立ち上がりを見込んだ保守的な計算にしておくと、稟議後の乖離が小さくなります。

用途別の向き不向きはこう分かれる

• 既存WordPressを活かしてAI執筆だけ足したい：既存CMS＋AI型、または運用基盤型（WordPress自動公開あり）
• 開発チームがあり多サイト・多言語を構造化配信したい：ヘッドレスCMS＋AI型
• 少人数で検索意図設計から問い合わせ追跡まで仕組み化したい：運用基盤型（ATK）

こういう場合は別タイプが向く

運用基盤型がすべてに最適というわけではありません。コンテンツを構造化データとして厳密に管理し、Web・アプリ・店頭サイネージなど多面的に配信したい、かつ表示側を内製できるチームがある場合は、ヘッドレスCMS＋AI型のほうが適しています。また、課題が「既存WordPressに執筆補助を足すだけ」に限定され、設計・公開・効果測定は既存の体制で完結しているなら、既存CMS＋AI型のプラグイン構成で十分なこともあります。カバレッジ3層診断で空きが1層だけなら、その層に対応する最小構成を選ぶのが合理的です。

自分の状況と照らせる3つの条件別シナリオ

シナリオA：製造業で技術記事は書けるが問い合わせが読めないパターン

技術部門が監修した記事を月2本公開でき、内容の質には自信がある。しかしどの記事から問い合わせが来たか説明できず、展示会と比べた費用対効果を経営に示せない——この状態なら空いているのは③測定・改善層です。記事生成ツールを買い増すより、GA4とSearch Consoleを問い合わせまでつなぐ工程を先に埋める順序になります。

シナリオB：士業で担当が実務と兼任、公開作業で止まるパターン

下書きはAIで作れるものの、見出し調整・内部リンク・アイキャッチ・カテゴリ設定に毎回時間を取られ、月末になると公開が滞る——このパターンでは②生成・公開層の後半が空いています。経路2の式（F × G × H）に自社の実測工数を入れると、投資判断の根拠が数字で出せます。

シナリオC：EC事業者で商品ページは多いが記事の狙いが定まらないパターン

商品ページは充実しているのに、比較・選び方といった検討段階のキーワードを誰も設計しておらず、記事が既存商品ページと共食いしている——この場合は①設計層が空いています。キーワードと内部リンクの方針を先に決めない限り、公開本数を増やしても流入は積み上がりません。

料金・機能はどう確かめるか（本記事が製品別の数値を載せない理由）

本記事は、特定製品の料金・機能スペックを数値で掲載していません。AI搭載CMSの価格体系は利用サイト数・生成回数・ユーザー数・契約年数で変動し、公開情報も改定が頻繁なため、記事内の数値をそのまま判断根拠にすると誤差が生じるためです。裏付けを取るときは、次の手順で一次情報に当たってください。

• 各製品の公式サイトの料金ページを開き、確認した日付をメモに残す（見積書やスクリーンショットを社内稟議に添付する）
• カバレッジ3層診断の8工程を一覧にして、対応可否を製品担当者に一問一答で確認する（「できます」ではなく「どの画面で何をすると実現するか」まで聞く）
• 問い合わせ計測が標準機能か、別途タグ設定やオプション費用が必要かを分けて確認する
• 解約条件・データエクスポート形式を契約前に確認する（記事データを持ち出せないと次の乗り換えで詰まります）

この4点を書面で揃えておけば、社内での比較検討が伝聞ではなく一次情報ベースになります。

よくある質問

Q. AI CMSを入れるならWordPressから乗り換えないとダメですか？

いいえ、乗り換えは必須ではありません。運用基盤型は既存のWordPressと併用する前提で、自動公開によって既存サイトへ記事を届けます。まずカバレッジ3層診断で空いている層を特定し、その層だけを埋められるかを確認してください。移行が必要になるのは、多サイト・多言語配信など構造そのものを変える要件がある場合です。

Q. AI搭載CMSの比較で最初に見るべきポイントは何ですか？

「記事が書けるか」ではなく「①設計・②生成公開・③測定改善のどの層まで担うか」です。本記事の8工程表をそのまま持って、各社に対応可否を確認するのが最短です。

Q. AIで記事を量産したのに問い合わせが増えないのはなぜですか？

多くの場合、①設計層と③測定・改善層が空いたままだからです。検索意図とずれたテーマを書き続けても流入は積み上がらず、どの記事が問い合わせに寄与したか測れなければ改善対象も選べません。生成本数ではなく、問い合わせ転換率（試算式のB）を動かせる工程が埋まっているかを確認してください。

Q. ヘッドレスCMSは社内にエンジニアがいなくても使えますか？

運用の主要部分で表示側の開発が前提になるため、内製エンジニアも継続的な外注予算もない場合は負荷が高くなります。記事の見た目を1か所直すのに開発依頼が必要になる体制で、月数本の更新を続けられるかを基準に判断してください。

Q. AI CMSの費用対効果はどう計算すればいいですか？

「流入数 × 問い合わせ転換率 × 成約率 × 平均受注単価 × 粗利率」で粗利増、「削減工数 × 月間本数 × 人件費単価」で工数削減額を出し、その合計で月額費用を割って回収月数を求めます。本記事の表の空欄に自社の数字を入れれば、そのまま稟議資料の根拠になります。

まとめ：3層のうち2層以上が空いているなら、まず現状把握から

AI搭載CMSの選定は、製品比較表を作る前に自社の空き工程を確定させる作業です。ここまでのチェックリストで「狙うキーワードを決める担当がいない」「どの記事から問い合わせが来たか説明できない」「リライト対象を勘で選んでいる」のうち1つでも当てはまるなら、埋めるべきは①設計層と③測定・改善層であり、記事生成ツールの買い増しでは解決しません。

無料診断では、現在の記事が検索意図をどこまで満たしているか、どのページで問い合わせを取りこぼしているか、カバレッジ3層診断のどの層が空いているかを確認できます。事前に、GA4とSearch Consoleの閲覧権限、直近3か月の問い合わせ件数、平均受注単価と成約率のメモを用意しておくと、本記事の試算式にそのまま数字を入れた状態で話を進められます。

｜