FigmaのDev Mode MCPサーバーを使用するための5つのヒント

新しい仕事の初日を思い出してください。おそらく、次のような流れだったでしょう。新しいチームメイトに会い、オンボーディング資料をもらい、どうすれば最善の方法でその仕事に取り組むかを考え始めたはずです。それでは、構造もコンテキストもなく、ただ新しいツールや情報が入ってくるだけで、それを理解するための地図がない状態を想像してください。

それはまさに、AIエージェントに生の非構造化デザインデータを渡したときに、エージェントに期待していることに似ています。FigmaのDev Mode MCPサーバーは、デザインファイルからのコンテキストをAIエージェントに提供し、より効率的で正確なデザイントゥコードのワークフローを可能にします。効果的なオンボーディング体験が整理された文書と明確な期待値に依存しているのと同様に、インプットの質を向上させるための手順を踏むことができます。これは最終的にアウトプットの質を向上させます。ここでは、あなたが使用するAIエージェントが、実際にあなたのチームに必要なものと一致し、より一貫したコードを生成するための5つの実践的なヒントを共有しています。

1. 安定したデザイン構造から始める

デザインとコードの世界はそれぞれに構造の定義を持っています。デザインにおいて構造とは、より包括的な全体像を指します。各要素の配置、それらがどのようにレイアウトとして集結し、全体としてどのようなエクスペリエンスを提供するかです。コードにおいて、構造とは、コードが効果的にコンパイルされ機能するために従わなければならない特定の規則、構成、および構文を指します。構造には「正しい」アプローチはありませんが、これらの違いを認識し、可能であればそのギャップを埋めることが重要です。

デザインとコードを整合させる方法

デザインをより簡単にコードに翻訳するための構造化方法をいくつか考えてみましょう。

• 外側から内側へのアプローチを取る: 要素の最も外側にあるセクションは何ですか?カードですか? Webページのセクションですか? 何であれ、外側から始め、最上位レイヤー内に追加の要素をネストします。
• レイヤーに名前を付ける: デザインは何を表していますか? それは何で作られていますか? 例えば、フォームボックスでは、入力欄、ボタン、リンクなどにラベルを付けることで、より良い結果が得られます。
• コンポーネントを使用する: コンポーネントは、デザインからコードへの翻訳を支援するだけでなく、将来のデザインに繰り返しパターンを作成するのにも役立ちます。

2つのフォームボックスの物語

これらの原則が実践されている例を見てみましょう。ここに2つのフォームボックスがあります。

一見したところ、これらのフォームは非常に似ているように見えます。それらは同じ方法で整理され、同じ要素を含み、全体として同じことを伝えます。どちらもデザインの観点から「正しく」構造化されていますが、1つはコードに最適化されており、もう1つはそうではありません。レイヤー構造を掘り下げてみましょう。

左側には、コンポーネントレイヤーに明確な構造と名前があります。右側には、要素が単一のレイヤーにまとめられています。レイヤーの命名と構造を明確にすることは、デザインに視覚的な影響を与えないかもれませんが、そうすることで、AIエージェントが左側のデザインに対して高品質で関連性の高いコードを生成するのがはるかに容易になります。

右側のデザインでは、AIエージェントはこれを単一の要素と解釈し、その中に含まれるすべての要素をその単一のコンテナに追加しようとする可能性が高いです。その結果、スペースやレイアウトの問題が発生し、開発者は手動で修正する必要があります。

2. 共通のバリアブル言語に整合する

最近のデザインから開発者へのハンドオフに関するガイドで、チーム間での共通言語を通じた整合の重要性について話しました。多くの点で、Dev Mode MCPサーバーは、デザイナーとAIエージェントの間のハンドオフツールと考えることができます。デザインから開発者へのハンドオフと同様に、AIエージェントへのハンドオフもスタイルやバリアブルなどの共通言語を作成することに左右されます。それにより、組織が確立したデザインパターンにAIエージェントを整合させることができます。

バリアブルをコードに翻訳する

MCPサーバーの出力を最適化するための優れた方法は、バリアブルにコード構文を設定することです。デザインでコード構文を持つバリアブルを使用する場合、バリアブルの値とその構文は、コード出力の一部としてAIエージェントに送信されます。AIエージェントがデザインのコンテキストをよりよく理解し、一貫性のある出力を実現するための方法は次の通りです。

• 命名規則を強制する: 新しいバリアブルが既存のデザインシステムバリアブルと一致していることを確認してください。
• 構文を伝える: 特定のフレームワークでは、コード内でバリアブルを使用する際に異なる構文が必要となるため、エージェントが適切な構造化方法を理解していることを確認してください。
• レスポンシブを作成する: AIコード生成でハードコードされたサイズ指定は避けてください。適切なブレークポイントに一致するように、コンポーネントをどのように構造化すべきかをエージェントに指示するようにします。

大規模なバリアブル変更の適用

一般的に、値のハードコーディングは避けるようにしてください。これを行うと、維持すべき表面積が大きくなりすぎる可能性があります。例えば、将来的にブランドの刷新を決定した場合、カラーパレットやフォントのスタイリングを含め、多くのWeb上の表示を更新しないといけないかもしれません。バリアブルを使用すると、こうした変更は簡単になります。スタイルシートを更新するだけで、バリアブルが使用されているすべての場所に新しい値が適用されます。AIが大量のコードを生成する能力を持つ今、このレベルの一貫性を強制することは重要です。

新しい共通言語の徹底

生成だけでなく、監査についてはどうでしょうか? Dev Mode MCPサーバーを使えば、デザインバリアブルとコードベースの間に不整合があるかどうかを識別することもできます。このサーバーは、get_variable_defsと呼ばれるツールを提供しており、指定された選択内のバリアブルをコードベースのスタイルシートと照合し、一貫したパターンの使用を強制します。

3. アノテーションでデザインの意図を伝える

デザインは、多くの場合、より動的なものを静的に視覚表現したものです。ビジュアルデザインで見えるものだけでなく、コードに変換する際には、状態のロジック、応答性、アクセシビリティガイドラインなど、見えない状態も考慮しなければなりません。コラボレーターはデザインから状態のロジックを見分けることができるかもしれませんが、LLMはそうではありません。LLMはMCPサーバーを介して提供される生データを見て、それをプロンプトによって与えられたタスクを完了するために使用します。ユーザーがこれに対処する方法の1つは、さらに複雑なプロンプトを作成することです。ところが、興味深いことに、プロンプトがより簡潔で具体的なときのほうが、LLMはより良い成果を上げる傾向にあります。

LLM向けツールチップとしてのアノテーション

アノテーションはAIエージェントにコンテキストを提供するための重要な手段であり、デザインに直接表れないデザインの意図を伝えることができます。カテゴリを含むアノテーションデータは、Dev Mode MCPサーバーの応答に含まれています。コード作成のガイドとなるアノテーションのサンプルを以下に紹介します。

• アニメーションとホバーエフェクトを指定する: テーブルの行にズームエフェクトを適用したり、ホバー時に背景色を黒200に変更したりできます。
• 状態変化を伝える: ユーザーがボタンの値に対応するページ名のページにいる場合、ナビゲーションボタンは無効にする必要があることを伝えます。
• コンテンツソースへの指示: 特定のセクションついて、CMSから動的に取得されること、および特定のサイズを超えた場合にページネーションを使用すべきことをアノテーションで指示します。

デザイナーとツール双方にとってのメリット

AIエージェントに意図を伝達するほかにも、アノテーションをこのように使用することで、デザイナーの時間が実際に節約されます。上記のナビゲーションボタンの例を取り上げます。ナビゲーションパネルにオプションがいくつあるかによって、個々の状態のためのデザインを作成しなければならない場合があります。アノテーションを使用することで、そのデザインのコンテキストでエージェントに状態を構築させることができます。

4. ルールでガードレールを作成する

アノテーションはデザインの意図を伝え、望んでいる機能を表現するのに役立ちますが、実際のコードでレイアウトがどのように機能するかや、バックエンドのデータ構造がどのように設定されているかなどを伝えるにはあまり適していません。そこでルールの出番です。アノテーションがツールチップのようにフレームごとや反復ごとに異なる指示を提供するならば、ルールはデータをどのように解釈し、タスクを完了するかの枠組みを作るハンドブックのようなものです。何をルールとすべきか、それとも単なる指示にとどめるべきかを判断するには、「このタイプのリクエストをするたびに、エージェントにこのアクションを正確に実行させたいか?」と自問してください。

ルールの構造化方法

Cursor、Windsurf、VS Code (Copilot指示と呼ばれる)のようなエディター用のルールは、比較的簡単に作成できます。マークダウン形式でファイルを書き、指定されたディレクトリに保存し、ルールを手動または自動でどのように呼び出すかを設定します。これらのルールファイルで指定できることを、次にいくつか紹介します。

• 既存コンポーネントの使用: エージェントに既存のコードの場所を示し、重複を防ぎます。
• 推奨されるレイアウトプリミティブとスタイルガイド: レスポンシブデザインを確保するための措置は既に講じているので、それらが確実に使用されていることを確認します。
• 組み込むべきデータソース: コードベース内のデータ構造を伝えることは、プロンプトだけを使うよりも簡単です。
• ファイル整理と命名パターン: 新しいコードを書くときは、既存のディレクトリ構造に準拠するようにしてください。

5. 反復を恐れない

AIエージェントがチームの新人エンジニアのような存在だとすれば、エンジニアが実際にどのように働くかを考えることが重要です。AIエージェントは、おそらく一度の試行で問題を解決することはないでしょう。プロンプトは、多くの場合、会話の始まりに過ぎません。初回のプロンプトで良い結果が得られることも多いですが、問題点を修正するために調整を加え、エージェントに再度プロンプトする必要があるでしょう。それは悪いことではありません。ツール呼び出しを再実行させて正しい情報が反映されているか確認するか、プロンプトを調整してビルド手法を変更できます。Dev Mode MCPサーバーを使用するメリットは、プロンプトを続けて調整することで、AIエージェントがデザインコンテキストを把握するようになり、関連する出力を生成できることです。コンテキストを把握している結果として、より少ないエージェント対応で成功基準を達成できます。

AIの情勢は変化していることを忘れずに

AIの進歩は驚くべき速さで進化しています。この急速な変化のペースは刺激的ですが、今日ここにあるものが明日も同じとは限らないことを忘れないでください。ベータ期間中に、私たちは素晴らしいユーザーフィードバックと変化する仕様に基づいて、すでに多くの改善と新機能を導入しました。デザインに基づいたより良いコード生成を達成するには、変化する状況に柔軟に対応することが重要です。