Contentful は API ファーストのヘッドレス CMS だ。WordPress のように表示まで一体で面倒を見るのではなく、コンテンツの「管理」と「配信」を API として切り出し、表側のフロントエンドは開発者が自由に作る、という思想で設計されている。
構造化されたコンテンツモデル
特徴はコンテンツモデルを自分で設計できる点だ。「記事」「著者」「商品」といった型をフィールド単位で定義し、参照関係も張れる。整形済みの HTML を貯めるのではなく、構造化データとして持つので、同じコンテンツを Web・アプリ・別チャネルへ使い回しやすい。配信用の Content Delivery API は CDN 経由で速く、編集用の Management API、GraphQL も用意され、Webhook で更新をビルドのトリガーにできる。
JAMstack との相性と料金
Next.js や Astro などで静的サイトを生成し、コンテンツは Contentful から取る――この JAMstack 構成と素直にかみ合う。多言語化(ローカライゼーション)も標準機能なので、複数言語のサイトを一元管理したい場合に向く。料金は無料の Community 枠があり、有料は段階制で、ユーザー数・コンテンツ数・API コール数の規模に応じて上がる。
設計を変えにくいという落とし穴
実運用で効いてくるのは、コンテンツモデルを後から大きく変えるコストだ。フィールドの型変更や必須化は、すでに何百件もエントリが入った状態だとマイグレーションが重く、移行スクリプトを書く前提になる。立ち上げ時にモデルを雑に切ると、後で全エントリを触り直す羽目になりやすい。最初に「どこまでを構造化し、どこを自由記述のリッチテキストに逃がすか」を決め切っておくと、その後の負担が大きく変わる。
向かないケース
逆に、プラグインを入れて機能を継ぎ足していく WordPress 的な拡張エコシステムを期待すると肩透かしになる。Contentful はあくまでコンテンツの入れ物と配信に徹しており、表示や機能は自前で実装する前提だ。フロントエンドを書ける開発リソースがある構成でこそ生きるツールであり、サイト制作を丸ごと外注して運用だけ引き継ぐような体制とは噛み合いにくい。