Claude CodeにLP修正を丸投げしてみた｜デザイナーの仕事はどう変わる？

「ちょっと余白だけ広げたい」「FVの文字、もう少し大きく」「CTAボタンの色をブランドカラーに寄せたい」。LP運用をしていると、毎日のように発生するこの手の小さい修正。以前は自分で開いて、CSSを書き換えて、ローカルで確認して、コミットして、デプロイして……という工程を踏んでいました。

最近、これをClaude Code に丸投げするようになりました。最初は半信半疑でした。「どうせ細かい余白とかは無理だろう」「レスポンシブで崩すだろう」と思っていたのが正直なところです。けれど、数週間使い倒した結果、はっきりと言えることがあります。

"修正作業"そのものよりも、"修正の指示の仕方"のほうが、自分の仕事の核になってきている。

この記事は、Claude Code に LP 修正を投げ続けてみた実体験のレポートです。「驚いたこと」「想像以上にダメだったこと」「結局、人間に残った仕事」を、現場感のまま書きます。

軽い気持ちで、LP修正を丸投げし始めた

最初は本当に軽い気持ちでした。「ローカルで CSS いじるのが面倒だな」というだけの理由で、Claude Code に依頼を投げ始めたのが入り口です。

頼んだ内容は、どれも"日々のLP運用で発生する地味な修正"ばかりでした。

• ボタンの余白を広げる

• FV の文字サイズと行間を調整する

• CTA セクションの背景色を変える

• スマホ表示で見切れているテキストを直す

• カードコンポーネントの角丸とシャドウを整える

• セクション間のマージンを統一する

• ホバー時のアニメーションを少し弱める

"自分でやれば10〜20分"レベルの修正たちです。ただ、これが日に何件も積み上がると、地味に時間を持っていかれる。そういう類の作業を、片っ端から Claude Code に渡してみることにしました。

最初に驚いたのは「普通に直してくる」こと

結論から書くと、想像していたよりずっと"普通に"修正されて返ってきます。最初の数日は、毎回、軽く驚いていました。

具体的に、ちゃんと処理されたものを並べるとこんな感じです。

とくに感心したのは、「該当箇所を勝手に探してくる」力です。「あのカードの角丸を少し弱めて」とだけ言っても、コードベースを読みに行って、対象のクラスを特定して、必要な箇所だけを書き換えてくる。grep で当たりをつけて、修正範囲を最小にしようとする挙動が、明らかに人間の作業手順と同じです。

CSS の知識面でも、十分すぎるくらい安定しています。margin / padding の使い分け、flex と grid の選択、メディアクエリの書き方、hover の感じ。"平均的に上手いコーダー"レベルの判断は、もう普通に出てきます。

でも、途中から"崩れる場所"も見えてきた

ここまで読むと「じゃあ全部 Claude Code でいいじゃん」となりそうなのですが、現場で使い倒すと、明確に詰まるポイントも出てきます。ここを書かないと、フェアじゃない。

実際に詰まったパターンを、リアルなまま並べます。

とくに「ここだけ直して」が想像以上に苦手です。たとえば「FV のボタンだけ余白を広げて」と頼んだのに、ページ内の他のボタン共通クラスごと触られて、結果として全ページのボタンが太ってしまう、というのは何度か遭遇しました。

レスポンシブの落とし穴もあります。PC では完璧に直っているのに、SP で見るとレイアウトが崩れている。逆に、SP に最適化したつもりが PC でテキストが間延びしている。プレビューを自分で確認しないと気づけない種類のミスは、一定の頻度で発生します。

あと、地味に効くのが"デザイン意図の読み違え"です。たとえば「CTA を目立たせて」と言うと、ボタンを赤くしてサイズを倍にして影をつけて……みたいな"全部盛り"が返ってくることがあります。本当に欲しかったのは「現状の落ち着いたトーンを保ったまま、視線が留まる強度だけ上げる」だったりするのですが、その粒度の指示は、こちらが噛み砕いて渡さないと届きません。

一番変わったのは「作業」じゃなくて「指示」だった

使い込むほど、はっきりと体感していることがあります。

仕事の重心が、"手を動かす"から"どう伝えるか"に、完全に移った。

以前は、こうでした。

今は、こうなっています。

結果、めちゃくちゃ感じるようになったのが、「言語化のうまさ」がそのまま成果物の質に直結するということです。同じ修正でも、こちらの伝え方次第で、出てくるものが大きく変わります。

右側の指示はどれも、"修正後にどうあってほしいか"が具体的です。Claude Code が強いのは、ここまで噛み砕いてもらった上での"実装"の部分。だから、自分が事前に「何を変えて、何を変えない」をはっきり持っていれば持っているほど、出力の精度が跳ね上がります。

逆に、ふわっと投げて、ふわっと返ってきて、「なんか違うな」を繰り返している時間が一番もったいない。これは AI 全般に共通する話ですが、LP 修正という具体的な作業に落とすと、より露骨に効いてきます。

デザイナーの仕事は「不要」じゃなく「ズレた」

ここまで読んで、「じゃあデザイナー、要らないじゃん」と思った方もいるかもしれません。けれど、現場の体感はまったく逆です。

デザイナーの仕事は無くなったのではなく、"重心がズレた"だけです。

具体的には、こういう変化が起きています。

つまり、"修正する人"から"判断する人"への、静かなロールシフトが起きています。手を動かす作業は AI に渡せるようになった分、その上のレイヤー（何を直すか／何を直さないか）に体重がかかってきている、という構造です。

結局、Claude Code を使うときの実務ルール

ここまでの体験を踏まえて、自分の中で固まってきた"使い方の実務ルール"を共有します。これから AI に LP 修正を任せたい人の、最低限の地図になればと思います。

• 変更前に「触ってほしくないファイル／クラス」を明示する

• 「ここだけ直す」系は、対象セレクタやファイル名を最初に渡す

• レスポンシブは PC / SP どちらの基準で直すかを必ず宣言する

• "目立たせて"などの抽象指示は、強度（数値や比較対象）に翻訳して渡す

• 差分は必ず自分の目で確認する。ブラウザでのプレビューを省かない

• 意図と違う改変が出たら、"なぜそう判断したか"を聞いてから修正方針を渡す

• 同じ改修パターンが3回出たら、共通クラス／変数に切り出す指示も同時に出す

地味ですが、これだけで Claude Code の出力品質はかなり安定します。要するに、「人間側が雑な指示を投げないこと」「最終判断は人間側が握ること」。この2つを守るだけで、AI 修正は十分に実務戦力になります。

まとめ：「修正する人」から「判断する人」へ

最後に、本記事の流れを1枚で整理します。

Claude Code に LP 修正を丸投げしてみて、はっきり分かったことがあります。「余白もう少し広げて」のひと言で LP が直る時代は、もう来ています。けれど、その"ひと言"を、的確に、適切な粒度で、適切なタイミングで投げられる人は、まだ全然多くありません。

デザイナー・コーダーの仕事が消えるわけではありません。"作業"の比重が抜けて、"判断"と"言語化"の比重が一気に増えた、というだけです。手を動かせる力は土台として残しつつ、その上に、判断と言語化の筋肉を乗せていけるかどうか。AI 時代のLP運用は、たぶんそこで差がつきます。