クラシックテーマとブロックテーマの設計思想比較：開発者が選ぶべき道

実装を始めてからテーマの方式を変えると、単にファイルを置き換えるだけでは済まない。管理画面で積み上げた設定、カスタム投稿の表示ロジック、編集者が慣れた運用フロー、プラグインとの接続。すべてが移行コストになる。

WordPressのクラシックテーマとブロックテーマを比較するとき、機能の多さだけを見ると判断を誤る。見るべきなのは、サイトを誰が、どの頻度で、どこまで変更するのか。そして、開発者がどの部分をコードで固定し、どの部分を編集画面に開くのかという設計思想だ。

クラシックテーマは「PHPで表示を制御する」ための仕組み

クラシックテーマの基本構成は、style.css、functions.php、index.phpを中心としたPHPテンプレートだ。投稿ページならsingle.php、固定ページならpage.php、カテゴリーならcategory.phpというように、表示したいコンテンツの種類に応じてテンプレートを分けていく。

この方式の強みは、表示ロジックを細かく制御できることにある。

テンプレート階層に沿ってファイルを配置し、ループの中で投稿データを取得する。条件分岐で特定の投稿タイプだけ表示を変える。フックを使って、WordPress本体やプラグインの処理に介入する。開発者にとっては、どこで何が出力されるのかを追いやすい。

もちろん、追いやすいのは開発者にとってだ。編集者から見ると、サイト全体のレイアウトはテーマファイルの中に隠れている。ヘッダーの構造を変えたい、記事一覧のカード数を変えたい、フッターの文言を差し替えたい。こうした変更には、テーマ編集、子テーマ、カスタマイズ画面、追加CSSなど、複数の経路が存在する。

この自由度が、クラシックテーマの魅力であり、運用上の負債にもなる。

フックが支える拡張性と、追跡しにくさ

クラシックテーマでは、functions.phpに処理を集約し、アクションフックやフィルターフックを利用して機能を追加する。SEO用のメタ情報、記事一覧の表示変更、管理画面の項目追加、ウィジェットエリアの登録など、実務で必要になる多くの処理に対応できる。

プラグインとの接続も、クラシックテーマの設計では重要な論点だ。

たとえば、プラグインが提供するカスタム投稿タイプをテーマ側で表示し、独自のテンプレートに差し替える。あるいは、本文中の特定ブロックに応じて、ページ上部に補助情報を表示する。こうした実装では、PHPとフックの組み合わせが今でも有効だ。

ただし、フックによる拡張は、規模が大きくなるほど依存関係の把握が難しくなる。

どのプラグインがどのフックに処理を追加しているのか。テーマ側のフィルターが、別のプラグインの出力を上書きしていないか。子テーマのfunctions.phpに追加された処理が、数年後も必要なのか。コード量よりも、処理の接続点が増えることが問題になる。

クラシックテーマの難しさは、PHPを書けることではない。増え続けるフックとテンプレートの関係を、運用期間中ずっと説明できることだ。

クラシックテーマを採用するなら、テンプレートの責務を最初に分けておきたい。表示だけを担当するファイル、データ取得を担う処理、管理画面の設定、外部サービスとの連携。これらをfunctions.phpに集めると、短期的には速い。しかし、後から仕様変更が入ったときに、どこを触るべきか分からなくなる。

クラシックテーマが向いているサイト

クラシックテーマは、古い方式だから選んではいけないというものではない。既存資産を活用するサイトでは、むしろ合理的な選択になる。

次のような条件では、クラシックテーマを継続する理由がある。

• 既存のPHPテンプレートに複雑なカスタムロジックが組み込まれている
• 独自の投稿タイプやフィールドと、テンプレートの結びつきが強い
• 編集者がレイアウトを自由に変えるより、決められた入力項目に沿って運用する
• 利用中のプラグインや社内ツールがクラシックテーマ前提で構築されている
• 子テーマや独自プラグインを含めた既存の開発体制が安定している

この場合、ブロックテーマへの移行は「新しいから」という理由だけでは正当化できない。移行によってユーザーの痛みが減るのか、更新速度が上がるのか、保守コストが下がるのか。仮説を置いて検証する必要がある。

ブロックテーマは「編集画面をサイト全体の操作面にする」

ブロックテーマは、クラシックテーマとは設計の出発点が異なる。WordPress 5.9で本格導入されたフルサイト編集に対応し、テンプレートはPHPファイルではなく、主にtemplates/配下のHTMLファイルで構成される。

サイトのタイトル、ナビゲーション、投稿一覧、フッター。これまでテーマファイルに定義していた要素を、ブロックの組み合わせとして扱う。外観の編集画面から、ページ本文だけでなく、サイト全体の構造を操作できる点が大きい。

Twenty Twenty-Two以降、WordPressのデフォルトテーマはブロックテーマが標準になった。この流れからも、WordPressが編集体験の中心をブロックへ移していることは読み取れる。

ただし、ブロックテーマは「PHPが不要になるテーマ」ではない。ここを誤解すると、設計の初期段階で大きくつまずく。

theme.jsonが担うデザインシステム

ブロックテーマの中心にあるのがtheme.jsonだ。色、フォント、余白、レイアウト幅、ブロックごとの設定など、エディターとフロントエンドで共有したいデザインルールを、一元的に定義できる。

クラシックテーマでは、CSS、カスタマイザー設定、ウィジェット、テーマ独自の設定画面などに分散しがちだった情報を、ひとつの設計思想に寄せやすい。

これは単なる設定ファイルの置き換えではない。デザインを「ページごとの個別調整」から「再利用できる設計ルール」へ移す動きだ。

たとえば、見出しの文字サイズをページごとにCSSで指定するのではなく、テーマが提供するサイズ設定として定義する。コンテンツ幅や余白をブロック単位で場当たり的に調整するのではなく、テーマ全体のプリセットとして設計する。編集者が画面上で変更できる範囲を、コード側で制御できる。

この差は、サイトの成長局面で効いてくる。

ページ数が増えたとき、編集者が増えたとき、ブランドルールが変更されたとき。個別ページに散らばった装飾を修正するのか、テーマの設定を変更するのか。修正の単位が変われば、施策の速度も変わる。

ブロックテーマのメリットは「編集の自由」だけではない

ブロックテーマの開発メリットとして、管理画面からサイト全体を編集できる点がよく挙げられる。しかし、プロダクトグロースの視点では、自由度そのものよりも、変更可能な範囲を設計できる点に価値がある。

編集者にとっては、開発者へ依頼せずに変更できる箇所が増える。開発者にとっては、毎回コード修正をしなくても済む小さな変更が増える。結果として、施策の仮説検証を短いサイクルで回しやすくなる。

ただし、自由度を上げればコンバージョンが改善するとは限らない。ブロックを並べられるようにした結果、ページごとに余白や見出しのデザインがばらばらになることもある。編集者が迷い、更新が止まることもある。

編集画面に何でも開放するのではなく、ユーザーの痛みを解消するために必要な操作だけを残す。これがブロックテーマ設計の重要な仮説になる。

クラシックテーマとブロックテーマの違いを構造で比較する

WordPressのクラシックテーマとブロックテーマを比較するとき、見た目の違いから入ると本質を逃しやすい。比較すべきなのは、テンプレート、設定、編集者の操作、データの保存先、拡張方法だ。

この表で見落としたくないのは、ブロックテーマが単に「HTMLで書くテーマ」ではないことだ。テーマの責務をPHPからHTMLへ移すだけでは、ブロックテーマの利点は出にくい。

テーマを構成するパーツをブロックとして捉え、デザイン設定をtheme.jsonに集約し、編集画面での変更範囲を管理する。ここまで含めて、ブロックテーマの設計になる。

データの保存先が変わると、運用の考え方も変わる

クラシックテーマとブロックテーマの違いは、ファイル構成だけではない。管理画面で行ったカスタマイズが、どのようにデータとして保存されるかも変わる。

クラシックテーマでは、テーマカスタマイザーなどで設定したデータは主にwp_optionsテーブルに保存される。サイト全体の設定をオプションとして扱う、従来型の設計だ。

一方、ブロックテーマでサイトエディターから行ったカスタマイズは、wp_postsテーブルに保存される。カスタム投稿タイプやリビジョン管理の仕組みが使われるため、編集内容を投稿に近いデータとして扱える。

ここには、移行時に見落としやすいリスクがある。

テーマファイルだけを差し替えればデザインが移行できると思っていても、管理画面上で行ったカスタマイズがデータベース側に残っている場合がある。逆に、旧テーマの設定を削除したつもりでも、別の場所に値が残り続けるケースも考えられる。

特に、次のようなデータは切り分けて扱いたい。

• テーマファイルに定義されたテンプレート
• カスタマイザーに保存されたサイト設定
• サイトエディターで上書きされたテンプレート
• ブロックパターンや再利用可能な構成
• プラグインが管理する投稿データや設定
• リビジョンとして残された過去の編集内容

テーマ移行の検証では、画面が表示できるかだけでは不十分だ。管理画面でどの設定が引き継がれ、どの設定が初期化され、どの設定が残るのかを確認する必要がある。

表示確認だけでは、移行の成否を判断できない

移行直後にトップページが表示されても、次の更新で問題が出ることがある。

記事を新規作成したときに意図したレイアウトにならない。編集者が変更できるはずのパーツが操作できない。サイトエディターで修正した内容がテーマ更新によって期待どおりに扱われない。こうした問題は、初回の表示確認だけでは見つからない。

私はテーマ移行を、画面の移し替えではなく、運用フローの再設計として捉えるようにしている。見るべき指標はページの表示速度だけではない。更新作業にかかる時間、開発者への依頼件数、編集ミスの発生箇所、修正の再現性。これらが実際の運用でどう変化するかが重要だ。

数字を取るなら、移行前に仮説を置いておく。

たとえば、毎回コード修正が必要だった告知ページの更新を、編集者だけで完了できるようにする。あるいは、サイト全体の余白変更を複数のCSSファイルではなく、theme.jsonの設定変更で管理する。施策の目的が明確なら、移行後に何を検証すべきかも見えてくる。

ブロックテーマ開発でPHPはどこに残るのか

ブロックテーマを選んだ場合でも、PHPとJavaScriptが消えるわけではない。カスタムブロックの開発、動的なデータ取得、フォーム処理、外部サービス連携など、アプリケーションとしての処理は引き続き必要になる。

ここを「ブロックテーマなら技術的な実装が不要」と捉えると、設計が破綻する。

ブロックテーマが変えるのは、主にテーマと編集画面の責務だ。サイトの骨格や基本的なレイアウトをブロックで管理しやすくする。一方で、複雑なデータ処理や独自のビジネスロジックまで、すべてをブロックだけで解決する必要はない。

動的なコンテンツは、テーマとプラグインを分けて考える

WordPressでは、テーマは見た目、プラグインは機能を担うという整理がよく使われる。ただし現実のプロジェクトでは、テーマに多くの機能が入り込んでいることも珍しくない。

クラシックテーマからブロックテーマへ移行する際、この境界を整理する機会が生まれる。

サイトのブランド表現やレイアウトはテーマ側に置く。予約、会員、検索、外部データ連携など、テーマ変更後も残るべき機能はプラグイン側に置く。カスタムブロックについても、テーマ固有の見た目なのか、サイト全体で継続利用する機能なのかを分けておく。

この分離ができていないと、テーマ移行が機能移行に変わってしまう。作業範囲が膨らみ、どの変更がコンバージョンに寄与したのか分からなくなる。

ブロックの再利用性は、設計品質に左右される

ブロックを使えば再利用できる。しかし、再利用できることと、再利用しやすいことは違う。

一つのブロックに多数の設定項目を詰め込めば、さまざまな表示に対応できる。その反面、編集者はどの設定を触るべきか迷う。逆に、用途ごとに細かくブロックを分割しすぎると、管理画面の選択肢が増えて運用が重くなる。

ここでも必要なのは、機能の最大化ではなく、運用上の摩擦を減らす仮説だ。

• 編集者が毎週変更する項目は、編集画面から操作できるようにする
• ブランドルールに関わる項目は、theme.jsonやテーマ側で制約する
• 複数ページで同じ構成を使う部分は、パターンとして再利用する
• データ取得や計算処理は、見た目のブロックから切り離す
• 変更頻度が低く、壊れると影響が大きい部分は自由にしすぎない

ブロックテーマのメリットを引き出すには、ブロックを増やすより、編集者が迷わない操作面を作ることが先になる。

ブロックテーマの価値は、誰でも自由に作れることではない。必要な変更だけを、必要な人が、壊さずに実行できることにある。

ハイブリッドテーマは、移行を一括イベントにしない

クラシックテーマとブロックテーマの間には、二者択一ではない選択肢がある。クラシックテーマにtheme.jsonを追加し、ブロックスタイルのサポートを取り入れる。既存のPHPテンプレートを残しながら、部分的にブロック機能を利用する。いわゆるハイブリッドテーマだ。

個人開発や小規模チームでは、この段階的な移行が現実的な場面も多い。

すでに公開されているサイトを一度にブロックテーマへ置き換えると、見た目の差分だけでなく、編集フローやデータ管理の差分まで同時に発生する。問題が起きたときに、テーマ構造の変更が原因なのか、データ移行が原因なのか、編集画面の変更が原因なのかを切り分けにくい。

ハイブリッド構造なら、変更単位を小さくできる。

段階的に移行する場合の進め方

移行を始める前に、現在のテーマを機能ではなく運用単位で棚卸しする。ファイル数を数えるだけでは足りない。どのページが頻繁に更新され、どのテンプレートが売上や問い合わせに関わり、どの部分に編集者の不満が集中しているかを見る。

進め方としては、次の順番が扱いやすい。

1. 変更頻度と事業影響でページを分ける

更新頻度が高く、変更のたびに開発者が介入しているページを優先候補にする。ほとんど変更されないページから着手しても、運用改善の効果は測りにくい。

2. テーマとプラグインの責務を確認する

テーマ内にある機能のうち、テーマを変更しても残すべき処理を分離する。ここを後回しにすると、ブロック化の作業と機能整理が混ざる。

3. theme.jsonでデザインルールを定義する

色、文字サイズ、余白、コンテンツ幅など、サイト全体で共通化したい値を整理する。既存CSSをそのまま移植するのではなく、何をルールとして管理するかを決める。

4. 編集者が触る領域を限定して試す

サイト全体を開放する前に、ヘッダーやフッター、特定のランディングページなど、影響範囲を区切って運用する。

5. 編集時間と修正依頼を比較する

移行前後で、ページ更新に必要な時間、開発者への依頼件数、表示崩れの発生状況を記録する。効果が見えなければ、ブロック化する範囲を見直す。

6. テンプレートの上書き状態を確認する

テーマファイルだけでなく、サイトエディター側に保存されたテンプレートやリビジョンも確認する。ファイルを更新したのに画面が変わらない場合、データベース側のカスタマイズが優先されている可能性がある。

この手順のポイントは、移行を技術イベントではなく検証可能な施策として扱うことだ。ブロックテーマを導入すること自体を成功条件にしない。更新速度が上がったのか、ユーザーの痛みが減ったのか、保守の予測可能性が高まったのか。評価対象はそこに置く。

「将来性」だけでクラシックテーマを捨てない

クラシックテーマの将来性を不安視する声はある。WordPressがブロックエディターとフルサイト編集を拡張している以上、今後の新しい設計がブロック中心になる可能性は高い。

しかし、現時点でクラシックテーマがWordPressから利用できなくなる、あるいは即座に廃止されると断定することはできない。既存サイトには既存の要件があり、PHPテンプレートとフックを活用した資産も残っている。

判断を「新しいか、古いか」にすると、必要以上に移行を急いでしまう。

見るべきなのは、次のような実務上の差だ。

保守性で比較する

クラシックテーマでは、テンプレート階層とPHPの構造を把握できる開発者がいれば、細かい表示変更に対応しやすい。一方で、フックやCSSの上書きが重なると、変更の影響範囲を見積もりにくくなる。

ブロックテーマでは、共通のデザイン設定をtheme.jsonへ寄せやすい。サイトエディターで変更した内容を編集履歴として扱える点も、運用上の利点になる。ただし、編集者が自由に上書きした結果、テーマ側の意図と実際の表示がずれることがある。

保守性は、方式だけで決まらない。設計ルールと更新手順があるかどうかで大きく変わる。

拡張性で比較する

複雑な条件分岐や外部データ連携は、クラシックテーマのPHPテンプレートと相性がよい場合がある。既存の実装を大きく変えずに機能を追加できるからだ。

ブロックテーマは、ページ構造やパーツの再利用に向いている。編集者がページを組み替えたり、サイト全体のスタイルを一定の範囲で調整したりする運用では、変更の速度を上げやすい。

ただし、拡張性を「何でも追加できること」と定義すると、どちらを選んでも複雑化する。将来追加したい機能をリストアップし、その機能がテーマに属するのか、プラグインに属するのか、ブロックとして提供するのかを先に整理する必要がある。

編集者の自走性で比較する

サイト運営者が頻繁にレイアウトを変更するなら、ブロックテーマの編集体験は有力だ。開発者への依頼を減らし、コンテンツ施策の検証サイクルを短くできる可能性がある。

一方で、編集者が本文と画像だけを更新し、レイアウト変更をほとんど行わないサイトでは、ブロックテーマの自由度が余計な選択肢になることもある。

自走性を高めるために必要なのは、自由な編集環境ではない。迷わず正しい変更ができる環境だ。

新規開発なら、ブロックテーマを第一候補にする

新規サイトで、特別な制約がない場合。私はブロックテーマを第一候補に置く。

理由は、WordPressの現在の編集体験と、デザイン設定の方向性に合っているからだ。theme.jsonでルールをまとめ、テンプレートをブロックで構成し、編集者が必要な範囲をサイトエディターから変更できる。この前提で設計を始めると、後からクラシックテーマの仕組みを無理に再現する必要がない。

ただし、第一候補と決定は違う。

独自の業務ロジックが中心にあるサイトや、既存プラグインとの統合が強いサイトなら、クラシックテーマやハイブリッド構造のほうが開発リスクを抑えられる場合がある。新規開発でも、サイトの目的がコンテンツ運用なのか、業務システムに近いデータ表示なのかで、最適なテーマは変わる。

判断のために、私は次のような問いを使う。

• レイアウト変更を開発者ではなく編集者が行う必要はあるか
• サイト全体のデザインルールを一元管理したいか
• 既存のPHPテンプレートを再利用する価値は大きいか
• 独自投稿タイプや外部データとの結合はどの程度強いか
• 変更の頻度が高いページはどこか
• 編集画面に開放してよい設定と、固定すべき設定は何か
• テーマを変更しても残るべき機能が、テーマ内に混ざっていないか

ここで答えが曖昧なままなら、テーマの方式を先に決める必要はない。まずはサイトの運用モデルを決める。技術選定はその後でよい。

既存サイトの移行判断は「痛みの大きさ」で決める

既存のクラシックテーマをブロックテーマへ移行するかどうか。判断材料は、将来性より現在の痛みだ。

更新のたびにPHP修正が必要で、施策のスピードが落ちている。ページごとのCSSが増え、表示崩れの修正に時間がかかる。編集者が管理画面で変更できる範囲が狭く、開発者への依頼が集中している。こうした問題が継続しているなら、移行を検討する意味はある。

逆に、現在のクラシックテーマが安定しており、更新フローも明確で、変更頻度も低いなら、方式変更そのものが新たなリスクになる。ブロックテーマに移行しても、目的がなければコンバージョンは改善しない。

私なら、移行前に最低限、次のデータを取る。

• 直近の一定期間に発生したテーマ関連の修正依頼数
• 編集者がページ更新を完了するまでの所要時間
• レイアウト変更やCSS修正で発生した不具合
• 特定のページでの離脱率やコンバージョンの変化
• テーマに含まれる機能と、プラグインに含まれる機能の一覧
• カスタマイザーやサイトエディターに保存されている設定の種類

これらは、きれいなレポートを作るための数字ではない。移行後に効果を検証するための基準だ。

「ブロックテーマにしたからモダンになった」という評価では、施策として弱い。更新が速くなったのか。依頼が減ったのか。編集ミスが減ったのか。ページ改善を試せる回数が増えたのか。ユーザーの反応につながる変化まで追いたい。

私が選ぶ基準は、テーマの新しさではなく変更の流れ

WordPressのクラシックテーマとブロックテーマを比較すると、クラシックテーマはコード中心、ブロックテーマは編集画面中心という違いが見えてくる。

ただし、実際のサイトでは完全に分かれるわけではない。ブロックテーマでもPHPは必要になる。クラシックテーマでもブロックエディターやtheme.jsonを部分的に活用できる。重要なのは、サイトの目的に対して、どの変更経路が最も短く、壊れにくいかだ。

クラシックテーマを選ぶなら、PHPテンプレートとフックの責務を整理する。ブロックテーマを選ぶなら、編集の自由度を制御し、theme.jsonをデザインシステムとして設計する。ハイブリッドを選ぶなら、何を残し、何を段階的に置き換えるのかを明確にする。

テーマは、見た目を格納する箱ではない。ユーザーの反応を見ながら、サイトを変えていくための運用基盤だ。

現時点での私の結論はこうだ。新規開発でコンテンツ運用と編集者の自走性を重視するなら、ブロックテーマを軸に仮説を立てる。既存のPHP資産や複雑なカスタムロジックが事業の中心にあるなら、クラシックテーマを無理に捨てない。必要であれば、ハイブリッド構造で移行コストを分割する。

次に試したいことは、テーマ移行そのものではない。まず、更新頻度の高い一つのページを選び、編集者がどこまで自力で変更できるかをブロックテーマで検証することだ。編集時間、修正依頼、表示崩れ、そしてコンバージョン。小さな実験で数字を取り、次の移行範囲を決める。

テーマ選定も、結局は仮説と検証の連続だ。新しい方式を採用することより、ユーザーの痛みを減らす変更を、継続して実行できる構造を作ること。その順番だけは、間違えないようにしたい。

関連記事: Docker Composeの内部ネットワークでコンテナ間通信ができる仕組み 、 Docker導入の分岐点：個人開発でコンテナ化が必要になる基準.