Tailwind レスポンシブレイアウト実践：コンテナクエリとブレークポイント戦略

導入

ディスプレイに映ったあのカードコンポーネントをじっと眺めています。

トップページでは完璧です。画像は左、テキストは右、余白もちょうどいい。ところがサイドバーにコピーした途端、レイアウト全体がくしゃくしゃに丸めた紙のように崩れてしまいました。画像は一本の線に押しつぶされ、テキストの折り返しもめちゃくちゃです。

このコンポーネントは、自分がどんな見た目になるべきか、どうやって知ればいいのでしょう。

問題はここにあります。従来のレスポンシブデザインは「ビューポート」しか見ません。ブラウザウィンドウの大きさに応じてコンポーネントが変わるだけです。でもコンポーネント自身は、自分がどれくらいの幅のコンテナに収められたのかをまったく知りません。広い一軒家に住んでいた人が、いきなり 10 畳ほどのワンルームに放り込まれて、家具の置き方がまるで分からなくなったような状態です。

Tailwind のコンテナクエリは、まさにこの問題を解決するためのものです。コンポーネントが、ブラウザウィンドウだけをぼんやり見るのではなく、自分が置かれたコンテナのサイズを「感じ取れる」ようにしてくれます。

この記事では、Tailwind のレスポンシブレイアウトで特につまずきやすい 2 つのポイントを取り上げます。ブレークポイント戦略の選び方と、コンテナクエリの使い方です。書きながら実際のコードをできるだけ多く載せます。ドキュメントを 100 回読むより、自分で 1 回動かしてみるほうがずっと身につくからです。

レスポンシブデザインの進化：ビューポートからコンテナへ

メディアクエリ：古い手法の古い悩み

正直に言うと、メディアクエリは何年も使ってきて、ずっと便利だと思っていました。ところがあるとき、同じカードコンポーネントをまったく異なる 3 つの場所に入れることになりました。トップページのカードフロー、サイドバーのおすすめ枠、そしてモーダル内のリストです。

そこでメディアクエリの問題が一気に表面化しました。

メディアクエリが判断しているのはビューポートの幅、つまりブラウザウィンドウの大きさです。でもコンポーネントが本当に気にすべきなのは、自分の親コンテナがどれくらい広いか、です。

たとえば、こんなスタイルを書いたとします。

/* 従来のメディアクエリ */
@media (min-width: 768px) {
  .card {
    flex-direction: row;
  }
}

このコードの意味は「ブラウザウィンドウが 768px を超えたら、カードを横並びにする」です。

ここで問題が起きます。ビューポートが 1200px でも、サイドバーがわずか 280px の幅しかなかったらどうなるでしょう。カードはお構いなしに横並びになり、その狭すぎるサイドバーの中でぎゅうぎゅうに潰れてしまいます。

そのときの見た目は、44 サイズの足を無理やり 38 サイズの靴に押し込んだような有様でした。

コンテナクエリ：発想を変える

コンテナクエリは視点を変えます。「ブラウザウィンドウはどれくらい大きいか」ではなく、「自分のコンテナはどれくらい大きいか」を問うのです。

/* コンテナクエリ */
@container (min-width: 400px) {
  .card {
    flex-direction: row;
  }
}

この一行の意味はまったく違います。コンテナの幅が 400px を超えたとき、カードを横並びにする、という意味です。

「それの何がすごいの？」と思うかもしれません。

違いは大きいのです。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

同じカードコンポーネントを、600px 幅のコンテンツ領域に置けば横並びで問題なし。280px 幅のサイドバーに置けば、自動的に縦積みになります。2 種類のコンポーネントを書く必要も、props を渡す必要も、条件分岐をいくつも組む必要もありません。

コンポーネントがついに本当の意味で「再利用可能」になったのです。

ブラウザの対応状況

コンテナクエリという機能は、2023 年ごろにようやく主要ブラウザで広くサポートされました。2024 年時点で、Container Size Queries のブラウザ対応率はすでに 90% を超え、Chrome、Firefox、Safari、Edge がすべて対応しています。

古いブラウザへの対応がまだ必要なプロジェクトなら、もう少し待つ必要があるかもしれません。とはいえ正直なところ、今ではほとんどのプロジェクトで導入できるはずです。

Tailwind CSS のブレークポイントシステム詳解

コンテナクエリの話に入る前に、まず Tailwind のブレークポイントシステムを押さえておきましょう。これが基本中の基本だからです。

デフォルトのブレークポイント

Tailwind はデフォルトで 5 つのブレークポイントを用意しています。

この数字を覚えられなくても大丈夫です。使っているうちに自然と慣れます。大事なのは、Tailwind のブレークポイントが「最小幅」だと理解することです。つまり md:flex-row は「ビューポート幅が 768px 以上になったら flex-row を適用する」という意味です。

モバイルファースト：まず小さい画面のスタイルを書く

Tailwind のブレークポイントシステムはモバイルファースト（mobile-first）です。どういう意味でしょうか。

つまり、スタイルを書くとき、デフォルトはスマホ向けのスタイルになります。そこからブレークポイントで段階的に拡張していきます。

<!-- モバイルファーストの書き方 -->
<div class="flex flex-col md:flex-row lg:gap-8">
  <!-- スマホ：縦積み -->
  <!-- タブレット（md）：横並びに変わる -->
  <!-- デスクトップ（lg）：余白を広げる -->
</div>

この書き方の利点は、スタイルがシンプルから複雑へと層を重ねていく点です。ユーザーが古いスマホでアクセスしても、最も基本的なスタイルだけが読み込まれるので、パフォーマンスも良くなります。

逆に「デスクトップファースト」にしようとすると、逆向きのブレークポイントを大量に書く羽目になり、とても面倒です。だから私は、特別な要件がない限り、いつもモバイルファーストを使っています。

カスタムブレークポイントが必要になるとき

正直に言うと、ほとんどのプロジェクトはデフォルトのブレークポイントで十分です。ただし例外もあります。

たとえば以前、管理画面システムを作ったとき、UI デザイナーから渡されたブレークポイントが Tailwind のデフォルト値とまったく合っていませんでした。彼女が決めたブレークポイントは 480px、720px、960px、1200px でした。

こういうときは tailwind.config.js を変更します。

// tailwind.config.js
module.exports = {
  theme: {
    screens: {
      'xs': '480px',   // さらに小さいブレークポイントを追加
      'sm': '640px',
      'md': '720px',   // デフォルト値を上書き
      'lg': '960px',
      'xl': '1200px',
    }
  }
}

もう一つよくある要望があります。sm より小さいブレークポイント、たとえばとても小さいスマホ画面向けのものが欲しいケースです。xs を追加すれば対応できます。

screens: {
  'xs': '475px',   // 追加
  'sm': '640px',
  // ... その他はデフォルトのまま
}

ブレークポイント命名の意味づけに関するアドバイス

これは私が痛い目を見たポイントです。

あるとき、ブレークポイントを mobile、tablet、desktop と名付けました。直感的でわかりやすそうですよね。ところが後でプロジェクトに折りたたみ画面や車載ディスプレイが加わり、これらの名前は途端に都合が悪くなりました。

それ以来、私はサイズの記号、つまり sm、md、lg を使うようになりました。具体的なデバイスの意味を持たせず、サイズの階層だけを表します。こうしておけば、将来新しいデバイスが登場しても、ブレークポイント名が時代遅れになりません。

コンテナクエリ実践：コンポーネントに空間を「感じさせる」

さて、いよいよ本題です。ここからは実際のコードでコンテナクエリの使い方を示していきます。

第 1 ステップ：コンテナを定義する

コンテナクエリの第 1 ステップは、ブラウザに「この要素はコンテナだ」と伝えることです。

Tailwind では、@container クラスを 1 つ追加するだけです。

<!-- 親コンテナ -->
<div class="@container">
  <!-- 子要素はコンテナサイズに応じてスタイルを調整できる -->
  <div class="flex flex-col @sm:flex-row">
    ...
  </div>
</div>

@container を付けると、この div はクエリコンテナになります。その子要素は @sm、@md といったコンテナブレークポイントでスタイルを書けるようになります。

コンテナブレークポイントの一覧

Tailwind が提供するコンテナブレークポイントは、ビューポートのブレークポイントとは少し異なります。

気づきましたか。コンテナブレークポイントの値はビューポートのブレークポイントよりずっと小さいのです。これは理にかなっています。コンテナはそもそもページ内にネストされているので、幅がビューポートより大きくなることはありえないからです。

実践ケース 1：自己適応カードコンポーネント

本当に使える形のカードコンポーネントを書いてみましょう。要件は次のとおりです。

• コンテナ幅 < 384px：縦積み、画像は全幅
• コンテナ幅 >= 384px：横並び、画像は固定幅
• コンテナ幅 >= 512px：画像をさらに大きく、テキストの行数も増やす

<!-- 親コンテナ：これがクエリコンテナだとブラウザに伝える -->
<div class="@container p-4">
  <!-- カードコンポーネント -->
  <article class="flex flex-col @sm:flex-row @lg:gap-6 bg-white rounded-lg shadow">
    <!-- 画像：コンテナに応じて幅を調整 -->
    <img
      src="https://example.com/image.jpg"
      alt="記事のアイキャッチ画像"
      class="w-full @sm:w-32 @lg:w-48 h-48 @sm:h-32 @lg:h-36 object-cover rounded-t-lg @sm:rounded-l-lg @sm:rounded-tr-none"
    />

    <!-- コンテンツ領域 -->
    <div class="p-4 @sm:py-2 @lg:py-4 flex-1">
      <h3 class="text-base @lg:text-lg font-semibold mb-2">
        Tailwind コンテナクエリ入門ガイド
      </h3>
      <p class="text-sm text-gray-600 line-clamp-2 @lg:line-clamp-3">
        この記事では、Tailwind CSS のコンテナクエリ機能を使って、コンポーネントを本当の意味でレスポンシブにする方法を紹介します...
      </p>
      <div class="mt-3 flex items-center text-xs text-gray-400">
        <span>2026-03-27</span>
        <span class="mx-2">·</span>
        <span>5 分で読める</span>
      </div>
    </div>
  </article>
</div>

このコードを 280px 幅のサイドバーに置くと、カードは自動的にコンパクトな縦並びレイアウトになります。600px 幅のコンテンツ領域に置けば、ゆったりとした横並びレイアウトに変わります。

コードを一切変える必要はありません。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

実践ケース 2：再利用可能なナビゲーションバー

ナビゲーションバーは、コンテナクエリの価値が最も発揮されるシーンの一つです。

同じナビゲーションコンポーネントが、こんな場所に登場することがあります。

• トップのナビゲーションバー（たいてい幅が広い）
• サイドバー（幅が狭いこともある）
• モバイルのドロワーメニューの中

<!-- ナビゲーションコンポーネント -->
<nav class="@container">
  <ul class="flex flex-col @lg:flex-row @lg:items-center gap-2 @lg:gap-6">
    <li>
      <a href="/" class="block py-2 px-3 rounded hover:bg-gray-100">
        ホーム
      </a>
    </li>
    <li>
      <a href="/posts" class="block py-2 px-3 rounded hover:bg-gray-100">
        記事
      </a>
    </li>
    <li>
      <a href="/about" class="block py-2 px-3 rounded hover:bg-gray-100">
        About
      </a>
    </li>
  </ul>
</nav>

コンテナ幅が 512px 以上（@lg）になると、ナビゲーション項目が自動的に横並びになります。

こうすれば、同じナビゲーションコンポーネントをあちこちで再利用でき、配置場所ごとに異なるスタイルを書く必要がありません。

コンテナクエリの制約

コンテナクエリも万能ではありません。いくつか注意すべき落とし穴があります。

1. 高さはクエリできない

現時点でコンテナクエリは幅のみをサポートしています。高さのクエリはまだ仕様の議論段階です。

/* この書き方は効かない */
@container (min-height: 400px) {
  /* 申し訳ないですが、今はまだ未対応です */
}

2. コンテナはサイズコンテナでなければならない

@container を付けた要素は「サイズコンテナ」になり、その子要素がそれをクエリできるようになります。子要素の子要素でコンテナクエリを書いた場合、クエリ対象になるのは最も近いコンテナ祖先であり、必ずしも直接の親要素ではありません。

3. ネストは深くしすぎない

コンテナクエリのネストが深くなるとパフォーマンスに影響します。最大でも 2〜3 階層にとどめ、それ以上深くなるなら設計の見直しを検討することをおすすめします。

ブレークポイント戦略の選び方：メディアクエリ vs コンテナクエリ

ここまで読んで、こう思うかもしれません。「結局、いつメディアクエリを使って、いつコンテナクエリを使えばいいの？」

いい質問です。

私はシンプルな判断基準にまとめています。スタイルが何に依存しているかを見ることです。

決定フロー

問い：このスタイルは何に依存している？

├─ ビューポートのサイズに依存 → メディアクエリを使う（md:、lg: など）
│   ├─ ページ全体のレイアウト
│   ├─ グローバルナビゲーション、Header、Footer
│   ├─ Hero 領域、全画面広告
│   └─ ビューポートの特定位置に固定される要素
│
└─ コンテナのサイズに依存 → コンテナクエリを使う（@sm:、@lg: など）
    ├─ 再利用可能なコンポーネント（カード、リスト項目）
    ├─ サイドバーのウィジェット
    ├─ モーダル内のコンテンツ
    └─ ネストしたコンポーネント

メディアクエリを使うシーン

ページレベルのレイアウト：ページ全体のグリッド構造には、メディアクエリがぴったりです。

<!-- ページレイアウト：ビューポートに応じて列数を調整 -->
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
  <!-- コンテンツカード -->
</div>

このレイアウトが気にしているのは「ブラウザウィンドウがどれくらい大きいか」であって、コンテナとは関係ありません。

グローバルナビゲーション：トップのナビゲーションバーの展開／折りたたみは、ビューポート幅に依存します。

<!-- スマホ：ハンバーガーメニュー、デスクトップ：横並びナビ -->
<header class="flex items-center justify-between px-4 py-3">
  <div class="logo">Logo</div>

  <!-- スマホでは非表示、デスクトップで表示 -->
  <nav class="hidden md:flex gap-6">
    <a href="/">ホーム</a>
    <a href="/posts">記事</a>
    <a href="/about">About</a>
  </nav>

  <!-- スマホで表示、デスクトップで非表示 -->
  <button class="md:hidden">
    <span class="sr-only">メニューを開く</span>
    <!-- ハンバーガーアイコン -->
  </button>
</header>

コンテナクエリを使うシーン

再利用可能なコンポーネント：さまざまな幅のコンテナで使われるコンポーネントです。

たとえば記事カードは、こんな場所に登場するかもしれません。

• トップページのカードフロー（幅およそ 300〜400px）
• 記事詳細ページの関連おすすめ（幅およそ 250px）
• サイドバーの最新記事（幅およそ 280px）

こうしたシーンでは、コンテナクエリが最適な選択肢です。

ネストしたコンポーネント：コンポーネントの中にコンポーネントが入るケースです。

<!-- 外側のコンテナ -->
<div class="@container w-full md:w-80">
  <!-- 内側のコンテナ -->
  <div class="@container">
    <!-- 最内層の要素は、2 つのコンテナに応じてスタイルを調整できる -->
    <div class="@sm:flex-row @lg:gap-4">
      ...
    </div>
  </div>
</div>

併用する

実際のプロジェクトでは、メディアクエリとコンテナクエリを併用することがよくあります。

ページレベルはメディアクエリ、コンポーネントレベルはコンテナクエリです。

<!-- ページレベルのレイアウト：メディアクエリ -->
<div class="grid grid-cols-1 md:grid-cols-3 gap-6">

  <!-- メインコンテンツ領域 -->
  <main class="md:col-span-2">
    <!-- カードコンポーネント：コンテナクエリ -->
    <div class="@container">
      <article class="flex flex-col @sm:flex-row">
        <!-- カードの中身 -->
      </article>
    </div>
  </main>

  <!-- サイドバー -->
  <aside class="@container">
    <!-- サイドバーのコンポーネント：コンテナクエリ -->
    <div class="@sm:grid-cols-2">
      <!-- コンポーネントの中身 -->
    </div>
  </aside>

</div>

この書き方の利点は、ページ全体の構造はデバイスに応じて調整され、コンポーネント内部は実際の空間に応じて調整される点です。2 つの層でレスポンシブが働き、それぞれの役割を果たします。

パフォーマンス最適化とベストプラクティス

最後に、実務で注意すべきことを少し話します。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

コンテナクエリのパフォーマンスコスト

正直に言うと、コンテナクエリにはパフォーマンスコストがあります。ブラウザはコンテナサイズを追加で計算し、さらにサイズの変化を監視する必要があるからです。

ただし、このコストは実はとても小さいものです。狂ったようにネストしない限りは。

私は以前、ある失敗をしました。リストの中で、各リスト項目すべてに @container を付け、さらに項目の内部でコンテナを何層もネストしたのです。その結果、ページをスクロールするときにわずかなカクつきを感じました。

解決策はとてもシンプルです。不要なコンテナの階層を減らすことです。

<!-- 非推奨：すべての層に @container を付ける -->
<div class="@container">
  <div class="@container">
    <div class="@container">
      <div class="@sm:flex-row">
        <!-- ネストが深すぎる -->
      </div>
    </div>
  </div>
</div>

<!-- 推奨：必要な場所だけに @container を付ける -->
<div class="@container">
  <div>
    <div>
      <div class="@sm:flex-row">
        <!-- 最外層だけがコンテナ -->
      </div>
    </div>
  </div>
</div>

コンテナクエリを使いすぎない

実は、コンテナクエリが必要ないシーンもあります。

たとえばトップページにしか登場しない Hero 領域は、幅がほぼ固定なので、メディアクエリで十分です。無理に @container を付けると、かえって余計なことになります。

私の原則はこうです。コンポーネントを異なる幅のコンテナで再利用する必要があるときだけ、コンテナクエリを使う。コンポーネントが固定幅の場所にしか現れないなら、メディアクエリで十分です。

デバッグのコツ

Chrome DevTools はコンテナクエリのデバッグに対応していますが、入り口が少し奥に隠れています。

DevTools を開く → Elements パネル → @container を持つ要素を選択 → Styles パネルで @container ルールを見つける → ブレークポイントにマウスを乗せると、Chrome が対応するコンテナをハイライト表示します。

もう一つの方法もあります。Computed パネルで container-type を検索すると、今の要素がクエリコンテナかどうかを確認できます。

ベストプラクティス一覧

ここ数年、つまずきながら得てきた経験をまとめます。

1. コンテナ階層のコントロール：@container のネストは最大 2〜3 階層、それ以上深くなるなら設計を見直す
2. 必要に応じて使う：コンポーネントを再利用する必要があるときだけコンテナクエリ、固定シーンはメディアクエリ
3. 意味づけのある命名：ブレークポイント名はサイズ記号（sm/md/lg）を使い、デバイス名（mobile/tablet）は避ける
4. 複雑なセレクタを避ける：コンテナクエリ内のセレクタはシンプルなほどよい。複雑なセレクタはパフォーマンスに影響する
5. アニメーションでは使わない：コンテナサイズが頻繁に変わる場合、アニメーション内でコンテナクエリに依存しない

最後にもう一つ。コードを書くときは、たくさんテストしましょう。コンポーネントをさまざまな幅のコンテナに入れて効果を確認し、デフォルトのレイアウトだけでテストするのは避けてください。多くの問題は公開後に発覚します。そのときには修正が面倒になっているものです。

まとめ

ここまでで、核心となる内容はほぼ説明し終えました。振り返ってみましょう。

コンテナクエリが解決する問題は、コンポーネントがビューポート幅だけをぼんやり見るのではなく、実際のコンテナサイズに応じてレイアウトを調整できるようにすることです。こうしてはじめて、コンポーネントは本当の意味で再利用できます。

使い分けの原則はシンプルです。

• ページレベルのレイアウト → メディアクエリ（md:、lg:）
• 再利用可能なコンポーネント → コンテナクエリ（@sm:、@lg:）

パフォーマンス面では 2 点に注意しましょう。 ネストを深くしすぎないこと、使いすぎないことです。

今、手元に再利用が必要なコンポーネントがあるなら、ぜひコンテナクエリを試してみてください。まずはカードコンポーネントから始めてみると、変更後にはこう気づくはずです。もう配置場所ごとに重複したコードを書かなくていいのだ、と。

さらに深く知りたい場合は、Tailwind 公式ドキュメントの Container Queries の章や、MDN の CSS Container Queries を見てみてください。

質問があれば、ぜひコメント欄で交流しましょう。