Claude Codeのfrontend-designプラグインでAIっぽい画面を避ける
frontend-designプラグインはスキル1つで、コードを書く前に題材の確認と設計計画の見直しを挟ませます。導入、スコープ、効く場面、CLAUDE.mdとの併用を扱います。
frontend-designは、Claude Codeでフロントエンドを作るときに「どこかで見た画面」へ寄るのを抑えるプラグインです。中身はスキル1つ。入れておくと、UIを作らせる依頼でClaudeが自動で読み込み、コードの前に設計計画を立てて見直す手順を踏みます。
この記事では導入とスコープの選び方、スキルが実際に何を指示しているか、効く場面と効かない場面、CLAUDE.mdとの併用までを順に扱います。
frontend-designは何を入れるプラグインか
マーケットプレイスの掲載には「Anthropic verified」の表示があり、説明は「汎用的なAI美学を避けた、製品品質のフロントエンドを作る」という趣旨です。提供元はAnthropicで、ソースはclaude-plugins-officialリポジトリの plugins/frontend-design にあります。
ディレクトリの構成は小さく、.claude-plugin のマニフェスト、skills/frontend-design、LICENSE、READMEだけです。マニフェストの description は「UI/UX実装のためのフロントエンドデザインスキル」の1行。コマンドやMCPサーバーは入りません。
つまり、導入して変わるのは「UIを作る依頼に対するClaudeの進め方」だけです。ツールが増えるわけではありません。
スキルのfrontmatterに書かれた説明は、新しいUIの構築や既存UIの作り替えで、美的方向性・書体・「テンプレートの既定に見えない選択」を助けるガイダンス、という内容です。Claudeはこの説明を手がかりに、依頼がフロントエンドに当たるかを判断して読み込みます。
導入する手順とスコープの選び方
導入先は公式マーケットプレイスです。Claude Codeは対話セッションを初めて起動したときに、公式マーケットプレイスを自動で登録します。
導入から有効化まで
- 1
インストールコマンドを実行する
セッション内なら
/plugin install frontend-design@claude-plugins-officialを打ちます。この場合はすぐ入らず、/pluginパネルがプラグインの詳細で開きます。 - 2
追加される内容を確認する
詳細欄の「Will install」にスキルが1つ出るのを確かめ、インストールスコープを選びます。
- 3
再読み込みして反映する
セッションが開いたままなら
/reload-pluginsで有効にします。パネルが再読み込みを案内する場合もあります。
シェルから入れる場合は次の1行です。マーケットプレイスのページの「Claude Code」ボタンがコピーするのも、この形です。
claude plugin install frontend-design@claude-plugins-official--marketplace フラグと @ 形式の違いはclaude plugin installの導入経路の記事にまとめています。
どのスコープで入れるか
スコープは3種類あり、記録先の設定ファイルが違います。
| スコープ | 効く範囲 | 記録先 |
|---|---|---|
| User | 効く範囲自分の全プロジェクト | 記録先~/.claude/settings.json の enabledPlugins |
| Project | 効く範囲そのリポジトリの全員 | 記録先.claude/settings.json(コミットする) |
| Local | 効く範囲自分のそのリポジトリだけ | 記録先.claude/settings.local.json |
個人で試すならUserかLocal。チームで画面の品質を揃えたい場合はProjectにします。ただしProjectスコープは、設定をコミットしても共同作業者のマシンにダウンロードされるわけではありません。各自が claude plugin install frontend-design@claude-plugins-official --scope project を1回ずつ実行する必要があります。
同じプラグインが複数のスコープに設定されていれば、LocalがProjectを、ProjectがUserを上書きします。
呼び出しは自動。効かないときの確かめ方
READMEには「フロントエンド作業ではClaudeがこのスキルを自動で使う」とあり、使用例は次の3文だけです。
- 音楽ストリーミングアプリのダッシュボードを作って
- AIセキュリティのスタートアップ向けにランディングページを作って
- ダークモード対応の設定パネルをデザインして
専用のスラッシュコマンドを打つ必要はありません。スキルを自動で読み込む仕組みは、説明文と依頼内容の一致で決まります。スキル一覧は/skillsコマンドで確かめられます。
効いていないと感じたら、次の順で切り分けます。
スキルが効いているか確かめる順番
- Q/plugin のInstalledタブで有効になっているか?答えがいいえのとき答えがはい
Spaceキーで有効にし、
/reload-pluginsを実行します。 - Q/skills の一覧にfrontend-designが出るか?答えがいいえのとき答えがはい
プラグインの再読み込みか、Claude Codeの再起動を試します。
- Q依頼文にUIを作る意図がはっきりあるか?答えがいいえのとき答えがはい
「frontend-designスキルを使って、〜のランディングページを作って」と名指しで頼みます。
それでも計画が出ない場合
スキルは読み込まれていても、依頼が小さな修正だけなら設計計画までは進みません。新しい画面や作り替えの依頼で試します。
スキルがコードの前にやらせること
スキルの本文を読むと、「見た目の好み」より「進め方」の指示が中心です。コードを書く前に3つの段階を挟みます。
スキルが指示する進め方
- 1
題材を押さえる
ブリーフに製品や題材が書かれていなければ、Claude自身が1つの具体的な題材・読み手・主な役割を仮置きし、依頼主に確認します。記憶に好みや文脈があれば手がかりにします。
- 2
設計計画を作る
色は4〜6個の名前付き16進数、書体と役割、レイアウト案(文章の説明とASCIIのワイヤーフレーム、整列方針を含む)、原則の4点で小さな設計計画を作ります。
- 3
計画を見直してから実装する
計画のどこかが「似た依頼なら誰でも出す案」に見えたら、直して、何をなぜ変えたかを伝えます。その後でコードを書きます。
Claude Codeで使うと、最初の返答がコードではなく質問や設計計画になることがあります。止まったと思わず、題材の仮置きに答えるか、計画に注文を付けて先へ進めます。
実装後の見直しについても書かれています。環境が対応していれば、スクリーンショットを撮って自分の仕事を批評するよう求める記述です。ブラウザを操作してスクリーンショットを撮るには、マーケットプレイスに並ぶPlaywrightプラグインのようなブラウザ自動化の手段が要ります。
「AIっぽさ」の具体的な正体
スキルが生成物の癖として挙げる型のうち、色とレイアウトの5つの既定(暖色クリームにセリフ体、黒背景に蛍光1色、新聞風、SaaSカード一式、題材と無関係な装飾)は、Opus 5.5のデザインでAIっぽさを避けるプロンプトの記事で一覧にしています。ここではそれ以外の指示を拾います。
既定の型以外にスキルが書いていること
ヒーローは題材の中から選ぶ
最初に見える部分は、題材の世界でいちばん特徴的なものを、見出し・画像・アニメーション・ライブデモなどから適した形で出す、と書かれています。「大きな数字+小さなラベル+補助の数値+グラデーションのアクセント」は既定の型だと明記されています。
書体は1〜2ファミリー
見出しと本文で別の書体を使う必要はなく、1ファミリーか2ファミリーにとどめます。2つ使うなら、はっきり違うものにします。行長は80文字未満が既定で、セリフ体の本文は行間を少し広げます。
構造要素は情報として使う
罫線、番号、ラベルなどは内容の構造を表すために使い、飾りにしません。番号マーカーは、内容が本当に手順や年表のときだけ付けます。
動きは絞る
ユーザー操作によらない動きは控えめにします。ページ読み込み時の1つの演出のほうが、各セクションのフェードインやカードごとのホバーより効くという立場です。操作に応じて状態の変化を示す動きは歓迎されています。
文面もデザインの一部
CTAは「送信」でなく「変更を保存」のように、起きることをそのまま書きます。エラーは謝らず、何が起きたかと直し方を書きます。空の画面は次の行動への案内にします。
大胆さは1か所に使う
記憶に残る要素を1つに決め、周りは静かに保ちます。レスポンシブ、キーボードフォーカスの可視化、モーション低減の設定への対応といった品質の床は、宣言せずに満たすことも求められます。
文面の指示は見落とされやすい部分です。画面の見た目を直しても、ボタンの文言が「送信」のままなら、テンプレート臭は残ります。
効く場面と、効きにくい場面
スキルは冒頭で、ブリーフが視覚の方向を指定しているなら従うように書いています。「ブリーフ自身の言葉が常に優先される」で、既定の型を指定された場合でも同じです。方向が決まっていない軸にだけ、既定へ流れないよう求める構造です。
| 状況 | 効き方 |
|---|---|
| 題材だけの依頼(ダッシュボード、LPなど) | 効き方大きく効く。選択の余地が広いため |
| 色・書体・雰囲気を依頼文で指定している | 効き方指定が優先され、指定外の軸だけに効く |
| 既存のデザインシステムに合わせる改修 | 効き方限定的。トークンを明示したほうが確実 |
| ロジックだけの修正 | 効き方ほぼ効かない |
既存のデザインシステムがあるプロジェクトでは、プラグインに任せきりにすると、既存の見た目から離れた「独自性」が出るおそれがあります。その場合はトークンと禁止事項を書いておきます。
CLAUDE.mdにブリーフの土台を置く
ブリーフが具体的なほどスキルは指定に従うので、毎回の依頼で繰り返す内容はCLAUDE.mdに寄せます。次はあくまで書き方の一例です。
## UIの方針
- 配色: 背景 #FAFAF7、文字 #1B1B18、アクセント #0F6E6E(これ以外の色を増やさない)
- 書体: 見出しと本文を同じファミリーで統一。ウェイトで階層を作る
- 角丸は4px固定。カードの影は使わない
- 動き: 初回表示の1演出のみ。ホバーの装飾は付けない
- 新しい画面は、実装前に配色・書体・レイアウトの計画を出して承認を取る最後の1行は、スキルが元々踏む「計画を作る」段階を、承認を挟む形に固定するものです。計画を見てから進められるので、作り直しが減ります。
依頼文を変えると、効き方は次のように変わります。
依頼文の書き方
題材だけを渡す
「社内向けの勤怠ダッシュボードを作って」。方向を指定していないので、スキルが選ぶ美的方向がそのまま出てきます。
読み手と制約も渡す
「経理担当が月末に毎日開く勤怠ダッシュボード。情報密度は高く、色は3色まで。既存のCSS変数を使う」。題材・読み手・制約が揃い、スキルは残りの軸に効きます。
CLAUDE.mdが長くなってきたら、毎回読ませる必要のない手順はCLAUDE.mdからスキルへ移すほうがコンテキストを節約できます。
つまずきやすい点
- 最初の返答が実装でない: 題材の確認や設計計画を出すのはスキルの手順どおりの動きです。計画への注文で先へ進みます。
- チームで効果が揃わない: Projectスコープでコミットしても、各自がインストールするまでダウンロードされません。
- 使っていないのにコンテキストを使う: Installedタブでは、最近使っていないプラグインが「Not used recently」にまとまります。UIを作らない期間は無効にできます。
- 指定した色が通らない: 色を指定したのに無視されるときは、依頼文に具体的な16進数を書きます。スキルは、ブリーフの指定が既定より優先されるとしています。
まとめ
frontend-designは、見た目の好みを押しつけるプラグインというより、「計画を立て、既定に流れていないか見直してから実装する」という進め方を足すプラグインです。題材だけの依頼で効果が大きく、色や書体を指定した依頼では指定が優先されます。まず1つ、新しい画面を題材だけで頼み、出てきた設計計画に注文を付けるところから試すと、スキルの効き方をつかめます。