responsive-design

レスポンシブデザイン

このスキルは、問題が発生しているレスポンシブ対象を特定し、実行可能な最小の対応パケットを選び、短い戦略と検証の概要を残す必要がある場合に使用します。

このスキルの目的は、汎用的な CSS のレシピを並べたり、フレームワークのスニペットを貼り付けたり、隣接するフロントエンドの懸念事項をすべて取り込んだりすることではありません。

このスキルでは、次のことを行います。

1. まずレスポンシブの問題を分類する
2. 主となるレスポンシブ対応パケットを1つ選ぶ
3. ビューポートとコンテナーのどちらが責任を持つかを明確にする
4. 高密度データやメディアのケースを一般的なレイアウトのアドバイスから切り分ける
5. リフローと検証を明確にする
6. 隣接するフロントエンド作業を適切に振り分ける

まず、以下のサポートドキュメントを読んでください。

• references/intake-packets-and-route-outs.md
• references/layout-decision-checklist.md
• references/handoff-boundaries.md

このスキルを使用する場合

• チームから「このページはモバイルで崩れる」と言われたものの、実際に問題が起きているレスポンシブ対象がまだ不明確な場合。
• ダッシュボード、ナビゲーション、フォーム、カードグリッド、料金ページ、テーブル、埋め込みコンテンツについて、ブレークポイントを追加する前にレスポンシブ戦略が必要な場合。
• 修正をビューポートのレイアウトルール、コンテナクエリ、内在的なレイアウト、レスポンシブなメディア処理、検証やリフローのフォローアップのどこに適用すべきか判断する必要がある場合。
• リリース準備の確認でオーバーフロー、折り返し、情報密度、ズームやリフローの不具合が見つかり、CSS の講義ではなく範囲を絞ったパケットが必要な場合。
• ページ単位の適応、コンポーネントの再利用、高密度データへの対応が依頼に混在しており、実装前に振り分けが必要な場合。

このスキルを使用しない場合

• 主な作業が、再利用可能なプリミティブ／スロット／バリアント API の設計、またはコンポーネントファミリーの責任範囲である場合 → design-system
• 主な作業が、キーボード／フォーカスの動作、セマンティクス、ラベル、コントラスト、モーションの軽減、またはアクセシビリティを重視した修正である場合 → web-accessibility
• 主な作業が、ブレークポイントのガバナンス、トークンポリシー、または複数プロダクトにまたがるレスポンシブ標準である場合 → design-system
• 主な作業が、幅広い UI の批評、仕上げ、ヒューリスティック評価、または多面的なリリース準備監査である場合 → web-accessibility
• 主な作業が、React のハイドレーション、再レンダリングの頻発、またはクライアント境界のパフォーマンス動作である場合 → react-best-practices
• レスポンシブ戦略がすでに明確で、作業が実装だけの場合。この場合は、ルーターを再度実行せず、直接実装してください。

手順

ステップ1：CSS を指定する前に、レスポンシブ対応の作業を整理する

まず、最小限のインテークパケットを記録します。

responsive_intake:
  surface: page-shell | nav | form | table | dashboard | card-grid | media-embed | component-slot | mixed | unknown
  workflow_type: bug-fix | refactor-plan | launch-readiness | review-follow-up | design-handoff | unknown
  primary_packet: page-layout | component-slot | dense-data | media-behavior | verification-reflow | mixed | unknown
  pressure_source: viewport-width | parent-container | content-density | localization-copy | zoom-reflow | mixed | unknown
  signal_source: bug-report | screenshot | browser-resize | qa-review | design-review | a11y-review | mixed | unknown
  confidence: high | medium | low

ルール：「もう1つブレークポイントを追加する」ことから始めてはいけません。まず、問題が発生しているレスポンシブ対象を特定してください。

ステップ2：主となるレスポンシブ対応パケットを1つだけ選ぶ

references/intake-packets-and-route-outs.md のルーターを使用します。

主なパケット：

1. page-layout
2. component-slot
3. dense-data
4. media-behavior
5. verification-reflow

現在の判断に最も効果の高いパケットを選びます。ほかの項目は同等の責任者としてではなく、フォローアップとして記載してください。

ステップ3：不変条件を明示する

以下のルールは、どの回答でも維持します。

• 機能の提供においては、モバイルファーストのデフォルトが引き続き最も安全な基準です。
• 問題をすっきり解決できる場合は、ブレークポイントの乱立より内在的なレイアウトを優先します。
• ビューポートのルールはページシェルの変更を担い、コンテナのルールは再利用可能なスロットの適応を担います。
• ブレークポイントは、デバイスのブランド名ではなくコンテンツへの圧力に基づいて決めます。
• 高密度なテーブルやツールバーは特殊なケースであり、明示的なフォールバックの選択が必要になることがよくあります。
• レスポンシブメディアには、幅を 100% にするだけでなく、srcset／sizes／アスペクト比を意識した設計が必要です。
• ズーム／リフローと長文コンテンツへの耐性は、後付けではなく検証要件です。

ステップ4：レスポンシブ戦略パケットを作成する

次の構成で返します。

# Responsive Strategy Packet

## Scope
- Surface:
- Workflow type:
- Primary packet:
- Confidence: high | medium | low

## Current signal
- Main symptom:
- Pressure source:
- What is already known:
- What still needs direct verification:

## Recommended first slice
1. ...
2. ...
3. ...

## Layout decisions
- Mobile-first baseline:
- Intrinsic layout rules:
- Viewport query layer:
- Container-query usage:
- Dense-data / media fallback:

## Verification plan
- Narrow-width checks:
- Zoom / reflow checks:
- Overflow / wrapping checks:
- Content-density / localization checks:

## Ownership and route-outs
- Primary owner:
- Adjacent skills / teams:

ステップ 5：巨大な CSS チュートリアルではなく、パケットを使う

references/intake-packets-and-route-outs.md からパケットを取得します。

パケットのルール：

• page-layout → ページシェル、ナビゲーション／サイドバーの変化、グリッド列、間隔の密度、ビューポートのブレークポイント
• component-slot → 親要素の幅に応じて変化する、再利用可能なカード／パネル／モジュールの振る舞い。コンテナクエリ、または固有のコンポーネントルール
• dense-data → テーブル、ツールバー、フィルターバー、ダッシュボード、および要約、開示、横スクロールなど、意図的に選択するフォールバック
• media-behavior → 画像／動画／埋め込みコンテンツのサイズ設定、srcset ／ sizes、アスペクト比、トリミング戦略、アートディレクションの例外ケース
• verification-reflow → リリース前のズーム、リフロー、オーバーフロー、長いラベル、ローカライズ、スクリーンショットと手動確認の追加チェック

ステップ 6：仕組みの選択と担当範囲の選択を分ける

本格的な回答では、必ず次のように分けます。

• 仕組み — 固有のレイアウト、ビューポートクエリ、コンテナクエリ、レスポンシブなメディアルール、フォールバック表示
• 担当範囲 — responsive-design、design-system、web-accessibility、design-system、web-accessibility、または react-best-practices

依頼のきっかけがスクリーンショット、QA メモ、または「モバイルで表示が崩れる」という報告の場合、スクリーンショットは完成されたレスポンシブ戦略ではなく、シグナルとなる成果物であることを明示します。

ステップ 7：関連作業は明確に振り分ける

問題が複数の領域にまたがる場合は、次の振り分け先を使います。

実際の作業内容が...	振り分け先...
再利用可能なプリミティブ API、バリアントの乱立、スロットの担当範囲、コンポーネント構造	design-system
セマンティクス、キーボード／フォーカス、ラベル、コントラスト、モーション、またはアクセシビリティを重視した修正	web-accessibility
共通のブレークポイントトークン、システム全体の密度ルール、複数プロダクトにまたがるフロントエンド標準	design-system
リリース準備に向けた幅広い UI 批評、視覚的階層、仕上げ、またはヒューリスティックレビュー	web-accessibility
ハイドレーション、再レンダリングの頻発、クライアント境界のコスト、またはランタイムパフォーマンス	react-best-practices

出力の期待事項

このスキルによる優れた回答では、次のことを行います。

1. 主となるレスポンシブパケットを特定する
2. 範囲を限定した適応戦略を 1 つ推奨する
3. 引き続き必要な手動確認を明示する
4. フレームワークのヘルパーを完全な戦略として扱わない
5. フロントエンド全体の担当範囲に関する広範な質問は抱え込まず、適切な担当先に振り分ける

例

例 1：モバイルでダッシュボードがオーバーフローする

入力

ダッシュボードのフィルターバーとデータテーブルが原因で、モバイルでは横スクロールが必要になります。レスポンシブな振る舞いの修正を手伝ってください。

回答の方向性

• dense-data を選ぶ
• モバイルファーストのシェルを維持しつつ、テーブル／ツールバーのフォールバックを意図的に設計する
• ズーム／リフローの確認と長いラベルのチェックを含める
• 問題の主軸がアクセシビリティを重視した修正に移った場合は、web-accessibility に振り分ける

例 2：多くのスロットで使う再利用可能なカード

入力

同じカードをサイドバー、フィード、2 列グリッドで使っています。コンテナクエリとビューポートブレークポイントのどちらを使うべきでしょうか？

回答の方向性

• component-slot を選ぶ
• 主な要因が親コンテナの幅である理由を説明する
• カードシェルの境界でコンテナクエリまたは固有のレイアウトを推奨する
• 構造自体に問題がある場合は、プリミティブ／API の再設計を design-system に振り分ける

例 3：リリース前の料金ページ

入力

リリース前にこの料金ページをレビューしてください。モバイルではカードが窮屈に感じられ、ヒーローの折り返しもうまくいきません。

回答の方向性

• レイアウト適応の範囲に限り、responsive-design を担当させる
• ページレイアウトと、モバイルで情報が密集するセクションについて、パケットを 1 つ作る
• 幅広い視覚的階層／CTA／仕上げのレビューは web-accessibility に振り分ける
• アクセシビリティの修正は、主な課題になるまでは分けて扱う

例 4：システム全体のブレークポイントに関する議論

入力

すべてのチームで、製品ごとに異なるブレークポイントやスペーシングのルールを使っています。レスポンシブデザインは適切なスキルですか？

出力の方針

• ブレークポイントやトークンの共有ガバナンスは、より広範な design-system の作業であると説明します
• responsive-design の範囲は、複数製品にまたがる標準より狭く保ちます
• ガバナンスだけを求めるリクエストで過剰に起動しないようにします

例 5：ズームとリフローの不具合

入力

このフォームは 400% のズームでもまだ崩れ、キーボードユーザーは文脈を失います。responsive-design で修正し続けるべきですか？

出力の方針

• レイアウトの担当範囲がまだ不明確な場合は、まず verification-reflow を選びます
• ズームとリフローの検証を明示的に含めます
• キーボード操作やフォーカスの修正は web-accessibility に振り分けます
• 1 つのスキルにすべてを担わせず、作業を分割します

ベストプラクティス

1. 構文上の工夫ではなく、問題が発生しているレスポンシブな画面から始めます。
2. ブレークポイントを追加する前に、内在的なレイアウトを優先します。
3. ビューポートとコンテナーの担当範囲を明確にします。
4. テーブル、ツールバー、情報量の多いダッシュボードは、個別に検討すべき例外として扱います。
5. スクリーンショットやデバイスモードでの確認は入力情報として扱い、完了の証明とはみなしません。
6. 検証をおろそかにしないでください。ズーム、リフロー、長いテキスト、オーバーフローも引き続き重要です。
7. 判断に迷ったら、このスキルの範囲をむやみに広げず、関連するフロントエンド作業を明確に振り分けます。

参考資料

• MDN：レスポンシブデザイン
• MDN：メディアクエリの使用
• MDN：コンテナクエリ
• MDN：レスポンシブ画像
• web.dev：レスポンシブデザインを学ぶ
• W3C WAI：リフローの理解