microCMSの発注は、業務とコンテンツの範囲、要件、責任分担を整理するところから始まります。そのうえで開発、移行、運用の順に進めると、自社に合うCMSにつながります。
発注形態から委託先選定まで、段階ごとに決めることを順に示します。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・microCMSのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
microCMSのシステムを発注する前に知っておきたい全体像
発注前にまず整理したいのは、microCMSに何を任せ、開発会社に何を作ってもらい、既存の業務システムに何を残すかです。
microCMSはコンテンツを管理・配信する基盤で、サイト全体の画面や業務処理まで自動で完成させるサービスではありません。そのため、発注書ではCMS設定、フロントエンド、インフラ、移行、運用設計を分けて記載します。
microCMSが担う範囲と開発会社が担う範囲
発注側は、microCMSの編集・配信機能と、開発会社に依頼する作業を分けて把握しておきます。
- 管理する情報：ニュース、ブログ、商品、施設、FAQ、採用情報
- 運用設計：カスタムフィールド、参照、予約投稿、レビュー、ワークフロー、メンバー・ロール管理
- API連携：Content APIのデータを、Next.js、Nuxt.js、Astro、React、Vueなどへ渡す
- 別途必要な開発：画面・URL・検索・フォーム・認証、外部DB・ホスティング・監視・テスト・移行を、microCMSの外で別に作る
microCMSの機能を組み合わせると、更新担当者が運用しやすいデータ構造を設計できます。
発注書を「microCMS導入一式」とすると納品範囲が曖昧になります。範囲を分けておけば、追加請求や認識違いを減らせます。
向いている業務と、microCMSに残さない業務
microCMSに任せる業務は、更新する情報と基幹処理の性質を基準に区分します。
- 情報発信：複数担当者が更新するコーポレートサイト、メディア、自治体・金融機関の広報
- 情報集約：複数ブランド・拠点の商品・施設情報を一元管理し、アプリやサイネージにも配信
- 基幹処理：受注・在庫引当・請求・会計などの業務、複雑な認証や決済、個人情報を使う処理は、microCMSの中で完結させない
- データ連携：正データは既存システムや専用DBに残し、連携するのは公開情報だけ
- 発注範囲：「CMS化する業務」と残す業務を一覧にし、連携方式とデータ責任を決める
microCMSのシステム発注・外注形態の選び方
社内にフロントエンドやインフラの担当者がいない場合は、要件定義から開発・移行・保守まで相談できる会社へ外注すると進めやすいです。ただし、業務要件や運用方針まで丸投げすると、完成後に社内で使えないCMSになりかねません。そのため、発注側が決める事項を先に分けておきます。
一括外注が向く企業：担当者が不足し、複数工程をまとめたい場合
一括外注では、企画から保守までの工程を一つの会社か責任者にまとめて依頼します。その作業は、二つのまとまりに分けて考えます。
- 企画・設計：要件の整理、情報の構造づくり、APIやフィールドの定義
- 開発・運用：画面、インフラ、移行、テスト、リリース後の保守
技術者が少なくても進めやすく、障害時の窓口も一本化できます。さらに、複数ブランドや会員向け情報、検索、外部APIがある場合は、工程間の引き継ぎ漏れを防ぎやすくなります。
一括で頼むと、提案を比べにくく、不要な開発を含むこともあります。そのため、見積は工程ごとに分けてもらいます。要件定義から保守まで同じ区切りで並んでいると、各社の提案を比べやすいです。
ソースコード、インフラ設定、API仕様書の納品条件は、契約前に確認します。操作マニュアルとデザインデータの納品も、契約前に決めておきます。
部分外注が向く企業：社内に設計または開発の担当者がいる場合
社内で設計や運用を担える場合は、外注する作業を技術作業と社内準備の二つに分けて考えます。
- 技術作業：フロントエンド実装、既存CMSからの移行、API連携
- 社内準備：既製テンプレートを使い、デザインや原稿を自前で用意して初期費用を抑える
API設計やインフラの経験がないまま実装だけを外注すると、公開後の改修を自社で続けられないおそれがあります。
そのため、担当範囲の境界は文章で明記します。たとえば、API設定は発注先、移行元データの整形は自社、移行スクリプトの実行と検証は発注先と分けて書きます。
作業に必要なアカウントや素材、データ形式を事前に決めておきます。レビュー担当者も決めておくと、工程が止まりにくくなります。
PoCから始める方式：要件や運用を検証したい企業
本開発に進む前に、検証する範囲と成果物を決めて、PoCを実施します。
- 検証対象：全サイトを一度に移行せず、代表的な記事やニュースを使う
- 操作確認：HobbyやTeam環境で入力、プレビュー、レビュー、API表示を試す
- 検証目的：本番で変更しにくいデータ構造を早く見つけること（費用を抑えることが目的ではない）
- 成果物：試作画面・モデル案・権限設計、移行件数サンプル、運用フロー、残課題、正式版の概算見積
同じ会社に本開発を頼む場合も、検証済みの事項と未確定の事項を整理してから契約します。
microCMSのシステム発注を成功させる要件整理とRFPの作り方
RFPは、開発会社に提案を依頼するための資料です。目的や利用者、公開時期を示したうえで、現行サイトの課題を書きます。必須要件と希望要件、発注側の準備物は分けて記載します。
RFPに最低限書くべき項目
RFPの基本情報として書くのは、達成したい状態と対象範囲です。
- 目的とKPI：更新時間、承認時間、表示速度、問い合わせ増加
- 対象範囲：サイト・ページ数、コンテンツ、言語、スマートフォン・検索・フォーム、会員、外部連携
既存サイトがある場合は、URLの一覧や記事数、画像数を整理します。あわせて、公開終了データやリダイレクト、移行が難しいコンテンツも洗い出します。
運用要件には、編集者・承認者・管理者の人数と役割を含めます。公開に関わる部分では、レビュー、予約投稿、緊急公開を含めます。さらに、更新履歴、バックアップ、窓口も入れます。
非機能要件には、アクセス集中時の性能、障害時の復旧目標、監視を含めます。脆弱性対応とアクセシビリティ、個人情報、ソースコード管理も入れます。省くと各社の前提が変わり、相見積もりが不正確になります。
コンテンツモデルとAPI連携の発注条件
APIの数やフィールドの切り方は、運用のしやすさを左右します。そのため、入力項目とデータの受け渡し方を具体化したうえで、提案を比べます。
- 入力設計：「お知らせ」は本文一つにするか、タイトル・概要・公開日、カテゴリー・関連リンク・画像・対象拠点に分けるかを決める
- 表示例：入力例を2〜3件添えて、一覧や詳細、関連コンテンツ、下書き、予約公開の見え方を示す
- 連携条件：正データの保有先と、即時・バッチ更新の別、失敗時の再送の扱いを決める
- 発注条件：個人情報の複製、API仕様、エラー処理、テストデータ、連携先担当者を定める
連携方式は、Webhook、マネジメントAPI、専用の連携サーバーなどを候補として挙げます。
microCMSのシステム開発を発注する進め方
microCMSの外注は、要件定義から始めて設計・開発へ進みます。その後は移行・テストを行い、リリース・運用に入ります。各工程の成果物を先に決めておくと、完成間際に大きな仕様変更が出るのを避けやすくなります。
要件定義・企画フェーズの決定事項
まず、現行サイトと業務を棚卸しします。担当者には、困っている画面や承認者、急ぐ情報を聞き、月間の更新本数も確かめます。
そのうえで、サイトマップやコンテンツ一覧、権限表を作ります。さらに、連携一覧と移行対象表もまとめます。
microCMSを使わない範囲も決めておきます。たとえば、会員情報や注文データは保存しない、決済は専門サービスに任せる、検索は専用エンジンを使う、といった境界を定めます。発注側では、責任者、編集者、法務・情報システムの確認者を決め、意思決定の期限も設定します。
設計・開発フェーズの確認事項
設計・開発では、データ設計とシステム構成を決めます。
- 設計：モデルやAPI、URL、画面・権限、公開フロー・ホスティング
- 技術選定：Next.js、Nuxt.js、Astroなどを、保守体制や速度から選ぶ
検索やサーバーサイドレンダリング、将来のアプリ連携も踏まえます。そのうえで、技術名だけで決めず、なぜ自社に適する構成なのかを提案書で説明してもらいます。
APIキーには、GET、POST、PUT、PATCH、DELETEなどの権限を設定できます。公式資料は、キーが露出するCSRで外部から呼び出されるリスクを説明しています。
発注側は、公開情報を必要最低限のGET権限に絞り、書き込み権限のキーはサーバー側で管理する設計を受入条件にします（出典：microCMS「APIキー（APIの認証と権限管理）」、2026年6月更新）。
移行・テスト・リリースフェーズの確認事項
移行から公開までの確認は、次の順で進めます。
- 少量のサンプルデータを移行して、内容を確かめます。
- 全件を移行したあと、操作確認とテストを行います。
- 判定条件を満たしたことを確かめたうえで、リリースします。
サンプルでは、HTMLや画像、公開日を確かめます。カテゴリーや著者、関連リンクも見ます。さらに、検索結果とリダイレクトも確認します。
文字化けや画像の欠落、リンク切れを点検します。見出しの崩れと公開状態も確かめます。
全件移行後は、発注側が検索・編集・公開を行えるかを確かめます。権限外のログインや下書きの表示も、テストの対象に含めます。API失敗時の再処理とアクセス集中時の表示も試します。
リリース判定には、重大な不具合がゼロであること、移行件数の照合、バックアップを含めます。復旧手順、運用マニュアル、緊急連絡先も判定に入れます。初期監視期間と瑕疵対応期限は、契約に記載します。
microCMSの発注で選ぶ契約形態と責任分担
契約形態は、要件の確定度と発注側の管理範囲で選びます。たとえば、要件定義は準委任、設計・実装は請負、公開後の改善は月額準委任に分ける方法があります。
一つの契約にまとめる場合でも、成果物と検収条件は明確にしておきます。
準委任契約：要件を一緒に整理しながら進める場合
準委任では、専門知識と稼働時間をもとに、要件定義や技術調査、伴走設計、運用改善を進めます。CMSに持たせる内容や既存システムとの連携方法がまだ決まっていない場合に適しています。
契約には、作業時間と担当者、定例会を書きます。成果物や報告、追加作業の承認方法も記載します。完成したサイトを納品する契約とは限りません。
発注側は、週次で課題と判断事項を確かめ、優先順位を決めます。定例では、API仕様書や画面一覧を見ます。課題表と検証結果も、同じ場で確認します。
請負契約：成果物と仕様が固まった開発
請負では、合意した仕様に基づくサイトや機能、移行スクリプト、文書などを納品し、検収します。そのため、画面数やAPI数、対応ブラウザ、移行対象、テスト範囲を具体化します。納品形式、検収期限、不具合の扱いも決めます。
完成条件は、「CMS導入」「レスポンシブ対応」「検索機能」といった言葉だけでは判断しにくいです。新しい連携や移行件数の増加、公開日やデザインの変更に備え、追加費用と納期を文書で確認する手続きを決めておきます。
変更を無制限に受ける見積は安く見えても、品質や納期を守れないことがあります。そのため、変更の扱いのルールも各社で比べます。
保守契約：対応範囲と時間帯の分け方
公開後の保守では、技術作業の範囲と契約上の対応条件を切り分けます。
- 保守作業：CMS設定変更、ライブラリ更新、障害・脆弱性対応、軽微な改修、更新代行
- 契約条件：月額内外の作業、受付時間、一次回答期限、復旧目標、連絡方法、再委託
個人情報を扱う場合は、委託先の選定や秘密保持、アクセス権を契約に定めます。さらに、再委託、削除・返却、監査も盛り込み、漏えい時の報告も定めます。
個人情報保護委員会の指針は、委託先の安全管理措置や再委託先の把握を示しています（出典：個人情報保護委員会「個人情報保護法ガイドライン（通則編）」、2025年確認）。認証情報は、個人アカウントを共有せず、役割と期限を限定します。
microCMSのシステム発注費用・相場とコストの内訳
費用は、サービス利用料と開発委託費を分けて考えます。利用料は公式情報で確認できますが、開発費はサイトや画面の数、移行量、デザイン、連携、非機能要件によって変わります。
次に示す開発費は、公式の一律価格ではなく、リサーチノートに基づく発注前の仮置きです。実際の予算は、RFPを渡して提案と見積を取ってから決めます。
microCMSの利用料金：プランと従量課金
2026年8月時点では、Hobbyは0円/月、Teamは4,900円〜/月、Businessは75,000円〜/月です。Enterpriseは個別見積もりです（出典：microCMS「料金プラン」、2026年8月確認）。
- 転送量：Teamは200GB/月を超えると20円/GB
- 追加料金：Teamのメンバー追加は1人1,200円、API追加は1個2,000円
- Hobby：API5個、コンテンツ1万件まで。小規模な検証向け
- Business：1TB/月を超えると18円/GB。権限管理やIP制限、複数環境、技術サポートを備えます
- Enterprise：監査ログ、SAMLによるシングルサインオン、SLA、2要素認証の必須化、専任サポートを個別に相談
2025年6月10日に料金改定があり、Advancedの新規申し込みは終了しました。
開発委託費：規模別のレンジ
開発規模別の費用と期間は、含める作業の条件とあわせて仮置きします。
- 小規模：1サイトで150万〜400万円程度、1〜3か月
- 中規模：400万〜1,200万円程度、3〜6か月
- 大規模：1,000万〜3,000万円以上、6〜12か月
小規模では、デザインやフロントエンド、API設定を含みます。公開環境と操作説明も入ります。
中規模は、複数モデルや検索、レビューを含みます。移行、分析、外部API連携も加わります。
大規模は、複数ブランド・複数拠点や、金融・自治体などの厳格な非機能要件を含む場合の想定です。既存業務システムとの連携や、アクセシビリティ試験、負荷試験、脆弱性診断も含まれます。
これは公開情報に基づく推定で、公式の制作料金ではありません。移行データの品質や承認者の数でも変わるため、見積は前提条件をそろえて比べます。
保守・インフラ・移行費：初期費用とは分けた見積
初期費用と公開後の費用は、次の項目に分けて見積もります。
- 月額費用：CMS利用料、ホスティング、ドメイン、監視、メール配信、検索サービス
- 別途費用：移行整形、画像差し替え、リダイレクト、原稿確認、公開後の更新代行
- 保守・改善費：初期開発費の年15〜25％程度、または月15万〜80万円程度
保守費は、対応時間と作業量を含めて比べます。
障害対応やライブラリ更新が都度課金の場合、初期見積は安くても3年総額が高くなることがあります。一方で、保守費が高くても更新代行が含まれず、軽微な修正の定義が曖昧なケースもあります。
比較は、3年総額で行います。初期費用、月額、従量課金、移行、保守、改善費を合わせた額です。
microCMSの委託先選定と見積比較のポイント
委託先は、導入実績の数だけでなく、似た課題をどう解決したかで選びます。公式パートナーは候補を探す材料になりますが、同規模・業種・体制で成果を出せる保証ではありません。
提案では、画面だけでなく、モデルや技術を確認します。移行件数、権限、保守体制も見ます。
実績：技術名より運用の再現性
実績については、統合サイト数や更新者数、移行件数を質問します。利用プランや外部APIとサイネージの連携についても聞きます。今回の担当者が参加するのか、公開後の窓口は誰かも確かめます。
microCMSの遠州鉄道の事例では、グループ約50サイトのうち20サイトに導入し、約300店舗が更新するほか、サイネージにも連携しました。このほか、実装工数をスクラッチ開発比で10分の1程度に削減しています（出典：microCMS「遠州鉄道株式会社様 導入事例」、2025年公開・2026年更新）。自社に近い運用実績を探します。
見積書の比べ方：工程・前提・除外項目
合計金額を見る前に、工程別の費用と工数、見積条件を横並びにします。
- 企画・開発費：要件定義、情報設計、デザイン、CMS、フロントエンドの金額と工数
- 公開・保守費：連携、移行、インフラ、テスト、公開、マニュアル、保守の金額と工数
- 見積条件：各作業の担当、回数、成果物、検収条件、除外作業
「一式」が多い見積は、作業ごとに分解してもらいます。
金額に加えて、回答の具体性も見ます。対象は、APIキー管理や下書き情報、XSS対策、移行検証、障害時の対応時間への回答です。
運用担当者の作業や判断が示されず、技術用語だけの回答なら、公開後の定着支援が弱い可能性があります。
セキュリティ・法務・内製化のリスク
APIキーの扱いに加えて、委託先の情報管理と、内製化後の引き継ぎまで確認します。
- APIキーの最小権限とサーバー経由での利用
- 管理権限、IP制限、2要素認証、バックアップ、ログ
- 脆弱性情報の連絡、HTMLのエスケープやサニタイズ、リンクや画像の検証
ISMSの有無は一つの材料にとどめ、個人情報の扱いや委託先・再委託先を確かめます。保存場所と削除方法も確認します。内製化する場合は、引き継ぎ用の納品物を指定します。
引き継ぎでは、API仕様、モデル一覧、環境変数、デプロイの情報を受け取ります。監視、テストコード、移行スクリプト、操作マニュアル、教育会記録も含めます。引き継ぎ後の質問対応やライブラリ更新の担当者も、見積と契約に含めます。
microCMSのシステム発注でよくある質問（FAQ）
発注では、料金や外注範囲、技術者の必要性、既存システムとの連携について質問が多く寄せられます。発注判断に直結する内容を中心に回答します。
microCMSのシステム開発費用はいくらですか？
要件整理前の仮置きは、小規模1サイト150万〜400万円、中規模400万〜1,200万円、大規模・複数サイト1,000万〜3,000万円以上です。
公式の制作費ではなく、デザイン、フロントエンド、移行、連携、テストを含めた発注前の推定です。月額利用料やホスティング、保守費は別に見積もります。
社内にフロントエンドエンジニアがいなくても導入できますか？
導入できます。画面開発、API連携、ホスティング、テスト、保守まで対応できる会社に外注すると、社内は目的と運用ルールの決定に集中できます。
完成後も、更新を担当する人は必要です。操作説明と内製化の支援を頼み、誰が管理画面の何を更新するかを決めます。
microCMSは既存の業務システムの代わりになりますか？
microCMSは、受注や在庫、会計、複雑な認証などの業務システムをそのまま置き換える仕組みではありません。基本の構成は、公開コンテンツをmicroCMSで管理し、顧客や注文の正データは既存システムに残す形です。
連携APIやWebhook、個人情報を複製する範囲は、RFPで明確にします。
発注後の保守はどこまで外注すべきですか？
社内で対応できない障害や脆弱性、ライブラリ更新、監視、API復旧は、保守契約に含める方法があります。更新を内製化する場合は、操作説明と引き継ぎを依頼します。
受付時間や一次回答、復旧目標、追加費用の条件を確認して決めます。
まとめ
発注では、利用料と委託費を分けて考え、責任範囲を明確にします。CMSやフロントエンド、業務システム、インフラ、保守のどこを誰が担うかを決めます。そのうえで、業務とコンテンツを整理し、RFPに目的や範囲、体制、移行量、非機能要件を書きます。
発注前の決定事項
技術者や運用担当者の体制、納期、要件の確定度を見て、一括外注、部分外注、PoCを選びます。たとえば、要件整理は準委任、仕様確定後の開発は請負、公開後の保守・改善は月額契約に分ける方法があります。
委託先は、パートナー掲載の有無だけでなく、同規模の移行やAPI連携の実績で比べます。権限管理や障害対応、内製化支援の実績も確認します。
見積比較の最終確認事項
見積では、工程や工数、成果物、除外項目を並べます。月額や従量課金、移行費、保守費を加え、3年総額で比べます。APIキーや下書き、XSSの対策を確かめます。
個人情報の扱い、復旧、引き継ぎも確認します。そのうえで、必要範囲を整理して複数社へRFPを渡し、自社の運用に合う提案を選びます。
▼全体ガイドの記事
・microCMSのシステム開発の完全ガイド
▼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を創業。