この記事の対象: 画面を左右に割るレイアウトを実装する/採用判断に迷っているWebデザイナー・フロントエンドエンジニア
読了時間: 約9分
スプリットレイアウト(画面を左右に分割するレイアウト)は、CSS Gridの数行で組めます。先に答えだけ書きます。
比率は grid-template-columns: minmax(28rem, 1fr) 1fr、折り返しはメディアクエリではなくコンテナクエリの @container (min-width: 60rem)、片側固定は position: sticky + align-items: start。 この3つを押さえれば、実装でつまずく箇所はほぼ消えます。
難しいのは実装ではなく判断のほうです。「なんとなく2分割にしたら情報が入りきらない」「スマホで見たら順番がおかしい」という事故は、左右に何を置くかを決めずに組み始めたときに起きます。この記事では動くCSSを先に出し、そのあとで採用すべき場面・避けるべき場面を切り分けます。
スプリットレイアウトの作り方|コピペできるCSS
まず動くコードです。解説は各ブロックの下にあります。
基本形:画面幅いっぱいを左右に割る
<div class="split-wrap">
<div class="split">
<div class="split__text">
<h2>見出し</h2>
<p>本文テキスト。</p>
</div>
<div class="split__visual">
<img src="/img/hero.jpg" alt="店内の様子">
</div>
</div>
</div>
.split-wrap {
container-type: inline-size;
}
.split {
display: grid;
grid-template-columns: 1fr; /* 既定は縦積み */
min-height: auto;
}
/* 親の幅が 60rem 以上ある時だけ左右に割る */
@container (min-width: 60rem) {
.split {
/* テキスト側に下限を持たせる。ビジュアル側は残りを取る */
grid-template-columns: minmax(28rem, 1fr) 1fr;
min-height: 100svh;
}
}
.split__text {
display: flex;
flex-direction: column;
justify-content: center;
/* 左右の余白は画面幅に追従させる */
padding: clamp(2rem, 5vw, 6rem);
}
.split__visual {
position: relative;
overflow: hidden;
}
.split__visual img {
width: 100%;
height: 100%;
object-fit: cover;
display: block;
}
これで、幅が足りない環境では縦積み、足りれば左右分割になります。高さ指定(100svh)も分割時だけ有効なので、スマホで写真だけ1画面・テキストだけ1画面という間延びが起きません。
対応ブラウザ:コンテナクエリも svh 単位も、主要ブラウザ(Chrome・Safari・Firefox)で広く対応が進んでいます。本番投入前にはCan I Useなど最新の対応状況を一度確認してください。
左右を入れ替える(PCで写真が左、スマホでコピーが先)
@container (min-width: 60rem) {
.split { grid-template-columns: 1fr minmax(28rem, 1fr); }
.split__text { order: 2; } /* PCでは右へ */
.split__visual { order: 1; }
}
HTMLはスマホの読み順(テキストが先)で書いたまま、PCでだけ見た目を入れ替えます。逆向き——HTMLをPCの見た目に合わせて書き、スマホで order を使って直す——はやらないでください。order は視覚的な並びだけを変え、キーボードのフォーカス順とスクリーンリーダーの読み上げ順は変えません。フォーカスが画面を飛び回る作りになります。
片側を固定して、もう片側だけスクロールさせる
.split-sticky {
display: grid;
grid-template-columns: 1fr 1fr;
align-items: start; /* これが無いと sticky が効かない */
}
.split-sticky__pinned {
position: sticky;
top: 0;
height: 100svh;
overflow: hidden;
}
.split-sticky__scroll {
padding-block: clamp(4rem, 10vw, 10rem);
}
@media (prefers-reduced-motion: reduce) {
/* 動きに敏感な人向けに追従をやめる */
.split-sticky__pinned { position: static; height: auto; }
}
position: fixed で組むと、フッターに差しかかったときに固定要素が居座り続けます。sticky なら親要素の範囲内でだけ貼り付きます。
実装でつまずく3か所と、その理由
コードは上で出し切ったので、ここからは「なぜその数値なのか」「動かないときどこを見るか」です。
1. 50:50で固定すると1024〜1280pxで読めなくなる
grid-template-columns: 1fr 1fr は書きやすいのですが、日本語テキストが入ると破綻します。本文は1行あたり35〜45文字を確保したい。1440pxの画面で50:50なら片側720px、余白を引いて600px前後、16pxの本文なら約37文字。ここはぎりぎり成立します。
問題は1024〜1280pxの帯です。片側512〜640pxから余白を引くと400〜540px、25〜33文字まで落ちます。比率を固定していると、この幅で読みづらくなります。
minmax(28rem, 1fr) は「テキスト側は最低448pxを確保し、余裕があれば伸びる」という指定です。画面が縮んでいくと、まずビジュアル側が痩せる。テキストの読みやすさを先に守り、写真は細くなっても object-fit: cover で成立する——この優先順位をCSSに判断させています。
下限値は狙う行長から逆算します。本文16pxで1行38文字なら、16px×38=約608pxが本文幅。そこに内側余白(clamp(2rem, 5vw, 6rem) の狭いとき64px×2)を足して約672px=42rem。今回28remに留めているのは、下限を上げすぎるとビジュアル側が先に潰れて写真として成立しなくなるためです。行長の理想値と写真の最低幅のどちらを優先するかを決めてから数値を置くのが順序になります。
| 画面幅 | 50:50固定 | minmax(28rem, 1fr) |
|---|---|---|
| 1440px | テキスト約37文字 | 約37文字(50:50と同じ) |
| 1280px | 約33文字 | テキスト側が448pxを確保、写真が痩せる |
| 1024px | 約25文字(読みづらい) | 縦積みへ切り替え |
2. 折り返し点は「画面幅」ではなく「入るかどうか」で決める
@media (max-width: 768px) で縦積みに切り替える書き方は、コンポーネントを使い回した瞬間に破綻します。同じスプリット部品を、幅いっぱいのセクションと、内側に余白のあるセクションの両方で使うと、後者だけ早く窮屈になるからです。
コンテナクエリは判断の基準を「画面がどれだけ広いか」から「この部品に与えられた場所がどれだけ広いか」へ移します。サイドバーの中に入れても、フル幅で置いても、同じ部品が正しく振る舞う。
ハマりどころ:container-type: inline-size を .split 自身に付けても効きません。コンテナクエリは祖先のコンテナを参照する仕組みなので、測る対象と問い合わせる要素は別でなければならない。必ず一段外側のラッパーに付けます。ラッパー自体が display: inline だったり幅を持たない状態だと測れないので、ブロック要素として置くことも確認してください。
既定を縦積みにして条件を満たしたときだけ横に割る書き方(モバイルファースト)にしておくのも重要です。コンテナクエリが効かない環境で、最悪でも縦積みのまま内容が読めます。
3. 「stickyを書いたのに動かない」の原因は2つだけ
ひとつは align-items: start の忘れ。Gridの既定値は stretch で、セルの高さが行の高さまで引き伸ばされます。要素が親と同じ高さになるとスクロールしてもはみ出す余地が無く、貼り付く場面が発生しません。
もうひとつは祖先要素のどこかに付いた overflow: hidden。これは見つけにくいので、探し方を書いておきます。開発者ツールのコンソールで、対象要素から親をたどって overflow の計算値を出力すると一発です。
let el = document.querySelector('.split-sticky__pinned');
while (el && el !== document.documentElement) {
const o = getComputedStyle(el).overflow;
if (o !== 'visible') console.log(el, o);
el = el.parentElement;
}
横スクロール対策で入れた overflow-x: hidden が body や共通ラッパーに付いていて、ページ全体のstickyを無効化しているケースがよくあります。overflow-x だけを指定しても overflow-y が auto に変わる仕様なので、「x方向しか触っていないから大丈夫」は成り立ちません。
グリッドの組み方そのもの(grid-template-columns の書き分け、auto-fit の使い分けなど)を一から確認したい場合はこちらにまとめています。
スプリットレイアウトを採用すべきか、3つの問いで決める
コードが短いぶん、判断を飛ばして組み始めがちです。ここを外すと、見た目は今風なのに読みづらいページができあがります。
3つ目が特に重要です。スプリットレイアウトは狭い画面で必ず縦に積み直されます。積んだ状態で意味が通らない構成は、スマホで見た人の全員にとって失敗になります。
判断を早めるための具体的な3つのチェック
- 右側に置くものを言葉で書けるか:「ブランドの空気を伝える外観写真」のように役割を一文で書けなければ、その右側はまだ飾りです
- 左右を入れ替えても意味が通るか:通ってしまうなら位置に意味が乗っていません。対比ではなく単なる並置です
- 縦積みにしたときの順序が決まっているか:どちらが先かを決められない構成は、スマホで必ず迷子になります
この3つを通過した案件だけ実装に進んでください。通過しないまま組むと、比率と折り返し点の調整を延々と繰り返すことになります。
機能する4パターン
スプリットレイアウトが生き残っているのは、装飾として綺麗だからではありません。2つのものを同時に見せて比べさせるという、他のレイアウトが苦手な仕事ができるからです。
- ビジュアルとコピーの対比:写真の情報量とテキストの静けさを隣に置く
- 選択肢の提示:法人向け/個人向け、注文する/来店する、といった二択
- ビフォー・アフター:施工前後、導入前後
- ブランドの二面性:製造とデザイン、オンラインと店舗
逆に、並べるものが1つしかないときに使うと崩れます。左に見出しとボタン、右に「なんとなく置いた画像」という構成は、右側が意味を持っていないので、ただ本文が半分の幅に押し込められただけの状態になります。
「2カラム」との違い
用語が混ざりやすいので線を引いておきます。
| スプリットレイアウト | 一般的な2カラム | |
|---|---|---|
| 分割の位置 | 画面幅いっぱいを割る(多くは50:50) | コンテンツ幅の内側で割る |
| 左右の関係 | 対等、または意図的な対比 | 主(本文)と従(サイドバー) |
| 背景 | 左右で色・画像が変わることが多い | 共通の背景 |
| 高さ | ビューポート基準(100svh など) |
コンテンツ量に依存 |
2カラムは主従があります。スプリットは左右が対等、もしくは対等に見せることが目的です。だから背景色を左右で変えるし、画面の端まで到達させる。この違いを押さえておくと、「どっちで組むか」の議論が短く済みます。
Soreiine!!掲載サイトに見るスプリットレイアウトの型
ギャラリーには画面分割を軸に組まれたサイトがいくつも掲載されています。構成の型として学べるものを3つ取り上げます。
左を固定し、右だけスクロールさせる型
飲食・宿泊系のサイトでよく見かける構成です。左半分にブランドのキービジュアルを固定し、右半分でコンテンツを流していきます。
見どころは、左側が「ずっと見えているブランドの顔」として働き続ける点です。右側で情報を読み進めている間、左側は退場しません。スクロールしても店の空気が消えない。通常のページで同じことをやろうとすると追従ヘッダーを厚くするくらいしか手がなく、その方法は読む面積を削ってしまいます。
注意したいのは右側のコンテンツ量です。右が画面の半分しかない以上、1行あたりの文字数が減ります。長文を流すと行数が膨らみ、スクロール量が体感で倍近くになる。具体的には、右側1ブロックあたり「見出し1行+本文3〜5行+画像1点」に収め、ブロック間は画面高の3割程度を空ける。これで左の固定ビジュアルが切り替わらなくても、読み手は「進んでいる」感覚を保てます。
逆に右側へ表や長い箇条書きを入れると、幅が足りず折り返しが増え、固定された左側が「動かない壁」として邪魔に見え始めます。
対角線で割って、動きを出す型
真っ二つの垂直分割ではなく、斜めのラインで割るパターンもギャラリーで見つかります。ブランドの印象を「静か」から「動き」に振りたいときの手です。
この型の良さは、分割線そのものがデザイン要素になること。垂直分割は整然としますが、裏を返せば没個性になりやすい。斜めに割ると、それだけでレイアウトに固有性が生まれます。
実際に効いているサイトを見ると、斜めの角度は浅めです。緩やかに傾けて、分割線を「動きの気配」に留めている。角度を強く付けるほど三角形の鋭角部分が広がり、文字も画像も置けない死に領域が増えます。斜め分割を検討するときは、角度を決める前に「一番狭くなる側に何を置くか」を決めておくと失敗しません。
実装では clip-path で斜めに切ると、切られた側のテキストが領域外に出てしまう事故が起きます。文字は分割形状の内側にさらに余白を取った安全域に置く、という設計上の約束が要ります。
分割をコンテンツの構造そのものにしている型
ファーストビューだけでなく、ページ全体を通して左右の意味を保ち続けている例もあります。左が常に「what(何を)」、右が常に「how(どうやって)」といった具合に、位置に意味を持たせる作り方です。
これはユーザーが位置を学習するので、読み進めるほど速く理解できるようになります。設計としては最も難度が高い代わりに、模倣されにくい構成でもあります。
成立させる条件は1つで、最後まで例外を作らないことです。途中で1か所だけ左右の役割を入れ替えると、そこで学習が壊れ、以降は両側を読み直すことになります。役割から外れるセクションが出てきたら、無理に分割へ押し込まず、幅いっぱいの帯に切り替えて「ここは別の話です」と見せたほうが読み手に親切です。
ギャラリーを眺めるときは、単に「分割されているか」ではなく、左右にどんな役割分担が与えられているかを見てください。そこがそのサイトの設計思想です。
スマホで壊れる3つの原因と対処
積み直したときの「順番」を設計に含める
PCで左右に並んでいたものは、狭い画面ではどちらかが上に来ます。問題になるのは、HTMLの並び順とデザインの意図がズレているケースです。
よくあるのは「PCでは右にコピー、左に写真」というデザイン。素直にHTMLを書くと、スマホでは写真が先、コピーが後になる。ファーストビューで写真だけが画面を埋め、何のサイトか分からないまま終わります。対処は前述の order による入れ替えです。HTMLは意味の順、CSSで見た目だけ入れ替える。
分割の高さを揃えようとしない
PC版で左右の高さがぴたりと揃っている美しさを、狭い画面まで持ち込む必要はありません。縦積みになった時点で「揃える」という概念自体が消えます。100svh を縦積み時にも残していると、写真だけで1画面、テキストだけで1画面という間延びしたページになります。
縦積みで解除するもの
- ビューポート基準の高さ
- sticky の追従
- 左右で変えていた背景色の境界
縦積みでも維持するもの
- HTMLの意味の順序
- テキストの行長の下限
- 見出しと本文の階層
左の列を解除し、右の列は分割時と同じ扱いを保つ。この線引きがスマホでの完成度を決めます。
背景の塗り分けは縦積みで意味が変わる
PCで左右を色で塗り分けていた場合、縦積みにすると上下の帯に変わります。垂直の境界線は「対等な2つ」を表しますが、水平の境界は「上から下への進行」に読めます。同じ配色でも伝わる関係が変わってしまう。
.split__text { background: #fff; }
.split__visual { background: #111; }
/* 縦積みのときは塗り分けをやめる */
@container (max-width: 59.99rem) {
.split__visual { background: transparent; }
}
あわせて、分割時にだけ意味を持っていた装飾——中央の縦罫線、左右にまたがる斜めの切り欠き、境界をまたぐ図形——も解除の対象です。縦積みになると位置の根拠を失って浮きます。
採用しないほうがいい場面
トレンドとして紹介される機会が多いぶん、向かない場面で使われがちです。
| 場面 | 理由 | 代わりの選択 |
|---|---|---|
| 情報量の多い一覧ページ | 幅が半分になり、カードが縦に伸びる | グリッド配置 |
| 長文の記事・コラム | 1行の文字数が足りず、行数だけ増える | 1カラム+読みやすい行長 |
| 3つ以上の選択肢を見せたい | 2分割に3つは入らない | 3カラムまたはカード |
| 更新頻度の高いセクション | 左右のバランスを毎回調整することになる | 定型のブロック |
| ビジュアル素材が用意できない | 片側が空洞になる | テキスト主体のレイアウト |
| フォームを含むセクション | 入力欄が狭まり、エラー表示の行が増える | 単独のフォーム画面 |
3つ以上を並べる判断については、カラム数の選び方をまとめた記事があります。
素材が無いまま採用しない
いちばん多い失敗がビジュアル素材の行です。スプリットレイアウトは片側にビジュアルを置く前提の型なので、写真が用意できない案件でこれを選ぶと、制作の後半で必ず詰まります。
カンプの段階ではストックフォトで綺麗に見えます。ところが実際の入稿写真が縦横比の合わないものや解像度の低いものだと、object-fit: cover で無理に埋めることになり、被写体が切れます。採用を決める前に次を確認してください。
- 使える写真が横位置で用意できるか(縦位置しか無いと
coverで大きく切られる) - 短辺で2000px以上あるか(画面半分でも大きく表示される)
- 継続的に差し替えられるか(撮影が一度きりなら、時間が経つと古びる)
素材の見通しが立たない場合は、スプリットにせず幅いっぱいの帯や余白の効いた1カラムで組むほうが結果的に長持ちします。工程の考え方についてはホームページ制作の期間と短縮法|急ぎで縮められる工程・縮められない工程【2026年】も参考になります。
運用に乗るかどうかも先に見る
見落とされがちなのが公開後です。スプリットレイアウトは左右の分量バランスで成立しているので、片側だけ文章が増えると崩れます。CMSで運用するセクションに採用するなら、更新する人が何をどこまで変えられるかを決めておく必要があります。
具体的には、テキスト側に文字数の上限目安を添える、画像は指定した比率でしか入らないようトリミングの仕組みを用意する、といった手当てです。これを省くと、公開から数か月で「PCだと左右の高さが合っていない」という指摘が返ってきます。分割は美しい代わりに、崩れたときも目立つ型だと考えてください。
実装後に確認する6項目
組み終えたら次の順で見てください。ブラウザの開発者ツールだけで全部できます。
- 1024pxで確認する:分割を維持したまま最も窮屈になる幅。ここで読めれば大抵は大丈夫です
- 375pxで確認する:縦積みの順序と、高さ指定が解除されているか
- 文字サイズを200%にする:ブラウザのズームではなくフォントサイズ設定を変える。テキスト側が溢れないか
- Tabキーで移動する:
orderを使った箇所でフォーカスが飛ばないか - 画像を差し替えてみる:縦位置の写真を入れて、切れ方が許容範囲か
- テキストを1.5倍に増やしてみる:実運用で文章が伸びたときに、
sticky側と高さが合わなくなる箇所を先に見つける
4番目を飛ばす現場が多いのですが、order を入れたページでは必ず通してください。目で見て分からない部分だけに、後から発覚すると修正範囲が広がります。
よくある質問
スプリットレイアウトの分割比率は50:50以外でもいいですか?
問題ありません。テキスト側を広めに取る60:40や、ビジュアルを主役にする40:60はよく使われます。固定値で書くより minmax() でテキスト側に下限を与えるほうが、1024〜1280pxの中間幅で破綻しません。
スマホでは何pxで縦積みにすべきですか?
画面幅ではなく、部品に与えられた幅で判断するのが確実です。コンテナクエリで min-width: 60rem 前後を目安にし、テキスト側が28rem(448px)を割り込む前に縦積みへ切り替えます。同じ部品を別の場所で使い回しても壊れません。
position: sticky を書いたのに固定されません。原因は何ですか?
ほぼ2つです。Gridで align-items: start を指定していない(既定の stretch だと要素が親と同じ高さになり、貼り付く余地が消える)か、祖先要素のどこかに overflow: hidden が付いている。後者は横スクロール対策の overflow-x: hidden が原因になりやすく、本文中のJSスニペットで親をたどれば特定できます。
左側を固定するスクロールはSEOに影響しますか?
position: sticky はCSSの表示指定なので、HTMLの内容がクローラーから見えなくなることはありません。注意すべきはページの読み込み速度と、追従部分に大きな画像を置いたときの表示負荷のほうです。
スプリットレイアウトは2026年でも古くないですか?
装飾のトレンドではなく、2つの要素を対比させるための構造なので、目的に合っていれば古びません。避けたいのは「今風だから」という理由で、対比する中身が無いまま使うこと。左右に別々の意味を持たせられるかどうかで判断してください。
まとめ
スプリットレイアウトで決めることを、順に並べ直します。
- 分割比率は50:50固定にせず、テキスト側に
minmax(28rem, 1fr)で下限を与える - 折り返し点はメディアクエリではなくコンテナクエリで、部品の幅を基準にする
- 片側固定は
position: sticky+align-items: start。fixedは使わない - HTMLの順序はスマホの読み順で書き、PCで
orderを入れ替える - 採用の可否は「左右に対等な意味があるか」「縦積みでも通じるか」で決める
- 素材の見通しが立たない案件では、そもそも採用しない
コードそのものは短い型です。時間を使うべきなのは、左右に何を置くかを決める前半の設計。ここが決まっていれば実装で迷う場面はほとんどありません。決まっていないまま組み始めると、比率と折り返し点を延々と触ることになります。
ギャラリーのサイトを見るときも、分割の見た目ではなく役割分担に注目してみてください。うまくいっているサイトは、左右のどちらにも理由があります。
