microCMSのシステムを発注・外注するなら、CMS利用料だけで判断せず、コンテンツ設計、フロントエンド開発、外部連携、移行、保守までを一つの業務要件として見積もることが重要です。
microCMSは管理画面と表示部分を分離したヘッドレスCMSです。自社に合う発注形態の選び方、RFPと要件の整理方法、契約形態、費用相場、委託先の選定、見積比較のポイントを、発注前に確認したい順番で解説します。
▼全体ガイドの記事
・microCMSのシステム開発の完全ガイド
microCMSのシステムを発注する前に知っておきたい全体像

発注前に最初に整理したいのは、「microCMSに何を任せ、開発会社に何を作ってもらい、既存の業務システムに何を残すか」です。microCMSはコンテンツを管理・配信する基盤であり、サイト全体の画面や業務処理まで自動的に完成させるサービスではありません。
microCMSが担う範囲と開発会社が担う範囲
microCMSでは、ニュース、ブログ記事、商品、施設、FAQ、採用情報などのコンテンツを、編集画面から登録できます。カスタムフィールド、コンテンツ参照、予約投稿、レビュー、ワークフロー、メンバー・ロール管理などを使い、更新担当者が運用しやすいデータ構造を設計できます。Content APIで取得したデータは、Next.js、Nuxt.js、Astro、React、Vueなどで作るフロントエンドへ渡されます。
一方、画面デザイン、URL設計、検索、フォーム、認証、外部データベースとの連携、ホスティング、監視、テスト、コンテンツ移行は、別途設計・開発が必要です。発注書に「microCMS導入一式」とだけ書くと、どこまでが納品物か分からなくなります。CMS設定、フロントエンド、インフラ、移行、運用設計を分けて記載することが、後からの追加請求や認識違いを減らします。
向いている業務と、microCMSに残さない業務
microCMSに向いているのは、複数の担当者が更新するコーポレートサイト、オウンドメディア、自治体や金融機関の情報発信、複数ブランド・複数拠点のサイト、商品・施設情報の一元管理です。Webサイトだけでなく、アプリやデジタルサイネージへ同じコンテンツを配信したい場合にも適しています。
反対に、受注、在庫引当、請求、会計、複雑な会員認証、決済、個人情報を使う基幹処理をmicroCMSだけで完結させる設計は避けます。正データを既存の業務システムや専用データベースに残し、microCMSには公開用の情報だけを連携する構成が安全です。発注時には「CMS化する業務」と「業務システムに残す業務」を一覧にし、連携方式とデータの責任範囲を確認します。
microCMSのシステム発注・外注形態はどれを選ぶべきですか?

結論から言うと、社内にフロントエンドとインフラの担当者がいない場合は、要件定義から開発・移行・保守までを一括して相談できる会社への外注が進めやすいです。ただし、業務要件や運用方針まで丸投げすると、完成後に社内で使えないCMSになりやすいため、発注側が決める事項を先に分けておきます。
一括外注は、担当者不足と複数工程をまとめたい企業向けです
一括外注では、企画、情報設計、microCMSのAPI・フィールド設計、画面開発、インフラ、移行、テスト、リリース後の保守を一つの会社または責任者にまとめて依頼します。社内に技術者が少なくても進めやすく、障害時の問い合わせ先も一本化できます。複数ブランド、会員向け情報、検索、外部APIなどがある場合は、工程間の引き継ぎ漏れを防ぎやすい点がメリットです。
一括外注の注意点は、提案内容を比較しにくく、不要な開発まで含まれやすいことです。見積書には、要件定義、デザイン、CMS設定、フロントエンド、移行、試験、公開、保守を項目別に分けてもらいます。ソースコード、インフラ設定、API仕様書、操作マニュアル、デザインデータの納品条件も契約前に確認します。
部分外注は、社内に設計または開発の担当者がいる企業向けです
社内でコンテンツ設計と運用を決められる場合は、フロントエンド実装だけ、既存CMSからの移行だけ、API連携だけを外注できます。既製テンプレートを使い、デザインや原稿を社内で用意する方式も、初期費用を抑える選択肢です。逆に、API設計やインフラの経験がない状態で実装だけを外注すると、公開後の改修を自社で続けられない可能性があります。
部分外注では、担当範囲の境界を文章にします。たとえば「microCMSのAPI設定は発注先、原稿の移行元データの整形は自社、移行スクリプトの実行と検証は発注先」と明記します。作業の前提となるアカウント、素材、データ形式、レビュー担当者を決めると、工程が止まりにくくなります。
PoCから始める方式は、要件や運用を検証したい企業向けです
microCMSを初めて使う場合は、いきなり全サイトを移行せず、代表的な記事やニュースだけでPoCを行います。HobbyやTeamの環境で、編集者が入力しやすいか、プレビューやレビューが機能するか、APIで想定した画面を表示できるかを確認します。PoCの目的は安く作ることではなく、本番で変更しにくいデータ構造を早く見つけることです。
PoCの成果物には、画面の試作だけでなく、コンテンツモデル案、権限設計、移行件数のサンプル、運用フロー、残課題、正式版の概算見積を含めます。PoC後に本開発を同じ会社へ発注する場合でも、何が検証済みで、何が未確定なのかを整理してから契約することが大切です。
microCMSのシステム発注を成功させる要件整理とRFPの作り方

RFPは、開発会社へ提案を依頼するための資料です。機能一覧だけではなく、なぜ作るのか、誰が使うのか、いつまでに何を公開するのか、現行サイトにどの課題があるのかを記載します。候補会社が同じ条件で提案できるように、必須要件と希望要件、発注側が準備するものを分けておくことがポイントです。
RFPに最低限書くべき項目
目的とKPIには、更新時間の短縮、公開までの承認時間、表示速度、問い合わせ増加など、達成したい状態を書きます。対象範囲には、サイト数、ページ数、コンテンツ種別、対応言語、スマートフォン対応、検索、フォーム、会員機能、外部サービス連携を記載します。既存サイトがある場合は、URL一覧、記事数、画像数、公開終了データ、リダイレクトの有無、移行が難しいコンテンツを整理します。
運用要件には、編集者・承認者・管理者の人数と役割、レビューの有無、予約投稿、緊急公開、更新履歴、バックアップ、問い合わせ窓口を含めます。非機能要件には、アクセス集中時の性能、障害時の復旧目標、監視、脆弱性対応、アクセシビリティ、個人情報の取り扱い、ソースコードの管理を含めます。これらを省略すると、会社ごとに前提が変わり、金額だけを比べる不正確な相見積もりになります。
コンテンツモデルとAPI連携を発注条件に含める
microCMSでは、APIの数やフィールドの切り方が運用性を左右します。たとえば「お知らせ」を一つの長い本文に詰め込むのか、タイトル、概要、公開日、カテゴリー、関連リンク、画像、対象拠点に分けるのかで、検索や一覧表示の作りやすさが変わります。RFPには、主要コンテンツの入力例を2〜3件添え、一覧、詳細、関連コンテンツ、下書き、予約公開の表示イメージを示します。
外部連携では、どちらが正データを持つか、更新を即時に反映するか、バッチで反映するか、失敗時に再送できるかを決めます。Webhook、マネジメントAPI、専用の連携サーバーなどの候補を示し、個人情報をmicroCMSへ複製する必要があるかも検討します。API仕様書、エラー時の処理、テスト用データ、連携先の担当者まで発注条件に含めると、開発会社の提案を比較しやすくなります。
microCMSのシステム開発を発注する進め方

microCMSの外注は、要件定義、設計・開発、移行・テスト、リリース・運用の順に進めます。各工程で発注側が確認する成果物を決めておくと、完成間際に大きな仕様変更が発生しにくくなります。
要件定義・企画フェーズで決めること
最初に、現行サイトと業務の棚卸しを行います。更新担当者へのヒアリングでは、「今どの画面で困っているか」だけでなく、「誰の承認が必要か」「公開を急ぐ情報は何か」「月に何本更新するか」まで確認します。サイトマップ、コンテンツ一覧、権限表、外部連携一覧、移行対象表を成果物にすると、後工程の判断材料になります。
この段階で、microCMSを使わない範囲も決めます。会員情報や注文データをCMSに保存しない、決済は専門サービスに任せる、検索は専用エンジンを使う、といった境界を定義します。発注側の責任者、現場の編集者、法務・情報システムの確認者を決め、意思決定の期限を設定することも重要です。
設計・開発フェーズで確認すること
設計では、コンテンツモデル、API、URL、画面、権限、公開フロー、ホスティングを決めます。フロントエンドはNext.js、Nuxt.js、Astroなどの候補から、社内の保守体制、表示速度、サーバーサイドレンダリング、検索、将来のアプリ連携を踏まえて選びます。技術名だけで決めず、なぜその構成が自社に適するのかを提案書で説明してもらいます。
セキュリティ設計では、APIキーの扱いを必ず確認します。microCMS公式ドキュメントでは、APIキーにGETやPOST、PUT、PATCH、DELETEなどの権限を設定でき、APIキーがクライアント側に露出するCSRでは、外部から呼び出されるリスクが説明されています。公開情報は必要最低限のGET権限に絞り、書き込み権限を持つキーはサーバー側で管理する設計を受入条件にします(出典:microCMS「APIキー(APIの認証と権限管理)」、2026年6月更新)。
移行・テスト・リリースフェーズで確認すること
既存サイトからの移行では、件数だけでなく、本文のHTML、画像、公開日、カテゴリー、著者、関連リンク、検索結果、リダイレクトを確認します。まず少量のサンプル移行を行い、文字化け、画像欠落、リンク切れ、見出し構造の崩れ、公開状態の誤りをチェックします。その後に全件移行し、発注側の担当者が実際に検索・編集・公開できるかを確認します。
テストでは、正常系だけでなく、権限のない人が管理画面に入れないか、下書きが公開画面に出ないか、API連携が失敗したときに再処理できるか、アクセス集中時に表示できるかを確認します。リリース判定には、重大な不具合ゼロ、移行件数の照合、バックアップと復旧手順、運用マニュアル、緊急連絡先を含めます。公開後の初期監視期間と、瑕疵対応の期限も契約に記載します。
microCMSの発注で選ぶ契約形態と責任分担

契約形態は、要件の確定度と発注側がどこまで開発を管理できるかで選びます。microCMSの導入では、要件定義は準委任、設計・実装は請負、公開後の改善は月額の準委任というように、工程ごとに分ける方法が現実的です。すべてを一つの契約にまとめる場合でも、成果物と検収条件を明確にします。
準委任契約は、要件を一緒に整理しながら進める場合に適しています
準委任契約では、開発会社の専門知識や稼働時間を使い、要件定義、技術調査、伴走型の設計、運用改善を進めます。新しいサイト構成で何をCMSに持たせるか決まっていない場合や、既存システムとの連携方法を検証したい場合に向いています。作業時間、担当者、定例会、成果物、報告方法、追加作業の承認方法を契約書に入れます。
準委任では、完成したサイトそのものを納品する契約とは限りません。発注側は、週次で課題と判断事項を確認し、優先順位を決める必要があります。作業時間だけを消化する契約にしないため、API仕様書、画面一覧、課題管理表、検証結果など、工程ごとの成果を定例で確認します。
請負契約は、成果物と仕様が固まった開発に適しています
請負契約では、合意した仕様に基づくサイト、機能、移行スクリプト、ドキュメントなどを成果物として納品し、検収します。画面数、API数、対応ブラウザ、移行対象、テスト範囲、納品形式、検収期限、不具合の扱いを具体化することが必要です。「CMS導入」「レスポンシブ対応」「検索機能」のような抽象的な表現だけでは、完成条件を判断できません。
請負で進める場合は、仕様変更の手続きを決めます。新しい外部連携、移行件数の増加、公開日変更、デザインの大幅な変更などが発生したら、追加費用と納期への影響を文書で確認します。変更を無制限に受ける見積は一見安く見えても、品質と納期を守れなくなるため、変更管理のルールまで含めて比較します。
保守契約は、対応範囲と時間帯を分けて決めます
公開後は、microCMSの設定変更、フロントエンドの依存ライブラリ更新、障害対応、脆弱性対応、軽微な画面改修、コンテンツ更新代行などが発生します。保守契約では、月額に含む作業、別途見積もる作業、受付時間、一次回答の期限、復旧目標、連絡方法、再委託の有無を確認します。
個人情報を扱う場合は、委託先の選定、秘密保持、アクセス権、再委託、削除・返却、監査、漏えい時の報告を契約へ落とし込みます。個人情報保護委員会のガイドラインでも、委託先の安全管理措置の確認や、再委託先の取り扱いを把握することが示されています(出典:個人情報保護委員会「個人情報保護法ガイドライン(通則編)」、2025年確認)。認証情報を開発会社へ渡す場合も、個人アカウントの共有ではなく、役割と期限を限定したアカウントを用意します。
microCMSのシステム発注費用・相場とコストの内訳

microCMSの費用は、サービス利用料と開発委託費を分けて考えます。公式の利用料金は比較的確認しやすい一方、開発費はサイト数、画面数、移行量、デザイン、外部連携、非機能要件で変わります。以下の開発費レンジはmicroCMS公式の一律価格ではなく、リサーチノートに基づく発注前の仮置きです。実際の予算は、RFPを渡して提案と見積を取得してください。
microCMSの利用料金はプランと従量課金を確認します
2026年8月に公式料金ページを確認した時点では、Hobbyは0円/月、Teamは4,900円〜/月、Businessは75,000円〜/月、Enterpriseは個別見積もりです。Teamはデータ転送量200GB/月を基準に超過分が20円/GB、Businessは1TB/月を基準に超過分が18円/GBです。メンバー追加は1人1,200円、API追加は1個2,000円が示されています(出典:microCMS「料金プラン」、2026年8月確認)。
HobbyはAPIが5個、コンテンツ数が1万件までで、小規模な検証に向いています。Businessでは権限管理、IP制限、複数環境管理、技術サポートなどが使え、Enterpriseでは監査ログ、SAMLによるシングルサインオン、SLA、2要素認証の必須化、専任担当者によるサポートなどを個別に相談できます。2025年6月10日に料金改定が行われ、Advancedの新規申し込みが終了しているため、古い記事の料金を根拠に予算を組まないようにします。
開発委託費は規模別のレンジで仮置きします
小規模なコーポレートサイトやブログ1サイトで、デザイン、フロントエンド、API設定、公開環境、操作説明を含む場合は、150万〜400万円程度、期間は1〜3か月が発注前の仮置きになります。中規模のメディアや会員向け情報サイトで、複数のコンテンツモデル、検索、レビュー、移行、分析、外部API連携を含む場合は、400万〜1,200万円程度、期間は3〜6か月が目安です。
複数ブランド・複数拠点、金融・自治体などの厳格な非機能要件、既存業務システム連携、アクセシビリティ試験、負荷試験、脆弱性診断を含む場合は、1,000万〜3,000万円以上、期間は6〜12か月のレンジを仮置きします。公開情報をもとにした推定であり、microCMS公式の制作料金ではありません。移行データの品質や承認者の人数で変動するため、金額だけでなく前提条件を比較します。
保守・インフラ・移行費を初期費用と分けます
見積書では、microCMS利用料、ホスティング、ドメイン、監視、メール配信、検索サービスなどの月額費用を開発委託費から分けます。さらに、移行データの整形、画像の差し替え、リダイレクト、原稿の確認、公開後の更新代行を別項目にします。保守・改善は、初期開発費の年15〜25%程度、または月15万〜80万円程度を仮置きできますが、対応時間や作業量を含めて比較する必要があります。
安い初期見積でも、公開後の障害対応やライブラリ更新が都度課金だと、3年間の総額が高くなる場合があります。反対に、高額な保守契約でも、コンテンツ更新代行が含まれず、軽微な修正の定義が曖昧なことがあります。初期費用、月額費用、従量課金、移行費、保守費、改善費を合わせた3年総額で比較します。
microCMSの委託先選定と見積比較のポイント

委託先は、microCMSを使った実績の数だけでなく、似た課題をどう解決したかで選びます。公式パートナーであることは候補を探す材料になりますが、自社と同じ規模・業種・運用体制で成果を出せる保証ではありません。提案時には、実績の画面だけでなく、コンテンツモデル、技術スタック、移行件数、権限、保守体制を確認します。
実績は技術名より運用の再現性を確認します
確認したい実績は、単に「microCMSを導入した」という記載ではありません。何サイトを統合したのか、何人が更新するのか、既存CMSから何件を移行したのか、どのプランを使ったのか、外部APIやサイネージと連携したのかを質問します。担当したディレクター、設計者、フロントエンド担当者が今回も参加するのか、公開後の窓口が誰なのかも確認します。
microCMS公式の遠州鉄道の導入事例では、グループの約50サイトのうち20サイトで導入し、約300店舗がコンテンツを更新し、サイネージにも連携しています。サイトリプレイスの実装工数をスクラッチ開発と比べて10分の1程度に削減した事例です(出典:microCMS「遠州鉄道株式会社様 導入事例」、2025年公開・2026年更新)。複数サイトや多人数運用を検討する企業は、このように自社に近い運用実績を探します。
見積書は工程・前提・除外項目を横並びにします
見積比較では、合計金額の前に、要件定義、情報設計、デザイン、microCMS設定、フロントエンド、外部連携、移行、インフラ、テスト、公開、マニュアル、保守の金額と工数を横並びにします。各項目の担当者、回数、成果物、検収条件、含まれない作業も記載してもらいます。見積書に「一式」が多い場合は、作業分解を依頼します。
提案の比較では、金額だけでなく、質問への回答の具体性も見ます。APIキーをどこで管理するか、下書き情報をどう扱うか、XSSをどう防ぐか、コンテンツ移行の検証方法は何か、障害時に誰が何分以内に対応するかを尋ねます。回答が技術用語だけで、運用担当者の作業や判断が書かれていない場合は、公開後の定着支援が弱い可能性があります。
セキュリティ・法務・内製化のリスクを確認します
セキュリティでは、APIキーの最小権限、サーバーサイド経由、管理画面の権限、IP制限、2要素認証、バックアップ、ログ、脆弱性情報の連絡方法を確認します。HTMLを入力できるフィールドがある場合は、表示時のエスケープやサニタイズ、リンクや画像の検証も受入条件にします。ISMSの有無だけで判断せず、自社の個人情報、委託先、再委託先、保存場所、削除方法を具体的に確認します。
内製化を予定する場合は、開発会社に依存しないための納品物を指定します。API仕様書、コンテンツモデル一覧、環境変数一覧、デプロイ手順、監視設定、テストコード、移行スクリプト、管理画面の操作マニュアル、教育会の記録を受け取ります。引き継ぎ後の質問対応や、フロントエンドの依存ライブラリ更新を誰が担当するかも、見積と契約の両方に含めます。
microCMSのシステム発注でよくある質問(FAQ)

microCMSの発注では、料金、開発会社への依頼範囲、技術者の必要性、既存システムとの連携について質問が多く寄せられます。ここでは、発注判断に直結する質問へ先に回答します。
microCMSのシステム開発費用はいくらですか?
小規模な1サイトなら150万〜400万円程度、中規模なら400万〜1,200万円程度、大規模・複数サイトなら1,000万〜3,000万円以上が、要件整理前の仮置きレンジです。これはmicroCMS公式の制作費ではなく、デザイン、フロントエンド、移行、連携、テストを含めた発注前の推定です。microCMSの月額利用料、ホスティング、保守費は別に見積もります。
社内にフロントエンドエンジニアがいなくても導入できますか?
導入できます。microCMSの設定だけでなく、画面開発、API連携、ホスティング、テスト、保守までを対応できる会社へ外注し、社内は目的と運用ルールの決定に集中する方法があります。ただし、完成後の更新担当者は必要です。発注時から操作説明と内製化支援を依頼し、管理画面で誰が何を更新するかを決めます。
microCMSは既存の業務システムの代わりになりますか?
microCMSは、受注、在庫、会計、複雑な認証などの業務システムをそのまま置き換えるものではありません。ニュース、商品説明、施設情報などの公開コンテンツをmicroCMSで管理し、顧客や注文の正データは既存システムに残す構成が基本です。連携APIやWebhookの設計、個人情報を複製する範囲をRFPで明確にします。
発注後の保守はどこまで外注すべきですか?
障害対応、脆弱性対応、依存ライブラリ更新、インフラ監視、API連携の復旧など、社内で対応できない領域は保守契約に含めることをおすすめします。コンテンツ更新や軽微な修正を内製化したい場合は、操作マニュアルと引き継ぎを発注し、開発会社には技術保守だけを依頼する方法もあります。受付時間、一次回答、復旧目標、追加費用の条件を確認して決めます。
まとめ

microCMSのシステムを発注・外注するときは、microCMS利用料と開発委託費を分け、CMS、フロントエンド、外部業務システム、インフラ、保守の責任範囲を明確にします。まず業務とコンテンツを分け、RFPに目的、対象範囲、運用体制、移行量、非機能要件、予算の考え方を記載します。
発注前に決めるべきこと
一括外注、部分外注、PoCのどれが合うかを、社内の技術者、運用担当者、納期、要件の確定度から選びます。契約は、要件整理を準委任、仕様が固まった開発を請負、公開後の改善と保守を月額契約に分ける方法が検討しやすいです。委託先は、公式パートナーの掲載有無だけでなく、同規模の移行、API連携、権限管理、障害対応、内製化支援の実績で比較します。
見積比較で最後に確認すること
見積書は、初期費用の合計だけでなく、工程、工数、成果物、除外項目、microCMSの月額、従量課金、移行費、保守費、3年総額を横並びにします。APIキーの最小権限、下書き情報の保護、XSS対策、個人情報の委託先管理、復旧手順、納品後の引き継ぎまで確認できれば、価格だけでは見えないリスクを減らせます。必要な範囲を整理したうえで複数社へRFPを渡し、自社の運用に合う提案を選びます。
▼全体ガイドの記事
・microCMSのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。
