figmascope vs Figma MCP
サーバー接続かプレーンファイルか

MCP（Model Context Protocol）はAIエージェントがサーバーインターフェース経由で外部サービスへランタイムツールコールを行えるようにします。FigmaはMCPサーバーを公式に提供しており、コミュニティもいくつかビルドしています。ピッチ：エージェントはFigmaから直接、オンデマンドで、会話の途中でデザインデータを要求できる。エクスポートステップなし。常にライブ。

figmascopeは逆のアーキテクチャ的な賭けをします：一度エクスポートし、バンドルを出荷し、二度と接続しない。これらは本当に異なる選択肢で、異なる含意があります。各々が実際にどんなコストと利点をもたらすかを説明します。

FigmaのMCPサーバーとは

Model Context ProtocolはAnthropicのAIエージェントを外部ツールにサーバーインターフェース経由で接続するためのオープン標準です。MCPサーバーはエージェントが呼び出せる型付きツールを公開します：「get_file」、「get_node」、「get_styles」などです。エージェントがデザインコンテキストを必要とすると、ツールを呼び出し、MCPサーバーがFigmaのAPIを呼び出し、結果が現在のプロンプトのコンテキストとして戻ってきます。

FigmaのMCPサーバーはファイル読み取り、ノード検査、コンポーネント取得、コメントアクセスをカバーします。コミュニティのMCPサーバー（GitHubにいくつかあります）はカスタムスキーマ、追加変換、または特定のエージェントワークフロー向けに最適化されたより狭いスコープでこれを拡張します。

FigmaのMCPサーバーを使用するには、エージェントクライアント（Claude Desktop、Cursor、Continueなど）でそれを設定し、Figma PATを提供し、サーバーがローカルプロセスとして実行されます。エージェントがFigmaコンテキストを必要とすると、ツールを呼び出します。明示的に何もエクスポートしません—エージェントが必要なときに必要なものをフェッチします。

MCPモデルの実際

典型的なMCP対応のFigmaワークフローはこんな感じです：Cursorを開き、会話を始め、「このFigmaファイルのチェックアウト画面を実装して」と言うと、エージェントがget_fileを呼び出し、ノードツリーを取得し、コンテキスト内にデザインデータを持ちます。次に「デザイナーがボタントークンを更新した」と言えば、エージェントは再び呼び出して新鮮なデータを取得できます。

このライブ接続モデルは一部のワークフローでは本物でありとても魅力的です。エージェントは現在のデータで作業します。エクスポートアーティファクトを管理しません。「デザイナーが変更をプッシュした」と「エージェントがそれを持っている」の間に手動ステップはありません。

MCPが優れている点

ライブデータ、エクスポートステップなし。エージェントはオンデマンドで現在の状態をフェッチします。デザインが10分前に変わっていても、エージェントはそれを見られます。figmascopeは変更を捉えるために手動再エクスポートが必要です。

会話的なデザイン探索。「CTAボタンの色は？」「このコンポーネントを参照している画面はいくつ？」MCPを使えば、エージェントはFigmaを呼び出してこれらに答えられます。バンドルでは、答えは最後のエクスポート時点のものです。

Figmaへの直接編集。一部のMCPサーバーは書き込み操作を公開しています—ノードの作成、プロパティの更新、コメントの投稿。これはライブ接続でのみ可能です。静的バンドルには書き込みパスがありません。

手動ワークフローなし。MCPに接続されたエージェントセットアップをすでに使っている開発者にとって、エクスポートステップがないということは忘れることが一つ減ります。コンテキスト管理はエージェントに委ねられます。

MCPが劣る点

ライブ接続モデルには過小評価しやすいアーキテクチャコストがあります。

セッションバウンドの状態。MCPコールは会話セッションのコンテキストで発生します。セッションAでエージェントが取得したデータは再フェッチなしにセッションBでは利用できません。新しいチャットを始めると、エージェントは白紙から始めます。figmascopeバンドルはセッション間、開発者間、ツール間で持続します—ただのファイルです。

gitに対して不透明。アーティファクトがありません。コミットするものが何もありません。コードを通知したデザインコンテキストはリポジトリに存在しません。6か月後にコンポーネントが構築されたときのデザインがどのようなものだったかを理解したくても、記録がありません。リポジトリにバンドルがあれば、デザイン意図のコミット履歴があります。

接続が必要。MCPは動作中のサーバー、ライブFigma API接続、アクセス権を持つPATが必要です。ネットワークダウン、Figma APIダウン、PAT期限切れ—エージェントにはコンテキストがありません。バンドルは飛行機の中でも動作します。

モデル依存の取得。エージェントがMCP経由で要求するものは、何を要求するかを決定するものに依存します。トークン値をフェッチしないかもしれません。コンポーネントインベントリを取得しないかもしれません。必要と思うノードサブツリーだけを要求し、隣接ノードからの空間コンテキストを見逃すかもしれません。取得は確率的であり、決定論的ではありません。figmascopeは固定スキーマで毎回すべてをフェッチします。

テストと再現が難しい。「エージェントがこのFigmaデータからこの時点でこのコンポーネントをビルドした」はMCPでは検証できません。フェッチは一時的です。バンドルを使えば正確に再現できます：同じバンドル、同じエージェント、同じプロンプト—決定論的出力。これはデバッグ、コードレビュー、リリースの説明責任のために重要です。

コンテキストウィンドウへの圧力。複雑なFigmaファイルへの素朴なget_fileコールは巨大なJSONツリーを返します。エージェントはコンテキストバジェット内に収まるためにセレクティブなツールコールをしなければなりません。これは間違いを犯す可能性のあるヒューリスティックと判断呼び出しを導入します。figmascopeは既知の制限されたサイズで必要なものだけを持つ構造化IRにツリーを事前処理します。

figmascopeのバンドルモデル：一度取得して、永遠に出荷

figmascopeはFigma REST APIからプレーンファイルの.zipをエクスポートします—プラグインなし、サーバーなし、ブラウザで動作します。バンドルには以下が含まれます：

• CONTEXT.md — 人間可読な仕様、エージェント可読な仕様
• tokens.json — 型付きデザイントークン、カスケードするソース：Figma変数→頻度から推測→なし
• screens/*.json — レイアウトセマンティクスを持つ画面ごとのIR：スタック、オーバーレイ、アブソリュート、リーフ；INSTANCEノードのcomponentId；テキストのstringRef.key
• screens/*.png — 2倍リファレンススクリーンショット
• components/inventory.json — 完全なコンポーネントインデックス
• strings.json — キー付けされたすべてのテキストコンテンツ
• _meta.json — エクスポートメタデータ

エクスポートされると、バンドルは自己完結していて不変です。それを記述するコードの隣のリポジトリに入ります。どんなエージェントも、どんなセッションも、どんな開発者も、どんなCIジョブも読めます。何への接続も不要です。

バージョン管理可能な差分：バンドルをコードのように比較する

これがバンドルモデルの最も強力な論拠です。出力が構造化されたJSONとMarkdownなので、差分が取れます。

デザインスプリント前にバンドルをエクスポートします。後でもう一度エクスポートします。tokens.jsonにdiffを実行します：

- "spacing.4": "16px"
+ "spacing.4": "14px"

これはスペーシングスケールの破壊的変更です。可視で、レビュー可能で、コミットに追跡可能です。MCPでは、同じ変更は静かに起きます—エージェントが次にフェッチするとき新しい値を取得し、何かが変わったという記録はありません。

これをPRゲートとして実行できます：デザインハンドオフの一部としてバンドルをエクスポートし、コミットし、実装開始前にデザイナーと開発者が差分にサインオフすることを要求します。それはコードとしてのデザイン仕様です。MCPには同等のものはありません。

決定論の論拠

同じFigmaファイルバージョン + 同じfigmascopeエクスポート = 同じバンドル。毎回。IRスキーマは固定です。トークンソーシングロジックは決定論的です。文字列キー抽出はルールベースです。

MCPの取得は決定論的ではありません。エージェントが何をフェッチするかを決定します。異なるエージェント、異なるプロンプトの言い回し、異なるコンテキストバジェット—異なるフェッチ動作。出力はモデル依存です。

本番UIコードジェンでは、決定論が重要です。コンポーネントを生成した仕様を再現可能にしたいです。同じ入力から同じコンポーネントを再生成して一貫した結果を得たいです。バンドルはこれをサポートします。MCPセッションはしません。

比較表

MCPは「Figmaをライブ編集」に輝く—バンドルは「本番UIをビルド」に輝く

これが正直なまとめです。ワークフローが会話的なデザイン探索—「このコンポーネントを変更して」、「この画面にアノテーションを付けて」、「このフレームのカラートークンは何？」—なら、MCPのライブ接続が正しいモデルです。エージェントはデザインプロセスでのコラボレーターであり、そのためにはデータが必要です。

ワークフローが確定した（またはほぼ確定した）デザインから本番UIを構築すること—コンポーネントを実装し、ステートを接続し、テストを書く—なら、バンドルモデルの方が優れています。仕様をリポジトリにアンカーし、デザイン反復にわたって差分が取れ、設定なしでどんなエージェントでも読め、ビルドするのに十分なくらい決定論的にしたいです。

両モデルは補完的です。デザインが流動的で反復的に協力しているときにはMCPを使います。デザインが安定していてエンジニアに実装を引き渡すときにfigmascopeバンドルをエクスポートします。バンドルは実装がビルドされる源泉—追跡可能で、レビュー可能で、再現可能—になります。