トップページの見出しを1行だけ変えたい。管理画面から直せると思って開いたら、その部分は編集できないブロックになっている。制作会社に依頼すると、見積が出るまでに1週間、作業にもう1週間かかると言われる。
文言1行の話なのに、なぜそうなるのか。 実際に理由を聞くと、デザインの問題でも工数の問題でもないことがあります。「当時のビルド環境が今の環境で動かないので、まず動くようにするところから」という回答が返ってきます。
カスタムブロックが、なぜ保守を重くしたのか
WordPress のブロックエディタ（Gutenberg）が入って7年以上経ちます。この間、サイト独自のパーツ——料金表、実績カード、お知らせ一覧のような部品——は「カスタムブロック」として作るのが標準的なやり方でした。
このカスタムブロックの作り方に、保守を重くする性質がありました。エディタ側の表示を JavaScript（React）で書き、それをビルドして配置する必要があったためです。結果として、サイトの中身とは別に次のものが増えます。
package.jsonと大量の依存パッケージ- ビルドを動かすための Node.js（当時のバージョン）
- ビルド後の生成物と、生成前のソース一式
サイトを公開して2年経ったあと、この一式が問題になります。当時のパッケージが今のNode.jsで動かない。 制作担当者が退職していれば、手順を知る人もいません。文言1行の修正に見積2週間という数字は、この復旧作業の見積です。
保守されなくなった依存関係が具体的にどう牙をむくかは、更新が止まったサイトの脆弱性と保守契約でも扱いました。
WordPress 7.0 の PHP のみでのブロック登録
2026年3月に WordPress Core の開発者向け告知として公開され、WordPress 7.0 に入ったのが「PHP-only block registration」です。block.json も JavaScript のビルドも無しに、PHP だけでブロックを登録できます。
書き方としては、register_block_type() を呼ぶときに supports の中で autoRegister を有効にすると、WordPress がそのブロックをエディタ側にも自動的に出します。
register_block_type( 'gleamhub/price-table', array(
'supports' => array(
'autoRegister' => true,
),
'attributes' => array(
'plan' => array( 'type' => 'string', 'default' => 'standard' ),
),
'render_callback' => 'gleamhub_render_price_table',
) );npm install も、ビルドの実行も、生成物の配置も要りません。PHP ファイルが1つあれば、そのブロックはエディタに現れます。
対象は、サーバー側で描画するだけの、エディタ上で高度な操作を必要としないブロックです。どうしても JavaScript が必要な場合は、登録は init で行い、スクリプトの読み込みは描画時のコールバックから行う形が案内されています。この場合、同じブロックがページ内に複数あってもスクリプトは重複せず、ページ末尾でまとめて読み込まれます。
「全部これにすればいい」ではない
新しい選択肢が出たときに起きがちなのが、既存のブロックを全部書き換えようとすることです。それは動いているものを壊す作業なので、勧めません。
判断は、そのブロックがエディタ上で何をしているかで分かれます。
| ブロックの性質 | 向く作り方 |
|---|---|
| 表示するだけ（料金表、実績カード、バナー） | PHP のみで十分 |
| 編集画面で見た目のプレビューが要る | 従来どおり JavaScript を含む形 |
| 編集画面で複雑な操作をする（並べ替え、動的な入力補助） | 従来どおり |
多くの企業サイトでは、カスタムブロックの大半が1行目に該当します。 料金表も実績カードもお知らせ一覧も、編集画面でやることは「文字を入れる」「画像を選ぶ」だけです。ここに React とビルド環境を持ち込んでいたのが、これまでの標準でした。
新しく作る部分から適用していけば、サイト全体としてビルド環境への依存が少しずつ減ります。 WordPress 7.0 系で入った他の変更点はWordPress 7 の AI コネクタと Abilitiesでも触れています。
発注と検収で確認する3点
制作を依頼する側が、専門知識なしで確認できることがあります。
- 「このブロックは、ビルドが必要ですか」と聞く。 必要だと答えられた場合、なぜ必要なのかを一緒に聞いてください。編集画面でのプレビューのためなら妥当です。「そういう作り方だから」という答えなら、見直す余地があります
- 納品物にビルド前のソースが含まれているか確認する。 生成物だけを渡されると、次に直すとき最初から作り直しになります。契約書の納品物の項目に、ソース一式を明記してください
- 開発環境の再現手順が文書で残っているか確認する。 Node.js のバージョンまで書かれていない手順書は、2年後には使えません
3点目は、そもそもビルドが不要なら発生しない確認です。依存を減らすことが、最も確実な引き継ぎ対策になります。CMS の選定段階から考える場合は更新できるサイトにするためのCMS選びも合わせて読んでください。
次にやること
まず、自社サイトの管理画面を開いて、直せない箇所がどれくらいあるか数えてください。 「ここは触れません」と言われている部分が5箇所以上あるなら、更新のたびに外注費が発生する構造になっています。
そのうえで、次の改修を依頼するときに 「この部分はビルド不要な作り方にできますか」と1つ質問してみてください。 答えられる相手かどうかで、保守の見通しがかなり分かります。WordPress 本体の更新を止めないことは前提として、コアの脆弱性と更新運用も併せて確認しておくと安全です。
WordPress サイトの保守設計、更新できる状態への作り替え、リニューアル時の納品物の決め方については、グリームハブの HP 制作・リニューアル相談で承っています。現在の構成によって取れる手が変わるため、お問い合わせから現状をお知らせください。
