Figma Makeカスタムスキル実践ガイド：デザインシステム向け3点セット

ブランド仕様から外れたまま出したビルド

レビュー用ビルドは、ほぼ正解でした。だからこそ危険でした。リブランド以来8pxに固定されているシステムなのに、ボタンの角丸は12px。プライマリアクセントは#18C5DAのような色で、クライアント指定の#06B6D4と見た目は近いものの、Figmaのカラーピッカーに貼り付ければ差は一目瞭然です。3つ目のフレームでは、本文がシステム指定の16pxではなく18pxになっていました。

その朝に書いたプロンプトが悪かったわけではありません。問題は、6つ前に書いたプロンプトでした。Figma Makeはセッション内のコンテキストを保持しますが、デザインシステムのルールは入力地点から離れるほど薄れていきます。ヒーローセクションの3案目を詰める頃には、もっともらしいトークン値をモデルが即興で補い始めます。2026年5月のリリースノートでも、カスタムスキルはまさにこの穴を埋めるものと説明されています。指示一式をパッケージ化して呼び出せるため、毎回貼り直さなくても各プロンプトに組み込めます。（Figmaリリースノートまとめ、2026年5月）

以下のスキルパックを作り、同じブリーフをMakeでもう一度実行しました。ボタンの角丸は8px、アクセントは#06B6D4、本文は16px。スキルがMakeを賢くしたのではありません。ルールを忘れられない状態にしたのです。

クライアントのデザインシステムが本当に求めるもの

この記事で扱うのは、実在するクライアントのシステムです。以下は機密情報を除いたトークンです。

• カラー：背景は#0A0E14、前景は#E6EDF3、アクセントは#06B6D4の1色だけ。セカンダリアクセントもグラデーションも使いません。
• スペーシング：基準は8px。使用できるスケールは8 / 16 / 24 / 40のみで、その間や範囲外の値は認めません。
• タイプスケール：14 / 16 / 20 / 32 / 48。本文は16で、18は使いません。
• 角丸：操作できるすべての面は8px、カードは0。例外はありません。
• ボタン：コンポーネントは1つ、状態はデフォルト、ホバー、無効の3つ。デフォルトはアクセントで塗り、無効時は前景色を不透明度30%で使います。

「ブランドに合わせて」という一般的なプロンプトでは、どの項目も守れません。形容詞には解釈の余地があるからです。「クール、ミニマル、アクセントは1色」だけなら、該当するシステムは無数にあります。モデルに必要なのはムードボードではなく、この表です。目標は、セッションごとに表を打ち直さなくても、このクライアント向けのすべてのMakeビルドを表に照らして検証できる状態にすることです。

Figma Makeを支える3つのスキル——実際の.mdファイル

Figma Makeのカスタムスキルは、Agent Skills仕様に従う単一のMarkdownファイルです。frontmatterのnameがスラッシュコマンドになります。アカウント単位でインストールされ、所有するすべてのMakeファイルで利用できます。重要なのは、ファイル単体で完結させる必要があることです。scripts/、references/、assets/ディレクトリは使えません。モデルに参照させたい内容は、すべて指示内に直接記述します。（Figma Makeのカスタムスキル、Figmaヘルプ）

私が毎回書き直していた内容の90%は、次の3つのスキルで置き換えられました。

/follow-ds-guidelines

トークン表を、そのまま指示として貼り付けたものです。解釈も形容詞も加えません。

---
name: follow-ds-guidelines
description: Enforce the client design system on every generated frame.
---

You are building inside a locked design system. Use these exact values.
Do not improvise alternates, do not interpolate, do not soften.

## Color
- background: #0A0E14
- foreground: #E6EDF3
- accent: #06B6D4 (single accent, no secondary)

## Spacing (8px base)
- allowed: 8, 16, 24, 40
- forbidden: any value not in the allowed list

## Type ramp
- 14 / 16 / 20 / 32 / 48
- body is 16. never 18.

## Radius
- interactive surfaces: 8
- cards: 0

## Button (one component, three states)
- default: fill #06B6D4, foreground #0A0E14
- hover: fill #06B6D4 at 90% opacity
- disabled: foreground #E6EDF3 at 30% opacity

If a request would produce a value outside this table, return the closest
allowed value and flag the substitution in a comment.

/design-crit

現在のフレームをトークン表と突き合わせて監査し、合否の一覧を返すレビュースキルです。違反箇所は16進カラーコードとピクセル値まで明示します。

---
name: design-crit
description: Audit the current frame against the client design system.
---

Walk the current frame top to bottom. For every visual element, check:
- color hex against the allowed palette
- spacing values against the 8 / 16 / 24 / 40 scale
- type size against the 14 / 16 / 20 / 32 / 48 ramp
- radius against 8 (interactive) or 0 (cards)

Return a table:
| Element | Property | Found | Expected | Pass/Fail |

End with a one-line verdict: PASS if all rows pass, FAIL otherwise.
Do not auto-fix. The human decides which deviations are intentional.

/insert-sample-data

レビュー用ビルドに承認済みのプレースホルダー文言を入れるスキルです。lorem ipsumやモデルが作った企業名をそのまま出し、後から法務に止められる事態を防げます。（2026年5月のリリースノートまとめ）

---
name: insert-sample-data
description: Replace placeholder text with approved sample data.
---

When asked for sample content, use only this set:

## Names
Sarah Chen, Marcus Okafor, Priya Raman, Diego Alvarez

## Company names (fictional, cleared)
Northwind Labs, Apex & Vine, Halcyon Group, Stratus Co

## Numbers
Use round numbers in product UI: 1,240 / 3,500 / 12,800.
Avoid revenue-shaped numbers unless asked.

Never use lorem ipsum. Never invent a real-sounding brand name not on this list.

ファイルはこの3つです。どれも、以前ならその都度貼り直していた内容を置き換えます。

Notionコネクターを接続し、最新のシステムを読む

/follow-ds-guidelinesにトークンを直接書く方法は、変更のないシステムには有効です。しかし、クライアントがトークンを更新した瞬間——そして更新は必ず起きます——埋め込んだ表は古くなります。そこでスキルとコネクターを組み合わせ、Makeに最新のソースを読ませます。（Figma Makeのコネクター、Figmaヘルプ）

このクライアントのファイルでは、デザインシステムを1枚のNotionページにまとめています。見出しはスキルと同じColor、Spacing、Type ramp、Radius、Buttonです。1つのプロンプトでスキルとコネクターを同時に呼び出します。

Use the /follow-ds-guidelines skill, but pull the current token values
from @Notion "Halcyon – Design System v3" and override the inline table
where they differ. Then build the pricing section per the attached spec.

同じ形式で、DriveからPRDを取得することもできます。@Drive "Halcyon pricing PRD"を加えれば、Makeがデザインシステムと仕様のコンテキストを一度に組み立てます。（2026年5月のリリースノートまとめ）

クライアントごとの判断基準は単純です。四半期の間変更がないシステムならトークンを直接記述し、まだ変化しているシステムならコネクターから取得します。どちらでもスキルの.mdは変えず、プロンプトだけを変えます。これは意図的な設計です。クライアントごとにスキルを増殖させるのではなく、必要に応じて上書きできる1つのスキルにしたいからです。

なお、Figma MCPサーバーの/prototype-to-figmaスキルは別の機能です。コードとキャンバスを往復するためにプリインストールされており、自分で作成するものではありません。Makeのカスタムスキルはその逆で、自分で記述してMake内に置き、MCPレイヤーには触れません。

実運用で詰まった点——非決定性と共有コスト

発表では触れられていなかった点が3つあります。

対応モデルは、ドキュメントから受ける印象より限定的です。 現在カスタムスキルが動くのは、Figma MakeのデフォルトモデルとClaude Opus 4.7だけです。チームがMakeで別のモデルに統一している場合、スキルは適用されません。しかも目立つエラーは出ず、ひっそりと効かなくなります。（Figma Makeのカスタムスキル、Figmaヘルプ）チーム制作で「なぜまた角丸が違うのか」を調べるとき、私はまずここを確認します。

結果は同一ではなく、「多くの場合」に一貫します。 これはFigma自身のドキュメントにも明記されています。モデルは非決定的なので、複雑なフレームでは/design-critが逸脱を見落としたり、意図した差まで違反と判定したりすることがあります。（Figma Makeのカスタムスキル、Figmaヘルプ）そのため、このレビュースキルは素早い一次確認に使い、最終承認には使いません。

運用で効いてくるのが、共有コストです。 現時点のカスタムスキルはアカウント単位です。チームメンバーにパックを渡すには.mdファイルを書き出し、各自のアカウントへアップロードしてもらいます。組織単位の公開機能はありません。（Figma Makeのカスタムスキル、Figmaヘルプ）複数クライアントのシステムを扱うスタジオには、無視できない負担です。新しいメンバーが加わるたびに、稼働中のすべてのスキルを手作業でインストールし、更新のたびに再度書き出す必要があります。対策は地味ですが確実です。.mdファイルをクライアントのリポジトリでバージョン管理し、私たちの場合は同じモノレポ内でデザイントークンの隣に置き、リリースにタグを付けています。これでアップロード元がSlackメッセージではなく、1つの正本になります。

このように席単位の運用負担があるプラットフォームを使うデザイナー向けに、スタジオ運営の視点からWebflowプレミアムプランの料金計算についても書きました。ツール側は見えている機能に価格を付けますが、利用者側はその下にある統合の摩擦まで負担することになります。

結論——スキルに任せること、人が担うこと

DVNC.studioで数週間運用して落ち着いたルールは、「2回を超えて書き直したものはスキルに入れる」です。トークン表、レビュー用チェックリスト、サンプルデータの規約、アクセシビリティ注釈の定型文。どれも創造的な仕事ではありませんが、すべて運用コストになっていました。

人に残すべきなのは判断です。/design-critはシステム外の値を検出できますが、それがミスなのか、単発のマーケティング画面で意図した例外なのかまでは決められません。「この角丸は12で、期待値は8」は得意です。しかし、「キャンペーンのコンセプトに柔らかいカードが必要で、火曜日に合意したため12にした」という事情は判断できません。そこを見極めることこそ、人の仕事です。

次の火曜日に試すなら、最もよく使うクライアントのシステムを1つ選んでください。.mdファイルを開き、上のHalcyonの例と同じようにトークン表を貼ります。follow-ds-guidelines.mdとして保存し、カスタムスキルとしてアップロードしたら、実際のビルドを1本通します。その出力に/design-critを実行し、トークン表との差分を手作業で確認します。普段なら自分で見つける問題をスキルが拾えれば、クライアントごとに毎週1時間かかっていた再プロンプト作業を置き換えられます。明らかな問題を見逃したなら、直す場所はプロンプト履歴ではなく.mdです。