【動作確認済み環境】
・WordPress：6.5
・PHP：8.2
・確認日：2026年2月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「ブロックエディターへの移行、実際のところ実務でどこまで使えるの？」
最近のサイトリニューアル案件で、お客様や開発チームからよくこのようなご相談をいただきます。FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）の機能が充実してくる中、使い慣れたクラシックテーマを維持するべきか、新しい設計に踏み切るべきか迷う場面は少なくありません。

正直に言うと、私も以前は従来のテーマ構築を好んでいました。しかし、納品後の更新しやすさや長期的な保守体制を考慮し、現在はプロジェクトの要件に合わせて柔軟に設計手法を使い分けるようにしています。

この記事では、実際のWeb制作現場で直面した課題から得た、フルサイト編集の活用法と、Gutenbergを実務に落とし込むための具体的な判断基準をシェアします。

■ この記事でわかること
・フルサイト編集を実案件で導入する際の具体的な注意点
・クラシックテーマから移行するケースとそうでないケースの判断基準
・運用者が更新しやすいブロックパターンの管理とエディター最適化の方法
・保守性を考慮したカスタムブロック開発の実践的なアプローチ

1. 実案件から見えたフルサイト編集の活用ポイントと注意点

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認時期：最新バージョンリリース時
・テーマ：Twenty Twenty-Four
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

企業のコーポレートサイトリニューアル案件で、お客様から「自社で自由にレイアウトを変更できるようにしてほしい」というご要望をいただくことが増えてきました。クラシックエディターや従来のテーマ開発で対応するか、それともFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）を導入するか、判断に迷う場面があるのではないでしょうか。

この記事では、実際のWeb制作現場でFSEを導入した際に見えてきたメリットと、事前に知っておくべき注意点をシェアします。

・実務におけるFSEのメリットと課題がわかります
・案件ごとの適切な導入判断基準がわかります
・保守性を高めるための具体的な設計のヒントがわかります

WordPressのFSEは、ヘッダーやフッター、アーカイブページといった従来はPHPテンプレートで構築していた部分も含め、すべてブロックエディター上で視覚的に組み立てることができる機能です。これにより、HTMLやPHPの知識を持たない運用担当者でも、サイト全体のデザインを直感的に調整できるようになります。

実際の案件では、FSEに対応したブロックテーマをベースに構築し、theme.jsonという設定ファイルでサイト全体のカラーパレットやタイポグラフィ、余白のルールを一元管理します。これにより、デザインの統一感を保ちながら、柔軟なページ作成が可能になります。

このアプローチが推奨される理由は、WordPressのコア開発が完全にブロックベースの設計へとシフトしているためです。内部的には、各ブロックの設定やスタイルがHTMLのコメントタグとしてデータベースに保存され、出力時にパースされる仕組みになっています。従来のfunctions.phpでの煩雑なフック処理を減らし、theme.jsonによる宣言的なスタイル管理に移行することで、コードの記述量を大幅に削減できます。

以前、更新頻度の高いメディアサイトの案件で、思い切ってFSEを全面採用しました。納品直後はお客様も「自由に作れて素晴らしい」と喜ばれていたのですが、運用が進むにつれてトラブルが発生しました。運用担当者が誤って共通のヘッダーテンプレートのブロックを削除してしまい、全ページのレイアウトが崩れてしまったのです。

この経験から、FSEを導入する際は「編集できる自由」と「壊れない安全性」のバランスを設計することが非常に重要だと痛感しました。現在では、お客様に引き渡す前に、theme.jsonやブロックのロック機能を活用して、編集可能な領域と固定すべき領域を明確に制限する設計を実案件のデフォルトにしています。

やりがちですが避けた方がよいのは、クラシックテーマに無理やり部分的なFSEの機能を継ぎ接ぎで導入することです。設定ファイルと従来のCSSが複雑に絡み合い、スタイルの優先順位の制御が非常に困難になります。新規構築や全面リニューアルのタイミングで、最初からブロックテーマとして設計し直す設計が安全です。

長期的な保守性や将来性まで考えると、WordPressコミュニティ全体がFSEとGutenbergブロックの開発に注力しているため、この技術要素を取り入れていくことは自然な流れです。ただし、メジャーアップデートのたびにブロックの仕様やインターフェースが微細に変更される可能性があるため、保守契約の中で定期的な動作検証とお客様への操作サポートを含めた体制を整えておくことが求められます。

迷ったときは、お客様の運用体制とリテラシーを軸に考えるとうまく整理しやすいです。自由に作れる反面、レイアウト崩れのリスクも伴うため、事前のヒアリングでどこまでの操作権限を渡すのが最適かを見極めることが、FSE導入を成功させる鍵となります。

2. クラシックテーマからGutenbergへ移行する際の判断基準

【動作確認済み環境】
・WordPress：6.4
・PHP：8.1
・確認日：最新
・テーマ：Twenty Twenty-Four / 独自クラシックテーマ
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

長年運用してきたWordPressサイトをクラシックテーマのままにしておくべきか、それともGutenberg（ブロックエディター）やフルサイト編集（FSE）に対応した新しい構成に移行するべきか。実際の制作現場でも、リニューアルのタイミングで最も多くご相談いただくテーマの一つです。

「とりあえず新しいものに変えれば良い」というわけではありません。実際の案件で両方のパターンを経験してきた中で見えてきた、移行に踏み切るかどうかの判断基準をシェアします。

移行の目的を明確にする

クラシックテーマからGutenbergへ移行する最大のメリットは、「更新担当者がHTMLやCSSを意識せずに、直感的にリッチなページを作れるようになること」です。

一方で、現状の運用で全く困っていない場合や、決まったフォーマットのテキストと画像を流し込むだけのシンプルなブログ機能しか使っていない場合は、急いで移行するメリットは薄いかもしれません。

まずは、「誰が、どのようなコンテンツを、どのくらいの頻度で更新するのか」を整理することが重要です。

移行コストと学習コストの見積もり

Gutenbergへの移行は、単にテーマを変更するだけでは済まないケースがほとんどです。過去にクラシックエディターで作成した記事をブロックエディターで編集しようとすると、レイアウトが崩れたり、クラシックブロックという一つのブロック内にまとめて格納されてしまい、ブロックごとの柔軟な編集ができなかったりします。

数千記事あるメディアサイトの場合、全記事をGutenbergのブロックに変換する作業（マイグレーション）は非現実的です。そのため、「過去記事はクラシックエディターのまま（またはクラシックブロックのまま）維持し、新規記事からGutenbergを使う」という運用ルールを設けることが、実務ではよくあります。

また、更新担当者が新しい操作画面（UI）に慣れるための学習コストも考慮する必要があります。「操作方法が変わって更新できなくなった」というトラブルを防ぐためにも、マニュアルの整備やレクチャーの時間を確保できるかどうかも判断材料になります。

向いているケース・向いていないケースまとめ

迷ったときは、以下の表を参考に状況を整理してみてください。

長期的な視点での選択

WordPress本体の開発は、すでにGutenbergやフルサイト編集（FSE）を軸に進められています。クラシックテーマやクラシックエディターのサポートがすぐに打ち切られることはないと考えられますが、将来的な拡張性や、新しいプラグインとの互換性を考えると、どこかのタイミングでGutenbergベースの運用に切り替えていくのが自然な流れと言えます。

「今回は見送る」という決断も立派な選択肢です。しかし、次回の数年後のリニューアル時には、Gutenbergへの移行が必須に近い状況になっている可能性も考慮しておくと良いでしょう。

Web制作のご相談や、WordPressの運用・リニューアルについて迷われていることがあれば、お気軽にeBIZクリエイトまでお問い合わせください。現状のサイト構成や運用体制をヒアリングした上で、最適な方向性を一緒に考えさせていただきます。

3. 現場で役立つブロックパターンの効果的な管理方法

実際のWeb制作案件でフルサイト編集（FSE）やブロックエディターを導入すると、運用担当者から「ブロックパターンが多すぎて、どれを使えばいいのか迷ってしまう」という相談をよく受けます。WordPressにはデフォルトで多くのパターンが用意されていますが、クライアントの運用環境においては、それがかえってノイズになることがあります。

この課題に対して、実務では「不要なデフォルトパターンを無効化し、プロジェクト専用のパターンカテゴリーを作成する」というアプローチをとります。運用者が迷わず正しいデザインを選択できるようにするための設定です。

まずは、WordPressに標準で組み込まれているコアのブロックパターンを非表示にする方法をご紹介します。以下のコードは、テーマの機能を追加・カスタマイズするファイルである`functions.php`に記述します。

// functions.php に記述します
// 初期化のタイミング（init）で実行されるアクションフックを利用します
add_action( 'init', 'ebiz_remove_core_block_patterns' );

function ebiz_remove_core_block_patterns() {
// コアのブロックパターンをテーマのサポートから除外します
remove_theme_support( 'core-block-patterns' );
}

この記述を追加するだけで、エディターのパターン一覧からデフォルトのものが消え、画面が非常にすっきりします。なぜこの処理が必要かというと、ブランドガイドラインから外れたデザインを運用者が意図せず使ってしまうリスクを防ぐためです。

次に、そのプロジェクト専用のカスタムカテゴリーを登録します。同じく`functions.php`に追記します。

// functions.php に記述します
add_action( 'init', 'ebiz_register_custom_pattern_category' );

function ebiz_register_custom_pattern_category() {
// register_block_pattern_category関数を使って新しいカテゴリーを登録します
register_block_pattern_category(
'client-custom-patterns', // カテゴリーの識別子（スラッグ）
array( 'label' => '専用デザインパーツ' ) // 管理画面に表示される名前
);
}

以前、あるオウンドメディアの構築案件で、デフォルトのパターンを残したまま納品したことがありました。結果として、サイト内で統一感のない見出しやボタンが量産されてしまい、後から修正に追われるという失敗を経験しました。それ以来、eBIZクリエイト株式会社の制作現場では、デフォルトパターンの無効化とカスタムカテゴリーの登録をセットで行うことを基本ルールにしています。

この管理方法を導入することで、クライアントは「専用デザインパーツ」というカテゴリーから選ぶだけで、サイトのトーン＆マナーに沿ったページを構築できるようになります。

ただし、すべてのプロジェクトでこの手法が適しているわけではありません。状況に応じた使い分けの判断基準を表にまとめました。

長期的な保守性の観点から見ても、運用者が迷わない環境を構築することは、サイトの品質維持に直結します。WordPressの自由度の高さを活かしつつ、適度な制限を設けることが、結果として使いやすい管理画面を生み出します。迷ったときは、サイトの更新を担当する方がどの程度の自由度を求めているかをヒアリングして判断すると整理しやすいです。

4. 納品後の運用を見据えたエディター画面の最適化手順

クライアントにWebサイトを納品した後、運用担当者から「ブロックが多すぎてどれを使えばいいか迷う」「意図しないデザインになってしまった」というご相談を受けることはありませんか？
FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）が進化する中で、エディターの自由度が高まる反面、運用現場ではその自由度が逆に混乱を招くケースが増えています。
納品後の運用をスムーズにするためには、エディター画面をクライアントの運用スキルに合わせて「最適化（制限）」する工程が欠かせません。

■ 運用を安定させるエディター最適化の基本

最適化の第一歩は、不要なブロックを非表示にし、本当に使うブロックだけを残すことです。
デフォルトのWordPressには数十種類のブロックが用意されていますが、実際の運用で使うのは見出し、段落、画像、リストなど限られたものばかりです。
多すぎる選択肢は、運用者の迷いを生み、サイトのデザインルールを崩す原因になります。
実案件でも、あらかじめ使用するブロックをヒアリングし、それ以外を非表示にする対応を標準化しています。

■ theme.jsonを使ったブロック制御の具体例

エディターの最適化は、functions.php（テーマの機能を追加・カスタマイズするファイル）で制御することも可能ですが、FSE環境では`theme.json`を活用するのが現在の主流です。
以下のコードは、特定の色パレットだけを許可し、ユーザーが独自の色を追加できないようにする設定例です。

{
"version": 2,
"settings": {
"color": {
"custom": false, // カスタムカラーピッカーを無効化
"customGradient": false, // カスタムグラデーションを無効化
"palette": [
{
"slug": "brand-primary",
"color": "#0056b3",
"name": "メインカラー"
},
{
"slug": "brand-secondary",
"color": "#f8f9fa",
"name": "背景用ライトグレー"
}
]
}
}
}

この設定を行うことで、エディター上の色選択が指定したパレットのみに制限されます。
ブランドカラーを守りつつ、クライアントが誤って奇抜な色を指定してしまう事故を未然に防ぐことができます。

■ 制限をかける理由と長期的な運用メリット

なぜここまで細かく制限をかけるのでしょうか。
それは、WordPressの方向性が「誰でも自由にデザインできる」へ向かっている一方で、企業サイトの運用では「デザインの統一性を保ちながら情報を発信する」ことが求められるからです。
自由と統制のバランスを取るのが、私たちWeb制作側の重要な役割になります。
正直に言うと、以前は制限を設けずに納品していた時期もありました。
しかし、数ヶ月後にサイトを確認すると、意図しないフォントサイズや色が多用され、ブランドイメージが損なわれているトラブルを経験しました。
それ以来、運用設計の一部としてエディターの最適化を必須工程に組み込んでいます。

■ ブロック制御の適用判断基準

すべての案件でガチガチに制限をかけるべきかというと、そうではありません。
クライアントの体制に合わせて柔軟に判断する必要があります。

将来性を考えると、WordPressのアップデートによって新しいブロックが追加されるたびに、それが意図せず表示されるリスクもあります。
そのため、`theme.json`による一元管理は、保守性の面でも非常に有効な選択肢となります。

迷ったときは、「誰が、どのような頻度で更新するのか」をクライアントと徹底的にすり合わせることから始めてみてください。
運用者のスキルに寄り添ったエディター画面を作ることで、納品後の満足度は大きく向上します。

Web制作や運用に関する仕組みづくりでお悩みの際は、お気軽にeBIZクリエイト株式会社までご相談ください。
地方密着型のデジタルパートナーとして、現場の課題に合わせた解決策をご提案いたします。

5. カスタムブロック開発の実例と保守性を高めるコードの書き方

Gutenberg（グーテンベルク）のブロックエディターを使ったWeb制作において、標準ブロックだけではクライアントの要望を満たせない場面によく直面します。以前の案件で、複雑なレイアウトの「スタッフ紹介」や特定の装飾が必要な「お客様の声」を実装する際、標準ブロックを組み合わせて対応しようとしたところ、運用時にレイアウト崩れが多発した経験がありました。その時の解決策として採用したのが、専用のカスタムブロックを開発することです。

この記事では、実際の案件で使えるカスタムブロック開発の実例と、長期的な運用を見据えた保守性の高いコードの書き方をシェアします。

この記事でわかること

カスタムブロック開発の基本的な流れと必要なファイル構成がわかります
実案件で使える「スタッフ紹介」ブロックの実装例がわかります
ブロックエディターのアップデートに強い、保守性を高めるコードの書き方の判断基準がわかります

カスタムブロック開発の基本構成（LAYER 1・2）

カスタムブロックを開発する際、主に以下のファイルが必要になります。現在は `@wordpress/create-block` パッケージを使用することで、雛形を簡単に構築できます。

`block.json`: ブロックのメタデータ（名前、カテゴリ、属性など）を定義するファイル
`index.js`: ブロックの登録処理を行うエントリーポイント
`edit.js`: エディター画面での表示と動作（Edit関数）を記述
`save.js`: フロントエンド（実際のWebサイト）に出力するHTML（Save関数）を記述
`style.scss`: フロントエンドとエディター共通のスタイル
`editor.scss`: エディター専用のスタイル

以下は、実務でよく作成する「スタッフ紹介」ブロックの `block.json` の例です。

// block.json
{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "ebiz/staff-profile",
"version": "1.0.0",
"title": "スタッフ紹介",
"category": "widgets",
"icon": "businessman",
"description": "写真、名前、役職、プロフィール文を表示するスタッフ紹介ブロックです。",
"attributes": {
"staffName": {
"type": "string",
"source": "html",
"selector": ".staff-name"
},
"staffRole": {
"type": "string",
"source": "html",
"selector": ".staff-role"
},
"staffImageId": {
"type": "number"
},
"staffImageUrl": {
"type": "string",
"source": "attribute",
"selector": ".staff-image img",
"attribute": "src"
},
"staffDescription": {
"type": "string",
"source": "html",
"selector": ".staff-description"
}
},
"supports": {
"html": false,
"align": ["wide", "full"]
},
"textdomain": "ebiz-blocks",
"editorScript": "file:./index.js",
"editorStyle": "file:./index.css",
"style": "file:./style-index.css"
}

Edit関数とSave関数の実装例

エディター側（`edit.js`）では、`RichText` や `MediaUpload` コンポーネントを使用して、クライアントが直感的に入力できるUIを提供します。

// edit.js
import { __ } from '@wordpress/i18n';
import { useBlockProps, RichText, MediaUpload, MediaUploadCheck } from '@wordpress/block-editor';
import { Button } from '@wordpress/components';

export default function Edit( { attributes, setAttributes } ) {
const { staffName, staffRole, staffImageUrl, staffImageId, staffDescription } = attributes;
const blockProps = useBlockProps();

return (
<div { ...blockProps }>
<div className="staff-image">
<MediaUploadCheck>
<MediaUpload
onSelect={ ( media ) => setAttributes( { staffImageUrl: media.url, staffImageId: media.id } ) }
allowedTypes={ [ 'image' ] }
value={ staffImageId }
render={ ( { open } ) => (
<Button onClick={ open } className={ staffImageId ? 'image-button' : 'button button-large' }>
{ ! staffImageId ? __( '画像をアップロード', 'ebiz-blocks' ) : <img src={ staffImageUrl } alt={ __( 'スタッフ画像', 'ebiz-blocks' ) } /> }
</Button>
) }
/>
</MediaUploadCheck>
</div>
<div className="staff-info">
<RichText
tagName="h3"
className="staff-name"
value={ staffName }
onChange={ ( content ) => setAttributes( { staffName: content } ) }
placeholder={ __( 'スタッフ名を入力', 'ebiz-blocks' ) }
/>
<RichText
tagName="p"
className="staff-role"
value={ staffRole }
onChange={ ( content ) => setAttributes( { staffRole: content } ) }
placeholder={ __( '役職を入力', 'ebiz-blocks' ) }
/>
<RichText
tagName="div"
className="staff-description"
value={ staffDescription }
onChange={ ( content ) => setAttributes( { staffDescription: content } ) }
placeholder={ __( 'プロフィール文を入力', 'ebiz-blocks' ) }
/>
</div>
</div>
);
}

フロント側（`save.js`）は、入力されたデータを基に出力するHTMLを定義します。

// save.js
import { useBlockProps, RichText } from '@wordpress/block-editor';

export default function save( { attributes } ) {
const { staffName, staffRole, staffImageUrl, staffDescription } = attributes;
const blockProps = useBlockProps.save();

return (
<div { ...blockProps }>
{ staffImageUrl && (
<div className="staff-image">
<img src={ staffImageUrl } alt={ staffName || 'スタッフ画像' } />
</div>
) }
<div className="staff-info">
<RichText.Content tagName="h3" className="staff-name" value={ staffName } />
<RichText.Content tagName="p" className="staff-role" value={ staffRole } />
<RichText.Content tagName="div" className="staff-description" value={ staffDescription } />
</div>
</div>
);
}

保守性を高めるコードの書き方（LAYER 3）

カスタムブロック開発において、最も気をつけなければならないのが「ブロックのリカバリーエラー（ブロックが壊れる現象）」です。これは、データベースに保存されたHTML（`save.js` の出力）と、現在ロードされている `save.js` の出力が一致しない場合に発生します。

これを防ぐためのポイントは以下の通りです。

1. `save.js` の変更を最小限にする:
一度公開したブロックの `save.js` の構造を安易に変更しないことが重要です。変更が必要な場合は、非推奨（Deprecated）の仕組みを利用して、過去のバージョンとの互換性を保つ必要があります。
2. `InnerBlocks` を活用する:
複雑な構造になる場合は、すべてを一つのブロック内で制御するのではなく、`InnerBlocks`（ブロック内に他のブロックを配置できる仕組み）を利用して、柔軟性を持たせる設計を検討します。
3. ダイナミックブロック（Dynamic Block）の採用:
フロントエンドの出力を `save.js` ではなく、PHP側（`render_callback`）で行うダイナミックブロックを採用すると、HTML構造の変更時にリカバリーエラーを気にする必要がなくなります。頻繁にデザイン変更が予想されるパーツには、ダイナミックブロックが向いています。

実案件での失敗談と判断基準

正直にお話しすると、以前はすべてJavaScriptベースの静的ブロックで開発していました。しかし、納品後に「ここに見出しを追加したい」「HTMLのタグを変えたい」という軽微な修正依頼が来た際、過去に作成した記事のブロックがすべてエラーになってしまうというトラブルを経験しました。

この経験から、現在は以下のような判断基準を設けています。

迷ったときは、「このブロックのHTML構造は、半年後も変更されないか？」と考えてみてください。少しでも不安がある場合は、PHP側で出力を制御できるダイナミックブロックで実装する方が、長期的な保守性（LAYER 4）が高くなります。

Web制作において、運用フェーズでの負担を減らす設計は非常に重要です。ブロックエディターのカスタマイズでお困りの際は、お気軽にeBIZクリエイトまでご相談ください。