ヘッドレスCMS開発の発注は、業務要件を整理し、契約と費用を比べ、公開後の体制まで確認したうえで委託先を選ぶ流れで進みます。この順で進めると、公開後も運用しやすい基盤につながります。
▼全体ガイドの記事
・ヘッドレスCMS開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ヘッドレスCMS開発を外注する前に知っておきたい全体像
発注では、CMSの製品名を選ぶより前に、誰へ何を届けるのか、社内の誰が更新するのかを決めます。管理機能と表示サイトは別々に見積もられ、検索やフォーム、外部システムとの連携も、それぞれ独立した項目になるためです。
ヘッドレスCMSの仕組みと依頼する作業
ヘッドレスCMSは、コンテンツを登録するバックエンドと、利用者が目にするフロントエンドを切り離す仕組みです。
開発会社には、CMSの初期設定を任せるほか、コンテンツモデルと権限・承認フローを設計してもらいます。プレビューやAPI接続、画面実装も、同じ依頼の中に含まれます。さらに、公開環境の用意と監視、テスト、移行も依頼の対象です。
既存サイトを置き換える場合は、URLとSEO評価を保つリダイレクト設計も必要です。
ヘッドレスCMSの発注で業務要件まで伝える必要性
同じCMSを使う場合でも、構成と費用は業務の条件によって変わります。たとえば、更新頻度や編集者数、承認段階が違うと、必要な設計も異なってきます。配信先や検索方式、既存データの品質も、構成と費用を左右します。
コーポレートサイトだけであれば、SSGと基本的な入稿機能で足りる場合があります。一方で、Webサイトやアプリ、会員ページへ配信する場合は、API権限とキャッシュの設計が加わります。障害時の代替表示やデータの公開範囲も、設計の対象です。
技術用語だけで発注すると、公開直前に追加費用が発生しやすくなります。そのため、業務と運用の要件を委託先へ伝えることが大切です。
ヘッドレスCMSの発注形態の選び方
発注形態は、一括委託から部分委託、伴走型、内製化支援までに分かれます。選ぶときは、社内に技術者がいるかどうかに加えて、公開後にCMSやフロントエンドを誰が管理するかを見ます。
一括委託が向いている企業
一括委託は、CMSやWeb開発の専門担当者が社内に少なく、企画から公開までの窓口を一本化したい企業に向いています。そのため、会社間の調整コストも抑えやすくなります。
要件定義からCMSの選定、画面設計、品質保証、研修までを一社に任せられます。API実装やデータ移行、インフラ構築も、同じ会社にまとめられます。ただし、提案会社の得意なCMSや技術へ誘導される可能性があります。
一括委託であっても、RFPには複数の選択肢を提示する条件を入れておくと、製品や技術を比べられる形になります。
部分委託と伴走型の使い分け
社内にプロダクト責任者やフロントエンド担当者がいる場合は、CMS設定や移行、API連携などを分けて発注できます。部分委託では、費用と知識を社内に残しやすい一方で、どこまでを誰が受け持つかが曖昧だと、障害時の調査が進みません。
伴走型では、開発会社の作業範囲と、社内へ移管する成果物を先に決めておきます。コードレビューや研修の回数、質問対応の時間も、契約書や作業計画書に明記します。
SaaS・セルフホスト・スクラッチの選び方
SaaS、セルフホスト、スクラッチは、選択肢ごとに運用負担と自由度が異なります。自社の業務要件と、将来の引き継ぎやすさを照らし合わせて比べます。
- SaaS型：短期間で始めやすく、サーバーやCMS本体の更新を任せやすい形式。
- セルフホスト型：データの配置や拡張を制御できる一方、監視や更新は自社の責任になる。
- スクラッチ：独自の画面や複雑な業務ルールに対応しやすいが、保守要員が必要になる。
セルフホスト型やオープンソースを選ぶと、バックアップと脆弱性対応も自社側に残ります。スクラッチでは、自由度の対価として、将来の移行コストも自社が負担することになります。
目先の安さだけで決めず、5年後に担当会社を変えても、データとコードを引き継げるかを確かめます。
RFPと要件整理の準備範囲
RFPは、完成した仕様書でなくても構いません。発注側の目的や制約、優先順位と、開発会社に提案してほしい範囲を揃えるためのものです。
データ構造やAPI設計は、画面の見た目からは読み取りにくいものです。そのため、業務とコンテンツの流れも言葉にして渡します。
RFPに書く最低限の項目
RFPには現状の課題と対象範囲を書き、各社が同じ条件で提案できるようにします。目的と範囲は、次の情報を軸に整理します。
- 目的：表示速度、更新時間、複数チャネルの利用、サイト統合、セキュリティの課題。
- 対象：サイト数、ページ数、コンテンツの種類、言語、公開頻度、既存CMS。
- 運用：編集者と承認者の人数、移行の対象、外部サービス、会員情報や個人情報の有無。
- 制約：公開時期、予算の考え方、社内体制、デザインガイド、問い合わせ窓口。
- 要件区分：公開日までの必須機能と、第2段階に回す希望機能。
記事入稿とプレビュー、権限管理は、必須要件の例です。301リダイレクトも、必須要件の例に入ります。多言語対応やAIによる下書き支援は、第2段階に分けておくと、見積もりを比べやすくなります。
開発会社には、CMS候補と前提条件を回答してもらいます。対象外の範囲や、追加費用が発生する条件も示してもらいます。
コンテンツモデルと編集フローの整理
コンテンツと編集の設計では、再利用する単位と、配信先ごとの入力項目を整理します。担当者と管理条件も、あわせて定めます。
- コンテンツ単位：記事、著者、カテゴリ、店舗、商品、FAQ、キャンペーンの定義。
- 配信先と項目：画面やアプリが取得するAPIと、タイトル、概要、本文、画像、公開日時、関連コンテンツ。
- SEO項目：description、canonical、OGP画像を、編集画面で入力できるようにする。
- 編集の役割：下書き、校正、公開を担う人の割り振り。
- 管理条件：権限、承認段階、退職者のアカウント停止、監査ログの保存期間の取り決め。
複数の部署で同じCMSを使う場合は、これらの条件を要件に含めておきます。
個人情報を扱う場合は、契約の前に、委託先と再委託先の監督、データの保管場所、アクセス記録を確かめておきます。
PoCと受け入れ基準の決め方
仕様が定まらない要件は、本開発の前に代表的な3〜5ページでPoCを行い、運用を試して確かめます。
- 操作確認：入稿からプレビュー、公開、検索、フォーム、外部API連携、権限変更まで、実際に動かして試す。
- 編集のしやすさ：編集者が迷わず更新できるかどうか。
- PoCの契約条件：無料の提案に含めるか、有償の要件定義にするかを、はっきりさせておく。
- 受け入れ基準：主要ブラウザ、表示速度、APIエラー処理、権限別のアクセス。
- 移行と復旧：データの件数と品質、301リダイレクト、サイトマップ、復旧手順の取り決め。
PoCの料金条件は会社ごとに違うため、発注前に確かめておきます。
テスト項目と判定する人を先に合意しておき、動いても運用できない状態を避けます。
ヘッドレスCMS開発の契約形態の選び方
契約形態は、要件がすでに固まっているか、開発中に仕様が変わりそうかで選びます。編集画面を試して初めて、運用上の不都合が見つかることもあります。
全工程を一つの契約で固定するよりも、要件定義と開発を分けて契約する方法が適しています。
請負契約が向いている場合
請負契約は、納品物や範囲、期限、検収条件が明確な工程に向いています。たとえば、合意済みの画面やCMS設定が成果物になります。API仕様や移行スクリプト、テスト結果も、成果物として扱えます。
完成の責任を委託先に持たせやすい一方で、大きな仕様変更があれば、変更契約や追加費用が発生します。要件が曖昧なまま契約すると、完成像の食い違いがそのままトラブルになります。
準委任契約と時間単価契約の使い方
準委任契約と時間単価契約は、要件定義や技術検証、伴走支援のように、作業内容を協議しながら進める工程で使います。アジャイル開発にも適しています。
月ごとの稼働時間や担当者、作業報告を決めておきます。定例会議と成果物の扱いも、あわせて定めます。発注側も、優先順位をすばやく判断します。
時間を使ったことだけで評価しないよう、月ごとに到達目標と検証結果を報告してもらいます。残課題と次月の計画も示してもらいます。
契約書で確認する知的財産権と保守条件
契約書では、成果物の権利と引き渡し、保守の対応範囲を整理します。
- 成果物：ソースコード、デザイン、移行スクリプト、設計書、テスト仕様書、CI/CD・インフラ設定それぞれの権利と引き渡し範囲。
- ライセンス：オープンソース、外部サービス、CMS利用契約、再利用する共通部品の扱い。
- 管理権限：管理者アカウント、APIキー、ドメイン、クラウド契約は、発注側の管理下に置く。
- 保守条件：受付時間や障害の重要度、初動時間、復旧目標、セキュリティパッチ、CMSとフレームワークの更新、バックアップ、監視、追加開発の単価。
CMSがSaaSであっても、フロントエンドやAPI連携が止まれば、サイトは表示できなくなります。そのため、SaaSのサポートと開発会社の保守を分けて、それぞれの対応範囲を明確にします。
ヘッドレスCMS開発の費用相場とコストの内訳
費用は、CMS利用料と開発会社への委託費に分けて考えます。CMSの公式料金は、プランごとにユーザー数やAPI回数などの条件で変わります。データ転送量や環境数、サポートも、料金の条件になります。
ここで示す開発費は、リサーチノートに記載された要件別の推定レンジです。CMSごとに一律で決まる価格ではありません。
CMSの利用料の目安
2026年8月時点の公式料金例では、microCMS Businessが月額75,000円（税抜）です。
Businessの料金は、2025年6月の改定後のものです（出典: microCMS公式「料金プランの価格改定／統合のお知らせ」、2025年）。
Advancedは月額180,000円（税抜）です（出典: microCMS公式「料金プランの価格改定／統合のお知らせ」、2025年）。
ただし、Advancedは新規申込を終了する方針が示されています。契約時にはプランを確認します（出典: microCMS公式「料金プランの価格改定／統合のお知らせ」、2025年）。
- Contentful Lite：月額300ドル。
- Sanity Growth：1席あたり月額15ドル。専用サポートや追加クォータは別料金です。
- Strapi Community：MITライセンスのオープンソースで、ソフトウェアの料金は無料です。
- Strapi Growth：月額45ドルと案内されています（出典: Strapi公式CMS Pricing、2026年8月確認）。
このプランには、1か月あたり100万API callsや100GBのCDN帯域などが含まれます（出典: Contentful公式Pricing、2026年8月確認）。
Strapiをセルフホストする場合は、サーバーと監視が別途必要になります。バックアップや更新対応の作業も、別に見込む必要があります。無料プランでも、運用の総額まで無料になるとは限りません。
開発・移行・連携の費用相場
ページ数や連携機能が増えると、開発費は上がりやすくなります。そのため、規模ごとの金額と期間を確認します。
- 小規模：コーポレートサイトやメディアの5〜20ページで、基本的なSEOと少量のデータの場合。導入・開発費は100万〜300万円、1〜3カ月程度。
- 中規模：50〜300ページの移行に、検索、フォーム、権限・承認、外部API連携が加わる場合。300万〜800万円、3〜6カ月程度。
- 大規模：複数サイトやアプリ、多言語、会員・商品・基幹連携、監査要件がある場合。800万〜2,000万円以上、6〜12カ月以上。
いずれも要件の差が大きい推定レンジです。既存CMSからの移行では、50万〜300万円程度を追加で計上することがあります。
移行の工数は、記事数だけでは決まりません。HTMLの崩れや画像の扱い、著者・カテゴリの再設計も、工数を左右します。さらに、URLの維持や301リダイレクト、公開前後の差分検査も影響します。
API連携やWebhook、外部検索は、連携先1つあたり30万〜150万円程度が目安です。会員・商品データの連携も、同じ目安で見ます。認証方式やエラー処理、テスト範囲は、別の項目として見積もります。
5年間のTCOで比べる費用
初期の開発費だけでなく、5年間のTCO（総所有コスト）を計算します。継続費用は、年ごとに並べて比べます。
- 基盤費：CMS利用料、クラウド、CDN、ドメイン、証明書。
- 運用費：監視、バックアップ、脆弱性対応、追加開発。
- 移行・社内費：コンテンツ移行、編集者研修、社内運用の工数。
- SaaSの変動：インフラ運用は減らせる一方で、席数やAPI回数、データ転送量が増えると、料金が上がる場合があります。
- セルフホストの工数：保守担当者の作業を予算に入れないと、比較を誤ります。
サービスの継続性も、TCOに含めて考えます。たとえば、Newtは2026年11月24日13時59分に、管理画面とAPIを含む全サービスを終了する予定と案内しています。
終了後のデータ削除も告知されています（出典: Newt公式「サービス終了についてのよくあるご質問」、2026年確認）。そのため、データの一括エクスポートやAPI仕様の文書化、代替CMSへの移行手順を確認しておきます。
移行手順を用意し、将来の費用が見えないリスクにならないようにすることが大切です。
ヘッドレスCMSの委託先の選び方
委託先は、CMSの導入実績だけでなく、要件定義から運用保守までの責任範囲で選びます。公式パートナーであることも判断材料ですが、自社業務との適合は別に確認します。
過去事例では、ページ数や規模、移行データの量を見ます。API連携の種類や公開後の体制も、あわせて見ます。そのうえで、自社と似た条件の実績があるかを確かめます。
導入実績の確認項目
導入経験は、自社に近い規模や運用の事例で確かめます。質問の軸をそろえておくと、事例の適合性を比べられます。
- 移行規模：何ページを何人の体制で扱ったか。
- 編集体制：担当者の数と、権限・承認の設計。
- 技術選定：SSR、SSG、ISRのうち、採用したもの。
- 運用実績：API障害時の表示の仕方と、公開後の保守年数。
遠州鉄道の公式導入事例では、20サイト・約300店舗の情報発信基盤を整備しました。
同じ事例では、スクラッチ開発と比べて、サイトリプレイスの開発工数を10分の1程度にできたと紹介されています（出典: microCMS公式「遠州鉄道株式会社 導入事例」、2026年確認）。
この事例を読むときは、効果だけでなく前提条件も確かめます。
技術力と運用支援の確認範囲
技術提案は、フロントエンド、バックエンド、APIのセキュリティに分けて確認します。そのうえで、構成の理由を業務要件と結び付けて説明できるかを見ます。
- フロントエンド：Next.js、Astro、Nuxtの選択理由、SSR・SSG・ISR、CDNキャッシュ、プレビュー、フォーム、検索、画像最適化。
- バックエンド：API認証、権限、Webhook、レート制限、ログ、バックアップ、エラー通知。
- APIの保護：APIキーをブラウザに埋め込まず、公開APIと管理APIを分けて、過剰な公開を防ぐ。
更新頻度や会員情報の有無を踏まえて、構成の理由を説明できる会社を選びます。APIでは、レート制限と監視も基本です。
OWASP API Security Top 10は、APIに関するリスクを整理しています。
そこでは、認可の不備やセキュリティ設定の不備が挙げられています。さらに、APIインベントリ管理の不備や、外部APIの安全でない利用も含まれます（出典: OWASP API Security Top 10、2023年版）。
RFPには、これらの対策とテスト方法を回答してもらう項目を入れておきます。
公開後の体制と担当者の継続性
確認するのは、営業担当者ではなく、要件定義から保守までを担うメンバーです。責任者と欠員時の代替要員を把握します。問い合わせへの返答時間や、障害時の意思決定者も確かめます。
担当会社が変わる場合に備えて、設計書やリポジトリ、CI/CDの管理を発注側に残しておきます。クラウドやドメイン、CMS管理者の名義も、発注側で管理できる体制にします。
ヘッドレスCMSの見積書の比較ポイント
見積書は、成果物と前提条件をそろえて比べます。合計額は、その土台がそろってから見ます。また、「開発費」に含まれる範囲は会社によって異なり、移行や研修が別料金になることもあります。
金額が低い見積もりほど、対象外の範囲と前提を丁寧に確認します。追加単価や保守の開始時期も、あわせて見ておきます。
見積項目を分ける単位
設計から公開後の運用まで、段階ごとに分けて比べます。
- 設計：要件定義、CMS選定、情報設計、コンテンツモデル。
- 構築：デザイン、フロントエンド、CMS設定、API・外部サービス連携。
- 公開準備：インフラ、コンテンツとSEOの移行、テスト、研修、公開作業。
- 運用：CMS利用料、クラウド費、保守。
各項目には、作業内容と数量、担当者を添えてもらいます。さらに、成果物や期間、前提、対象外も明記してもらいます。
「API連携一式」とだけ書かれていると、認証やデータ変換、失敗時の再送、監視、テストが含まれるかが読み取れません。
CMS利用料やクラウド費は、初年度だけでなく2年目以降の単価も確認します。APIリクエストや席数、メディア容量が条件に含まれるかを見ます。CDN転送量や環境数、ログ保持期間の条件も、同じように見ます。
為替、最低契約期間、解約時のデータ取得費も確認します。公式料金と開発会社の提示額が異なる場合は、再販手数料、サポート費、請求代行費を分けて説明してもらいます。
相見積もりで価格以外に比べる点
価格以外では、要件の理解度や質問の内容、前提、実装から移行、運用までの範囲を見ます。
- 提案の適合性：目的と実装範囲、編集者の使いやすさ。
- 移行と運用：計画の内容、SEOの維持、セキュリティ、障害対応。
- 継続性：データの持ち出し、社内への引き継ぎ、5年間のTCO。
移行対象が少なめに見積もられていたり、保守が含まれていなかったりすると、後から追加費用が発生することがあります。
要件定義やPoCは、不確実さを減らす工程として見積もりに含まれる場合があります。
各社には同じ質問をして、回答の具体性やリスクの説明の仕方を記録しておきます。
提案書に「想定外」と書かれた項目は、契約後にもめやすい部分です。そのため、発注前に追加の見積もりを取っておきます。
発注前に避けたい見積もりの特徴
成果物や対象外が曖昧な見積もりでは、追加費用や運用上のリスクを判断しにくくなります。
- 一式表記：成果物や対象外がなく、内容を比較できない。
- 曖昧な約束：「最短で公開」「すべて対応」と書かれていても、移行件数、テスト、研修、保守条件が不明。
- 要件確認の不足：編集業務や既存データを質問せず、CMS機能だけを説明する。
- 危険な構成：APIキーの埋め込み、管理APIの公開、バックアップやロールバックの欠如。
- 管理と納期：個人名義のクラウド契約、根拠のない短納期や固定価格。
動くことと、安全に運用できることは別です。判断が難しい部分は、第三者のセキュリティレビューや有償のPoCを使って確かめます。
よくある質問
発注や外注に関する疑問をまとめました。自社の要件や契約条件に合わせ、RFPや見積もりの比較で確認する項目として活用してください。
ヘッドレスCMSの開発費は最低いくらから発注できますか？
ページ数が少ない小規模サイトで、基本的なCMS設定とフロントエンド実装に絞る場合、リサーチノート上の推定では100万〜300万円程度が目安です。
一律の相場はなく、デザインや移行、フォームを含むかで金額は変わります。検索やSEO、研修、保守の扱いも、金額を左右します。安さだけで決めず、見積もりに含まれない作業を確認します。
WordPressからヘッドレスCMSへ移行する場合、何を外注しますか？
移行対象を洗い出すことや、コンテンツモデルの再設計、記事と画像の変換を外注できます。URL維持や301リダイレクトも、外注の範囲に含められます。canonicalやサイトマップ、公開前後の差分検査も対象です。
既存プラグインやカスタムフィールドの業務を、CMSや外部サービスでどう再現するかを決めます。記事数と画像数を示すと、見積もりが安定します。さらに、移行の方式と手作業の範囲も伝えておくと役立ちます。
公開後は自社だけでヘッドレスCMSを運用できますか？
CMSへの入稿や承認は自社で運用できます。フロントエンドやAPIを担えるかは、社内体制によります。インフラや監視、セキュリティ更新も、社内の体制次第です。
発注時に編集者研修や運用マニュアルを含めておくと、内製化を進めやすくなります。障害時の連絡先や、コードとクラウドの引き渡しも、あわせて含めておきます。
専門知識が足りない場合は、月次保守やスポット対応を残しながら、担当範囲を段階的に移していきます。
ベンダーロックインを避けるために何を確認しますか？
データをJSONやCSVで出力できるか、API仕様とコンテンツモデルを文書にまとめられるかを確かめます。ソースコードとインフラ設定の引き渡しも、あわせて見ます。
契約終了後のデータ削除や取得期限も確かめます。SaaSの終了や料金改定は完全には避けられないため、PoCで移行手順を試し、5年後に別のCMSへ移れる設計を契約条件に含めます。
まとめ
発注前に確認すること
発注前には、目的と必須要件を決めて、現行のコンテンツと運用フローを洗い出します。RFPでは、委託先に提案してほしい範囲と、発注側が判断する範囲を分けて示します。
各社に同じ条件を示しておくと、見積もりを比べやすくなります。
公開後を見据えた委託先の選び方
公開後は、コンテンツ更新やAPI、フロントエンドを継続して管理します。インフラやセキュリティも、その対象に含まれます。引き継ぎと障害対応の条件は、発注前に確かめておきます。
- 責任分担：社内に技術者が少ない場合は一括委託、いる場合は部分委託や伴走型が候補になります。
- RFP：目的や対象範囲、必須と希望の要件、ページ数、連携先、移行対象、公開時期、運用体制を、各社へ示す文書。
- 契約：成果物、検収、変更管理、知的財産権、アカウント管理、保守、障害対応、データ出力の取り決め。
- 費用：CMS利用料、開発費、移行費、インフラ費、保守費を分けたうえで、5年間のTCOと継続性を比べる。
- 引き継ぎ：データとコードを渡す契約、障害時の連絡体制。
製品名や初期費用だけで決めず、コンテンツモデルや編集フロー、フロントエンド、API連携を一体で整理します。移行やSEO、セキュリティ、保守も、同じ流れで見ておきます。
ヘッドレスCMSは、設計次第で、Webサイトやアプリ、会員ページへコンテンツを再利用しやすくなります。そのため、長期的な運用の改善にもつながります。
成果は、開発会社の提案力や公開後の体制によっても変わります。だからこそ、業務と将来の運用を理解し、移行やセキュリティ、引き継ぎまで説明できる委託先を選ぶことが大切です。
▼全体ガイドの記事
・ヘッドレスCMS開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。