CMS選定ガイド

技術選定 CMS コンテンツ管理 アーキテクチャ

CMS選定ガイド

このドキュメントは、プロジェクトでCMS（Content Management System）を選定する際の検討事項をまとめたものです。従来型CMSからヘッドレスCMS、GitベースCMS、ファイルベースCMSまで、技術の進化の流れを理解することで、各技術の本質的な特徴と適切な用途が見えてきます。

CMSの進化の歴史

各技術は、前世代の技術が抱えていた課題を解決するために生まれてきました。フロントエンドとバックエンドの分離、開発者体験の向上、運用性の改善へと進化してきました。

第一世代：従来型CMS（2000年代〜）

WordPress (2003年)

生まれた背景: ブログやWebサイトを簡単に作成・管理できるように。非技術者でもコンテンツを管理できるように。

解決した課題:

  • 非技術者でもコンテンツを管理可能
  • 豊富なテーマとプラグイン
  • 簡単なインストールとセットアップ
  • 管理画面による直感的な操作

残された課題:

  • フロントエンドとバックエンドが密結合: デザイン変更が困難
  • パフォーマンス問題: 動的生成による遅延
  • セキュリティリスク: プラグインやテーマの脆弱性
  • スケーリングが困難: サーバー負荷が高い
  • 開発者体験が悪い: カスタマイズが複雑

影響: 世界で最も使用されているCMS。多くのWebサイトで採用されている。

Drupal (2001年)

生まれた背景: より柔軟で拡張性の高いCMS。エンタープライズ向けの機能。

解決した課題:

  • 高いカスタマイズ性
  • エンタープライズ向けの機能
  • 複雑なコンテンツ構造に対応
  • 権限管理が細かい

残された課題:

  • 学習コストが高い
  • フロントエンドとバックエンドが密結合
  • パフォーマンス問題
  • 開発が複雑

影響: エンタープライズ向けCMSとして採用。政府機関や大企業で使用。

第二世代：ヘッドレスCMS（2010年代後半〜）

生まれた背景: モバイルアプリ、SPA、静的サイトなど、多様なフロントエンドに対応するため、コンテンツ管理とフロントエンドを分離。

Contentful (2013年)

解決した課題:

  • フロントエンドとバックエンドの分離: 任意のフロントエンドで使用可能
  • API経由でのコンテンツ提供: REST API、GraphQL API
  • マルチチャネル対応: Web、モバイル、IoT等
  • 開発者体験の向上: モダンな開発ワークフロー
  • スケーラビリティ: クラウドベースで自動スケーリング

残された課題:

  • コストが高い（使用量に応じた課金）
  • ベンダーロックイン
  • オフライン編集ができない
  • カスタマイズが限定的

影響: ヘッドレスCMSの先駆者。多くの企業で採用。

Strapi (2016年)

解決した課題:

  • オープンソース: ベンダーロックインの回避
  • 自己ホスティング可能: インフラのコントロール
  • カスタマイズ性: プラグイン開発が容易
  • 開発者向け: Node.jsベースで開発しやすい

残された課題:

  • 運用負荷がある（自己ホスティングの場合）
  • エコシステムが限定的（Contentfulと比較）
  • エンタープライズ機能が限定的

影響: オープンソースのヘッドレスCMSとして注目。開発者コミュニティで支持。

Sanity (2017年)

解決した課題:

  • リアルタイムコラボレーション: 複数ユーザーが同時編集
  • 構造化コンテンツ: 柔軟なコンテンツモデル
  • 開発者体験: Reactベースのカスタマイズ
  • 画像最適化: 自動的な画像最適化

残された課題:

  • 学習コスト（独自の概念）
  • コストが高い（大規模利用時）
  • ベンダーロックイン

影響: リアルタイムコラボレーション機能で注目。コンテンツチーム向け。

第三世代：GitベースCMS（2010年代後半〜）

生まれた背景: 開発者体験の向上、バージョン管理の活用、CI/CDとの統合。

Netlify CMS (2017年)

解決した課題:

  • Gitでコンテンツを管理: バージョン管理が容易
  • 静的サイトとの統合: Jekyll、Hugo、Gatsby等と統合
  • CI/CDとの統合: 自動デプロイ
  • オープンソース: 無料で使用可能

残された課題:

  • 機能が限定的（従来型CMSと比較）
  • 非技術者には使いにくい
  • リアルタイム編集ができない

影響: 静的サイト向けCMSとして広く採用。開発者向け。

Forestry (2016年)

解決した課題:

  • Gitベース: バージョン管理
  • 直感的なUI: 非技術者でも使いやすい
  • プレビュー機能: 変更内容の確認
  • 複数ブランチ対応: ワークフロー管理

残された課題:

  • サービス終了（2022年）
  • ベンダーロックイン

影響: GitベースCMSの先駆者。後継サービス（Tina CMS等）に影響。

Tina CMS (2020年)

解決した課題:

  • オープンソース: ベンダーロックインの回避
  • ローカル開発: 開発環境で動作
  • リアルタイムプレビュー: 変更が即座に反映
  • TypeScript対応: 型安全性

残された課題:

  • エコシステムが成長中
  • 企業での採用事例が限定的

影響: Forestryの後継として注目。開発者向けCMS。

第四世代：ファイルベースCMS（2010年代〜）

生まれた背景: 最もシンプルなアプローチ。ファイルを直接編集し、Gitで管理。

Markdown + Git

解決した課題:

  • 最もシンプル: 追加のツールが不要
  • Gitでバージョン管理: 完全な履歴管理
  • 人間が読み書き可能: 直接編集可能
  • CI/CDとの統合: 自動ビルド・デプロイ
  • コストゼロ: 追加コストなし

残された課題:

  • 非技術者には使いにくい
  • 管理画面がない
  • リアルタイム編集ができない
  • 権限管理が限定的

影響: 開発者向けのコンテンツ管理の標準。多くの静的サイトで採用。

MDX（Markdown + JSX）

解決した課題:

  • Markdownの拡張: Reactコンポーネントを埋め込める
  • インタラクティブなコンテンツ: 動的な要素を追加可能
  • 開発者体験: コードとコンテンツの統合

残された課題:

  • 非技術者には使いにくい
  • 学習コスト（JSXの知識が必要）

影響: 技術ドキュメント、ブログで採用。開発者向け。

技術の系譜と選択の指針

フロントエンド分離の系譜

WordPress（密結合） → Contentful（API分離） → GitベースCMS（完全分離） → ファイルベース（統合）

選択の指針: フロントエンドとバックエンドを分離したい場合、ヘッドレスCMSまたはGitベースCMSを検討。

開発者体験重視の系譜

WordPress（複雑） → ヘッドレスCMS（API） → GitベースCMS（Git統合） → ファイルベース（シンプル）

選択の指針: 開発者体験を重視する場合、GitベースCMSまたはファイルベースCMSを検討。

非技術者向けの系譜

WordPress（管理画面） → ヘッドレスCMS（管理画面） → GitベースCMS（管理画面） → ファイルベース（技術者向け）

選択の指針: 非技術者がコンテンツを管理する場合、管理画面があるCMSを選択。

コスト重視の系譜

商用CMS（有料） → ヘッドレスCMS（使用量課金） → GitベースCMS（オープンソース） → ファイルベース（無料）

選択の指針: コストを最小化したい場合、オープンソースまたはファイルベースCMSを検討。

現在の主要技術の比較

WordPress (2003年)

強み:

  • 世界で最も使用されているCMS
  • 豊富なテーマとプラグイン
  • 非技術者でも使いやすい
  • 簡単なセットアップ

弱み:

  • フロントエンドとバックエンドが密結合
  • パフォーマンス問題
  • セキュリティリスク
  • スケーリングが困難
  • 開発者体験が悪い

適している用途: ブログ、小規模Webサイト、非技術者が管理するサイト

選ぶべき場合:

  • 非技術者がコンテンツを管理する
  • 豊富なテーマとプラグインが必要
  • シンプルなブログやWebサイト
  • カスタマイズが限定的で良い

Contentful (2013年)

強み:

  • フロントエンドとバックエンドの分離
  • マルチチャネル対応（Web、モバイル、IoT）
  • スケーラビリティ
  • 開発者体験が良い
  • 豊富な機能

弱み:

  • コストが高い（使用量に応じた課金）
  • ベンダーロックイン
  • オフライン編集ができない

適している用途: エンタープライズアプリケーション、マルチチャネル対応が必要なプロジェクト

選ぶべき場合:

  • 複数のフロントエンド（Web、モバイル、IoT）で同じコンテンツを使用
  • スケーラビリティが必要
  • 開発者体験を重視
  • コストを許容できる

Strapi (2016年)

強み:

  • オープンソース（ベンダーロックイン回避）
  • 自己ホスティング可能
  • カスタマイズ性が高い
  • Node.jsベースで開発しやすい

弱み:

  • 運用負荷がある（自己ホスティングの場合）
  • エコシステムが限定的
  • エンタープライズ機能が限定的

適している用途: 中規模Webアプリケーション、カスタマイズが必要なプロジェクト

選ぶべき場合:

  • オープンソースを重視
  • 自己ホスティングしたい
  • カスタマイズが必要
  • 運用チームが充実している

Sanity (2017年)

強み:

  • リアルタイムコラボレーション
  • 構造化コンテンツ
  • 開発者体験（Reactベース）
  • 画像最適化

弱み:

  • 学習コスト（独自の概念）
  • コストが高い（大規模利用時）
  • ベンダーロックイン

適している用途: コンテンツチームが複数人で編集するプロジェクト、リアルタイム編集が必要

選ぶべき場合:

  • 複数ユーザーが同時編集する
  • リアルタイムコラボレーションが必要
  • 構造化コンテンツが必要
  • コストを許容できる

Netlify CMS (2017年)

強み:

  • Gitでコンテンツを管理
  • 静的サイトとの統合
  • CI/CDとの統合
  • オープンソース（無料）

弱み:

  • 機能が限定的
  • 非技術者には使いにくい
  • リアルタイム編集ができない

適している用途: 静的サイト（Jekyll、Hugo、Gatsby等）、開発者向けプロジェクト

選ぶべき場合:

  • 静的サイトを使用している
  • Gitでコンテンツを管理したい
  • CI/CDと統合したい
  • 開発者向けのプロジェクト

Tina CMS (2020年)

強み:

  • オープンソース
  • ローカル開発
  • リアルタイムプレビュー
  • TypeScript対応

弱み:

  • エコシステムが成長中
  • 企業での採用事例が限定的

適している用途: 開発者向けプロジェクト、Reactベースのサイト

選ぶべき場合:

  • オープンソースを重視
  • ローカル開発環境で動作させたい
  • Reactベースのサイト
  • リアルタイムプレビューが必要

Markdown + Git（ファイルベース）

強み:

  • 最もシンプル（追加ツール不要）
  • Gitでバージョン管理
  • 人間が読み書き可能
  • CI/CDとの統合
  • コストゼロ

弱み:

  • 非技術者には使いにくい
  • 管理画面がない
  • リアルタイム編集ができない
  • 権限管理が限定的

適している用途: 開発者向けプロジェクト、技術ドキュメント、ブログ

選ぶべき場合:

  • 開発者がコンテンツを管理する
  • 最もシンプルな構成を望む
  • Gitでバージョン管理したい
  • コストを最小化したい

選定時の実践的な検討事項

技術の進化の流れを理解した上で、プロジェクトの要件に合わせて選定します。

1. コンテンツ管理の要件

コンテンツ管理者

  • 非技術者: WordPress、Contentful、Strapi、Sanity
  • 技術者: Netlify CMS、Tina CMS、Markdown + Git

編集頻度

  • 頻繁: 管理画面があるCMS（WordPress、Contentful等）
  • 稀: ファイルベースCMS（Markdown + Git）

同時編集

  • 必要: Sanity（リアルタイムコラボレーション）
  • 不要: その他のCMS（通常の編集で対応可能）

2. フロントエンド要件

フロントエンド技術

  • 任意の技術: ヘッドレスCMS（Contentful、Strapi等）
  • 静的サイト: GitベースCMS（Netlify CMS、Tina CMS）、ファイルベース
  • WordPress: WordPress（テーマシステム）

マルチチャネル対応

  • 必要: ヘッドレスCMS（Contentful、Strapi等）
  • 不要: 従来型CMS、ファイルベースCMS

3. 開発・運用要件

開発者体験

  • 重要: ヘッドレスCMS、GitベースCMS、ファイルベースCMS
  • やや重要: 従来型CMS

運用負荷

  • 最小化したい: マネージドサービス（Contentful、Sanity）
  • 許容できる: 自己ホスティング（Strapi、WordPress）
  • 完全にコントロールしたい: ファイルベースCMS

CI/CD統合

  • 必要: GitベースCMS、ファイルベースCMS
  • 不要: 従来型CMS、一部のヘッドレスCMS

4. コスト要件

初期コスト

  • 最小化したい: オープンソース（WordPress、Strapi、Netlify CMS、Tina CMS、ファイルベース）
  • 許容できる: マネージドサービス（Contentful、Sanity）

運用コスト

  • 最小化したい: ファイルベースCMS（コストゼロ）
  • 許容できる: オープンソース（自己ホスティング）
  • 高額でも良い: マネージドサービス

選定チェックリスト

選定時に確認すべき項目をチェックリスト形式でまとめます。

コンテンツ管理要件

  • コンテンツ管理者（技術者/非技術者）
  • 編集頻度（頻繁/稀）
  • 同時編集の必要性
  • 権限管理の要件

フロントエンド要件

  • フロントエンド技術（任意/静的サイト/WordPress）
  • マルチチャネル対応の必要性
  • カスタマイズ性の要件

開発・運用要件

  • 開発者体験の重要性
  • 運用負荷（最小化/許容/完全コントロール）
  • CI/CD統合の必要性
  • バージョン管理の要件

コスト要件

  • 初期コスト（最小化/許容/高額可）
  • 運用コスト（最小化/許容/高額可）
  • スケーリングコスト

その他

  • ベンダーロックインの許容
  • オープンソースの要件
  • セキュリティ要件
  • パフォーマンス要件

参考資料