【CSS】画面を縮小すると右側に謎の隙間が…原因は「固定幅」の積み重ねだった

CSS
この記事は約11分で読めます。

この記事の結論

画面を縮小したときに右側に現れる隙間の原因は、ほぼ100%の確率で子要素の固定幅(px)の合計が親要素の幅を超えていることです。overflow-x: hiddenで隠すのは対症療法にすぎません。DevToolsでセクション単位にdisplay: noneして犯人を絞り込み、flex-shrink: 0の削除・固定幅グリッドのminmax()への変更で根本解決してください。

この記事で解決できること

画面幅を縮小したときに右側に現れる隙間・横スクロールバーの原因特定方法と根本解決策を、実案件をもとに解説します。

  • 画面幅を縮小したときに右側に謎の隙間ができる
  • 横スクロールバーが勝手に表示される
  • overflow-x: hidden で隠しても根本解決しない

結論:隙間の正体は「固定幅要素の合計オーバー」

(Point)

レスポンシブ対応したはずなのに右側に隙間が出る——この問題は、ほぼ100%の確率で子要素の幅の合計が親要素の幅を超えていることが原因です。

個々のCSSプロパティは問題なくても、flex-shrink: 0grid-template-columns: repeat(3, 200px) のような固定幅指定が複数組み合わさると、特定の画面幅でコンテナを突き破ります。

(Reason)

なぜこれが見落とされやすいのか。理由は「個別には正しいCSS」が組み合わさったときにだけ問題になるからです。PC幅では十分なスペースがあるため発覚せず、中間的な画面幅(1000〜1200px付近)でのみ破綻します。しかも数ピクセル〜十数ピクセルの微妙なはみ出しなので、目視では気づきにくい。

以下、実際のクライアントワークで遭遇した事例をもとに、DevToolsでの原因特定 → 数値による裏付け → 根本解決の流れを解説します。

発端:画面幅1100px付近で突然現れた白い余白

PC版の確認では問題なかったのに、Chrome DevToolsで画面幅を1100px付近まで縮小した途端、右側に10〜20pxの隙間と横スクロールバーが出現しました。

先日、建設会社のコーポレートサイトをリニューアルしていたときのことです。PC版の確認を終え、Chrome DevToolsでレスポンシブチェックを始めました。

1200px以上では問題なし。しかし1100px付近まで縮小すると——

1080pxの方に右側の隙間と横スクロールバーが表示されている様子

ページ全体の右側に10〜20pxほどの隙間が出現し、横スクロールバーまで表示されています。

メディアクエリは max-width: 1200px で設定済み。各セクションのレスポンシブ対応も完了していたはずでした。

最初にやった「間違った対処法」とその限界

overflow-x: hiddenで横スクロールバーは消せますが、隙間自体は残ります。これは対症療法であり、はみ出し要素を特定して修正しない限り根本解決になりません。

焦った私は、まず以下のCSSを試しました。

横スクロールバーは消えましたが、隙間自体は残ったまま。フッターのリンクが見切れてしまっています。

これは対症療法です。「はみ出している要素」を特定して修正しなければ、別のブレークポイントでまた同じ問題が再発します。

DevToolsで犯人を特定する2つの手順

各セクションにdisplay: noneを順番に適用して犯人を絞り込み、次にElementsパネルで子要素を一つずつ選択してはみ出し箇所を視覚的に特定します。

ここからが本題です。「どの要素がはみ出しているのか」を効率的に特定する方法を紹介します。

手順1:セクション単位で display: none して切り分ける

地道ですが最も確実な方法です。Chrome DevToolsのStylesパネルで、各セクションに display: none を一時的に追加していきます。

今回はフッターを非表示にしたときだけ隙間が消えたので、犯人はフッター内のどこかに確定しました。

なお、調査を効率化するデバッグ用CSSも有効です。

これで全要素の範囲が一目でわかるので、どこがはみ出しているか視覚的に判断しやすくなります。

Stylesパネルで .footer に display: none を入力している画面

手順2:DevToolsのElementsパネルで視覚的に絞り込む

犯人がフッターだと分かったら、次はフッター内の子要素を一つずつ選択していきます。Elementsタブで要素を選択すると、その要素のボックスが画面上にハイライトされます。

Chrome DevToolsでフッター要素を選択している様子

フッター内の .footer-nav-sections-grid を選択したところ、ボックスが画面の右端をはみ出していることが視覚的に確認できました。

原因の深掘り:2つの「固定幅」が合わさった結果

(Example)

犯人の要素が特定できたので、なぜはみ出しているのかをCSSから読み解きます。フッターのHTML構造はこうなっていました。

そして問題のCSS。

問題その1:flex-shrink: 0 で縮小が完全にブロックされている

flex-shrink: 0 は「このボックスは絶対に縮小させない」という指定です。画面幅が狭くなっても、ロゴエリアは頑なに360px + margin 40px = 400px以上を確保し続けます。

問題その2:グリッドカラムが固定幅で逃げ場がない

grid-template-columns: repeat(3, 200px) は、各カラムが200px固定。グリッドの最小幅は常に以下の値になります。

どんなに画面が狭くなっても、このグリッドは648px以下には縮小しません。

数値で検証:「はみ出す瞬間」を特定する

実際に計算してみると、破綻するポイントが明確になります。

画面幅1150pxの場合(ギリギリ収まる):

要素
コンテナ内幅 1150px − 40px(padding)= 1110px
フッターヘッダー(左) 400px(flex-shrink: 0で固定)
右セクション用の残り 1110px − 400px = 710px
グリッドが必要な幅 648px

→ 710px > 648px でギリギリ収まる。

画面幅1080pxの場合(はみ出す):

要素
コンテナ内幅 1080px − 40px = 1040px
フッターヘッダー(左) 400px(縮小しない)
右セクション用の残り 1040px − 400px = 640px
グリッドが必要な幅 648px

640px < 648px で、8pxはみ出し!

コンテナ幅1040pxに対して、左400px + 右648px = 1048pxとなり、8pxはみ出す様子を視覚化

このたった8pxのオーバーフローが、右側の隙間と横スクロールバーの正体でした。個別に見ればどちらも「妥当な値」なのに、合計すると親を超える。これが固定幅の積み重ねの怖さです。

解決策:固定幅を「柔軟な幅」に置き換える

flex-shrink: 0の削除、固定幅グリッドのminmax()への変更、狭い画面での列数削減の3段階で対応します。

解決策1:flex-shrink: 0 を削除する

これで、フッターヘッダーが必要に応じて縮小できるようになります。min-width は残しておくことで、ロゴが極端に小さくなることも防げます。

解決策2:固定幅グリッドを minmax() に変更する

minmax(140px, 200px) により、グリッドの最小幅が大幅に下がります。

画面幅に応じて468px〜648pxの範囲で伸縮するようになり、はみ出しが解消されます。

解決策3:狭い画面では列数自体を減らす

画面幅がさらに狭くなる場合は、列数を段階的に減らすのも有効です。

修正後の確認

修正を適用し、DevToolsで再確認しました。

隙間がなく、フッターが画面幅内に収まっている様子

画面幅1080pxでも隙間なし。横スクロールバーも表示されなくなりました。

再発を防ぐ:レスポンシブ設計で押さえるべき4つの原則

(Point:教訓のまとめ)

今回の経験から、レスポンシブ設計で意識すべきポイントを4つにまとめます。

原則1:flex-shrink: 0 は「本当に必要な場面」だけ使う

「絶対に縮小させたくない」場面は意外と少ないです。アイコンボタンのクリック領域確保のような明確な理由がある場合のみ使い、テキストを含むコンテンツエリアやナビゲーションには使わないのが安全です。

原則2:固定幅(px)より柔軟な単位を優先する

危険な書き方 安全な書き方
width: 200px max-width: 200px + width: 100%
repeat(3, 200px) repeat(3, minmax(140px, 200px))
min-width: 360px min-width: min(360px, 100%)

原則3:複数の固定幅要素の「合計」を常に意識する

今回の根本原因は「左400px + 右648px = 1048px」がコンテナ幅1040pxを超えたことでした。個別のCSS宣言だけを見ていても、この問題には気づけません。レスポンシブ設計では「最も狭い画面幅 × 最も幅を取る要素の組み合わせ」を常に想定してください。

原則4:ブレークポイントの「境界値」をテストする

メディアクエリを max-width: 1200px で設定したなら、1200pxだけでなく1199pxでもテストしてください。境界値こそ最も問題が起きやすいポイントです。

私がレスポンシブチェックで必ず確認する画面幅:

  • 1200px / 1199px(PCとタブレットの境界)
  • 768px / 767px(タブレットとスマホの境界)
  • 480px / 479px(小型スマホ対応)

おまけ:調査時に使えるデバッグCSS

全要素のボックス可視化、はみ出し要素の強制収容、怪しい要素のハイライトの3つのCSSスニペットが原因調査に役立ちます。

原因調査で役立つCSSスニペットを3つ紹介します。

全要素のボックスを可視化:

はみ出し要素を強制的に収める(原因切り分け用):

これで隙間が消えれば、どこかの要素がはみ出していることが確定します。

怪しい要素を目立たせる:

ページ全体に赤い枠線が表示され、はみ出し箇所が目立つ状態

CSSが原因のブラウザトラブルとしては、YouTubeでマウスカーソルが消える問題もありました。拡張機能のCSS注入が原因だったケースを以下で紹介しています。

まとめ:チェックリスト

右側の隙間の原因はほぼ「固定幅要素の合計オーバー」です。overflow-x: hiddenで隠すのではなく、minmax()や%などの柔軟な単位で根本解決してください。

右側の隙間に遭遇したら、以下を確認してください。

  • flex-shrink: 0 が不必要に設定されていないか
  • 固定幅(px)のグリッドカラムがないか
  • min-width が大きすぎないか
  • 複数要素の幅の合計が親を超えていないか
  • ブレークポイントの境界値でテストしたか

overflow-x: hidden で隠すのは最後の手段です。まずは原因を特定し、minmax()%vw などの柔軟な単位で根本解決を目指しましょう。

CSS
この記事を書いた人
rapls

Web開発歴6年超のフリーランスエンジニア。WordPress.orgにプラグインを2本公開中。「自分が3時間ハマった問題を、誰かが3分で解決できるように」がブログの原点。Xserver環境でのトラブルシューティングとAI駆動開発が得意分野です。

raplsをフォローする
raplsをフォローする

コメント

タイトルとURLをコピーしました