mcpField
A
antislop-layoutmobile

antislop-layoutmobile

github.com/miqdadbadjuberデザイン・UI7.5k6.0k 回インストール今日更新
リポジトリ

antislop-layoutmobile について

antislop-layoutmobileは、画面幅に応じたレイアウトの構築や編集でantislop.mdと併用する、AIコーディングエージェント向けスキルです。意図的な再配置を重視し、ブレークポイント、サイズ、グリッド、はみ出し、タッチ領域を扱います。

主な機能

  1. 01コンテンツに応じたブレークポイント
  2. 02レスポンシブなサイズと文字組み
  3. 03グリッドの再配置と積み重ね
  4. 04はみ出しを防ぐ指針
  5. 05タッチ領域のサイズと間隔

活用シーン

  1. 01デスクトップレイアウトのスマートフォン対応
  2. 02画面幅ごとのレイアウト確認
  3. 03モバイルのはみ出しや窮屈な操作部の発見

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/miqdadbadjuber/anti-slop --skill antislop-layoutmobile

インストール後、Claude Code で/antislop-layoutmobileを入力して読み込まれたか確認します。

詳細

antislop-layoutmobile

Anti Slop:AI コーディングエージェント向けルール。モバイルレイアウトのスキル

antislop システムの一部です。コアである antislop.md と併せてお読みください。このスキルでは、レスポンシブレイアウトの課題、つまりスマートフォンからデスクトップまで、画面サイズに応じてレイアウトをどう組み替えるかを掘り下げます。ブレークポイント、スケール、グリッド、オーバーフロー、タップ領域、ナビゲーションを扱います。コアのルールは番号で参照し、重複させたり番号を振り直したりしません。あらゆる画面幅で適切に表示されるレイアウトを構築または編集するタスクで読み込んでください。

このスキルの使い方

  • モバイルまたはレスポンシブレイアウトの作業では、antislop.md と併せて読み込んでください。コアでは仕組み(目的のテスト、3 つの階層、デリバリーゲート)を扱い、このスキルではモバイルレイアウトを掘り下げます。
  • 各項目は同じ形式です。Tell(パターン)、Why(それがなぜスロップに見えるか)、Fix(代わりにすべきこと)を示し、適用されるコアルールを R-XX として記載します。
  • このスキルの原則は、モバイルレイアウトは、デスクトップレイアウトを小さくしたものではなく、別のレイアウトであるということです。意図を持って組み替える必要があります。要素を積み重ね、サイズを調整し、順序を入れ替えます。以下の各パターンは、レイアウトの組み替えがうまくいかない例です。
  • コアのデリバリーゲートは引き続き適用されます。このファイルの末尾にある「Layoutmobile スキルチェックリスト」は、併せて実施するモバイル向けの補足項目です。

ブレークポイント

デスクトップ専用レイアウト
  • Tell: あらゆる画面でレイアウトが 1 つだけで、モバイル表示はデスクトップレイアウトをスマートフォンの幅に押し込んだものです。
  • Why: R-03 では、後付けではなく、完璧なモバイルレイアウトが求められます。単に縮小するだけでは、モバイルデザインとは言えません。横並びで機能していたカードが重なり、広い画面向けのテキストが狭い画面に詰め込まれてしまいます。
  • Fix: コンテンツが機能しなくなるブレークポイントで、実際のモバイル表示を定義してください。モバイルレイアウトでは、列を縦に積み重ね、サイズを小さくし、コンテンツに応じて順序を変更します。モバイル表示がデスクトップ表示を単に狭くしたものなら、レイアウトはまだ完成していません。
デバイス一覧に基づくブレークポイント
  • Tell: 「iPhone のサイズだから」という理由で選んだ、スマートフォンの幅(375px、414px、768px)にちなんだブレークポイントです。コンテンツがそこで崩れるかどうかは考慮されていません。
  • Why: デバイスの幅は毎年、モデルごとに変わります。ブレークポイントとはレイアウトが維持できなくなる位置です。デバイス一覧に合わせると、コンテンツではなく仕様書にレイアウトを追従させることになります(R-03)。
  • Fix: コンテンツが実際に崩れる位置にブレークポイントを設定してください。たとえば、列が読みづらくなったときや、カードの横並びが狭くなりすぎたときです。ビューポートを狭めながら、どこでレイアウトが切り替わるかを確認し、その位置にブレークポイントを設定してください。
モバイルスタイルを最後に追加
  • Tell: モバイル向けのルールを最後に上書きとして追加しています。デスクトップ向けの長いスタイルシートの末尾に、小さなメディアクエリを加え、1 つか 2 つの問題を修正しています。
  • Why: 上書きによるパッチはモバイルデザインではありません。報告された症状は直せても、次の問題はそのまま残ります。また、基本スタイルは広い画面に最適化されたままです(R-03)。
  • Fix: モバイルを上書きではなく、デザインされた状態として扱ってください。狭いビューポート向けに、サイズや積み重ね方を意図的に設計し、パッチを当てた箇所だけでなくレイアウト全体をそこで確認してください(R-35)。
2状態レイアウト
  • 見分け方: ちょうど2つの状態だけを持つレイアウトです。1つのブレークポイントより下では単一の縦積みカラム、それより上では幅の広い複数カラムのグリッドとなり、その間には何も定義されていません。そのため、タブレットや小型ノートパソコンの幅では、近いほうの状態がそのまま適用されます。つまり、スマートフォン向けの縦積みが不自然なほど横に引き伸ばされるか、デスクトップ向けのグリッドが本来の表示領域の一部に押し込まれることになります。
  • 理由: ページが対応する幅は連続しており、R-03が求めているのは、選んだ2つのブレークポイントだけでなく、すべての幅で適切に表示されることです。状態が2つだけだと、幅の範囲の中間帯全体(タブレットや小型ノートパソコンが該当する、およそ600~1024 px)が成り行き任せになります。コンテンツは意図どおりに縦積みされず、収まるグリッドにも配置されません。デザインどおりに見えるのは2つの確認用の幅だけで、その間はすべて崩れて見えます。
  • 修正方法: コンテンツが適切に表示されなくなる幅に、実際の状態を定義します。状態の数はコンテンツに必要なだけ増やします。一般的なリフローは2つではなく3つの状態です。単一カラムから始まり、カードを1列に並べると幅が広くなりすぎる段階で2カラムのグリッドにし、複数カラムのグリッドが本当に収まる段階で初めて全体のグリッドにします。幅を2つだけ確認して完了とせず、ビューポートを範囲全体でドラッグして確認してください(R-35)。

スケールとサイズ設定

すべてがデスクトップサイズ
  • 見分け方: デスクトップ向けのパディング、間隔、ヒーローの高さ、カードサイズをモバイルでも変えずに使っているため、スマートフォンでは各セクションがすべて大きく見えます。
  • 理由: 1440pxのキャンバス向けのサイズは、375pxの画面では要素を支配してしまいます。デスクトップでは堂々と見えるサイズも、モバイルでは大きすぎます。何も収まらず、余白もなく、手元の画面とは異なる画面向けにデザインされたようなページになります(R-03)。間隔と文字サイズはデザインのリズムに沿う必要があり(R-05)、モバイルではそのリズムを小さく調整します。
  • 修正方法: モバイル用に独自のサイズ段階を設けます。文字サイズのスケールを小さくし、セクションのパディングを詰め、間隔を狭めます。タップ領域は最小サイズを維持し(「タップ領域」を参照)、ブレークポイントではそれ以外の要素を意図的に縮小します。
固定ピクセルの文字サイズ
  • 見分け方: フォントサイズを固定のpxで指定し、デスクトップとモバイルで変えていないため、見出しや本文がスマートフォンでも大きすぎます。
  • 理由: ビューポートに合わせて変化しない文字サイズは、1つの画面にしか適していません。R-03はモバイルレイアウトが適切に表示されることを求めており、R-06は読みやすさを高めるタイポグラフィを求めています。スマートフォンの幅全体に広がる見出しや、広い行幅に合わせた本文サイズでは、どちらも要件を満たせません。
  • 修正方法: clamp() を使った流動的な文字サイズでビューポートに応じてサイズを調整するか、ブレークポイントで文字サイズの段階を小さくします。デスクトップのプレビューだけでなく、狭い幅でも結果を確認してください(R-35)。
100vhのセクション
  • 見分け方: ヒーローやセクションの高さを 100vh に設定しているため、セクションがスマートフォンの画面全体を占め、ほかのコンテンツがすべて画面下へ押し出されています。
  • 理由: デスクトップモニター向けにデザインされたビューポート全体を占めるセクションは、スマートフォンでは巨大なブロックになります。また、100vh にはブラウザーのUIも含まれるため、モバイルブラウザーでは表示領域からはみ出します。導入として機能するのではなく、レイアウトを支配してしまいます(R-03)。
  • 修正方法: セクションの高さはコンテンツに合わせて自動調整する(auto)か、本当に画面全体の高さが必要な場合は動的ビューポート単位(dvh)を使います。画面下のコンテンツの表示が、ビューポート単位による予期しない結果にならないようにしてください。
大きすぎる空白のパディング
  • 見分け方: デスクトップ向けのセクションパディング(96px、128px)をモバイルでも維持しているため、スマートフォンではセクション間に大きな空白ができます。
  • 理由: 大きなキャンバス向けに調整されたパディングは、小さな画面では縦方向のスペースを無駄にします。ページは空白の中をスクロールすることになり、R-05が求めるリズムはセクションの合間ごとに空虚な間隔へと変わります。
  • 修正方法: ブレークポイントでセクションのパディングをモバイル向けの値(およそ半分以下)に減らし、広大な空間を延々とスクロールするのではなく、自然な密度でページをスクロールできることを確認します。

グリッドと縦積み

折り返されないカラム
  • **見分け方:**複数カラムのグリッドがモバイルでも横並びのままになり、カラムが縮んでテキストが不自然に折り返され、要素同士が重なります。
  • **原因:**グリッドは、利用できる幅についての前提を示すものです。ビューポートが狭くなってもグリッドが再配置されないと、各カラムの幅がわずかになり、テキストが読めなくなり、カードが重なります(R-03)。これは衝突による破綻です。デスクトップでの横並びが、モバイルでは詰め込み状態になります。
  • **修正方法:**ブレークポイントでグリッドを、内容に合わせて折り返される単一カラムにします。横並びから縦積みになり、各項目が再び全幅を使えるようになります。狭い幅で再確認してください(R-35)。
固定幅のグリッド
  • 見分け方:grid-template-columns が固定 px で設定されている、またはグリッドエリアが再配置できず、ビューポートが狭くなってもグリッドが固定されたままになります。
  • **原因:**固定 px のトラックはビューポートを考慮しません。幅を保ったまま、はみ出しや衝突を引き起こします。このレイアウトは単一の画面サイズ向けに作られており、形を変えられません(R-03)。
  • **修正方法:**トラックのサイズには minmax() または auto-fit と auto-fill を使い、コンテンツに合わせてカラムが縮み、折り返されるようにします。また、ブレークポイントで折りたたまれるグリッドエリアを定義します。グリッドはデフォルトで流動的にし、固定サイズにするのは意図的に必要な場合に限ります。
強制的な12カラム
  • **見分け方:**1~2カラムが適切なモバイル向けコンテンツに12カラムのグリッドを強制し、スパンが不自然になり、計算がレイアウトと合わなくなります。
  • **原因:**12カラムシステムは、多数のコンテンツカラムを並べる広い画面向けです。スマートフォンでこれを強制すると、すべての要素が、ユーザーには見えないグリッドの一部となり、グリッドにコンテンツを合わせることになって、コンテンツにグリッドを合わせられなくなります(R-03)。
  • **修正方法:**カラムはコンテンツに合わせます。モバイルでは通常、コンテンツは1カラム、または多くても2カラムが適切です。12カラムのスパンが意味を持つのは、実際にそれだけの項目を横並びにするレイアウトの場合に限られます。

はみ出し

横スクロールの発生
  • **見分け方:**テーブル、コードブロック、画像、長くて途中で折り返されない文字列など、ビューポートより幅の広い要素があるため、ページが横方向にスクロールします。
  • **原因:**横スクロールは、モバイルでの期待を損ないます。ユーザーはページの端がどこにあるのか分からず、レイアウトが画面からはみ出しているのが目に見えて分かります(R-03)。原因となる要素がデスクトップのプレビューでは画面外にあり、スマートフォンで開くまで見過ごされるため、最もよくあるはみ出しの問題です。
  • **修正方法:**ビューポートより幅の広い要素(再配置が必要なテーブルやスクロールコンテナ、折り返されるコードブロック、max-width: 100% を設定した画像など)を見つけ、はみ出さないようにするか、内容に合わせて再配置します。最も狭い対象幅でページ全体を確認し、横スクロールがまったく発生しないことを確かめてください(R-35)。
overflow: hidden によるクリッピング
  • **見分け方:**コンテナに overflow: hidden を設定しているため、幅が狭いとテキストやコントロールが収まらずに隠れ、クリッピングされます。
  • **原因:**クリッピングは、問題を隠しているだけです。レイアウトに収まらないコンテンツをコンテナが切り取ると、ユーザーは情報や操作性を失います(R-03)。これに対するズームやテキストサイズ変更の観点については、antislop-human で説明されています。
  • **修正方法:**クリッピングするのではなく、コンテンツを再配置します。コンテナを拡張できるようにする、内容を折り返す、またはブレークポイントで折りたたむなどの方法があります。サムネイルのように切り抜くことがデザインの意図である場合に限り、クリッピングを使います。コンテンツを隠す目的では使わないでください。
固定幅の子要素
  • **見分け方:**狭い画面で、固定 px 幅または min-width を持つ flex や grid の子要素が、親要素からはみ出します。
  • **原因:**絶対 px でサイズを指定した子要素は、親要素がどれだけの幅を持つかを考慮しません。モバイルでは親要素が縮んでも子要素の幅は広いままなので、コンテナとページからはみ出します(R-03)。
  • **修正方法:**相対単位で子要素のサイズを指定し、折り返せるようにします(flex-wrap、流動的な幅、grid の子要素に対する min-width: 0 など)。子要素はデスクトップ用のサイズを保つのではなく、コンテナに合わせて縮められるようにします。

タップ領域

ターゲットが小さすぎる
  • 見分け方: ボタン、リンク、コントロールが約 44 x 44 px より小さく、デスクトップではカーソルで簡単に操作できても、親指では操作しにくい状態です。
  • 理由: デスクトップのカーソルはピクセル単位で正確に操作できますが、親指はそうではありません。16px では問題ないターゲットも、スマートフォンでは操作するたびにストレスになり、UI がモバイルで使えるという約束を果たせません(R-03)。
  • 修正方法: インタラクティブなターゲットには、見た目が小さい場合でもパディングや大きなヒットボックスを使って、44 x 44 px 以上のタッチ領域を確保します。スマートフォンの画面幅で、すべてのコントロールを確認してください(R-35)。
ターゲット同士が近すぎる
  • 見分け方: 44px のターゲットが隙間なく並び、親指でタップすると誤ったターゲットに触れてしまう状態です。
  • 理由: ターゲットのサイズは、ターゲット間の間隔があってこそ重要です。大きなコントロールが2つ接していると、1つの大きなコントロールのように動作し、ユーザーはどちらかを確実に選べません(R-03)。
  • 修正方法: 隣接するインタラクティブなターゲットの間には、少なくとも数 px、できれば指のタッチ領域が重ならない程度の明確な隙間を設けます。間隔もタップのしやすさを左右する重要な要素です。
ホバーのみのインタラクション
  • 見分け方: メニュー、表示切り替え、ツールチップがホバー時にしか表示されず、タッチ操作のユーザーが開けない状態です。
  • 理由: タッチスクリーンにはホバーがありません。ホバーにしか反応しないインタラクションは、モバイルユーザーには存在しないも同然で、それに依存するコントロールは行き止まりになります(R-03)。
  • 修正方法: ホバーのみのインタラクションにはすべて、タップで代替できる操作を用意します。ホバーで開くメニューはタップでも開き、ホバーで表示される内容はクリックでも表示されるようにし、インタラクティブな要素にはタップが反応したことが分かるよう、目に見える :active のフィードバックを表示します。タッチ操作だけで UI を使ってテストしてください(R-35)。

モバイルナビゲーション

デスクトップのままのナビゲーション
  • 見分け方: デスクトップのリンクが横並びになったトップバーをモバイルでも維持しているため、リンクが詰まったり、2行に折り返されたり、ビューポートからはみ出したりする状態です。
  • 理由: デスクトップのナビゲーションは広い画面向けのサイズになっています。スマートフォンでも横並びのままでは、リンクが窮屈に詰まって見づらくなります。モバイルユーザーが最初に目にする要素でもあります(R-03)。ナビゲーションでは、レイアウトの再配置がとりわけ重要です。ユーザーは目的地へ移動する前に、まず行き先を見つける必要があるからです。
  • 修正方法: ブレークポイントでナビゲーションをモバイル向けのパターンに切り替えます。主要な移動先が少数ならボトムナビゲーションにし、それ以外はメニューにまとめます。リンクを横並びから再配置し、主要な移動先には親指で1回タップすればアクセスできるようにします。狭い画面幅でも問題なく表示されることを確認してください(R-35)。
ラベルのないハンバーガーメニュー
  • 見分け方: すべての項目が、ラベルも説明もないハンバーガーアイコンの背後に隠れているため、ユーザーがメニューの存在に気づかなかったり、何が開くのか分からなかったりする状態です。
  • 理由: ラベルのないハンバーガーアイコンは、ユーザーがその意味と、背後にメニューがあることをすでに知っている前提です。モバイルユーザーはそれを知らないかもしれません。また、モバイルでは、隠れたメニューにアプリ内を移動する唯一の手段が含まれている場合もあります(R-03)。
  • 修正方法: メニューの存在を分かりやすくします。ハンバーガーアイコンに「メニュー」とラベルを付けるか、主要な移動先を表示したまま、二次的な項目だけを隠します。重要な項目にたどり着く唯一の手段がメニューである場合は、そのことが明確に分かるようにする必要があります。
コンテンツを隠してしまうボトムナビゲーション
  • 見分け方: 固定されたボトムナビゲーションバーがコンテンツに重なり、リストの最後の項目、最後のボタン、またはユーザーが入力を完了しようとしていたフォームを覆ってしまう状態です。
  • 理由: 固定バーは小さな画面で実際の表示領域を占めます。その領域を確保しないと、コンテンツがバーの下に隠れてスクロールし、特にページの最下部では、隠れた項目にアクセスできなくなります(R-03)。
  • 修正方法: ページのスクロールパディングや、デバイスに応じたセーフエリアのインセットを設定し、コンテンツにバーの高さ分の領域を確保します。重要な内容がバーの背後に隠れないようにしてください。狭い画面幅でも、最後の項目にアクセスできることを確認してください(R-35)。
画面を占有する固定ナビゲーション
  • 見分け方: 固定ヘッダーや高さのある固定ボトムバーが画面の大きな部分を占め、スマートフォンの画面が常にナビゲーションに取られています。
  • 理由: 小さなビューポートでは、固定された表示要素が占めるピクセルの分だけコンテンツが失われます。高さのある固定ヘッダーが表示領域をレターボックス状にし、コンテンツを細長くしてしまいます(R-03)。
  • 修正方法: 固定ナビゲーションはコンパクトに保ち、コンテンツが画面の主役となる大きさにします。適切な場合は、スクロール時に折りたたむか縮小します。ナビゲーションは表示されるべきですが、画面の大部分を占めてはいけません。

Layoutmobile スキルチェックリスト

モバイルまたはレスポンシブレイアウトの作業では、コアの Delivery Gate とあわせて以下を実行してください。すべての回答がはいである必要があります。

  • レイアウトは、デスクトップ版を圧縮するのではなく、明確に異なるモバイル状態へと再配置されますか?(R-03)
  • スマートフォンとデスクトップだけでなく、画面幅に応じた状態が定義されており、タブレットや小型ノートPCの幅で、引き伸ばされた縦積みや詰め込まれたグリッドになりませんか?(R-03、R-35)
  • 文字、パディング、間隔、セクションの高さなどのサイズには、デスクトップ用のサイズをそのまま使わず、モバイル用のスケールが適用されていますか?(R-03、R-05)
  • 複数列のグリッドは、衝突するのではなく、列を減らして縦に積み重なりますか?(R-03)
  • 横方向のオーバーフローがなく、切れているものもありませんか?(R-03)
  • インタラクティブなターゲットは少なくとも 44 x 44 px あり、互いに間隔が空いていますか?(R-03)
  • ホバー時のみのインタラクションに、タップでの代替操作と視認できるフィードバックがありますか?(R-03)
  • ナビゲーションは、デスクトップ用の横一列を圧縮するのではなく、モバイル向けの形式(ボトムナビゲーションまたはメニュー)に再配置されますか?(R-03)
  • 固定ナビゲーションバー(ボトムナビゲーション、固定ヘッダー)がコンテンツを覆わず、安全領域に配慮していますか?(R-03)
  • モバイルのブレークポイントでレイアウトを検証しましたか?(R-35)

コメント