始める前に
- 表示の確認にはChromeと対象URL。CSSの修正演習には編集できる隔離環境
- 崩れるURL、幅・高さ、期待する列数の記録
- 変更前のソースと戻す方法
用語が分からないとき
- 照合
- 二つの記録を見比べ、同じ対象・時刻・内容かを確かめることです。
- 未確認
- まだ調べていない、または判断に必要な結果を得られていない状態です。「問題なし」とは分けて記録します。
表示を確認する運営担当の方へ
CSSを編集できなくても、崩れた条件と読者ができなくなった操作は記録できます。下のCSS修正は、隔離環境を扱える実装担当へ引き継ぎます。
設定を変えずに確認すること
- 対象URL、画面の幅と高さ、拡大率、端末とブラウザを記録する。同じ条件で、どの本文・表・入力欄が崩れるかを確認する。
- 期待する表示と実際の表示を並べる。「390pxで本文が2列のまま」「送信ボタンが画面外にある」のように、場所と困る操作を具体的に残す。
この手順で使う用語
- 画面幅と拡大率
- 比較する条件。幅を変えた結果と、拡大した結果は分けて記録します。
- CSSの指定
- 列数やサイズなどの表示を決めるルール。同じ要素に複数の指定があるとき、どれが採用されたかを実装担当が調べます。
- DevToolsでの変更
- その場の調査用の変更。ソースを修正して配信し直したことにはなりません。
実装担当へ渡す情報
対象URL、再現する幅・拡大率・ブラウザ、期待する列数、実際に崩れた領域、困る操作を渡します。修正後は同じ条件と別の幅で確認し、本文・表・フォームが使えるかを運営側でも照合してください。
確認済みと未確認の境界
原因のCSSを特定できなければ、表示の再現だけ確認済みとします。スマホ幅の模擬画面だけを見た場合は、実機で確認したとは記録しません。
調べる前に、幅と崩れた領域を揃える
CSSを編集できるサイトで、対象URL、Chrome、画面の幅と高さ、拡大率、期待する列数を記録します。この例は390×844px、拡大率100%で比較しています。まず本文が潰れた領域を選んでください。違う画面幅で比べると、修正の効果と条件の違いを区別できません。
検証は自分が管理するページの隔離環境で行います。DevTools内の変更は調査用で、ソースを修正したことにはなりません。ここに掲載した画像は現在のHTMLに履歴のCSSを適用した再現であり、過去の本番画面を保存したものではありません。
見た目を左右したのは、クラス二つの指定だった
問題のページにはstatic-page-shellとhas-asideの二つのクラスが付いていました。通常幅では260pxのサイドバーと残り幅の本文を並べるため、.static-page-shell.has-asideで2列を指定していました。一方、900px以下の上書きは.static-page-shellだけで1列を指定していました。
この二つの指定は詳細度（セレクタの重み）が違います。出所・重要度・カスケードレイヤーの条件が同じルールを比べた場合、クラス二つの0-2-0が、クラス一つの0-1-0より強くなります。メディアクエリ内に書いたこと自体は、この差を逆転させません。スマホ用指定が後にあっても、2列の指定が残る条件でした。
.static-page-shell.has-aside {
grid-template-columns: 260px minmax(0, 1fr);
}
/* 修正：スマホ側にも二つのクラスを指定 */
@media (max-width: 900px) {
.static-page-shell.has-aside {
grid-template-columns: 1fr;
}
}390pxで再現し、幅を測る
10月6日のローカル再現では、過去のCSSでグリッドの列幅が260pxと48pxになり、ページが画面幅を30px超えました。これは当時の記録にあった「スマホでもサイドバー列が残る」という説明と一致します。フォームの見かけだけでなく、グリッドの計算値を測ることで原因を絞れます。
修正後のCSSでは列幅が342pxの1列となり、横方向のはみ出しは0pxでした。フォーム幅は248pxで、残りは本文領域の余白です。今回は2026年10月6日時点のHTMLに過去のCSSを適用した比較です。当時の本番画面と画素単位で同じ表示ではありません。実機ではOS、フォント、ブラウザの文字拡大によっても折り返しが変わります。
10月6日のローカル再現結果
値はこのページと環境の測定結果です。スマホ全機種の表示を保証する数値ではありません。
| 測定項目 | 過去のCSS | 修正後のCSS |
|---|---|---|
| グリッド列幅 | 260px + 48px | 342px（1列） |
| ページのはみ出し | 30px | 0px |
| 確認条件 | Chrome / 390 × 844 | 同じHTML・同じ幅 |
開発者ツールで、消えていない指定を探す
Chromeの対象ページで開発者ツールを開き、デバイスモードで幅390px・高さ844pxを指定します。要素選択で潰れた本文を選び、Elementsの親要素を辿ってstatic-page-shellとhas-asideが付いたグリッドへ移動します。本文の文字のスタイルだけを見ると、列幅を決める指定を見落とします。
Stylesの絞り込みにgrid-template-columnsを入力します。打ち消されている1frと、採用されている260px minmax(0, 1fr)を比べ、セレクタと適用幅を確認します。Computedで同じプロパティを探すと、計算後の列幅を確認できます。表示名や配置はDevToolsの版で変わるため、プロパティ名を手がかりにします。
採用されている2列の宣言をDevToolsで一時的に無効化し、一列に戻るか確認します。戻れば、その宣言が関わっていると判断できます。戻らなければ、子要素の固定幅・min-width・別のグリッド等を確認し、詳細度だけが原因と決めつけません。
今回は出所・重要度・カスケードレイヤーの条件が同じため、スマホ側も二つのクラスを指定して詳細度を揃えました。!importantを追加する前に、出所・レイヤー・重要度・詳細度・記述順を確認します。DevToolsの変更をソースへ反映し、再読み込み後にも一列になることを確かめます。
修正したページだけで終えない
同じstatic-page-shellを使う固定ページにも影響が出るため、問い合わせ、運営情報、編集方針、規約を両方の幅で確認します。目次、長いURL、表、入力欄は、本文が収まっていても単独ではみ出す場合があります。横幅の確認には下の式が使えますが、横スクロールを意図した表まで禁止するものではありません。
画面の確認では入力、エラー表示、キーボード移動まで通します。自動点検は幅・コントラスト・リンクなどの検出に使い、文字の読みやすさと操作の流れは画面でも見ます。最初に不具合を見つけた幅だけでなく、390pxと1280px、さらに境界付近の幅で点検すると、上書きの漏れを見つけやすくなります。
document.documentElement.scrollWidth
- document.documentElement.clientWidth
// ページ全体のはみ出しがなければ0。表の内部スクロールは別に確認。完了の記録は、直した条件と残る確認を並べる
390pxで本文が読めるかに加え、900pxの境界付近と1280pxでも期待する列数を確認します。長いURL、表、入力エラーを表示し、ページ全体が押し広げられないかを見ます。表の中だけで横スクロールする状態は、ページ全体のはみ出しと分けて記録してください。
キーボードでリンクとフォームへ移動できること、200%の拡大でも操作できることも確認します。 ブラウザのズームとDevToolsの端末表示の縮尺は別に記録し、プレビューを大きくしただけで200%ズームの操作確認にはしません。デバイスモードでの結果を実機確認と記録しないでください。実機を確認していない場合はその範囲を残し、修正箇所・幅・結果・未確認事項を次の担当者へ渡します。
対象URL／OS・ブラウザの版:
確認日時／表示を確認した担当:
画面幅・高さ／拡大率:
期待する表示と、困っている操作:
採用されていたCSS／修正した担当と指定（未調査なら未確認）:
390px・境界付近・1280pxの結果:
長い文字列／フォームエラー／キーボード／200%拡大:
実機の確認状況／未確認事項:
次の作業と再現・再確認の条件:
確認する担当／確認予定日:完了の確認
- 採用されたCSSと修正理由を、その版のソース・幅・計算値で説明できる
- 再読み込み後、狭い幅・境界付近・広い幅で期待する列数と本文・表の表示を確認する
- フォームエラー・長い文字列・拡大・キーボードの結果を残し、DevToolsの模擬幅を実機確認に含めない
確認できなかった項目は、未確認として次の作業に残してください。