Claude CodeでDesign as Code——参考サイトからWebデザインを作る3ステップ
目次
- なぜAIデザインツールを使わず、参考サイトの設計を読み解くアプローチを選んだのか
- そもそも「AIデザインツール」には2種類ある
- 生成系ツールの現状と限界
- 「クローンして原型がなくなるまで改造する」という発想
- clone-websiteはコピーではなく構造抽出ツールである
- 参考サイトを3段階で丸ごと分解する仕組み
- 出力はそのまま自分のサイト制作のベースになる
- ReactからAstroへの移植でコードは別物になる
- 独自性は「自分だったらこうしたい」から生まれる
- 色変更・削除・追加で自然と原型が消える
- 創造意欲こそが最終的な独自性を決める
- clone-website × Claude Designのハイブリッドパイプラインが次の選択肢になる
- Design as Codeは過渡期の実用的な代替手法である
先週、当サイト(CODENOTE)のデザインを数日で作成しました。その際、Google Stitch、Figma Make、Pencil——最近はAIでデザインを生成するツールが次々と登場していて、触ってみる誘惑もありました。
さらには先日(4月17日)には、AnthropicからClaude Designがリリースされ、デザインからプロトタイプ・スライドまでClaude上で作れるようになっています。
でも当時(と言っても月内の話なんですが、変化がめちゃ早いですね)は「まだAIデザイン系ツールは、過渡期だな」という認識もあり、今回はClaude Codeだけを使ったDesign as Codeに割り切ることにしました。
デザインを作り終えた後にClaude Designがリリースされ、今だったらまた違う選択肢が見えてきたのは後からの話ですが、それも含めて両方の良さを活かす話にも今回繋げていければと思います。
今回やったのは、①参考サイトの構造をAIで抽出 → ②自分の技術スタックに変換 → ③独自にカスタマイズという3ステップです。生成系ツールに頼るのではなく、「良いお手本の設計を参考に、そこから自分色に染めていく」アプローチを取りました。この記事では、その実践プロセスと、後から見えてきたClaude Designとの組み合わせ方まで順を追って書いていきます。
なぜAIデザインツールを使わず、参考サイトの設計を読み解くアプローチを選んだのか
そもそも「AIデザインツール」には2種類ある
この記事では性質の異なる2種類のAIデザインツールが登場するので、最初に整理しておきます。
Reactベース系(Stitch / Figma Make / Pencil / v0 など)
プロンプトからReactコンポーネントとしてUIを出力するツール。アプリ開発など向けの構成が多く、HTMLだけで軽量性を求められるウェブサイト・LP制作には不向きな面があります。
HTMLベース系(Lovable / Claude Design など)
HTMLとして直接出力するツール。ウェブページ向けの構成で、SEOや軽量性の観点でも扱いやすく、Claude Designの場合はそのままClaude Codeへハンドオフできます。(Lovableについての記事)
今回「webサイトでの活用を前提とするとまだ過渡期」と感じていたのは、主にReactベース系ツールに対してのこと。HTMLベースの出力もしてくれるClaude Designは、むしろこの記事で紹介する手法との相性が良いことに後から気づきました。
生成系ツールの現状と限界
ただ実際にいくつか試してみて感じたのは、それっぽくはあるけど中身がペラペラということ。
見た目の雰囲気は出てくるのですが、実際に使えるブログとして必要な要素——記事の一覧にサムネイルや日付がちゃんと並んでいるとか、SNSのシェアボタンが適切な場所にあるとか、人気記事ランキングがサイドバーに出るとか——そういった「当たり前に必要なもの」が抜け落ちていることが多いです。
プロンプトで追加指示すれば足してはくれるのですが、後から継ぎ足した感が出てしまい、全体のレイアウトとして整合性のないデザインになりがちです。最初から考えられた設計とは程遠い、パッチワーク的な仕上がりになってしまうんですよね。
今回はブログメディアという特定の用途があり、「この構造で、このブランドカラーで、この情報密度で」といった明確なイメージがすでにありました。ゼロからAIに生成させるより、 良いお手本の構造を参考に肉付けする方が自分のイメージに近づきやすい——そう判断しました。
「クローンして原型がなくなるまで改造する」という発想
今回のアプローチの前提を整理しておきます。
基本は 「参考になるサイトがあるなら、まずクローンした後に原型がなくなるぐらい改造しまくる」 という発想です。
この「構造の骨格だけ借りる」という手法が、実際にどこまで機能するのか。次からは具体的な工程です。
clone-websiteはコピーではなく構造抽出ツールである
先日Xでバズっていたclone-websiteスキルを軸に作業を進めました。バズったはいいものの「すごい」で終わっている人が多そうだったので、このスキルが何をしているのか整理しておきます。
参考サイトを3段階で丸ごと分解する仕組み
clone-websiteスキルは、3つのフェーズで参考サイトを解析します。
① Reconnaissance(偵察) — PCやスマートフォンなど複数の画面サイズでスクリーンショットを撮影し、サイト上で使われているフォント・余白・色などのデザイン数値を自動で読み取ります。今回は参考にしたサイトのトップ・カテゴリ・記事の3ページを対象にしました。
② Foundation(基盤構築) — 読み取った色・フォント・画像などをダウンロードし、新しいサイトの土台を整えます。#faf5eb(クリーム背景)、#209dd2(スカイブルー)といった具体的な色の値がこの段階で確定します。
③ Component Specs(仕様書生成) — ヘッダー・記事カード・サイドバーなど、各パーツごとの「設計書」を自動生成します。どこに何がどのサイズで配置されているか、ホバー時の動きはどうか、といった情報が細かく記述されます。
この設計書をもとにAIが各パーツを実装し、最後にスクリーンショットで元のサイトと見比べて差異を修正する流れになります。
出力はそのまま自分のサイト制作のベースになる
このスキルを、最初に使ったとき意外だったのですが、clone-websiteが出力するのは参考サイトのコピーではなく、開発ですぐ使えるコンポーネント(パーツ)一式です。
スキルの設計として、Next.js + shadcn/ui + Tailwind CSS v4のコンポーネント一式で出力されることが明示されているので、どのAIモデルでこのスキルを実行するかにもよりそうですが、ほとんどの場合、ちゃんとコンポーネントを分けて出力されてくるかと思われます。
参考サイトの見た目を再現しつつ、AIが自分で構造を組み直してパーツとして再構築する設計になっているわけですね。
今回の場合、3ページの解析からヘッダー・フッター・記事一覧・記事カード・サイドバー・目次など15以上のパーツが生成されました。新しくウェブメディアを作るときに必ず必要になる部品が、最初から揃った状態で手元に届くんですよね。
ここまでで「参考サイトの設計図の抽出」ができました。次はこれを自分が使いたい技術に合わせて変換します。
ReactからAstroへの移植でコードは別物になる
今回当サイトでは最終的にAstroで動かしたかったので、できあがったReactコンポーネントをAIに渡してAstroに変換してもらいました。
この段階で、HTMLとCSS的には元のサイトとかなり別物になっています。元サイトはそもそもTailwindも使っていないし、React経由でリファクタリングされているので。見た目は確かに「クローン」でありつつ、コード的にはすでに別物という状態です。
今回の場合、元サイトがWordPressベースだったのに対し、最終的な技術スタックはAstro 6 + Tailwind CSS + Cloudflare Workersに完全に置き換わりました。
クローンから独自の実装への分岐点はここにあります。コードレベルで別物になった上で、さらに自分色に染めていくわけです。コードが別物になった時点で、技術的な差別化は一定達成されています。
残る問題は「見た目がまだ参考サイトに似ている」状態をどう脱するか——つまりビジュアル面での独自性です。
独自性は「自分だったらこうしたい」から生まれる
色変更・削除・追加で自然と原型が消える
倫理的な前提は当然ありますが、それとは別に「自分が作りたいものを考えたら、参考元とは結局全然違うものになるのが当たり前では」という感覚の方が個人的には強いです。
実際に色の変更、不要なコンポーネントの削除、欲しい要素の追加を進めていくと、自然と「参考サイトそのまま」という感じはほぼなくなります。
構造の骨格だけ借りて、肉付けは全部別物にする。この運用で倫理的にも実用的にも成立するんですよね。
創造意欲こそが最終的な独自性を決める
昨今、アイデアやアプリをツイートするとめちゃめちゃパクられる問題が多発していますが、みんなそんなに「自分だったらこうしたい」という感情がないんだなというのが正直寂しいですね。
Design as Codeの文脈でも同じことが言えて、AIが出したデザインをそのまま使うのではなく、「自分ならどうするか」を突き詰めていく過程こそが独自性の源泉になります。構造は借りても、そこに何を乗せるかは完全に自分次第。
この「創造意欲を最後まで貫く」姿勢が、良いAIデザイン生成とは何かの判断基準になるんじゃないかと思います。
clone-website × Claude Designのハイブリッドパイプラインが次の選択肢になる
今回の実践を終えた後に気づいたことですが、このワークフローには「続き」があります。
CODENOTEのデザインを作り直していた時点では、まだClaude Designはリリースされていませんでした。でも今考えると、clone-website → Claude Designという組み合わせは自然な次のステップとして面白い可能性を持っています。
Claude Designは「0からとりあえずデザイン作って」と指示することもできますが、既存のコードベースや既存のデザインファイルを添付して、そこからデザインシステムを構築することも可能です。
つまりclone-websiteで抽出したReactコンポーネント一式をそのまま渡せる。ゼロから「いい感じのブログを作って」と頼むと、ベースがないぶん出てくるものがどうしても汎用的になりがちですが、clone-websiteで抽出した構造があれば、その骨格の上でデザインを肉付けしていけます。
パイプラインとして整理するとこうなります:
まず設計図を借りてベースを固めてから、その上でAIデザイン生成を重ねる。Claude Designの出力はライブHTMLで、そのままClaude Codeへハンドオフできる点も、このパイプラインとの相性が良いと感じています。
1からAIに生成させるのが「まだ過渡期」という認識は変わりませんが、ベースとなるインプットの質さえ担保できれば、AIデザイン生成ツールの出力は格段に自分のイメージに近づく——そういう使い方なら今でも十分に機能しそうです。
Design as Codeは過渡期の実用的な代替手法である
今回の実践を振り返ると、clone-websiteで構造を抽出し、React→Astroへの変換でコードを別物にし、そこから独自のカスタマイズを重ねるという3ステップがありました。今のフェーズでのデザイン制作において、これが合理的なワークフローでした。
AIデザイン生成ツールは今後も進化していくでしょう。Claude Designがデザインとコーディングの境界を溶かし始めていますし、他のツールも追従していくはずです。
でも現時点では、「良いお手本の設計図を借りて、自分の創造意欲で肉付けする」手法が一番しっくりきています。設計図を借りる方が修正の往復が少なく、自分のイメージにより早く到達できるからです。
同じようにwebデザインに悩んでいる方がいれば、「参考サイトの設計図を借りる→独自にカスタマイズする」ワークフローを試してみてはいかがでしょうか。
試すなら、まずclone-websiteのリポジトリを手元で動かして、参考にしたいサイト1ページのみを対象に偵察フェーズだけ走らせてみるのが最小ステップです。
出力された骨組みを眺めるだけでも、「このサイトがなぜ読みやすく見えるか」の構造的な理由が見えてきて面白いですよ。