デスクトップとモバイルを「レスポンシブ CSS で一本化」しない選択とその確認手順
はじめに
UI を作るとき、「CSS に @media を書けばデスクトップもモバイルも一本化できる」という発想は一般的です。
しかし、このアプリでは @media によるレスポンシブ CSS を使わず、デスクトップ画面とモバイル画面を完全に別ファイルで設計する 方針を取っています。
なぜそうしたか、そしてそれぞれどう検証するかを記録します。
なぜ「@media で一本化」しないのか
① デスクトップとモバイルでは「見せたいもの・操作したいもの」が違う
デスクトップは固定幅レイアウトで情報密度を上げられる。
モバイルはタップ操作を最優先に、1カラムで縦に流す。
この差は「CSS で幅を変える」だけでは解決しません。コンポーネントの構造・要素の順序・ボタンのサイズ、すべてが変わります。
@media で同じ HTML を見た目だけ変えようとすると、デスクトップにもモバイルにも最適化されない中途半端な画面になりやすい。
② 後から「モバイル対応」を追加すると CSS が破綻しやすい
デスクトップ向けに作ったコンポーネントに後から @media を足すアプローチは、CSS の上書きが複雑になり、デスクトップのレイアウトを壊すリスクが高まります。
③ テストとレビューが「片方だけ確認して完了」になりやすい
1 ファイルにデスクトップとモバイルのスタイルが混在すると、片方を直した際に気づかずもう片方が崩れる事故が起きやすい。
このアプリの方針
| 対象 | 方針 |
|---|---|
| デスクトップ画面 | 現在稼働中。FilmsView.vue・FilmDetailView.vue 等 — デスクトップ専用設計 |
| モバイル画面 | 将来的に別コンポーネント・別ファイルとして実装する |
禁止事項：
- 既存のデスクトップ用コンポーネントに
@mediaを後付けすること - Bootstrap や Tailwind の「一石二鳥のレスポンシブ対応」を使うこと
- デスクトップ確認とモバイル確認を同一ファイルで済ませること
デスクトップ画面の確認手順
1. Chrome DevTools をデスクトップモードで開く
1. F12（DevTools を開く）
2. デバイスツールバー（スマホアイコン）が OFF になっていることを確認
3. ウィンドウ幅を 1200px 以上に保つ
Responsive モード（DevTools のモバイルシミュレータ）には切り替えない。
デスクトップコンポーネントはデスクトップ幅で確認するのが原則。
2. 主要画面を順に操作確認する
- 作品一覧（サイドバー展開・折りたたみ両方）
- 作品詳細（画像フォールバック・動画再生）
- ログイン・会員登録フロー
- マイページ・レンタル履歴・支払い履歴
- 決済フロー（通常ヘッダー → Isolated Checkout ヘッダーに切り替わること）
3. 認証状態を変えて確認する
未ログイン → 作品一覧表示 → 詳細 → ログイン → マイページへ遷移
ログイン済み → マイページ → 履歴 → 決済フロー
ログイン前と後でレイアウトが正しく切り替わることを確認します。
// App.vue（認証状態でタブ表示を切り替える実装）
<a
v-if="!isAuthenticated"
@click="currentPage = 'auth'"
>
ログイン・会員登録
</a>
<a
v-else
@click="currentPage = 'mypage'"
>
マイページ
</a>
モバイル画面の確認手順（将来実装時）
モバイル画面は デスクトップとは別のコンポーネント・別のファイル として作成します。
確認も完全に分離して行います。
❌ デスクトップ用コンポーネントを Chrome DevTools の Responsive モードで確認した
✅ モバイル専用コンポーネントを実機または Chrome DevTools のモバイルシミュレータで確認した
Vue 3 での画面幅判定（参考：将来のモバイル実装時に使う想定）
モバイル専用コンポーネントを作る際には、JS で画面幅を判定する処理が必要になることがあります。
あくまで「モバイル専用コンポーネントの初期化時」に使うものであり、デスクトップコンポーネントに混ぜるためのものではありません。
// 画面幅に応じてサイドバーの初期状態を決める（デスクトップ専用コンポーネントの例）
const isSidebarOpen = ref(window.innerWidth > 991)
// matchMedia で画面幅を判定する（将来のモバイル専用コンポーネントの参考）
const isMobile = window.matchMedia('(max-width: 991px)').matches
まとめ
このアプリの方針：
❌ @media を書いてデスクトップ・モバイル両対応を一本化する
❌ Bootstrap の responsive グリッドで「一石二鳥」にする
❌ 既存のデスクトップコンポーネントに後から @media を追加する
✅ デスクトップ画面とモバイル画面を最初から別ファイル・別設計にする
✅ デスクトップの確認はデスクトップ幅で、モバイルの確認はモバイル専用で行う
✅ 両者の実装タイミングも独立させる
「@media を書く = 両対応完了」ではなく、「別々の画面として最初から設計する」という判断をしました。
このアプリの設計方針：レスポンシブではなくモバイル専用画面を別途作る
このDVDレンタルアプリは、レスポンシブ設計を採用していません。
採用した方針
| 項目 | 内容 |
|---|---|
| PC画面 | 固定幅 1240px（min-width: 1240px）、横スクロール運用 |
| モバイル画面 | 同一アプリ内にモバイル専用コンポーネントとして別途作成予定 |
| 機能 | PC画面・モバイル画面ともに同等の機能を提供 |
@media クエリ | PC用コンポーネントには原則入れない |
/* App.vue: PC画面は固定幅で横スクロール対応 */
.page-shell {
min-width: 1240px; /* 幅を縮めても横スクロールで右端まで到達できる */
}
overflow-x: hidden で右端を隠すのではなく、横スクロールで右カラムまで到達できることを維持する設計です。
なぜレスポンシブにしないのか
記事で紹介したレスポンシブ対応は「1つのコンポーネントで全デバイスに対応する」アプローチです。
一方、このプロジェクトではPCとモバイルで情報密度・操作方式・レイアウト方針が大きく異なるため、
同一コンポーネントに @media を後付けするより、モバイル専用コンポーネントを別途設計することを選択しました。
この判断は、Amazon・楽天・DMM のようなECサービスが PCとモバイルで画面をまったく別のUIとして設計しているのと同じ考え方です。
まとめ
この記事で紹介したチェックリストは、「1つのコードでレスポンシブ対応する場合」の確認事項です。 「モバイルは専用画面を別途作る」という設計方針をとる場合は、このチェックリストの適用範囲はモバイル専用コンポーネントの開発時になります。
このシリーズの記事マップ
→ dvdrental 管理アプリと対になるエンドユーザー向けDVDレンタルアプリを作っている話 — Vue 3 + Spring Boot の全体構成と記事マップ