使用中・公開

Figma MCP Bridge

Figmaで選択した要素だけを、実装に必要な情報としてAIコードエディタへ渡すツールです。

追加のDev SeatなしでFigmaの選択ノードをAIコードエディタへ渡す、3人チームのOSSです。私はアーキテクチャ議論とMCPサーバー実装に参加し、Codex連携の調査・設定コミット・日英韓文書を担当しました。プラグイン本体とブリッジ全体を単独実装したものではありません。

リンク

チーム全員が使える低コストのデザイン受け渡し

AIコードエディタを使っても、開発者がFigmaを見ながら色、余白、文字、階層を毎回説明すれば、チーム全体の実装速度は上がりません。また、全員分の有料Dev Seatを用意することも現実的ではありませんでした。

そこで、Figmaで今選んでいる要素をそのままAIコードエディタへ渡し、誰でも同じ手順で使えるチーム向けツールを作ることにしました。

デザインを渡す流れ

選択したデザインだけをコードエディタへ返す

ボタン一つを実装する場合でも、REST APIでFigmaファイル全体を取得すると、関係のないページやノードまでレスポンスへ含まれました。

チーム全員が追加の有料Dev Seatなしで利用でき、選択中のノードから実装に必要な情報だけを返す必要がありました。REST APIの大きなレスポンスを別経路で再現するだけでは目的を達成できません。

チームではDesktop Plugin APIで現在の選択範囲だけを読み、MCPサーバーとWebSocketブリッジを通じて実装に必要な情報を返す方式を選びました。私はこの設計議論とサーバー側の実装・クライアント検証に参加しました。

一つのサンプルノードでRESTレスポンスは2,307行・142KBでした。公開ブリッジはUmaso・Lingdingで使用しましたが、公式Dev Seatとの時間・トークン比較は測定していません。

AIへ多く渡すより、現在の作業に必要な情報を選ぶ方が結果を安定させました。

MCPリクエストはstdio、WebSocket、Figmaプラグインの複数境界を通ります。どこかで止まったときに空のレスポンスや一般的なエラーだけを返すと、利用者は設定・接続・選択のどこを直すべきか判断できません。

Claude Code、Windsurf、CodexはMCPサーバーの登録方法と実行環境が異なります。さらに、Figma未起動、選択なし、複数クライアント接続のように利用者が直接直せる状態も区別する必要がありました。

チーム実装では通信経路の失敗を一つにまとめず、未接続・選択なし・複数接続を区別しました。私は各クライアントで実際の呼び出しを再現し、Codex設定と確認手順をREADMEへ記録しました。

Claude Code、Windsurf、Codexで実際のツール呼び出しを確認し、再現手順を公開READMEへ残しました。接続失敗シナリオの自動テストはまだ追加していません。

連携ツールでは成功レスポンスだけでなく、利用者が次の行動を選べる失敗時の契約もプロダクトの一部だと学びました。

OSSリポジトリは公開中です。チームのブリッジを3種類のクライアントで検証し、私の公開履歴ではCodex設定と日英韓文書コミットを確認できます。Umaso・Lingdingの画面実装でも利用しました。

AIツールを作るとき、最初に『Figmaのボタン実装を速くする』のように短くしたい作業を一つ決めるようになりました。その後、その作業に必要な選択ノード、レイアウト、テキスト、色、余白だけを選び、クライアントが失敗理由を区別できるレスポンスを設計します。

公式Dev Seatより技術的に優れているという比較結果や、実装時間が何倍短くなったという測定値はありません。