AI にフロントエンドを作らせると、どうしても似たような見た目になるって経験、みんなあるやろ
- 黒い背景に紫のグラデーション
- Inter フォント
- 青い丸ボタン
- 最小限のアニメーション
見覚えありすぎて笑えてくるレベルやんか
この記事を読むメリット
そうそう、Claude の公式ブログでめちゃ興味深い記事が出てたんよね
この記事、「なぜ AI の UI が似るのか」と「どう抜け出すか」が丁寧にまとまってるんだけど、少し分かりにくいという人もいるかもなぁと思った。後、具体的なプロンプトの書き方などが不足してるから、そのあたりを補うために書いた
この記事で得られるメリットはこんなところ
- AI っぽい UI を改善するプロンプトが分かる
- デザインに個性が出る
- Skills を理解できる
なぜ AI が作る UI は "AI っぽく" なるのか
Claude も ChatGPT も、めっちゃ優秀なのに、なぜか UI デザインになると個性がなくなる
これって実は AI が下手なわけじゃなくて、分布収束 っていう統計的な宿命なんよね
LLM は学習データの中で「もっとも確率の高い選択肢」を返すように設計されてる
つまり、Web 上に存在する大量のデザインパターンから、安全で無難な選択肢を統計的に選んでしまうってわけ
- Inter フォントが選ばれるのは、Google Fonts でダウンロード数が多いから
- 紫のグラデーションが多いのは、SaaS 系のランディングページでよく使われてるから
モデルは「これが正解」と思ってるわけじゃなくて、「これが統計的に安全」って判断してるんよね
結果として生まれるのが "AI slop" と呼ばれるジェネリックな UI
ブランドアイデンティティも個性もなく、一目で「あ、AI が作ったな」って分かる見た目になってまう
これはモデルの能力不足じゃなくて、モデルの性質上避けられない現象
分布収束という統計的な宿命
もうちょい深掘りすると、LLM のトークン予測ってのは確率分布に基づいてる
「次にどの単語が来るか」を予測するとき、モデルは学習データ全体の統計パターンを参照する
たとえば「フォントを選んでください」って言われたら、モデルの中では以下みたいな確率分布が生まれる
- Inter: 35%
- Roboto: 20%
- Open Sans: 15%
- Playfair Display: 5%
- JetBrains Mono: 3%
モデルは基本的に上位の選択肢を選ぶので、Inter や Roboto みたいな「よくあるフォント」が選ばれやすくなる
これが積み重なると、全体のデザインが平均的な方向に引っ張られていくんよ
色もレイアウトもアニメーションも、全部この原理で「統計的に安全な方向」に収束していく
だから AI が作る UI は、どれも似たような見た目になってまうってわけ
Skills で個性を取り戻す仕組み
じゃあどうすれば個性のある UI を作れるのか
答えは 「デザインの軸をしっかり指示する」 こと
ただ、毎回プロンプトに「Inter は使わないで」とか「紫のグラデーションは避けて」とか書くのは面倒やんか
そこで登場するのが Skills（スキル） って仕組みよ
Skills は 「必要なときだけ読み込む追加の文脈ファイル」 として設計されてる
Claude の公式ブログでは以下のように説明されてる
スキルは指定されたディレクトリに保存されたドキュメント（多くはマークダウン）であり、Claude はシンプルなファイル読み込みツールを通じてアクセスできる
つまり、システムプロンプトに全部詰め込むんじゃなくて、必要な専門知識を必要なときだけ活性化させるってこと
フロントエンド特化の Skill を作っておけば
- React を書くときだけ読み込む
- UI を生成するときだけ読み込む
- 他の作業では邪魔しない
みたいに、ドメイン固有のプロンプト拡張ができるんよね
これによって、プロンプトの再利用性が上がるし、文脈の軽量化もできる
さらに、チームで Skill を共有すれば、デザインガイドラインを統一することもできる
Skill 作成手順
Anthropic の Skills Marketplace からプラグインをインストールした後、Claude に
「.claude/skills/ 以下にスキルを作って」と頼むだけで自動生成できる。
ディレクトリ構成
| 種類 | パス | 説明 |
|---|---|---|
| グローバルスキル | ~/.claude/skills/ | すべてのプロジェクトで利用可能 |
| プロジェクトスキル | .claude/skills/ | 現在のプロジェクト内限定 |
例：独自スキル article-writer を作る場合
実際にどう使うのか - 4 つの設計軸
Claude の公式ブログでは、4 つの主要な設計軸で Skills を活用する方法が紹介されてる
1. タイポグラフィで差をつける
まず一番効果が出やすいのがタイポグラフィ
Skill に以下みたいな指示与えて Claude に作らせると自動でスキル内容を補足してくれて、UI の印象がガラッと変わるものを作ってくれる
たったこれだけで、モデルが選ぶフォントの傾向が変わる
「Inter を避ける」って指示を入れるだけで、統計的な分布から外れた選択肢を選ぶようになるんよね
実際、公式ブログの例では、SaaS ランディングページが基本的な紫グラデーションから、独特なタイポグラフィと一貫性のあるカラースキームに変わってる
2. テーマで統一感を出す
次に効果的なのがテーマの指定
たとえば「RPG 風のテーマ」とか「ダークモードのダッシュボード」とか、具体的な美学を指定すると、全体の統一感が出る
こういう指示を入れることで、モデルが「統計的に安全な選択」から離れて、テーマに沿った個性的な UI を作るようになる
3. モーションで生き生きとさせる
静的な UI だと、どうしても "AI っぽさ" が残る
モーションを加えることで、UI に生命感が出るんよね
こういう指示を入れることで、モデルがポーランドされたインタラクションを実装するようになる
公式ブログの例では、ページロード時に段階的に要素が表示される洗練されたアニメーションが実装されてた
4. 背景で深みを作る
最後に、背景の扱いも重要
AI っぽくならないように、紫色とグラデーションを避ける
こういう指示を入れることで、モデルが単色の背景から脱却して、視覚的に豊かな UI を作るようになる
Artifacts の制約を突破する web-artifacts-builder
Skills の話をするうえで外せないのが web-artifacts-builder って Skill
Claude の Artifacts って便利やけど、実は大きな制約があった
それは 「HTML 1 ファイルにまとめないと表示できない」 ってこと
つまり、React のコンポーネント分割とか、複数ファイルでの開発とかができなかったんよね
これを解決したのが web-artifacts-builder skill
この Skill を使うと
- React コンポーネントを複数ファイルに分割
- Tailwind CSS でスタイリング
- shadcn/ui のコンポーネントを活用
- Parcel で自動的にバンドリング
- 最終的に 1 ファイルの HTML として出力
ってことが裏で自動的に行われる
つまり、開発者としては普通に React を書く感覚で、複雑なアプリケーションを作れるんよね
web-artifacts-builder skill は “自作できるタイプの Skill” で、仕組みは「Claude にコマンド実行とファイル生成を指示して、React/Tailwind/shadcn/ui/Parcel の雛形を自動構築させる」スキル になってる
公式ブログでは、ホワイトボードアプリやタスク管理ツールみたいな、より機能豊富なアプリケーションの例が紹介されてた
これによって、Artifacts の UI 品質がめちゃ上がってる
結論から言うと、web-artifacts-builder skill は “自作できるタイプの Skill” で、仕組みは「Claude にコマンド実行とファイル生成を指示して、React/Tailwind/shadcn/ui/Parcel の雛形を自動構築させる」スキル になってる。
公式の SKILL. md が GitHub に公開されてるので、その構造と作り方をわかりやすく解説するね。
ざっくり仕組み
web-artifacts-builder skill はこう動く。
- Claude に「React プロジェクトの雛形を作るためのコマンド一覧」を渡す
- Claude が「使うべきツール」や「構成ファイル」を読み取り、
npm create vite@latestなどの boilerplate コマンドを“自動で実行” - shadcn/ui・Tailwind・Parcel のセットアップスクリプトも自動実行
- 最後に Parcel で 全てを 1 HTML にバンドル
- Artifact の「単一 HTML 制約」に対応した最終出力ができる
つまり
「大量の面倒なセットアップ作業」をスクリプト化して Claude に渡す Skill
という構造。
公式リポジトリ
ここに SKILL.md がある
これがそのまま Claude の Skill になる。
1. スキルは Markdown で書く
SKILL.md がスキルの本体。
中には
- 何をするスキルか
- どういう時に読み込むか
- Claude が実行するコマンド
- 必要なテンプレートや構成ファイルの例
が Markdown で書かれてる。
Claude は必要な時にスキルファイルを読み込んで
書かれた手順を実行する。
2. “プロジェクト雛形を作るコマンド群” を書く
たとえば
- React プロジェクト初期化
- Tailwind セットアップ
- shadcn/ui の init
- Parcel セットアップ
Skill に以下のような手順を書く。
例（イメージ）
3. Parcel で 1 ファイルにまとめるスクリプトを書く
Artifact は HTML 1 ファイルしか表示できないので
React プロジェクトを Parcel で bundle し直す必要がある。
Skill に書く内容（要旨）
parcel build index.html --no-cache --no-source-maps- 出力物の dist を read して 1 HTML にまとめる
Claude はスキルに書かれた「build スクリプト」を実行する。
4. 最後に Claude に「どう使うか」も書く
SKILL. md の最後に使用方法を記述する。
例
Claude はこの部分を読み、
ユーザーが「使って」と言った時だけこのスキルをロードする。
まとめるとこう作る
-
SKILL .md を作る（Markdown）
-
この中に
- React/Tailwind/shadcn/ui のセットアップ指示
- Parcel bundling の指示
- 使い方（トリガー条件）
- boilerplate スクリプトや構成ファイルの例
を書く
-
Claude に「このスキルを有効化して」と言えばロードされる
つまり、新しい Skill は「Claude が読むレシピ本」
web-artifacts-builder は「React プロジェクト構築レシピ」。
実践：自分だけの Skill を作ろう
じゃあ実際に Skill を作るにはどうすればいいか
基本的な手順はこんな感じ
.claude/skills/ディレクトリを作成- Markdown ファイルで Skill を定義
- Claude に使ってもらう
たとえば、自分のプロジェクト専用のデザイン Skill を作るなら
こうやって定義しておけば、Claude が UI を生成するときに自動的にこのガイドラインを参照してくれる
ポイントは 「禁止事項を明確にする」 こと
「Inter を使わない」とか「紫のグラデーションを避ける」みたいに、統計的に選ばれやすい選択肢を明示的に除外することで、モデルの分布収束を回避できる
あと、具体例を入れるのも効果的
「こういう感じの UI にして」って例を示すことで、モデルの理解が深まる
Skills はプロンプトのモジュール化
最後にまとめると、Skills ってのは 「プロンプトのモジュール化」 って考えるとしっくりくる
これまでは、毎回プロンプトに大量の指示を書く必要があった
でも Skills を使えば
- デザインガイドラインを再利用できる
- 必要なときだけ読み込むから文脈が軽い
- チームで共有できるから統一感が出る
- 企業レベルの UI 品質を維持できる
ってメリットがある
つまり、Skills は 「デザインの知識資産」 として機能するんよね
Claude は本来もっとできるのに、分布の平均に引っ張られて実力を発揮しきれてなかった
Skills を使うことで、その制約から解放されて、個性的で質の高い UI を作れるようになる
AI が作る UI の "AI っぽさ" を消すには、統計的な分布から意図的に外れる必要がある
そのための仕組みが Skills ってわけやな
これからフロントエンドを作るときは、まず自分の Skill を整えることから始めるのが良さそうよね
