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

Movable Typeのシステム開発は、CMSを設置してページを作るだけではなく、コンテンツの構造、承認・公開の流れ、外部システムとの連携、公開面の安全性までを一つの運用基盤として設計することです。成功のポイントは、製品を先に決めるのではなく、要件整理から定着までを6つのフェーズに分けて判断することです。

本記事では、「Movable Typeのシステム」を導入・リニューアルするときの進め方を、要件整理、製品・構成の選定、設計・開発、テスト、稼働、定着の順に解説します。MT9への移行、MovableType.net・クラウド版・ソフトウェア版の使い分け、2026年時点のライセンス・クラウド料金、構築費の推定レンジ、発注前のチェックリストまで、社内検討や見積依頼に使える形で整理します。

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

Movable Typeのシステム開発は何を決める作業ですか？

Movable Typeは、記事やウェブページだけでなく、ニュース、店舗、施設、製品などのコンテンツデータを構造化して管理できるCMSです。テンプレートによる静的ページ生成、権限・ロール管理、予約公開、履歴管理、共有プレビュー、Data APIを組み合わせることで、企業サイト、自治体サイト、メディア、会員向け情報サイト、イントラサイトの基盤として利用できます。したがって開発の中心は、画面を増やすことではなく、情報を誰がどの粒度で管理し、どの経路で承認して、どこへ公開するかを決めることです。

Movable Typeのシステムを検討するときは、似た名称の製品を同じものとして比較しないことが重要です。少人数でサーバー管理の負担を抑えたい場合はSaaS型のMovableType.net、MTの柔軟なテンプレートとマネージド環境を使いたい場合はMovable Typeクラウド版、社内インフラや特殊な連携を自社方針で管理したい場合はソフトウェア版やAMI版が候補です。多段階承認、複数サイト、LDAPや商用データベース連携など大規模運用の要件がある場合は、AdvancedやPremiumを検討します。

判断の基準は「会社の規模」ではなく、管理画面を分ける必要性、サイト数、更新者の人数、承認段階、アクセスのピーク、データ連携、インフラの責任分界です。たとえば1サイトで更新者が数名なら高価な上位版が必ず必要とは限りません。一方、複数拠点が同じブランド基準で発信し、公開前に複数部署の承認が必要なら、ワークフローや権限を標準機能・追加製品で実現できるかを優先して確認します。

要件の起点は、ページの種類ではなく、更新業務とデータの関係です。ニュースと製品情報を同じ自由入力欄で管理すると、担当者によって表記や入力漏れが変わります。ニュース、店舗、施設、製品などをコンテンツタイプとして分け、必須項目、選択肢、関連コンテンツ、公開日、担当部署を定義すると、入力品質と検索性を保ちやすくなります。これは担当者が変わっても運用を継続するための設計です。

また、会員情報、予約、決済、個人情報を扱う業務処理までMovable Typeに詰め込む必要はありません。CMSはコンテンツ管理層として利用し、業務ロジックを専用アプリや外部サービスへ分け、Data APIで連携する方が保守しやすいケースがあります。公式情報でも、Data APIはREST/JSONで記事やコンテンツタイプを取得・更新でき、独自アプリや他プラットフォームとの連携、ヘッドレスCMSの構成に利用できると説明されています。

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

開発は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで進めます。各フェーズで「何を確認できたら次へ進むか」を決めると、会議が機能の好みを話し合うだけにならず、手戻りを抑えられます。既存サイトのリニューアルでは、現行踏襲を前提にせず、残す業務、やめる業務、将来連携する業務を分けることが特に重要です。

最初に、現行CMS、記事・ウェブページ・コンテンツデータ・画像・PDFの件数、ユーザー数、URL、プラグイン、フォーム、外部連携、アクセスピーク、更新体制を棚卸しします。次に「誰が、何を入力し、誰が承認し、どのタイミングで、どの公開先へ出すか」を業務フローにします。画面の要望を集めるだけではなく、公開後の修正、差し替え、予約公開、取り下げ、緊急告知まで確認します。

要件整理のチェックリストは、（1）コンテンツタイプと必須項目、（2）サイト・ドメイン・言語の単位、（3）編集者・承認者・公開担当・管理者の権限、（4）URLと301リダイレクト、（5）検索・フォーム・解析、（6）APIや外部DBとの連携、（7）バックアップ・復旧目標、（8）脆弱性対応の担当です。成果物として業務フロー、データ項目一覧、権限表、URL一覧、連携一覧、MUST・WANT表を残し、発注側と開発会社の認識をそろえます。

選定では、MovableType.net、クラウド版、ソフトウェア版・AMI版、Advanced・Premiumを、自社要件の表に当てはめます。少人数でサーバー運用を避けたいならSaaS、公開サーバーとCMSを分離して運用負荷や不正アクセス時の影響を抑えたいならクラウド版、社内インフラやデータベースを自社基準で管理したいならソフトウェア版やAMI版が候補になります。多段階承認、複数サイト、LDAP、商用データベース、監査や大規模運用が要件ならAdvanced・Premiumの適合性を確認します。

デモやPoCでは、ベンダーが用意したサンプルではなく、匿名化した自社の代表データを使います。「ニュースを入力して承認し、予約公開し、公開後に差し替え、関連する製品ページから参照する」流れを操作し、入力必須、プレビュー、権限、履歴、再構築、検索、API、エラー時の復旧を確認します。MT8からMT9へ移行する場合は、既存プラグイン、テンプレート、PerlやPHP、文字コード、再構築時間を検証し、互換性が不明なプラグインを本番採用の前提にしないことが大切です。

設計では、サイトマップやURLだけでなく、コンテンツモデル、関連付け、アーカイブ、テンプレートの責任範囲を決めます。たとえば製品情報を一つのコンテンツタイプにし、カテゴリ、型番、PDF、関連ニュース、問い合わせ先を項目化すれば、担当者が自由入力でレイアウトを壊すリスクを下げられます。デザインでは、更新者が迷わない入力画面と、閲覧者が目的の情報へ到達しやすいナビゲーションを同時に設計します。

外部連携を含む場合は、Data APIで取得・更新する項目、認証方式、レート制限、エラー時の再送、ログ、個人情報の保存場所を定義します。会員・予約・決済などの業務処理を別アプリへ分ける場合は、CMSとアプリのどちらを正とするか、連携停止時に公開を継続できるか、データを削除・訂正する手順まで設計書に記載します。標準機能、プラグイン、個別開発の境界をこの段階で決めると、後から保守できない独自改修が増えにくくなります。

テストは、画面が表示されるかだけでは不十分です。代表的な記事、古い記事、画像やPDFを含む記事、予約公開、公開後の修正、権限が異なるユーザー、フォームのエラー、検索結果、外部API停止を組み合わせて確認します。移行では、件数、タイトル、本文、カテゴリ、公開日、作成者、画像、内部リンク、canonicalやメタ情報、旧URLからの301リダイレクトを照合し、サンプルだけでなく全件の結果を確認します。

非機能テストでは、再構築時間、同時アクセス、バックアップからの復元、ログの取得、管理画面への多要素認証、権限外データへのアクセス、TLS設定、障害時の連絡経路を確認します。シックス・アパートの公式機能情報ではTOTPによる2要素認証や細かなロール設定が案内されていますが、利用する製品・バージョン・構成で対象範囲が変わるため、実環境で検証します。2025年版のIPA TLS暗号設定ガイドラインも参照し、TLSを「対応済み」と書くだけで終わらせないことが重要です。

本番稼働では、いきなり全ページを切り替えるのではなく、社内確認、限定公開、主要ページの切り替え、全体公開の順に段階を分けます。切り替え前に、DNS、証明書、CDNやWAF、フォーム通知、解析タグ、robots.txt、サイトマップ、リダイレクト、バックアップを確認します。旧サイトをすぐに消去せず、一定期間は参照・復旧できる状態にしておくと、移行漏れや問い合わせの原因を追跡しやすくなります。

リリース判定は「担当者が問題ないと言った」ではなく、件数照合、主要URLの表示、フォーム送受信、権限、検索、速度、監視、復元テストの結果で判断します。公開面を外部サーバーへ配信する構成では、CMS管理画面が停止しても公開済みページを提供できるか、再配信にどの程度かかるかを確認します。担当者、開発会社、インフラ会社、広報や法務の連絡先を一覧化し、障害時に誰が判断するかも稼働条件に含めます。

稼働後に使われない原因は、機能不足よりも、入力ルールや問い合わせ先が分からないことです。編集者向けには、ログイン、コンテンツタイプの選択、画像の扱い、プレビュー、承認依頼、公開後の修正、緊急取り下げを実データで研修します。管理者向けには、ユーザー追加、権限変更、バックアップ確認、復元、プラグインと本体の更新、障害連絡を手順書にします。

保守契約では、月次の問い合わせ対応だけでなく、CMS本体、プラグイン、OS、Webサーバー、ミドルウェアの更新責任を分けます。MT9は2025年10月22日に正式提供され、LTS版のサポート期間が最長4年に整理されました（出典: シックス・アパート「Movable Type 9の提供を開始」、2025年）。一方、公式のセキュリティ情報では2026年2月にもMT9.1.0などの更新が案内されているため、検証環境で更新してから本番へ反映する運用を契約に含めます。

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

Movable Typeの費用は、製品・インフラの利用料と、要件整理・設計・制作・移行・連携・テスト・教育の開発費を分けて考えます。公式に確認できるライセンス価格が、そのまま構築総額になるわけではありません。以下の構築費はMovable Type専用の全国統計ではなく、リサーチノートに記載した業務システム一般の費用構造と、MT案件で発生しやすい移行・テンプレート・連携作業を踏まえた推定レンジです。

小規模の企業サイトを新規構築し、既存CMSから軽微に移行する場合は、150万〜400万円、期間は2〜4か月程度が一つの推定目安です。基本テンプレート、主要ページ、記事移行、フォーム、アクセス解析、操作研修を含む想定ですが、古いプラグインの再現や大量の画像整理は別途上振れします。ページ数が少なくても、独自の入力項目や複雑な承認がある場合は小規模とは限りません。

中規模のコーポレートサイトやメディアで、複数部署の権限、コンテンツタイプ、サイト内検索、CSV移行、外部API、ステージング、総合テストまで行う場合は、400万〜1,200万円、4〜8か月程度が推定レンジです。自治体、複数サイト、多言語、既存DB、会員基盤、監査要件を含む大規模案件は、1,000万〜3,000万円超、6〜12か月以上になる可能性があります。これらは作業範囲に基づく推定であり、実際には要件と体制をもとに個別見積もりが必要です。

2026年4月1日以降の公式価格では、Movable Typeソフトウェア版が税込132,000円、年間メンテナンスが44,000円です。Movable Type Advancedは1,650,000円、年間メンテナンス330,000円、Movable Type Premium（Advanced Edition）は1,980,000円、年間メンテナンス550,000円です（出典: シックス・アパート「価格改定のお知らせ」、2025年）。ワークフローやステージングなどの追加製品、サーバー、証明書、CDNやWAFは別費用になり得ます。

クラウド版のさくらのクラウドプランは、本体プランとストレージを合算します。2026年時点の公式料金表では、Movable Typeの1C2と20GBの組み合わせが月額26,400円、Movable Type Premiumの1C2Pと20GBが月額41,250円で、最上位例の8C16Pと500GBは月額407,550円です（出典: シックス・アパート「Movable Typeクラウド版 さくらのクラウドプラン」、2026年確認）。初期費用やサポートの扱い、マルチドメインの条件、オプションの有無まで含めて比較します。

運用保守は、障害対応だけでなく、脆弱性情報の確認、定期更新、バックアップと復元確認、軽微な改修、アクセス分析、編集者支援をどこまで含むかで変わります。リサーチノートの一般論では、保守運用は初期開発費の年間15〜25％、または月額15万〜80万円程度が目安とされています。案件固有の確定価格ではないため、見積書では対応時間、月の作業時間、緊急時の扱い、バージョンアップ費用を分けて確認します。

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

見積もりを比較するときは、合計金額の安さより、同じ条件で比較できているかを確認します。特にMovable Type案件は、ライセンス、クラウド、デザイン、テンプレート、コンテンツ移行、プラグイン、API、テスト、教育、保守が別々の項目になりやすく、安い見積もりほど作業範囲が含まれていない可能性があります。発注前に成果物と除外項目を明確にすることが、後からの追加費用を抑える近道です。

見積依頼書には、サイト数、ドメイン数、ページと記事の件数、コンテンツタイプ、画像・PDF、言語、既存URL、利用中のプラグイン、フォーム、外部連携、想定アクセス、公開希望日を記載します。さらに、編集者・承認者の人数、承認段階、管理画面を分けるか、CMSと公開サーバーを分離するか、MT8からMT9へ移行するかも明記します。情報が不足している場合は、要件定義・現状調査を先行見積もりに分けてもらいます。

成果物は、要件定義書、サイトマップ、データ項目一覧、権限表、画面・テンプレート仕様、API仕様、移行計画、テスト計画、操作マニュアル、運用手順書に分けて確認します。受け入れ条件は、「移行対象の全件数を照合する」「主要URLのリダイレクトを確認する」「各ロールで公開できる範囲を検証する」「復元手順を実行する」など、第三者が結果を判定できる表現にします。

開発会社には、Movable Typeの構築実績だけでなく、自社と近い案件の事例を確認します。自治体や大規模複数サイトなら、北海道内7空港のサイトを統合し、多言語展開、静的配信、セキュリティ要件に対応した北海道エアポートの事例が参考になります（出典: シックス・アパート導入事例、2026年確認）。フォーム・会員・外部DB連携を重視する企業は、プラグイン開発やAPI連携の担当者が継続して支援できるかを確認します。

質問する項目は、（1）MT9と既存プラグインの対応実績、（2）移行と301リダイレクトの担当範囲、（3）テンプレートやソースコードの引き渡し、（4）障害時の一次窓口、（5）本体・プラグイン・OSの更新責任、（6）教育とマニュアルの回数、（7）契約終了時のデータ返却です。会社の知名度や提案資料の見栄えではなく、公開後に誰が何を判断するかまで回答できる会社を比較します。

よくある失敗は、打ち合わせの途中で「この一覧も自動化したい」「過去記事もきれいに直したい」「会員機能もCMSに追加したい」と要望が増え、費用と納期の基準が変わることです。MUST・WANT・将来検討を分け、追加要望が出たときは、費用、納期、テスト範囲、保守への影響を記録して承認する変更管理を行います。機能を削る場合も、削除によって残る手作業やセキュリティ上のリスクを明記します。

移行では、記事本文の変換だけに注目すると、画像の参照切れ、古いURLの消失、埋め込み、カテゴリの重複、公開日や作成者の欠落が起こります。全件移行の前に、代表データで変換ルールを決め、件数とエラー一覧を出せるようにします。教育では一度の説明会だけで終えず、運用開始後に質問が集中する期間の問い合わせ窓口と、担当者が異動した場合の引き継ぎ資料を契約範囲に含めます。

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

最後に、導入前に特に質問されやすい内容を整理します。製品の適否や費用は、サイト規模だけでなく、移行、承認、連携、セキュリティ、運用体制によって変わるため、自社の条件に置き換えて判断します。

すぐに本番移行するのではなく、MT9の機能やライフサイクルが自社の更新計画に合うかを確認してから進めます。既存MT8や古いバージョンから移行する場合は、プラグイン互換性、テンプレート、Perl・PHP、再構築時間、データ変換、リダイレクトを検証環境で確認し、問題が残る範囲を見積もりに反映します。新規開発ではMT9を基本候補にしつつ、将来の更新手順と検証環境を先に決めます。

不要にはなりません。クラウド版では基盤やサービス側の運用負荷を抑えられますが、アカウント・権限、コンテンツ、プラグインやテンプレート、連携先、公開サーバー、TLS、バックアップ復元、更新の検証など、利用者側で判断する範囲が残ります。見積もりでは、サービス提供者、開発会社、自社の責任分界を表にし、脆弱性情報を誰が確認し、誰がいつ更新するかを契約に落とします。

既存CMSからの軽微な移行と基本テンプレート、フォーム、研修を含む小規模案件では、構築費の推定レンジとして150万〜400万円、期間2〜4か月程度が一つの目安です。ただし、これはライセンス・クラウド利用料、複雑なプラグイン、独自API、大量移行、写真やPDFの整理、公開後の保守を含むかで変わります。見積もりでは初期費用とランニング費用を分け、含む作業と除外項目を確認してください。

技術的にはData APIや個別開発で連携できる場合がありますが、すべてをMovable Typeへ集約する設計が適切とは限りません。コンテンツの作成・承認・公開はMovable Type、認証・予約・決済・個人情報を含む業務処理は専用アプリや外部サービスとし、必要な情報だけをAPIで連携する構成をまず検討します。要件整理でデータの正、認証、権限、障害時の動作、削除や訂正の手順を決めてから、実現方法と費用を比較します。

まとめ

Movable Typeのシステム開発を成功させるには、製品名や機能数から入らず、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズで判断します。最初にコンテンツタイプ、権限、承認、URL、移行、外部連携、公開面、バックアップ、更新責任を整理し、その要件に合うMovableType.net、クラウド版、ソフトウェア版、Advanced・Premiumを選びます。

費用は、製品・インフラの利用料と、要件定義、デザイン、テンプレート、移行、プラグイン、API、テスト、教育、保守を分けて見積もります。構築費の推定レンジは、小規模で150万〜400万円、中規模で400万〜1,200万円、大規模で1,000万〜3,000万円超ですが、金額は作業範囲とデータ量で変わります。まずは現行環境の棚卸しと、代表データを使ったPoC、成果物と受け入れ条件を含む見積依頼書の作成から始めることが現実的です。

最初の打ち合わせまでに、現行サイトのURL一覧、コンテンツと画像の件数、更新者と承認者の役割、利用中のプラグイン、外部連携、困っている作業をまとめます。完成した仕様書でなくても、現場の言葉で「誰が何に時間を使っているか」を書けば、開発会社は調査範囲と仮説を立てやすくなります。要件整理の成果物を見積もりと契約の基準にすることが、後からの認識違いを防ぎます。

稼働日はゴールではなく、運用の開始日です。編集者教育、問い合わせ窓口、脆弱性情報の確認、バージョンアップの検証環境、バックアップ復元、改善要望の優先順位まで決めておけば、公開後に担当者だけへ負荷が集中しません。Movable Typeを長く使うために、初期開発の範囲と保守で継続する範囲を分けて合意します。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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