よくある間違いとして、すべてのブロックをDynamic Blockにしてしまうケースがあります。エディター上でのリッチなプレビュー表示や、複雑なインタラクションが求められるブロックにおいては、Reactベースの静的ブロックの方が適している場合もあります。目的に応じて使い分けることが重要です。

長期的に見てこの選択は、WordPressが推進するフルサイト編集（FSE）の方向性とも合致します。データとプレゼンテーション層を切り離すことで、テーマの切り替えや大規模リニューアル時の負担を大幅に軽減できるからです。保守・メンテナンス契約において、クライアントに安定した運用環境を提供するためにも、こうした内部設計の意思決定は慎重に行う必要があります。

Web制作のご相談はお気軽にeBIZクリエイトまでお問い合わせください。

3. フルサイト編集導入時に現場で直面する課題と安全な移行プロセス

フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）への移行を検討する際、既存のクラシックテーマからそのまま切り替えてしまうと、予期せぬレイアウト崩れや機能の喪失といったトラブルにつながるケースが少なくありません。

実際の案件でも、企業サイトのリニューアルでフルサイト編集を導入した際、既存のショートコードや複雑なカスタムフィールド（独自の入力項目を追加する機能）が、そのままではうまくブロックとして配置できないという問題に直面しました。この経験から、現在ではいきなり本番環境を切り替えるのではなく、段階的な移行プロセスを推奨しています。

フルサイト編集を安全に導入するためには、以下のステップを踏むことが重要です。

1. 検証環境での徹底的なテスト
必ずローカル環境やステージング環境を用意し、そこでブロックテーマを有効化して影響範囲を洗い出します。
2. 独自機能のブロック化または代替機能の選定
これまでfunctions.php（テーマの機能を追加・カスタマイズするファイル）やPHPテンプレートに直書きしていた独自の処理を、カスタムブロックとして開発するか、既存のコアブロックで代替できないかを検証します。
3. theme.jsonによるスタイルの一元管理
デザインの制御は、従来のstyle.cssではなく、theme.json（テーマのスタイルやエディターの設定を定義するファイル）に集約させます。

なぜtheme.jsonによる管理が推奨されるのかというと、WordPressのエディター画面とフロントエンド（実際のサイト表示）のデザインを完全に一致させるためです。CSSで無理に上書きをしてしまうと、管理画面のブロックエディター上での見た目と実際の公開ページの表示にズレが生じ、お客様が運用する際の混乱を招きます。内部でどのように動いているかというと、theme.jsonに記述した設定はWordPressによって自動的にCSSカスタムプロパティ（変数）として出力され、各ブロックに適用される仕組みになっています。

ここで、フルサイト編集導入の判断基準を整理します。

複雑なシステム要件がある既存サイトの場合、無理にフルサイト編集へ完全移行するのは避けた方が良いケースもあります。そのような場合は、クラシックテーマを維持しながら、投稿や固定ページの編集部分にだけブロックエディターの機能を活用するハイブリッドなアプローチを代替案として検討します。

しかし、WordPress公式（https://wordpress.org）の開発の方向性は明確にフルサイト編集を軸に進められています。長期的な保守性や将来のメジャーアップデートへの対応まで考えると、新規のWeb制作案件においては、ブロックテーマの採用を前提とした設計方針を取り入れていくのが今後のスタンダードな判断になると考えています。迷ったときは、サイトの要件と運用体制を照らし合わせて、無理のない移行計画を立てることが何よりも大切です。

4. Web制作の効率を向上させるtheme.jsonの基本設計と活用方法

フルサイト編集（FSE）を前提としたテーマ制作において、要となるのが`theme.json`です。実際の案件でも、このファイルの設計次第で、後のスタイル調整や運用フェーズでの手間が大きく変わることを実感しています。

従来は`style.css`や`functions.php`に分散して記述していたカラーパレットやタイポグラフィ、レイアウトの基本設定などを、一つのファイルで一元管理できるのが`theme.json`の最大の利点です。

まずは、実務ベースでベースとなる基本的な構造を見ていきます。このファイルは、テーマフォルダの直下に配置します。

// 配置場所: テーマのルートディレクトリ (例: wp-content/themes/your-theme/theme.json)
{
"version": 2,
"settings": {
"color": {
// ユーザーによるカスタムカラーの選択を制限
"custom": false,
// テーマ専用のカラーパレットを定義
"palette": [
{
"slug": "primary",
"color": "#005baa",
"name": "メインカラー"
},
{
"slug": "secondary",
"color": "#e5e5e5",
"name": "サブカラー"
}
]
},
"typography": {
// 任意のフォントサイズ指定を無効化
"customFontSize": false
},
"layout": {
// コンテンツの標準幅と最大幅を設定
"contentSize": "800px",
"wideSize": "1200px"
}
}
}

この書き方が推奨される理由は、エディター上でのデザインの破綻を防ぐためです。内部的な動きとして、`theme.json`で定義した値は、エディター側とフロントエンド側の両方にCSS変数（カスタムプロパティ）として自動的に出力されます。つまり、エディターと実際の表示の差異をなくす仕組みが最初から用意されているということです。

以前、あるコーポレートサイトの案件で、クライアントがエディターから独自の鮮やかな色を自由に追加してしまい、全体のトーン＆マナーが崩れてしまった問題に直面しました。その際、上記のように`”custom”: false`を設定してカラーパレットを制限することで、デザインのガイドラインを強制しつつ、運用しやすさを保つことができました。この制限機能は、現在では当社の案件のデフォルト設定としています。

やりがちですが注意が必要な間違いとして、`theme.json`の記述エラーがあります。JSON形式であるため、末尾のカンマの有無や閉じカッコの不一致など、わずかな構文エラーでエディター全体が白画面になることがあります。編集時は必ずJSONの構文チェックツールを使用し、検証環境で確認を重ねることが大切です。

また、すべてのスタイルを無理に`theme.json`に詰め込むのは避けた方が良いケースもあります。複雑なアニメーションや、特定のブロックに対する高度なレスポンシブ調整などは、依然として従来の`style.css`で管理した方が見通しが良くなります。

長期的に見て、WordPress本体はブロックエディターとフルサイト編集の機能を拡張し続けており、その中心には常に`theme.json`が存在します。CSS変数を用いたモダンなフロントエンド開発とも親和性が高く、将来のメジャーアップデートの影響を吸収する設計思想となっています。デザインシステムをコードとして管理するアプローチは、今後のWeb制作においてますます重要になります。

迷ったときは、サイト全体の「ルール」に関わるものは`theme.json`に、個別の「例外的な装飾」はCSSに、と切り分けて考えると整理しやすいです。

5. 今後のWordPress案件で求められるブロックベース構築の柔軟な対応策

実際の案件でフルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入する際、クライアントから「どこまで自分たちで変更できるのか」というご質問をよくいただきます。

実務の現場では、すべてのサイトを完全なブロックテーマで構築することが常に最適な選択になるとは限りません。既存のシステムと連携が必要な場合や、特定の固定レイアウトを厳格に守りたい場合など、クラシックテーマの要素を残した「ハイブリッドテーマ」というアプローチを採用することが多々あります。

例えば、以前コーポレートサイトのリニューアル案件を担当した際、クライアントは日常的なお知らせやコラムの更新はブロックエディターで柔軟に行いたい一方で、トップページやサービス紹介ページはデザインの崩れを防ぐために固定しておきたいというご要望をお持ちでした。

その際の解決策として、基本はクラシックテーマとして構築しつつ、`theme.json`を導入してGutenberg（ブロックエディター）のカラーパレットやタイポグラフィの制御だけを有効にするハイブリッド対応を行いました。

以下は、その際に使用した`theme.json`の基本的な記述例です。

{
"version": 2,
"settings": {
"appearanceTools": true,
"color": {
"palette": [
{
"name": "メインカラー",
"slug": "primary",
"color": "#0056b3"
},
{
"name": "サブカラー",
"slug": "secondary",
"color": "#f8f9fa"
}
],
"custom": false,
"customGradient": false
},
"typography": {
"customFontSize": false,
"dropCap": false
}
}
}

この設定を行うことで、ユーザーが自由に独自の色や極端なフォントサイズを指定する機能（`custom`や`customFontSize`を`false`に設定）を制限しつつ、あらかじめ定義したブランドカラーだけを選択させることが可能になります。

このように、WordPressの機能が進化しても、それをどう制御し、クライアントの運用体制に合わせて制限をかけるかという設計の視点が、今後のWeb制作において非常に重要になってきます。

迷ったときは、「クライアントの運用体制」と「デザインガイドラインの厳格さ」を軸に考えると整理しやすいです。運用者がどこまで自由に触れるべきか、その権限と機能のバランスを設計段階でしっかりと協議することが、納品後のトラブルを防ぐ鍵となります。