PHPの脆弱性から考えるデカップルドCMS｜WordPressとの違いとメリット

WordPressでは、記事を編集する管理画面と、Webページを表示する機能が一つのCMSにまとまっています。このように、管理と表示が一体になった構成を「カップルドCMS」と呼びます。

これに対して、管理する側と公開する側を分けるのが「デカップルドCMS」です。閲覧に必要なHTMLや画像を事前に用意し、公開側から配信する構成なら、ページを表示するたびにCMSへアクセスする必要はありません。

この記事では、両者の違いと、管理・公開を分けるメリットを説明します。PHPの脆弱性が見つかったとき、構成によって何が変わるのかも取り上げます。情報は2026年10月24日時点のものです。

この記事での用語と比較対象

CMSは、記事や画像などのコンテンツを管理する仕組みです。この記事では、次の意味で用語を使います。

WordPressは、テーマ（デザインや表示を決める仕組み）を使う一般的な構成を比較対象とします。

用語の使い方には幅があり、AWSのヘッドレスCMS解説はデカップルドとヘッドレスを区別し、Drupalのデカップルド構成の解説は同じ意味で扱っています。当サイトのヘッドレスCMSの入門記事はAWSの区分に沿っていますが、この記事では「管理と公開を分ける」という共通の考え方に着目し、上の表の定義で説明します。

カップルドCMSは、管理から表示までを一つの仕組みで扱う

一般的なWordPressでは、管理画面で記事を登録し、テーマを通して訪問者に表示します。ページを生成するときは、PHPというプログラミング言語で、データベースから記事の情報を読み出し、HTMLを組み立てます。

管理画面、データベース、テーマが連携しているため、記事を書くところから公開までを一つの仕組みで扱えます。デザインの変更や機能の追加に、テーマやプラグインを活用しやすいことも利点です。

作成済みのページを再利用する「キャッシュ」を使えば、アクセスのたびにページを作り直す処理を省けます。ただし、キャッシュを導入することと、CMSの実行環境を公開サイトから分けることは別です。WordPress公式の最適化ガイドでも、キャッシュはページ表示の負荷を減らす方法として説明されています。

デカップルドCMSは、管理側と公開側の役割を分ける

デカップルドCMSでは、編集者が使う管理側と、訪問者にページを届ける公開側を分けます。更新した内容は、HTMLファイルとして書き出すか、APIで受け渡すことで公開側へ反映します。

例えば、CMSでHTMLファイルを生成し、別の公開サーバーへ配置する構成です。編集者はCMSへログインして記事を更新し、訪問者は公開サーバーにあるファイルを受け取ります。公開サーバーにCMS本体を置く必要はありません。

Movable Typeクラウド版のサーバー配信機能は、この構成の一例です。CMSで生成したコンテンツを外部サーバーへ配信でき、公開先にCMSをインストールせずに運用できます。

静的配信を組み合わせた場合の違いを、WordPressの一般的な構成と比較すると次のようになります。

ヘッドレスCMSと静的配信は、別に考える

ヘッドレスCMSも、管理と表示を分ける方法の一つです。ただし、CMSがAPIでデータを渡すことと、公開側が静的HTMLを配信することは別の話です。

HTMLを作る方法には、アクセス時にサーバーで生成するSSRと、事前に生成しておくSSGがあります。microCMSの公式解説でも、これらの方法を選んで実装できることが説明されています。

SSRでは、表示側のサーバーや接続先のシステムでPHPを使う構成もあります。PHP自体がサーバー上でHTMLを生成できるためです。ヘッドレスという名称だけでは、PHPを使うかどうかは決まりません。

以下で説明するのは、管理環境と公開環境を分け、閲覧に必要なHTMLや画像などを静的ファイルとして配信する構成のメリットです。

管理と公開を分け、静的配信にする3つのメリット

1. 公開サイトからCMSへ届く攻撃の経路を減らせる

2026年10月21日、PHP公式は、認証なしでサーバー上のコードを実行されるおそれがある脆弱性と修正版を公表しました。WordPress公式もPHPの更新を呼びかけています。PHP本体の問題なので、WordPressやプラグインの更新だけでは対処できません。

PHPでページを生成するカップルド型の構成では、キャッシュされていないページへのリクエストをPHPが処理します。一方、CMSを分離して静的ファイルだけを配信する公開環境には、CMSのPHPを置く必要がありません。ページへのアクセスが、そのままCMSのPHP処理につながる経路をなくせます。

管理側へのアクセスも、編集者や必要なシステムに限定します。別のURLから誰でもCMSへ接続できる状態では、そちらに攻撃経路が残るためです。

PHPを使う管理環境では、Webサーバーやネットワーク側で接続元を制限し、許可していないリクエストをPHPへ渡さないようにします。今回のPHP公式告知でも、アプリケーションのコードが動く前に攻撃が成立する環境が示されています。

管理側に残るPHPやCMSの修正は、引き続き必要です。

2. CMSのメンテナンス中も、公開済みのページを表示できる

必要なファイルが公開環境にそろっていれば、CMSのメンテナンス中も、会社案内や過去のお知らせを表示できます。CMSの再開を待つのは、新しい記事の編集や公開です。

ただし、画像の読み込みや検索に管理側のシステムを使っている場合は、停止の影響を受けます。HTMLだけでなく、画像や各機能の接続先も含めて分離することが前提です。

3. 閲覧が増えても、CMSの処理を増やさずに済む

静的配信では、訪問者に生成済みのファイルを返します。ページを表示するたびにCMSから記事を取り出し、HTMLを組み立てる処理は不要です。

生成したファイルは、複数の拠点からコンテンツを届けるCDNでも配信できます。microCMSのSSGの解説でも、この配信方法が紹介されています。ただし、静的配信だけで表示が速くなるとは限りません。画像の容量やJavaScriptの処理も表示速度に影響します。

分離すると、公開までの手順と保守する範囲が変わる

カップルドCMSでは一つにまとまっていた機能を分けるため、管理側と公開側をつなぐ仕組みが必要になります。導入前には、次の点を確認します。

更新してからサイトに反映されるまでの流れ

静的配信では、CMSで記事を更新した後に、HTMLの生成と公開環境への反映が必要です。プレビューや予約公開、配信に失敗した際の通知、前の状態へ戻す手順も用意します。

当サイトはmicroCMSとNext.jsを使い、記事ページを静的生成しています。更新から反映までの流れは、microCMSの記事が反映されない原因と再ビルドの確認方法で紹介しています。

フォームや会員機能をどこで動かすか

問い合わせの送信、会員認証、予約、決済などは、HTMLファイルを配信するだけでは処理できません。処理を担当するサーバーや外部サービスを別に用意します。

例えば、公開ページが静的でも、フォームが管理側のシステムへ接続していれば、そのシステムを止めると送信できなくなります。どの機能まで管理側から切り離すかを決めておく必要があります。

管理側と公開側を誰が保守するか

分離した後も、管理側のCMSや、その実行に使うソフトウェアの更新は必要です。HTMLを生成する環境や配信サービスのアカウント、公開ファイルを書き換える権限も管理します。サービス提供者に任せる範囲と、自分たちで保守する範囲を決めておきます。

CMSの記事が改ざんされ、その内容を生成・配信すれば、静的サイトにも改ざんは反映されます。バックアップと変更履歴を残し、問題が起きたときに元へ戻せるようにしておきます。

CMSは、必要な機能と運用体制で選ぶ

テーマやプラグインを活用し、記事の管理から公開までをまとめて扱いたい場合は、WordPressのようなカップルド型が選択肢になります。

会社案内やサービス紹介、お知らせなど、訪問者ごとに内容を変える必要が少ないサイトでは、デカップルド構成と静的配信を検討できます。管理側への接続を限定したい場合や、CMSのメンテナンス中も公開ページを表示し続けたい場合に向いています。

会員ごとの画面やリアルタイムの予約・決済が中心なら、動的な処理をどこで行うかも含めて設計します。CMSの名称だけで判断せず、「閲覧時にどのシステムが動くか」「管理側を止めたときに何が使えなくなるか」「誰が更新と保守を担当するか」を確認すると、必要な構成を選びやすくなります。