CSSメディアクエリの使い方｜画面幅・ブレークポイント・検証を学ぶ

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

CSSメディアクエリは、画面の幅、印刷、入力機器、利用者の設定などの条件に合わせて、CSSを適用する仕組みです。最初は狭い画面で読める基本形を書き、幅が広がったら必要な指定だけを重ねると理解しやすくなります。「スマホ用」「パソコン用」という名前だけで分けず、どの条件で何が変わるかを説明できるようにしましょう。

この記事では六枚のカードを一列、二列、三列へ切り替える練習用ページを作ります。640pxと960pxの境界を使い、条件が重なるときの順序、境界の前後、長い文字、拡大表示、動きの軽減、印刷まで確認します。Grid自体の配置技法より、条件の一致と適用結果を照合することが中心です。

仕様の確認日は2026年10月4日です。MDNの現行CSSメディアクエリ資料に基づきます。掲載例は外部依存のないHTML/CSSで、ローカルでは要素・条件・境界の期待値を照合しました。検証環境のブラウザー起動制約により、実際のブラウザー表示、端末での操作、印刷結果は未検証です。コードの点検と実表示の成功は区別します。図版は説明用の生成イメージです。

狭い画面から設計し、何を条件で変えるか決める

メディアクエリは、条件に合うCSSを選ぶ入口

メディアクエリでは、@mediaに続けて条件を書き、その中に適用したいCSSを置きます。たとえば画面の表示で幅が640px以上のときだけ、カードを二列にする指定を適用できます。条件に合わない場合はその中の指定を使わず、ほかの基本CSSなどから表示が決まります。

条件が合っただけで、必ずその指定が最終結果になるとは限りません。CSSには詳細度、記述順、重要度などのルールがあり、同じ要素へ複数の指定が当たる場合があります。まず条件が成立しているか、次に適用するプロパティが別の指定で上書きされていないか、という二段階で調べると切り分けやすくなります。

基本の構文と対象の種類は、MDNのメディアクエリーの使用で確認できます。幅だけでなく、画面か印刷か、ポインターの性質、動きを減らす設定なども条件になります。最初にすべてを使う必要はなく、今回の表示に必要な条件から選びます。

幅は、機種名ではなくビューポートのCSSピクセルで考える

画面幅のメディアクエリで見るwidthは、一般にレイアウトに使うビューポートの幅です。PC本体の画面解像度やスマートフォンの物理的なピクセル数を、そのまま条件の値へ入れるものではありません。ブラウザーのウィンドウを狭くしたPCでも、同じ幅条件に入ることがあります。

「幅が小さいからタッチ操作」「幅が大きいからマウス」と決め付けるのも避けます。小さなウィンドウでマウスを使う人も、大きなタッチ画面を使う人もいます。列数を変える条件と、ホバー操作に応じた装飾を加える条件は、目的を分けて考えます。

今回の640px、960pxは練習のための切り替え位置です。特定のスマートフォンやタブレットを判定する公式の境界ではありません。実務では内容を少しずつ広げたり狭めたりし、文字やカードの幅が無理なく収まる位置を見て決めます。機種一覧を作るより、連続した幅で崩れないかを見る方が役立ちます。

基本の一列を、条件なしで完成させる

最初の基本形は一列です。本文の順番で六枚のカードが縦に並び、長い説明があっても読めるようにします。一列の状態で重要な情報が抜けていると、広い画面だけを整えても解決しません。まず、どんな順番で何を読んでほしいかをHTMLの並びとして決めます。

「狭い画面から作る」とは、すべての要素を小さくすることではありません。文字の大きさや操作しやすさを保ち、横幅が足りなければ縦へ並べる考え方です。画面へ押し込むために文字を極端に小さくしたり、拡大を禁止したりする必要はありません。

※表は横にスクロールできます。

viewportの指定を、拡大禁止と混同しない

スマートフォンなどでページ幅を扱うため、例のheadにはmeta name=”viewport”を入れています。width=device-widthとinitial-scale=1を指定する構成です。文字列をコピーした後は、引用符やカンマが欠けていないか確認してください。

この指定へuser-scalable=noなどを付けて、利用者の拡大を止める必要はありません。画面が崩れる問題を拡大禁止で隠すと、文字を大きくして読みたい人が困ります。viewportの意味と各値は、MDNのviewportメタデータで確認できます。

基本CSSへ幅の条件を重ね、六枚のカードを作る

外部依存のない一つのHTMLとして保存する

次のコードを、新しい練習用フォルダーへpractice.htmlなどの名前で保存します。文字コードはUTF-8にし、既存のサイトや仕事のHTMLへ直接上書きしないでください。CSSも同じファイル内に入っているため、外部のスタイルシートやJavaScriptを用意しなくても構造を確認できます。

六枚のカードには短い説明と、同じページ内の確認項目へ移動するリンクを置いています。一枚には長い英数字のファイル名を入れ、折り返しの確認に使います。外部サイトへの送信やログインは不要です。各カードの本文は練習用の架空の学習メモです。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>メディアクエリの練習</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; font-family: sans-serif; color: #183043; background: #f1f5f8; }
    main { width: min(100% - 32px, 1080px); margin: 32px auto; }
    h1 { font-size: 1.7rem; line-height: 1.4; }
    .cards { display: grid; grid-template-columns: 1fr; gap: 16px; }
    .card { min-width: 0; padding: 20px; background: white; border: 1px solid #637d92; border-radius: 8px; transition: transform 150ms ease; }
    .card h2 { margin-top: 0; font-size: 1.2rem; }
    .card p { line-height: 1.7; overflow-wrap: anywhere; }
    a { color: #124f94; text-underline-offset: 3px; }
    a:focus-visible { outline: 3px solid #154f9c; outline-offset: 3px; }
    @media screen and (min-width: 640px) {
      .cards { grid-template-columns: repeat(2, minmax(0, 1fr)); }
    }
    @media screen and (min-width: 960px) {
      .cards { grid-template-columns: repeat(3, minmax(0, 1fr)); }
    }
    @media (hover: hover) and (pointer: fine) {
      .card:hover { transform: translateY(-2px); }
    }
    @media (prefers-reduced-motion: reduce) {
      .card { transition: none; }
      .card:hover { transform: none; }
    }
    @media print {
      body { color: black; background: white; }
      main { width: auto; margin: 0; }
      .cards { display: block; }
      .card, .card:hover { break-inside: avoid; margin-bottom: 12pt; transform: none; transition: none; }
    }
  </style>
</head>
<body>
<main>
  <h1>週末に試す六つの学習メモ</h1>
  <p>画面幅に合わせて、1列・2列・3列を切り替える練習です。</p>
  <section class="cards" aria-label="学習メモ一覧">
    <article class="card"><h2>文章を整える</h2><p>一文を短くし、伝える順序を確認します。</p><a href="#check">確認項目へ</a></article>
    <article class="card"><h2>写真を整理する</h2><p>同じ目的の写真をまとめ、名前をそろえます。</p><a href="#check">確認項目へ</a></article>
    <article class="card"><h2>表を作る</h2><p>見出しと値が対応するように情報を整理します。</p><a href="#check">確認項目へ</a></article>
    <article class="card"><h2>色を比べる</h2><p>文字と背景を見比べ、読める配色を選びます。</p><a href="#check">確認項目へ</a></article>
    <article class="card"><h2>長い名前を確認する</h2><p>very-long-example-filename-for-responsive-layout-testing.txt</p><a href="#check">確認項目へ</a></article>
    <article class="card"><h2>手順を見直す</h2><p>初めて読む人が迷わない順番を考えます。</p><a href="#check">確認項目へ</a></article>
  </section>
  <h2 id="check">確認項目</h2>
  <p>境界幅、長い文字、キーボード操作、拡大表示を点検します。</p>
</main>
</body>
</html>

ファイルを保存したら、手元のブラウザーで開きます。最初はウィンドウを狭くして、六枚のカードが縦に並ぶかを見てください。その後、幅を広げ、二列、三列へ切り替わるかを確認します。ここではその動作を期待するコードを示しており、本稿の環境で実表示を確認した結果ではありません。

min-widthの条件は、指定値を含む

min-width: 640pxは、幅が640px以上という意味です。640pxちょうども条件に含まれます。639pxならこの条件には合いません。960px以上の指定も同様に、960pxちょうどで成立します。この境界を曖昧にせず、前後の幅を確かめることが後の検証につながります。

今回の基本CSSは一列で、640px以上の条件の中に二列、960px以上の条件の中に三列を置いています。960px以上では二つの幅条件が両方成立しますが、同じ.cardsへ同じプロパティを指定し、三列のルールを後に書いているため、ほかに競合がないこの例では三列が最終結果になる設計です。

@mediaの詳しい構文は、MDNの@media資料を参照できます。ここでは分かりやすさを優先し、min-widthを順に重ねる一つの方式に統一しています。異なる書き方を複数混ぜる前に、この例の条件と結果を追えるようにしましょう。

二列と三列の記述順を入れ替えたらどうなるか

練習の追加課題として、二列と三列の@mediaブロックの順番を入れ替えた場合を考えます。960px以上では両方の条件が成立し続けますが、同じ詳細度の指定では後に書いた二列が優先される可能性があります。「広い幅の条件の方が必ず勝つ」という仕組みではありません。

メディアクエリ自体が、内部のセレクターの詳細度を高くするわけでもありません。幅条件の中へ.cardsを書いても、別の場所により強いセレクターや!importantがあると、その指定が影響する場合があります。問題が起きたときは、境界値を変えるだけでなく、同じ要素を指定するCSSを確認します。

順番を試す場合は練習ファイルのコピーで行い、どこを変えたか記録して戻せるようにします。条件の値、記述順、列指定を同時に変えると、どの変更が結果を生んだか分からなくなります。一回に一つの条件を変え、予想と結果を比較してください。

Gridは配置の手段、メディアクエリは切り替えの条件

この例でGridを使っているのは、カードを等しい列へ並べやすいためです。メディアクエリそのものが列を作るわけではありません。displayやgrid-template-columnsは配置の指定、@mediaはその指定をいつ使うかの条件です。この役割を分けると、Flexboxや文字サイズの変更にも同じ考え方を使えます。

minmax(0, 1fr)とカードのmin-width: 0は、長い内容が列を押し広げる問題を考慮した指定です。さらに説明文にはoverflow-wrap: anywhereを指定し、長い英数字が折り返せるようにしています。どれも、メディアクエリの条件が正しくても内容がはみ出す可能性を減らすための設計です。

カードの読み順はHTMLの順序のままです。広い画面だけ見た目を入れ替えても、キーボードや読み上げの順序が同じように変わるとは限りません。列数の切り替えを練習するときは、まず意味の順序を固定し、見た目の順番を複雑に変更しない方が確認しやすくなります。

境界幅の前後で、条件と適用結果を照合する

639・640・641と、959・960・961を確認する

代表的な狭幅と広幅だけでなく、切り替え位置の直前、ちょうど、直後を確認します。640pxの境界なら639、640、641、960pxなら959、960、961です。これに320pxや1280pxなどを加えると、基本形と広い状態も合わせて点検できます。

次の表は、今回のCSSにほかの上書きがなく、画面向けメディアとして扱う場合の期待値です。ローカルでは条件式の真偽と記述順に基づく期待値を計算しました。ブラウザーが実際に同じ列数で描画したことまで確認した表ではない点に注意してください。

※表は横にスクロールできます。

実際のブラウザーで確認するときは、開発者ツールのレスポンシブ表示などで指定した幅と、ページが使うビューポートの幅を見ます。画面の外枠を物差しで測った値や、ウィンドウ全体の大きさとは一致しない場合があります。開発者ツールを横に表示したことでページ幅が変わることにも注意しましょう。

min-widthとmax-widthを混ぜるときの重なりを見る

max-width: 640pxも、640pxちょうどを含みます。もし一列用をmax-width: 640px、二列用をmin-width: 640pxとして同じプロパティを指定すれば、640pxでは両方の条件が成立します。どちらが適用されるかはCSSの優先順位に関係するため、境界の設計を確認する必要があります。

重なりを避けようとして639pxと640pxに分ける方法だけに頼ると、拡大や倍率などで幅が小数になる環境を考えたときに、条件のすき間を見落とす場合があります。今回のように基本形を条件なしで用意し、必要な変更をmin-widthで順に重ねる方法なら、少なくとも基本スタイルが抜ける構成にはしにくくなります。

現行CSSには範囲比較の構文もありますが、利用するブラウザーの対応とチームの書き方を確認して採用します。大切なのは新しい書き方を使うことではなく、どの幅がどの条件に入るかを漏れなく説明できることです。複数の条件が同時に成立しても意図した結果になる設計かを見ます。

andは条件を組み合わせ、カンマは別の条件を並べる

screen and (min-width: 640px)は、画面向けであることと、幅が640px以上であることの両方を要求する形です。今回の幅条件にscreenを付けているのは、印刷用の条件と役割を分けるためです。幅だけを指定した場合との違いを理解して使います。

複数のメディアクエリをカンマで並べる書き方は、いずれかの条件が成立する場合に適用するために使います。andとカンマを見た目が似ているからと置き換えると、対象範囲が変わります。最初は一つの条件を文章で説明し、その後に必要な条件だけを追加すると間違えにくくなります。

notやonlyなどの構文もありますが、条件が複雑になって読み取りにくくなったら、ルールを分けることを検討します。あとから直す人が「この指定はいつ効くのか」を説明できることが重要です。短く書けることだけで、理解しにくい条件を一つへまとめないようにしましょう。

境界が正しくても、内容が収まるとは限らない

二列へ切り替わったことと、二列のカードが読めることは別です。長い見出し、長い英数字、画像の固定幅、操作ボタンなどがあると、列数だけ正しくてもはみ出す場合があります。サンプルに長いファイル名を入れているのは、短い日本語だけでは見落とす問題を確認するためです。

六枚のカードのうち一枚だけ説明文を長くしたときも、横幅と高さの関係を見ます。高さを固定して文章を隠す方法でそろえるより、必要な内容を読み切れる構造を優先します。カードの高さが違うこと自体は、必ずしも不具合ではありません。

境界を決め直す必要がある場合は、「この機種の幅だから」ではなく、「この幅では二列にすると見出しが読みにくい」など、内容に基づいた理由を残します。サイトの文章やカード数が変わったときも、どの条件を見直すべきか判断しやすくなります。

幅以外の条件で、操作・動き・印刷にも配慮する

hoverとpointerは、操作の特徴を確認する条件

掲載例では、hover: hoverとpointer: fineの両方が成立する場合だけ、カードへポインターを重ねたときの小さな移動を付けています。これは、ホバーできる主な入力手段と、細かな位置を指せるポインターがある環境を対象にする考え方です。画面幅だけから操作方法を決めるより、目的に合う条件を使えます。

ただし、これらの条件も機種名や利用者の能力を判定するものではありません。複数の入力機器を持つ端末や、接続を変えた環境もあります。重要な説明やリンクを、ホバーしたときだけ出す設計にはしないでください。サンプルでは、装飾がなくてもすべての文章とリンクを読めます。

hoverの意味は、MDNのhoverメディア特性で確認できます。キーボードでリンクへ移ったときには別にfocus-visibleの枠を出し、どこを選んでいるか分かるようにしています。ホバー装飾とキーボードの操作表示を混同しないようにしましょう。

動きを減らす設定では、装飾の移動を止める

prefers-reduced-motion: reduceは、利用者が動きを減らす設定を希望している場合に応じるための条件です。今回の例では、カードの遷移をなくし、ホバー時の移動も止めます。動きがなくても内容は変わらないため、説明や操作に支障を出さずに配慮できます。

単にtransitionだけを消すと、移動そのものは瞬時に起こる場合があります。そのため例ではtransformもnoneへ戻しています。何を止めたいかを、アニメーションの速さだけでなく、動きそのものから考えます。条件はホバー用の指定より後に置き、同じ.card:hoverへ適用する構成にしています。

詳細はMDNのprefers-reduced-motionを参照してください。OSの設定や開発者ツールで条件を変えられる場合は、通常状態と軽減状態を比較します。本稿では条件の記述を点検し、実際のOS設定を変更した動作確認は行っていません。

印刷では、紙に必要な構造を残す

@media printの中では、背景を白、文字を黒にし、カードを縦に読み進める表示へ変更しています。画面の三列をそのまま紙へ押し込むより、文章を切らずに読むことを優先する例です。break-inside: avoidは、カードの途中でページが分かれないようにする意図ですが、内容の長さや印刷環境によって結果は変わります。

印刷用CSSを書いたら、印刷プレビューで見出し、リンク、改ページ、余白を確認します。背景色が消える設定でも意味が分かるか、長いカードが用紙をはみ出さないかを見ます。CSSの指定があるだけで、すべてのプリンターや用紙で同じ結果になるとは限りません。

紙へ出すと使えない操作リンクがある場合は、必要な説明が文章として残るかを考えます。反対に、印刷で不要な装飾を消す場合も、本文まで隠していないかを確認します。画面用と印刷用を二つの別原稿として管理するより、同じ内容を条件で見やすくする設計を目指します。

※表は横にスクロールできます。

拡大表示とキーボードで、見た目以外を確認する

文字を拡大したとき、列数が変わったり、カードが縦へ長くなったりするのは自然な調整です。元の見た目を保つために、本文の下半分を隠す、重要なリンクを画面外へ固定する、といった方法でしのがないようにします。必要な情報と操作に到達できることを確認します。

Tabキーでリンクを順番に移動し、枠線が見えるか、HTMLの読む順番と大きく矛盾しないかを見ます。サンプルではすべて同じページ内の確認項目へ移動するため、操作後の場所が分かるかも確認できます。実案件では各カードのリンク先が異なる場合があるので、名前と行き先が一致するかも点検します。

開発者ツールの端末表示は役立ちますが、実機のタッチ操作や画面拡大、OSの文字設定と完全に同じではありません。対象端末が指定されている仕事では、その端末で確認したかを別に記録します。代替の表示確認を行っただけで、すべてのスマートフォン対応が完了したと報告しないようにしてください。

効かない原因を、条件・優先順位・内容に分けて調べる

最初は、ファイルとviewportを確認する

メディアクエリが効かないように見えるときは、編集したファイルを保存したか、ブラウザーがそのファイルを開いているかを確認します。似た名前のコピーを開いたままだと、条件を書き換えても結果が変わりません。外部CSSへ分けた場合は、リンク先のパスと読み込みも確認します。

次にviewportの指定と、調べている幅を見ます。物理画面のピクセル数を条件と比べていないか、開発者ツールの表示設定が意図どおりか、ブラウザーの拡大率がどうなっているかを確認します。幅を変えたつもりでも、ページのレイアウト幅が想定と違えば、条件の判断も変わります。

構文では、@mediaの後の括弧、条件値の単位、波括弧の閉じ忘れを見ます。640pxと書くところを640だけにしたり、min-widthの綴りを間違えたりすると、期待どおりに条件を解釈できません。必要な一つのルールだけを短い練習ファイルへ移して比べると、問題の範囲を絞りやすくなります。

条件が合っているのに変わらなければ、競合を調べる

開発者ツールで対象要素のスタイルを確認できる場合は、メディアクエリ内の指定が表示されているか、打ち消されているかを見ます。条件が成立していても、別のCSSが同じプロパティを上書きする場合があります。反対に、条件自体が成立していないなら、詳細度を上げても解決しません。

!importantを追加して強引に見た目を合わせる前に、どのルールが競合しているかを確認します。理由の分からない強い指定を増やすと、次の幅や別のページで直しにくくなります。対象のクラス、同じプロパティの指定、記述順を整理し、必要な範囲へ限定して修正します。

メディアクエリの外側にある基本スタイルも確認します。二列用の指定を消しても、別の場所で固定幅やdisplayが指定されていれば、一列にならないことがあります。条件のある部分だけを読むのではなく、対象要素へ最終的にどんな値が当たるかを見ることが大切です。

横にはみ出すときは、列数より中身を調べる

条件どおり二列になっていても、カード内の長い文字や固定幅の画像が外へはみ出す場合があります。そのときは、さらに細かいブレークポイントを追加する前に、はみ出した要素を特定します。幅、最小幅、余白、折り返しの指定を順に確認してください。

ページ全体へoverflow-x: hiddenを付けて見えなくするだけでは、読めない情報が残る可能性があります。原因が表など意図的に横へ広がる要素なら、その部分に適切なスクロール領域を用意する方法もあります。今回のカードでは、長い文字が折り返して収まることを期待する設計です。

実際の内容を短いダミー文字へ置き換えると正常に見える場合は、CSSの条件だけでなくデータの長さが原因に関わっています。長文、長いURL、画像、ボタン名など、運用で入る内容を使って確かめます。最初の見本だけに合うCSSで終わらないようにしましょう。

実施した検証と、未実施の表示確認を分けて残す

この練習では、HTML内に六枚のカードがあること、viewportの値、ページ内リンクの参照先、幅条件640pxと960pxの記述順をローカルで点検しました。境界の前後については条件式を計算し、639で一列、640で二列、960で三列という期待値に矛盾がないことを確認しています。

これはブラウザーのCSSエンジンを動かした検証ではありません。実際の列数、文字の折り返し、キーボード操作、軽減設定、印刷プレビューは、利用環境で追加確認が必要です。自分が何を試したかを正確に残せば、あとでほかの人が未確認部分を引き継ぎやすくなります。

※表は横にスクロールできます。

変更記録には、問題が出た幅、対象の要素、期待値、実際の結果、修正したルールを残します。「スマホで崩れた」だけより、「幅639pxで長い名前のカードが右へはみ出した」と書く方が再現しやすくなります。修正後はその幅だけでなく、隣の境界と広い状態も再確認しましょう。

練習ページの工夫を、説明できる作品へまとめる

コードを学習記録として残すなら、なぜ640pxと960pxを選んだか、何を変え、何を共通にしたかを書き添えます。値が仮のものなら仮と明記し、実際に表示を確認した環境を後から追記します。見た目の画像だけでなく、条件と検証の説明があると、学んだ内容が伝わりやすくなります。

作品の整理には、プログラミングのポートフォリオとREADMEの作り方も参考にしてください。学習支援を比較する場合は、副業向けプログラミングスクールの比較で、費用と支援内容を確認する方法もあります。学習サービスの利用やこの練習だけで、仕事や収入が保証されるわけではありません。

CSSメディアクエリは、機種ごとの見た目を暗記するより、条件を決めて結果を確かめる道具として使うと理解しやすくなります。狭い基本形を作り、必要な変更を重ね、境界の前後と幅以外の条件を点検する。この順番で、自分が説明できるレスポンシブなページへ育てていきましょう。