はじめに
生成AIにHTMLやCSSを作らせると、短時間で画面を用意できます。しかし、何度か依頼しているうちに、次のような問題が起こりがちです。
- 画面ごとに配色や余白が少しずつ異なる
- とりあえず角丸カードを並べたデザインになる
- 紫系のグラデーションや絵文字が増える
- 既存サイトと異なるUIライブラリを勝手に使う
- 見た目は整っているが、キーボード操作やフォーカス表示が考慮されていない
- 修正するたびに別のデザインへ変わっていく
このような問題を減らす方法として、GitHubで公開されているClaude Design System PromptをCodexへ導入してみます。
この記事では、リポジトリの概要だけでなく、Codexへの導入方法、既存サイトへの適用方法、実際の指示例まで紹介します。
Claude Design System Promptとは
Claude Design System Promptは、AIに対して「コードを生成する人」ではなく「コードを道具として使うデザイナー」として振る舞うよう指示するシステムプロンプトと手順書のセットです。
名前にClaudeとありますが、リポジトリにはClaude版とCodex版が用意されています。ChatGPT、Gemini、ローカルLLMなど、システムプロンプトを設定できる環境でも考え方を利用できます。
ただし、これはAnthropic公式のリポジトリではありません。作者がClaude Designの挙動を分析して再構成した、非公式のリバースエンジニアリング版です。
また、完成済みの配色やコンポーネントを提供するデザインシステムでもありません。より正確には、AIに既存のデザインを調べさせ、デザインルールを守らせ、完成後に品質を確認させるための土台です。
主な内容
リポジトリは、主に次の要素で構成されています。
claude-design-system-prompt/
├── claude/
│ ├── system-prompt.md
│ └── skills/
├── codex/
│ ├── AGENTS.md
│ ├── system-prompt.md
│ └── skills/
├── README.md
└── LICENSE
system-prompt.mdには、次のような基本方針がまとめられています。
- 既存のブランド、CSS、コンポーネントを先に確認する
- 目的のない要素やダミーコンテンツを追加しない
- 配色、文字、余白に一貫した規則を持たせる
- CSS変数などのデザイントークンを利用する
- 再利用できるコンポーネントとして考える
- WCAG、セマンティックHTML、キーボード操作を確認する
- ホバー、フォーカス、無効、読み込み中などの状態を設計する
- AIが生成しがちなテンプレート的デザインを避ける
- 最後に実際の表示を確認する
skillsには、作業別の手順書が14種類用意されています。
| 分類 | 主なスキル | 内容 |
|---|---|---|
| 制作 | discovery-questions |
制作前に必要な情報を確認する |
| 制作 | wireframe |
ワイヤーフレームを複数案作る |
| 制作 | make-a-prototype |
操作可能なHTMLを作る |
| 制作 | generate-variations |
デザイン案を比較できる形で作る |
| 標準化 | design-system-extract |
既存サイトから色、文字、余白などを抽出する |
| 標準化 | component-extract |
再利用可能な部品を整理する |
| 検査 | accessibility-audit |
コントラスト、HTML構造、操作性を確認する |
| 検査 | ai-slop-check |
AI的なテンプレート表現を検出する |
| 検査 | hierarchy-rhythm-review |
情報の優先順位や余白を確認する |
| 検査 | interaction-states-pass |
操作状態とフィードバックを確認する |
| 検査 | polish-pass |
公開前の総合確認を行う |
Codexへの導入方法
1. リポジトリを取得する
まず、公開されているリポジトリを取得します。
git clone https://github.com/Trystan-SA/claude-design-system-prompt.git
対象プロジェクトへ移動し、Codex版のシステムプロンプトとスキルをコピーします。
cd 対象プロジェクト
mkdir -p design-ai
cp ../claude-design-system-prompt/codex/system-prompt.md design-ai/
cp -R ../claude-design-system-prompt/codex/skills design-ai/
導入後は、次のような構成になります。
対象プロジェクト/
├── AGENTS.md
├── design-ai/
│ ├── system-prompt.md
│ └── skills/
├── src/
└── README.md
2. AGENTS.mdから読み込ませる
Codexは、プロジェクト内のAGENTS.mdを作業前の指示として読み込みます。そこで、プロジェクト直下のAGENTS.mdへ次の内容を追加します。
# デザイン作業
HTML、CSS、JavaScript、画面、UIに関する作業を行う場合は、
作業前に `design-ai/system-prompt.md` を読むこと。
依頼内容が個別スキルに該当する場合は、
`design-ai/skills/` 内の該当ファイルを読み、その手順に従うこと。
# 既存デザインの維持
- 最初に既存のCSS、テンプレート、コンポーネント、画像を確認する
- 既存の配色、フォント、文字サイズ、余白、角丸、影を維持する
- 既存コンポーネントを優先して再利用する
- 不明点を推測で補わない
- 新しいUIライブラリを勝手に追加しない
- 変更後はPCとスマートフォンの表示を確認する
すでにAGENTS.mdがある場合は、リポジトリ付属のファイルで上書きせず、既存の指示へ追記します。
OpenAIの公式ドキュメントでも、Codexはプロジェクトルートから現在の作業ディレクトリまでAGENTS.mdを探索し、作業時の指示として読み込むと説明されています。
3. 新しいセッションで確認する
AGENTS.mdを追加した後は、Codexを新しいセッションで起動します。
読み込まれた指示を確認する場合は、次のように依頼します。
作業はまだ行わず、現在読み込んでいるプロジェクト指示と、
デザイン作業で参照するファイルを要約してください。
Codex CLIでは、次のような確認もできます。
codex --ask-for-approval never "現在読み込んでいるプロジェクト指示を要約してください"
最初に既存デザインを抽出する
既存サイトへ導入する場合、いきなり画面を変更させるのではなく、最初に現在のデザインを分析させます。
このプロジェクトの既存デザインを調査してください。
最初に以下を読んでください。
- AGENTS.md
- design-ai/system-prompt.md
- design-ai/skills/design-system-extract.md
既存のCSS、テンプレート、コンポーネント、画像を確認し、
次の項目を整理してください。
- ブランドカラー
- 背景色と文字色
- フォント
- 文字サイズ
- 余白の規則
- 角丸
- 影
- ボタン
- 入力欄
- カード
- ヘッダー
- レスポンシブ仕様
今回は調査のみとし、既存ファイルは変更しないでください。
現在の仕様、不統一箇所、標準化の提案を分けて報告してください。
不明な値を推測で補わないでください。
調査結果を確認した後、必要に応じてtokens.cssや既存形式に合わせたトークンファイルを作成します。
先ほどの調査結果をもとに、既存デザインを大きく変えず、
色、文字、余白、角丸、影をデザイントークンとして整理してください。
既存のCSS構成と命名規則に合わせてください。
新しい色やフォントを勝手に追加しないでください。
作成後、どの画面へどの順番で適用するか提案してください。
この段階では既存画面への一括適用は行わないでください。
新しい画面を作るときの指示例
例えば、地名を入力して地図へ表示する検索画面を追加する場合は、次のように指示できます。
自由入力した地名を検索し、該当する位置を地図に表示する画面を作成してください。
作業前に以下を読んでください。
- AGENTS.md
- design-ai/system-prompt.md
- design-ai/skills/make-a-prototype.md
既存の画面、CSS、テンプレート、地図設定を確認し、
現在のデザインに合わせてください。
要件:
- 地名を自由入力できる
- 検索候補を表示する
- 候補を選択すると地図を移動する
- 該当地点にマーカーを表示する
- 結果がない場合は具体的なメッセージを表示する
- スマートフォンに対応する
- キーボードだけでも操作できる
禁止事項:
- 新しいUIライブラリを追加しない
- 既存の地図操作を壊さない
- 存在しない地名データを作らない
- 既存画面と異なるデザインにしない
最初に実装方針と変更対象ファイルを提示し、
その後に実装してください。
完了後は実際に画面を表示して確認してください。
ポイントは、作ってほしい機能だけでなく、維持するもの、禁止するもの、完了条件も指定することです。
複数のデザイン案を比較する
いきなり本番コードへ実装せず、複数案を比較したい場合はgenerate-variationsを利用します。
既存デザインを維持したまま、検索部分について3案作成してください。
design-ai/skills/generate-variations.mdに従ってください。
変更する軸:
- 検索欄の配置
- 検索候補の表示方法
- 地図との位置関係
変更しないもの:
- ブランドカラー
- フォント
- ヘッダー
- 地図の基本デザイン
- 既存機能
各案について、利点、欠点、スマートフォンでの使いやすさを説明してください。
この段階では本番コードを変更しないでください。
「雰囲気を変えた3案」ではなく、何を変えて何を維持するかを明示すると比較しやすくなります。
デザインレビューだけを行う
リポジトリに含まれる検査スキルは、通常は問題を見つけた後に修正まで行います。診断だけを依頼する場合は、「変更しない」と明記します。
現在の画面をデザインレビューしてください。
以下を順番に確認してください。
- design-ai/skills/accessibility-audit.md
- design-ai/skills/ai-slop-check.md
- design-ai/skills/hierarchy-rhythm-review.md
- design-ai/skills/interaction-states-pass.md
今回は診断のみとし、ファイルは変更しないでください。
問題を次の順に整理してください。
1. 対応必須
2. 対応推奨
3. 好みの範囲
各問題について、対象箇所、理由、修正案を示してください。
公開前の最終確認
実装が完了したら、polish-passで総合確認します。
この画面を公開前の最終確認としてレビューしてください。
design-ai/skills/polish-pass.mdに従い、以下を確認してください。
- アクセシビリティ
- AI生成らしいテンプレート表現
- 情報の優先順位
- 文字と余白の規則
- ホバー、フォーカス、無効、読み込み中の状態
- PC、タブレット、スマートフォン表示
問題をすべて確認してから修正してください。
既存機能や文言は変更しないでください。
修正後、もう一度画面を表示して確認してください。
サイト固有のルールも用意する
公開されているプロンプトだけでは、自社サイト固有のデザインまでは決まりません。プロジェクト内にdesign-ai/project-design.mdを追加し、サイト固有のルールを記述すると安定します。
# プロジェクト固有のデザインルール
# 目的
地名を探し、地図上で位置を確認できる、落ち着いた地理情報サービスとする。
# 維持するもの
- 既存テンプレートエンジン
- 既存の地図ライブラリと操作方法
- ヘッダーとナビゲーション
- 現在のブランドカラー
- 既存のカテゴリ表現
# 禁止事項
- フレームワークを勝手に変更しない
- UIライブラリを新規導入しない
- 地図より目立つ装飾を追加しない
- SaaS管理画面のようなカード中心の構成にしない
- 存在しない説明文や統計情報を追加しない
# 確認項目
- 地図の表示領域が十分に確保されている
- スマートフォンでも検索できる
- 検索結果をキーボードで選択できる
- 検索結果と地図上の位置が対応している
AGENTS.mdからこのファイルも読むように指定します。
デザイン作業では、プロジェクト固有のルールとして
`design-ai/project-design.md`も読むこと。
共通の品質基準とプロジェクト固有のルールを分けることで、複数サービスに同じデザインを押し付けずに、品質だけを共通化できます。
導入時の注意点
質問が多くなる場合がある
元のCodex版プロンプトには、曖昧な依頼では複数の質問をするルールがあります。大規模な新規制作には有効ですが、小さな修正では煩雑になる場合があります。
その場合は、AGENTS.mdへ次のルールを追加します。
要件が明確な場合や既存画面の小さな修正では質問を省略する。
実装結果を大きく左右する不明点だけを質問する。
プロンプトだけで完全には統一できない
デザインの一貫性を保つには、プロンプトに加えて次の仕組みも必要です。
- CSS変数やデザイントークン
- 再利用可能なコンポーネント
- lintやテスト
- スクリーンショットによる確認
- 人間による最終判断
プロンプトは判断を助けるものですが、コード上の強制力までは持ちません。
既存デザインを無視させない
「おしゃれにしてください」だけでは、AIが新しい配色や構成を作り始める可能性があります。
次の4点を明示することが重要です。
- 最初に確認するファイル
- 変更してよい範囲
- 維持するもの
- 完了条件
まとめ
Claude Design System Promptは、HTMLをきれいに生成するためだけのプロンプトではありません。
その価値は、AIのデザイン作業を次の流れに整えられる点にあります。
既存デザインを確認する
→ ルールを抽出する
→ 複数案を比較する
→ 既存ルールに沿って実装する
→ アクセシビリティと品質を検査する
→ 実際の表示を再確認する
特に複数の画面を継続的に追加するプロジェクトでは、毎回プロンプトを貼り付けるより、AGENTS.mdから共通ルールを参照させる方が安定します。
まずは一つのプロジェクトへ導入し、小さな画面で試しながら、自分たちのブランドや開発ルールに合わせて調整していくのがよいでしょう。