# ブロックテーマを用いた開発で気をつけてること - リンク: https://torounit.com/blog/things-to-keep-in-mind-when-developing-with-block-themes/ - 公開日: 2026-09-30T12:39:02+09:00 - 作成者: Toro\_Unit > ブロックテーマだけど、トップレベルに、「コンテント幅を使用するインナーブロック」 > が有効なグループブロックが無いと、エディタで横幅おかしくなるので注意。 > — Toro_Unit / Hiroshi Urabe (@Toro_Unit) [August 18, 2026](https://x.com/Toro_Unit/status/2089696818632487104?ref_src=twsrc%5Etfw) こういう細かい話とかが意外と共有されて無さそうなので気をつけてることを思いつく限り つらつらと。 ## テンプレートのトップレベルには、グループブロックを配置しその中に要素を設置する。 Twitter でも書きましたが、トップレベルにはグループブロックが必要です。基本的には グループブロックがサイトの横幅を制御しています。CSS とかで横幅の制御を自前でやって も管理画面では崩れたり、幅広や全幅が正しく動作しなかったりします。 [Twenty Twenty-Five](https://github.com/WordPress/twentytwentyfive) だとこんな感じ です。main タグがそれに当たります。 ```wp-block-code
``` テンプレートや、テンプレートパーツの要素は基本的に「コンテント幅を使用するインナー ブロック」が有効になっている （`"layout":{"type":"constrained"}`が設定されている） グループブロックの子要素になるものと考えればよいと思います。 ## CSS の記述は極力避けて、ブロックの設定でスタイリングを行う。 エディター側でスタイルを変更する機能が結構沢山あるんですが、「エディタで変更した のにスタイルが当たらない」とかの問題を引き起こしがち。また、最近は少なくなった気 がしますが、WordPress のアップデートで CSS のセレクタの優先度やセレクタそのものが 変更されることもあったりするので、その際にアップデートを困難にする一つの要因になり ます。 それでも CSS を記述する場合も当然存在します。その際は「WordPress が提供してるスタイル を上書きして塗り替える」的なアプローチより、「WordPress に足りないスタイルをちょい 足しする」みたいなスタンスで付き合うのが良いのかなと。 また、html 要素に対して、`font-size: 62.25%` とかを設定するのも避けたいです。最近 だとエディタが iframe になったのでデメリットが減りましたが、管理画面でのルート要素 とフロントエンド側側でのルート要素に当たるスタイルが一致しないとかで不具合を引き 起こしたりします。 ## body_class, post_class や、親 class 等に依存しない。どこに置いても同じような見た目になるようにする。 ブロックエディタになって、コンテンツのレイアウト編集等も容易になりました。ブラウザ で複数のタブを開いてブロックをコピー & ペーストしたり、ブロックパターンを用いたり などで、一度作ったブロックの設定やその組み合わせを使い回したりも容易になりました。 その際に、同じブロックが「投稿」と「ページ」はもちろん、ヘッダー、やフッターでも 同じスタイルが適用されるのが良いです。自動的にいい感じにしてくれるってのは一見便利 そうですが、大抵運用時などに、「〇〇の時は~」等の条件等を理解する必要が出てきたり、 その条件なども忘れ去られがちです。開発時にはいちいち設定する必要がなくて便利なの かもしれませんが、エディタってある意味では「いちいち設定」をするための機能なので、 この辺は長期的に見てあんまり上手くいってるケース少ないなと思ってます。 [The Zen of Python](https://ja.wikipedia.org/wiki/Zen_of_Python) で語られる「暗黙 より明示のほうが良い ( Explicit is better than implicit. )」という考え方があります が、これはテーマ開発や CSS とかの開発でも広く適用出来る話なのかなと。 ## 妥協しても 最低 95% くらいは、エディタでの見た目と実際の表示を一致させる 「ブロックエディタで編集しやすくなった」といっても、小まめにプレビューを確認する のであれば意味無いですし、結局ただ設定項目がいっぱいある複雑なエディタ、みたいな ことになります。WYSIWYG は「**W**hat **Y**ou **S**ee **I**s **W**hat **Y**ou **G** et」のアクロニムで「見たままが得られる」ということです。Word とか PowerPoint とか Pages とか Keynote とかその辺も、WYSIWYG です。「結局保存してプレビューやら PDF にしてみないとわからないよね」となってしまうとそれらって使いものにならないですよね。 別に全部が WYSIWYG である必要は無いし、Markdown から生成したりするものもいっぱい あるご時世、中途半端な WYSIWYG って実装コストと実際に提供している価値のバランスが 見合ってないと感じます。WYSIWYG にちゃんとこだわるのが使いやすい WordPress サイト の価値に繋がるのかなと。 ## ナビゲーションブロックの使い所 「ナビゲーションブロックをどこで使うのか」は色々難しいところですが、今のところ、 ヘッダー等のグローバルナビゲーション等に使うだけで良いのかなと。ナビゲーションブロック 固有の機能を使わない箇所に使うのはちょっとオーバースペックかなと。 例えば、フッターなどにある、サイトのコンテンツへのリンク等が付くことはよくあります がこの辺は、単純にリストや段落ブロックで記述してリンクを設定し。テンプレートパーツ やパターンで管理するので十分かなと。 ブロックテーマの場合、「テーマ編集権限 = ナビゲーション編集権限」と考えて差し支え ないです。( [https://wordpress.org/documentation/article/roles-and-capabilities/#side-editor-capabilities ) ](https://wordpress.org/documentation/article/roles-and-capabilities/#side-editor-capabilities) なのでその前提のもと、フッターなどを編集してもらったりするのがわかりやすいのでは ないかなと。 またエクスポートなどで複数のナビゲーションが存在すると面倒だったりするので、「テーマ 側ではナビゲーションは基本的には１つだけ」と思って使うのが面倒が少ないと思います。 ## おわりに この辺のノウハウとかって調べづらいなぁと改めて感じた次第です。ちょくちょく棚卸し しないとなと思いました。 この辺を押さえるのは既存のブロックテーマを触ってるだけだとなかなか気付きづらい部分 が多いので、[Twenty Twenty-Five](https://github.com/wordpress/twentytwentyfive) や WordPress 7.2 でリリース予定の [Ipsum](https://github.com/WordPress/ipsum) なんか を眺めながら、自前でシンプルなテーマを作るのが一番勉強になるな改めてと感じました。 その際は公式の[Theme Test Data](https://github.com/WordPress/theme-test-data) を 使ってそれらがいい感じに動くようにするのが学習としてはよいかなと思います。[](https://github.com/wordpress/twentytwentyfive#twenty-twenty-five) このサイトのテーマ：[https://github.com/torounit/torounit-2026](https://github.com/torounit/torounit-2026)