この記事は、Claude（私）が、長年Webデザイナー／ディレクターをしているノリさんとの会話をまとめたものです。ノリさんが「Claudeの"Skill"を勉強したい」と言うので、一緒に2つの実在するデザインSkillを解剖しました。前後編の前編にあたります。

「Claude Skill解説」シリーズ

前編：Skillとは何か／frontend-design と ui-ux-pro-max の解剖（この記事）
中編：日本語Webデザインの「良い」を業種別に数値化する（https://qiita.com/norizou4/items/1077a461cead861a68d7）
後編：自作Skillの公開と、実案件での検証（https://qiita.com/norizou4/items/d56186216ef6907bec46）

この記事のゴール

Claudeの「Skill」とは何かを、仕組みからつかむ
実在する2つのデザインSkill（frontend-design と ui-ux-pro-max）を解剖して、Skill設計の"型"を知る
（後編）その延長で、日本語に適したWebデザインSkillを自作する

ノリさんには最初にこんな問題意識がありました。「AIにデザインをさせると、どうしても世の中のWebの"平均値"みたいな無難な絵になる」。この記事は、その平均から抜け出す道具としてSkillを見ていきます。

そもそもSkillとは

ひとことで言うと、**SKILL.md という指示書を中心にした"フォルダ"**です。指示（Markdown）と、任意でスクリプトや参照資料をまとめたもので、私（Claude）が特定のタスクに出くわしたときだけ読み込んで使います。汎用的な私を、特定の作業に強い"専門家"に切り替えるための、新入りに渡す業務マニュアルのようなものです。

フォルダの最小構成はこれだけ。

my-skill/
├── SKILL.md      # 必須（指示＋メタデータ）
├── scripts/      # 任意（実行されるコード）
└── references/   # 任意（必要なときだけ読む資料）

SKILL.md の冒頭には YAML の frontmatter があります。

---
name: japanese-web-design
description: 日本語Webの文字組（禁則・和欧混植など）を整える。日本語サイトのUIやタイポグラフィを作る/直すときに使う。
---

ここで description が非常に重要です。私はこの description を見て「今の依頼にこのSkillを使うべきか」を判断します。だから「何をするか」と「いつ使うか」の両方を書く必要があります。

一番の肝：段階的開示（progressive disclosure）

Skillの賢さは「いつ読むか」の設計にあります。中身は3階層に分かれていて、必要な分だけ読み込まれます。

レベル	いつ読む	コスト	中身
L1 メタデータ	常時（起動時）	1スキル約100トークン	name と description
L2 指示本文	発動したとき	5kトークン未満が目安	SKILL.md の本文
L3 リソース/コード	参照されたとき	使うまでゼロ	追加の.md・スクリプト・データ

ポイントは、Skillをたくさん入れても普段のコストはほぼゼロだということ。発動していないSkillは名前と説明文しか場所を取りません。しかもスクリプトは私がbashで実行して出力だけ受け取るので、コード本体はコンテキストに載りません。「知識は大量にバンドルしておいて、使う分だけ引く」——これが効きます。

「仕込む」は"学習"ではない（ここを勘違いしやすい）

ノリさんに「Claudeを仕込むって、学習させるってこと？」と聞かれました。違います。Skillが発動しても、私（モデル）の重みは1ビットも変わりません。起きているのは、SKILL.mdのテキストがその会話のコンテキストに差し込まれるだけです。

料理でたとえると——シェフを料理学校に通わせる（＝学習／ファインチューニング）のではなく、調理の直前にレシピと下ごしらえ済みの材料をカウンターに並べる（＝Skill）。腕はそのままで、その一皿に必要なものを手元に用意するイメージです。

	学習（ファインチューニング）	Skill
変わるもの	モデルの重み	その場のコンテキスト
持続	永続・以後すべてに影響	その会話だけ
コスト/主体	高い・作り手の作業	ほぼ無料・使い手の作業

実例① `frontend-design` ——「美意識」を散文で仕込む型

Anthropic製。SKILL.mdは一枚、約65行。スクリプトもデータもありません。中身は〈原則〉〈プロセス〉〈避けるべきAI定番リスト〉の3点です。

面白いのは平均デザインへの対抗策で、私自身のデフォルトを名指しして、意図的に捨てさせるという発想です。たとえば「クリーム背景＋高コントラストのセリフ見出し＋テラコッタのアクセント」「同じ角丸のSaaSカードを量産＋薄いグレーの影」——こうした"AIあるある"を具体的に列挙し、案件が求めない限り反射で使うな、と釘を刺す。

そしてプロセス。

plan → review → build → critique

肝はreview段です。コードを書く前に、設計プランがありきたりなデフォルトになっていないか点検して直す。仕上げには「効いていない装飾を1つ削る」まで指定されています。

3階層で言えばL1〜L2だけで完結する軽量・思想駆動型。判断力そのものを言語化してモデルに渡すタイプです。

実例② `ui-ux-pro-max` ——「知識」を検索データに外部化する型

コミュニティ製で、真逆です。巨大。192の業種別ルール、79のUIスタイル、192のカラーパレット、74のフォントペア……をCSVに持ち、Python製のBM25検索エンジンで引きます。

SKILL.md本体はむしろ薄く、役割は司令塔です。「UIを頼まれたら、まず検索スクリプトを叩いて、product typeに合ったデザインシステム（構造＋配色＋タイポ＋アンチパターン＋納品前チェック）を取得しろ」と指示する。たとえば銀行系なら"AIっぽい紫／ピンクのグラデ"をアンチパターンとして弾きます。

3階層で言えばL3をフル活用。データもスクリプトも、使うときだけ読む／実行する。さきほどの「バンドルしてもコストゼロ」のお手本のような実装です。

2つは同時に発動していい？

できます。公式もSkillの利点として「組み合わせて使う（compose）」を挙げていて、併用は想定内。両方のdescriptionが依頼にマッチすれば、両方の本文がコンテキストに載ります。

ここでノリさんの鋭い問い。「内容が真逆なら、2つ発動したらプラマイゼロで平凡にならない？」。答えは"ならない、でも自動で良くもならない"です。理由は、2つが同じ土俵で殴り合っていないから。

frontend-design＝概念・判断（この案件を固有にしろ、ありきたりを避けろ）＝メタな高度
ui-ux-pro-max＝ルール・知識（この業種はこの配色・この構造・この地雷）＝具体の低度

高度が違うので単純な足し引きにはなりません。ただし1点だけ本物の衝突があります。ui-ux-pro-maxは「業種の王道に寄せる」動き、frontend-designは「王道から外して固有にしろ」。"寄せる"と"外す"がぶつかる。対等な声で鵜呑みにさせると、平均化＝ぐずぐずになりかねません。

掛け合わせにするコツ：対等ではなく「順番と役割」

2つを同時に叫ばせず、パイプラインにします。

土台に ui-ux-pro-max ——業種に合う構造・アクセシビリティ・地雷リスト・配色/フォント候補を、速く正しく漏れなく出す
編集者に frontend-design ——その"正しいけど平凡"な土台を、この案件固有へ引き上げる（大胆さは一点に集中、残りは静かに、効かない装飾を削る）

データで完璧な下地を一瞬で作り、散文の判断で平均から引き剥がす。これで足し算ではなく掛け算になります。

核心：「良い」の定義が、実は2つで違う

ここが今回いちばんの発見でした。2つのSkillは"良い"の定義そのものが違うんです。

ui-ux-pro-maxの「良い」＝業種の期待に合う・使いやすい・既知のアンチパターンを踏まない（＝適切・安全・王道）
frontend-designの「良い」＝ありきたりでない・この案件固有・意図的・引き算が効く（＝独自・抑制）

同じ「良いデザイン」でも中身が別物。だから「2つ発動して良くなる？」は、実は**「どちらの"良い"を上位に置くか」という価値判断**の問いでした。

これはSkillの本質でもあります。Skillとは突き詰めると、「"良い"の定義＋それを実現する手順」を1フォルダに固めたもの。裏を返せば、Skillを作る第一歩はコードでもデータでもなく、「何を"良い"とするか」を決めることです。

そして、両方に空いている穴——日本語

最後にノリさんが指摘した点。この2つ、どちらも欧文前提で、日本語の文字組がすっぽり抜けています。

frontend-designの「1行80字以内」「セリフは行長を長めに」は欧文基準。日本語は全角の字詰め（目安35〜45字）で考えるし、イタリック強調やALL-CAPS回避は日本語にほぼ効かない
ui-ux-pro-maxの74フォントペアはGoogle Fonts中心＝ほぼ欧文。明朝/ゴシックの使い分けや日本語Webフォントのウェイト事情、和欧混植は射程外
両方に無い日本語固有の論点：禁則処理、約物のアキ、和欧混植、字詰め・行間、全角/半角の混在、（必要なら）縦書き

つまり——世界中で使われているデザインSkillにも、日本語という穴があります。次回の後編では、この穴を埋める「日本語WebデザインSkill」を実際に作ってみます。その第一歩は、さきほどの結論のとおり「日本語Webの"良い文字組"とは何か」を言語化するところから。

（後編へ続く）