レスポンシブデザインの作り方｜設計・CSS実装・WordPress・検証の手順

「スマホで開ける」と「スマホでも必要な情報を読めて、迷わず操作できる」は別の状態です。パソコンの画面を小さく表示するだけでは、料金表の文字が読めなかったり、メニューの項目が重なったりします。レスポンシブデザインでは、画面に応じて配置や余白を変えながら、情報の意味と操作を保ちます。

この記事は、自社サイトを改修する担当者と、実装を始める制作者に向けたガイドです。設計、CSS、画像・表、操作、WordPress、納品時の確認を順に説明します。Google、MDN、W3C、WordPress、GOV.UKの公開資料を参照し、独自の例は説明用の想定例として区別しています。資料の確認日は2026年9月11日です。

レスポンシブデザインで実現することを決める

同じ内容を、画面に合う配置で届ける

レスポンシブデザインは、閲覧領域に応じてレイアウトを柔軟に調整する考え方です。たとえばパソコンでは横に並ぶ三つのサービスを、スマホでは縦に並べます。見出し、説明、申込条件は残し、並べ方を変えます。単純な縮小との違いは、文字や操作部品を読める・扱える状態に保つ点にあります。

対象はスマホとパソコンの二種類だけではありません。タブレット、画面の横向き、パソコンの分割表示、文字を拡大したブラウザーもあります。機種名ごとに完成画面を増やすより、内容が収まる条件を決める方が管理しやすくなります。社内の確認用スマホ一台で崩れていないことを、すべての条件に対応した証拠にはできません。

最初に成果物を具体化しましょう。「スマホ対応」だけでは、トップだけ直すのか、記事、料金表、問い合わせフォームまで含むのか分かりません。対象ページ、共通部品、使えるべき機能、確認するブラウザーを一覧にします。これがデザイン案と実装後の状態を比較する基準になります。

検索向けにも主要な情報をそろえる

Googleのモバイルファーストインデックスの説明では、主にモバイル版の内容をインデックスとランキングに利用し、実装・保守の容易さからレスポンシブ方式を推奨しています。同じURL・同じHTMLを利用する方式のほか、端末によってHTMLを変える方式や別URLを使う方式も説明されています。

スマホだけサービスの条件や実績の説明を削ると、読者が判断できる情報も減ります。一方、情報を折りたたんで整理することと、クリックするまで主要な内容を読み込まないことは同じではありません。Googleは主要コンテンツの読み込みをユーザー操作に依存させないよう案内しています。制作会社には、見た目だけでなく読み込み方も確認してもらいます。

対応方式を変えるだけで検索順位が上がるとは限りません。内容の適切さ、検索意図、リンク、サイトの状態なども関わります。まずは端末によって説明や申込先が欠けないことを確かめ、その後に検索経由の訪問や相談の推移を見ます。

表示・操作・速さを別々に確認する

表示は読めるか、操作は目的地へ進めるか、速さは表示や反応をどれほど待つか、という違いがあります。幅が収まっていてもメニューを閉じられなければ操作上の問題です。画像が画面内に収まっていても大きなファイルを転送していれば、表示速度の調査が必要になります。

説明用の想定例として、地域の設備会社のサイトを考えます。スマホで会社案内は読めても、対応地域の表が切れ、相談ボタンが追従バナーに隠れているなら、全ページの作り直しを決める前に表と重なりを調べます。問題を分けることで、見積もりにも修正対象と確認方法を記載できます。

デザインの前に、情報と読む順番を整理する

利用者が判断する順番を原稿にする

最初から二列か三列かを決めず、利用者が何を知る必要があるかを書き出します。サービスページなら、誰向けか、何を頼めるか、対応地域、費用の条件、実績、相談方法が候補です。全部を同じ強さで見せるのではなく、検討段階に応じた順序を考えます。

原稿を一列に並べて読むと、説明の抜けや繰り返しを見つけやすくなります。料金を示す前提が後ろの注意書きにしかなければ、料金の近くへ移します。相談ボタンの前に必要な条件がそろっているかも確認します。スマホで縦に並べた結果、重要な前提が何画面も離れる設計を避けるためです。

仮の短い文章だけでデザインを確定しないことも大切です。正式な会社名、長いサービス名、実際の説明文を入れ、写真の縦横比も近づけます。文章が増えたときにカードの高さが伸びるのか、隣とそろえるのか、ボタンはどこへ来るのかまで決めておくと、原稿確定後の手戻りを減らせます。

公開されている設計例から考え方を学ぶ

具体的な公開例として、英国政府のGOV.UK Design Systemのレイアウト方針があります。小さな画面から考えて一列を基本とし、広い画面では内容に応じて列を使い分ける構成が示されています。単に空いている横幅を埋めるのでなく、読みやすさを理由に本文の幅を制限する点が参考になります。

これは公開された設計方針の例であり、日本の企業サイトで同じ配置にすれば問い合わせが増えるという実証ではありません。また、英語の一行の文字数を日本語へそのまま当てはめることもできません。自社の文章と書体で、視線を次の行へ移しやすいか、見出しと段落の区別がつくかを確認します。

応用するなら、会社紹介の長文は幅を抑え、補足リンクは広い画面で横へ置き、狭い画面では本文の後ろへ移す、といった考え方になります。主情報と補足情報の関係が保たれているかが判断の中心です。流行のレイアウトを採用する前に、なぜその配置が必要かを説明できる状態にします。

配置が変わる場面をデザイン資料に残す

パソコン版とスマホ版の完成図だけでは、途中の幅でどう変化するかが未定のままです。カードが折り返す条件、ナビゲーションがメニューに切り替わる条件、見出しの改行、写真の切り抜き位置を補足します。固定のピクセル値をすべて決める必要はありませんが、守るべき関係は共有します。

たとえば「料金と注意事項は離さない」「人物の顔は切らない」「相談ボタンは説明より先に読まれない」を仕様にできます。見出しを装飾のために画像へ埋め込む場合も、縮小時の可読性とテキストの代替方法を考えます。変更できる余白と、変更してはいけない情報の関係を分けると、制作者が途中の幅を調整しやすくなります。

CSSは柔軟な幅を基本にし、必要な位置で切り替える

viewportと通常の文書構造を確認する

実装では、まずHTMLのheadにviewport設定があるか確認します。一般的な出発点は次の指定です。すでにテーマが出力している場合は重複追加せず、現在の指定を調べます。拡大を妨げる設定を入れて、見た目の崩れを隠す方法は避けます。

<meta name="viewport" content="width=device-width, initial-scale=1">

次に、見出し、段落、一覧、リンクを意味に沿うHTMLの順序で組みます。最初から要素を絶対配置して完成画像に合わせると、文章が折り返した際に重なりやすくなります。通常の文書の流れを基本に、横並びが必要な部分へGridやFlexboxを使う方が、原稿が増えたときの動きを追いやすくなります。

MDNのレスポンシブデザイン教材では、柔軟なレイアウトとメディアクエリーなどを組み合わせる方法を説明しています。メディアクエリーは有用ですが、レスポンシブな配置すべてに必須というわけではありません。伸縮や折り返しで対応できる箇所まで、機種別の条件を増やす必要はありません。

小さなコードで部品の動きを確認する

次は、説明用に作成したカード一覧のCSSです。クラスを付けた一覧の直下にカードを置く想定で、狭い幅では一列、幅に余裕ができたら二列になります。48remはこの例の切り替え値であり、すべてのサイトに推奨する値ではありません。既存サイトへ貼る前に、同じクラス名や親要素の指定との干渉を確認してください。

.service-cards {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  gap: 1.5rem;
}
.service-cards > * {
  min-width: 0;
  overflow-wrap: anywhere;
}
.service-cards img {
  max-width: 100%;
  height: auto;
}
@media (min-width: 48rem) {
  .service-cards {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

カードの高さは固定せず、内容に合わせて伸びる構成です。長いURLなどで列が押し広げられないよう、縮められる幅と折り返しを指定しています。ただし、この例にメニューや入力フォームの動作は含みません。コードが動くことと、サイト全体が使えることは別に確認します。

ブレークポイントは内容が窮屈になる位置で決める

切り替え幅は、端末名から機械的に決めるのでなく、実際の内容で調整します。幅をゆっくり変え、ナビゲーションが折り返す、カードの文章が極端に縦長になる、ボタン同士が接近するといった地点を探します。切り替えの直前と直後も確認し、どちらか一方だけで生じる重なりを見逃さないようにします。

修正のたびに条件や!importantを追加すると、どの指定が効いているか分かりにくくなります。先に親の幅、子の最小幅、余白、固定高さを調べ、原因になっている指定を直します。pxという単位自体を禁止する必要はありません。固定値が必要な部分と、文章や画面に合わせて伸びるべき部分を分けて使います。

画像・表・文章を、小さな画面でも読める形にする

画像の表示サイズと配信サイズを分けて考える

CSSで画像を画面幅に収めても、元の大きなファイルが転送される場合があります。配置の調整とデータ量の調整を分けて確認しましょう。MDNのレスポンシブ画像の解説では、srcsetやsizesによる候補画像の指定と、pictureによる構図の切り替えを区別しています。

同じ写真を適した解像度で届けたいのか、スマホでは人物を大きく写した別の切り抜きにしたいのかで方法が変わります。幅を変えながら、顔、商品、看板など説明に必要な部分が切れていないかを確認します。WordPressが候補画像を出力する場合も、独自テンプレートや背景画像で同じ仕組みが使われているとは限りません。

図解は縮小しても全体の関係を読めるようにし、細部を見るための拡大リンクも用意します。意味は本文でも説明し、画像を開かなければ結論が分からない状態を避けます。転送量や読み込み順の調査は、WordPressの表示速度改善ガイドで詳しく扱っています。

比較表は関係を保って横に読めるようにする

料金表をそのまま縮小すると、行と列は残っていても文字が読めなくなります。項目が少なければ縦の説明へ整理し、列同士の比較が必要なら表の領域だけ横に動かす方法を検討します。表の前に要点を書き、「横にスクロールできます」と伝えると、続きの存在が分かります。

W3Cのリフローの解説は、縦に読むコンテンツについて幅320 CSSピクセル相当で情報や機能を失わずに表示する条件を説明しています。一方、意味のために二次元の配置が必要な表や図などには例外があります。表の例外が、周囲の本文まで横へはみ出してよいという意味ではありません。

表には行・列の見出しを付け、キーボードでも必要な範囲を読めるか確認します。一つのセルに長文を詰め込まず、共通条件は表の近くの文章へ移す方法もあります。スマホ版だけ注意事項を消して表を短くするのではなく、比較に必要な内容を維持したまま表示方法を選びます。

文字の拡大と更新後の文章量を試す

通常表示が整っていても、拡大すると固定高さの枠から文字が切れることがあります。ブラウザーの拡大、長い見出し、箇条書きの追加を試し、段落やボタンが重ならないかを見ます。狭い幅を一度確認しただけで、アクセシビリティ基準全体に適合したとは判断できません。

日本語の見出しは、どの幅でも同じ位置で強制改行するより、意味のまとまりと自然な折り返しを両立させます。「お問い合わせ」の最後の一文字だけが残る場合、書体を小さくする前に余白、行の幅、改行指定を確認します。補足が読めなくなるほど文字を縮めて、完成図の高さを守る必要はありません。

運用担当者が写真を差し替える、事例名が長くなる、料金条件が増えるといった変化も検証対象です。完成時の文章だけでなく、想定する最長の見出しと複数段落を入れて確認します。どこまで編集してよいかをCMSの説明へ残すと、公開後にも同じ設計を保ちやすくなります。

メニューとフォームは、見た目と操作を一緒に設計する

押せる範囲と周囲の間隔を確認する

アイコンが見える大きさと、実際に押せる範囲は一致しないことがあります。メニュー、閉じるボタン、ページ送り、同意欄などは、文字や図形だけでなく反応する領域を確認します。近くに別の操作がある場合は、押し間違えにくい間隔も必要です。

WCAG 2.2のターゲットサイズの解説では、レベルAAの達成基準2.5.8として24×24 CSSピクセル以上という条件と、間隔、同等の操作、文章中のリンクなどの例外が説明されています。すべてのリンクを一律に同じ寸法にする基準ではありません。WebのCSSピクセルと、別の設計指針で使われるptやdpを混同しないようにします。

最低条件を満たす寸法が、利用者にとって最も押しやすい寸法とは限りません。主要な相談ボタンには内容に応じた余裕を持たせ、横に並ぶ副操作との関係を実際に試します。余白を増やした結果、別の要素へ重なっていないか、画面下部を隠しすぎていないかも確認します。

画面の並びとフォーカスの移動を照合する

パソコンで横並びの項目をスマホで並べ替えるとき、CSS上の見た目だけが変わり、キーボードで移動する順番が飛び飛びになる場合があります。Tabキーで移動し、現在地が見え、意味の通る順番で進めるか確認します。W3Cのフォーカス順序の解説は、意味と操作性を保つ順序を求めています。視覚上の順番と常に完全一致することだけが条件ではありません。

開閉メニューでは、開いたことが分かるか、項目を選べるか、閉じて元の操作へ戻れるかを一続きで試します。閉じたメニューの見えないリンクへ移動したり、背後の本文へ意図せず操作が移ったりしないかも確認します。アイコンの形を整えるだけでは、この動作の確認を代替できません。

表示順の都合で同じ内容を二重に置く場合は、読み上げやキーボードから両方へ到達して混乱しないか調べます。可能なら、同じ文書構造を使った配置調整で解決します。どの操作方法でも情報と役割が伝わる設計については、中小企業のWebアクセシビリティの解説も参照してください。

入力開始からエラー・完了まで確認する

フォームは空の状態の見た目だけで判断しません。入力中のキーボードで項目が隠れないか、エラーが表示されても入力内容を見直せるか、確認画面から戻れるかを試します。ラベルや補足説明は入力後も分かるようにし、どの項目の問題なのかを示します。

想定例として、スマホで相談内容を入力すると追従ボタンが送信欄に重なるケースがあります。この場合はフォームの文字サイズだけを調整しても原因は残ります。キーボード表示中の高さ、追従要素の位置、スクロールできる範囲を記録して制作者へ渡します。送信テストは関係者に分かる内容と宛先で行い、受付側の確認も含めます。

すでに公開しているLPの操作上の問題を先に点検したい場合は、スマホLPの改善手順で再現条件と修正の優先順位を整理できます。本記事の設計手順と組み合わせ、問題の発生箇所に応じて使い分けてください。

WordPressは、テーマ・本文・追加機能の担当範囲を調べる

どこが表示を決めているかを特定する

WordPressでは、共通のヘッダーはテーマ、記事の表は本文のブロック、予約欄はプラグインが出力していることがあります。同じページでも変更元が異なります。崩れた箇所へ追加CSSを重ねる前に、出力元、適用されているCSS、他ページとの共通性を確認します。

全記事で同じ見出しが崩れるなら共通スタイル、特定の記事だけなら本文内の指定が候補になります。もちろん原因は一つとは限りません。修正票には対象URLと部品名、現在の状態、望ましい状態を書き、どの層を変更したかも記録します。後からテーマやプラグインを更新するときの確認材料になります。

古い記事内に専用のstyleやscriptが埋め込まれている場合、現在のテーマの目次や図解の仕組みと重複することがあります。削除前に必要な機能を洗い出し、共通機能で置き換えられることを確認します。見た目の古い部分をまとめて消して、説明やリンクまで失わないようにします。

テーマの直接編集と子テーマの使い分けを決める

配布テーマを直接編集すると、更新時に変更が失われる可能性があります。WordPressの子テーマの公式資料は、親テーマを継承しながら変更する仕組みを説明しています。ただし、子テーマを作れば親のファイルを何でもコピーしてよいわけではありません。functions.phpは親を置き換えるものではなく、親の関数を丸ごとコピーすると重複でエラーを起こし得ます。

既存のオリジナルテーマ、ブロックテーマ、制作会社の管理下にあるテーマでは、保守の方法が異なります。現在の構成に合う変更場所を確認し、CSSがどの順で読み込まれるかも調べます。追加CSSの行数だけを基準に、自分で直すか外注するかを決めることはできません。

テーマを変更するなら、デモ画面だけでなく実際の原稿、画像、表、フォームを入れた検証環境で試します。デモの速度スコアや最終更新日だけでは、既存サイトとの互換性や運用のしやすさは判断できません。失われる独自部品や設定がないか、変更前の状態へ戻せるかまで見積もりに含めます。

編集者が更新しても保てる形で引き継ぐ

公開後に毎回コードを直さなければならない設計では、更新が滞りやすくなります。写真、料金、事例、よくある質問など、頻繁に変わる情報は編集場所を分かるようにします。見出しの装飾は共通のスタイルへまとめ、記事ごとに異なるコードを貼る運用を減らします。

引き継ぎ資料には、写真の推奨比率、見出しの使い方、表の追加方法、プレビューで見る箇所を記載します。長文を入れた場合や項目を一つ追加した場合も実際に試してもらいます。編集権限があることと、崩さずに更新できることは別なので、操作説明だけでなく更新後の表示確認までを受け渡しに含めます。

実装後の検証と、制作会社へ渡す依頼内容をまとめる

画面幅の検証と実機での確認を組み合わせる

ブラウザーの開発者ツールは幅を連続して変えられ、切り替え前後の確認に役立ちます。ただし、Chrome DevToolsのデバイスモードの説明でも、実際のモバイル端末の動作を完全には再現できないことが示されています。パソコン上の確認を、そのままiPhoneのSafariで確認した記録にしないようにします。

まず対象ページを幅違いで確認し、重要な導線は実機でも操作します。端末名、OS、ブラウザー、向き、拡大設定を記録し、再現できる形で不具合を伝えます。長いページでは最上部だけでなく、遅れて読み込まれる画像、途中の表、最下部の相談導線まで到達して確認します。

すべての機種を所有する必要はありませんが、確認対象を合意する必要はあります。利用状況や問い合わせで報告された環境を参考に優先順位を付け、未確認の条件は未確認と残します。画面のスクリーンショットと、操作して到達した結果を分けて保存すると、何が確かめられたのかが明確になります。

対象・不具合・完了条件を一枚にまとめる

「スマホでいい感じに」では、修正範囲も完了条件もそろいません。次の表を依頼メモの出発点にしてください。例は説明用であり、実際の顧客案件の結果ではありません。

見積もりはページ数だけでなく、共通部品の数、独自フォーム、外部サービス、原稿整理、画像加工、検証環境によって変わります。費用の根拠が分からなければ、「調査」「設計」「実装」「確認」「引き継ぎ」に分けて説明を求めます。一律の相場だけで決めるより、今回必要な工程を比較できます。

公開後にも確認し、次の更新へつなげる

検証環境で問題がなくても、本番のキャッシュ、外部機能、公開設定で結果が変わる場合があります。公開後のURLで同じ確認を行い、画像やリンクが正しく読み込まれること、メニューや相談導線が動くことを確かめます。変更前の保存データと戻し方も用意しておきます。

その後は、検索の表示・クリック、利用中の問題、相談の件数や内容を期間と条件をそろえて見ます。レスポンシブ対応と同時に原稿や広告も変えたなら、数値の変化をレイアウトだけの成果と断定しません。対応の完了は表示と操作で確認し、集客への影響は別に継続して観測します。

自社で対応範囲を整理しきれない場合は、現行URL、困っている画面、更新したい情報、希望時期をまとめるところから始められます。Acquaのホームページ制作・リニューアルの対応内容では、構成からデザイン・実装まで相談できます。見栄えを整えるだけでなく、読む人の判断と操作、公開後の更新までを含めて対応範囲を決めましょう。