AIにUIを作らせると、なぜか「どこかで見たことのある、けばけばしい画面」になりがちです。その悩みに正面から効くのが、本記事で解説する claude-design-system-prompt です。過剰なグラデーション、絵文字だらけの装飾、角丸に左ボーダーを添えたカード、そしてどの画面もInterフォント一色——。こうした「AI slop（AIが吐き出す安っぽい汎用デザイン）」は、パッと見は整っていても、意図もアクセシビリティも欠けています。
claude-design-system-prompt は、このAI slop問題に正面から取り組むオープンソースです。Anthropicのデザインツールのシステムプロンプトをリバースエンジニアリングしたものとされ、LLMを「意見を持ち・アクセシビリティに配慮し・AI slopに抗う」デザイン協働者に変える、システムプロンプトとスキルライブラリの一式です。MITライセンスで、Claude・GPT・Gemini・ローカルモデルなど、システムプロンプトをサポートするあらゆるLLMに貼り込めます。本記事では、この claude-design-system-prompt が何を退け・何を注入するのか、20章のデザイン哲学と14の手続き的スキル、そして最新モデル向けの調整までを、公式リポジトリの一次情報から解説します。
UI生成・デザインの全体像は デザインシステム構築ガイド：トークン設計からコンポーネント運用まで をご覧ください。
- ・claude-design-system-promptは、LLMを「AI slopに抗うデザイン協働者」に変えるシステムプロンプト＋スキル集（MIT）。
- ・退けるのは汎用SaaSテンプレ調（過剰グラデ・絵文字装飾・Inter一色など）。注入するのは20章のデザイン哲学。
- ・制作・抽出・レビューの14の手続き的スキルを鎖状につないで、探索→試作→仕上げを回す。
- ・最新フロンティアモデル向けに調整（ノルマでなく条件で指示・ハウススタイル対策）。どのLLMにも貼れる。
1. claude-design-system-prompt とは — 「Claude Design」の逆算
Trystan-SA/claude-design-system-prompt は、その名のとおり Anthropicのデザインツールのシステムプロンプトをリバースエンジニアリングした とされる、システムプロンプト＋スキルライブラリです。狙いはシンプルで、LLMを「意見を持つ、アクセシビリティに配慮する、AI slopに抗う」デザイン協働者に変えること。MITライセンスで公開されています。
使い方は2通りです。一つは、system-prompt.md（20章のメインプロンプト）をそのまま任意のLLMのシステムプロンプトとして貼り込む方法。エージェントはこのデザイン哲学に従い、タスクが該当するときは名前でスキルを参照します。もう一つは、skills/ にある14の手続き的スキルを、必要に応じて組み合わせて使う方法です。前者は「常時オン」の土台として、後者は「オンデマンド」の手順として機能し、両者は排他ではありません。システムプロンプトで全体の方針を固めつつ、個別のタスクではスキルが呼ばれて具体的な手順を提供する——この二層構造が、一貫した方針と柔軟な進行を両立させています。
。ここが「きれいに作って」という漠然とした指示との決定的な違いです。何を良しとし、何を避けるのか——その判断のよりどころを、20章の哲学と14の手順として言語化し、LLMに一貫して適用させます。
リポジトリの構成は明快です。claude/ ディレクトリにClaude Code／Claude.ai向けのバリアント（system-prompt.md と14スキル）、codex/ ディレクトリにOpenAI Codex向けのバリアント（AGENTS.md で自動検出され、サブエージェントを使わない単一ループ・逐次レビュー版）が入っています。同じ哲学を、ツールの特性に合わせて2系統で提供しているわけです。Claudeバリアントが並列のサブエージェント（レビュー役を別途走らせる）を前提にするのに対し、Codexバリアントは単一ループの中で逐次的にレビューを回す——エージェントのアーキテクチャの違いに合わせて、同じ思想の実装を作り分けている点は、移植性を考えるうえでの好例です。
ここで「リバースエンジニアリング」という言葉に補足しておくと、これはAnthropicの公式配布物ではなく、Claude.aiのデザインツールが示す挙動から、その背後にあるであろうシステムプロンプトを推定・再構成したもの、という位置づけです。したがって内容はコミュニティによる再現であり、公式仕様そのものではありません。ただ、実際に貼り込んで動かせる形で公開されている以上、「良いデザイン出力を引き出すプロンプトとはどういうものか」を学び、自分の用途に合わせて改変するための、極めて実践的な教材になっています。MITライセンスなので、丸ごと使うのも、一部だけ抜き出して自分のCLAUDE.mdに混ぜるのも自由です。
読者が当サイトのOSS解説に求める「①結局何ができる／②何を解決する／③何を代替できる」に当てはめれば、これは「①LLMを一貫した基準を持つデザイン協働者に変える／②AI slop（安っぽい汎用デザイン）を解決する／③場当たり的なデザイン指示や、一枚ものの使い捨てページ量産を、システム思考とレビューゲートで置き換える」ツールだと言えます。
もう少し噛み砕くと、このプロンプトが与えるのは「デザインの語彙と規律」です。多くの人がAIにデザインを頼むとき、指示は「モダンでかっこいい感じで」といった曖昧なものになりがちです。しかし何が「モダン」で何が「かっこいい」かの基準が共有されていなければ、AIは学習データの平均——つまりどこかで見た汎用デザイン——を返します。claude-design-system-promptは、その基準を20章の哲学と14スキルとして明文化することで、「曖昧な依頼」を「具体的な判断基準にもとづく協働」に変えます。デザインの専門家でなくても、専門家が持っているような判断のよりどころを、プロンプト経由で借りられる——そう捉えると、このツールの価値がわかりやすいでしょう。
2. AI slop を退けるデザイン哲学 — 20章の中身
このプロンプトの中核は、system-prompt.md に収められた 20章のデザイン哲学 です。最初に「何を拒否するか」を明確にします。多くの「デザインアシスタント」プロンプトが吐き出す汎用SaaSテンプレ調——過剰なグラデーション、絵文字での装飾、角丸に左ボーダーを添えたカード、どの画面もInterフォント一色——を、明示的に退ける。これらは一見「無難」ですが、裏を返せば「どのプロダクトにも似合わない、個性のない見た目」でもあります。無難さは、しばしば没個性と紙一重なのです。そのうえで、完全なデザイン哲学に置き換えます。ここで重要なのは、「何がダメか」を列挙するだけでは不十分だという認識です。禁止事項だけを並べても、モデルは「では何をすればいいのか」を見失う。だからこのプロンプトは、退けるパターンを示すと同時に、代わりに従うべき積極的な原則を20章にわたって与えます。「これを避けよ」と「これを目指せ」を対で示すことで、はじめてモデルの出力を望ましい方向へ導けるのです。
その哲学がカバーする領域は驚くほど広く、絵作りから実装、そして納品後の運用にまで及びます。章立てで見てみましょう。
| # | 章 | # | 章 |
|---|---|---|---|
| 1 | アイデンティティと役割 | 11 | インタラクションとフィードバック |
| 2 | ワークフロー | 12 | シンプルさと一つの明確なCTA |
| 3 | まず質問する | 13 | システム思考 |
| 4 | 既存の文脈に根ざす | 14 | 媒体を尊重する |
| 5 | コンテンツ原則（中身のない要素を置かない） | 15 | ユーザーを理解する |
| 6 | 美的原則（目的あるビジュアル） | 16 | 量より質 |
| 7 | 視覚的ヒエラルキーとリズム | 17 | 出力原則 |
| 8 | タイポグラフィシステム | 18 | 協働と納品 |
| 9 | カラーシステム | 19 | 知的財産とコンテンツの境界 |
| 10 | アクセシビリティと包摂性 | 20 | 利用可能なスキル |
特筆すべきは、単なる「見た目のセンス」に留まらない点です。アクセシビリティ（10章） はWCAG、セマンティックHTML、キーボードナビゲーション、フォーカスリング、モーション設定に踏み込み、媒体を尊重する（14章） では実際のCSS Grid・oklch()・text-wrap: pretty・本物の対話的プロトタイプといった、実装の質にまで言及します。「デザイン」を絵作りではなく、コンテンツ・アクセシビリティ・実装を含む総合的な営みとして捉えているのです。
中盤の章立ても具体的です。視覚的ヒエラルキーとリズム（7章） は、サイズ・色・ウェイト・位置・密度・余白のスケールで情報の優先順位をつける方法を扱い、タイポグラフィシステム（8章） と カラーシステム（9章） は、その場しのぎのフォント選びや色使いではなく、一貫したシステムとして扱うことを求めます。インタラクションとフィードバック（11章） は、ホバー・アクティブ・無効・フォーカス・ローディング・バリデーションといった各状態を漏れなく設計させる。システム思考（13章） は、一枚もののページではなく、コンポーネントとトークンで考えることを促します。いずれも「見栄えの良い一画面」ではなく、「破綻せず拡張できる設計」に向かわせる章です。
なぜここまで細かく規定するのか。理由は、LLMが放っておくと「無難で平均的な、しかし没個性な」出力に収束しがちだからです。パレットを決めずに色を足していけば濁り、フォントを決めずに書けばInter一色になり、状態を意識しなければホバーもフォーカスも抜け落ちる。20章の哲学は、その「平均への収束」に一つひとつ楔を打ち込み、意図のある選択を強制する装置だと言えます。
16章の「量より質（Quality over quantity）」は、このプロンプトの通奏低音です。幅広く浅くではなく、深く掘って一つひとつのディテールを磨く。5章の「中身のない要素を置かない（no filler）」や12章の「一つの明確なCTA」も同じ精神の表れで、要素を足すより減らすことで質を上げる、という規律が全体を貫いています。AI slopが「とりあえず盛る」方向に走りがちなのとは、正反対の思想です。デザインの熟練者が「引き算」を重んじるのと同じ価値観を、プロンプトの規律として明文化している、と言い換えてもよいでしょう。
3. 14の手続き的スキル — 制作・抽出・レビュー
哲学だけでは絵に描いた餅になりがちですが、このプロンプトは 14の手続き的スキル で「では具体的にどう進めるか」を手順化しています。スキルは自己完結したフェーズ分けのプロシージャで、ユーザーの要求がスキルの説明に合致すると、エージェントがそれを読み込んで従います。ポイントは、スキルの「名前が発火のトリガー」になっている点です。ユーザーの依頼内容がスキルの説明とマッチすれば、エージェントは該当するスキルを自動的に呼び出す。だから利用者は「wireframeスキルを使って」と明示的に指定しなくても、「まずワイヤーで探りたい」と伝えれば適切なスキルが選ばれる、という自然な使い勝手になります。
3系統の中身を、それぞれの代表スキルとともに整理します。
| 系統 | スキル | 役割 |
|---|---|---|
| 制作（Production） | discovery-questions / frontend-aesthetic-direction / wireframe / make-a-deck / make-a-prototype / make-tweakable / generate-variations | 何かを作る。要件ヒアリングから、方向性決め、ワイヤー、試作、バリエーション生成まで |
| 抽出（System） | design-system-extract / component-extract | 構造を抜き出す。トークン抽出、再利用コンポーネントの棚卸し |
| レビュー（Review） | accessibility-audit / ai-slop-check / hierarchy-rhythm-review / interaction-states-pass / polish-pass | 監査して直す。アクセシビリティ、AI slop検出、階層・リズム、インタラクション状態、最終ゲート |
制作系のスキルも、それぞれ役割がはっきりしています。discovery-questions はキックオフの質問プロトコル（作り始める前に要件を引き出す）、frontend-aesthetic-direction はブランドが無いときに見た目を決め切るためのスキル、wireframe は3案以上の低忠実な探索、make-a-prototype は触れるクリック可能な試作、make-tweakable は浮動の調整パネルを付けて微調整できるようにする、generate-variations は軸をまたいだ3案以上の高忠実バリエーション、make-a-deck はHTMLでのスライド作成です。抽出系の design-system-extract は既存ソースからトークンを引き出し、component-extract は再利用可能なコンポーネントを棚卸しします。
とりわけ象徴的なのが、レビュー系にある ai-slop-check です。グラデーション・絵文字・フォント・ハウススタイルといった「AIが陥りがちな見た目のクセ」を検出する専用スキルで、いわば「自分の出力が安っぽくなっていないか」を自己点検する仕組み。そのほかのレビュースキルも具体的で、hierarchy-rhythm-review はサイズ・ウェイト・色と余白スケールを、interaction-states-pass はホバー・アクティブ・無効・フォーカス・ローディングの各状態を点検します。そして最後に polish-pass（最終ゲートの傘となるレビュー）が、すべてを総ざらいします。作りっぱなしではなく、必ず検査を通す——この「作る（Maker）／チェックする（Checker）」の分業が、品質を担保する肝です。人間のデザインレビューで、作った本人とは別のレビュアーが目を通すのと同じ発想を、スキルの構成に落とし込んでいるわけです。
4. スキルを鎖状につなぐワークフロー
14のスキルは単体でも使えますが、真価は 鎖状につなぐ（チェーンする） ときに発揮されます。リポジトリは、代表的な2つのフローを示しています。
一つは、ゼロから作る グリーンフィールド のフロー。もう一つは、既存ブランドがある場合の ブランド対応 フローです。どちらのフローも、単発のスキルを並べただけではなく、前の段の出力を次の段が受け取って積み上げていく設計になっています。質問で得た要件が方向性決めの材料になり、方向性が試作の土台になり、試作がレビューの対象になる——という具合に、情報が段を追って濃くなっていきます。両者を図にすると、こうなります。
あるか"} Q -->|"ない（新規）"| A1["discovery-questions
要件を聞く"] A1 --> A2["frontend-aesthetic-direction
方向性を決める"] A2 --> A3["wireframe
低忠実で探る"] A3 --> A4["make-a-prototype
触れる試作"] A4 --> P["polish-pass
最終ゲート"] Q -->|"ある（ブランド既存）"| B1["design-system-extract
トークンを抽出"] B1 --> B2["generate-variations
複数案を出す"] B2 --> B3["make-tweakable
調整パネルつき"] B3 --> P P --> D["納品"]
新規なら、まず discovery-questions で要件を聞き、frontend-aesthetic-direction で方向性を決め（ブランドが無いときに「見た目を決め切る」ためのスキル）、wireframe で低忠実に探り、make-a-prototype で触れる試作を作り、polish-pass で仕上げる。既存ブランドがあるなら、design-system-extract でトークンを抽出し、generate-variations で軸をまたいだ複数案を出し、make-tweakable で調整用の浮動パネルを付け、polish-pass で締める。どちらも最後は必ずレビューゲートを通るのがポイントです。
この2つのフローの分岐点は「ブランド資産があるかどうか」です。ゼロから作るなら、まず方向性を決めるところから始める必要がある。一方、既存のプロダクトに新しい画面を足すような場合は、すでにあるトークン（色・タイポ・間隔のルール）を抽出して踏襲することが最優先になります。「新規は方向決めから、既存は抽出から」——この使い分けは、実際のデザイン現場の判断そのものです。claude-design-system-promptは、こうした「状況に応じてどの手順から入るべきか」まで含めて手順化しているため、利用者は自分の状況に近いフローを選ぶだけで、抜けのない進め方ができます。
この「探索 → 具体化 → レビュー」という流れは、人間のデザインプロセスそのものです。いきなり完成品を作ろうとせず、質問で要件を固め、低忠実で方向を探り、試作で手触りを確かめ、最後に品質ゲートで締める。claude-design-system-promptは、その人間の段取りを、LLMが再現できる形に手順化しているわけです。
チェーンにすることの利点は、「各段で判断が確定していく」点にあります。いきなり高忠実な完成品を作らせると、方向性が違ったときにやり直しのコストが大きい。だからまず質問で前提をそろえ、次に低忠実で方向を探り、良さそうな線が見えてから手触りのある試作に進む。各段で人間が確認・修正できるため、最終成果物が大きく外れることを防げます。とりわけ make-tweakable（調整パネルつき）や generate-variations（複数案）は、「一発で正解を当てる」のではなく「選べる状態を作る」ためのスキルで、デザインが本質的に反復的な営みであることを、ワークフローに織り込んでいます。AIに任せると「それっぽい一案」で止まりがちですが、このプロンプトは意図的に「比べて選ぶ」局面を作るのです。
5. 最新モデル向けの調整 — ノルマでなく条件で
このリポジトリで技術的に興味深いのが、現行のフロンティアモデル向けの調整（Model calibration） です。claude/ バリアントは、Fable 5やOpus 4.7/4.8系といった、指示を字義どおりに受け取り、過剰なプロンプトを必要としないモデルに合わせて作られています。ここは、デザインに関心が無い人にとっても読む価値のあるパートです。なぜなら、「新しい世代のモデルに、どう指示を書けば意図どおり動くか」という、プロンプトエンジニアリングの実践知が凝縮されているからです。
その調整方針は、プロンプトエンジニアリングの実務として示唆に富みます。
・ノルマでなく条件で指示する：「N個以上質問せよ」「CRITICAL: YOU MUST」といった量的ノルマや強い命令を避ける。現行モデルはノルマを字義どおりの契約として扱い、過剰発火するため。代わりに「どんな条件で行動するか」を述べ、些細な判断は自律に委ねる
・スキルとサブエージェントの発火条件を明示する：これらのモデルは任意の機能を控えめにしか使わないので、各スキルに「いつ呼ぶか」を明記し、検証役への委譲にも明確なトリガー（「実質的な視覚変更のたびに」）を置く
・網羅重視のレビュー：レビューエージェントには確信度・重大度つきで「すべて」報告させ、絞り込みは集約段に任せる。「重要な問題だけ報告」と言うと字義どおり受け取って知見を握りつぶすため。つまり「拾う」と「絞る」を別の工程に分け、拾う側には遠慮させないのが要点
・ハウススタイル対策：現行モデルの既定の美的傾向（クリーム色の背景、セリフの見出し、テラコッタ／琥珀のアクセント）を ai-slop-check（ルール9）が検出し、frontend-aesthetic-direction が先回りして防ぐ。temperature のようなサンプリングパラメータはもう存在しないため、視覚の多様性は乱数でなく各案の明示指定で作る
この穏やかな言い回しは最新モデル向けの最適化なので、古いモデル（Claude Opus/Sonnet 4.6以前や非Anthropic系）では指示が弱すぎて発火しないことがあります。質問ラウンドやレビューが飛ばされるようなら、命令口調を強める運用に戻すことが推奨されています。モデルの世代によって「効くプロンプト」が変わる——この一点は、プロンプトを書くすべての人にとっての教訓です。なお `codex/` バリアントは別系統で保守されており、これらの注意の影響を受けません。
この「モデルの世代に合わせて言い回しを変える」という発想自体が、実は大きな学びです。同じ内容の指示でも、モデルが賢くなるほど「強い命令」は逆効果になり、字義どおりの過剰反応を招く。逆に賢いモデルには、条件と意図を伝えて判断を委ねたほうが良い結果が出る。プロンプトは「モデルに対して固定の呪文」ではなく、「相手の性質に合わせて調整する対話設計」だ——claude-design-system-promptの調整方針は、それを具体例で示しています。デザインに関心がなくても、プロンプトエンジニアリングの参考として読む価値がある理由が、ここにあります。
6. claude-design-system-prompt の導入と、誰に向くか
導入は拍子抜けするほど簡単です。system-prompt.md の中身を、任意のLLMのシステムプロンプトとして貼り込むだけ。あとはエージェントがデザイン哲学に従い、タスクに応じてスキルを名前で参照します。スキルを手続きとして使いたい場合も、各スキルは自己完結しているので、ユーザーの要求がスキルの説明に合致すれば自動的に読み込まれます。
ただし一点、環境の前提には注意が必要です。このプロンプトはHTML出力のデザイン環境（Claude.aiのデザインツールに似た構成）を想定しています。Figmaプラグイン、コードのみのアシスタント、チャットのみのデザインコーチなど、対象環境が異なる場合は、ワークフロー章やツール参照を調整する必要があります。ただし原則を述べた5〜16章は、どの媒体にも移植できると作者は述べています。つまり、「具体的なツールの使い方（ワークフロー章）」と「普遍的なデザイン原則（5〜16章）」が分離して書かれているので、自分の環境に合わせて前者だけ差し替えれば、後者はそのまま活きる設計になっているわけです。
実務的には、まるごと貼り込むだけでなく、必要な章やスキルだけを抜き出して自分のCLAUDE.mdやプロジェクトの指示ファイルに混ぜ込む使い方も現実的です。たとえば「AI slopだけは絶対に避けたい」なら ai-slop-check の観点を、「アクセシビリティを担保したい」なら accessibility-audit の観点を取り込む、といった具合です。MITライセンスで帰属表示も不要なので、こうした部分的な流用も気兼ねなくできます。貢献も歓迎されており、追加のレビュースキル（コピーレビュー、モーションレビュー、ダークモード整合チェックなど）や、他環境向けの適応、他言語への翻訳が特に有用とされています——日本語環境向けの調整を寄せる、といった関わり方もできるわけです。
実際に試すなら、いきなり本番のプロジェクトに適用するより、まずは使い捨ての実験から始めるのが安全です。適当なランディングページやダッシュボードのお題を用意し、素のLLMに作らせたものと、system-prompt.md を貼り込んだうえで作らせたものを見比べてみる。あるいは、既存のAI生成デザインに ai-slop-check をかけて、どんな指摘が返ってくるかを確かめる。こうした小さな比較を一度やるだけで、「システムプロンプトの有無で出力がどう変わるか」が体感でき、自分の用途にどこまで組み込むかの判断がつきます。
このプロジェクトが向くのは、次のような人です。
・AIにUIを作らせると「安っぽくなる」と感じている人：ai-slop-checkと20章の哲学が、その原因を言語化して潰す
・アクセシビリティを最初から織り込みたい人：WCAG・キーボード・モーションを扱うaccessibility-auditが標準装備
・デザインを「システム」として運用したい人：トークン抽出・コンポーネント棚卸し・レビューゲートで、一枚もの量産から脱却できる
・プロンプトエンジニアリングを学びたい人：最新モデル向けの調整方針そのものが、実務的な教材になる
・非デザイナーだが、それなりの見た目を自力で用意したい人：専門家の判断基準を借りて、平均以上の成果物にたどり着ける
逆に、ピクセル単位の細かな調整を対話で詰めたい人や、既に確立した独自のデザインプロセスを持つチームには、このプロンプトの「決め打ち」がかえって窮屈に感じられるかもしれません。その場合も、丸ごと採用するのではなく、ai-slop-checkやaccessibility-auditといった一部の観点だけを取り込む使い方が向いています。要は「全部乗せの土台」としても「部品取りの参考」としても使える柔軟さがあるので、自分の関わり方に合わせて距離を選べばよいのです。
このプロンプトは、CLAUDE.mdやスキルとしてClaude Codeに組み込む形でも活きます。Claude Code側の作法は Claude Code完全ガイド2026：インストールから本番運用まで を、AIに「良し悪しの感覚」を持たせる周辺の考え方は taste-skill 解説 や awesome-design-md 解説 もあわせて読むと、デザイン協働の全体像がつかめます。
claude-design-system-promptは、「きれいに作って」という曖昧な指示では出てこない、意図あるデザインをLLMに作らせるためのシステムプロンプト＋スキル集です。AI slopを明示的に退け、20章の哲学（コンテンツ・美・ヒエラルキー・アクセシビリティ・システム思考・量より質）を注入し、14の手続き的スキルで探索→試作→レビューを回す。最新モデル向けの調整方針まで含め、これ自体が「LLMに専門的判断を持たせる」ことの実例になっています。AIのデザイン出力に物足りなさを感じているなら、まず system-prompt.md を貼り込んでみる価値があります。
まとめ
本記事では、LLMを「AI slopに抗うデザイン協働者」に変えるOSS、claude-design-system-promptを、公式リポジトリの一次情報にもとづいて解説しました。Anthropicのデザインツールの挙動をリバースエンジニアリングした、実際に貼り込んで動かせるシステムプロンプト＋スキル集です。
その核心は、「良いデザインの判断基準と具体手順を、システムプロンプトとしてLLMにまるごと持たせる」ことにあります。汎用SaaSテンプレ調を明示的に退け、コンテンツ・美・ヒエラルキー・アクセシビリティ・システム思考・量より質という20章の哲学を注入し、制作・抽出・レビューの14スキルを鎖状につないで、探索から仕上げまでを回す。さらに、最新フロンティアモデルの挙動に合わせた調整——ノルマでなく条件で指示する、ハウススタイルを先回りで潰す——まで作り込まれており、プロンプトエンジニアリングの実例としても学びが多い一本です。
デザインという営みは、突き詰めれば「無数の選択に一貫した意図を通すこと」です。フォント一つ、余白一つ、状態一つに理由があり、それらが全体として一つの方向を向いている。AIは個々の要素を手早く生成できますが、放っておくと「意図の一貫性」が抜け落ち、平均的で没個性な出力に流れます。claude-design-system-promptは、その一貫性をシステムプロンプトという形で外から与える試みだと言えます。AIにデザインを任せて「なんだか安っぽい」と感じたことがあるなら、まず system-prompt.md を貼り込み、ai-slop-check を一度走らせてみてください。自分の出力の何が「slop」だったのかが言語化されるだけでも、次の一手が変わってくるはずです。
参照ソース
・claude-design-system-prompt（Trystan-SA 公式リポジトリ） — 本記事が解説した一次情報。20章の哲学・14スキル・モデル調整のすべて
・WCAG（Web Content Accessibility Guidelines・W3C） — accessibility-auditが準拠するアクセシビリティ標準
