grab/cursor-talk-to-figma-mcp: AIエージェントからFigmaを操作するMCPサーバーの実像

このツールが埋める溝は何か

AIエージェントはテキストやコードを扱えるが、Figmaのキャンバスには手が届かない。デザインファイルの中身はFigmaのプラグインAPIの内側にしかなく、エージェントから見れば不透明な外部状態である。cursor-talk-to-figma-mcpは、Model Context ProtocolのサーバーをFigmaプラグインとWebSocketでつなぎ、エージェントがFigmaのノードを読んだり書き換えたりできるようにする。READMEの冒頭は「reading designs and modifying them programmatically」と述べており、読み取りと変更の両方が対象だと明記している。想定読者は、CursorやClaude Codeを日常的に使い、Figmaの反復作業をエージェントに委ねたいデザイナー兼エンジニア、あるいはデザインとコードの往復が多いプロダクトチームである。

3つのプロセスがWebSocketでつながる構成

リポジトリの構成は3つに分かれている。src/talk_to_figma_mcp/はTypeScriptで書かれたMCPサーバー、src/cursor_mcp_plugin/はFigma側のプラグイン、src/socket.tsは両者をつなぐWebSocketサーバーである。データの流れはこうだ。エージェントがMCPツールを呼ぶと、MCPサーバーがWebSocket経由でFigmaプラグインに要求を送り、プラグインがFigmaのプラグインAPIを叩いて結果を返す。つまりエージェントはFigmaに直接触れず、常にこの中継を経由する。READMEの利用手順には「Connect the plugin to the WebSocket server by joining a channel using join_channel」とあり、プラグインとサーバーの対応付けはチャンネル名で行う。複数のFigmaファイルを同時に扱う場合、このチャンネル設計が分離の単位になる。

セットアップはbun setupとbun socketの2コマンド

ランタイムはBunである。READMEはまず「curl -fsSL https://bun.sh/install | bash」でBunを入れ、次に「bun setup」を実行する。このコマンドはCursorのアクティブプロジェクトへのMCP登録も兼ねる。その後「bun socket」でWebSocketサーバーを起動する。手動で設定する場合は~/.cursor/mcp.jsonにmcpServersブロックを書き、commandにbunx、argsにcursor-talk-to-figma-mcp@latestを指定する。ローカルで開発する場合はcommandをbunに変え、argsにリポジトリ内のsrc/talk_to_figma_mcp/server.tsのパスを渡す。Figma側はPlugins > Development > New PluginからLink existing pluginを選び、src/cursor_mcp_plugin/manifest.jsonを指定する。WindowsとWSLの組み合わせでは、src/socket.ts内のhostname: "0.0.0.0"のコメントを外す手順がREADMEに明記されている。これを忘れるとWSL側から接続できない。

ツール群は読み取りより編集に厚い

MCPツールの一覧を眺めると、このプロジェクトの重心が見える。読み取り系はget_document_info、get_selection、read_my_design、get_node_info、get_nodes_info程度で、選択中のノードを取得する用途が中心だ。一方で編集系は厚い。テキストはscan_text_nodes、set_text_content、set_multiple_text_contentsによるバッチ更新、レイアウトはset_layout_mode、set_padding、set_axis_align、set_layout_sizing、set_item_spacing、スタイルはset_fill_color、set_stroke_color、set_corner_radius、set_image_fillが揃う。コンポーネント周りではget_instance_overridesとset_instance_overridesがあり、READMEは「Propagate component instance overrides from a source instance to multiple target instances」と説明する。単一ノードをちまちま触るより、多数のノードに同じ変更を流す設計だと読める。

向かない場面: 破壊的操作と同時編集

この構成にははっきりした弱点がある。delete_nodeやdelete_multiple_nodes、set_parentのような破壊的・構造変更的なツールがエージェントに公開されている以上、エージェントの誤解釈がそのままFigmaファイルの破壊につながる。READMEには取り消しやドライラン、変更前のスナップショットに関する記述が見当たらない。また、WebSocketサーバーはチャンネル単位でプラグインと結びつくため、同じファイルを複数人が同時に編集している状況での競合解決については何も述べられていない。単一のエージェントセッションが一つのファイルを占有する使い方が前提だと考えるのが妥当である。加えて、MCPサーバーはローカルで動く前提のツールであり、チーム共有のサービスとして常時稼働させる設計はREADMEからは読み取れない。

Figma REST APIとの違いはどこにあるか

比較対象として自然なのはFigmaのREST APIである。REST APIはHTTP経由でファイルの読み取りやコメント操作を行えるが、実行にはアクセストークンとネットワーク越しのリクエストが必要で、操作できる範囲もAPIが公開している範囲に限られる。cursor-talk-to-figma-mcpはFigmaプラグインの内側で動くため、プラグインAPIが許す操作、たとえばオートレイアウトの各プロパティやインスタンスのオーバーライド、プロトタイプのリアクション取得といったキャンバス寄りの操作に届く。逆に、CI上で定期実行するようなバッチ処理にはREST APIのほうが素直である。エージェントとの対話的な編集が目的ならMCP、スケジュールされた自動処理が目的ならREST API、という住み分けになる。

ライセンスと保守コストの見積もり

ライセンスはMITである。商用・非商用を問わず利用と改変が許されるが、これは法的助言ではないので、自組織のポリシーに照らした確認は別途必要になる。保守の観点では、このプロジェクトはMCPサーバー、WebSocketサーバー、Figmaプラグインの3つのコンポーネントを同時に動かす必要があり、Figma側のプラグインAPIの変更やMCP仕様の改訂がどれか一つに影響すれば全体の更新が要る。READMEにはリリースノートやバージョン互換性の記述がなく、更新の頻度や破壊的変更の予告を事前に把握する手段は提供されていない。依存を固定したい場合は、bunxの@latestではなくローカルのserver.tsを指す設定に切り替え、リポジトリを特定のコミットに固定する運用が現実的である。

編集部の結論

向いているのは、Figmaのテキスト差し替えやインスタンスのオーバーライド伝播のような反復作業を、CursorやClaude Codeのセッションから一括で流したいチームである。逆に、本番のデザインシステムを自動生成させたい場合や、複数人が同時に同じファイルを編集する現場には向かない。試す前に、src/socket.tsのホスト名設定、join_channelのチャンネル名、そして手元のFigmaプラグインがsrc/cursor_mcp_plugin/manifest.jsonと一致するかを確認したい。特にWSL環境では0.0.0.0のコメントアウトを外さない限り接続が成立しない点が、最初の関門になる。

公式情報源

1. grab/cursor-talk-to-figma-mcp on GitHub
2. Issues
3. License: MIT
4. Project website
5. README