私がこれまで個人プロジェクトを作るときは、機能よりもデザインに割く時間が多くなりがちでした。
自分しか使わないものだから見た目にはこだわらないつもりで作り始めても、毎日自分の目に入るとなると、納得できるまで何度も触ってしまいます。
そこへ使いやすさまで考え始めると、ボタンや情報をどこへ置くか、余白をどれくらい取るかといった検討にも相当な時間がかかります。
かといって、どこかで見つけたテンプレートをそのまま使うと、ほかのサイトと同じに見えるのが気になります。
今はAIにデザインを作ってもらえる時代です。
ただ、AIが生成した画面も、内容が違うのに似たデザインへ寄りやすいという話を目にします。
そこで試してみたのが、Claude Design System Promptです。
今回は、このブログ「試してから書く」を題材に、ClaudeとCodexで各3案、合計6案を作りました。
一度の実行で唯一の正解が出る道具ではありませんが、デザイン検討の工程をかなり堅くできました。
実際の記事と制約を固定したため、どの案もブログの雰囲気を大きく壊さず、長文の読みやすさや検証状態の見せ方まで扱えました。
一方、6案はモデルが違っても似た3系統へ収束しました。
最終的な差を作ったのは、生成後に自分で「この一覧は好き」「この連番は要らない」「目次は左右で比べたい」と要素ごとに判断した工程です。
この記事は個人開発者だけでなく、Claude CodeやCodexを使ってWebサイトや社内ツールのUIを検討したいデザイナー、エンジニア、開発チームにも向けて書いています。
私が今回試したこと
実験の題材には、上述した通りこのブログを使いました。
ゼロから架空のページを作るのではなく、現在の色、書体、記事一覧、長い日本語本文、検証記録を残したまま改善できるかを試しています。
比較条件をそろえるため、ClaudeとCodexには同じ読者、同じ文章、同じ制約、同じ採点表を渡しました。
出力先はブログ本体から分離し、良さそうな案が出ても自動では反映されないようにしています。
Claudeでは次の1行だけを実行しました。
/design-bakeoff/design-bakeoffはClaude Design System Promptに用意されているコマンドではありません。
今回の実験用に私が用意した、プロジェクト専用のSkillです。Claude Design System Promptを、このブログの実装と検証条件に接続するための進行役として作りました。
このリポジトリは何を目的としているのか
固定commitのREADMEで、リポジトリ作者は目的を次のように説明しています。
A system prompt and skill library that turns an LLM into an opinionated, accessibility-aware, AI-slop-resistant design collaborator.
（訳）LLMを、判断基準を持ち、アクセシビリティへ配慮し、AIらしい安易なデザインに抗う協働相手へ変えるsystem promptとSkill集。
Claude Design System Promptのsystem-prompt.mdは、1つの長いプロンプトをChapter 1からChapter 20までに分けた構成です。
前半では、AIの役割、作業の進め方、着手前の質問、既存文脈の読み方を定めています。
中盤では、コンテンツ、見た目、情報階層、書体、色、アクセシビリティ、操作状態、コンポーネント設計を扱います。
後半では、出力方法、共同作業、知的財産、利用できるSkillを定めています。
別に用意された14個のSkillは、実作業の手順書です。
今回使ったものには、既存サイトからデザイントークンを抽出するdesign-system-extract、複数案を作るgenerate-variations、アクセシビリティを確認するaccessibility-audit、AIにありがちな表現を点検するai-slop-checkなどがあります。
20章のsystem promptが「何を良いデザインと考えるか」を担当し、14個のSkillが「どう作り、どう確認するか」を担当します。
Claude向けとCodex向けが分かれており、Codex版は同じ考え方を単一ループの順次レビューへ合わせています。
なお、これはAnthropicの公式配布物ではありません。作者がClaude Designのsystem promptをリバースエンジニアリングしたと説明している、第三者のOSSです。
/design-bakeoffを実行すると何が起きるのか
/design-bakeoffを実行すると、Claudeは.claude/skills/design-bakeoff/SKILL.mdを読み、そこに書かれた順番で作業します。私がMarkdownファイルを1枚ずつチャットへ添付したわけではありません。SkillがClaudeへ、次のファイルをプロジェクトから自動で読むよう指示しています。
README.md――実験の目的と変更してよい範囲BRIEF.md――読者、ブランド、改善したい問題、必須ページ、技術制約CONTENT.json――3案で共通利用する記事タイトル、説明、本文、検証記録RUBRIC.md――ブランド、情報階層、可読性、アクセシビリティなどの採点表- 現在のAstro実装のうち、比較に必要なファイル
- 固定したcommitのClaude Design System Promptと、必要な上流Skill
今回使った手順を別のプロジェクトでも試せるように整理した、コピペ用テンプレートを置いておきます。
導入手順と4つの入力ファイルの役割も同じページにまとめました。制作フローに関わる中核部分を短くすると、次の内容です。
## 最初に読む
README.md → BRIEF.md → RUBRIC.md → CONTENT.json → 現行実装
## ユーザー聞き取りゲート
HTML/CSSを書く前に、好きな点・変えたい点・残したいブランド要素・
改善の優先順位・大胆な変更の許容範囲を質問する。
## 方向性ゲート
コードを書く前に方向性を3案提示し、
A／B／C／組み合わせ／修正の選択を待つ。
## プロトタイプ制作
同じコンテンツを使い、一覧ページと記事ページを含む3案を作る。
1440pxと390px、semantic HTML、focus、コントラストを確認する。
## 評価
現行版と3案を同じRUBRICで評価し、悪化点と実装リスクも残す。このSkillが、プロジェクト固有の入力とClaude Design System Promptをつなぎ、3案の作成から自分のレビューまでを進行します。
再現するために用意するもの
今回の構成を簡略化すると、次のようになります。
tested-notes/
├── .claude/skills/design-bakeoff/SKILL.md
└── design-experiments/claude-design-system/
├── README.md
├── BRIEF.md
├── CONTENT.json
├── RUBRIC.md
└── claude/SKILL.mdには、読むファイルの順番、参照する上流commit、使う上流Skill、変更可能な出力先、質問、方向性承認、3案作成、評価、完了条件を書きます。
実行手順は次のとおりです。
- 対象プロジェクトをClaude Codeで開きます
/design-bakeoffを実行します- 固定した上流GitHubのプロンプトとSkillを読む許可を出します
- 現行デザインと希望についての質問に答えます
- コード作成前に提示される方向性を選ぶか、組み合わせ、修正を伝えます
- 生成された3案をブラウザで見て、採用、合成、修正、全案不採用を判断します
私はClaudeのモデルとしてOpus 4.8を選びました。
上流READMEによると、Claude版はOpus 4.7／4.8系など新しい上位モデル向けに調整されています。
Opus／Sonnet 4.6以前では質問やレビューが発動しにくい場合があり、指示を強める必要があるとのことです。今回はモデル間の比較までは行っていません。
実行時に自分で決められる条件
条件は、生成前にファイルへ固定するものと、対話しながら決めるものを分けると整理しやすくなります。
| 段階 | 決める内容 | 今回の指定例 |
|---|---|---|
| 実行前 | 読者とサイトの目的 | 海外のAI・開発ツールを、実機検証と失敗ログつきで伝える |
| 実行前 | 変えてよい範囲 | 実験ディレクトリのみ。ブログ本体、依存、外部フォントは変更禁止 |
| 実行前 | 必須ページと実コンテンツ | 一覧、記事、結論、検証記録、目次、コード、参考情報源 |
| 実行前 | ブランド資産 | 生成りの紙面、墨、朱の検印、藍のリンク、等幅メタ情報 |
| 実行前 | 技術・表示条件 | Astroへ移植可能、JavaScriptなしでも読める、1440pxと390px |
| 実行前 | 評価基準 | ブランド20、情報階層20、可読性20、アクセシビリティ20、実装性10、AIスロップ耐性10 |
| 実行中 | 現行の好き嫌い | 落ち着きは残し、記事一覧と目次を改善する |
| 実行中 | 目指す印象 | 派手ではなく、編集紙面のように具体的で信頼できる |
| 実行中 | 改善の優先順位 | 一覧での選びやすさ、長文可読性、ブログの個性 |
| 実行中 | 変更の大胆さ | 現行に近い案と、構造から変える案の両方を出す |
| 生成後 | 採否と組み合わせ | Bの一覧、Cの説明と見出し、結論先出し、検証記録→目次の順 |
特に効いたのはCONTENT.jsonです。
ダミーの英語LPではなく、実際の記事タイトル、長い日本語description、検証状態、本文、コードを3案で固定しました。
これがないと、デザインの差と文章量の差が混ざり、比較しにくくなります。
今回のSkillには、生成物を実験ディレクトリだけへ書き出すよう指定しました。
そのため、案を生成しただけでブログ本体のデザインが変わることはありません。
ClaudeとCodexの6案はどうなったか
Claude側は次の3案になりました。
| 案 | 方向性 | 主な特徴 |
|---|---|---|
| A | 現行踏襲・磨き込み | 静かな紙面を維持し、focusや検証状態を改善 |
| B | 検証台帳・構造再考 | 日付と検証状態を一覧のレールにし、記事は右側に常駐目次 |
| C | 静かなeditorial | サイト説明と明朝見出しを強め、記事は左側に常駐目次 |
生成された6案を画像で比較
一覧の左列がClaude、右列がCodexです。A、B、Cを同じ行で見比べられます。各サムネイル内では左側がトップページ、右側が記事ページです。クリックすると拡大して確認できます。
Codexでは、同じ固定ファイルと上流SkillのCodex版を使ったところ、ほぼ同じ3系統が出力されました。
ClaudeとCodexが偶然同じ発想をしたのではなく、指示内容と比較条件をはっきり揃えたために一致したものと考えています。
ただCodexは、Claude案と私の感想を見た後に実行しているため、モデルだけの差を比べるブラインド比較ではありません。
個人でも企業でも使えますが、確認工程は必要です
このリポジトリはMITライセンスで、作者は商用利用、改変、配布が可能だと明記しています。
そのため、個人開発者だけを対象にしたものではありません。
企業のWebサイト、社内ツール、デザインシステムの検討にも利用できます。
企業で利用する場合は、法務、セキュリティ、品質を組織のルールに沿って確認する必要があります。
Claude Design System Promptには知的財産やアクセシビリティを扱う章がありますが、それ自体がこれらを保証するわけではありません。
私は今回、3案の内容をそれぞれ確認し、トップページは1案に統合し、記事ページだけ「左レール」「右レール」を作って、目次の位置だけを比較できる状態にしました。
本体と出力先を分け、人が採用範囲を決めてから移植する手順は、レビュー担当者が多いチームでも使いやすいはずです。
一方、「おまかせで完成デザインを1つ出してほしい」という用途には向きません。
今回の成果物もHTML/CSSのプロトタイプであり、Figmaデータが直接できるわけではありません。
まとめ
- Claude Design System Promptは、1つのsystem promptを20章に分け、別に14個の手続き型Skillを用意した第三者OSSです
- 今回は3つの長文プロンプトを手で流したのではなく、
/design-bakeoffから固定ファイルとgenerate-variationsを読み込ませました - ClaudeとCodexの各3案は、現行改善、右レール、明朝と左レールの似た3系統へ収束しました
- 最終的な価値は一発生成ではなく、自分で候補を比較し、よい要素を組み合わせ、未決定箇所だけを再比較できることにありました
使ってみて、AIとのデザイン会議に共通言語とレビュー手順を持ち込む道具だと感じました。
私のように、個人プロジェクトのデザインをいつまでも触り続けてしまう人にとっては、考える順番と決めるタイミングを区切ってくれるだけでも大きな助けになります。