Workflow Lab: デザインとコードの間をエージェントで移動

Workflow Labへようこそ。ここではFigma製品とツールを活用したワークフローのサンプルを紹介します。

架空のSTEM学習アプリRadicleのエンジニアリングチームは、かつてないスピードで業務を進めています。以前は数週間かかっていた作業も、今では数日、あるいは数時間で済むようになりました。しかし、このスピードにもかかわらず、成果はあまり上がっていません。AIが生成したコードが設計仕様から外れてしまうことがよくあるからです。コーディングエージェントにスクリーンショットや開発チケットを提供して作業を依頼していますが、それだけでは正しい出力を得ることができず、チームは修正作業に追われる羽目になっています。

もしAIによる最初の出力結果が、本番稼働に近いものだとしたらどうでしょうか。Figmaに記録された承認済みのコンポーネントやトークンなど、デザインに関するより多くのコンテキストが与えられれば、コーディングエージェントはより少ないプロンプトで開発者の意図を正確に反映できるようになります。このワークフローの例では、Radicleの開発者がFigmaの開発者向けツールを使用して、コーディングエージェントにより詳細なコンテキストを提供し、より高品質なコードを生成できるようにしています。最初のワイヤーフレームから最終レビューに至るまで、開発者が新機能のデザインとコードをどのように密接に連携させているかをご確認ください。

問題

Radicleチームは、学生がインストラクターや他の学生とメッセージをやり取りするための受信トレイを刷新したいと考えています。まず、新しい一括更新フローを追加する予定で、これにはツールバー、モーダル、トースト(一時的な通知)の3つの要素が含まれます。ツールバーでは、ユーザーが自分のメッセージをすべて選択したり、削除したり、未読に戻したりできるようになります。モーダルでは、操作の確認または取り消しを求められます。そして最後に、操作が成功した場合はトーストが表示され、操作を元に戻すオプションも提供されます。

チームのデザイナーがFigma Designで各画面を作成し、プロジェクトの開発者がこれらのデザインをコーディングエージェントに取り込みます。すぐにコードが返ってきますが、UIはずれています。アイコンは一致せず、モーダルの間隔も均一でなく、トーストには失敗したときの状態がありません。開発者がそれを修正するのに、午後いっぱいかかりそうです。その代わりに、一歩後戻りして、Figmaの開発ツールで一からやり直すことができます。

プロンプトの前に計画する

コードを記述する前に、開発者は新しい一括更新フローを定義する画面、状態、および遷移の意図された動作の概要をまとめます。その概要を、PRDおよび現在の受信トレイを構成するコンポーネントのコードとともにエージェントに渡します。その後、FigmaのMCPサーバーと連携したgenerate_diagramツールを使用して、開発者はFigJam内で編集可能なダイアグラムを作成し、3つの要素にわたるフローを可視化します。

• ツールバーの「すべて選択」オプションを選択すると、すべてのメッセージにチェックマークが付く
• 「削除」オプションを選択すると、確認モーダルが開く
• トーストの「元に戻す」ボタンを押すと、ダッシュボードが前の状態に更新される

この図は、エージェントが開発の基盤として活用できる追加の背景情報を提供すると同時に、開発開始前にチームが対応すべき事項を示す役割も果たします。開発者は、FigJamをデザイン担当者とデザインシステム責任者と共有し、両者はSlackのスレッドではなく、図上に直接フィードバックを残します。

エージェントに構築するためのシステムを与える

全員が承認すると、開発者はFigmaのMCPサーバーを通じてFigJamの図をコーディングエージェントに送信します。これにより、エージェントはRadicleのデザインシステム内のコンポーネント、トークン、レイアウトにアクセスできるようになります。

もし開発者がスクリーンショットだけを頼りに作業すれば、コードベースをくまなく調べて適切なコンポーネントを探したり、デザイナーに問い合わせて詳細を確認したりすることになるでしょう。例えば、その12ピクセルの間隔が正しい間隔トークンなのか、そのボタンがリポジトリにすでに存在するセカンダリボタンなのか、あるいはそのモーダルが新しいパターンなのか、それともチームがすでにリリース済みのものなのか、といった点です。その代わりに、FigmaのMCPサーバーを通じて、それらの答えはすべてファイル内に含まれており、エージェントは必要なデザインのコンテキストをすべて得ることができます。

デザインシステムをコードに接続

どのコンポーネントを使うべきか知っていても、それがどう実装されているかまで知っているとは限りません。その部分を担うのがCode Connectで、Radicleのデザインシステム責任者が設定します。まずFigmaから作業を開始し、ライブラリをチームのGitHubリポジトリに連携させることで、各コンポーネントがその実装ファイルを参照できるようにします。次に、コードベース内でボタン、アイコン、モーダルなどのコンポーネント用のテンプレートファイルを記述し、Figmaのプロパティをコードのプロパティにマッピングします。

これにより、開発者がエージェントにFigmaでの選択内容に基づいて構築するようプロンプトすると、Code Connectがインポートすべきコンポーネントを特定するようになります。新しいコードを記述するのに時間とクレジットを浪費する代わりに、エージェントは既存の実装の青写真から作業を開始します。

しかし、一括更新の選択状態は新しい機能であるため、Code Connectがマッピングできない唯一の部分です。一から構築する前に、開発者はsearch_design_systemをプロンプトし、チームのFigmaライブラリ全体から既存の選択コンポーネントを探します。エージェントは、チームが数ヶ月前にリリースした機能の中から類似したコンポーネントを特定します。そこから、エージェントはそのコンポーネントをコードベースで見つけ出し、一括更新フローに合わせて適応させます。結果は、ブランドに即した、Radicleアプリの他の部分とも一貫性のあるものとなり、エージェントはチームがすでに構築したパターンを改めて考案する必要がなくなりました。

ドリフトが発生する前にキャッチ

開発者は確認モーダルのコーディングに取りかかります。しかし、作業中にデザインチームから2つの変更依頼がありました。モーダルの色をブランドカラーの濃い色に変更すること、それとボタンの角の半径を変更することです。デザイナーはRadicleのライブラリにアップデートを公開し、チケットで変更点をフラグ付けします。開発者は手動で変更を加える代わりに、エージェントにドリフトのチェックを依頼します。

コーディングエージェントにget_variable_defsとプロンプトすると、モーダルで使用されているバリアブルが返され、そこにはデザイナーによる変更が反映されています。エージェントはそれらをコード内のトークンと比較し、両方の不一致をすぐに見つけてモーダルを更新します。

本番稼働までの道のり

開発者は、ツールバー、メッセージの選択状態、確認モーダルを完成させました。これら3つはすべて、チームが維持しているコンポーネントから作成されたものです。残るのはトーストですが、これは構築中に作成されたもので、現時点ではコード上にしか存在しません。まだ失敗時の状態が実装されていません。開発者はuse_figmaをプロンプトして、トーストをキャンバスに編集可能なレイヤーとして追加し、デザイナーは「再試行」アクションを追加して、不足していた状態を実装します。次に、デザインシステム責任者が新しいコンポーネントを公開し、Code Connectを使用してコードにマッピングします。これで、このトーストはRadicleのライブラリ内の他の要素と同様に機能するようになりました。

そこから先は、他のリリースと何ら変わりません。開発者がプルリクエストを開くと、その差分は主に機能ロジックです。エンジニアはコードをレビューし、デザイナーはプレビュービルドを確認します。

FigmaのMCPサーバーとCode Connectにより、エージェントはチーム全員が作業しているのと同じシステムにアクセスできるため、チームはAIが生成したコードの修正に時間を費やすことなく、ユーザーエクスペリエンスを形作る細部にまでこだわることができます。構築に費やす時間が増えることは、単に作業が速くなるだけでなく、より質の高い成果につながります。

Figma MCPサーバーをインストールし、お気に入りのコーディングエージェントと連携させることで、エージェントにより詳しいコンテキストを提供できるようになります。チームが最も再利用するコンポーネントのためにCode Connectを設定しましょう。

Workflow Labシリーズのブログ記事を読んで、Figmaでのその他の活用方法を探ってみてください。