Contentfulとは——上限は「プラン」と「Space」の2軸で決まる【2026年版】多言語・環境・料金の読み方

「提案書にContentfulと書いてあるが、これは何なのか」——サイトのリニューアルや多言語対応を検討し始めた方から、こうした相談をよく受けます。調べると「ヘッドレスCMS」という分類が出てきて、グローバル企業の導入事例が並び、料金ページには$300/monthと書かれている。ただ、それが自社の何を解決するのかが見えてこない。

先に結論を書きます。Contentfulは、ひとつのコンテンツを複数の言語・複数の配信先へ届けることを前提に設計されたヘッドレスCMSです。そして検討時にいちばん誤解されるのが、使える上限が1本の軸で決まらないという点です。ユーザー数やロケール数やAPIコール数はPlatformプラン(Free / Lite / Enterprise)で決まり、コンテンツタイプ数や環境数やレコード数はSpaceの種類で決まります。月額を払えば制限が外れる、という構造ではありません。

この記事では、Contentful固有の中身だけを扱います。データの持ち方(スペース・環境・コンテンツタイプ・エントリ)、環境の使い分け、ローカリゼーション、5つのAPIとアプリ、料金体系とSpaceのクォータ、そして日本企業が詰まりやすい点です。ヘッドレスCMSとは何かという一般論は、当社の別記事にまとめてあるのでそちらへ譲ります。実装のコードも出てきません。想定している読者は、技術者ではなくCMSを選定している事業側の方です。なお料金・上限・機能は2026年9月15日に公式サイトと公式ドキュメントで確認した内容で、公式に日本円の表記がないため価格はUSDのまま記載し、勝手な換算はしていません。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、2018年からホーチミンを拠点に、約100社の開発体制づくりを支援してきました。当社はヘッドレスCMSを使ったWebサイトの構築を開発実績として持っており、つまり表示側をつくる側です。その立場から言うと、Contentfulは合う案件と過剰な案件がはっきり分かれます。言語が1つで配信先も1サイト、更新も年に数回という構成なら、この道具立ての大半は使わずに終わります。

読み終えたら、4つだけ棚卸ししてみてください。言語とロケールはいくつ必要か。配信先はWebだけか、アプリやサイネージも含むか。コンテンツの構造を今後どれくらい作り替えるか。表示側を誰が持ち続けるのか。この4つが埋まれば、提案されたプラン構成が自社に合っているかは、その場で判断できます。

Contentfulとは——多言語と複数チャネルを前提につくられた海外製のヘッドレスCMS

Contentfulは、ドイツ・ベルリン発のヘッドレスCMSです。コンテンツを「スペース」という単位で管理し、「コンテンツタイプ」でデータの構造を定義して、APIで外部のアプリケーションへ届けます。ここで押さえておきたいのは、この製品が「Webページを作るためのツール」として設計されていないことです。設計の前提にあるのは、ひとつのコンテンツを複数の言語・複数の配信先へ配るという状況です。

ヘッドレスCMSという分類のなかでの位置づけ

ヘッドレスCMSとは、ユーザーが見る表示画面(ヘッド)を持たず、コンテンツの管理と配信だけに特化したCMSのことです。従来型のCMSがテーマやプラグインで画面まで面倒を見てくれるのに対して、ヘッドレス型は表示側を利用者側が用意します。この分類そのものの説明、従来型CMSとの構造の違い、ヘッドレスを選ぶと自社に何が残るのかについては「microCMSとは」の記事で詳しく扱っているので、そちらをご覧ください。本記事では、その前提を踏まえたうえで、Contentful固有の中身だけを見ていきます。

2014年の誕生から、2026年のSalesforce傘下入りまで

Contentfulの共同創業者は、公式ブログのなかで、当時のCMSがネイティブのモバイルアプリに向いていないという着想から会社が生まれたと書いています。iPhone向けのアプリを開発していた側と、バックエンドを作っていた側の2人が始めた、という経緯です。Webサイトのページを組み立てる道具ではなく、アプリにコンテンツを流し込む道具として出発している。この出自が、現在の機能構成——多言語、複数環境、複数のAPI——にそのまま残っています。

2026年6月1日、Salesforceによる買収の合意が発表されました。公式ブログ「A New Chapter for Contentful」で共同創業者が「13年のチームワークの集大成」として公表したもので、Salesforceの発表では取引の完了時期を同社の2027会計年度第3四半期としています。2026年9月15日時点で、Contentfulの公式サイトのトップには「Contentful is now officially part of Salesforce!」というバナーが出ています。

事業側の担当者として気にすべきなのは、買収そのものより、今後の製品方針と料金体系がどう動くかです。現時点で公式に発表されているのは体制の話までで、プランの統合や価格改定についての告知は確認できませんでした。数年単位で使うCMSを選ぶ以上、この点は稟議の材料として押さえておく価値があります。

日本製のmicroCMSと比べると、どこが違うのか

比較を主題にはしませんが、立ち位置だけ整理しておきます。日本製のmicroCMSは、管理画面もドキュメントもサポートも日本語で、料金も日本円で、国内のサイト運用を素直に回すことに最適化されています。対するContentfulは、ロケール(言語+地域)を前提にしたローカリゼーションの仕組み、本番を止めずにコンテンツモデルを変えるための環境(environment)、5つのAPIといった、複数言語・複数ブランド・複数チャネルを同時に扱うための道具立てが厚い。その代わり、公式の一次情報は英語で、料金もUSD建てです。つまり選択は「どちらが優れているか」ではなく、「その道具立てを使う要件が自社にあるか」で決まります。要件が1言語・1サイトなら、Contentfulの強みはほぼ使いません。

私は2018年からホーチミンを拠点に、約100社の開発体制づくりを支援してきました。CMS刷新の相談でContentfulの名前が挙がるとき、その多くは海外拠点や多言語のページを抱えている企業です。逆に、国内向け1サイトの案件でこの名前が出てきたときは、たいてい提案側の得意技で選ばれています。輪郭が見えたところで、次はContentfulがどうデータを持つのかを見ていきます。

Contentfulのデータの持ち方——スペース・環境・コンテンツタイプ・エントリ

Contentfulの説明が頭に入りにくい原因は、耳慣れない単語が5つ同時に出てくることにあります。スペース、環境、コンテンツタイプ、エントリ、アセット。この5つは入れ子の階層になっていて、順番に並べれば一度で理解できます。そして、この階層を押さえると、後で出てくる上限も料金も、すべて同じ図の上に並びます。

5つの階層で覚える——組織 / スペース / 環境 / コンテンツタイプ / エントリとアセット

公式ドキュメントのデータモデルでは、スペースを「ひとつのプロジェクトに関係するリソースをまとめる単位」と説明しています。エントリ、メディアアセット、そして言語ごとのローカライズ設定が、このスペースの中に入ります。実際の階層は次のとおりです。

この表を上から下へ読むと、Contentfulが「箱の中に箱を入れる」構造で出来ていることが分かります。そして上限は、ほぼすべてこの箱の単位で課されます。コンテンツタイプの数はスペース(正確にはSpaceの種類)ごと、環境の数もスペースごと、ロケールは環境ごと、といった具合です。料金の話が分かりにくくなるのは、プラン側とスペース側の両方から上限が来るからで、この点は料金の章で改めて整理します。

なお、アセットには名前・説明・添付ファイルという3つの固定フィールドがあると公式ドキュメントに明記されています。画像に代替テキストを持たせたい、撮影者のクレジットを持たせたいといった要件があるなら、アセットそのものではなく、アセットを参照する別のコンテンツタイプを作るのが定石です。

フィールドは12種類、1コンテンツタイプにつき50まで

コンテンツタイプは、フィールドの集まりです。公式ドキュメントでは、使えるフィールドの型として短いテキスト(Symbol)、長いテキスト(Text)、リッチテキスト(RichText)、整数、小数、日時、位置情報、真偽値、メディア、参照、配列、JSONオブジェクトが挙げられています。それぞれに上限があり、発注前に知っておく価値があるのは次の3つです。

• 短いテキストは256文字まで。タイトルやスラッグ用
• 長いテキストは50,000文字まで。全文検索の対象になる
• リッチテキストは200,000文字まで。ただしフィールド全体で1MBを超えられない

そしてフィールドの数は、1つのコンテンツタイプにつき50個までです。これは技術上限のページに明記されている数字で、プランを上げても変わりません。1つの型に何十もの項目を詰め込む設計をしていると、ここで頭を打ちます。実務では、50に近づいた時点で設計を疑うべきサインだと考えています。

参照(Reference)でつなぐ設計と、その上限

Contentfulのコンテンツモデルでいちばん効くのが、参照フィールドです。たとえば「製品」から「ブランド」と「カテゴリ」を参照する、というように、エントリどうしを関連づけられます。公式ドキュメントのサンプルでも、商品カタログをカテゴリ・ブランド・製品の3つの型に分けて参照でつなぐ例が示されています。

この参照にも上限があります。技術上限のページによれば、1つのエントリが持てるリンクの合計は1,000、参照をたどれる深さは10階層までです。10階層というのは、通常の設計で当たる数字ではありません。当たるとしたら、それは型の切り方を間違えている可能性が高い。参照は便利なので、設計の初期に増やしすぎる傾向があります。当社がヘッドレスCMSでサイトを構築する案件でも、モデル設計のレビューは日本人PMが必ず入る工程にしています。

環境(environment)の使い分け——masterとsandbox、そしてエイリアス

環境は、Contentfulを他のCMSと分ける機能のひとつです。スペースを作ると自動的に「master」という環境ができ、そこから複製する形でsandbox環境を作れます。公式ドキュメントでは、masterを本番配信用、sandboxを非本番の開発・テスト用と位置づけ、sandboxを本番に使ってはならないと明記しています。

なぜこれが効くのか。コンテンツモデルの変更を、本番を止めずに試せるからです。「製品」に新しいフィールドを足したい、参照の構造を変えたいといった変更を、sandboxで作って動かし、問題がなければ本番へ持っていく。運用中のサイトでモデルを変えるのは本来こわい作業ですが、その怖さを下げるための仕組みが標準で用意されている、というのがContentfulの性格をよく表しています。

ただし、実務で先に知っておくべき制約が4つあります。

さらに「環境エイリアス」という仕組みがあり、masterという名前を実体の環境に付け替えられます。これを使うと、新しいモデルで作った環境を、表示側の接続先を変えずに本番へ切り替えられます。ただし技術上限のページによれば、カスタムエイリアスを含まないプランではエイリアスは master の1つだけ、含むプランでも master + カスタム2つの計3つまでです。

器の設計は、公開してからやり直すほど高くつきます。コンテンツタイプの切り方も環境の運用ルールも、入稿が始まってからでは動かしにくい。だからこそ設計段階で、次章の多言語要件まで含めて決めておく必要があります。

ローカリゼーション(多言語配信)——4つの持たせ方と、ロケール数という壁

Contentfulを選ぶ理由として最も多いのが、多言語です。ただし「多言語対応している」という一言で片づけると、後で設計をやり直すことになります。Contentfulには多言語コンテンツの持ち方が4通りあり、どれを選ぶかで権限の効き方も公開の粒度も変わるからです。そして無料プランには、日本企業が最初に当たる上限があります。

ロケールは「言語+地域」の組で持つ

Contentfulでは、言語のことを「ロケール」と呼びます。公式ヘルプでは、ロケールを「言語と地域の組」と定義しています。ドイツ語ひとつをとっても、ドイツ向けの de-DE、オーストリア向けの de-AT、スイス向けの de-CH があり、それぞれ別のロケールとして扱えます。日本語なら ja-JP、アメリカ英語なら en-US です。

一覧に用意されていないロケールが必要な場合は、Content Management API を使ってカスタムロケールを作成できるとヘルプに書かれています。また、ロケールは環境ごとに設定する項目です。つまりsandbox環境で言語構成を試してから本番へ持っていく、という運用ができます。

フォールバックという考え方も押さえておいてください。あるロケールの値が空のとき、別のロケールの内容で埋める設定です。たとえばカナダ・フランス語が空ならフランス・フランス語を出す、といった具合です。翻訳が追いつかない期間があるなら、この設定を先に決めておくと、公開の判断が楽になります。

4つのローカライズ方式と、選ぶときの3つの基準

公式ヘルプは、多言語コンテンツの持ち方を4つ挙げています。判断の基準として示されているのは、ガバナンス(特定のロケールだけを編集させられるか)、非同期公開(ロケールごとに別のタイミングで公開できるか)、フォールバックの3つです。

実務でよく使われるのはフィールド単位です。日本語と英語を同じ画面に並べて見比べながら編集できるうえ、「タイトルは翻訳するが、イベント開催日は全ロケール共通にする」といったフィールド単位の設定ができます。公式ヘルプはこの方式を、複数言語を同時に公開する運用に最も適していると位置づけています。

一方、地域法人がそれぞれ独自の内容を持ち、構成そのものが違うというケースでは、コンテンツタイプ単位やスペース単位が候補に入ります。ただしこの2つはフォールバックが働かず、型を同期させ続ける手間が発生します。公式ヘルプも、型が似すぎても違いすぎても困るという難しさを認めています。

どの方式を採るかは、翻訳の体制で決まります。日本語の原稿を翻訳会社に出して全言語を揃えてから公開するのか、各国の担当者が自分の裁量で書くのか。前者ならフィールド単位、後者ならエントリ単位以降が向きます。この判断はコンテンツモデルの形に直結するので、CMSの契約より前に決めておくべき項目です。

日本語+英語+もう1言語で、無料プランの上限に当たる

ここが実務で最初に当たる壁です。2026年9月15日時点の公式の料金ページによれば、使えるロケール数は Free プランが2、Lite プランが3、Enterprise がカスタムです。技術上限のページには環境あたり500ロケールという数字も載っていますが、プランの割り当てが技術上限より小さい場合はプラン側が優先されると明記されています。

つまり、日本語と英語の2言語だけなら無料プランの範囲に収まりますが、そこに中国語を足した瞬間に有料プランが必要になります。さらに簡体字と繁体字を分けたい、英語を en-US と en-GB に分けたいといった要件が出ると、Liteの3も超えます。言語を足すたびにプランが動く構造です。

多言語サイトの相談を受けるとき、私が最初に確認するのはこの点です。「いま何言語で、3年後は何言語か」。ロケールは後から足せますが、足すたびに翻訳の運用も費用も増えます。言語を足すのは、あとから足すほど高い。だから最初の設計時に、将来の言語構成まで含めて方式を選んでおくのが得策です。

ContentfulのAPI——Delivery・Preview・Management・Images・GraphQLの5つ

ヘッドレスCMSは、APIでしかデータを出しません。だからAPIの構成を理解することは、そのCMSで何ができるかを理解することとほぼ同じです。Contentfulには役割の違う5つのAPIがあり、どれをどこで使うかが、表示側の作り方と権限設計を決めます。ここは発注前に開発会社と合わせておく箇所です。

5つのAPIの役割とエンドポイント

公式ドキュメントのAPI基礎のページでは、5つのAPIが次のように整理されています。

読み方のこつは、CDAとCPAが「同じ形をした別のドア」だという点です。表示側の実装は1つ書いておき、接続先とアクセストークンを差し替えればプレビュー環境になります。GraphQLのスキーマは、コンテンツタイプを更新するたびに自動で作り直されると明記されています。またEUのデータレジデンシーを使う顧客向けに、cdn.eu / preview.eu / api.eu / images.eu / graphql.eu という別系統のエンドポイントが用意されています。

当社は決済アプリやAIチャットボット、求人プラットフォームなど、外部APIと繋ぎ込む開発を多く担当してきました。その経験から言うと、この5つのうち設計を誤りやすいのはCMAです。読み取りにも使えるため便利に見えますが、未公開のコンテンツも全ロケール分も返すので、表示側からうっかり呼ぶと出してはいけないものが出ます。表示はCDA、プレビューはCPA、書き込みはCMAという原則を、最初に文書で固めておくことをお勧めします。

レート制限とサイズの上限——発注前に見ておく数字

料金ページに載る月間のAPIコール数とは別に、秒単位のレート制限があります。2026年9月15日時点の技術上限のページから、事業側が見ておくべき数字を抜き出すと次のとおりです。

• CDA(GraphQLを含む): Freeプランは1スペースあたり毎秒55リクエスト、有料プランは毎秒78リクエスト
• CPA: Freeは毎秒14、有料は毎秒20
• CMA: Freeは毎秒7、有料は毎秒10
• リクエストサイズ1MB、レスポンスサイズ7MB、GraphQLのリクエストは8KBまで
• 1エントリのサイズは2MB、URIの長さは7,600文字まで
• Webhookはスペースあたり、FreeとLiteが20個、Lite以外の有料プランが100個

この数字を見て「毎秒78回で足りるのか」と不安になるかもしれませんが、事前生成(SSG)やCDNのキャッシュを使う構成なら、公開ページの表示ごとにAPIを叩くわけではありません。逆に、リクエストのたびにCMSへ問い合わせる作りにすると、この数字が効いてきます。どちらの作りにするかは表示側の設計の話なので、発注時に必ず確認してください。

アプリとマーケットプレイス——App Frameworkの7つの配置場所

Contentfulには、管理画面そのものを拡張する仕組みがあります。公式のマーケットプレイスには100以上の連携とプラグインが並んでいると記載されており、Vercel、Slack、OpenAIを使ったAIコンテンツ生成といったアプリが公開されています。

自社用のアプリを作ることもできます。App Framework のドキュメントによれば、アプリを置ける場所は7つです。App Configuration(アプリの設定画面)、Page(独立したページ)、Home(ホーム画面)、Dialog(モーダル)、Entry Editor(エントリ編集画面そのもの)、Entry Field(個々のフィールドの入力欄)、Entry Sidebar(エントリ画面の右側)。フィールドの入力欄を自社仕様に差し替えたり、右側に社内システムの情報を表示したりできる、というのが現実的な使い道です。

ここも上限があります。技術上限のページでは、アプリの定義数は Free プランが組織あたり10、有料プランが250、インストール数は Free が環境あたり10、有料が50です。マーケットプレイスのアプリを並べるだけなら十分ですが、自社アプリを多数抱える構成では確認が必要です。

APIの使い分けとアプリの要否は、見積もりの金額を左右します。相見積もりを取るなら、この2つを条件として揃えてから依頼するのが確実です。

Contentfulの料金体系——2026年9月15日時点の3区分と、Spaceという第2の軸

ここが本記事でいちばん誤解されやすいところです。Contentfulの上限は1本の軸では決まりません。プラン側で決まるものと、Space側で決まるものがあり、その組み合わせで実際に使える範囲が決まります。以下の数値はすべて2026年9月15日に公式の料金ページで確認したものです。日本円の表記は公式にないため、通貨はUSDのまま記載し、換算はしていません。

Platformプランは Free・Lite・Enterprise の3区分

まず契約の土台となるPlatformプランです。

FreeとLiteで「超過分の課金」の扱いが違う点に注意してください。Freeは上限に達しても追加課金は発生しない代わりに、その先へは伸びません。Liteは有料の超過が許容されます。運用の読みが立っていない段階でFreeを本番に使うと、月の途中で上限に達したときに打つ手がなくなります。

Enterpriseは金額が公開されていません。公式には「カスタムのユーザー数・ロール数・ロケール数」「無制限のAPIコール」「最大99.99%の稼働率SLA」「Spaceの割り当ては無制限」「Personalization・Studio・AI Actionsと組み合わせ可能」と書かれています。追加で契約できる製品として、Personalization(パーソナライズ配信)、AI Actions(AIによるコンテンツ作成の自動化)、Studio(画面のビジュアル組み立て)、Professional Services(導入支援)が並んでいます。

また、スペースの数そのものにも上限があります。技術上限のページによれば、組織あたりのスペース数は Free が1、Lite が2、Lite以外の有料プランが750です。

Spaceという第2の軸——Starter・Lite Space・Premium Spaces

ここが本題です。プランを上げても、Spaceのクォータは自動では上がりません。公式の料金ページは、Spaceを「プロジェクトごとの領域」と説明し、種類ごとに次のクォータを示しています。

つまり、$300/monthのLiteプランを契約しただけでは、Spaceは Starter Space のままです。コンテンツタイプは25、環境は2(本番と検証用が1つずつ)、レコードは10,000。この枠を超えたいなら、$850/monthのLite Spaceを追加購入するか、Enterpriseに上がるかの二択になります。日本語の解説記事で「Liteにすれば環境が4つ使える」と書かれているものがありますが、正確には「Lite Spaceを追加購入すれば」です。

Premium Spaces は Enterprise 向けで、3つの性格に分かれています。Standard は標準的なマーケティングサイト向け、Enterprise は複数のチーム・ブランド・事業部・地域をまたぐ運用向け(公開前に伏せておくアセット、ロケール単位の公開、ローカライズされたワークフロー、スペース間の連携などが使える)、Templated はテンプレートを揃えた小規模サイトを大量に展開する用途(グローバルのマイクロサイトやフランチャイズ)向けです。複数ブランドのサイトを1つに統合したいという相談では、この3種をどう組み合わせるかが見積もりの中身になります。

無料枠で実際にどこまでできるのか

Freeプランは「学習と検証のため」と公式に位置づけられています。数字を並べると、ユーザー10人、ロール2種(管理者と編集者)、ロケール2つ、APIコール100K/月、CDN帯域50GB/月、スペース1つ、コンテンツタイプ25、環境2、レコード10,000です。技術上限のページによれば、1ファイルのアップロードは50MBまで、アプリの定義と設置は各10までです。

この範囲で何ができるか。日本語と英語の2言語で、中規模のオウンドメディアやサービスサイトを1つ動かすことは、数字の上では可能です。ただし本番運用に持っていくなら、次の3つを確認してください。ひとつ目は、ロールが管理者と編集者の2種類しかないこと。承認者と執筆者を分けるといった運用は組めません。ふたつ目は、ワークフローが使えないこと。三つ目は、サポートがコミュニティとドキュメントのみで、問い合わせ窓口がないことです。公式のサポートページには、Free利用者はヘルプセンター、サポートポータル、開発者ポータル、Discordを利用でき、チケットの起票はLite以上の顧客が対象と書かれています。

見積もりを受け取ったら、まずどちらの軸の話をしているかを確かめてください。「Liteで月$300」と書かれていても、Spaceの追加が前提なら実際は$1,150/monthです。この確認をしないまま複数社の見積もりを並べても、比較にはなりません。

日本企業がContentfulで詰まりやすい点と、開発側が持つ範囲

ここまでが製品の中身です。最後に、当社が日本企業の開発体制を支援してきた立場から、実際に詰まる箇所と、その先にある「誰が何を持つのか」という話を書きます。詰まるのは機能の不足ではありません。海外製のSaaSであることに由来する、情報・通貨・上限の組み合わせ・担い手という4か所です。

日本語の情報量とサポート体制

まず情報量です。2026年9月15日時点で、Contentfulの公式ドキュメントとヘルプセンターは英語で提供されており、日本語版は確認できませんでした。公式サイトのフッターにある言語切り替えも English の表示のままです。つまり、料金の詳細、技術上限、ローカリゼーションの方式といった判断に必要な一次情報は、すべて英語で読むことになります。

この影響は、導入時より運用時に出ます。導入時は開発会社が読んでくれます。問題は、公開から2年後、担当者が交代したあとです。管理画面の操作で分からないことが出たとき、日本語で検索して出てくるのは個人ブログか制作会社の概説記事で、しかも料金プランの区分が古いまま残っているものが混じります。本記事の執筆時にも、現行と違う区分や価格で書かれた日本語記事を複数確認しました。

サポート体制もプランで分かれます。公式のサポートページによれば、無料利用者が使えるのはヘルプセンター、サポートポータル、開発者ポータル、Discordで、サポートへのチケット起票は Lite 以上の顧客が対象です。料金ページの記載では、Free がコミュニティサポート、Lite が標準の技術サポート、Enterprise が応答時間のSLA付きの優先サポートと専任のカスタマーサクセスマネージャーとなっています。日本語での問い合わせ可否と対応時間帯は公式ページでは確認できなかったため、商談の段階で直接確認することをお勧めします。

通貨と契約——USD建てで、日本円の表記はない

料金ページの表示はUSDのみで、日本円の価格表は用意されていません。本記事でも換算していないのはそのためです。稟議に上げる段階で、為替をどう置くか、消費税の扱いはどうなるか、請求は誰宛にどの通貨で来るのかを、決裁者が知りたがります。これは公式ページからは読み取れないので、Contentfulの営業か、国内のパートナー経由で確認する必要があります。

ここは日本製CMSとの現実的な差です。国内のサービスなら、日本円の価格表があり、適格請求書が出てきて、経理が迷いません。Contentfulを選ぶということは、その手間を受け入れるということです。多言語や複数ブランドという要件があるなら十分に見合いますが、要件がないのにこの手間だけ増えるのは、失敗のもとです。

Contentfulが過剰なケース

当社は表示側を実装する受注側なので、本来なら大きな構成を勧めたほうが売上になります。それでも、次のような案件にContentfulを勧めることはありません。

判断軸を1つに絞るなら、「Contentfulの道具立てのうち、いくつを実際に使うか」です。ロケールを2つ以上使い、環境を本番と検証で回し、配信先が2つ以上あるなら、価格に見合います。3つとも使わないなら、他の選択肢のほうが総額でも運用でも楽になります。

表示側の実装・移行・運用を誰が持つか——当社の体制

ヘッドレスCMSを選ぶと、表示側の実装・移行・運用という3つの仕事が発注側に残ります。この3つを誰が持つかを決めずに契約するのが、いちばんありがちな失敗です。

実装は、CMSから受け取ったデータを画面にする仕事です。デザイン、表示速度の設計(事前生成にするか都度取得にするか)、プレビュー環境の構築、そしてContent Preview APIとの接続。この設計次第で、前章で挙げたレート制限に当たるかどうかが決まります。

移行は、見積もりで最も過小評価されます。既存のWordPressやスプレッドシートにあるコンテンツを、新しいコンテンツタイプの形に合わせて入れ直す作業で、Content Management API を使った移行スクリプトを書くのが定石ですが、実際に時間を食うのはスクリプトではなく、既存データの表記ゆれの整理と、旧URLから新URLへのリダイレクト設計です。

運用は、公開後に続きます。コンテンツタイプの追加、表示の改修、Contentful側の仕様変更への追随、そして障害対応。サイトは公開して終わりではなく、公開後に動き続けます。だから当社は、仕様が動く前提のこの領域を準委任(ラボ型)で受けています。

当社はヘッドレスCMSを使ったWebサイト構築の開発実績があり、2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインする体制を取っています。協力会社を挟まないので、仲介マージンは発生しません。最小構成は日本人PMがフロントに立つ形で2〜3人月、月額約80万円から。1名から契約でき、最短2週間で開始、増員は約1週間、縮小や交代は1か月単位です。公開している単価は実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、5年で2,000USD、10年目安とブリッジSEで3,000USDです。当社調べで市場相場の約1/2にあたります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質の担保は3点。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。コンテンツモデルの設計レビューを日本人PMの工程に入れているのは、この部分の判断ミスが公開後にいちばん高くつくからです。実績としては、介護記録SaaSのCareViewerで日本語対応のブリッジSE1名とフルスタック2名の体制を組み、従来の半分以下のコストで週次の優先順位判断まで含めて回しています。

そのうえで繰り返しますが、Contentfulが過剰だと判断したときは、そうお伝えします。要件に対して道具が大きすぎる構成は、最初の見積もりが通っても、2年目の運用で必ず問題になります。相見積もりの取り方や評価軸そのものについては「システム開発会社の選び方」の記事にまとめてあるので、比較検討の段階ではそちらも参考にしてください。

Contentfulに関するよくある質問

最後に、Contentfulの採用を検討している事業側の方から実際によく届く質問を5つ挙げ、短く答えます。数値はいずれも2026年9月15日時点で公式サイトと公式ドキュメントを確認した内容です。

Q1. 無料プランのまま本番運用してもよいですか

技術的には動きますが、お勧めしません。ロールが管理者と編集者の2種類しかなく、ワークフローが使えず、サポートへの問い合わせ窓口もないためです。ロケールも2つまでです。検証用と割り切って使い、公開前に有料プランへ切り替える前提で進めるのが安全です。

Q2. 管理画面は日本語で使えますか

コンテンツ自体は日本語で入稿でき、ロケールとして ja-JP を設定できます。ただし2026年9月15日時点で、公式ドキュメントとヘルプセンターは英語での提供で、日本語版は確認できませんでした。入稿する人が英語のメニューを読む必要があるかどうかは、契約前にトライアルで実機を触って確かめてください。

Q3. 既存のWordPressから移行できますか

できます。公式ドキュメントも、Content Management API の用途としてWordPressやDrupalからの自動インポートを挙げています。ただし工数がかかるのは移行スクリプトそのものではなく、既存コンテンツの表記ゆれの整理、新しいコンテンツタイプへの割り当て、旧URLからのリダイレクト設計です。ページ数と既存データの整い方で工数が大きく変わるので、見積もり前に実データのサンプルを渡すのが確実です。

Q4. 開発はどれくらいの期間と体制で始められますか

当社の場合は、1名から契約でき、打ち合わせからアサインまで約1週間、候補者面談に約1週間で、最短2週間で開始できます。最小構成は日本人PMがフロントに立つ形で2〜3人月、月額約80万円からです。増員は約1週間、縮小や交代は1か月単位で対応します。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

Q5. Contentfulの利用料は誰が払うのですか

Contentfulとの契約は原則として発注者側が直接結び、CMS利用料は発注者の負担になります。開発会社が払うのは開発と運用の費用です。ここを曖昧にしたまま進めると、解約や移管のときに管理権限の所在でもめます。契約主体、支払い方法、組織の管理者権限を誰が持つかの3点を、着手前に文書で確定させておくこと。

まとめ: Contentfulの上限は「プラン」と「Space」の2軸で決まる——判断するのは言語数・配信先・モデル変更の頻度・表示側の保有者

Contentfulとは、コンテンツをスペースという単位で管理し、コンテンツタイプで構造を定義して、APIで複数の配信先へ届けるヘッドレスCMSです。設計の前提に多言語と複数チャネルがあり、ロケール(言語+地域)による4通りのローカライズ方式、本番を止めずにモデルを変えるための環境(environment)、5つのAPI——Content Delivery、Content Preview、Content Management、Images、GraphQL——が用意されています。2014年にモバイルアプリ向けのコンテンツ配信という着想から生まれ、2026年6月1日にSalesforceによる買収の合意が発表されました。

検討で最も誤解されるのが、上限が1本の軸では決まらないという点です。2026年9月15日時点の公式ページによると、Platformプランは Free($0)、Lite($300/month)、Enterprise(見積もり)の3区分で、ここで決まるのはユーザー数、ロール数、ロケール数(Freeは2、Liteは3)、APIコール数、配信帯域です。一方でコンテンツタイプ数・環境数・レコード数はSpaceの種類で決まり、全プランに付くStarter Spaceは25・2・10,000、追加購入できるLite Space($850/month・1つまで)は50・4・50,000です。$300/monthを払ってもStarter Spaceのままなら環境は2つのままである、という構造です。公式に日本円の表記はないため、本記事では換算していません。この領域は変更が入ることがあるので、最終判断の前に必ず公式の最新情報をご確認ください。

判断するのは4点だけです。言語とロケールはいくつ必要か。配信先はWebだけか、アプリやサイネージも含むか。コンテンツの構造を今後どれくらい作り替えるか。そして表示側を誰が持ち続けるのか。ロケールが1つ、配信先が1サイト、更新が年に数回であれば、Contentfulの道具立ての大半は使わずに終わります。その場合は他の選択肢のほうが総額でも運用でも楽になります。日本製のヘッドレスCMSとの比較検討をされているならmicroCMSとはを、そもそもサイト制作を外注する場合の費用の考え方はホームページ制作の外注費用をご覧ください。当社はヘッドレスCMSを使ったWebサイト構築の開発実績があり、表示側の実装、既存サイトからの移行、公開後の継続的な改善をラボ型(準委任)で担当しています。最小構成は日本人PMフロント+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、Contentfulが適しているかどうかを含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。