第2回: CSSが効かない？ theme.jsonで支配する次世代のスタイル設計

「style.css に書いたはずのスタイルが、画面に反映されない」
「開発者ツールでは効いているのに、実際の表示では打ち消されている」

こんな経験に、心当たりはありませんか？

ただし最初に、はっきりさせておきます。

この記事は
「CSSが効かない時の対処テクニック」を解説する回ではありません。

この第2回の目的は、
CSSで解決しようとしてしまう「前提そのもの」を壊すことです。

WordPressは今、
「HTMLとCSSを組み立てるCMS」ではありません。
スタイルを生成・管理・上書きするCMSへ進化しています。

この前提を理解しない限り、
どれだけCSSを書いても、競合はなくなりません。

第1回で「原因をログで特定する視点」を身につけたあなたに、
次に必要なのは、
「どこで戦うべきか」を見誤らない設計視点です。

CSSだけで戦う時代は終わった

FSE（フルサイト編集）以降のWordPressでは、
style.css は数あるスタイル出力ルートのひとつにすぎません。

かつてのWordPressでは、

• style.css に書く
• セレクタを強くする
• 読み込み順で調整する

といった方法で、ほぼすべてのスタイル問題を解決できました。

しかし現在は、状況が根本から変わっています。

現在、スタイル（CSS）は次のような経路で生成されます。

これらが同時にCSSを生成する時代になっています。

※数字は「設計上の優先順位」を示す

この 1️⃣〜5️⃣ は、
CSSの読み込み順や強さを示しているわけではありません。

「どこでスタイルを決めるべきか」
という設計上の優先順位です。

• 上に行くほど 前提・土台
• 下に行くほど 例外・調整

という関係になります。

基本設計は theme.json、
全体調整は Global Styles、
CSSは どうしても必要な例外処理のみ。

なぜ「CSSが効かない」のか

現在のWordPressでは、

• theme.json からCSSが動的生成され
• ブロック設定はクラスやインラインCSSとして出力されます。

そのため、

「セレクタを強くする」
「!important を付ける」

といった旧来の方法は、
構造的に通用しなくなっています。

この章で伝えたいことは一つだけです。

CSSが弱くなったのではありません。

戦う場所が変わったのです。

次の章では、
theme.json を軸にした
負けないスタイル設計 を解説します。

theme.json vs カスタマイザー vs style.css の「詳細度戦争」最終ルール

かつてのWordPress開発は単純でした。

「style.css に強いセレクタを書いた方が勝つ」

しかし今は違います。

CSSの勝敗を分けるのは、
セレクタの強さではなく、出力経路と出力順です。

特に theme.json や Global Styles は、
最終的に style タグとして head 内に出力されることがあります。

つまり、あなたの style.css より
後から、同等以上の条件でCSSが出てくるケースが普通に起こります。

この構造を理解しない限り、
「CSSが効かない」という現象は、永遠に続きます。

 ⚠️なぜあなたのCSSは負けるのか（よくある誤解）

例えば、クライアントが管理画面で「ボタンの色」を赤に設定したとします。するとWordPressは以下のようなHTMLを出力します。

<button class="wp-block-button__link has-red-background-color has-background">
  ボタン
</button>

<button class="wp-block-button__link has-red-background-color has-background">
  ボタン
</button>

これに対して、style.cssに 

.wp-block-button__link {
  background: blue;
}

.wp-block-button__link {
  background: blue;
}

と書いても効かない場合があります。

よくある説明は
「has-red-background-color の方が強いから」というものですが、これは正確ではありません。

クラスセレクタ同士の詳細度は基本的に同等です。

負ける本当の理由は、

• Global Styles 由来のCSSが後から出ている
• インラインstyle相当の指定が生成されている
• より具体的なセレクタが自動生成されている

つまり、
問題は「強さ」ではなく「場所」と「条件」です。

✅プロの解決策：戦う場所を変える

ここからが、この回の結論です。

FSE時代のスタイル設計は、
次の2つに切り分ける必要があります。

1️⃣ 基本ルールは theme.json に集約する

• フォントサイズ
• カラーパレット
• 余白
• レイアウト幅

これらを CSS ではなく theme.json で定義します。

そうすることで、
WordPressが生成するスタイルと同じ土俵で設計できます。

2️⃣ CSSは「例外」専用にする

• 擬似要素
• アニメーション
• JSONで表現できない装飾

CSSは「最終調整レイヤー」として使います。

この切り分けができると、CSS競合は一気に減ります。

FSE移行で増える div ネストに振り回されない

ブロックエディタは、
レイアウト制御のために div を自動挿入します。

その結果、次のようなCSSは簡単に壊れます。

.container > .item {
  margin-top: 20px;
}

.container > .item {
  margin-top: 20px;
}

対策は、div を消すことではありません。

余白管理をWordPressに委譲することです。

{
  "settings": {
    "layout": {
      "contentSize": "840px",
      "wideSize": "1100px"
    },
    "spacing": {
      "blockGap": "1.5rem"
    }
  }
}

{
  "settings": {
    "layout": {
      "contentSize": "840px",
      "wideSize": "1100px"
    },
    "spacing": {
      "blockGap": "1.5rem"
    }
  }
}

blockGap を定義するだけで、
ブロック間余白はWordPressが自動管理します。

🚥「!important」禁止令：@layer でCSSに秩序を作る

!important は即効性があります。
同時に、確実に技術的負債になります。

そこで使うのが CSS Cascade Layers（@layer） です。

@layer reset, base, theme, custom;

@layer custom {
  .wp-block-button__link {
    border-radius: 0;
  }
}

@layer reset, base, theme, custom;

@layer custom {
  .wp-block-button__link {
    border-radius: 0;
  }
}

@layer は万能ではありませんが、
CSS設計を破綻させないための強力な整理手段になります。

Global Styles の暴走を防ぐ（クライアントワーク必須）

納品後に
「なんとなく触ったらデザインが崩れた」

これはブロックテーマ時代の典型的な事故です。

theme.json で、
触らせる範囲を先に決めておく必要があります。

{
  "settings": {
    "appearanceTools": false,
    "color": {
      "custom": false
    },
    "typography": {
      "customFontSize": false
    }
  }
}

{
  "settings": {
    "appearanceTools": false,
    "color": {
      "custom": false
    },
    "typography": {
      "customFontSize": false
    }
  }
}

基本は
全部閉じて、必要な所だけ開ける。

これが、壊れない運用の鉄則です。

クラシック記事とブロック記事が混在する場合の注意点

FSEへ移行したサイトでは、
これまでのクラシックエディタで書かれた記事と、
新しく作成されたブロックエディタの記事が、しばらくの間は共存することになります。

この状態で注意したいのが、wpautop（自動整形）への対応です。

レイアウトを整えたい一心で、
wpautop を無条件に無効化してしまうと、
過去記事の表示が崩れたり、思わぬ箇所に影響が及ぶことがあります。

そのため、対応する際は、

• 対象をブロックエディタの記事のみに限定する
• 投稿タイプや条件を明確に切り分ける
• 影響範囲を事前に把握したうえで調整する

といったように、段階的かつ限定的な設計を心がけることが大切です。

「一括で切る」のではなく、
既存資産を尊重しながら移行する。
それが、長期運用に耐えるFSE移行のポイントです。

FSE移行では、
クラシック記事とブロック記事が混在します。

wpautop を無条件で切ると、
必ず副作用が出ます。

やるなら、
影響範囲を限定した設計が必要です。

上級者Q&A: FSE時代のCSS設計

Q1. FSE環境で style.css に書いたCSSが反映されないのは不具合ですか？

不具合ではありません。
FSE（フルサイト編集）では、ブロック設定やGlobal Stylesが高い優先度でCSSとして出力されるため、外部CSSよりも優先されるケースがあります。これはWordPressの設計仕様に基づく挙動です。

Q2. theme.json は CSS を書かなくてよくする仕組みですか？

そうではありません。
theme.json は色・フォント・余白・レイアウトなどの「基本設計」を定義するための仕組みであり、CSSを完全に置き換えるものではありません。
CSSは、theme.jsonで表現できない装飾や挙動を補完する役割として使います。

Q3. theme.json と Global Styles の優先順位はどうなっていますか？

一般的には、ユーザーがサイトエディタで設定した Global Styles の方が優先されます。
theme.json はテーマ側の初期設計、Global Styles は運用時の上書きという位置づけです。

Q4. ブロックごとのスタイル設定が特に強いのはなぜですか？

ブロック単位の設定は、クラスの追加やインラインスタイルとしてHTMLに直接出力されるため、CSSのカスケード上、非常に高い優先度を持ちます。
これはスタイルエンジンの仕様によるものです。

Q5. FSEで自動生成される div が増えることは問題になりませんか？

問題ではありません。
FSEではレイアウト制御を担うラッパー要素が自動生成される設計になっています。
これを前提として、margin指定ではなく layout や spacing 設定を用いることが推奨されます。

Q6. CSSの @layer 機能は WordPress 環境でも安全に使えますか？

はい。
@layer はCSSの公式仕様であり、WordPress固有の機能ではありません。
対応ブラウザ環境であれば、詳細度に依存しないスタイル設計が可能になります。

Q7. 「CSSで戦わない設計」とは、CSSを使わないという意味ですか？

いいえ。
CSSを主役にせず、設計の基盤を theme.json に置くという考え方です。
CSSは例外処理や装飾に限定することで、競合や保守コストを抑えることができます。

まとめ

「CSSが効かない」という現象は、
不具合でも、スキル不足でもありません。

それは、WordPressが
「スタイルを設計・管理するCMS」へと進化した結果として
自然に起きているものです。

この前提を理解できると、
CSSは何かと競い合う存在ではなく、
設計を丁寧に仕上げるための補助的な道具として扱えるようになります。

スタイル設計の整理ができた今だからこそ、次はサイト全体のパフォーマンスを、より冷静に、より科学的に見ていきましょう。

WEBさん

WordPressの不具合をなおす人

XInstagramYouTubeContact

あなたのお仕事をする時間を使ってITに関することを調べたり、トライしてみたりして、それでもうまくいかない。そんなことはありませんか？ WEB先案内をご利用いただくと、困ったときにITの顧問としてあなたのITに関するお悩みにお答えし、サポートを行うことができます。