はじめに
最近、AI に UI 実装を任せる開発スタイルが広がっています。Figma の公式 MCP サーバーを使えば、デザインデータを AI が直接読み取って React コードを生成できる。便利な時代になりました。
しかし、実際に業務で使ってみると一つ大きな壁にぶつかります。「AI が社内 UI ライブラリを使ってくれない」 という問題です。
本記事では、この課題を解決するために整備した talentx-ui-mcp（社内 UI ライブラリ専用の MCP サーバー）と関連設定について、実際に効果を検証した結果を共有します。
背景：Figma MCP だけでは足りなかった
何が問題だったか
Figma MCP を導入したことで、デザインの構造・色・サイズといった情報を AI が正確に読み取れるようになりました。見た目の再現度は高い。
しかし、生成されるコードには以下の問題がありました。
- Figma MCP が返すのは React + Tailwind の参照コード
- AI はそれを styled-components に変換するが、社内 UI ライブラリ（talentx-ui）のコンポーネントは使わない
- チェックボックスを SVG で自作、テーブルを
<div>で手組み、ラベルを styled-components で再実装...
デザインは再現できるが、プロダクションコードとしては使えない。 レビューで「talentx-ui の Table を使ってください」「CheckBox があるのに自作しないで」と差し戻しが発生し、結果として工数が増えてしまう状態でした。
整備したもの
この課題を解決するために、以下を整備しました。
1. talentx-ui-mcp
社内 UI ライブラリのコンポーネントカタログを AI が検索・参照できる MCP サーバーです。TypeScript AST で Storybook ファイルを静的解析し、以下の 3 つのツールを提供します。
| ツール | 機能 |
|---|---|
search_stories |
キーワードで Storybook を検索し、該当するコンポーネントと Story スニペット（使用例）を返す |
get_component_detail |
指定コンポーネントの全 Props（型・required・デフォルト値）と Story スニペットを返す |
get_design_tokens |
theme.ts からデザイントークン（色・スペーシング等）のソースコードを返す |
2. CLAUDE.md
プロジェクトの規約を AI に伝える設定ファイル。
- 「talentx-ui を優先使用」
- 「styled-components は補助的に」
- 「Transient props を使う」
など、コードベース固有のルールを記載しています。
3. figma-to-ui スキル
Figma URL → talentx-ui コンポーネント検索 → 実装方針提案 → コード生成 というワークフローを定義したスキル。AI が迷わず最適な手順で動けるようになります。
検証実験
これらの整備にどれだけの効果があるのか、同一の Figma デザインに対するコード生成実験で検証しました。
対象デザイン
応募者一覧テーブル（8 列 × 7 行、チェックボックス・ステータスドット・ラベルバッジ等を含む複合 UI）。
比較条件
| A（整備済み） | B（未整備） | |
|---|---|---|
| Figma MCP | 可 | 可 |
| talentx-ui-mcp | 使用可 | 不可 |
| CLAUDE.md | 参照可 | 不可 |
| figma-to-ui スキル | 使用可 | 不可 |
| 既存コード参照 | 制約なし | 制約なし |
- A = MCP・CLAUDE.md・スキルを導入済みの環境
- B = Figma MCP だけある環境（既存コードは自由に読める）
両方とも既存コードを参照できる条件にすることで、「MCP やスキルの整備だけが差を生むか」を見ました。
結果
定量データ
| 指標 | A（整備済み） | B（未整備） |
|---|---|---|
| Token 使用量 | 93,276 | 67,592 |
| 所要時間 | 272 秒 | 163 秒 |
A のほうが token・時間ともに多い。MCP への問い合わせ分のオーバーヘッドがあるためです。
コード品質
| 観点 | A（整備済み） | B（未整備） |
|---|---|---|
| テーブル実装 | talentx-ui Table コンポーネント |
<table> タグで自作 |
| チェックボックス | talentx-ui CheckBox |
SVG で自作 |
| ラベルバッジ | talentx-ui Tag |
styled-components で自作 |
| テキスト表示 | talentx-ui Text |
styled-components で自作 |
| ESLint | エラーなし | エラーあり |
| CLAUDE.md 規約準拠 | Transient props 等準拠 | 一部準拠 |
A は talentx-ui を正しく使い、B は既存コードを参照したにも関わらず talentx-ui をほぼ使わなかった。 この差は大きい。
なぜ B は talentx-ui を使わなかったか
B は実は既存コードを自発的に探索していました。
AnalyticsTable.tsxArticleTable.tsxDomainTable.tsx
しかし、これらの既存テーブルが talentx-ui の Table コンポーネントを使っていなかったため、B もそのパターンを踏襲して <table> タグで自作してしまったのです。
既存コードに「正解」がないと、AI は既存の（必ずしも最適でない）パターンに倣う。
これは AI の挙動として理にかなっています。プロジェクト固有のパターンに合わせようとした結果、レガシーなコードを真似てしまう。MCP があれば、こうした「コードベースの惰性」に流されず、UI ライブラリの正しい使い方を AI に伝えられます。
結論
MCP + CLAUDE.md + スキル整備の効果
今回の検証で、これらの整備が AI の UI 実装品質を大きく向上させる ことが確認できました。
- talentx-ui の正しい活用: 未整備では
Tableを<table>タグで自作、CheckBoxを SVG で手書きしていたのが、整備済みでは talentx-ui のTable,CheckBox,Tag,Textを正しく選択・使用できた - 規約への準拠: CLAUDE.md により Transient props の使用や styled-components の命名規則など、プロジェクト固有の規約にも自動で従う
- 既存コードの落とし穴を回避: 既存コードを参照できる環境でも、レガシーなパターンを踏襲してしまう問題を防げる
特に効果が大きい場面
- 既存コードに UI ライブラリの使用例がまだ少ないプロジェクト
- 新しいライブラリやコンポーネントを導入した直後
- 既存コードにレガシーなパターンが残っていて、それを踏襲してほしくない場合
コストとのトレードオフ
MCP を使うと token・時間は増えます（今回は token +38%、時間 +67%）。しかし、レビューでの差し戻しや手直しの工数を考えると、人を含めたトータルコストでは MCP 導入のほうが安い という結論になります。
今後の伸び代
検証で見えた改善ポイントもあります。
Storybook のパターンを増やす
整備済みの A でも、talentx-ui にコンポーネントが存在するのに styled-components で自作してしまう箇所が一部ありました。これは MCP が参照する Storybook のカバレッジに依存するため、Story を充実させることで精度がさらに上がります。
Figma 側のコンポーネント命名・構造を整備する
Figma 上のコンポーネント名や階層構造が talentx-ui の命名と一致していれば、AI がデザインから対応するコンポーネントを特定しやすくなります。デザインとコードの命名を揃えることは、MCP の検索精度を上げる地味だが効果の大きい施策です。
おわりに
Figma MCP は強力ですが、それだけでは社内 UI ライブラリを使いこなせません。社内ライブラリ専用の MCP + プロジェクト規約（CLAUDE.md）+ ワークフロー（スキル）の三点セットを整備することで、AI が出すコードはプロダクションに直接入れられる品質になりました。
token や時間のオーバーヘッドはありますが、レビュー・手直しを含めたトータルでは確実にプラス。社内 UI ライブラリを持っている組織であれば、MCP の整備は検討する価値があると思いました。
