CSSが反映されない9つの原因と直し方｜変わらない時の確認チェックリスト

生徒

先生、大変です…！CSSを書いて保存したのに、ブラウザで見ても色もサイズも全然変わらないんです。コードは合ってるはずなのに…どうして反映されないんでしょうか？

ペン博士

落ち着いて大丈夫だよ！「CSSが反映されない」って、初心者がほぼ全員ぶつかる壁なんだ。でも原因は9パターンくらいに決まっていて、上から順に確認すればほぼ必ず特定できる。今日はその見つけ方と直し方を、いっしょに丁寧に見ていこうね！

HTMLとCSSを書いてスタイルを整えようとしたとき、保存したのにブラウザの見た目がまったく変わらないという現象は、Web制作の学習中や実務でとても頻繁に起こります。書いたコード自体は正しく見えるのに反映されない。この「変わらない」という状態は、原因が目に見えないぶん、初心者にとって非常にやっかいです。

しかし安心してください。CSSが反映されない原因は、無限にあるわけではありません。実務でも学習でも、原因はだいたい9つのパターンのどれかに収まります。しかもそのほとんどは、開発者ツール（DevTools）を使えば数十秒で特定できます。この記事では、CSSが反映されない9つの原因を1つずつ「症状→原因→確認方法→直し方」の順で解説し、さらに詳細度（Specificity）の数え方、開発者ツールでの特定手順、スーパーリロードのやり方、WordPress特有の注意点まで、未経験の方でも自力で解決できるように徹底的にまとめました。最後には「反映されないときの確認チェックリスト」も用意しています。

大切なのは、原因を「暗記する」ことではなく、目の前のトラブルがどの原因に当てはまるかを切り分ける手順を身につけることです。CSSが効かない場面は人によって千差万別ですが、切り分けの手順そのものはいつも同じだからです。この記事を読み終えるころには、初めて出会うトラブルでも「まずこれを確認して、次にここを見る」と、落ち着いて手を動かせるようになっているはずです。逆に、この手順を持たないまま思いつきでコードを書き換えると、原因が別の場所に移動したように見えたり、CSSがどんどん複雑になったりして、かえって解決から遠のいてしまいます。

この記事の結論｜CSSが反映されないときの考え方

先に結論からお伝えします。CSSが反映されないとき、闇雲にコードを書き換えるのは逆効果です。まずは「そもそもCSSが読み込まれているか」と「読み込まれた上で上書きされていないか」の2段階で切り分けるのが最短ルートです。次のポイントを上から順に確認してください。

• キャッシュを疑う。ブラウザやサーバーが古いCSSを覚えていて、新しい記述が届いていないケースが最も多いです。まずスーパーリロードを試します。
• 開発者ツールで対象要素を検証する。F12で要素を選び、狙ったCSSが「打ち消し線」で消されていないか、そもそも表示されているかを見ます。
• 詳細度（Specificity）で負けていないかを確認する。より強いセレクタや!importantに上書きされていないかを見ます。
• セレクタが本当にその要素を指しているかを確認する。クラス名の綴りミスや、対象違いは非常によくある原因です。
• CSSファイルが正しく読み込まれているかを確認する。link先のパス誤りや、途中の構文エラーで以降が無効になっていないかを見ます。

この5つの視点を持つだけで、次に何をすべきかが見えてきます。逆に、この切り分けを飛ばして「とりあえず!importantを付ける」「よく分からないまま数値を変える」といった対処を重ねると、CSSがどんどん複雑になり、本当の原因が埋もれてしまいます。

この記事で扱う9つの原因を、先に一覧にしておきます。どれも「症状→原因→確認方法→直し方」の順で解説するので、自分のトラブルに近いものから読んでも構いません。

それでは、CSSが反映されない9つの原因を、1つずつ具体的に見ていきましょう。

前提知識｜そもそもCSSはどうやって適用されているのか

9つの原因を理解する土台として、まずCSSがどういう仕組みで最終的な見た目を決めているかを押さえておきましょう。ここが分かっていると、「なぜ効かないのか」を自分の頭で説明できるようになり、開発者ツールの表示も一気に読みやすくなります。少し遠回りに感じても、この章はすべての原因の共通言語になるので、飛ばさずに読んでください。

カスケード（Cascade）とは

CSSはCascading Style Sheets（段階的に適用されるスタイルシート）の略です。この「カスケード（滝のように上から下へ流れる）」という名前どおり、CSSは複数のルールを一定の順番で重ね合わせ、最終的にどのスタイルを採用するかを決めています。1つの要素に対して、あなたが書いたCSS・ブラウザの初期スタイル・テーマやライブラリのCSSなど、複数のルールが同時に候補になります。

そのとき「どれを採用するか」を決める基準が、大きく分けて3つあります。この3つの優先順位こそが、CSSが反映されない問題のほぼすべての正体です。

つまりブラウザは、同じ要素の同じプロパティに複数の指定があると、①!importantの有無 → ②詳細度 → ③順番の順でふるいにかけて勝者を1つ決めます。「自分のCSSが効かない」とは、この勝ち抜き戦であなたのルールが負けているか、そもそも参加できていない（マッチしていない・読み込まれていない）かのどちらかなのです。

「効かない」は2種類に分けられる

この仕組みを踏まえると、CSSが反映されない状態は大きく2つのタイプに分類できます。この分類ができるだけで、9つの原因のどのグループを疑うべきかが決まります。

• タイプA：CSSは要素に届いているが、上書きされて負けている。開発者ツールで自分のCSSが「打ち消し線つき」で表示されます。→ 原因②③⑤（詳細度・!important・後勝ち）や⑨（インラインstyle）が該当。
• タイプB：CSSがそもそも要素に届いていない。開発者ツールに自分のCSSが表示すらされません。→ 原因④（マッチミス）・⑥（パス誤り）・⑦（構文エラー）・⑧（メディアクエリ範囲外）が該当。

そして、この2タイプのどちらでもなく「そもそも新しいCSSが届いていない（＝古いCSSが表示されている）」という第3の状態が、最頻出の原因①キャッシュです。だからこそ、まずスーパーリロードでキャッシュを排除し、次に開発者ツールでタイプAかタイプBかを見分ける、という順番が最短になります。

この「キャッシュ → タイプA／タイプB」という地図さえ頭にあれば、9つの原因はバラバラの知識ではなく、1本の判断の流れとしてつながって見えてきます。効かないと感じたら、まず「新しいCSSは届いているか？」、次に「届いた上で負けているのか、そもそもマッチしていないのか？」。この2つの問いに答えるだけで、あなたはもう原因の8割にたどり着いています。それでは、この地図を手に、9つの原因を1つずつ見ていきましょう。

原因①：ブラウザ・サーバーのキャッシュが古い

最も頻度が高い原因がキャッシュです。ブラウザやサーバーが「前に読み込んだCSS」を記憶していて、あなたが更新した新しいCSSではなく古いCSSを表示し続けている状態です。コードは正しいのに変わらない、というときはまずこれを疑います。

症状

CSSを書いて保存したのに見た目が変わらない。とくに普通のリロード（F5）では変わらないが、シークレットウィンドウで開くと反映されている場合は、キャッシュがほぼ確定です。別のブラウザや別の端末では正しく見える、というのも典型的なサインです。

原因

ブラウザは表示を高速化するため、一度読み込んだCSSファイルを一定時間ローカルに保存（キャッシュ）します。ファイル名やパスが同じだと「もう持っているから読み込み直さなくていい」と判断し、古い内容を使い続けます。レンタルサーバーやCDN、WordPressのキャッシュ系プラグインが同じことをしている場合もあります。

確認方法

シークレット（プライベート）ウィンドウでページを開いてみてください。シークレットウィンドウはキャッシュを持たないため、ここで反映されていれば原因はキャッシュで確定です。あわせて、開発者ツールの「Network」タブでCSSファイルを選び、ステータスが200（読み込み直した）か304／(from disk cache)（キャッシュ利用）かも確認できます。

直し方（スーパーリロード）

キャッシュを無視してファイルを取り直すのがスーパーリロード（ハードリロード）です。OSとブラウザによってショートカットが違うので、下の表を参考にしてください。

スーパーリロードでも変わらないほど強くキャッシュされている場合は、開発者ツールの「Network」タブで「Disable cache（キャッシュを無効化）」にチェックを入れておくと、開発中はキャッシュに悩まされにくくなります。ただしこれは開発者ツールを開いている間だけ有効な設定です。

サーバー側やCDN、WordPressのキャッシュ系プラグインが原因の場合は、それぞれの管理画面から「キャッシュの削除（クリア）」を実行します。WordPress特有の注意点はこの後の章で詳しく解説します。それでもキャッシュを消して変わらないなら、次の原因に進みましょう。

キャッシュに悩まされないための予防策

そもそもキャッシュ問題を起こしにくくする工夫もあります。実務で本番のCSSを更新するときは、ファイル名やURLの末尾にバージョン番号を付けて、更新のたびに変えるのが定番です。ブラウザはURLが変わると「別のファイル」とみなして読み込み直すため、古いキャッシュが残っていても新しいCSSが確実に届きます。

<!-- ?ver= の値を更新するたびに変えると、キャッシュを確実に切り替えられる -->
<link rel="stylesheet" href="style.css?ver=20260709">
<!-- 次の更新時 -->
<link rel="stylesheet" href="style.css?ver=20260710">

この手法はキャッシュバスティング（cache busting）と呼ばれ、WordPressでも wp_enqueue_style のバージョン引数で同じことができます。開発中は開発者ツールの「Disable cache」で運用し、本番はバージョン番号で管理する、と使い分けると快適です。

よくある勘違い

「保存したのだから最新のはず」という思い込みが、キャッシュ問題を見抜けなくする最大の原因です。あなたのエディタでは確かに最新でも、ブラウザに届いているのが最新とは限りません。エディタの保存・サーバーへのアップロード・ブラウザの読み込み、この3か所のどこかで「古いまま」が起きていないかを、常に切り分けて考える習慣をつけましょう。

原因②：詳細度（Specificity）で負けている

キャッシュを消してもCSSが反映されないなら、次に疑うのは詳細度（Specificity）の負けです。詳細度とは、複数のCSSが同じ要素・同じプロパティを指定したとき「どちらを優先するか」を決める強さのことです。あなたが書いたCSSより強いルールが別にあると、そちらが勝ってしまい反映されません。

症状

開発者ツールで対象要素を見ると、自分が書いたCSSが打ち消し線で消されている。別のセレクタ（IDや、より深い階層指定）が同じプロパティを上書きしている、という状態です。

原因

CSSは「後に書いたほうが勝つ」だけでなく、セレクタの強さ（詳細度）が高いほうが勝つというルールがあります。詳細度が高いルールは、たとえ先に書かれていても後のルールに勝ちます。そのため、あなたが書いたクラス指定が、既存のID指定や複雑なセレクタに負けているケースが起こります。

詳細度の数え方

詳細度は、セレクタの構成要素を種類ごとに数えて比較します。おおまかに「ID＞クラス・属性・擬似クラス＞要素・擬似要素」の順で強いと覚えてください。より正確には、次の4つの枠（a,b,c,d）で点数を数えます。

この (a, b, c, d) を左から順に比べて、大きいほうが勝ちます。たとえば #nav .item は「ID1個・クラス1個」で (0,1,1,0)、.menu .list .item a は「クラス3個・要素1個」で (0,0,3,1) です。左から比べると b が 1 > 0 なので、前者（IDを含むほう）が勝ちます。クラスをいくつ重ねてもID1個には勝てない、というのが重要なポイントです。

計算の具体例

次のセレクタの詳細度を数えてみましょう。

この表で #main と .box .text を比べると、クラスを2つ使った .box .text より、ID1つだけの #main のほうが強くなります。「クラスをたくさん並べたのに効かない」ときは、たいてい相手にIDが含まれています。

直し方（悪い例と良い例）

詳細度で負けているときの直し方は2つあります。1つは負けている側のセレクタを、相手と同等以上の詳細度に引き上げること。もう1つは、相手のセレクタを弱くしてCSS全体をフラットに保つことです。まずは悪い例を見てみましょう。

/* HTML: <div id="card"><p class="title">見出し</p></div> */

/* 既存のCSS（先に読み込まれている） */
#card .title {
  color: red;   /* 詳細度 (0,1,1,0) */
}

/* 後から書いた自分のCSS → 反映されない！ */
.title {
  color: blue;  /* 詳細度 (0,0,1,0) で負ける */
}

この場合、後に書いた .title は詳細度で負けているため、文字は赤のままです。次のように直します。

/* 良い例：相手と同じ土俵（詳細度）に合わせる */
#card .title {
  color: blue;  /* 詳細度 (0,1,1,0) で同点 → 後勝ちで青になる */
}

/* もしくは、そもそも既存側をIDに依存させない設計にしておく */
.card .title {
  color: blue;
}

実務では、最初からIDセレクタでスタイルを当てないことが詳細度トラブルの一番の予防策です。IDはJavaScriptの目印やページ内リンク用にとどめ、スタイルはクラスで当てる。この習慣だけで、詳細度の泥沼にはまることが激減します。

よく詰まる詳細度パターン早見表

初心者がとくに引っかかりやすい詳細度の負けパターンを、早見表にまとめました。「効かない」と感じたら、まずこの表の状況に当てはまっていないかを疑ってください。

この表から分かるとおり、詳細度負けは「相手のほうにIDや余分なクラスが混じっている」ことがほとんどです。開発者ツールで勝っているルールのセレクタを見て、自分のものより要素が多くないかを比べるだけで、原因の見当がつきます。

継承（inherit）と詳細度は別物

補足として、継承（親要素から受け継ぐ性質）と、詳細度による上書きは別の話です。color や font-size のように親から子へ受け継がれるプロパティは、子要素に直接指定がなければ親の値が使われます。これは「上書き合戦」ではなく「そもそも指定がないから親を見ている」状態です。効かないと感じたとき、それが上書きされているのか、単に指定していない継承値なのかを区別できると、開発者ツールの読み取りがぐっと正確になります。

原因③：!important に上書きされている

詳細度をそろえても反映されないときは、どこかで !important が使われている可能性があります。!important は詳細度のルールをすべて無視して最優先で適用される、いわば「切り札」です。あなたのCSSがこれに負けている状態です。

症状

開発者ツールで見ると、自分のCSSはもちろん、他の強そうなCSSまで打ち消し線で消えていて、!important が付いたルールだけが生き残っている。値を変えても、詳細度を上げても、まったく効かない、というのが特徴です。

原因

!important は詳細度の計算より上のレイヤーで効くため、通常のセレクタでは絶対に勝てません。プラグインやテーマ、フレームワーク（Bootstrapなど）が、上書きされにくくするために !important を多用していることがあり、これがユーザーの記述を打ち消しています。とくに配布テーマやUIライブラリは、どんな環境でも見た目が崩れないようにと !important を保険的に付けていることが多く、それを知らずに上書きしようとすると「何をやっても効かない」と感じてしまうのです。

確認方法

開発者ツールの「Styles」パネルで、効いているルールに !important の表記があるかを探します。どのファイルの何行目で指定されているかも表示されるので、出どころを特定できます。

直し方

!important に勝つには、原則こちらも同じプロパティに !important を付けるしかありません。ただし乱用すると「!important 合戦」になり収拾がつかなくなるため、次の順で検討します。

1. まず、なぜ相手が !important を使っているのか（テーマ・プラグイン由来か）を確認する。
2. 可能なら、相手の !important を外す・設定で無効化する方向を優先する（自作CSSなら削除）。
3. 外せない場合のみ、こちらも同じプロパティに !important を付け、かつ詳細度も相手以上にする。

/* 相手（テーマ由来など、変更しにくい） */
.btn { color: gray !important; }

/* 自分：!important 同士なら、詳細度が高いほうが勝つ */
.page .btn { color: #ffbf00 !important; }

大切なのは、!important は最後の手段だという意識です。自分のプロジェクトのCSSで多用していると、後から自分自身が上書きに苦しむことになります。基本は詳細度で解決し、どうしても外せない外部CSSに勝つときだけ使いましょう。

!important同士がぶつかったとき

では、双方に !important が付いていたらどうなるのでしょうか。答えは!important同士なら、通常どおり詳細度の高いほうが勝つです。さらにそれも同点なら、後に書かれたほうが勝ちます。つまり !important は「詳細度・順番より上の判定を一段追加する」だけで、その中では通常のルールがそのまま生きています。相手の !important に勝てないときは、こちらも !important を付けたうえで、セレクタの詳細度を相手以上に引き上げれば確実に勝てる、というわけです。

原因④：セレクタの綴りミス・対象違い

そもそもセレクタが対象の要素を指していないため、CSSが1文字も適用されていない、というケースです。地味ですが非常に多い原因です。

症状

開発者ツールで対象要素を見ても、自分の書いたCSSがStylesパネルに一切表示されない。打ち消し線ですらなく、そもそも候補に出てこない、という状態です。これは「上書きされた」のではなく「マッチしていない」サインです。

原因

よくあるパターンを挙げます。CSSは大文字・小文字や記号に厳格なので、些細な違いでマッチしなくなります。

• クラス名の綴りが違う：HTMLは class="button"、CSSは .buttun のようなタイプミス。
• ドット（.）やシャープ（#）の付け忘れ：クラスなのに button {} と書いている（＝要素セレクタ扱い）。
• 大文字・小文字の不一致：.mainBox と .mainbox は別物として扱われます。
• 複数クラスの区切り違い：.a.b（両方持つ要素）と .a .b（子孫）はまったく意味が違います。

確認方法

開発者ツールで要素の class 属性を実際に確認し、CSSのセレクタと1文字ずつ照らし合わせます。もう1つ確実な方法は、そのセレクタに一時的に派手なスタイルを当てて反応を見ることです。

/* テスト用：このセレクタがマッチするか確認する */
.target {
  outline: 3px solid magenta !important;
  background: yellow !important;
}

これで枠や背景が変われば、少なくともセレクタは正しくマッチしています。何も変わらなければ、セレクタが対象を指せていないので綴り・記号・階層を見直します。

直し方

HTML側のクラス名とCSS側のセレクタを完全に一致させます。.a .b（半角スペース＝子孫）と .a.b（スペースなし＝同一要素に両方）を混同していないかも要チェックです。マッチ確認用の派手なスタイルは、確認が済んだら必ず消しておきましょう。

見落としがちなマッチミスのパターン

綴りミス以外にも、マッチしなくなる落とし穴がいくつかあります。次のパターンは、コードをいくら見直しても気づきにくいので、頭の片隅に入れておいてください。

• 全角スペース・全角文字の混入：クラス名やセレクタに、見た目では分からない全角スペースが紛れていると別物になります。
• 擬似クラスの状態違い：:hover や :focus は、その状態のときしか効きません。マウスを乗せないと見えない指定を「効かない」と誤解しがちです。
• 子孫（半角スペース）と直下（>）の違い：.list li（すべての子孫）と .list > li（直下のみ）は対象範囲が違います。
• HTMLが動的に生成されている：JavaScriptで後から追加された要素は、想定と違うクラスが付いていることがあります。開発者ツールで実際のDOMを見て確認します。

こうしたケースでも、確認方法は同じです。開発者ツールで実際のDOMのクラス属性を確認し、セレクタと突き合わせる。頭の中のHTMLではなく、ブラウザが実際に持っているHTML（DOM）を見ることが、マッチミスを見抜く鉄則です。

原因⑤：読み込み順・後勝ちのルール

詳細度が同じ場合、後から読み込まれたCSSが勝つ（後勝ち・カスケード）というルールがあります。この順番を意識していないと、自分のCSSが先に読み込まれてしまい、後の別ファイルに上書きされることがあります。

症状

自分のCSSと相手のCSSの詳細度は同じなのに、なぜか相手が勝っている。開発者ツールで見ると、下（後）に書かれた／後で読み込まれたルールが優先されている、という状態です。

原因

CSSは同じ詳細度なら「あとに現れたほうを採用」します。この「あと」は、同じファイル内なら下の行、複数ファイルなら後に <link> されたファイルを指します。よくあるのは、共通スタイルより先に自分のカスタムCSSを読み込んでしまい、後から来る共通スタイルに負けるパターンです。

確認方法

HTMLの <head> 内で、CSSファイルがどの順で <link> されているかを確認します。開発者ツールのStylesパネルでも、勝っているルールがどのファイル由来かが分かるので、読み込み順との関係を照合できます。

直し方

原則は「上書きしたい自分のCSSを、いちばん後に読み込む」ことです。次のように、ライブラリや共通CSSより後に自作CSSを置きます。

<!-- 悪い例：自作CSSが先。後のライブラリに上書きされる -->
<link rel="stylesheet" href="my-style.css">
<link rel="stylesheet" href="library.css">

<!-- 良い例：自作CSSを最後に読み込む -->
<link rel="stylesheet" href="library.css">
<link rel="stylesheet" href="my-style.css">

なお、@import を使ってCSS内から別CSSを読み込むと、読み込みが直列になり表示が遅くなるうえ、順序も直感に反しやすくなります。実務では @import より <link> で並べるほうが読み込み順を管理しやすく、パフォーマンス面でも有利です。

同じファイルの中でも「後勝ち」は起きます。うっかり同じセレクタを2回書いていて、下の記述が上を打ち消しているケースは意外と多いです。開発者ツールで、同じセレクタが2か所に出ていないか、下のほうが勝っていないかを確認しましょう。「さっき書いた指定が効かない」ときは、その下に古い同じ指定が残っていないかを疑うのが近道です。

原因⑥：CSSファイルのパス・link記述の誤り

CSSファイルそのものが読み込まれていないため、書いた内容が一切効かないケースです。原因④が「読み込まれているが対象違い」だとすれば、こちらは「ファイルすら届いていない」状態です。

症状

そのCSSに書いたスタイルが1つも効いていない（全滅）。特定のプロパティだけでなく、そのファイルの記述すべてが無効なのが特徴です。

原因

<link> の href に指定したパスが間違っていて、ブラウザがファイルを見つけられていません。相対パスの階層ミス、ファイル名の綴り違い、拡張子ミス、rel="stylesheet" の書き忘れなどが典型です。

確認方法

開発者ツールの「Network」タブを開いてページを再読み込みし、CSSファイルの行を探します。ステータスが404（Not Found）なら、パスが間違っていてファイルが見つかっていない証拠です。200なら読み込み自体は成功しているので、原因は別（対象違いや詳細度）です。

<!-- よくある誤り -->
<link href="style.css">                 <!-- rel="stylesheet" 抜け -->
<link rel="stylesheet" href="styles.css"> <!-- ファイル名違い(style/styles) -->
<link rel="stylesheet" href="/css/style.css"> <!-- ルート指定が環境と不一致 -->

<!-- 正しい例（HTMLと同じ階層にcssフォルダがある場合） -->
<link rel="stylesheet" href="./css/style.css">

直し方

Networkタブで404が出ているファイルの正しい相対パス／絶対パスを確認して修正します。./（同じ階層）、../（1つ上）を意識し、フォルダ構成と照らし合わせましょう。rel="stylesheet" の書き忘れも意外と多いので、あわせて確認してください。

相対パスと絶対パスの違いを理解する

パス誤りを減らすには、相対パスと絶対パスの違いを押さえておくのが近道です。相対パスは「今のファイルから見た位置」、絶対パス（ルート相対）は「サイトの一番上から見た位置」を表します。次の表で整理しましょう。

ローカルでは動いたのに本番で404になる、というトラブルの多くは、このルート指定（先頭の /）が、ローカルと本番でズレていることが原因です。サブディレクトリで運用しているサイトでは、ルート相対のつもりが別の場所を指してしまいます。迷ったら相対パス（./ や ../）で書き、Networkタブで200になることを確認するのが確実です。

原因⑦：CSSの構文エラーで以降が無効になっている

どこかの記述で構文を間違えると、そこから先のCSSがまとめて効かなくなることがあります。「ある行から下だけ効いていない」ときは、その少し上に構文エラーが潜んでいる可能性が高いです。

症状

あるプロパティより上は効いているのに、特定の行から下のスタイルがごっそり効かない。あるいは、一見関係ない離れた場所のスタイルが崩れる、という状態です。

原因

CSSは、閉じ忘れの波かっこ { } やコロン・セミコロンの抜けがあると、そこからのパース（解析）がずれてしまい、続くルールを正しく読めなくなります。とくに波かっこの閉じ忘れとコロンの抜けは影響範囲が広く、以降のブロックがまとめて無効になりがちです。

確認方法

開発者ツールの「Console」タブにCSSの警告が出ることがあります。また、Networkタブで対象のCSSファイルを開いて中身を確認し、問題の行の直前で { } が正しく閉じているかを目視します。エディタのシンタックスハイライトで色が崩れる場所も、エラーの手がかりになります。

/* 悪い例：セミコロンと閉じかっこの抜け */
.a {
  color: red    /* ← セミコロン抜け */
  font-size: 16px;
/* ← 閉じかっこ } を忘れている */
.b {
  color: blue;  /* ← .a が閉じていないので、ここも巻き込まれて無効化 */
}

/* 良い例：各宣言にセミコロン、ブロックごとに閉じかっこ */
.a {
  color: red;
  font-size: 16px;
}
.b {
  color: blue;
}

直し方

{ と } の数が一致しているか、各宣言の末尾にセミコロンがあるかを確認します。エディタの整形（フォーマット）機能や、CSS Lint系のツールを使うと、構文エラーの位置を自動で教えてくれます。VS Codeなら拡張機能やコマンドパレットの整形で崩れを検出しやすくなります。

構文エラーを未然に防ぐコツ

構文エラーは、書いているそばから気づける環境を整えておくのが一番の対策です。編集部が新人にすすめている工夫を挙げます。どれも一度設定すれば、以降ずっと効きます。

• エディタの自動整形（フォーマッタ）を保存時に走らせる：Prettierなどを使うと、保存のたびにインデントやかっこの対応が整い、崩れがひと目で分かります。
• シンタックスハイライトの色に注目する：色が急に変わる・コメントの色が続いてしまう場所は、その手前で構文が壊れているサインです。
• プロパティは1行に1つ、必ずセミコロンで終える：最後の宣言にもセミコロンを付けておくと、後から行を足したときのミスが減ります。
• かっこはペアで先に書く：{} を先に打ってから中身を書くと、閉じ忘れが起きにくくなります。

それでも混入したときは、問題が起きている行より「上」を疑うのが鉄則でした。効かなくなった最初の行から少しずつ上へさかのぼり、直前のブロックが正しく閉じているかを確認していけば、必ず原因の1文字にたどり着けます。

原因⑧：メディアクエリの条件から外れている

PCでは効くのにスマホで効かない（またはその逆）というときは、メディアクエリ（@media）の条件範囲を疑います。表示している画面幅が、あなたのCSSが効く条件から外れている状態です。

症状

同じCSSなのに、PCブラウザでは反映されるがスマホでは反映されない。あるいはブラウザ幅を広げたり狭めたりすると、効いたり効かなくなったりする、という状態です。

原因

メディアクエリは「画面幅が○px以上／以下のとき」といった条件でCSSを切り替えます。min-width と max-width の指定を取り違えていたり、ブレイクポイントの数値がずれていたりすると、狙った画面幅で条件が成立せず、CSSが適用されません。スマホで崩れる場合は、そもそも viewport のメタタグが抜けていることもあります。

確認方法

開発者ツールのデバイスツールバー（スマホ表示モード）で画面幅を変えながら、どの幅でスタイルが切り替わるかを確認します。Stylesパネルでは、どのメディアクエリの中にあるルールかも表示されるので、条件と現在の幅を照合できます。

<!-- スマホで崩れるならまずこれを <head> に確認 -->
<meta name="viewport" content="width=device-width, initial-scale=1">

/* 悪い例：min/max の取り違えで、意図した幅に当たらない */
@media (min-width: 600px) {
  .box { color: red; }   /* 600px以上に適用（スマホには当たらない） */
}

/* 良い例：スマホ（狭い画面）に当てたいなら max-width */
@media (max-width: 600px) {
  .box { color: red; }   /* 600px以下に適用（スマホに当たる） */
}

直し方

狙いたい画面幅に対して min-width（○px以上）か max-width（○px以下）のどちらが正しいかを整理し、ブレイクポイントの数値を見直します。スマホで見た目が総崩れするときは、viewportメタタグが入っているかを最優先で確認してください。

viewportメタタグが抜けているとどうなるか

スマホでCSSが「効かない」と感じるケースの中には、実はメディアクエリではなくviewportメタタグの抜けが原因のものが混じっています。このタグが無いと、スマホのブラウザはページを「PC幅（例：980px）」として描画し、それを縮小して表示します。すると、あなたが max-width: 600px で書いたスマホ用のスタイルは、ブラウザ内部の幅が980px扱いのため発動しません。結果として「スマホなのにPCのレイアウトのまま小さく表示される」状態になります。

つまり、メディアクエリを正しく書いていても、viewportが無ければ画面幅の判定そのものが狂うということです。レスポンシブ対応が丸ごと効いていないように見えたら、メディアクエリを直す前に、まず <head> にviewportメタタグがあるかを確認してください。これ1行で一気に解決することも珍しくありません。

原因⑨：インラインstyle・属性が優先されている

HTMLタグに直接書かれた style属性（インラインstyle）は、通常のCSSより強く、詳細度でも上位に位置します。外部CSSで指定しても、インラインstyleに負けて反映されないことがあります。

症状

CSSファイルで色やサイズを指定しても効かず、開発者ツールで見ると要素に element.style として直接値が入っている。多くの場合、そのインラインstyleが最優先で勝っています。

原因

インラインstyleは詳細度の枠でいう最上位（a）にあたり、通常のセレクタ（ID・クラス・要素）よりも強く適用されます。手書きのstyle属性のほか、JavaScriptやプラグインが動的にstyleを書き込んでいることもあり、この場合はCSSファイルをいくらいじっても勝てません。

確認方法

開発者ツールで対象要素を選び、Stylesパネルの一番上に element.style { } という項目がないかを見ます。ここに値が入っていれば、インラインstyleが効いている証拠です。HTMLの該当タグを直接見て、style="..." が書かれているかも確認します。

<!-- 悪い例：インラインstyleが外部CSSより優先されて赤いまま -->
<p style="color: red;" class="note">テキスト</p>

<!-- 外部CSSで青にしても効かない -->
<!-- .note { color: blue; } ← 負ける -->

直し方

原則はHTML側のインラインstyleを削除し、スタイルはCSSファイルに集約することです。どうしてもインラインstyleを消せない（プラグインが出力しているなど）場合は、最終手段としてCSS側で !important を使い、詳細度でも同等以上にして上書きします。JavaScriptがstyleを書き込んでいる場合は、そのスクリプト側を修正するのが本筋です。

補足として、詳細度の観点でインラインstyleに勝てるのは!important付きのCSSだけです。通常のセレクタは、どれだけIDやクラスを重ねてもインラインstyleには勝てません。逆に言えば、開発者ツールで element.style に値が入っているのを見つけたら、「これはCSSファイルを直すだけでは勝てない相手だ」とすぐ判断できるということです。まずはインラインstyleを生んでいる出どころ（手書きのHTMLか、JavaScriptか、プラグインか）を特定するのが解決の近道になります。

実例で学ぶ｜切り分けの流れを再現する

原因を1つずつ知っても、実際のトラブルでは「どれに当てはまるか」を見抜く力が要ります。ここでは、編集部がよく遭遇する典型的な3つのケースを取り上げ、どう考えて切り分けるかを再現します。自分のトラブルと照らし合わせてみてください。

ケース1：ボタンの色を変えたのに変わらない

.btn { background: #ffbf00; } と書いたのに、ボタンの色が変わりません。手順はこうです。まずスーパーリロード。変わらなければボタンを右クリック→検証。Stylesパネルを見ると、自分の .btn が打ち消し線で消され、上に .card .btn { background: #333 !important; } が生きていました。これはタイプA（上書き負け）で、犯人は !important（原因③）と詳細度（原因②）。相手のCSSがテーマ由来で外せないため、.page .card .btn { background:#ffbf00 !important; } と詳細度・重要度をそろえて解決しました。

ケース2：スマホだけレイアウトが崩れる

PCでは整っているのに、スマホで見ると横並びが縦積みにならず崩れます。開発者ツールのデバイスツールバーで幅を狭めると、期待した @media のスタイルが当たっていません。Stylesで確認すると、指定は @media (min-width: 768px) の中。スマホ（狭い画面）に当てたいのに「768px以上」の条件だったため、狭い画面では発動していませんでした（原因⑧）。max-width: 767px に直し、あわせて viewport メタタグの有無も確認して解決です。

ケース3：本番だけ全部のCSSが効かない

ローカルでは完璧なのに、本番にアップしたらCSSが全滅。開発者ツールのNetworkタブでCSSファイルを見ると、ステータスが 404。パスを確認すると、ローカルは ./css/style.css で動いていたのに、本番はサブディレクトリ運用でルート指定 /style.css がずれていました（原因⑥）。相対パスに直してアップし直したら、一発で反映されました。もし 200 だったら、次はキャッシュ（原因①）を疑う、という流れです。

3つのケースに共通するのは、必ず「スーパーリロード → 開発者ツールで検証 → 打ち消し線とNetworkステータスを見る」の順で進めていることです。この型さえ守れば、初めて出会うトラブルでも落ち着いて原因にたどり着けます。逆に、ケースごとに違う直し方をいきなり試すと、たまたま直っても「なぜ直ったか」が分からず、次に同じトラブルが起きたときにまた一から悩むことになります。

もう1つ大切なのは、Networkタブのステータス（200か404か）で「タイプA」と「タイプB」を機械的に振り分けられることです。ファイルが届いている（200）のに効かないなら上書き問題（タイプA）、届いていない（404）なら読み込み問題（タイプB）。この一点を確認するだけで、疑うべき原因が半分に絞れます。ケースに出会うたびにこの型で処理していけば、切り分けは反射的にできるようになります。

開発者ツール（DevTools）でCSSの効き具合を特定する手順

ここまで9つの原因を見てきましたが、そのほとんどは開発者ツールを開けば数十秒で切り分けられます。開発者ツール（DevTools）は、ブラウザに標準搭載されたWeb制作者向けの検証ツールで、CSSが反映されない問題を解決する最強の武器です。手順を身につけましょう。

開発者ツールは、Chrome・Edge・Firefox・Safariといった主要ブラウザにすべて備わっています。名前や見た目は少しずつ違いますが、「要素を検証してStylesを見る」という基本操作はどのブラウザでも共通です。この記事ではChromeを例に説明しますが、他のブラウザでも同じ考え方でそのまま使えます。まだ使ったことがない方も、ここで一度覚えてしまえば、以降のCSSトラブルは怖くなくなります。

開発者ツールの開き方

• Windows：F12、または Ctrl + Shift + I。
• Mac：Command + Option + I。
• どのOSでも、調べたい要素を右クリック →「検証」が最速です。

CSSが反映されない原因を特定する流れ

1. 対象の要素を右クリック →「検証」で、その要素をElementsパネルで選択する。
2. 右側のStyles（スタイル）パネルを見る。その要素に効いている／効いていないCSSが、ファイル名・行番号つきで一覧表示される。
3. 打ち消し線に注目する。打ち消し線（取り消し線）が引かれたルールは「書かれているが上書きされて無効」。何が勝っているかを上にたどる。
4. そもそも自分のCSSが一覧に無いか確認する。無ければ「マッチしていない（原因④）」か「ファイル未読込（原因⑥）」。
5. Computed（計算済み）タブで最終的な値を確認する。実際にブラウザが採用した最終値と、その値がどのルール由来かを追える。

この流れの肝は「打ち消し線」と「そもそも表示されているか」の2点です。打ち消し線があれば上書き問題（詳細度・!important・後勝ち）、表示すらされなければマッチ／読み込み問題、と一瞬で切り分けられます。この記事の前半で説明した「タイプA（上書き負け）」と「タイプB（そもそも届いていない）」の分類が、ここでそのまま役立ちます。開発者ツールは、その分類を目で確認するための道具だと考えてください。

慣れるまでは、この5ステップを紙に書いて手元に置いておくのもおすすめです。手順を1つずつ声に出しながら進めると、焦っているときでも飛ばさずに切り分けられます。何度か繰り返せば、要素を右クリックした瞬間にどこを見るべきかが分かるようになり、確認は本当に数十秒で終わるようになります。

Computedタブの使い方

Styles（スタイル）タブが「どのルールが書かれ、どれが勝ったか」を見るのに対し、Computed（計算済み）タブは「最終的にこの要素はこの値になった」という結果を見るためのものです。たとえば color の項目を展開すると、その値がどのCSSファイルの何行目から来たのかまで表示されます。「結局いま何色なのか」「その色はどこで決まったのか」を確定させたいときに便利です。

その場で値を書き換えて試す

Stylesパネルでは、値をクリックしてその場で書き換えたり、チェックボックスでプロパティを一時的にオン・オフしたりできます。これで「この値にすれば直る」を確定させてから、実際のCSSファイルに反映するという進め方ができます。開発者ツール上の変更はページを再読み込みすると消えるので、確定したら必ずファイル側に書き戻しましょう。

Stylesパネルの色分けを読む

Stylesパネルは、情報を色や表示で伝えてくれます。読み方を知っておくと、切り分けが一段と速くなります。次のサインを覚えておきましょう。

この表を頭に入れて開発者ツールを開けば、「打ち消し線か・表示すら無いか・警告か」の3択を見るだけで、原因のグループを瞬時に絞り込めます。開発者ツールは眺めるものではなく、この観点で「読む」ものだと意識してください。

WordPress・キャッシュ系プラグイン特有の注意点

WordPressでCSSが反映されないときは、通常の原因に加えてキャッシュとテーマの仕組みが絡みます。静的なHTML/CSSより「変わらない」が起きやすいので、WordPressならではの確認ポイントを押さえましょう。

キャッシュ系プラグインのキャッシュを消す

WordPressでは高速化のために、ページやCSSをキャッシュするプラグインを入れていることが多いです。これらはCSSを変更しても古いキャッシュを配信し続けるため、まずプラグイン管理画面から「キャッシュのクリア（削除）」を実行します。サーバー側のキャッシュ機能やCDNを使っている場合は、そちらのキャッシュも合わせて消します。

ミニファイ（結合・圧縮）機能に注意

高速化プラグインには、複数のCSSを1つにまとめたり圧縮したりするミニファイ（minify）・結合機能があります。これがオンだと、あなたが編集した元のCSSではなく、まとめられた古いキャッシュファイルが配信され続けることがあります。反映されないときは、いったんミニファイ機能をオフにして確認すると切り分けられます。

追加CSS・カスタマイザーとの競合

WordPressのカスタマイザーには「追加CSS」欄があり、テーマファイルとは別にCSSを書けます。この追加CSSは後から読み込まれるため、テーマ本体のCSSより優先されやすいです。「テーマのstyle.cssを直したのに変わらない」ときは、追加CSSやテーマ独自のカスタム設定が上書きしていないかを確認します。

子テーマとブラウザキャッシュ

テーマを直接編集せず子テーマで上書きしている場合、親テーマと子テーマのどちらのCSSが後に読み込まれているかで勝敗が決まります。また、WordPressはCSSファイルにバージョン番号（?ver=...）を付けてキャッシュを制御していることがあり、これが更新されないと古いCSSが配信され続けます。開発者ツールのNetworkタブで、実際に読み込まれているCSSのURLとバージョンを確認しましょう。

WordPressでCSSが効かないときのチェック順

WordPress特有の要素が絡むぶん、確認する順番を決めておくと切り分けが速くなります。次の順で潰していくのが効率的です。

1. キャッシュ系プラグインとサーバー・CDNのキャッシュを削除する。まずこれで反映されるケースが非常に多い。
2. ミニファイ・結合機能を一時オフにして、まとめられた古いファイルが配信されていないかを確認する。
3. 追加CSS（カスタマイザー）を確認する。テーマ本体より優先されやすいので、ここで上書きされていないか見る。
4. 親テーマ／子テーマの読み込み順を確認する。開発者ツールのNetworkで、どのstyle.cssが後に来ているかを見る。
5. それでも駄目なら通常の9原因（詳細度・!important・セレクタ等）に戻って、開発者ツールで検証する。

ポイントは、WordPressではまず「キャッシュとミニファイ」を疑うことです。静的サイトなら真っ先に開発者ツールを開くところ、WordPressではその前にキャッシュ層を1枚はがす、と覚えておくと迷いません。

テーマファイルを直接編集するリスク

なお、テーマ本体の style.css を直接書き換えるのはテーマ更新で上書きされて消えるリスクがあるため、実務では推奨されません。カスタムCSSは「追加CSS」欄か子テーマ、あるいはCSSを管理できるプラグインにまとめるのが安全です。どこにCSSを書いたかを一元管理しておくと、「どのCSSが効いているのか分からない」という混乱そのものを防げます。

そもそも「反映されない」を起こさないための設計・習慣

トラブルは、起きてから直すより起きないようにするほうが圧倒的にラクです。ここでは、CSSが反映されない問題そのものを減らすための設計と習慣を、編集部の実務目線でまとめます。学習中から意識しておくと、後々の苦労が大きく減ります。

IDでスタイルを当てない・詳細度を上げすぎない

詳細度トラブルの根本原因は、セレクタを強くしすぎることです。スタイルは原則クラスで当て、IDはJavaScriptやページ内リンクの目印に限定する。こうしておくと、後から上書きするときも同じクラス指定で足りるため、!importantに頼らずに済みます。「上書きしたくなったらまたクラスを重ねる」のではなく、最初からフラットな詳細度を保つのがコツです。

!importantを安易に使わない

!important は一度使うと、それに勝つためにまた !important が必要になり、雪だるま式に増えていきます。自作CSSでの!importantは原則ゼロを目指すくらいの意識でちょうどいいです。どうしても必要なのは、テーマやプラグインなど「自分では外せない外部の!important」に勝つときだけ、と割り切りましょう。

読み込み順を固定する

複数のCSSを読み込むなら、ライブラリ・共通CSSを先に、上書きしたい自作CSSを最後に、という順番をプロジェクトのルールとして固定します。順番が決まっていれば、「後勝ち」を味方につけて素直に上書きできます。@import でCSS内から読み込むのは避け、<link> で並べて順番を目で管理できるようにするのがおすすめです。

保存時フォーマットとキャッシュバスティングを仕込む

エディタに保存時の自動整形を入れておけば構文エラーを早期に発見でき、CSSのURLにバージョン番号を付けておけばキャッシュ問題を防げます。環境側で防げるトラブルは、環境で防ぐ。人間の注意力に頼らず、仕組みで潰しておくのがプロの作法です。これらを最初に整えておくだけで、「反映されない」に費やす時間が驚くほど減ります。

最後にもう1つ。CSSを書くときは、命名をルール化して、同じ意味のクラスがあちこちに散らばらないようにするだけでも、上書き事故がぐっと減ります。どこにどのスタイルを書いたかを自分で把握できていれば、「どのCSSが効いているのか分からない」という混乱そのものが起きにくくなるからです。設計と習慣でトラブルの芽を摘んでおくことが、結果的に一番の時短になります。

それでも反映されないときの確認チェックリスト

ここまでの内容を、上から順に試せる確認チェックリストとしてまとめました。CSSが変わらないときは、このリストを1つずつ潰していけば、9つの原因のどれかに必ず行き当たります。編集部が実際の切り分けで使っている順番です。

• スーパーリロードした？（Ctrl+F5 / Cmd+Shift+R）シークレットウィンドウで反映されるならキャッシュが原因（原因①）。
• 開発者ツールで対象要素を検証した？ F12 →「検証」→ Stylesパネルを見る。すべての切り分けの起点。
• 自分のCSSがStylesに表示されている？ 表示されない → セレクタのマッチミス（原因④）かファイル未読込（原因⑥）。
• 打ち消し線が引かれている？ 引かれている → 詳細度負け（原因②）・!important（原因③）・後勝ち（原因⑤）のいずれか。
• 相手にIDや!importantが含まれていない？ 含まれるなら、こちらの詳細度を合わせるか、設計を見直す。
• CSSファイルはNetworkタブで200になっている？ 404ならパス誤り（原因⑥）。304やfrom cacheならキャッシュを疑う。
• 構文エラーがない？ {} の対応・セミコロン・コロンをチェック。ある行から下が全滅なら構文エラー（原因⑦）。
• メディアクエリの範囲内で見ている？ PC/スマホで挙動が違うならmin/max・ブレイクポイント・viewportを確認（原因⑧）。
• インラインstyleが入っていない？ element.styleに値があれば、それが優先されている（原因⑨）。
• （WordPressの場合）キャッシュ系プラグインとミニファイを確認した？ キャッシュ削除・ミニファイ一時オフを試す。

このチェックリストを上から順にたどれば、たいていは3〜4項目目までに原因が判明します。大事なのは、思いつきで直すのではなく、上から順に切り分けることです。順番を守るだけで、解決までの時間が大きく変わります。

なぜ「上から順」なのかというと、上の項目ほど原因の頻度が高く、確認コストが低いからです。スーパーリロードは数秒でできてキャッシュ問題を一発で排除できますし、開発者ツールでの検証は残りのほぼすべての原因を一度に切り分けられます。頻度が高く手間の少ないものから潰していくのが、最短で解決するコツです。慣れてきたら、症状から当たりをつけて途中の項目に飛んでも構いませんが、迷ったら必ずこの順番に戻ってきてください。原因が分からず手が止まったときほど、基本の順番が効いてきます。

よくある質問

Q. CSSを更新して保存したのに、まったく変わりません。何から確認すべき？

まずスーパーリロード（Ctrl+F5 / Cmd+Shift+R）を試してください。それでも変わらないなら、シークレットウィンドウで開いてみます。シークレットで反映されていればキャッシュが原因（原因①）です。反映されていなければ、開発者ツールで対象要素を検証し、自分のCSSが表示されているか・打ち消し線が引かれているかを確認します。この2ステップで、原因が「キャッシュ」「マッチミス」「上書き」のどれかに絞れます。

Q. 一部のプロパティだけ効いて、特定のプロパティだけ効きません。

そのプロパティが別のルールに上書きされている可能性が高いです。開発者ツールでその要素を検証し、効かないプロパティに打ち消し線が引かれていないか確認しましょう。引かれていれば、詳細度で負けているか（原因②）、!important に負けているか（原因③）、後から読み込まれたCSSに上書きされている（原因⑤）のいずれかです。打ち消し線がなくプロパティ名がグレーや警告表示なら、値の書き間違い（無効な値）も疑ってください。

Q. PCでは効くのに、スマホで見ると効きません。

メディアクエリ（@media）の条件から外れている可能性が高いです（原因⑧）。min-width と max-width の取り違えや、ブレイクポイントの数値ずれを確認してください。また、スマホで全体が崩れる場合は、<head> に <meta name="viewport"...> が入っているかを最優先でチェックします。開発者ツールのデバイスツールバーで画面幅を変えながら、どの幅でスタイルが切り替わるかを見ると確実です。

Q. ローカルでは反映されるのに、本番サーバーにアップしたら変わりません。

多くはサーバー側やCDN、キャッシュ系プラグインのキャッシュが原因です。まず本番でスーパーリロードし、シークレットウィンドウで確認します。それでも変わらなければ、サーバーやCDN、WordPressのキャッシュを削除してください。あわせて、本番にアップロードしたファイルが本当に最新版か（アップロード漏れ・別フォルダにアップしていないか）と、CSSのパスがローカルと本番で違っていないか（原因⑥）も確認します。

Q. クラスを重ねて書いたのに、なぜか効きません。

相手のセレクタにIDが含まれている可能性が高いです（原因②）。詳細度のルール上、クラスをいくつ並べてもID1個には勝てません。開発者ツールで、いま効いているルールのセレクタを確認してください。IDが使われているなら、こちらもIDを含めるか、そもそも既存側をIDに依存しない設計に直すのが根本解決です。

Q. とりあえず !important を付ければ直りますか？

直ることは直りますが、!important の多用は強くおすすめしません。!important は詳細度を無視して最優先されるため、後から自分自身が上書きに苦しむことになり、CSS全体の見通しが悪くなります。基本は詳細度で解決し、テーマやプラグインなど「外部の変更できない!important」に勝つときだけ、最後の手段として使ってください（原因③）。

Q. 開発者ツールを開いても、どこを見ればいいか分かりません。

見るべきはStyles（スタイル）パネルの2点です。1つ目は「自分のCSSがそもそも表示されているか」。表示されなければマッチミスか未読込です。2つ目は「打ち消し線が引かれているか」。引かれていれば、そのルールは何かに上書きされています。上書きしているルールをたどれば、原因（詳細度・!important・後勝ち）が特定できます。最終的な値を確定したいときは Computed タブを使います。

Q. 反映はされるのですが、たまに古い表示に戻ります。

キャッシュが不安定に効いている状態です（原因①）。開発者ツールを開き、Networkタブの「Disable cache」にチェックを入れて開発すると、開発中はキャッシュに悩まされにくくなります。WordPressなら、キャッシュ系プラグインのキャッシュ有効期限やミニファイ設定を見直しましょう。本番では、CSSファイルにバージョン番号を付けて更新時にキャッシュを切り替える仕組みが有効です。

Q. 開発者ツールで自分のCSSが打ち消し線で消えています。何をすればいい？

打ち消し線は「そのルールは書かれているが、別のルールに上書きされて無効」というサインです。上書きしている勝者のルールが、同じStylesパネルの上のほうに表示されています。まず勝者のセレクタを見て、IDが含まれていないか（詳細度）・!importantが付いていないか・自分より後に読み込まれていないかを確認してください。そのうえで、自分のセレクタを勝者と同等以上の詳細度にそろえる、または勝者側を弱くする、のどちらかで解決します。

Q. インラインstyleを消せません（プラグインが出力している）。どうすれば？

HTML側を触れない場合は、CSSで同じプロパティに!importantを付け、詳細度も高めて上書きするのが現実的な対処です。ただしこれは対症療法なので、可能であればプラグイン側の設定でそのstyle出力を止められないか、別のプラグインに替えられないかも検討してください。JavaScriptがstyleを書き込んでいる場合は、そのスクリプトの実行タイミングや処理内容を修正するのが根本解決になります。

Q. あるプロパティより下だけ、まとめてCSSが効かなくなりました。

その効かなくなった行の少し上に構文エラーが潜んでいる可能性が高いです（原因⑦）。CSSは {} の閉じ忘れやコロン・セミコロンの抜けがあると、そこからのパースがずれて、以降のルールをまとめて読めなくなります。効かなくなった最初の行から上へさかのぼり、直前のブロックが正しく閉じているかを確認してください。エディタの整形機能を使うと、崩れている場所が一目で分かります。

Q. WordPressでカスタマイザーの追加CSSに書いたのに効きません。

追加CSSはテーマ本体より後に読み込まれるため通常は優先されますが、それでも効かない場合はキャッシュ系プラグインのキャッシュとミニファイをまず疑ってください（キャッシュ削除・ミニファイ一時オフ）。それでも駄目なら、そのプロパティが !important や、より詳細度の高いテーマ側ルールに負けていないかを開発者ツールで確認します。プレビュー画面では反映されるのに公開側で変わらないときは、ほぼキャッシュが原因です。

まとめ

CSSが反映されない・変わらないという問題は、Web制作を学ぶうえで誰もが通る道です。しかし原因は9つのパターンにほぼ収まり、開発者ツールを使えば数十秒で切り分けられます。キャッシュ→開発者ツールで検証→打ち消し線の有無、という順で見ていけば、闇雲にコードを書き換えることなく最短で解決できます。

特に、詳細度（Specificity）の考え方と、開発者ツールでの検証手順の2つは、今回の9つの原因の多くに共通する土台です。この2つを身につければ、「なぜか効かない」に振り回されることがなくなり、狙ったとおりにデザインをコントロールできるようになります。困ったときは、この記事の確認チェックリストを上から順にたどってみてください。

最初はチェックリストを見ながらでも構いません。何度か切り分けを経験するうちに、「この症状ならまずここを見る」という勘が自然と身につきます。そうなれば、CSSが反映されないトラブルは「怖いもの」から「数十秒で片付く作業」に変わります。大事なのは、その場しのぎで直すのではなく、なぜ効かなかったのかを毎回きちんと理解すること。理解を積み重ねた分だけ、あなたのCSSはシンプルで壊れにくくなっていきます。

・切り分けが9割：まずキャッシュ、次に開発者ツールで検証。闇雲に直さず、上から順に原因を潰す。
・上書き問題は詳細度で理解：ID＞クラス＞要素の強さと!importantを押さえれば、「打ち消し線」の理由が読める。
・!importantは最後の手段：基本は詳細度と読み込み順で解決し、CSSをシンプルに保つ。

とはいえ、詳細度・カスケード・開発者ツールの使いこなしは、独学だと「なんとなく」で止まってしまいがちです。WithCodeでは、CSSが効かない原因を自分で切り分けられる「調べて直す力」まで含めて、実践的に身につけられます。手を動かしながら、つまずくポイントを1つずつ潰していけるので、未経験からでもデザインを思いどおりにコントロールできるようになります。

WithCodeを体験できる初級コース公開中！

初級コース(¥49,800)が完全無料に！

• 期間：1週間
• 学習内容：
  ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
  → 正しい学習方法で「確かな成長」を実感できるカリキュラム。

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！