WordPress フルサイト編集で構築サイトの全体制御を取り戻す
要約
WordPress フルサイト編集（FSE）は2026年に実務フェーズを迎えた。新規インストールの68%がブロックベース。このフォリオは最小ブロックテーマの構造、サイトエディターの5エリア、パターンオーバーライドの実務活用、そして本番環境での既知の課題を実務者目線で解説する。
WordPress フルサイト編集で構築サイトの全体制御を取り戻す
WordPress フルサイト編集（FSE）は2026年時点で成熟期を迎えた。WordPress 6.9では、新規サイトの68%がブロックベースのアーキテクチャをデフォルトで採用している。クラシックPHPテーマを納品し続けているフリーランサーやエージェンシーにとって、FSEを採用するかどうかはもはや問題ではない。問題は、本番ワークフローを壊さずにどう移行するかだ。
このフォリオはメカニクスを扱う。宣伝文句ではなく。WordPress 6.8および6.9で動く実クライアントサイトでテスト済みだ。
TL;DR: WordPress フルサイト編集（FSE）は2026年に実務フェーズを迎えた。新規インストールの68%がブロックベース。このフォリオは最小ブロックテーマの構造、サイトエディターの5エリア、パターンオーバーライドの実務活用、そして本番環境での既知の課題を実務者目線で解説する。
FSEが何を変え、何を残したか
従来のWordPressでは、テーマの構造はPHPファイルの階層で定義されていた。header.php、footer.php、single.php、archive.php。FSEはこの構造をブロックに置き換える。しかし、完全に置き換えるのではない。
残るもの：PHPのカスタマイズ性、プラグインエコシステム、REST APIとの親和性。変わるもの：テンプレートの編集がブロックエディターで完結し、PHPを書かずにヘッダーやフッターを変更できる。
「クラシックテーマのほうが自由度が高い」という声を現場でよく耳にする。短期的にはその通りかもしれない。しかし、クライアントへの引き渡し後のメンテナンス性を考えると、FSEのほうが優れている場合が多い。実際の現場データがそれを示している。
最小限のブロックテーマ - 3つのファイル
ブロックテーマに必要な最小ファイルは3つだ。
style.css- テーマのヘッダー情報templates/index.html- デフォルトテンプレートtheme.json- スタイル定義とブロック設定
これだけで、WordPressはそのディレクトリをブロックテーマとして認識する。functions.phpは不要だ。必要になれば追加できるが、最初から必要というわけではない。
templates/index.htmlの最小構成は、ヘッダー、フッター、メインコンテンツの3ブロックをcore/template-partとcore/post-contentで組み合わせる。実務では、この最小構成から始めてファイルを追加していく方法が安全だ。最初から全テンプレートを用意すると、どのファイルが何をしているかを把握するのが難しくなる。
WordPress 6.9のサイトエディター - 5つのエリアと1つの階層
WordPress 6.9のサイトエディターは5つのエリアで構成される。
ナビゲーション - グローバルナビゲーションの管理
スタイル - theme.jsonのビジュアルエディター
ページ - 個別ページの編集
テンプレート - 投稿タイプやアーカイブのテンプレート
パターン - 再利用可能なブロックのコレクション
これらのエリアは1つの階層で管理される。スタイルで定義したカラーパレットは、テンプレートでもパターンでも使える。この一貫性がFSEの強みだ。
実務での注意点がある。サイトエディターで加えた変更は、データベースのwp_postsテーブルにポストタイプwp_templateとして保存される。テーマファイルの変更ではなく、DBオーバーライドとして保存される。これはバージョン管理の観点から課題になりうる点だ。
テンプレートパーツ - 正しい抽象化、間違った使い方
テンプレートパーツ（core/template-part）は、ヘッダーやフッターのような繰り返し要素を切り出すための仕組みだ。正しく使えば、複数のテンプレート間でヘッダーを一元管理できる。
よく見かける間違いは、テンプレートパーツを乱用することだ。セクションごとにテンプレートパーツを作ると、管理が複雑になる。目安として、サイト全体で共通して使う要素のみをテンプレートパーツにするべきだ。
また、テンプレートパーツにはArea（エリア）の概念がある。header、footer、sidebar、uncategorizedの4種類。このエリア設定は、将来のWordPressバージョンでのUI表示に影響する可能性があるため、適切に設定することを推奨する。
クエリーループブロック - PHPなしのPHPループ
core/queryブロック、いわゆるクエリーループは、従来のWP_Queryをブロックエディターで表現したものだ。カスタム投稿タイプの一覧表示、タクソノミーフィルター、ページネーションをPHPなしで実現できる。
実務で確認した制限がある。クエリーループはtax_queryの複雑なネストには対応していない。複数のタクソノミーをANDで組み合わせる場合、queryブロックのカスタムqueryVarsフックが必要になる。この制限はWordPress 6.9時点でも解消されていない。
theme.json - 何を制御し、何を委任するか
theme.jsonはWordPress 6.7でv3になった。このファイルはサイトの設計言語を定義する。
制御できること：カラーパレット、タイポグラフィスケール、スペーシングプリセット、ボーダー設定、ブロックごとのスタイル。
委任すること：インタラクション（ホバー、フォーカス）の複雑な状態は依然としてカスタムCSSに依存する。複数のブレイクポイントにまたがるレスポンシブ対応も、theme.jsonだけでは完結しない場合がある。
theme.jsonのベストプラクティスは、グローバル設定を最初に定義し、ブロック固有の設定をその後に重ねることだ。ブロック固有の設定でグローバル設定を上書きできる。この順序を守ると、スタイルの優先順位が明確になる。
パターンオーバーライド - ロック構造、上書き可能コンテンツ
WordPress 6.8で導入されたパターンオーバーライドは、2026年のクライアント引き渡しにおける最重要機能の一つだ。Block Bindings APIのcore/pattern-overridesソースを使う。
仕組みはシンプルだ。パターン内の特定ブロック（見出し、テキスト、画像など）を「上書き可能」としてマークする。クライアントはパターンの構造を崩さずに、指定されたコンテンツのみを編集できる。
フリーランサーやエージェンシーにとっての実務的価値：クライアントがサイトのデザインを崩す問題を防止できる。「このテキストだけ変えてください」という指示が、技術的に強制できるようになった。これは2026年のFSE活用において、最も実務的なアップデートの一つだ。
本番環境でまだ壊れること
率直に書く。FSEはまだ完璧ではない。2026年時点での既知の問題を記録しておく。
テンプレートのDBオーバーライド問題：サイトエディターで加えた変更はDBに保存される。テーマファイルへの変更でこのオーバーライドが競合する場合がある。Git管理が複雑になる点だ。
RTLのギャップ：右から左（RTL）言語（アラビア語、ヘブライ語）のサポートは改善されているが、複雑なネストブロックでのRTL表示にはまだ課題がある。RTL対応サイトを構築する場合は、早い段階でテストすることを強く推奨する。
ネストDOMの深さ：ブロックのネストが深くなると、DOMの深さが増す。パフォーマンスに影響を与える場合がある。Core Web Vitalsを計測しながら構築することを推奨する。
FSE実務で使えるツール
現場で実際に使っているツールを挙げる。
Create Block Theme プラグイン：既存テーマのブロックテーマへのエクスポートに使える。
Gutenberg プラグイン：コアに先行してFSE機能を試せる。
Block Visibility プラグイン：条件分岐での表示制御に。
WP-CLI：テンプレートのエクスポートとインポートの自動化に不可欠。
noonwpのPattern Forgeは、FSEパターンの作成と管理に特化したツールだ。Monk（無料）プランから利用できる。
よくある質問
FSEはすべてのWordPressサイトに適用できますか？
技術的には適用できますが、既存のクラシックテーマからFSEへの移行は段階的に行うべきです。WordPress 6.9では「ハイブリッドテーマ」として一部のみFSEを採用することも可能です。
theme.jsonとカスタムCSSはどちらを優先すべきですか？
まずtheme.jsonで定義し、対応できない部分のみカスタムCSSを使うアプローチを推奨します。theme.jsonで定義した設定はブロックエディターのUIにも反映されるため、一貫性が高まります。
パターンオーバーライドはどのWordPressバージョンから使えますか？
WordPress 6.8から利用できます。Block Bindings APIが必要です。
クエリーループブロックはカスタム投稿タイプに対応していますか？
対応しています。サイトエディターでクエリーループを追加する際に、対象の投稿タイプを選択できます。ACF（Advanced Custom Fields）などのプラグインと組み合わせることで、より複雑なクエリーも実現できます。
FSEテーマの本番環境への移行で最初に確認すべきことは何ですか？
Core Web Vitals（特にLCP）とRTL対応を最初に確認することを推奨します。次に、クライアントが実際に使うフローでサイトエディターを操作してもらい、想定外の変更が起きないかテストします。
サイトエディターで加えた変更をGit管理するにはどうすればよいですか？
WP-CLIのwp block-theme exportコマンドを使い、DBのテンプレートオーバーライドをテーマファイルとして書き出す方法が現時点のベストプラクティスです。
実際のクライアントサイトで試してほしい。それが最短の学習経路だ。