フルサイト編集（FSE）は実務で使える？2026年のWordPressコーディング新常識
サイトのメインコピー
ここに紹介文が入ります。
なぜこのアプローチを採用するのか
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。 ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。 1. 一貫性のあるCSS管理 個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。 2. デザインシステムと同期した直感的な編集 あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。 —実案件でのエピソードと失敗談
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。 しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。 この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。 —やめた方がいいケースと注意点
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。 複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。 その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | | :— | :— | :— | | サイトの要件 | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト | | デザイン仕様 | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン | | 運用の体制 | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 | —長期的な視点から見たテーマ設計
今後のWordPressの方向性を考慮すると、ブロックをベースとしたコンポーネント化（要素パーツ化）の流れがさらに加速していくことは確実です。 従来のPHPテンプレートを用いたサイト開発の手法も依然として有効ですが、将来のメジャーアップデートによってコアブロックの仕様が変化した際にも対応できるよう、段階的にブロックシステムに馴染んでおくことが、長期的な保守性の向上につながります。 テーマ開発においては、デザインを細分化（アトミックデザインの考え方）し、再利用可能なパターンとして切り出す設計手法を身につけておきましょう。これにより、古い構造のテーマを使い続けるリスクを低減し、常に最新の仕様に適合したサイト運用を支援することが可能になります。4. 納品後のクライアント運用を考慮した、フルサイト編集（FSE）におけるブロック制限と管理画面カスタマイズの方法をお伝えします
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ・テーマ：WordPressデフォルトテーマ（Twenty Twenty-Four） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「自由度が高すぎて、クライアントが意図しないレイアウト崩れを起こしてしまうのではないか」 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務に導入する際、このような不安を抱いたことはありませんか。 自由度の高さは、運用の現場では時にリスクとなります。この記事では、制作時のデザインを保ちつつ、クライアントが迷わず安全に更新できる環境を整えるための具体的な制限方法をお伝えします。 この記事でわかること ・編集権限を適切にコントロールし、デザイン崩れを防ぐ方法がわかります ・特定のブロックのみを登録・許可するコードの書き方がわかります ・ブロックの移動や削除を制限する「ロック機能」の使いどころがわかります —
ブロック制限でクライアントの「誤操作」を防ぐ
実務案件において、納品後の更新作業でレイアウトが崩れてしまうトラブルは避けたいものです。フルサイト編集（FSE）が導入された現代のWordPressでは、固定ページや投稿だけでなく、ヘッダーやフッターなどの共通パーツまで直感的に編集できるようになりました。 しかし、すべてを編集可能にしておくと、フォントサイズや色の変更、意図しないブロックの削除によって、ブランドガイドラインから外れたページが作られてしまうことがあります。これを防ぐために、制作者側で「触っていい場所」と「触ってはいけない場所」を明確に区別し、制御する設計が求められます。 具体的には、不要なブロックを非表示にし、特定のブロックのみを使えるように制限するアプローチをとります。 —functions.php で使用可能なブロックを制限する
クライアントの管理画面から、使わないブロック（たとえば、デザインを損なう可能性のある高度なレイアウトブロックなど）を非表示にするコードを紹介します。 この設定を行うことで、投稿画面や固定ページ編集画面の「＋」ボタン（ブロック追加）を押したときに、許可したブロックだけが表示されるようになります。 “`php post->post_type ) { return array( ‘core/paragraph’, // 段落 ‘core/heading’, // 見出し ‘core/image’, // 画像 ‘core/list’, // リスト ); } // それ以外（固定ページなど）は制限しない、または別の定義を返す return $allowed_block_types; } // allowed_block_types_all フックに登録し、エディター読み込み時に実行する add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 ); “`コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。 `allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。 —なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。 内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。 —実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。 それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。 —制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。 また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 | | テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ | —保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。 そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。 —まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。 1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す 2. 不要なブロックは `allowed_block_types_all` フックで非表示にする 3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする 正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。 Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。 実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。 | 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（ブロックテーマ） | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合
・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 | | クラシックテーマ | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合
・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。 しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。 このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。 1. 要件定義での「運用制限」の合意 クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。 2. デザインの自由度と構築工数の検証 FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。 3. 保守運用のロードマップ策定 数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。 FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。 — Web制作のご相談はお気軽にeBIZクリエイトまで 福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。 [お問い合わせはこちら](https://ebiz-create.co.jp/contact/)【動作確認済み環境】 ・WordPress：6.7 ・PHP：8.2 ・確認日：2025年2月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 — 「そろそろフルサイト編集（FSE）を実務に導入すべきか、それとも従来のクラシックテーマ開発を続けるべきか」と悩んだことはありませんか。 WordPressの仕様が変わるたびに、コーダーや開発者にとって「どの技術を選択肢の中心に据えるか」は死活問題です。実際に私自身も、クライアントへの提案や運用のしやすさを考えては、どちらを採用すべきか頭を抱える日々がありました。 フルサイト編集（FSE）とは、ブロックエディターを使ってヘッダーからフッターまでサイト全体を視覚的に編集できるWordPressの機能です。この記事では、10年以上の実務経験から得た知見をもとに、2026年を見据えた技術選定の判断軸を皆さんにシェアします。 ・クラシックテーマとフルサイト編集（FSE）を実務で選ぶための明確な判断基準 ・実際のWeb制作現場でフルサイト編集（FSE）を導入して実感したメリットと課題 ・制作効率をアップさせ、納品後のクライアントによる表示崩れを防ぐコーディング手法 ・長期的なサイト保守やWordPressのアップデートを見据えた開発の選択肢
1. 従来のクラシックテーマ開発とフルサイト編集（FSE）のどちらを選ぶべきか、実務での判断基準を解説します
【動作確認済み環境】 ・WordPress：6.4.3 ・PHP：8.1.22 ・確認日：2024年3月 ・テーマ：Twenty Twenty-Four（FSE検証用）、オリジナルクラシックテーマ（比較用） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「新しいテーマ制作手法のFSE（フルサイト編集）って、本当に実務案件で使えるレベルなのだろうか？」と悩んだことはありませんか。仕様変更のスピードが速く、どのタイミングでシフトすべきか迷いますよね。この記事では、実案件での経験をもとに、現在主流となっている判断基準をシェアします。 この記事でわかること ・クラシックテーマとFSE（フルサイト編集）の技術的な違いがわかります ・実務案件でどちらを採用すべきかの具体的な判断基準がわかります ・FSEを導入する際のメリットと、現時点での注意点がわかります — WordPressのテーマ開発は、従来の「クラシックテーマ」と、ブロックエディターでサイト全体のレイアウトを編集できる「FSE（フルサイト編集）」の2つのアプローチに分かれています。実案件の現場において、これらをどのように使い分けるべきか、具体的な判断基準を見ていきましょう。
クラシックテーマとFSE（フルサイト編集）の違い
クラシックテーマは、`index.php`や`sidebar.php`といったPHPテンプレートファイルに、HTMLとPHP、WordPressのテンプレートタグを記述して構築する従来の手法です。 一方、FSE（フルサイト編集：Full Site Editing）は、テーマの大部分をHTMLファイル（ブロックマークアップ）で構成し、ヘッダーやフッター、サイドバーなどのレイアウトを含めたサイト全体をWordPressの管理画面上（エディター）で直感的に編集できるようにする仕組みです。実際の案件でどちらを採用するかの判断基準
実務において、これらを選択する際の軸となるのは「納品後にクライアントがどこまで自由にレイアウトを変更したいか」と「予算および開発期間」です。 実務における意思決定のフローは以下のようになります。 “`php // 実務でのテーマ選定ロジック（イメージ） if ( $client_needs_layout_change === true ) { // 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合 $selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討 } else { // デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合 $selected_theme_type = ‘classic’; // クラシックテーマが堅実 } “`なぜその基準で判断するのか（内部仕様の違い）
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。 対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。実案件でのエピソード
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。 FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。よくある間違い・ハマりポイント
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。 FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（フルサイト編集） | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合
・複雑な条件分岐やカスタムクエリを多用する大規模サイト | | クラシックテーマ | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合
・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
長期的な視点での考察
WordPressのコア開発はFSEを中心に進められており、将来的にブロックテーマの仕組みがより洗練されていくことは確実です。ただし、クラシックテーマがすぐに使えなくなるわけではありません。下位互換性を重んじるWordPressの姿勢から、長期間にわたり両方の選択肢が提供され続けると考えられます。 現在では、クラシックテーマの安定性を活かしつつ、投稿本文の編集エリアにのみブロックエディターを最適化させて提供する「ハイブリッド」な設計が、多くの実務案件においてバランスの良い解決策となっています。 — Webサイトの制作やカスタマイズ方法、運用の設計でお悩みの際は、お気軽にeBIZクリエイトまでご相談ください。お客様のビジネスに最適な設計をご提案いたします。2. 実際のWeb制作案件でフルサイト編集（FSE）を導入して分かった、メリットと具体的な注意点をご紹介します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ・テーマ：Twenty Twenty-Four（ブロックテーマ） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「フルサイト編集（FSE：ブロックエディターでサイト全体のレイアウトやパーツを視覚的に編集できるWordPressの機能）って、実際の受託案件で本当に使えるレベルなのだろうか？」と悩んだことはありませんか。 従来のクラシックテーマでの制作に慣れていると、新しい制作フローへの移行には慎重になりますよね。 この記事では、実案件での導入を通して見えてきたフルサイト編集のリアルなメリットと、事前に知っておくべき具体的な注意点をシェアします。 この記事でわかること ・実務にフルサイト編集を導入するメリット ・制作現場で直面しやすい具体的な注意点と対策 ・クラシックテーマとの制作フローの違い ・案件ごとにフルサイト編集を採用するかどうかの判断基準 フルサイト編集を実際の制作案件に導入すると、これまでのテーマ開発とは大きく異なるメリットが得られる一方で、特有の注意点にも直面します。実案件での経験をもとに、それぞれのポイントを整理しました。 ◆ 実務で実感した3つのメリット 1. クライアント自身での軽微な修正がスムーズになる ヘッダーやフッター、共通サイドバーなどのパーツ（パターンやテンプレートパーツ）を、HTMLやPHPの知識がないクライアントでも管理画面から直接編集できるようになります。納品後の「テキストを1文字だけ変えたい」といった細かな要望に対して、制作側が都度コードを修正して反映する手間が減り、運用のスピード感が大幅に向上します。 2. 開発時の一貫性を保ちやすい（theme.jsonの活用） テーマ全体のデザインルール（カラーパレット、フォントサイズ、余白など）を「theme.json」という設定ファイルで一元管理できます。エディター上での表示と実際のフロント表示が一致しやすいため、「編集画面と公開画面で見た目が全然違う」というコーダーのストレスが大きく軽減されます。 3. 余分なプラグインを減らせる これまでページビルダー系プラグインを導入して実現していた複雑なレイアウトを、WordPressの標準機能だけで構築できます。プラグインの競合による不具合や、表示速度の低下を防ぐことにつながります。 ◆ 現場で直面した具体的な注意点 1. 自由度が高すぎるゆえのデザイン崩れ パーツを視覚的に編集できるということは、裏を返せば「クライアントが誤って全体のレイアウトやフォント設定を崩してしまうリスク」があるということです。実務では、ユーザーの権限に応じて編集可能なブロックを制限するなどの制御があらかじめ必要になります。 2. バージョンアップによる仕様変更の影響 フルサイト編集は発展途上の機能であるため、WordPressのメジャーアップデート時にエディターのUI（操作画面）や出力されるHTMLの構造、CSSのクラス名が変更されることがあります。保守運用フェーズにおけるメンテナンスコストを考慮しておく必要があります。 3. 従来のPHPテンプレート用関数の知識がそのまま使えない 従来のクラシックテーマで使用していた `get_header()` や `wp_nav_menu()` といった関数をテンプレートファイル（HTMLファイル）内に直接書くことはしません。テーマの構造設計やパーツの呼び出し方が根本的に異なるため、コーダー自身の学習コストが発生します。 ◆ 以前の案件での失敗共有 正直に言うと、初めてフルサイト編集を採用したコーポレートサイトの案件では、事前の権限設定を怠ってしまいました。その結果、納品後にクライアント担当者様が操作した際、共通ヘッダーのナビゲーションリンクを誤って削除してしまい、全ページのヘッダーが崩れるというトラブルが発生しました。 この経験から、弊社では「theme.json」やフックを使って、クライアントが触る必要のないレイアウトやスタイル設定はエディター上でロック（編集不可に）する運用をデフォルトにしています。 ◆ 向いているケース・向いていないケースまとめ | 項目 | 向いているケース | 向いていないケース | |—|—|—| | サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 | | デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト | | 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 | ◆ 保守性・将来性の考察 フルサイト編集は、WordPressロードマップの根幹に位置づけられている機能です。今後のアップデートを考慮すると、ブロックテーマを中心とした制作スタイルへ緩やかにシフトしていくことは、長期的な保守性の観点からも理にかなっています。 ただし、現時点ですべての受託案件をフルサイト編集に切り替える必要はありません。複雑なアニメーションや、管理画面の自由度を極限まで絞り込みたいカスタム投稿主体のサイトなどでは、信頼性の高いクラシックテーマでの構築の方が安全なケースも多々あります。 案件の目的、運用者のスキル、そして将来のアップデートに伴う保守コストを総合的に天秤にかけ、最適なアプローチを都度選択していく判断力が、これからのWeb制作者には求められています。
3. 2026年に向けたWordPressテーマ開発で、制作効率を向上させるための新しいコーディング手法をご提案します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 従来のテーマ制作（クラシックテーマ）では、PHPファイルの中にHTMLとWordPress独自の関数を組み合わせて記述する手法が一般的でした。しかし、フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）の普及に伴い、コーディングの進め方やパーツの共通化の手法は大きく変化しています。 実務で制作効率を向上させ、納品後の運用保守フェーズでも破綻しにくいテーマ構造を作るためには、新しい概念である「ブロックパターン」と「ブロックテンプレート」の仕組みを理解し、適切に設計することが求められます。 この記事では、これからの実務で求められるテーマ開発の新しいコーディング手法と、その設計のポイントを共有します。
この記事でわかること
FSE（フルサイト編集）に対応したテーマ開発における、コンポーネントの新しい管理方法 実務での修正作業を迅速にするためのファイル分割設計 開発効率と自由な編集機能を両立させるブロックパターンの活用基準 —ブロックパターンを「 theme.json 」と組み合わせて活用する
従来のWordPress開発では、共通のレイアウトパーツ（ヘッダーやフッター、特徴セクションなど）を「 `get_template_part()` 」という関数を使用してPHPファイルから呼び出すのが主流でした。 これからの開発では、ブロックを組み合わせたレイアウトを「ブロックパターン」として登録し、テーマ側から提供するアプローチが標準的になります。 “`php ‘ヒーローセクション（メインビジュアル）’, ‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’, ‘content’ => ‘サイトのメインコピー
ここに紹介文が入ります。
なぜこのアプローチを採用するのか
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。 ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。 1. 一貫性のあるCSS管理 個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。 2. デザインシステムと同期した直感的な編集 あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。 —実案件でのエピソードと失敗談
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。 しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。 この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。 —やめた方がいいケースと注意点
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。 複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。 その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | | :— | :— | :— | | サイトの要件 | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト | | デザイン仕様 | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン | | 運用の体制 | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 | —長期的な視点から見たテーマ設計
今後のWordPressの方向性を考慮すると、ブロックをベースとしたコンポーネント化（要素パーツ化）の流れがさらに加速していくことは確実です。 従来のPHPテンプレートを用いたサイト開発の手法も依然として有効ですが、将来のメジャーアップデートによってコアブロックの仕様が変化した際にも対応できるよう、段階的にブロックシステムに馴染んでおくことが、長期的な保守性の向上につながります。 テーマ開発においては、デザインを細分化（アトミックデザインの考え方）し、再利用可能なパターンとして切り出す設計手法を身につけておきましょう。これにより、古い構造のテーマを使い続けるリスクを低減し、常に最新の仕様に適合したサイト運用を支援することが可能になります。4. 納品後のクライアント運用を考慮した、フルサイト編集（FSE）におけるブロック制限と管理画面カスタマイズの方法をお伝えします
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ・テーマ：WordPressデフォルトテーマ（Twenty Twenty-Four） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「自由度が高すぎて、クライアントが意図しないレイアウト崩れを起こしてしまうのではないか」 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務に導入する際、このような不安を抱いたことはありませんか。 自由度の高さは、運用の現場では時にリスクとなります。この記事では、制作時のデザインを保ちつつ、クライアントが迷わず安全に更新できる環境を整えるための具体的な制限方法をお伝えします。 この記事でわかること ・編集権限を適切にコントロールし、デザイン崩れを防ぐ方法がわかります ・特定のブロックのみを登録・許可するコードの書き方がわかります ・ブロックの移動や削除を制限する「ロック機能」の使いどころがわかります —
ブロック制限でクライアントの「誤操作」を防ぐ
実務案件において、納品後の更新作業でレイアウトが崩れてしまうトラブルは避けたいものです。フルサイト編集（FSE）が導入された現代のWordPressでは、固定ページや投稿だけでなく、ヘッダーやフッターなどの共通パーツまで直感的に編集できるようになりました。 しかし、すべてを編集可能にしておくと、フォントサイズや色の変更、意図しないブロックの削除によって、ブランドガイドラインから外れたページが作られてしまうことがあります。これを防ぐために、制作者側で「触っていい場所」と「触ってはいけない場所」を明確に区別し、制御する設計が求められます。 具体的には、不要なブロックを非表示にし、特定のブロックのみを使えるように制限するアプローチをとります。 —functions.php で使用可能なブロックを制限する
クライアントの管理画面から、使わないブロック（たとえば、デザインを損なう可能性のある高度なレイアウトブロックなど）を非表示にするコードを紹介します。 この設定を行うことで、投稿画面や固定ページ編集画面の「＋」ボタン（ブロック追加）を押したときに、許可したブロックだけが表示されるようになります。 “`php post->post_type ) { return array( ‘core/paragraph’, // 段落 ‘core/heading’, // 見出し ‘core/image’, // 画像 ‘core/list’, // リスト ); } // それ以外（固定ページなど）は制限しない、または別の定義を返す return $allowed_block_types; } // allowed_block_types_all フックに登録し、エディター読み込み時に実行する add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 ); “`コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。 `allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。 —なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。 内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。 —実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。 それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。 —制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。 また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 | | テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ | —保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。 そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。 —まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。 1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す 2. 不要なブロックは `allowed_block_types_all` フックで非表示にする 3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする 正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。 Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。 実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。 | 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（ブロックテーマ） | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合
・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 | | クラシックテーマ | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合
・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |
将来的なアップデートへの対応力を見極める
WordPressは、ブロックエディターを中心とした開発ロードマップを明確に進めています。長期的な視点で見れば、FSEに準拠したブロックテーマの方が、コア（WordPress本体）の進化による恩恵を受けやすいのは事実です。 しかし、現段階の実務においては、FSEの仕様変更スピードが速いこと自体が「運用の懸念材料」になるケースもあります。コアのアップデートによって、エディター上の表示ルールやブロックのネスト構造に変更が加わり、過去に納品したサイトの編集画面で一部表示が乱れるといった現象が報告されることもあります。 このようなアップデート対応への工数を、保守契約の範囲内でカバーできる体制があるかどうかも、重要な判断基準となります。実務での採用判断フロー
私たちが実案件で判断に迷った際は、以下の3つのステップで意思決定を行っています。 1. 要件定義での「運用制限」の合意 クライアントが「どこまで自由に触りたいか」をヒアリングします。「お知らせのテキストだけ変えられればいい」という場合は、自由度が高すぎるFSEよりも、クラシックテーマにカスタムフィールドを組み合わせる方が、運用の事故を防げます。 2. デザインの自由度と構築工数の検証 FSEで求められるデザインを実現する場合、ブロックパターンの定義や `theme.json`（ブロックテーマのスタイルや設定を管理するファイル）の細かなチューニングが必要になります。この実装工数が、従来のPHPコーディングに比べて膨らまないかを事前に検証します。 3. 保守運用のロードマップ策定 数年スパンでのサイトリニューアルを想定しているか、あるいは5年以上同じシステムを使い続ける予定であるかを確認します。長期的な利用が前提で、かつ予算に余裕がある場合は、将来性を見据えてFSEベースでの構築を選択肢に入れます。 FSEは素晴らしい進化を遂げていますが、すべての案件に一律に適用するのではなく、クライアントの運用スキルや、アップデート時の保守サポート体制に合わせて最適な構成を使い分ける視点が、実務においては何よりも重要です。 — Web制作のご相談はお気軽にeBIZクリエイトまで 福島県郡山市を拠点に、全国のWeb制作・保守運用をワンストップでサポートしています。WordPressのテーマ選定や、運用を見据えた最適なサイト設計についてお悩みの際は、お気軽にお問い合わせください。 [お問い合わせはこちら](https://ebiz-create.co.jp/contact/)【動作確認済み環境】 ・WordPress：6.7 ・PHP：8.2 ・確認日：2025年2月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 — 「そろそろフルサイト編集（FSE）を実務に導入すべきか、それとも従来のクラシックテーマ開発を続けるべきか」と悩んだことはありませんか。 WordPressの仕様が変わるたびに、コーダーや開発者にとって「どの技術を選択肢の中心に据えるか」は死活問題です。実際に私自身も、クライアントへの提案や運用のしやすさを考えては、どちらを採用すべきか頭を抱える日々がありました。 フルサイト編集（FSE）とは、ブロックエディターを使ってヘッダーからフッターまでサイト全体を視覚的に編集できるWordPressの機能です。この記事では、10年以上の実務経験から得た知見をもとに、2026年を見据えた技術選定の判断軸を皆さんにシェアします。 ・クラシックテーマとフルサイト編集（FSE）を実務で選ぶための明確な判断基準 ・実際のWeb制作現場でフルサイト編集（FSE）を導入して実感したメリットと課題 ・制作効率をアップさせ、納品後のクライアントによる表示崩れを防ぐコーディング手法 ・長期的なサイト保守やWordPressのアップデートを見据えた開発の選択肢
1. 従来のクラシックテーマ開発とフルサイト編集（FSE）のどちらを選ぶべきか、実務での判断基準を解説します
【動作確認済み環境】 ・WordPress：6.4.3 ・PHP：8.1.22 ・確認日：2024年3月 ・テーマ：Twenty Twenty-Four（FSE検証用）、オリジナルクラシックテーマ（比較用） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「新しいテーマ制作手法のFSE（フルサイト編集）って、本当に実務案件で使えるレベルなのだろうか？」と悩んだことはありませんか。仕様変更のスピードが速く、どのタイミングでシフトすべきか迷いますよね。この記事では、実案件での経験をもとに、現在主流となっている判断基準をシェアします。 この記事でわかること ・クラシックテーマとFSE（フルサイト編集）の技術的な違いがわかります ・実務案件でどちらを採用すべきかの具体的な判断基準がわかります ・FSEを導入する際のメリットと、現時点での注意点がわかります — WordPressのテーマ開発は、従来の「クラシックテーマ」と、ブロックエディターでサイト全体のレイアウトを編集できる「FSE（フルサイト編集）」の2つのアプローチに分かれています。実案件の現場において、これらをどのように使い分けるべきか、具体的な判断基準を見ていきましょう。
クラシックテーマとFSE（フルサイト編集）の違い
クラシックテーマは、`index.php`や`sidebar.php`といったPHPテンプレートファイルに、HTMLとPHP、WordPressのテンプレートタグを記述して構築する従来の手法です。 一方、FSE（フルサイト編集：Full Site Editing）は、テーマの大部分をHTMLファイル（ブロックマークアップ）で構成し、ヘッダーやフッター、サイドバーなどのレイアウトを含めたサイト全体をWordPressの管理画面上（エディター）で直感的に編集できるようにする仕組みです。実際の案件でどちらを採用するかの判断基準
実務において、これらを選択する際の軸となるのは「納品後にクライアントがどこまで自由にレイアウトを変更したいか」と「予算および開発期間」です。 実務における意思決定のフローは以下のようになります。 “`php // 実務でのテーマ選定ロジック（イメージ） if ( $client_needs_layout_change === true ) { // 納品後、クライアント自身が直感的にパーツ配置やレイアウトを変えたい場合 $selected_theme_type = ‘fse’; // FSE（ブロックテーマ）を検討 } else { // デザインの再現性が極めて厳密で、表示崩れを防ぎたい場合 $selected_theme_type = ‘classic’; // クラシックテーマが堅実 } “`なぜその基準で判断するのか（内部仕様の違い）
クラシックテーマは、表示されるHTMLを開発者側で完全にコントロールできます。PHPでロジックを制御し、出力されるタグを制限できるため、クライアントが管理画面から入力したことによってサイトのデザインが崩れるリスクを低く抑えられます。 対してFSEは、デザインの自由度をクライアントに渡す仕様です。データベースにブロックの配置情報が保存されるため、HTML構造の自由度が高い反面、意図しない操作によってレイアウトが崩れてしまう懸念があります。実案件でのエピソード
以前、お知らせや簡易的な施工実績をご自身で頻繁に更新したいという企業のWebサイト構築案件がありました。当初はFSEでの構築を検討しましたが、ヒアリングを進めると「デザインガイドラインが厳格で、指定された余白やフォントサイズ以外は一切使わせたくない」というご要望があることが判明しました。 FSEをそのまま導入すると、編集時に余白設定などを自由に変更できてしまうため、あえて管理画面からの自由度を制限できる「クラシックテーマ ＋ カスタム投稿タイプ ＋ カスタムフィールド」の構成で提案しました。結果として、運用後のデザイン崩れに関する問い合わせはゼロに抑えられました。自由度が高ければ良いというわけではなく、運用の体制に合わせた設計が必要です。よくある間違い・ハマりポイント
「新しい機能だから」という理由だけで、100ページを超える大規模なポータルサイトや、複雑なカスタムクエリ（複雑な条件分岐による投稿一覧表示）が多用されるサイトにFSEを全面的に採用するのは、現時点では注意が必要です。 FSEでもクエリーループブロックなどを用いて投稿一覧を出力できますが、PHPによる複雑な引数（WP_Queryのパラメータ）を組み合わせた制御を行う場合、クラシックテーマにテンプレートファイルを用意した方が、コードの可読性や保守性が向上するケースが多々あります。向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（フルサイト編集） | ・納品後、クライアント側でヘッダーやフッター、レイアウトの調整を行いたい場合・シンプルな構成のコーポレートサイトやランディングページ | ・デザインガイドラインが極めて厳格で、表示崩れを徹底的に防ぎたい場合
・複雑な条件分岐やカスタムクエリを多用する大規模サイト | | クラシックテーマ | ・完全オリジナルのデザインを1px単位で厳密に再現したい場合
・複雑なPHPロジックや外部APIとの連携が必要なシステム寄りのサイト | ・クライアントがコードに触れることなく、直感的にヘッダーやレイアウトを自由に変更したい場合 |
長期的な視点での考察
WordPressのコア開発はFSEを中心に進められており、将来的にブロックテーマの仕組みがより洗練されていくことは確実です。ただし、クラシックテーマがすぐに使えなくなるわけではありません。下位互換性を重んじるWordPressの姿勢から、長期間にわたり両方の選択肢が提供され続けると考えられます。 現在では、クラシックテーマの安定性を活かしつつ、投稿本文の編集エリアにのみブロックエディターを最適化させて提供する「ハイブリッド」な設計が、多くの実務案件においてバランスの良い解決策となっています。 — Webサイトの制作やカスタマイズ方法、運用の設計でお悩みの際は、お気軽にeBIZクリエイトまでご相談ください。お客様のビジネスに最適な設計をご提案いたします。2. 実際のWeb制作案件でフルサイト編集（FSE）を導入して分かった、メリットと具体的な注意点をご紹介します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ・テーマ：Twenty Twenty-Four（ブロックテーマ） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「フルサイト編集（FSE：ブロックエディターでサイト全体のレイアウトやパーツを視覚的に編集できるWordPressの機能）って、実際の受託案件で本当に使えるレベルなのだろうか？」と悩んだことはありませんか。 従来のクラシックテーマでの制作に慣れていると、新しい制作フローへの移行には慎重になりますよね。 この記事では、実案件での導入を通して見えてきたフルサイト編集のリアルなメリットと、事前に知っておくべき具体的な注意点をシェアします。 この記事でわかること ・実務にフルサイト編集を導入するメリット ・制作現場で直面しやすい具体的な注意点と対策 ・クラシックテーマとの制作フローの違い ・案件ごとにフルサイト編集を採用するかどうかの判断基準 フルサイト編集を実際の制作案件に導入すると、これまでのテーマ開発とは大きく異なるメリットが得られる一方で、特有の注意点にも直面します。実案件での経験をもとに、それぞれのポイントを整理しました。 ◆ 実務で実感した3つのメリット 1. クライアント自身での軽微な修正がスムーズになる ヘッダーやフッター、共通サイドバーなどのパーツ（パターンやテンプレートパーツ）を、HTMLやPHPの知識がないクライアントでも管理画面から直接編集できるようになります。納品後の「テキストを1文字だけ変えたい」といった細かな要望に対して、制作側が都度コードを修正して反映する手間が減り、運用のスピード感が大幅に向上します。 2. 開発時の一貫性を保ちやすい（theme.jsonの活用） テーマ全体のデザインルール（カラーパレット、フォントサイズ、余白など）を「theme.json」という設定ファイルで一元管理できます。エディター上での表示と実際のフロント表示が一致しやすいため、「編集画面と公開画面で見た目が全然違う」というコーダーのストレスが大きく軽減されます。 3. 余分なプラグインを減らせる これまでページビルダー系プラグインを導入して実現していた複雑なレイアウトを、WordPressの標準機能だけで構築できます。プラグインの競合による不具合や、表示速度の低下を防ぐことにつながります。 ◆ 現場で直面した具体的な注意点 1. 自由度が高すぎるゆえのデザイン崩れ パーツを視覚的に編集できるということは、裏を返せば「クライアントが誤って全体のレイアウトやフォント設定を崩してしまうリスク」があるということです。実務では、ユーザーの権限に応じて編集可能なブロックを制限するなどの制御があらかじめ必要になります。 2. バージョンアップによる仕様変更の影響 フルサイト編集は発展途上の機能であるため、WordPressのメジャーアップデート時にエディターのUI（操作画面）や出力されるHTMLの構造、CSSのクラス名が変更されることがあります。保守運用フェーズにおけるメンテナンスコストを考慮しておく必要があります。 3. 従来のPHPテンプレート用関数の知識がそのまま使えない 従来のクラシックテーマで使用していた `get_header()` や `wp_nav_menu()` といった関数をテンプレートファイル（HTMLファイル）内に直接書くことはしません。テーマの構造設計やパーツの呼び出し方が根本的に異なるため、コーダー自身の学習コストが発生します。 ◆ 以前の案件での失敗共有 正直に言うと、初めてフルサイト編集を採用したコーポレートサイトの案件では、事前の権限設定を怠ってしまいました。その結果、納品後にクライアント担当者様が操作した際、共通ヘッダーのナビゲーションリンクを誤って削除してしまい、全ページのヘッダーが崩れるというトラブルが発生しました。 この経験から、弊社では「theme.json」やフックを使って、クライアントが触る必要のないレイアウトやスタイル設定はエディター上でロック（編集不可に）する運用をデフォルトにしています。 ◆ 向いているケース・向いていないケースまとめ | 項目 | 向いているケース | 向いていないケース | |—|—|—| | サイトの運用体制 | 納品後、クライアント自身でレイアウトや文言を頻繁に更新・追加していきたい場合 | 納品後はテキストの修正程度で、デザインやレイアウトを一切変更させたくない場合 | | デザインの自由度 | ブロックの組み合わせによる、標準的なレイアウトパターンで構成されたサイト | 細部までピクセル単位で厳密に作り込まれた、変則的かつ複雑なデザインのサイト | | 保守・運用の予算 | 定期的なWordPressのアップデート検証や、デザイン保守の予算が確保できる場合 | 初期制作のみで、納品後は一切予算をかけずに放置して運用したい場合 | ◆ 保守性・将来性の考察 フルサイト編集は、WordPressロードマップの根幹に位置づけられている機能です。今後のアップデートを考慮すると、ブロックテーマを中心とした制作スタイルへ緩やかにシフトしていくことは、長期的な保守性の観点からも理にかなっています。 ただし、現時点ですべての受託案件をフルサイト編集に切り替える必要はありません。複雑なアニメーションや、管理画面の自由度を極限まで絞り込みたいカスタム投稿主体のサイトなどでは、信頼性の高いクラシックテーマでの構築の方が安全なケースも多々あります。 案件の目的、運用者のスキル、そして将来のアップデートに伴う保守コストを総合的に天秤にかけ、最適なアプローチを都度選択していく判断力が、これからのWeb制作者には求められています。
3. 2026年に向けたWordPressテーマ開発で、制作効率を向上させるための新しいコーディング手法をご提案します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 従来のテーマ制作（クラシックテーマ）では、PHPファイルの中にHTMLとWordPress独自の関数を組み合わせて記述する手法が一般的でした。しかし、フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）の普及に伴い、コーディングの進め方やパーツの共通化の手法は大きく変化しています。 実務で制作効率を向上させ、納品後の運用保守フェーズでも破綻しにくいテーマ構造を作るためには、新しい概念である「ブロックパターン」と「ブロックテンプレート」の仕組みを理解し、適切に設計することが求められます。 この記事では、これからの実務で求められるテーマ開発の新しいコーディング手法と、その設計のポイントを共有します。
この記事でわかること
FSE（フルサイト編集）に対応したテーマ開発における、コンポーネントの新しい管理方法 実務での修正作業を迅速にするためのファイル分割設計 開発効率と自由な編集機能を両立させるブロックパターンの活用基準 —ブロックパターンを「 theme.json 」と組み合わせて活用する
従来のWordPress開発では、共通のレイアウトパーツ（ヘッダーやフッター、特徴セクションなど）を「 `get_template_part()` 」という関数を使用してPHPファイルから呼び出すのが主流でした。 これからの開発では、ブロックを組み合わせたレイアウトを「ブロックパターン」として登録し、テーマ側から提供するアプローチが標準的になります。 “`php ‘ヒーローセクション（メインビジュアル）’, ‘description’ => ‘トップページの上部に配置する、画像とテキストのブロックレイアウトです。’, ‘content’ => ‘サイトのメインコピー
ここに紹介文が入ります。
なぜこのアプローチを採用するのか
これまでの開発では、静的なHTML/CSSで構築されたデザインをWordPressに組み込む際、管理画面で編集できる箇所をカスタムフィールドに依存しがちでした。しかし、カスタムフィールドを多用しすぎると、表示用のPHPファイルを変更しなければレイアウトを変更できないという、制作者側の二度手間が発生していました。 ブロックパターンと、スタイルを制御する「 `theme.json` 」ファイルを組み合わせる手法を採用すると、以下の内部的なメリットが得られます。 1. 一貫性のあるCSS管理 個別の要素に対して独自のクラス名を付与してCSSを記述するのではなく、`theme.json`にカラーパレットやフォントサイズ、余白のルールを定義しておくことで、エディターが自動的に最適なCSSカスタムプロパティ（CSS変数）を出力します。これにより、コードの肥大化を防ぎ、サイト全体の一貫性を保ちやすくなります。 2. デザインシステムと同期した直感的な編集 あらかじめ検証済みのブロックパターンを用意しておくことで、クライアントが追加のページを作成する際にも、デザインルールを崩すことなく、高品質なコンテンツをセルフサービスで構築できるようになります。 —実案件でのエピソードと失敗談
正直に言うと、フルサイト編集の過渡期には「すべてをブロックエディターで編集できるようにした方が便利だろう」と考え、テンプレートの全パーツをクライアントが自由に操作できるフルブロックテーマとして納品したことがありました。 しかし、納品後すぐに「フォントサイズが変わってしまった」「意図しない位置に余白が入って表示が崩れた」といったトラブルの対応に追われることになりました。自由度が高すぎる設計は、専門知識を持たない運用の現場においては、かえってデザイン崩れを引き起こす原因になってしまったのです。 この時の苦い経験から、私たちは「全体をブロックテーマ化する」のではなく、「クラシックテーマの安定性と、必要な部分にだけブロックパターンを提供するアプローチ」を組み合わせたハイブリッドな設計を実務のデフォルトにするようになりました。 —やめた方がいいケースと注意点
すべてのサイトで最新のFSE手法を採用すればよいというわけではありません。 複雑なアニメーションや、動的な条件分岐（「特定の会員ステータスのみ表示を変える」など）が各所に埋め込まれているオリジナルデザインのサイトの場合、ブロックエディターで視覚的に管理しようとすると、かえってコードが複雑化し、開発効率が著しく低下することがあります。 その場合は、無理にブロックエディター上でフルサイト編集を行おうとせず、信頼性の高い「クラシックテーマ」の構成で、管理画面の特定のセクションにのみブロックパターンを組み込む手法をお勧めします。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | | :— | :— | :— | | サイトの要件 | 納品後、クライアント側で頻繁に新ページの作成やランディングページの構成変更を行うサイト | ガチガチにレイアウトが固定されており、文字と画像の差し替えのみを行う静的なコーポレートサイト | | デザイン仕様 | グリッドシステムに準拠し、コンポーネント（要素パーツ）化がしやすいデザイン | 複雑なオブジェクトが絡み合う、1ページごとに大きく異なる前衛的なデザイン | | 運用の体制 | 編集担当者がサイト全体の更新活動に意欲的で、レイアウトの操作方法を習得できる場合 | IT知識が乏しい担当者が1人で管理しており、極力操作箇所を制限したい場合 | —長期的な視点から見たテーマ設計
今後のWordPressの方向性を考慮すると、ブロックをベースとしたコンポーネント化（要素パーツ化）の流れがさらに加速していくことは確実です。 従来のPHPテンプレートを用いたサイト開発の手法も依然として有効ですが、将来のメジャーアップデートによってコアブロックの仕様が変化した際にも対応できるよう、段階的にブロックシステムに馴染んでおくことが、長期的な保守性の向上につながります。 テーマ開発においては、デザインを細分化（アトミックデザインの考え方）し、再利用可能なパターンとして切り出す設計手法を身につけておきましょう。これにより、古い構造のテーマを使い続けるリスクを低減し、常に最新の仕様に適合したサイト運用を支援することが可能になります。4. 納品後のクライアント運用を考慮した、フルサイト編集（FSE）におけるブロック制限と管理画面カスタマイズの方法をお伝えします
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ・テーマ：WordPressデフォルトテーマ（Twenty Twenty-Four） ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「自由度が高すぎて、クライアントが意図しないレイアウト崩れを起こしてしまうのではないか」 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務に導入する際、このような不安を抱いたことはありませんか。 自由度の高さは、運用の現場では時にリスクとなります。この記事では、制作時のデザインを保ちつつ、クライアントが迷わず安全に更新できる環境を整えるための具体的な制限方法をお伝えします。 この記事でわかること ・編集権限を適切にコントロールし、デザイン崩れを防ぐ方法がわかります ・特定のブロックのみを登録・許可するコードの書き方がわかります ・ブロックの移動や削除を制限する「ロック機能」の使いどころがわかります —
ブロック制限でクライアントの「誤操作」を防ぐ
実務案件において、納品後の更新作業でレイアウトが崩れてしまうトラブルは避けたいものです。フルサイト編集（FSE）が導入された現代のWordPressでは、固定ページや投稿だけでなく、ヘッダーやフッターなどの共通パーツまで直感的に編集できるようになりました。 しかし、すべてを編集可能にしておくと、フォントサイズや色の変更、意図しないブロックの削除によって、ブランドガイドラインから外れたページが作られてしまうことがあります。これを防ぐために、制作者側で「触っていい場所」と「触ってはいけない場所」を明確に区別し、制御する設計が求められます。 具体的には、不要なブロックを非表示にし、特定のブロックのみを使えるように制限するアプローチをとります。 —functions.php で使用可能なブロックを制限する
クライアントの管理画面から、使わないブロック（たとえば、デザインを損なう可能性のある高度なレイアウトブロックなど）を非表示にするコードを紹介します。 この設定を行うことで、投稿画面や固定ページ編集画面の「＋」ボタン（ブロック追加）を押したときに、許可したブロックだけが表示されるようになります。 “`php post->post_type ) { return array( ‘core/paragraph’, // 段落 ‘core/heading’, // 見出し ‘core/image’, // 画像 ‘core/list’, // リスト ); } // それ以外（固定ページなど）は制限しない、または別の定義を返す return $allowed_block_types; } // allowed_block_types_all フックに登録し、エディター読み込み時に実行する add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_block_types’, 10, 2 ); “`コードの書き方とタイミング
上記のコードは、使用しているテーマの「functions.php（テーマの機能を追加・カスタマイズするファイル）」に記述します。 `allowed_block_types_all` という「filter hook（フィルターフック：データを加工・変換する仕組み）」を利用しており、エディターが読み込まれるタイミングで、表示可能なブロックの配列（リスト）をフィルタリングして上書きしています。 —なぜこの制御が必要なのか（内部仕様とメリット）
WordPressの標準機能のままでは、インストールされているすべてのブロック（サードパーティ製プラグインが追加するものも含めて）がエディターに表示されます。選択肢が多すぎると、更新担当者がどのブロックを使えばよいか迷ってしまいます。 内部的には、許可リスト（ホワイトリスト形式）でブロックを制限することで、不要なスクリプトの読み込みストレスを軽減し、管理画面のUIをシンプルに保つ効果があります。また、HTMLの構造を壊されたくない重要なエリアには、テンプレートロックをかけるアプローチも有効です。 —実案件での失敗から学んだ「守り」の設計
正直に言うと、フルサイト編集を導入し始めた初期の案件では、クライアントへの引き渡し後に「文言を変えようとしたら、文字の大きさがバラバラになって元に戻せなくなった」という連絡を何度もいただきました。自由度を提供することが、必ずしも親切ではないと痛感した経験です。 それ以来、私たちのチームでは、見出しの階層（H2、H3など）や使用するカラーパレットをあらかじめテーマ側（theme.jsonなど）で固定し、上記のようなブロック制限コードを案件ごとに必ず組み込む仕様にしています。 —制限をかける際のはまりポイントと注意点
すべてのブロックを制限しすぎると、将来的に「新しいコンテンツを追加したい」となった際に、クライアント自身で対応できなくなります。 また、プラグインを導入した際に追加される便利なブロックまで非表示にしてしまうケースがあるため、制限をかける際は「投稿（お知らせなど）」と「固定ページ（サービス紹介など）」で、制限の強弱を分ける設計が望ましいです。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | ブロックの制限 | 更新担当者がWebの専門知識を持たない場合、複数人で運用する場合 | 社内にインハウスのWebデザイナーがおり、自由なレイアウト構築が求められる場合 | | テンプレートロック | 会社概要やお問い合わせなど、レイアウトを崩したくないページ | ランディングページのように、日々構成をテストして入れ替えるページ | —保守性と将来性を見据えたアプローチ
WordPressのフルサイト編集（FSE）は、今後もアップデートによって機能が拡張されていきます。独自の制限コードを複雑に書きすぎると、WordPress本体のメジャーアップデート時にフックの仕様が変わり、管理画面が正常に動かなくなるリスクがあります。 そのため、過度なカスタマイズコードを書き連ねるのではなく、WordPress標準の「theme.json」によるカラーパレット制御や、ブロックパターンを活用した運用のルール作りなど、極力シンプルな機構で標準機能に準拠した設計をしておくことが、長期的な保守性の担保につながります。 —まとめ：安全な運用環境を作るためのステップ
クライアントが迷わず、かつデザインの統一感を損なわずに運用できる環境を作るためには、以下のステップで設計を整理することをおすすめします。 1. 運用担当者が「本当に投稿で使うブロック」をヒアリングして洗い出す 2. 不要なブロックは `allowed_block_types_all` フックで非表示にする 3. 色やフォントサイズは個別指定させず、事前に定義したパレットから選ぶルールにする 正解は一つではありませんが、運用の負荷を減らし、長く愛されるWebサイトにするための設計を心がけたいものです。 Web制作やWordPressのカスタマイズ、運用保守に関するお困りごとがございましたら、いつでもお気軽にeBIZクリエイトまでご相談ください。丁寧にお話を伺い、最適な解決策を一緒に形にいたします。5. 将来的な保守性とアップデートへの対応力から考える、フルサイト編集（FSE）の採用判断プロセスを共有します
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 フルサイト編集（FSE：ブロックエディターでサイト全体を編集できるWordPressの新機能）を実務で採用すべきか。この問いに対する答えは、単に「技術的に可能か」だけでは導き出せません。納品後の保守フェーズにおけるクライアントの運用体制や、WordPress自体のメジャーアップデートにどこまで追従できるかという「将来的な保守性」を天秤にかける必要があります。 実案件で長く安定したサイト運用を支えるために、私たちが普段どのような基準でFSEの採用を判断しているか、その具体的なプロセスを共有します。
クライアントの運用リテラシーとカスタマイズ要求度で整理する
FSEを導入する最大の分岐点は、「誰が、どこまでサイトを修正するのか」という運用の設計にあります。クラシックテーマ（従来のPHPテンプレートを主体としたテーマ）とFSE（ブロックテーマ）の特性を比較しながら、どちらが適しているかを検討します。 | 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（ブロックテーマ） | ・クライアント自身でレイアウトやヘッダー・フッターを頻繁に変更したい場合・運用コストを下げ、ノーコードに近い形で更新を完結させたい場合 | ・デザインのミリ単位の再現性を厳格に求められる場合
・クライアントが誤って全体のレイアウトを崩してしまうリスクを避けたい場合 | | クラシックテーマ | ・独自に設計した高度なカスタムフィールドと連動した表示を行いたい場合
・編集制限を厳しく設定し、運用時の表示崩れを未然に防ぎたい場合 | ・ちょっとしたバナー追加やナビゲーションの変更も、都度制作会社に依頼する必要があり、スピード感を重視する運用の構成には不向きな場合 |