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

はじめに

先週の火曜日の夜 11 時、私はモニターに映るあの忌々しいカードコンポーネントを眺めていました。

トップページでは完璧に表示されています。画像は左、テキストは右、余白も快適。しかし、これをサイドバーにコピーした瞬間、レイアウトはしわくちゃの紙くずのように崩れてしまいました。画像は細い線のように押しつぶされ、テキストは滅茶苦茶に折り返されています。

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

15%割引を入手 →広告

その時、私の頭の中には一つの疑問しかありませんでした。「この代物はどうやって自分の見た目を判断すればいいのか？」

問題はここにあります。従来のレスポンシブデザインは「ビューポート」しか見ていません。つまり、ブラウザウィンドウの大きさに応じてコンポーネントが変化するのです。しかし、コンポーネントは自分がどのくらいの幅のコンテナに配置されているのかを知る由もありません。まるで豪邸に住んでいた人が突然 30 平米のワンルームに放り込まれ、家具の配置に途方に暮れているようなものです。

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

この記事では、Tailwind レスポンシブレイアウトで最も陥りやすい二つの部分についてお話しします。ブレークポイント戦略の選び方と、コンテナクエリの使い方です。実際のコードを多めに掲載します。ドキュメントを百回読むより、自分で一度実行してみる方が実感が湧くものですから。

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

メディアクエリ：従来の手法の問題点

正直に言うと、メディアクエリは何年も使ってきて、ずっと便利だと思っていました。しかし、ある時、同じカードコンポーネントを三つの全く異なる場所に配置する必要が出てきました。トップページのカードストリーム、サイドバーのおすすめ欄、そしてモーダル内のリストです。

そこでメディアクエリの問題が露呈しました。

ご存知の通り、メディアクエリが判断するのはビューポート幅、つまりブラウザウィンドウの大きさです。しかし、コンポーネントが本当に気にすべきなのは「親コンテナがどれくらいの幅か」という点です。

例を挙げましょう。このようなスタイルを書いたとします：

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

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

しかし、ここで問題が発生します。ビューポートが 1200px で、サイドバーの幅が 280px しかない場合はどうなるでしょうか。カードは相変わらず横並びレイアウトになり、その狭苦しいサイドバーの中で押しくちゃ雑然としてしまいます。

当時、私は 44 サイズの足を無理やり 38 サイズの靴に詰め込んでいるような光景を目にしていました。

コンテナクエリ：発想の転換

コンテナクエリは視点を変えました。「ブラウザウィンドウはどれくらい大きいか」と聞く代わりに、「私のコンテナはどれくらい大きいか」と聞くのです。

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

このコードの意味は全く異なります。「コンテナ幅が 400px を超えたら、カードを横並びレイアウトにする」です。

「何がそんなに違うの？」と思うかもしれません。

大違いです。

同じカードコンポーネントでも、600px 幅のコンテンツエリアに配置すれば横並びレイアウトで問題ありません。280px 幅のサイドバーに配置すれば、自動的に縦積みに変わります。二つのコンポーネントを書く必要も、props を渡す必要も、条件分岐を書く必要もありません。

コンポーネントはついに真に「再利用可能」になりました。

ブラウザサポート状況

コンテナクエリは 2023 年頃に主要ブラウザで広くサポートされるようになりました。2024 年現在、Container Size Queries のブラウザサポート率は 90% を超えており、Chrome、Firefox、Safari、Edge が全面的にサポートしています。

古いブラウザをサポートする必要があるプロジェクトの場合は待つ必要があるかもしれません。しかし、正直に言って、現在のほとんどのプロジェクトでは採用できるはずです。

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

コンテナクエリについて話す前に、まず Tailwind のブレークポイントシステムをはっきりと理解しておく必要があります。これは基本中の基本ですから。

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

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

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

モバイルファースト：小画面から書き始める

Tailwind のブレークポイントシステムはモバイルファーストです。どういうことかというと？

スタイルを書く時、デフォルトはスマートフォン用のスタイルです。そこからブレークポイントで段階的に強化していきます。

<!-- モバイルファーストの書き方 -->
<div class="flex flex-col md:flex-row lg:gap-8">
  <!-- スマートフォン：縦積み -->
  <!-- タブレット（md）：横並びに変更 -->
  <!-- デスクトップ（lg）：間隔を追加 -->
</div>

この書き方の利点は、スタイルが単純なものから複雑なものへと積み重ねられることです。古いスマートフォンでアクセスした場合、最も基本的なスタイルしか読み込まれないため、パフォーマンスも向上します。

逆に、「デスクトップファースト」で書こうとすると、逆のブレークポイントを大量に書く必要があり、非常に面倒です。そのため、私は特別な要件がない限り、直接モバイルファーストで書く習慣をつけています。

いつカスタムブレークポイントが必要か

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

以前、管理画面システムを作った時、UI デザイナーが定めたブレークポイントが Tailwind のデフォルト値と全く異なっていました。彼女が決めたブレークポイントは、480px、720px、960px、1200px でした。

そのような場合は、tailwind.config.js を変更する必要があります：

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

今すぐ始める →広告

// 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：コンテナを定義する

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

Tailwind では、@container クラス名を追加するだけです：

<!-- 親コンテナ -->
<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 幅のコンテンツエリアに配置すれば、ゆったりとした横並びレイアウトになります。

コードを一切変更する必要がありません。

実践例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">
        このサイトについて
      </a>
    </li>
  </ul>
</nav>

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

これで、同じナビゲーションコンポーネントをどこでも再利用でき、場所に応じて異なるスタイルを書く必要がなくなります。

コンテナクエリの制限事項

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

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

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

/* これは動作しない */
@container (min-height: 400px) {
  /* 残念ながら、まだサポートされていません */
}

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

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

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

価格を見る →広告

3. ネストしすぎない

コンテナクエリのネストレベルが深くなるとパフォーマンスに影響します。最大 2-3 層までのネストをお勧めします。それ以上深くなる場合は、リファクタリングを検討すべきです。

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

ここまで書いて、あなたはこう思うかもしれません。「じゃあ、いつメディアクエリを使って、いつコンテナクエリを使えばいいの？」

良い質問です。

私はシンプルな判断基準をまとめました。**「そのスタイルが依存しているのは何か」**を見るのです。

意思決定フロー

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

├─ ビューポートサイズに依存 → メディアクエリ（md:、lg: など）
│   ├─ ページ全体のレイアウト
│   ├─ グローバルナビゲーション、ヘッダー、フッター
│   ├─ ヒーローエリア、全画面広告
│   └─ ビューポートの特定位置に固定される要素
│
└─ コンテナサイズに依存 → コンテナクエリ（@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">このサイトについて</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">
    <!-- 最内層の要素は二つのコンテナに応じてスタイルを調整可能 -->
    <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>

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

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

最後に、実際の仕事で注意すべき点についてお話しします。

コンテナクエリのパフォーマンスオーバーヘッド

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

しかし、このオーバーヘッドは非常に小さいです。疯狂するほどネストしない限りは。

以前、ある間違いを犯しました。リストの中で、各リスト項目に @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>

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

コンテナクエリが不要なシナリオもあります。

例えば、トップページにしか登場しないヒーローエリア。その幅は基本的に固定されており、メディアクエリで十分です。無理に @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:）

パフォーマンスで注意すべき二点：ネストしすぎない、使いすぎない。

現在、再利用が必要なコンポーネントをお持ちなら、ぜひコンテナクエリを試してみてください。カードコンポーネントから始めて、完了したら、二度と異なる場所のために重複したコードを書く必要がなくなることに気づくでしょう。

さらに深く理解したい場合は、Tailwind 公式ドキュメントの Container Queries チャプター、または MDN の CSS Container Queries を参照してください。

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

6 min read · 公開日: 2026年3月27日 · 更新日: 2026年3月28日

Easton

技術開発