5年後、CMSを替えたくなったら何が起きる？（後編）― 作り直しを小さくする3つの条件

前編では、ヘッドレスCMSで作ったWebサイトを次の4つの部品に分けて、5年後に「CMS」と「デザイン」を替えたくなったケースを見てきました。

• コンテンツ管理：microCMS
• Webサイトの組み立て：Astro
• 配信の仕組み：Cloudflare Workers
• 制作データの保管：GitHub

後編では、残りの「配信の仕組み」と「Webサイトを組み立てる道具」を替えるケースを取り上げます。最後に、すべてのシナリオに共通する条件をまとめます。

シナリオ3：配信の仕組みを替えたくなったら

2031年、グループ全体でクラウドサービスの利用方針が統一され、Webサイトの配信先も指定のサービスに移すことになったとします。

何が起きるのか

当社のヘッドレスCMSパッケージでは、コンテンツとデザインのひな形を組み合わせて、Webページをあらかじめ作っておく静的サイト生成（SSG）方式を採用しています。この方式で作ったWebサイトの実体は「ファイルの集まり」です。特定のサーバーやデータベースに依存しないため、移転先の選択肢が広く、移転作業そのものは比較的スムーズに進みます。実際に当社パッケージでも、Cloudflare Workersのほかに、オプションでAWS Amplify Hostingを選べます。

ただし、配信サービスならではの機能を使っている部分は、移転先で作り直しが必要です。

• お問い合わせフォームなど、送信された内容を処理する仕組み
• 古いURLから新しいURLへの転送設定
• セキュリティに関する設定
• 更新したコンテンツをWebサイトに反映するまでの手順

配信サービスそのものの進化も続いています。2026年2月、Cloudflareは、AIからのアクセスに対して、WebページをAIが読み取りやすい文章形式（Markdown）に変換して返すMarkdown for Agentsを発表しました。この機能を有効にしたWebサイトで利用できます。こうした新機能は「移転する理由」になる一方で、特定のサービスの機能に依存しすぎると「移転できない理由」にもなります。

今のうちにしておきたい準備

配信サービス独自の機能を「使わない」のではなく、「どこで使っているかを把握しておく」ことが大切です。

• 転送設定やセキュリティの設定、フォームの処理などを、デザインのひな形と一緒にGitHubで管理する
• 更新をWebサイトに反映するまでの手順を、担当者の記憶や管理画面の設定だけに頼らず、設定ファイルとして残す

こうしておけば、移転の際に必要な「作業リスト」が、最初から手元にそろった状態になります。

シナリオ4：Webサイトを組み立てる道具の将来が変わったら

2031年、Webサイトの組み立てに使っている道具（フレームワーク）を取り巻く状況が変わり、別の道具への乗り換えを検討する必要が出てきたとします。

何が起きるのか

このシナリオについては、正直にお伝えしておきます。

当社パッケージで使っているAstroについて、2026年1月、開発元のチームがCloudflareに加わることが発表されました。発表では、Astroがオープンソース（プログラムの中身が公開され、誰でも利用できるソフトウェア）として続くことや、Cloudflare以外の配信サービスを使う人に向けても開発を続ける姿勢が示されています。現時点で、利用上の懸念があるわけではありません。

それでも、5年先のことは誰にもわかりません。人気の道具が世代交代していくことは、Webの世界で何度も繰り返されてきました。AIによって、Webサイトの作り方そのものが変わる可能性もあります。

このシナリオで作り直しが必要になるのは、デザインのひな形の部分です。4つのシナリオの中では作業量が多くなりやすいものの、コンテンツ、CMS、URL、配信の仕組みは基本的にそのまま残せます。「すべてを作り直すリプレイス」と「ひな形だけを作り直す乗り換え」では、プロジェクトの規模もリスクも大きく異なります。

今のうちにしておきたい準備

デザインのひな形を、なるべく標準的な書き方で素直に作っておくことです。

• 道具独自の複雑な機能に依存しすぎない
• できあがるWebページのコード（HTMLやCSS）を、Webの標準に沿ったシンプルなものにしておく
• 色や余白などのデザインルールを、特定の道具に依存しない形でまとめておく

シンプルで標準的なコードは、人にとってだけでなく、AIにとっても読み解きやすいものです。AIを使ってコードを別の道具に移し替える方法が広がれば、この「素直さ」の価値はより高まります。

4つのシナリオを並べてみると

替えたいもの	作業が必要なところ	基本的にそのまま残せるところ
CMS	コンテンツと入力欄の設計の移行、CMSとのやり取り部分の修正	デザイン、URL、配信の仕組み
デザイン	デザインのひな形の作り直し	コンテンツ、CMSの管理画面、URL、配信の仕組み
配信の仕組み	配信サービス独自の機能（フォーム、転送設定など）、反映の手順	コンテンツ、CMS、デザイン、URL
Webサイトを組み立てる道具	デザインのひな形の作り直し	コンテンツ、CMS、URL、配信の仕組み

※前編・後編で紹介した準備をしている場合の目安です。

製品や作り方によって違いはありますが、従来型のCMSでは、コンテンツ管理、デザインのひな形、配信の役割が1つのシステムの中で結びついています。そのため、どれか1つを替えようとすると、ほかの部分も一緒に作り直しになりやすい傾向があります。

交換しやすさに共通する3つの条件

条件1：部品同士の境目がはっきりしている

CMSとのやり取りを1か所にまとめる、配信サービス独自の機能を使っている箇所を把握しておく。こうした工夫によって、交換の影響が及ぶ範囲を小さくできます。

条件2：部品の中身が標準的な形になっている

意味のまとまりで登録したコンテンツ、見た目を持ち込まないデータ、素直なコード。標準的な形であるほど、乗り換え先の選択肢が広がります。

条件3：手順や設定が記録に残っている

デザインのひな形や設定をGitHubで管理し、反映の手順も設定ファイルとして残しておく。「前任者しか知らない」状態を作らないことが、どの部品を替えるときにも役立ちます。

交換の手間はゼロにはならない

ここまでお読みいただき、「ヘッドレスCMSなら乗り換えは簡単」と感じた方もいるかもしれません。しかし、交換の手間が無くなるわけではありません。

• コンテンツを移したあとは、正しく移行できたかの確認が必要です
• デザインのひな形を作り直すには、相応の時間と費用がかかります
• 替えやすさを確保するために、導入の段階で設計の手間が少し増えます

かといって、あらゆる変化に備えて何でも作り込めばよいわけでもありません。備えすぎた設計は、かえって開発や保守の負担を増やします。どこまで備えるかは、Webサイトの規模や更新の頻度、将来の計画に合わせて見極める必要があります。

私たちが目指しているのは、乗り換えの手間をゼロにすることではありません。将来の乗り換えの手間を、見通しが立ち、コントロールできる範囲に収めることです。

まとめ：5年後の自分たちに、選択肢を残しておく

CMSを選ぶことは、今の課題を解決する手段を選ぶことであり、将来の選択肢の広さを決めることでもあります。

AIをはじめとする技術の変化は、これからも私たちの予想を超えていきます。そのような時代に大切なのは、完璧な未来予測よりも、変化が訪れたときに必要な部品だけを入れ替えられる身軽さです。

ミツエーリンクスの「ヘッドレスCMSパッケージ」は、microCMSを中心に、Astro、Cloudflare Workers、GitHubを組み合わせた構成で、Webサイトの構築から運用・保守までを支援しています。導入の段階の設計はもちろん、5年後、10年後に「替えたくなったとき」まで見据えたWebサイトづくりについて、お気軽にご相談ください。

※記載されている会社名、製品名などの固有名詞は、各社の登録商標または商標です。