Movable Typeのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Movable Typeのシステム開発は、要件整理、製品選定、設計・開発、テスト、段階的な稼働、定着の6段階で進めます。この順で進めると、運用に合うCMS基盤につながります。

費用相場と見積もりの要点は後半で扱います。全体像は、Movable Typeのシステム開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・Movable Typeのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Movable Typeのシステム開発で決める内容

Movable Typeは、記事やウェブページに加えて、ニュース、店舗、施設、製品などのデータも構造化して管理できるCMSです。企業や自治体、メディア、会員向け情報、イントラサイトなどで利用できます。

静的ページ生成、権限・ロール管理、予約公開を組み合わせられます。さらに、履歴管理、共有プレビュー、Data APIも組み合わせられます。開発では、画面を増やすことに加えて、情報の管理単位、承認経路、公開先を決めます。

最初に区別する4つの製品・提供形態

製品の候補は、サーバー運用や連携要件によって変わります。そのため、主な提供形態の特徴を比べて選びます。

• MovableType.net：少人数で、サーバー管理の負担を抑えたい場合に向きます。
• クラウド版：柔軟なテンプレートとマネージド環境を使いたい場合の候補です。
• ソフトウェア版・AMI版：社内インフラや特殊な連携を、自社の方針で管理したい場合に検討します。
• Advanced・Premium：多段階承認、複数サイト、LDAPや商用DB連携などを求める場合に検討します。

判断では、会社の規模だけでなく、サイト数、更新者数、承認段階を確かめます。そのほか、管理画面の分離とアクセスピーク、データ連携、インフラの責任分界も見ておきます。

1サイトを数名で更新するなら、高価な上位版が必ず必要とは限りません。一方で、複数拠点で発信し、複数部署の承認を通すなら、標準機能や追加製品で権限とワークフローを実現できるかを確かめます。

機能一覧より先に決める運用とデータの単位

要件整理では、更新業務で扱うデータの単位を先に決めておきます。決める中心は、データの分け方、入力項目、業務処理の切り分けの3点です。

• データを分類：ニュース、店舗、施設、製品を、それぞれ別のコンテンツタイプにします。
• 入力項目を定義：必須項目、選択肢、関連情報、公開日、担当部署の各項目を決めておきます。
• 業務処理を分ける：会員、予約、決済などは、専用アプリや外部サービスに切り離して扱います。

ニュースと製品情報を同じ自由入力欄で管理すると、表記や入力漏れにばらつきが出ます。そこで項目を定義しておくと、入力の質や検索性を保ち、担当者が代わった後も運用を続けられます。

公式情報では、Data APIはREST/JSONで記事やコンテンツタイプを取得・更新できます。さらに、独自アプリや他のプラットフォームとの連携、ヘッドレスCMSとしての利用にも使えます。

Movable Typeのシステム開発の進め方

開発は6つのフェーズで進めます。各段階で確認する条件を決めておくと、機能の好みだけを話す会議を避けられ、手戻りも抑えられます。

リニューアルでは、残す業務、やめる業務、将来連携する業務を分けて考えます。現行の仕組みをそのまま踏襲する前提は置かないことが大切です。

1. 要件の整理と、業務・データ・責任範囲の把握
2. 製品、構成、標準機能の範囲の選定
3. 情報設計、画面、外部連携の設計と開発
4. 移行、連携、非機能のテスト
5. 段階的な本番稼働
6. 教育、保守、改善による定着

フェーズ1：要件整理による業務・データ・責任範囲の把握

現行CMSから切り替えるときは、移行対象を洗い出すことと、公開後の業務フローを確かめることが、手戻りを防ぐ土台になります。

• 現行環境：CMSや記事・ページ・データ・画像・PDFの件数、ユーザー数、URL、プラグイン・フォーム・連携、アクセスピーク、更新体制。
• 業務フロー：入力者、承認者、公開時期と公開先、修正・差し替え、予約公開・取り下げ、緊急告知。
• サイトと権限：コンテンツタイプ、必須項目、サイト・ドメイン・言語の単位、編集者・承認者・公開担当・管理者の権限、URL、301リダイレクト。
• 機能と運用：検索、フォーム、解析、API・外部DB連携、バックアップ・復旧目標、脆弱性対応の担当。

公開フローでは、誰が何を入力し、誰が承認し、いつどこへ出すかを、一連の流れとして確かめます。成果物として、業務フロー、データ項目一覧、権限表を残します。URL一覧、連携一覧、MUST・WANT表もあわせて残すことで、発注側と開発会社の認識がそろいます。

フェーズ2：製品・構成・標準機能の範囲の選定

自社の要件表に、各製品と構成を当てはめます。サーバー運用、公開構成、承認・連携要件を比べ、候補を絞り込みます。

• MovableType.net：サーバー運用を避けたい場合の候補になります。
• クラウド版：公開サーバーとCMSを分離し、運用負荷や不正アクセス時の影響を抑えたい場合に検討します。
• ソフトウェア版・AMI版：社内インフラやDBを自社の基準で管理したい場合の候補です。
• Movable Type Advanced・Movable Type Premium：上位版として比べる選択肢です。

多段階承認や複数サイト、LDAP、商用DBなどが要件なら、Advanced・Premiumが必要な機能に合うかを確かめます。監査や大規模運用が要件に入る場合も、同じ見方で確認します。

デモやPoCでは、ベンダーのサンプルではなく、匿名化した自社の代表データを使います。たとえば、ニュースを入力して承認し、予約公開や差し替えを試したうえで、製品ページと関連付けます。

PoCでは、必須入力やプレビュー、権限、履歴を確かめます。加えて、再構築、検索、API、エラー時の復旧も見ておきます。

MT8からMT9へ移行する場合は、互換性も検証します。その際は、プラグインやテンプレートの扱いを確かめます。

PerlやPHP、文字コード、再構築時間も、同じ検証で見ておきます。互換性が確かめられていないプラグインを、本番採用の前提にしないことが大切です。

フェーズ3：情報設計・画面・連携の開発

設計・開発では、情報の構造と画面を決めるとともに、外部との連携でどこまでを誰が受け持つかも決めておきます。

• 情報設計：サイトマップ、URL、コンテンツモデル、関連付け、アーカイブ、テンプレートの責任範囲。
• 画面設計：更新者が迷わない入力画面と、閲覧者が目的の情報へ進めるナビゲーション。
• API連携：取得・更新項目、認証、レート制限、再送、ログ、個人情報の保存場所。
• 業務処理の分担：CMSと別アプリのどちらを正とするか、停止時の公開継続、データ削除・訂正の手順。

製品情報は、カテゴリや型番、PDF、関連ニュース、問い合わせ先を項目にしておくと、自由入力によるレイアウト崩れを抑えられます。加えて、標準機能、プラグイン、個別開発の境界も決めておくと、保守しにくい独自改修が増えにくくなります。

フェーズ4：移行・連携・非機能のテスト

テストでは、移行、連携、非機能のそれぞれの条件を確かめます。代表的なケースを組み合わせて検証します。

• 動作確認：代表・古い記事、画像・PDF、予約公開・修正、権限別ユーザー、フォームエラー・検索、API停止。
• 移行照合：全件の件数と、タイトル・本文・カテゴリ・公開日・作成者、画像、内部リンク、canonical・メタ情報、301。
• 非機能確認：再構築時間と同時アクセス、復元とログ、多要素認証・権限外アクセス、TLS、障害連絡。

移行の確認では、サンプルだけでなく、移行対象の全件の結果を確かめます。画面が表示されるかどうかだけでは、確認として不十分です。

シックス・アパートの公式情報では、TOTPによる2要素認証や細かなロール設定が案内されています。対象範囲は製品・バージョン・構成で変わるため、実環境で検証します。

また、2025年版のIPA TLS暗号設定ガイドラインも参照します。TLSを「対応済み」と記すだけで終えないことが大切です。

フェーズ5：段階的な稼働

本番は、移行の状況を確かめながら段階的に稼働させます。切り替えは、次の順で進めます。

1. 社内での確認
2. 限定公開
3. 主要ページの切り替え
4. 全体公開

切り替えの前には、DNSや証明書、CDN・WAF、フォーム通知、解析タグを確かめます。加えて、robots.txt、サイトマップ、リダイレクト、バックアップも確認します。

旧サイトは、すぐに消去せず、一定期間は参照や復旧ができる状態にしておきます。そうしておくと、移行漏れや問い合わせの原因を追跡できます。

リリースの判断は、件数照合と主要URL、フォーム送受信の結果に基づけます。権限と検索、速度の確認、監視や復元テストの結果も、判断の材料になります。

公開面を外部サーバーへ配信する構成では、CMSの管理画面が止まっても、公開ページを提供できるかを確認します。あわせて、再配信にかかる時間も確かめます。

担当者や開発会社、インフラ会社、広報や法務の連絡先を一覧にしておきます。障害時に判断する人も、稼働条件に含めておきます。

フェーズ6：教育・保守・改善による定着

稼働後に使われなくなる原因のひとつは、入力ルールや問い合わせ先が分からないことです。そのため、教育と保守で次の点を決めます。

• 編集者教育：ログイン、コンテンツタイプ、画像・プレビュー、承認、公開後の修正、緊急取り下げ。
• 管理者手順：ユーザー追加、権限変更、バックアップの確認と復元、プラグインと本体の更新、障害連絡を手順書にまとめます。
• 保守の分担：問い合わせ対応と、CMS本体・プラグイン・OS・Webサーバー・ミドルウェアの更新責任。

編集者研修は実データを使って行い、更新責任は契約で分けておきます。保守契約では、月次の問い合わせ対応だけでなく、各種更新の担当も明記します。

MT9は2025年10月22日に正式提供され、LTS版のサポート期間は最長4年に整理されました（出典: シックス・アパート「Movable Type 9の提供を開始」、2025年）。また、公式セキュリティ情報では、2026年2月にもMT9.1.0などの更新が案内されています。そのため、検証環境で更新してから本番へ反映する運用を、契約に含めます。

Movable Typeのシステム開発にかかる費用相場

費用は、製品やインフラの利用料と、開発費に分けて考えます。開発費は、要件整理から設計・制作、移行、連携、テスト、教育までの作業にかかります。

ただし、ライセンス価格だけでは、構築にかかる総額にはなりません。ここで示す数字は、Movable Type専用の全国統計ではありません。リサーチノートの業務システム一般の費用構造を基に、MT案件の移行・テンプレート・連携作業を踏まえた推定レンジです。

構築費の幅：150万円から3,000万円超まで

構築費と期間は、規模や作業範囲によって異なります。小規模、中規模、大規模の3段階で、推定レンジを見ていきます。

• 小規模：150万〜400万円、2〜4か月程度。
• 中規模：400万〜1,200万円、4〜8か月程度。
• 大規模：1,000万〜3,000万円超、6〜12か月以上となる可能性。自治体、複数サイト、多言語、既存DB、会員基盤、監査要件などを想定。

小規模は、企業サイトの新規構築と、既存CMSからの軽微な移行を想定します。基本テンプレートや主要ページ、記事移行、フォーム、アクセス解析、操作研修を含みます。

中規模は、コーポレートサイトやメディアを想定します。複数部署の権限や、コンテンツタイプ、サイト内検索、CSV移行を含みます。さらに、外部API、ステージング、総合テストも含めます。

ただし、古いプラグインの再現や大量の画像整理は、小規模でも別途上振れします。ページ数が少なくても、独自の入力項目や複雑な承認があれば、小規模とは限りません。

ここまでの金額は、作業範囲に基づく推定です。実際の金額は、要件と体制による個別見積もりで決まります。

ライセンス・クラウド・保守費の内訳

ライセンス、クラウド、保守の費用は、別々に把握します。製品ごとの料金は、ソフトウェア版からクラウド版の上位例まで5件並べます。

• ソフトウェア版：税込132,000円、年間メンテナンス44,000円。
• Movable Type Advanced：1,650,000円、年間メンテナンス330,000円。
• Movable Type Premium（Advanced Edition）：1,980,000円、年間メンテナンス550,000円。
• クラウド版：MTの1C2・20GBは月額26,400円。Premiumの1C2P・20GBは月額41,250円。
• クラウド上位例：8C16P・500GBは月額407,550円。

ライセンス価格は2026年4月1日以降の価格です（出典: シックス・アパート「価格改定のお知らせ」、2025年）。クラウド料金は2026年時点の公式価格で、本体プランとストレージの合算です（出典: シックス・アパート「Movable Typeクラウド版 さくらのクラウドプラン」、2026年確認）。

このほか、ワークフローやステージング製品、サーバー、証明書、CDN・WAFは、別費用になり得ます。見積もりでは、初期費用、サポート、マルチドメイン、オプションも比べます。

保守には、障害対応や脆弱性確認、定期更新、バックアップ・復元があります。ほかに、軽微な改修やアクセス分析、編集者支援も含まれ、範囲によって費用が変わります。

リサーチノートの一般論では、保守運用費は初期開発費の年間15〜25％、または月額15万〜80万円程度が目安です。ただし、これは案件固有の確定価格ではありません。見積書では、対応時間と月の作業時間、緊急時の扱い、バージョンアップ費用を分けて確認します。

Movable Typeのシステム開発で見積もりを取るポイント

見積もりを比べるときは、合計金額だけでなく、同じ条件で比較できるかを見ます。ライセンスやクラウド、デザイン、テンプレートなどは、別項目になりやすい要素です。移行やプラグイン、API、テスト、教育、保守も、見積もりでは別項目になりやすい要素です。

安い見積もりでは、作業範囲が含まれていない可能性があります。成果物と除外項目を明確にしておくと、後からの追加費用を抑えやすくなります。

見積依頼書に記載する対象範囲と終了条件

見積依頼書には、対象範囲と公開希望日を記します。記載する項目は、次のように分けて整理します。

• サイト情報：サイト・ドメイン数、ページ・記事件数、コンテンツタイプ、画像・PDF、言語・既存URL、プラグイン。
• 機能と体制：フォームや外部連携、想定アクセス、編集者・承認者数、承認段階、管理画面・公開サーバーの分離、MT8からMT9への移行。
• 成果物：要件定義書・サイトマップ・データ項目一覧、権限表、画面・テンプレート仕様・API仕様、移行・テスト計画・操作・運用手順書。

情報が不足している場合は、要件定義や現状調査を先行見積もりとして分けてもらいます。受け入れ条件は、第三者が判定できる形にします。たとえば、全件数の照合や主要URLのリダイレクト、各ロールの公開範囲、復元手順の実行を確かめます。

案件タイプ別に見る開発会社の実績と保守体制

開発会社を比べるときは、自社に近い案件の実績と、公開後の保守体制の両方を見ます。見る観点は3点です。

• 類似実績：北海道内7空港を統合し、多言語・静的配信・セキュリティ要件に対応した北海道エアポートの事例（出典: シックス・アパート導入事例、2026年確認）。
• 連携と移行：プラグインやAPIの支援、MT9対応、移行と301リダイレクトの担当範囲。
• 保守と引き継ぎ：コード引き渡し、障害窓口、更新責任、教育回数、契約終了時のデータ返却も確かめます。

フォームや会員、外部DB連携を重視する場合は、専門の担当者が継続して支援できるかを確かめます。加えて、公開後に誰が判断するかまで答えられる会社かどうかも比べます。

スコープクリープ・移行漏れ・教育不足の事前防止

スコープ変更や移行漏れ、教育の不足を防ぐには、事前に対応を決めておく必要があります。対応は、4つの面から整理します。

• 変更管理：MUST・WANT・将来検討を分け、追加要望の費用、納期、テスト、保守への影響を記録・承認します。
• 機能削減：残る手作業やセキュリティ上のリスクを明記します。
• 移行確認：画像参照・旧URL・埋め込み、カテゴリ、公開日、作成者を確認し、代表データでルールを決めます。
• 教育と引き継ぎ：質問が集中したときの窓口と、担当者交代時の資料を契約範囲に含めます。

全件を移行する前に、件数とエラー一覧を出せるようにしておきます。本文の変換だけでなく、埋め込みやカテゴリの重複も点検します。

Movable Typeのシステム開発でよくある質問

製品の適否や費用は、サイト規模だけでなく、移行や承認、連携、セキュリティ、運用体制によっても変わります。そのため、自社の条件に置き換えて判断することが大切です。

Movable Type 9への移行はすぐに行うべきですか？

すぐに本番移行はせず、MT9の機能やライフサイクルが更新計画に合うかを確かめてから進めます。既存のMT8や古い版から移行する場合は、プラグインの互換性とテンプレート、Perl・PHPを、検証環境で確かめます。再構築時間、データ変換、リダイレクトも同じ検証で見て、問題が残る範囲は見積もりに反映します。

一方で、新規開発ではMT9を基本候補にしつつ、将来の更新手順と検証環境を先に決めます。

Movable Typeクラウド版ならセキュリティ対策は不要ですか？

クラウド版でも、利用者側で判断する対策は残ります。基盤やサービス側の運用負荷は抑えられますが、対策が不要になるわけではありません。

対象は、アカウントや権限、コンテンツ、プラグインやテンプレートです。加えて、連携先、公開サーバー、TLS、バックアップ・復元、更新検証なども含まれます。

提供者、開発会社、自社それぞれについて、どこまでを誰が受け持つかを表にまとめます。脆弱性情報を誰が確認し、誰がいつ更新するかも、契約に定めます。

小規模サイトならどのくらいの費用で開発できますか？

既存CMSからの軽微な移行、基本テンプレート、フォーム、研修を含む案件では、構築費150万〜400万円、期間2〜4か月程度が推定目安です。金額は、ライセンス・クラウド利用料、複雑なプラグイン、独自API、大量移行、写真やPDFの整理、公開後の保守を含むかどうかで変わります。

初期費用とランニング費用を分けて、含む作業と除外項目を確認してください。

Movable Typeで会員・予約・業務システムまで作れますか？

Data APIや個別開発で連携できる場合はありますが、すべてをMovable Typeに集める設計が適切とは限りません。そのため、コンテンツの作成・承認・公開はMovable Typeに置き、認証・予約・決済・個人情報を含む処理は、専用アプリや外部サービスへ分ける構成を検討します。

まず、要件整理でデータの正や認証、権限、障害時の動作、削除・訂正の手順を決めます。そのうえで、方法と費用を比べます。

まとめ

判断は、6段階に沿って進めます。前半は要件整理と選定、中盤は設計・開発とテスト、後半は稼働と定着です。製品名や機能数から入らないことが大切です。

最初に、コンテンツタイプや権限、承認、URLを整理します。移行や外部連携、公開面、バックアップ、更新責任も、同じ段階で書き出しておきます。その要件に合う製品として、MovableType.net、クラウド版、ソフトウェア版、Advanced・Premiumから選びます。

費用は、製品やインフラの利用料と開発費、保守費に分けて見積もります。開発費は、要件定義やデザイン、テンプレートを含みます。移行やプラグイン・APIの作業も入り、テストや教育も開発費に含まれます。

構築費の推定レンジは、小規模で150万〜400万円、中規模で400万〜1,200万円、大規模で1,000万〜3,000万円超です。いずれも、作業範囲とデータ量で変わります。

現行環境を洗い出し、代表データでPoCを行います。そのうえで、成果物と受け入れ条件を含む見積依頼書から始めるのが現実的です。

最初に作る資料：要件・URL・権限の3点

初回の打ち合わせまでに、URLの一覧や、コンテンツと画像の件数、更新者・承認者の役割をまとめます。プラグインや外部連携、困っている作業も書き添えます。

完成した仕様書でなくても、現場で誰が何に時間を使っているかが分かれば、開発会社は調査の範囲と仮説を立てやすくなります。さらに、要件整理の成果物を見積もりと契約の基準にすると、認識違いを防げます。

公開後の更新責任を決めたうえでの発注

稼働日は、運用の開始日です。そのため、編集者教育や問い合わせ窓口、脆弱性情報の確認、更新検証環境、バックアップ復元、改善要望の優先順位を決めておきます。

これにより、公開後の負荷が担当者だけに集中しにくくなります。あわせて、初期開発と継続保守の範囲を分けて合意します。

▼全体ガイドの記事
・Movable Typeのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

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