ブロックテーマとクラシックテーマ：正直な比較

テーマフォルダを開いてください。中に index.html を含む templates ディレクトリがあり、ルートに theme.json があれば、それはブロックテーマです。index.php が header.php や footer.php と並んでいて、管理画面のサイドバーに外観からカスタマイザーが表示されるなら、クラシックテーマです。

この構造上の違い 1 つが、誰がサイトの何を変更できるか、その変更がどこに保存されるか、そして WordPress のプラグインエコシステムのどちら側が正常に動くかを決めています。

30秒でできる見分け方

手がかり	クラシックテーマ	ブロックテーマ
ルートのテンプレートファイル	index.php	templates/index.html
ヘッダーとフッター	header.php、footer.php	parts/header.html、parts/footer.html
全体設定	functions.php	theme.json（加えて任意で functions.php）
管理メニュー	外観 > カスタマイザー	外観 > エディター
編集内容の保存先	ディスク上のファイル	データベース（wp_template 投稿として）
ウィジェット画面	あり	なし

WordPress は templates/index.html があるかどうかで判定します。theme.json を持ちながら PHP テンプレートを維持しているテーマは、依然としてクラシック扱いです。この中間状態はよくあるもので、名前もあります。後述します。

シェルが使えるなら、コマンド 1 つで決着します。

wp eval 'var_dump( wp_is_block_theme() );'

自分が作ったのではないサイト、とくにページビルダーが通常の管理メニューを隠している場合、WP-CLI がいちばん速い確認方法です。

サイトを編集する人にとって何が変わるか

クラシックテーマでは、ヘッダー、フッター、サイドバー、色、ロゴはカスタマイザーの向こう側にあり、テーマ作者が作ることに決めたコントロールしか使えません。フッターの著作権表示にコントロールが用意されていなければ、コントロールは存在しません。PHP ファイルを編集するか、そのまま使うかの二択です。

ブロックテーマでは、サイトエディターがページ全体を開放します。ヘッダー、フッター、ループ、404 ページ、検索結果のレイアウト、そのすべてがブロックであり、PHP を見たこともない人が編集できます。これが本当の目玉機能であり、その価値は本当に大きいものです。

その代償が、PHP を見たこともない人がすべてを編集できてしまう、ということです。クライアントは深夜 2 時にヘッダーからサイトタイトルを削除でき、そこから復元できるバージョン履歴はディスク上にありません。あるのはサイトエディター自身のリビジョンだけです。ブロックのロックや、エディターに到達できる人の制限で締めることはできますが、それは自分で忘れずにやる必要のあるオプトインの作業です。

実務で効いてくる小さめの損失が 2 つあります。ブロックテーマにはウィジェット画面がなく（ウィジェットエリアはテンプレートパーツとブロックに置き換わります）、クラシックなメニューはナビゲーションブロックに置き換わり、その項目は見慣れたメニュー画面ではなく別のコンテンツタイプとして保存されます。

開発者にとって何が変わるか

クラシックテーマは PHP のテンプレート階層を使います。WordPress は既知の連鎖 — single-{post-type}.php、次に single.php、次に singular.php、次に index.php — をたどってリクエストを解決し、あなたのファイルが実行され、get_header() を呼び、ループを回し、1 文字単位で制御できるマークアップを出力します。

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

ブロックテーマは同じ階層の名前を .html 拡張子で使いますが、ファイルの中身はブロックマークアップ、つまりコメント形式のブロック区切りを含む HTML であり、テンプレートタグは存在しません。

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

開発者がすぐにぶつかる帰結が 3 つあります。

get_header() と get_footer() は実行されません。 プラグインや古い子テーマがこれらのアクションにフックしていても、何も起きずに終わります。wp_head と wp_footer は発火するのでエンキュー処理はたいてい生き残りますが、ヘッダー固有のフックは動きません。

データベースがファイルに勝ちます。 誰かがサイトエディターでテンプレートを保存した瞬間、WordPress はその版を wp_template 投稿として保存し、あなたのファイルの代わりにそれを配信します。午後いっぱい HTML ファイルを編集しても、フロントエンドの変化はゼロです。そのテンプレートのカスタマイズを消せば、ファイル版に戻ります。これは「ブロックテーマが壊れた」という報告で最も多い原因であり、バグではありません。

スタイリングが theme.json に移ります。 色、余白スケール、タイポグラフィー、ブロックごとのデフォルトは、CSS ではなくデータとして宣言し、CSS は WordPress が生成します。より整理されていて一貫性もはるかに高いのですが、スキーマで表現できないものが必要になった途端、結局 CSS を書くことになり、生成されたルールとの詳細度争いが始まります。

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

version の値は、使っている WordPress のリリースに対して必ず確認してください。スキーマは何度か改訂されており、古いチュートリアルからバージョン番号をコピーすると、設定が黙って無視される状態になります。

なお functions.php がなくなるわけではありません。ブロックテーマでも、エンキュー、add_image_size の登録、カスタム投稿タイプ、その他 PHP の処理には引き続き使います。ただ、そこでテンプレートの仕事をすることが大幅に減るだけです。

実際に得るもの、実際に失うもの

ブロックに移って得るもの： ページ全体をエディターで制御できること、theme.json によって強制されるデザインの一貫性、維持するファイルの少なさ、そしてエディターとフロントエンドの見た目がクラシックテーマ時代よりはるかに一致すること。

ブロックに移って失うもの： 出力マークアップの直接的な制御、フックによる素直なカスタマイズ、PHP テンプレートを前提とするものとの互換性、そしてサイトの見た目がバージョン管理に載っているという安心感。

最後の 1 つは強調に値します。クラシックテーマなら git log が何が変わったかを教えてくれます。ブロックテーマでは、サイトの見た目のかなりの部分が、デプロイパイプラインの視界に入らないデータベースに存在します。

クラシックテーマがいまだに正解である場面

• ページビルダーがサイトを動かしている。 Elementor、Divi、Beaver Builder などのツールは、テンプレートの役割を自分で引き受けます。その下にブロックテーマを敷いても、何もしない 2 つ目のテンプレートシステムが増えるだけです。
• マークアップが厳密でなければならない。 独自のコンポーネントライブラリ、厳格なアクセシビリティ対応のマークアップ、特殊な構造化データ要件など。ブロックの出力はブロックが吐くものに縛られ、それと戦うコストは PHP を書くコストを上回ります。
• プラグインのテンプレートを多用している。 会員制、LMS、ディレクトリ、古めの EC 拡張は、PHP のテンプレートオーバーライドを同梱していることが多いものです。ブロック版があるものも増えましたが、ないものも多く残っています。
• サイトが完成していて、問題なく動いている。 5 年分のカスタマイズが積み上がったテーマに、ブロックへのアップグレード経路はなく、あるのは作り直しだけです。「新しいやり方だから」はビジネス上の理由になりません。
• 編集するのは自分だけ。 サイトエディターの最大の利点は、非開発者に制御を渡せることです。非開発者がいないなら、誰も使わない利点のためにコストだけ払っていることになります。

ハイブリッドという中間解

クラシックテーマに theme.json を追加すれば、PHP テンプレートとカスタマイザーを保ったまま、グローバルスタイルの仕組み、色と余白のプリセット、一貫したエディタースタイルが手に入ります。WordPress はこれをブロックテーマとは呼ばず、サイトエディターも使えないままですが、デザインシステムの恩恵の大半を、はるかに少ない作業量で得られます。

おおむね問題なく動いている既存サイトなら、これがたいてい正しい第一手です。theme.json を追加し、パレットと余白を定義し、それが置き換える CSS を削除して、そのうえで残りが本当に必要かを判断してください。