responsiveness-check

レスポンシブ対応のチェック

ビューポート幅の変化に対するウェブサイトのレイアウトの反応をテストします。1つのブラウザーセッションでブレークポイントを移動しながら、各幅のスクリーンショットを撮影し、隣接するサイズを比較して、レイアウトが崩れる箇所を報告します。

テスト対象：レイアウトのレスポンシブ対応 — はみ出し、積み重ね、ナビゲーションの切り替え、コンテンツの再配置。

テスト対象外：一般的なアクセシビリティ（ARIA、セマンティック HTML、見出し階層、色のコントラスト）。これらはビューポート幅によって変化しないため、代わりに ux-audit スキルを使用してください。

ブラウザーツールの優先順位

開始する前に、利用可能なブラウザーツールを確認してください。

1. playwright-cli（推奨） — リサイズ、名前付きセッション、サブエージェントの並列実行に対応しています。インストールされている場合は、まず /playwright-cli を実行して、コマンドのリファレンス全体を読み込んでください。
2. Playwright MCP (mcp__plugin_playwright_playwright__*) — ビューポートの変更には browser_resize を使用します。
3. Chrome MCP (mcp__claude-in-chrome__*) — ビューポートの変更には resize_window を使用します。ユーザーがログインしている Chrome セッションを使用します。

いずれも利用できない場合は、ユーザーにその旨を伝え、playwright-cli または Playwright MCP のインストールを提案してください。

実行モード

モード 1：標準チェック

使用する場合：「レスポンシブ対応をチェック」「レスポンシブチェック」「ブレークポイントをテスト」

デバイスの幅広い範囲をカバーする、主要なブレークポイント 8 種類をテストします。

幅	デバイスのコンテキスト
320px	小型スマートフォン（iPhone SE）
375px	標準的なスマートフォン（iPhone 14）
768px	タブレットの縦向き（iPad）
1024px	タブレットの横向き／小型ノートパソコン
1280px	ノートパソコン
1440px	デスクトップ
1920px	Full HD
2560px	ウルトラワイド／4K

手順：

1. 1つのブラウザーセッションで URL を開きます（高さ：900px）。
2. 320px から開始します。各ブレークポイント幅で、次の手順を実行します。 a. ビューポートをリサイズします。 b. CSS の再配置（レイアウト遷移）が完了するまで少し待ちます。 c. ファーストビューのスクリーンショットを撮影します。 d. ページにファーストビューより下のコンテンツが多くある場合は、スクロールしてスクリーンショットを撮影します。 e. 8 項目のレイアウトチェックを実行します（下のマトリクスを参照）。 f. 深刻度とともに問題を記録します。
3. 隣接する幅を比較し、レイアウトが切り替わる箇所を特定します。
4. レポートを作成します。

モード 2：スイープ

使用する場合：「レスポンシブスイープ」「すべてのブレークポイントをスイープ」「崩れる箇所を見つける」

320px から 2560px まで 160px 刻みですべての幅をテストします（合計 15 種類）。標準チェックと同じく、1つのセッションで実行します。違うのは、データポイントが増えることだけです。レイアウトが崩れる正確な幅を見つけるためのモードです。

幅：320、480、640、800、960、1120、1280、1440、1600、1760、1920、2080、2240、2400、2560

スイープモードを開始する前に、簡潔に確認してください（スクリーンショット 15 枚を撮影するため、相応の時間がかかります）。

モード 3：範囲を指定したチェック

使用する場合：「768 から 1024 の間をチェック」「タブレットのブレークポイントをテスト」「モバイルの幅を重点的に確認」

ユーザーが指定した範囲を 80px 刻みでテストします。問題が起きる箇所がわかっており、詳しく調査する必要がある場合に使用します。

例：「768 から 1024 の間をチェック」の場合、768、848、928、1008 をテストします（終点として 1024 も含みます）。

複数 URL

複数の URL をテストする場合（例：「ホームページ、概要ページ、問い合わせページをチェック」）：

• URL ごとに 1 つのサブエージェントを起動し、並列実行します（ブレークポイントごとではありません）。
• 各サブエージェントは、それぞれの名前付きセッションで、担当 URL の標準チェックを実行します。
• 結果をまとめて 1 つのレポートにします。

# Sub-agent pattern (playwright-cli)
playwright-cli -s=page1 open https://example.com/ &
playwright-cli -s=page2 open https://example.com/about &

レイアウトチェック項目

以下の 8 項目では、ビューポート幅によって実際に変わる問題を確認します。

#	チェック項目	確認する内容
1	水平方向のオーバーフロー	コンテンツがビューポートより広くなっていないか — 水平スクロールバーが表示される、要素が途切れる
2	テキストのオーバーフロー	テキストが単語の途中で切れている、隣接する要素と重なっている、フォントサイズが読めないほど小さい（< 12px）
3	ナビゲーションの切り替え	適切な幅でハンバーガーメニューが表示・非表示になるか、表示モード間で「崩れた」状態にならないか
4	コンテンツの積み重ね	狭い幅では、複数列のレイアウトが論理的な読み順で単一列に積み重なるか
5	画像・メディアの拡大縮小	画像がコンテナーからはみ出す、アスペクト比が崩れる、レスポンシブなサイズ指定がない
6	タッチターゲット	モバイル幅（< 768px）でインタラクティブ要素が 44px 未満 — ボタン、リンク、フォーム入力欄
7	余白のバランス	モバイルでは窮屈すぎる（余裕がない）、広い画面ではスカスカすぎる（余白の中にコンテンツが埋もれる）
8	CTA の視認性	各幅で、スクロールしなくても主要な行動喚起がファーストビューに表示されるか

切り替え箇所の検出

このスキルならではの価値は、レイアウトの切り替えが起きる箇所と、その切り替えがスムーズかどうかを特定することです。

隣接する幅でスクリーンショットを比較する際は、次のいずれかが起きる幅を報告してください。

• 列数が変わる（3 列 → 2 列 → 1 列のグリッド）
• ナビゲーションモードが切り替わる（フルナビゲーション → ハンバーガーメニュー、またはその逆）
• サイドバーが表示・非表示になる（コンテンツ幅が大きく変わる）
• グリッドが再配置される（カードが次の行に折り返す）

各切り替えが起きる正確な幅の範囲を報告してください。

切り替え	変更前	変更後	幅の範囲
ナビゲーション：ハンバーガー → フル	768px	1024px	約 960px で切り替え
グリッド：1 列 → 2 列	640px	768px	約 700px で再配置
サイドバーが表示	1024px	1280px	約 1100px で表示

これにより、開発者は CSS のブレークポイントをどこに設定（または修正）すればよいかを正確に把握できます。

重大度レベル

ux-audit と同じ基準です。

重大度	意味
Critical	レイアウトが壊れている — コンテンツが読めない、ナビゲーションにアクセスできない、ページが使用できない
High	重大なレイアウトの問題 — 大きなオーバーフロー、重要なコンテンツが隠れている、切り替えが崩れている
Medium	目立つが使用可能 — 不自然な余白、軽微なオーバーフロー、積み重ね順が最適でない
Low	仕上げの調整 — 余白の微調整、わずかな位置ずれ、タッチターゲットの軽微な不足

自律性のルール

• そのまま実行：ビューポートの幅を変更し、スクリーンショットを撮影し、レイアウトを分析して幅を比較します
• 簡単な確認：スイープモード（15 個のビューポート）を実行する前、および 4 件以上の URL を並行してテストする前
• 事前に確認：フォームを操作する前、または認証フローを進める前

レポートの出力

レポートは docs/responsiveness-check-YYYY-MM-DD.md に保存してください（単一ページの簡易チェックの場合はインラインで記載します）。

レポートの構成については references/report-template.md を参照してください。

参考ファイル

場合	読むファイル
ブレークポイントの詳細と問題が起こりやすい領域を確認する場合	references/breakpoints.md
レスポンシブネスレポートを作成する場合	references/report-template.md