Claude Code でレスポンシブの悩みが全部解決した話

レスポンシブデザインって、一見簡単そうに見えるけど、実際やってみるとめっちゃ面倒なんよね

デスクトップで完璧に見えてたカードグリッドが、タブレットで見たら崩れてる

スマホでは問題ないのに、微妙な幅のタブレットだけレイアウトが壊れる

こういう経験、フロントエンドやってる人なら誰でもあるやろ

ワイも何度もこの問題に悩まされてきたんよ

特にタチが悪いのが、「特定の幅だけ崩れる」パターンやねん

例えば 843px だけオーバーフローするとか、920px だとナビゲーションの文字が折り返されるとか

こういうのを見つけるために、DevTools でひたすら幅を変えながらチェックするんやけど、めっちゃ時間かかるんよね

しかも、DevTools で完璧に見えても、実機の Safari で崩れてたりするから、結局実機テストも必要になる

この試行錯誤の繰り返しが、レスポンシブ実装の一番面倒なところやったんや

参考

従来のアプローチの何が問題やったん

レスポンシブ実装の従来のアプローチには、いくつか大きな問題があったんよ

手動メディアクエリの限界

まず、手動でメディアクエリを書くアプローチの問題やな

最初に base の CSS を書いて、それから各ビューポート幅での崩れを見つけて、後付けでメディアクエリを書いていくってやり方

これって、どの幅で break するかは内容次第やから、デバイスの標準的な幅（768px とか 1024px とか）を使っても、実際のコンテンツが折れる場所とは合わないことが多いんよ

例えば、Tailwind の md ブレークポイントは 768px やけど、実際のプロジェクトでは 920px でナビゲーションの文字数が折れるとか、そういうズレが発生するわけ

結果として、「フレームワークのブレークポイントに合わせてデザインが歪む」って現象が起きる

本来は「コンテンツが折れる場所」を基準にすべきやのに、「フレームワークが定義した幅」に合わせざるを得なくなるんやな

これって本末転倒よね

実機テストの終わりなき戦い

次に、実機テストの問題や

DevTools のレスポンシブモードでチェックしても、実機で見ると全然違うことがあるんよ

iOS の Safari で崩れる、Android のブラウザ UI でコンテンツが隠れる、iPad の横向きで変なことになる

こういう問題は、実機でテストしないと分からへんことが多い

でも、全てのデバイスと全ての幅でテストするなんて、現実的に無理やんな

結局、主要なデバイスだけテストして、「まあ、これで大丈夫やろ」って妥協することになる

そして、リリース後にユーザーから「このデバイスで崩れてます」って報告が来るわけや

この「テストしてもしても完璧にはならない」っていう状況が、めっちゃストレスやったんよね

フレームワーク依存の罠

Bootstrap や Tailwind のブレークポイントを使うと、確かに実装は速くなるんよ

でも、それが「そのプロジェクトに最適な幅」とは限らへん

Tailwind の標準的なブレークポイントは以下みたいな感じや

• sm: 640px
• md: 768px
• lg: 1024px
• xl: 1280px
• 2xl: 1536px

これって、確かに一般的なデバイスの幅を考慮してるんやけど、プロジェクトごとのコンテンツの量や文字数、レイアウトの複雑さによって、最適な幅は変わってくるんよね

例えば、ナビゲーションのメニュー項目が 6 個あるプロジェクトと、10 個あるプロジェクトでは、ハンバーガーメニューに切り替えるべき幅が違うはずやん

でも、フレームワークの標準ブレークポイントを使ってると、そういうプロジェクト固有の最適化がやりにくくなるんや

デバッグがめっちゃ大変

レスポンシブのバグって、原因の特定がめっちゃ大変なんよ

例えば、「843px だけオーバーフローする」みたいなバグがあったとする

これの原因を探すために、width、padding、gap、font-size、それらの複合的な影響を全部チェックしないといけへん

しかも、親要素の設定が子要素に影響してたりするから、CSS 全体を追わないと原因が分からへんことも多いんや

経験豊富なエンジニアでも、こういうバグの修正には時間がかかるんよね

ワイも以前、たった 1px のズレを修正するために、3 時間くらい費やしたことがあるわ

Claude がレスポンシブの悩みを解決してくれる

で、ここからが本題やねん

Claude がこのレスポンシブの悩みを、めっちゃスマートに解決してくれるようになったんよ

しかも、用途に応じて 2 つのモードがあるんや

Claude.ai はプロトタイピングに最強

まず、ブラウザ版の Claude.ai は、レスポンシブの新規設計に最適やねん

実装前のプロトタイピングや構造設計に強いんよ

例えば、こんな感じで指示を出すだけで、レスポンシブなレイアウトを作ってくれる

「デスクトップで 3 列、タブレットで 2 列、モバイルで 1 列のカードレイアウトを作って」

そうすると、セマンティックな HTML5 と、複数のビューポートに対応した CSS を生成してくれるんや

しかも、ただコードを生成するだけじゃなくて、「なぜそのブレークポイントを選んだか」も説明してくれるんよね

例えば、「カードの最小幅が 300px なので、3 列を維持するには 960px 以上必要です。そのため、960px 未満では 2 列に切り替えます」みたいな説明がつく

これがめっちゃ便利やねん

ブレークポイントを選んだ理由が分かると、後で調整する時にも判断しやすくなるんよ

ワイが特に気に入ってるのは、Claude が「標準ブレークポイントありき」じゃなくて、「コンテンツが折れる場所を優先する」っていう基本姿勢を理解してる点や

これって、レスポンシブ設計の基本中の基本やけど、意外と守られてないことが多いんよね

Claude Code は既存コードのリファクタリングに強い

次に、CLI 版の Claude Code は、既存コードベースの大規模リファクタリングに使うんや

これがめっちゃ強力やねん

CSS 全体を解析して、問題点を一覧化してくれるんよ

しかも、行番号付きで「どのルールが崩れの原因か」まで特定してくれる

例えば、こんな感じで指示を出すと

「このプロジェクトのレスポンシブ対応をチェックして、問題があれば修正して」

Claude Code は以下みたいなことをやってくれるんや

• 全ての CSS ファイルを解析
• 固定幅のスタイル（width: 800px みたいなやつ）を特定
• オーバーフローの原因になってる箇所を指摘
• 流動的な代替案（max-width: 100% とか）を提案
• 自動修正まで実行
• 複数のビューポートサイズで動作確認
• Playwright テストを自動生成

これって、「デザインチームもエンジニアチームも嫌がる、横断的な CSS のリファクタ」を自動化してくれるってことやねん

めっちゃ画期的やと思わへん

具体的にどんなコード提案してくれるん

じゃあ、Claude が具体的にどんなコードを提案してくれるのか、見ていこか

CSS Grid の auto-fit + minmax パターン

Claude がよく提案してくれるのが、CSS Grid の repeat(auto-fit, minmax()) パターンやねん

これがめっちゃ便利なんよ

このパターンの何がすごいかっていうと、メディアクエリなしでレスポンシブになるんよ

auto-fit は、利用可能なスペースに応じて自動的にカラム数を調整してくれる

minmax(300px, 1fr) は、各カードの最小幅を 300px、最大幅を残りのスペースの均等割りに設定する

つまり、画面幅が 900px なら 3 列、600px なら 2 列、300px 未満なら 1 列になるってことやな

これまでワイは、こういうレイアウトを実現するために、3 つくらいメディアクエリを書いてたんよ

でも、このパターンを使えば、メディアクエリなしで同じことができるんや

Flexbox の flex-wrap パターン

Flexbox を使う場合は、flex-wrap と組み合わせたパターンを提案してくれるんよ

この例だと、flex: 1 1 300px で「伸びる、縮む、ベースは 300px」って指定してるんよ

そして、max-width で各ブレークポイントでの最大幅を制御してる

Claude は、Grid と Flexbox の使い分けについても説明してくれるんやけど、基本的には以下みたいな考え方やな

• Grid: 2 次元レイアウト（行と列を同時に制御したい場合）
• Flexbox: 1 次元レイアウト（行または列のどちらかだけを制御したい場合）

この使い分けが理解できると、レスポンシブ実装がめっちゃ楽になるんよ

Container Query の活用

最近の Claude は、Container Query も提案してくれるようになったんや

これがめっちゃ便利やねん

Container Query は、ビューポートの幅じゃなくて、親要素の幅に応じてスタイルを変えられるんよ

これって、コンポーネント単位でレスポンシブにできるから、再利用性が高くなるんやな

従来のメディアクエリだと、「画面全体の幅」を基準にするしかなかったけど、Container Query なら「このコンポーネントが置かれてる場所の幅」を基準にできるわけや

これは、デザインシステムやコンポーネントライブラリを作る時に特に便利やねん

実際の使い方、こんな感じで指示すればいい

じゃあ、実際に Claude をどう使えばいいのか、具体的な指示の例を紹介するわ

新規レイアウトを作る場合

Claude.ai を開いて、こんな感じで指示を出すんや

そうすると、HTML と CSS を生成してくれる

しかも、「なぜこの実装にしたか」の説明もついてくるから、学習にもなるんよね

既存コードをリファクタする場合

Claude Code を使う時は、こんな感じでターミナルから指示を出すんや

「このプロジェクトの CSS を解析して、レスポンシブ対応の問題点を洗い出して。特に、固定幅のスタイルと、オーバーフローの原因になってる箇所を教えて」

そうすると、Claude Code がプロジェクト全体を解析して、問題点をリストアップしてくれるんよ

例えば、こんな感じの報告が返ってくる

• styles/header.css:23 - width: 1200px が原因で、小さい画面でオーバーフローしています。max-width: 100% に変更すべきです
• styles/card.css:45 - padding: 40px が固定値なので、小さい画面で余白が大きすぎます。clamp(1rem, 5vw, 2.5rem) の使用を検討してください
• styles/grid.css:12 - grid-template-columns: 1fr 1fr 1fr は固定されています。repeat(auto-fit, minmax(300px, 1fr)) に変更すれば、自動的にレスポンシブになります

こういう具体的な指摘をもらえると、修正がめっちゃ楽になるんよね

テストまで自動化してくれる

さらにすごいのが、Playwright のテストコードまで生成してくれることやねん

「主要なブレークポイントで正しく表示されるか、テストコードを作って」

って指示すると、こんな感じのテストを生成してくれる

このテストを CI に組み込んでおけば、リグレッションを防げるんよね

レスポンシブのバグって、「別の場所を修正したら、前は動いてた部分が壊れた」ってことが多いから、こういう自動テストがあるとめっちゃ安心やねん

ワイが実際に使ってみて感じたこと

ワイも実際に Claude Code を使ってみたんやけど、めっちゃ便利やったで

特に良かったのは、以下の 3 点や

試行錯誤の時間が激減した

これまでは、ブレークポイントを決めるために、DevTools で幅を変えながら何度も確認してたんよ

「ん、この幅だと崩れるな」「じゃあ、もうちょっと広くするか」みたいな感じで

でも、Claude に相談すると、「コンテンツの幅から計算すると、このブレークポイントが最適です」って理由付きで提案してくれるんや

これで、試行錯誤の時間がめっちゃ減った

見落としてた問題を発見できた

既存のプロジェクトを Claude Code で解析させたら、ワイが全く気づいてなかった問題点を指摘されたんよ

「この padding は固定値なので、小さい画面で余白が大きすぎます」とか

「この要素は min-width が設定されてないので、テキストが長い場合に崩れる可能性があります」とか

こういう「まだ顕在化してない潜在的な問題」を見つけてもらえるのは、めっちゃありがたいよね

学習になる

Claude は、ただコードを提案するだけじゃなくて、「なぜそうするのか」を説明してくれるんよ

これがめっちゃ勉強になる

例えば、「flex-basis と width の違いは何ですか」って聞いたら、詳しく説明してくれるし

「このケースだと、Grid より Flexbox の方が適してる理由」みたいな設計判断の根拠も教えてくれる

コードを書いてもらうだけじゃなくて、レスポンシブ設計の考え方自体を学べるのが、めっちゃ価値あると思うんよ

注意点、完全に丸投げはできへん

ただし、注意点もある

Claude は確かにめっちゃ便利やけど、完全に丸投げできるわけじゃないんよ

デザインの意図は伝える必要がある

Claude は、レスポンシブの実装方法は提案してくれるけど、「どういうデザインにすべきか」は分からん

だから、「このブレークポイントでは、どういうレイアウトにしたいか」っていうデザインの意図は、ちゃんと伝える必要があるんや

例えば、「モバイルでは画像を小さくしたい」のか「モバイルでは画像を非表示にしたい」のかで、実装が全然変わってくるよね

その辺の判断は、やっぱり人間がしないと

生成されたコードは確認が必要

Claude が生成したコードは、基本的には正しいんやけど、たまに微妙な部分もあるんよ

例えば、不要な vendor prefix が入ってたり、古い書き方になってたりすることがある

だから、生成されたコードは一度確認して、必要なら修正する必要があるねん

まあ、これは Claude に限らず、AI 全般に言えることやけどな

プロジェクト固有の制約は考慮されへん

Claude は、一般的なベストプラクティスを提案してくれるけど、プロジェクト固有の制約までは考慮されへんことが多いんよ

例えば、「IE11 対応が必要」とか「CSS Modules を使ってる」とか「Tailwind のカスタム設定がある」とか

そういうプロジェクト固有の事情は、ちゃんと伝える必要がある

逆に言えば、ちゃんと伝えれば、それに対応したコードを提案してくれるってことやけどな

まとめ、レスポンシブの悩みから解放された

レスポンシブ実装の「面倒」「経験が必要」「漏れが出る」っていう問題を、Claude がめっちゃ解決してくれるようになったんよ

新規設計の場合は Claude.ai でプロトタイピングして、既存コードのリファクタは Claude Code で自動解析・修正する

この使い分けができるようになると、レスポンシブ実装の効率がめっちゃ上がる

ワイ自身、これまでレスポンシブ実装にめっちゃ時間かけてたんやけど、Claude を使うようになってから、その時間が半分以下になったわ

しかも、品質も上がってるんよね

見落としてた問題を指摘してもらえるし、ベストプラクティスに沿ったコードを提案してもらえるから

特に、「なぜそうするのか」の説明が付いてくるのが、めっちゃありがたいねん

ただコードを提案されるだけじゃなくて、レスポンシブ設計の考え方自体を学べるから

もしあなたがレスポンシブ実装で悩んでるなら、Claude を試してみることをめっちゃオススメするで

特に、既存のプロジェクトで「レスポンシブ対応が微妙なまま放置されてる」みたいな状況があるなら、Claude Code で一気にリファクタするのがいいと思うんよ

デザインチームもエンジニアチームも嫌がる「横断的な CSS のリファクタ」を、AI が自動化してくれるって、めっちゃ革命的やと思わへん

これからのフロントエンド開発は、AI をうまく使いこなせるかどうかが、生産性の差になってくると思うんよね

レスポンシブ実装は、その良い例やと思うわ