CMS選定の考え方
オウンドメディアのCMS選定では、いきなり「WordPressにすべきか、Astroか、ヘッドレスか」と技術名で迷いがちです。しかし、CMSは目的ではなく運用設計を支える手段。社内に技術者がいなくても、「誰がどれくらいの頻度で更新するか」「外注を入れるか」「速度はどこまで必要か」という運用面の問いから入れば、必要な選択肢は自然に絞り込めます。
本記事は、技術者がいない前提でも判断できるように、WordPress・Astro・ヘッドレスCMSの3択を運用観点で比較し、迷ったときの実用的な判断軸を整理します。
CMS選定は、「更新頻度・内製外注比率・表示速度要件・セキュリティ要件・入稿運用・入稿スピード」の順に運用要件を整理してから、候補CMSを当てはめると失敗しません。多くの会社は、既存メディアはWordPress、新規の専門ドメインはAstro、複数フロントへの配信が必要な場合だけヘッドレスCMSという棲み分けが現実的です。技術選定そのものはTantouに丸投げできるので、社内では「読者と運用体制」だけ決めれば十分です。
「PHP」「ヘッドレス」「ビルド」「Islands」などの単語に困っても、CMS選定はできます。Tantou では、社内の運用要件（誰がいつ更新する／何を優先したい）をヒアリングし、CMS選定・構築・運用代行までを丸ごと請け負う体制を提供しています。技術判断はTantouに任せ、社内では「読者は誰か」「どんな価値を届けるか」だけを決めれば、メディアが立ち上がります。
01.結論：CMS選定は『運用要件 → 候補』の順で考える
トレンドベースで候補CMSを並べて比較すると、自社の運用要件が後付けになりがちです。最初に運用要件を整理し、それを満たすCMSはどれかを後から決める順序にすると、選定ミスを大きく減らせます。
| 順序 | やること | 目的 |
|---|---|---|
| 1. 運用要件の整理 | 更新頻度・内製外注比率・編集者数・公開フロー | 候補CMSの絞り込み基準を作る |
| 2. 非機能要件の整理 | 表示速度・セキュリティ・可用性・SLA | 技術選定の制約を明確にする |
| 3. 接続要件の整理 | 代行・SSO・分析・MA／CRMとの連携 | 実運用での負荷を見積もる |
| 4. 候補CMSとの突き合わせ | WordPress／Astro／ヘッドレスを当てる | 「やりたいことが満たせるか」を判定 |
| 5. 既存／新規の判断 | 移行コストと改善余地を見比べる | 切り替えタイミングを決める |
02.選定で見るべき7つの判断軸
更新頻度と内製/外注比率
非エンジニアの編集者が管理画面で記事を入稿し、外部ライター・編集者・代行も加えていく運用なら、入稿UIが整っているWordPressや、Notion／Studio型のヘッドレスCMSが向いています。一方、生成AI（ChatGPT・Claude・Geminiなど）の出力をそのままMarkdownファイルとしてGitにコミットしたい、スクリプトで複数記事を一括入稿したい—といったワークフローなら、Astro＋Gitが構造的に速くなります（詳細：§08 入稿スピード）。実際、弊社のTANTOUもAstro構成を推奨しており、表示速度・入稿スピードの両面で構造的に有利です。
表示速度とセキュリティ
表示速度を最優先するならAstroなどの静的サイト生成が有利です。WordPressでもキャッシュとCDN、画像最適化、テーマ刷新で大幅改善できますが、プラグイン依存のリスクは残ります。セキュリティ面では、プラグイン管理体制の有無がWordPress採用可否を決める分水嶺になります。
Page ExperienceとCore Web Vitals｜表示速度の評価指標
LCP・INP・CLSなど、CMS選定で必ず影響する表示速度の基準を整理しています。
入稿運用と編集UIの完成度
サイト作成後に非エンジニアの編集チームが管理画面で記事を入稿していくスタイルなら、WordPress一択に近い状況です。管理画面の入稿UIが完成度高く、ライター・編集者の増員にも耐えやすく、運用ナレッジも厚く溜まっています。入稿フローを完全にカスタマイズしたい、または既存の業務システムと統合したい場合は、microCMS・Strapi・Contentful などのヘッドレスCMSも選択肢になりますが、入稿者側の学習コストと管理画面の作り込みコストはWordPressより上がります。なお、生成AIの出力をそのまま記事化していくコードベース型ワークフロー（Astro＋Git＋Markdown）は管理画面を持ちませんが、入稿スピードでは別軸の強さがあります（§08 で詳説）。
03.WordPressの強みと弱み
| 観点 | 強み | 弱み |
|---|---|---|
| 更新性 | 管理画面で直感的に編集可 | 編集者が増えると権限管理が煩雑 |
| 機能拡張 | プラグインで広範に対応 | プラグイン過多で速度・セキュリティ低下 |
| 代行親和性 | 対応できる代行が圧倒的多数 | — |
| 表示速度 | キャッシュ・CDN・画像最適化で改善可能 | ベース速度はAstroに劣る |
| セキュリティ | WAF・自動更新でカバー可能 | プラグイン脆弱性が攻撃面 |
04.Astroなど静的サイトの強みと弱み
Astro は、ページを事前にHTMLとして書き出しておき、動きが必要な部分にだけJavaScriptを後から読み込ませる「Islands Architecture」を採用した、静的サイト生成ツール（あらかじめ全ページをファイルとして書き出して配信する仕組み）です。表示速度・セキュリティ・保守性、そしてAI連携での入稿スピードに構造的な強みがある一方、非エンジニアが管理画面で入稿する体制には別途設計が必要です。
| 観点 | 強み | 弱み |
|---|---|---|
| 表示速度 | 事前にHTMLを書き出しておくため、表示速度の指標（LCP・INP）が構造的に速い | — |
| セキュリティ | 攻撃面が狭く、管理画面を持たない | — |
| 保守性 | 依存（package.json）が明示的で見通し良好 | — |
| 更新性 | Markdownで書けてGit管理可能、AI出力をそのまま入稿できる | 管理画面を別途用意する必要 |
| 代行親和性 | — | 対応経験のある代行が限られる |
| 拡張性 | ReactなどUIフレームを部分採用できる | プラグインエコシステムは未成熟 |
| AI／構造化対応 | 構造化データ・llms.txt をビルド時に明示的に出力可 | — |
| スケール時コスト | CDN中心で低コスト | — |
編集者が少数で、ブランド／コーポレート／専門メディアを最高速・最小攻撃面で配信したい場合はAstroの構造的優位が活きます。本サイトもAstro系の構成思想で構築しており、Core Web Vitalsとセキュリティの両立が容易です。
05.ヘッドレスCMSの位置づけ
ヘッドレスCMS（microCMS、Contentful、Sanity、Strapi、Newt など）は、コンテンツの管理だけを担い、表示はフロントエンドに任せる構成です。複数フロント（Web／アプリ／別ドメイン）に同じコンテンツを配信する運用や、開発と編集を完全に分業したい組織で本領を発揮します。
ヘッドレスCMSは設計と運用の自由度が高い反面、フロントエンド開発・SEO要件の手当て・SSO／権限管理など、自前で組む範囲が広くなります。単一のWebメディア運用が目的なら、WordPressやAstroのほうが立ち上がりは速いです。
既存WordPressメディアの運用改善｜引き継ぎ時に見るべき構造・速度・品質
WordPressのまま整える場合の優先順位と診断項目を整理しています。
06.CMS 横並び比較マトリクス
ここまでの個別解説を 1 つの表に圧縮します。7 観点で 4 系統（WordPress / Astro / ヘッドレス / SaaS 系オールインワン）を◎/○/△/× で評価します。社内の意思決定資料にそのまま添付できる粒度に揃えています。
| 観点 | WordPress | Astro (静的) | ヘッドレス CMS | Wix / STUDIO / Webflow |
|---|---|---|---|---|
| 記事公開速度（編集者） | ◎ ブロック編集に慣れている | ○ Markdown / MDX 編集 | ○ 編集 UI は CMS 側で快適 | ◎ WYSIWYG が速い |
| 初期構築コスト | ○ テーマ流用で速い | △ 開発工数が必要 | △ フロント開発が必要 | ◎ ノーコードで完結 |
| 長期運用コスト（保守 / 脆弱性） | △ 本体・プラグイン更新が必須 | ◎ 静的なので脆弱性少 | ○ ヘッドレス側は SaaS 任せ | ◎ SaaS 任せ |
| 表示速度 (Core Web Vitals) | △ チューニング必須 | ◎ ビルド済み静的が速い | ○ SSG / ISR 設計次第 | ○ プラットフォーム次第 |
| SEO / 構造化データ自由度 | ◎ プラグイン豊富 | ◎ コードで自由 | ○ フロント実装次第 | △ 制約がある |
| AI 検索向け構造化 (llms.txt / sitemap / 著者) | ◎ プラグインで対応可 | ◎ コードで対応 | ○ フロント次第 | △ プラットフォーム制約 |
| 拡張性 / 外部連携 (CRM / GA4 / 翻訳) | ◎ プラグインで対応 | ◎ フロントの自由度 | ◎ API 中心 | ○ 連携先制限あり |
観点ごとの優先順位（例：表示速度 + 拡張性 を最重視）を先に決め、それを満たす系統を 1 つに絞ります。「全部やりたい」と全観点で◎を求めると、結局 WordPress + 手厚いプラグインに戻るのがあるあるパターンです。
5 分で判定できる選定フローチャート
個別事情があっても、最初のあたりを付けるためのフローです。
| 質問 | Yes なら | No なら |
|---|---|---|
| 既に WP メディアを運用しているか？ | 現行 WP で整える | 次へ |
| 50 本以上の既存記事の移行が必要か？ | 現行 WP のまま改修 | 次へ |
| 編集者が非エンジニアで、毎日触る人が複数？ | WP / SaaS オールインワン | 次へ |
| 複数ドメイン / アプリにも同じ記事を出す？ | ヘッドレス CMS | 次へ |
| 表示速度・SEO 自由度を最大化したい？ | Astro（静的） | WP に戻る |
07.既存活用と新規構築の判断
| 状況 | 推奨方針 |
|---|---|
| 既存WordPressに50本以上の記事がある | WordPressのまま構造・速度・品質を整える |
| 既存メディアが古いHTMLで管理コスト過大 | AstroなどでリプレースしつつWordPressから移行 |
| 新規の専門メディアを立ち上げたい | Astroで構築、Web速度とSEOを最優先 |
| 複数ドメインで同じ情報を出したい | ヘッドレスCMSを採用し、フロントを分割 |
| 既存メディア＋新規メディアを並行運用 | 既存はWordPress、新規はAstroの使い分け |
08.AI検索時代は「入稿スピード」で差がつく
構造化データ（FAQPage・Article・BreadcrumbList）、メタ情報、サイトマップ、llms.txt、Core Web Vitals──AI検索時代に必要と言われる項目は、WordPress・ヘッドレスCMS・Astro のいずれでも対応可能です。機能の有無で選んでも、CMS間で大きな差は出ません。
実際に差が出るのは 入稿スピードと、出せる記事の本数 です。AI検索（ChatGPT・Claude・Geminiなど）はトピックの網羅性と更新の鮮度を引用判断の根拠にしているため、同じ品質なら記事点数を早く積み増せる側が有利になります。
ここで効いてくるのが、「CMSの管理画面で入稿するより、ファイルを直接作った方が速い」という世界が来ているという点です。生成AI（ChatGPT・Claude・Gemini）が出力するのはテキストファイルそのものなので、Markdownファイルを書き出して Git にコミットすれば、それがそのまま公開記事になります。CMSに転記する一手間が消えます。
コードベース（Astro＋Git＋Markdown）が入稿スピードで圧倒的に有利な理由は次の3つです。
- 管理画面を開かずに、テキストエディタやAIツールから直接Markdownを書ける
- 複数記事の一括生成・一括修正をスクリプトやAIエージェントで処理できる
- Pull Requestの差分でレビューできるため、編集の往復回数が減る
弊社の TANTOU が Astro 構成を推奨しているのも、表示速度に加えて入稿スピードを最大化するためです。WordPressでも入稿テンプレやエディタ整備で改善できますが、ファイルを直接書き出す方式とは構造的な差が残ります。
ChatGPT による記事量産は SEO に有効か
AIで記事を量産するときに何が効いて何が効かないか、SEO 効果検証の観点で整理しています。
AI 出力の品質管理｜ハルシネーション対策とファクトチェックの基礎
入稿スピードを上げるなら、AI 出力の品質管理が前提になります。
09.次に読むとよい記事
WordPress運用でよくある10の課題と対策｜「作りっぱなし」で失敗しないためのチェックリスト
WordPress を選ぶ場合に必ず直面する 10 課題と対策、引き継ぎ移行で 10 課題が同時発覚した実例まで整理しています。
既存WordPressメディアの運用改善｜引き継ぎ時に見るべき構造・速度・記事品質・計測
既存 WordPress を整える初月診断と、サーバー移行を伴う場合の実行プレイブックを整理しています。
10.よくある質問（FAQ）
結局WordPressとAstroのどちらがいいですか？
目的次第です。既存メディアはWordPressのまま、新規の専門ドメインはAstroという使い分けが、多くのBtoB企業にとって実用的です。非エンジニアの編集チームが管理画面で更新する／プラグインで機能拡張したい／外部代行と連携する—ならWordPress、表示速度と入稿スピード（生成AIの出力をMarkdownでそのまま公開）を最大化するならAstroと整理できます。
ヘッドレスCMSはいつ選ぶべきですか？
Webサイトと別にスマホアプリや別ドメインのフロントエンドにも同じコンテンツを配信したい、開発チームがフロントエンドを内製している、編集者と開発者を完全に分業したい—といった要件があるときに本領を発揮します。BtoBオウンドメディア単体ではオーバースペックになることが多いです。
WordPressのセキュリティが心配です
WordPressコアとプラグインの自動更新、不要プラグイン削除、管理画面のIP制限、強固なパスワードと2段階認証、定期バックアップ、SSL、WAFを揃えれば十分実用的です。脆弱性のあるプラグインを放置するのが最大のリスクなので、四半期に一度プラグイン棚卸しを組み込むことをおすすめします。
CMSを切り替えるべきタイミングは？
(1) 表示速度の改善余地が出尽くした、(2) プラグイン依存でセキュリティ・保守コストが上がっている、(3) 別ドメインの専門メディアを並行運用したくなった、(4) 編集体制がアプリ・複数ドメインに広がった、のいずれかに該当するときが目安です。改善余地がある段階で切り替えると、移行コストに見合いません。
AI検索時代に有利なCMSはありますか？
構造化データ・メタ情報・サイトマップ・llms.txt・表示速度などのAI検索向け要件は、WordPress・Astro・ヘッドレスCMSのいずれでも対応可能です。差が出るのは入稿スピードと記事点数で、コードベース（Astro＋Git＋Markdown）が圧倒的に有利です。生成AIの出力をそのままMarkdownファイルとしてGitにコミットでき、CMSへの転記工程が不要になるためです。
外部代行を使う場合のCMSの選び方は？
人手の代行を中心に組むならWordPressが圧倒的に有利です。多くの編集者・ライター・運用代行がWordPress入稿に慣れており、入稿テンプレートやマニュアルも整備されているため、立ち上げコストを抑えられます。Astroやヘッドレスを採用する場合は、対応経験のある代行を最初から探すか、AI入稿（生成AIの出力をMarkdownのままGitにコミット）を前提とする代行体制を組む必要があります。
11.AI活用で、CMS運用を標準化する
CMS選定が終わっても、運用フェーズではライター・編集者・SEO担当者の人件費が継続的に発生します。弊社ではAIフル活用によるSEO自動化パイプラインで、WordPressでもAstroでも入稿フローをテンプレ化し、構造化データ・メタ情報・内部リンクまで含めた入稿を一括で代行しています。
AI活用代行では、CMS選定、構成案、入稿準備、リライト候補整理を標準化しつつ、ディレクションと一次情報インタビュー、最終レビューを人間が担う設計にできます。CMSを選ぶ段階で、この分業が回るかも確認します。
TANTOU ─ 回すほど高品質になる、AI SEO エンジン
WordPress・Astro・ヘッドレスCMSのいずれの構成でも、キーワード戦略 → 制作 → 公開 → 分析 → ガイドライン改善を同じ基準で回します。BtoB・BtoC問わず、構造化データ・メタ情報・内部リンクまで含めた運用を支援します。
メディア運用・コンテンツ制作 基礎知識集
一覧に戻る →戦略・全体設計
CMS選定
- ›CMS選定の考え方（この記事）
