figmascope vs Figmaプラグイン
プラグインランタイムかブラウザエクスポートか

Figmaプラグインエコシステムは広大です。トークンエクスポート、コードアノテーション、スタイルガイド、アクセシビリティチェック、コード生成向けのプラグインがあります。「Figmaコードツール」と言えば、ほぼ常にプラグインを指します。figmascopeはプラグインではありません。それが重要な理由と、そうでない場合を説明します。

プラグインモデル

FigmaプラグインはFigmaデスクトップまたはWebアプリ内のサンドボックス化されたiframe内で動作します。現在のファイルのノードツリー、スタイル、コンポーネント、変数を公開するJavaScriptインターフェース—Figmaプラグインアプリ—にアクセスできます。プラグインはこのデータを読み取り、変換して、ファイルに結果を書き戻したり、Figmaの保存ダイアログ経由でユーザーのローカルシステムにファイルをエクスポートしたりできます。

プラグインAPIは豊富です。すべてのノードをトラバースし、計算されたスタイルを読み取り、コンポーネント定義にアクセスし、変数をクエリし、プラグインのUIレイヤーからネットワークリクエストを行うことさえできます。「デザインデータを読み取って何かする」タスクのほとんどに、プラグインAPIで十分です。

プラグインはFigma Communityストアまたはプライベートチームプラグインとして配布されます。ユーザーはFigmaインターフェース経由でインストールします。アップデートはFigmaのプラグインホスティングを通じて提供されます。プラグインを公開した開発者アカウントがアップデートをプッシュでき、ユーザーは次回プラグインを実行するときに取得します。

人気のあるFigmaコードプラグイン：Locofy（Locofy比較で詳述）、Tokens Studio（デザイントークン同期）、Figma to Code（オープンソースのFlutter/SwiftUI/Jetpack Compose）、その他多数の専門化されたツール。

プラグインの制限

Figmaの内部でのみ動作。プラグインを実行するには、Figmaを開いて、ファイルを開いて、プラグインを開いて、エクスポートをトリガーします。プラグインはターミナルから、CIジョブから、スクリプトから、またはFigmaアプリの外部のコンテキストから呼び出せません。CLIはありません。ヒットできるAPIはありません。実行コンテキスト全体がFigma UIです。

ランタイム専用実行。プラグインはバックグラウンドで実行されません。人間がそれを開いてボタンをクリックしたときに実行されます。スケジュールされたエクスポート、自動化されたパイプライン、プログラムによるインテグレーションはプラグインモデルを通じては不可能です。

プラグインストアのゲートキーパー。公開FigmaプラグインをパブリッシュするにはFigmaのレビューと承認が必要です。アップデートには再レビューが必要です。Figmaがレビューポリシーを変更したり、プラグインが自社の利益と競合すると判断した場合、プラグインは削除または制限される可能性があります。プライベートチームプラグインはストアをバイパスしますが、Figmaのサンドボックス内で動作し、FigmaのプラグインインフラストラクチャーにEDEKで依存します。

リソース制約。プラグインサンドボックスはメモリと実行時間が制限されています。複雑な階層を持つ大きなFigmaファイルはタイムアウトを引き起こしたりプラグインをクラッシュさせたりする可能性があります。プラグインUIはiframe内で制限されたアクセスで動作します—Figmaのエクスポートダイアログ以外ではローカルファイルシステムにアクセスできず、メインスレッドからの任意のネットワークアクセスもありません。

クロスプラットフォームの不一致。FigmaデスクトップアプリとWebアプリでは、エッジケースによってプラグインAPIの動作が若干異なります。一方で完璧に動作するプラグインが他方では癖がある場合があります。

チーム配布のフリクション。プラグインを実行する必要があるすべての開発者が個別にインストールします。チーム全体のバージョン一貫性はFigmaの自動更新メカニズムに依存します。特定のバージョンをピン留めする必要がある場合、それは簡単ではありません。

figmascopeの外部アプローチ

figmascopeはプラグインシステムに全く触れません。標準のブラウザタブ—任意のブラウザ、Figmaアプリ不要—で動作し、ユーザーが提供するPersonal Access TokenでFigma REST APIを直接呼び出します。PATはメモリにのみ保持され、どのサーバーにも送信されません。

Figma REST APIはプラグインAPIが利用するのと同じデータソースですが、外部からアクセスします。figmascopeはファイルJSONをフェッチし、クライアントサイド（すべての計算がブラウザで行われる）でノードツリーを処理し、コンテキストバンドルを生成します。APIコールはブラウザから直接FigmaのサーバーへとEDEKで届きます。figmascope自身のインフラストラクチャーはデータパスにありません。

これにはいくつかの含意があります：

インストール不要。タブを開いて、FigmaのURLとPATを貼り付けて、エクスポートをクリックします。インストールするものも、アカウントを作るものも、Communityストアで探すプラグインもありません。ブラウザを持つ誰でも使えます—Figmaユーザーでなく、アプリをインストールしていない開発者も含めて。

原則的にスクリプト化可能。figmascopeはREST APIを基盤としているため、同じ呼び出しをプログラムで再現できます。MITコードベースは検査可能なオープンソースです。ブラウザを開かずにコマンドラインからバンドルをエクスポートするスクリプトを構築したい場合、figmascopeのソースコードはAPIの呼び出し方とレスポンスの処理方法を正確に示しています。

原則的にCI/CD対応。ヘッドレスなエクスポートパイプラインが実現可能です：Figma REST APIコール、同じIR処理ロジック、同じバンドル形式。figmascopeのブラウザアプリはCIで直接動作しませんが（ブラウザツールなので）、アーキテクチャアプローチ—REST API、決定論的処理、プレーンファイル出力—は設計上CI対応です。モデルはGUIを必要としません。

プラグインストア依存なし。figmascopeはドメインでホストされ、GitHubでオープンソースです。FigmaのプラグインインフラストラクチャーやレビュープロセスEDEKに依存しません。Figmaはストアから削除できません。ドメインがダウンしても、リポジトリからローカルで実行できます—完全に静的なHTML/JSです。

Figmaアプリ不要。開発者はFigmaアプリで一度も開いたことのないFigmaファイルのコンテキストを、共有されたFigmaのURLとPATだけを使用してエクスポートできます。エンジニアがFigmaを直接使わないが設計仕様が必要なワークフローで重要です。

プラグインの方が優れている点

公平に言いましょう。プラグインには外部APIアプローチでは再現できない本物の優位性があります。

キャンバス内アノテーション。プラグインはFigmaファイルに書き戻すことができます—アノテーションを追加、コンポーネントプロパティを設定、フレームを準備完了としてマーク、コメントを投稿。figmascopeは読み取り専用です。Figmaの内部でデザインサイドの作業を行うツールが必要な場合は、プラグインが必要です。

ライブキャンバスコンテキスト。プラグインは何が選択されているかを知っています。選択変更に対応し、ノードの更新を監視し、進行中のデザイン作業に対応できます。figmascopeはスナップショットを取ります。ライブキャンバスアクセスはありません。

Figma組織によるチーム配布。チーム全体がFigma組織プランに入っている場合、プライベートプラグインをチームにプッシュするのは簡単です。全員がFigmaインスタンスに持っています。組織内のクロスチーム配布には、プラグインモデルがよくサポートされています。

Figma UI内のリッチなインタラクション。プラグインはパネル内にカスタムUIをレンダリングし、ユーザーインタラクションに応答し、デザイナーの既存ワークフロー内で即座にフィードバックを提供できます。figmascopeのインターフェースは別のブラウザタブ—コンテキストスイッチです。

比較表

データプライバシーの観点

FigmaプラグインがネットワークリクエストEDEKを行う場合、デザインデータはブラウザを離れてプラグインベンダーのサーバーに向かう可能性があります。プラグインのプライバシーポリシーとインフラストラクチャーを信頼することになります。多くのチームにとってこれは許容範囲内です。しかし、NDA下のデザインを持つエンタープライズチーム、機密クライアントファイルを扱うエージェンシーにとっては重大な懸念事項です。

figmascopeの外部アプローチは異なります。すべての処理はブラウザタブで行われます。REST APIコールはブラウザからFigmaのサーバーへ直接届きます（Figmaを通常使用するときにブラウザが行うのと同じコール）。figmascope自身のサーバーはパスにありません。デザインデータはFigmaのAPIEDEK以外のどこにも行きません。PATはメモリにあり、タブを閉じると消去されます。

これはバックエンドベンダーに依存するプラグインに対して外部ブラウザアプローチの構造的な優位性です。

どちらを選ぶか

Figmaプラグインを使うとき：ファイルにアノテーションを付けたり書き戻す必要がある、デザイナーのワークフローの一部としてキャンバス内インタラクションが欲しい、チームが完全にFigmaに入っていてプラグインメカニズムによる配布が便利、またはREST APIアプローチでは再現できない特定のFigma UI内機能を持つプラグインが必要な場合。

figmascopeを使うとき：AIエージェントコードジェン向けのポータブルでバージョン管理されたコンテキストバンドルが必要、インストールなしでストア依存なしにしたい、デザインデータがサードパーティプラグインベンダーに送信されないよう気にする、出力をコードの隣のgitリポジトリに置きたい、またはエクスポートプロセスを説明可能で再現可能にしたい場合。

AIエージェントを使った本番UIコードジェンワークフローのほとんどで、プラグインモデルは取り戻せないフリクションを追加します。プラグインはFigmaで動作します。エージェントはエディタで動作します。プラグインを通じてデザイン仕様を一方から他方に渡すには、手動のコピーペーストか、ディスクに書き込むプラグインが必要です—そして不透明なパイプラインからの不透明なファイルができます。figmascopeの出力は検査可能で、構造化されていて、そのエージェントハンドオフのために明示的に設計されています。