「Claude Skill解説」シリーズ
- 前編：Skillとは何か／frontend-design と ui-ux-pro-max の解剖（https://qiita.com/norizou4/items/0f825bb389d41de4da1b）
- 中編：日本語Webデザインの「良い」を業種別に数値化する（この記事）
- 後編：自作Skillの公開と、実案件での検証（https://qiita.com/norizou4/items/d56186216ef6907bec46）
前編では、Claude Skillの仕組み（段階的開示の3階層）と、frontend-design（散文型）・ui-ux-pro-max（データ型）という2つの実例を解剖しました。この中編では、その延長でノリさんと一緒に「日本語Webデザイン向けの自作Skill」の土台になるデータを組み立てていった過程をまとめます。結論から言うと、今回一番時間を使ったのはコードを書くことではなく、Skillの土台になるデータをどう作るかでした。実際にSkillを組み上げてGitHubに公開するところは、後編に持ち越します。
SKILLは指示書、指示書の解像度がアウトプットを決める
Skillとはつまるところ「指示書」です。そして指示書の解像度が高いほど、AIが出してくるアウトプットの質も上がります。これは今回のプロジェクトの出発点になった考え方で、ノリさんの言葉を借りるとこうなります。
AIとのコミュニケーションでクリエイティブをさせる場合、一番重要なのはクリエイティブが持っている抽象的なセンスをどこまで解像度高く言語化できるかである。しかし、それが人間が共感できる抽象度の高い詩的な文章ではなく、具体的な言い回しー できれば数値的な指標で伝えられるかが重要。
「上品なデザインにして」と指示しても、AIは学習データの中にある一番"それっぽい"パターン、つまり平均的でどこかで見たことのあるようなデザインに寄っていきます。これがいわゆる「AIっぽさ」の正体の一つです。この抽象的な"センス"を、数値や実例という具体的な言い回しに変換できれば、指示書の解像度は上がるはずだ、というのが今回の仮説でした。
そのために、実在する「良いデザイン」を集めたギャラリーサイトを2つ選び、そこに登録されているサイトのデータを業種別・タイプ別に集計する、というアプローチを取りました。
Skillが「うまくいった」をどう判断するか
データの話に入る前に、そもそも今回作ろうとしているSkillが「うまくいっているかどうか」をどう判断するか、という前提の話をしておきます。通常のプログラミングなら、コードを書いて実行し、期待通りの結果になればOKです。しかしデザインは正解が一つに決まらないので、同じようには判断できません。
今回は次の3段階で考えることにしました。
- ルールチェック：禁則処理や配色コントラストなど、機械的に「守れているか/いないか」を判定できる項目
- ルーブリック採点：業種にふさわしいトーンになっているか、LLM自身に採点させる（LLM-as-judge）
- A/Bテスト：Skillを使った場合と使わない場合の出力を比較し、狙った方向に寄っているかを見る
完璧な自動採点は望めませんが、この3層があれば「なんとなく良さそう」で終わらせず、ある程度の検証可能性を持たせられます。
参照したデータソースについて
今回のデータ基盤は、日本人が運営する2つのWebデザインギャラリーサイトを分析して作りました。データの出所を明確にしておきます。
- choooodoii.com — バランスの取れた、着実に実装された一般的な良質サイトを集めたギャラリー
- 81-web.com — 大胆なレイアウトや実験的な表現に振ったサイトを集めたギャラリー
両サイトとも、個別記事のサムネイル画像や紹介文をそのまま転載することはしていません。取得したのは、それぞれのサイトが自ら付与している分類ラベル（業種・サイトタイプ・トーン・配色・フォントなど）と、その集計値です。choooodoiiについてはWordPressの公開REST API（design/toneなどの公式タクソノミー）を、81-webについてはサイト内の検索機能が呼んでいる内部APIエンドポイント（/api/toppage_v2）を、それぞれ通常のブラウジングと同程度の頻度で呼び出して取得しました。どちらのサイトもrobots.txtを確認しましたが、この用途を明示的に制限する記述はありませんでした。
集計・分析目的でのこうした利用は、著作権法30条の4（情報解析のための利用）の範囲内だと理解していますが、もし両サイトの運営者の方でご懸念があれば、記事末尾の連絡先までご一報いただければ対応いたします。
choooodoiiで母集団まるごとの統計を取る
最初はサンプル調査を考えていました。20サイトほど手動でピックアップして、業種ごとの色・フォント・角丸・動画の有無をブラウザで実測する、という方法です。実際にこの20サイトのパイロット調査はやってみました。
やってみて気づいたのは、choooodoii.comがWordPressで構築されていて、しかもdesign（13種類）・tone（12種類）という制御語彙のタクソノミーを公式に持っていたことです。個別記事の「サイトイメージ」スライダー（落ち着き↔活気、穏やか↔荒々しいなど）は投稿ごとに軸のラベルが違う自由記述に近いものでしたが、この公式タクソノミーは固定語彙なので、サンプリングをする必要すらありませんでした。REST APIをper_pageとpageでページネーションしながら全件（2,080件）取得すれば、母集団そのものの統計が手に入ります。
GET /wp-json/wp/v2/posts?design={id}&per_page=100&page=1
このアプローチに切り替えたことで、「業種×デザインキーワードの出現率」を全数で出せるようになりました。一部を抜粋します。
| 業種 | n | シンプル% | 上品% | かっこいい% | ポップ% | 高級・リッチ% |
|---|---|---|---|---|---|---|
| 美容 | 121 | 32.2 | 49.6 | 13.2 | 1.7 | 8.3 |
| ウェディング | 26 | 23.1 | 76.9 | 7.7 | 0 | 46.2 |
| 不動産・建築・空間・施設 | 162 | 38.9 | 17.3 | 24.1 | 16 | 4.9 |
| アート | 42 | 28.6 | 33.3 | 28.6 | 14.3 | 11.9 |
| 暮らし商品・サービス | 155 | 43.2 | 25.2 | 7.1 | 20.6 | 7.1 |
| IT・システム | 142 | 39.4 | 5.6 | 30.3 | 16.9 | 0 |
ウェディングの「上品76.9%・高級リッチ46.2%」や、IT・システムの「高級リッチ0%・かっこいい30.3%」のように、業種ごとのキャラクターがくっきり数値に出ます。これはまさに「抽象的なセンスの数値化」そのものでした。
タクソノミーの設計：81-webの26分類ではなくchoooodoiiの25分類に統一する
当初は81-web.com由来の26分類（業種）・7分類（タイプ）のリストを使う想定でしたが、choooodoiiの公式カテゴリ分類（業種25種）の方が実データに裏付けられているため、こちらに一本化しました。またサイトタイプは、choooodoiiの13分類のうち「記念サイト」「特設サイト」「企画・プロモーション」「キャンペーン」「エンタメ公式サイト」を「特設・キャンペーンサイト」に統合し、9分類に整理しました（ポートフォリオは個人依頼のデザイン要件として独立して残しています）。
| 新タイプ名 | n |
|---|---|
| コーポレートサイト | 721 |
| 商品・製品紹介 | 564 |
| 店舗・施設紹介 | 535 |
| サービス紹介 | 390 |
| 特設・キャンペーンサイト | 269 |
| EC・WEBサービス | 205 |
| メディア・ポータル | 100 |
| 採用サイト | 90 |
| ポートフォリオ | 27 |
業種25分類×タイプ9分類で、最大225通りのマスができる計算です。全部が埋まるわけではありませんが、このマス目がSkillのデータ型部分の骨格になります。
81-webを追加した理由：「ちょうど良すぎる」問題
choooodoiiのデータだけで一区切りついたところで、ノリさんから「choooodoiiは本当にちょうどいいんですが、ちょうど良すぎちゃう」という指摘がありました。母集団統計は信頼できる基準にはなるものの、それだけを基準にSkillを作ると、出力が"平均的で無難"な方向に寄ってしまう。これはまさに「AIっぽさ」を助長しかねないリスクです。そこで、大胆なレイアウトに振ったサイトを集めている81-web.comを追加で分析し、同じ業種の中に「moderate（choooodoii）↔ bold（81-web）」という2点のグラデーションを持たせることにしました。
81-webはWordPressではなくNuxt.js製のSPAで、公開APIはありません。ですが、サイト内のカテゴリ絞り込みフィルターを操作したときにブラウザが叩いているリクエストをfetchをモンキーパッチして観察したところ、/api/toppage_v2という内部APIが素直にJSONを返してくれることがわかりました。
GET /api/toppage_v2?paged=1&tax_query[1][taxonomy]=category&tax_query[1][field]=slug&tax_query[1][terms]=cosmetic-beauty&tax_query[1][operator]=IN
このエンドポイントを使って、choooodoiiの6業種（不動産・建築・空間・施設／ウェディング／暮らし商品・サービス／アート／美容／IT・システム）に対応する81-webのカテゴリを1,401件取得しました。81-webには「シンプル/上品/にぎやか」のようなchoooodoiiと同じ語彙のタグはないので、代わりに配色（黒率・カラフル率）、動き系タグ（アニメーション・スクロールアニメーション・Movie等）の保有率、キャンペーン・特設型サイトの比率を"大胆さ"の代理指標として使いました。
| 業種 | choooodoii シンプル% | choooodoii 上品% | 81-web 黒率% | 81-web 動きtag保有率% |
|---|---|---|---|---|
| 美容 | 32.2 | 49.6 | 18.4 | 39.0 |
| 不動産・建築・空間・施設 | 38.9 | 17.3 | 13.9 | 42.0 |
| 暮らし商品・サービス | 43.2 | 25.2 | 13.9 | 38.0 |
| アート | 28.6 | 33.3 | 26.5 | 40.9 |
| ウェディング | 23.1 | 76.9 | 31.0 | 31.0 |
| IT・システム | 39.4 | 5.6 | 12.4 | 53.6 |
同じ業種でも、choooodoii側の「上品・堅実」な印象と、81-web側の「黒基調・動き多め」な傾向は、はっきり違う顔を見せます。IT・システムは動きtag保有率が53.6%と全業種中最も高く、他は白基調中心のサイトでも、モーションで差別化する傾向が強いことが読み取れます。
CSS実測でウラを取る：18サイトの色・フォント調査
分類ラベルと集計％だけでは「実際どんな色番号・どんなフォント名を使っているのか」までは分かりません。そこで6業種から代表サイトを3件ずつ、計18サイトを選び、実際にブラウザで開いてgetComputedStyleで背景色・文字色・フォント・ボタンの角丸・動画やCanvasの有無を実測しました。
面白かった発見をいくつか挙げます。
-
ウェディング：神社（城山熊野神社）とブライダルサロン（sumire）の2サイトが、
fot-tsukuaoldmin-pr6nやShippori Minchoといった明朝体系フォントを使用。choooodoiiの「上品76.9%」という数値と符合する、和風・伝統的な実装でした。 -
不動産・建築・空間・施設：伝統工芸ブランドのサイトが背景
#0A0801・文字#D9D7D4というダークトーン。choooodoiiのデータに多い明るく親しみやすい配色とは対照的でした。 -
暮らし商品・サービス／アート：
neue-haas-grotesk-textやhelvetica-neue-lt-proのような有償の欧文フォントを使うサイトが目立ち、和文ゴシック一辺倒ではなく海外ブランド的な質感を狙っている実例が確認できました。
この実測データが、集計％と実際のCSS値をつなぐ"翻訳表"になります。
データ型はui-ux-pro-maxとは違う設計になった
ここまで作ったデータを、前編で紹介したui-ux-pro-maxのデータ型と比べてみます。ui-ux-pro-maxの中核はui-reasoning.csvという1本のCSVで、192行（業種×プロダクト形態の組み合わせ）、各行にRecommended_Pattern・Style_Priority・Color_Mood・Decision_Rulesのような列があります。ただしこれらは実サイトの計測値ではなく、「この業種ならこう作るべき」というデザイナーが手でキュレーションした処方箋です。Color_Mood列は"Trust blue"のようなムードの言葉で、実際のhexコードは別のスタイルカタログを参照する設計になっています。検索はsearch.pyがクエリとUI_Categoryなどの自由記述テキストをBM25（検索エンジンで使われるランキングアルゴリズムの一種）でマッチさせて、最も近い行を引いてくる仕組みでした。
今回作ったデータは、これとは逆で実測・統計データです。しかも同じ業種の中にchoooodoii（moderate）と81-web（bold）という2つの参照点を持てるのが大きな違いです。ui-ux-pro-maxは1業種につき1つの答えしか持っていませんが、こちらは「どのくらい大胆にするか」というダイアルを、実データで挟み込めます（ちなみにui-ux-pro-max自体にも--varianceという1〜10のダイアルが実装されていて、方向性としては近いことに後で気づきました）。
もう一つの違いは検索方式です。ui-ux-pro-maxがBM25のような検索アルゴリズムを必要としたのは、自由記述のクエリと緩いカテゴリ名を突き合わせる必要があったからです。今回のデータは業種25分類×タイプ9分類という固定の制御語彙で作ってあるので、ユーザーのブリーフをどのマスに当てはめるかはClaude自身が文脈から直接判断でき、検索アルゴリズムを挟まずCSVを直接フィルタするだけで足ります。緩いカテゴリを大量に持つより、固定タクソノミーで作った方がむしろシンプルに済む、というのは想定していなかった発見でした。
ここまでで見えてきたこと
「Skillは指示書であり、指示書の解像度がアウトプットを決める」という前提から出発し、その解像度を上げるために実在する"良いデザイン"を数値化する、というアプローチを取りました。できあがったのは、業種25分類×タイプ9分類のマス目に、choooodoii（母集団2,080件の統計）と81-web（1,401件の統計＋18サイトのCSS実測）という2つの参照点を埋め込んだデータセットです。
後編では、このデータを実際にSkillのデータ型部分（CSVフィルタ＋Claudeによる業種判定）として組み込み、frontend-designのような散文型の原則パートと合流させて、SKILL.mdとして完成させます。完成したSkillはGitHubで公開する予定なので、そこまでを後編でまとめます。
※本記事は choooodoii.com、81-web.com の各サイトを分析対象として参照しています。両サイトの運営者の方でこの記事の内容についてご懸念やご要望がありましたら、コメント欄またはXでご連絡ください。対応いたします。