飛行中のエンジン構築：Figma MCP サーバーを立ち上げ

Figma が 3 ヶ月で実現した MCP サーバー構築の裏側：AI エージェントがデザインをコードに変える戦略

Figma のエンジニアであるジェシー・ルマリー氏は、MCP（Model Context Protocol）という新しいプロトコルを活用し、わずか 3 ヶ月間で Figma 初の MCP サーバーを製品化しました。この発表は、単なる技術的な実装事例ではなく、デザインツールと開発ツールの境界を AI でどう曖昧にするかという現実的な課題と、その解決策を示す重要なケーススタディです。

不確実な環境での「MCP サーバー」構築

2024 年 11 月、Anthropic が MCP サーバー仕様を発表した際、AI エージェントの世界では実験が始まりました。しかし、OpenAI や Cursor、VS Code など主要なクライアントがすぐに完全対応したわけではなく、仕様のバージョンアップや機能のサポート状況はクライアントごとにバラつきがありました。

「多くの場合、ツール（Tools）のみがサポートされるなど、どの機能を最終的に目指せばいいか見通しが立ちにくい状況でした」

ジェシー氏は当初、Figma の成長部門で「20% プロジェクト」として個人で開発を進めていましたが、その価値を認められチーム化されました。彼らは「MC Peeps（MCP 担当の仲間たち）」として名乗り上げました。

この不確実な環境下でも、Figma は「開発者向けにローカル MCP サーバー」を最優先して立ち上げる決断をしました。なぜなら、AI ワークフローを最初に受け入れるのは開発者であり、彼らが Figma のデザイン情報をコードエディタに直接取り込めるようになることが最も価値が高いと考えたからです。

コンテキストウィンドウを圧迫しない「文脈表現」の最適化戦略

Figma のキャンバスは内部で C++ で記述されたシーングラフ（HTML の DOM 構造のようなノードの繋がり）として管理されています。これを AI エージェントに渡す際、どのように表現するかが最大の課題でした。

1. 画像ベース: 初期案でしたが、AI が画像から CSS を生成するのはまだ精度が低く、また Base64 データをそのまま送信するとコンテキストウィンドウ（AI の記憶容量）を圧迫してしまいます。
2. 内部表現（JSX/XML風）: 抽象度が高く、情報の抜け漏れが発生するリスクがありました。
3. React Tailwind による完全変換: Figma の既存機能「Code Connect」を活用し、デザイン要素を React と Tailwind CSS で記述されたコードに変換します。

「画像とコードの両方を AI に渡すことで、単なる画像よりもはるかに精度の高い出力が得られました。しかし、すべての要素を冗長なコードで埋め込むのはコンテキストウィンドウの無駄です」

彼らの最終的な戦略は、「React Tailwind によるピクセルパーフェクトな記述」と「既存の Code Connect を活用したスパース（疎）なコンポーネント参照」を組み合わせることでした。

具体的には、ボタンなどのデザイン要素を AI に渡す際、HTML/CSS で書き下した巨大なコードブロックではなく、「use ButtonComponent」というように、ユーザーが持つ既存のコードベース内のコンポーネントへのポインタ（参照）を送信します。これにより、AI は「アクセシビリティ」や「国際化」対応済みの、信頼性の高いコンポーネントを正しく使用できるようになります。

手動評価から LLM 判事による自動評価へ

品質を保証するための評価（Evals）プロセスも劇的に進化しました。初期段階では、エンジニアが数百回の実行結果を手動で Excel に記録し、2 時間かけて評価する非効率な作業が行われていました。

「手動での評価は絶対にやめましょう。それは苦痛で、スケーラブルではありません」

その後、Figma は独自の Web アプリを開発し、「LLM 判事（LLM Judge）」による自動評価システムを導入しました。このシステムでは、AI エージェントが生成したコードを週に数百回実行し、変数の使用やテーマの適用、視覚的な美しさなどを AI が判定します。

これにより、人間は不要なループから解放され、プロンプトの変更に対する品質変化だけを監視することに集中できるようになりました。また、Figma ファイルとオープンソースコードがセットになったデータが少ないという課題に対し、独自のテストリポジトリを作成して評価の基盤を固めています。

セキュリティ重視の段階的アーキテクチャ

MCP サーバーの実装において、セキュリティと権限管理は最優先事項でした。特にエンタープライズユーザーのデータを扱う以上、データ流出やファイル権限の侵害は許されません。

そのため、Figma は以下のような段階的なアプローチを採用しました。

1. 初期リリース: Electron アプリ内でのローカルサーバーとして実装。開発者向けに限定し、データの外部流出リスクを最小化。
2. 拡張: 信頼性が確認された後にリモートサーバーへの対応へ移行。

また、MCP 仕様には「サーバーインストラクション（Server Instructions）」や「エリシテーション（ユーザーへの質問機能）」など、クライアント側の実装が追いついていない部分もありました。Figma はこれらの機能が不足している間も、ツール呼び出しごとに AI に具体的な指示を送るなどの工夫で、機能不全を回避しながら製品化を進めました。

まとめ

Figma の MCP サーバー構築は、仕様が未成熟な環境下でも「開発者のニーズ」に焦点を当て、既存の資産（Code Connect）を最大限活用することで、デザインとコードの隔たりを AI で埋める道筋を示しました。これは、単なるツール連携の話を超え、AI エージェントがエンタープライズ環境で信頼して使えるようになるための重要なステップです。