ブロック/FSEは「編集画面」ではない ― WordPress設計思想の転換を俯瞰する
結論
ブロックエディターと FSE（フルサイト編集）は「Classic より使いにくい編集画面」ではありません。サイト全体をブロックという共通単位で構成し、見た目を theme.json で一元管理するという設計思想の転換です。本文だけでなくヘッダー・フッター・テンプレートまでブロックで組み、色・余白・タイポグラフィを一箇所で握る——これが WordPress の「本流」です。Classic や独自ビルダーは実用性こそ高いものの、この本流からは少しずつ乖離していきます。編集画面の好き嫌いで判断していたものは、実はどの設計思想に乗るかという選択だった、というのが本稿の核心です。
この記事はこんな人へ
- ブロックが苦手で、つい Classic エディターに戻している中級制作者
- ページビルダー（Elementor 等）やカスタム CSS で隅々まで作り込んでいる人
- 「ブロックは触りにくい」という体感を、設計思想の話として捉え直したい人
- 数年単位で運用するサイトの保守性・移植性に不安がある人
- 標準（ブロック/FSE）に乗るべきか、今のやり方を続けるべきか迷っている人
よくある認識（近視眼モデル）
- ブロックエディターは「Classic の置き換え版の編集 UI」にすぎない
- FSE は「上級者向けの難しい機能」で、自分には関係ない
- 見た目はテーマの CSS かビルダーで作るもの。
theme.jsonは触らなくていい - ビルダーの独自ブロックは便利だから、全ページそれで作れば問題ない
- カスタム CSS を足せば、ブロックの制約はいくらでも回避できる
これらはどれも「編集画面の使い勝手」というレイヤーで物事を見ています。間違いではありませんが、視座が一段低い。本来は「サイト全体をどの単位で組み、見た目をどこで管理するか」という構造の話なのです。
なぜ天井にぶつかるか
ブロック/FSE には見た目を決める階層が複数あります。ざっくり言うと、theme.json（テーマが定義する初期値・全体の土台）、グローバルスタイル（外観 ＞ エディター内の「スタイル」でサイト全体に上書き）、ブロック個別設定（個々のブロックでの上書き）の三層です。優先順位は 個別 ＞ グローバル ＞ theme.json の方向に強くなります。
ここで「後付け知識」で扱うと迷子になります。全体の見出し色を変えたいのに、過去に各見出しブロックで個別に色を指定していると、グローバルスタイルを変えても個別設定が勝って反映されない。逆に「theme.json をいじったのに変わらない」のは、グローバルスタイルで上書き済みだから、というケースもよくあります。
さらに厄介なのが、ここに手書きの !important 付きカスタム CSS を被せた状態です。三層のさらに外側から強制的に勝ちにいくため、「どこを直せば何が変わるか」の見通しが完全に崩れます。場当たりの上書きを積むほど、後から来た人（未来の自分を含む）が解読できない特定度の沼ができあがる。これが「ブロックは思い通りにならない」という体感の正体であり、天井です。天井は機能の限界ではなく、階層を逆走している運用が作っています。
俯瞰で見る：何が標準になったか
| 観点 | 旧来（Classic／独自ビルダー） | ブロック/FSE（本流） |
|---|---|---|
| 見た目の管理 | テーマCSS・ビルダー設定・個別CSSに分散 | theme.json＋グローバルスタイルに一元化 |
| 構成単位 | ショートコード・独自要素・PHPテンプレート | コアブロック（共通のデータ構造） |
| 編集場所 | エディター（本文のみ）／ビルダー画面 | 外観 ＞ エディター（サイトエディター）でヘッダー〜フッターまで |
| 移植性 | テーマ・ビルダー依存で持ち出しにくい | ブロックは標準仕様なのでテーマを越えて生き残りやすい |
注目すべきは「編集場所」です。Classic では本文しか触れず、ヘッダーやフッターはテーマの PHP の領域でした。FSE では 外観 ＞ エディター（サイトエディター） からサイトの骨格そのものをブロックで編集します。編集の射程が「本文」から「サイト全体」へ広がった——これが FSE の本質です。
WordPress 7.0 で広がったブロックの守備範囲
2026年5月リリースの WordPress 7.0 は、この方向をさらに推し進めました。
- 新コアブロック「Breadcrumbs（パンくず）」が追加。プラグインなしでサイト構造から自動生成される。
- 新コアブロック「Icon（アイコン）」が追加。標準アイコンライブラリを内蔵し、SVGを配置・リサイズ・配色できる。
- Grid ブロックのレスポンシブ化。列数が「上限」として扱われ、画面幅に応じて自動で段数が減る。
- Gallery ブロックのライトボックス対応。「クリックで拡大」時に前後送りやキーボード操作、読み上げに対応。
これまで「プラグインやビルダーで補う」のが当たり前だったパンくず・アイコン・レスポンシブグリッド・ライトボックスが、コア標準で賄えるようになった。本流の守備範囲は着実に広がっています（出典：WordPress News）。
具体シナリオ① Classic 固執で「一元管理」を逃しCSS地獄に
何が起きた：ある制作者は Classic エディターで全記事を書き続け、見た目はテーマの追加 CSS で調整していました。100ページを超えた頃、「本文の基準色・リンク色・見出し下の余白を全体的に変えたい」という依頼が来ます。ところが色も余白も各所のカスタム CSS にバラバラに直書きされ、!important も散在。一括変更どころか、どこを直すと何が壊れるか追えず、ページを一つずつ目視で修正する羽目になりました。
なぜ：見た目の管理場所が「分散」していたからです。theme.json とグローバルスタイルを使っていれば、全体の色・余白・タイポは定義一箇所を変えるだけで全ページに波及したはずでした。
俯瞰の教訓：編集 UI の好みで Classic を選ぶのは自由ですが、その選択は同時に「theme.json による一元管理という最大の恩恵を捨てる」選択でもある、と自覚することが重要です。
具体シナリオ② ビルダー独自ブロックで全ページ作り、テーマ移行で移植不能に
何が起きた：別の制作者は高機能なページビルダーの独自ウィジェットでサイト全体を構築。数年後、テーマを入れ替えようとしたところ、各ページの中身がビルダー独自の形式で保存されていたため、テーマやビルダーを外すとレイアウトが丸ごと崩壊。本文を新環境へ持ち出せず、作り直しに近い工数がかかりました。
なぜ：コンテンツが「標準のブロック（共通のデータ構造）」ではなく「特定ツール依存の形式」で固定されていたからです。
俯瞰の教訓：標準コアブロックで書かれた本文は、テーマやビルダーを越えても素のまま生き残ります。「今の便利さ」と「将来の持ち出しやすさ」はトレードオフであり、長期運用ほど後者の比重が上がります。
では、どう向き合うか（3つの判断軸）
- 標準ブロックで書けているか — 段落・見出し・グループ・カラム・Grid といったコアブロックで実現できないか。独自ブロックやショートコードに逃げる前に、まず標準で組めないかを問う。
- theme.json で管理できているか — 色・余白・フォントを各ブロックに直書きしていないか。全体に効く値は theme.json とグローバルスタイルへ寄せ、個別上書きと
!importantは最後の手段に。 - 5年後にテーマを変えても本文が生き残るか — 今書いているコンテンツは、テーマやビルダーを外しても素のブロックとして残るか。残らないなら、それは「資産」ではなく「特定ツールへの預け金」だと考える。
この3つは「ブロックに全面移行せよ」という話ではありません。標準＝ブロック/FSE を基準点に置いたうえで、あえて外れる判断なのか、知らずに外れているのかでは、数年後の保守コストがまるで違います。
次に読む・関連記事
- 次の講義 → 講義4：AIネイティブ化するWordPress
- 関連 → 講義1：ノーコード依存からの脱却
- 実装ルール → 上級者ガイド 第2回 theme.json
- 土台 → WordPress全体図／全体像ハブ
まとめ
ブロック/FSE への抵抗感は、多くの場合「編集画面の好き嫌い」として語られます。しかし本質は、サイト全体をブロックで構成し、見た目を theme.json で一元管理するという設計思想に乗るかどうかです。Classic に固執すれば一元管理の恩恵を、ビルダー独自形式に頼れば移植性を、それぞれ静かに失います。「標準ブロックで書けているか／theme.json で管理できているか／5年後に本文が生き残るか」——この3軸で、いま自分がどの思想に乗っているかを点検してみてください。
情報確認日：2026年5月29日
