開発者が「Figma インスペクター」を検索する場合、通常 2 つのことのどちらかを求めています。Dev Mode のシートなしでノードのプロパティ値を確認する方法、または Figma コンテンツを AI エージェントに渡す方法です。前者のカテゴリはプラグインで十分に対応されています。後者のカテゴリは figmascope が登場するまでほぼ何も提供されていませんでした。

この記事では 2 つのカテゴリを比較し、それぞれが異なる問題を解決する理由を説明し、エージェントネイティブなエクスポートが実際にどのように見えるかを示します。エクスポートを試すには figmascope.dev にアクセスしてください。実際のワークフローについては Figma から Cursor へまたは Figma から Claude Code へをご覧ください。

「Figma インスペクター」ツールが実際にすること

クラシックな Figma インスペクターは Figma 自身の UI の右パネルです。ノードを選択すると、塗りつぶし、ストローク、エフェクト、寸法、制約、タイポグラフィが表示されます。Dev Mode（2023 年に追加）では、このパネルにコードスニペットが追加されます。ノードから推論された CSS プロパティ、flexbox として表現された auto-layout、Variables が設定されている場合はカラーの変数名などです。

Inspect、Figma to Code、Anima などのプラグインはこれをさらに拡張します。選択されたノードから React や SwiftUI のスニペットを生成するものもあります。CSS ファイルをエクスポートするものもあります。ハンドオフレビューのためにキャンバスに注釈を付けるものもあります。

これらはすべて、画面を見ている人間の開発者向けに設計されています。どのノードが重要かを知っている人が選択した情報を、ノードごとにオンデマンドで表示します。

なぜこのモデルが AI エージェントには機能しないのか

言語モデルは Figma でノードをクリックしながら作業しているわけではありません。コード生成を始める前に、コンテキストウィンドウ内に関連するコンテキスト全体が必要です。ノードごとのインスペクションはフラグメントを生成します。エージェントが必要なのは、スクリーン全体をカバーする構造化されたドキュメントです。階層、トークン値、文字列、コンポーネント参照 — すべてが一度に揃っている必要があります。

フォーマットの問題もあります。Dev Mode は正しいに近い CSS スニペットを生成しますが、フレームワーク間でプロパティ名が異なり、短縮プロパティの展開が必要で、絶対ピクセル値はトークンシステムにマッピングする必要があります。生の Dev Mode 出力を使用するエージェントはトークン名を再ハルシネーションし、スペーシング値を作り上げ、デザインを一度見た人が設計したようなコードを生成します。

インスペクタートールは「このノードは何？」に答えます。エージェントツールは「このスクリーン全体は何で、モデルが推論できるフォーマットになっているか？」に答えます。

Figma インスペクターの代替としての figmascope

figmascope は Figma 内のパネルではありません。ブラウザで動作し、Figma REST API と直接通信し、コンテキストバンドルをエクスポートします。コンテキストバンドルは AI エージェントがデザインを実装するために必要なすべてを含む構造化された zip です。トークンフォーマットの詳細は AI エージェント向けデザイントークンエクスポートに、幅広いハンドオフ哲学は AI デザインハンドオフに記載されています。

エクスポートに含まれるもの：

直接比較

機能 Figma Dev Mode インスペクタープラグイン figmascope
単一ノードのプロパティ値 あり あり なし（目的ではない）
フルスクリーンレイアウトツリーエクスポート なし 部分的 あり — screens/*.json
型付きデザイントークン JSON なし 一部プラグイン あり — tokens.json
AI エージェント向けスペックドキュメント なし なし あり — CONTEXT.md
キー付き集約文字列 なし なし あり — strings.json
コンポーネントインベントリ 部分的 部分的 あり — components/inventory.json
参照レンダリング 手動エクスポート なし あり — screens/*.png（2×）
トークン頻度推論 なし なし あり — Variables なしのファイルのフォールバック
Figma シート不要 Dev Mode シートが必要 プラグインにより異なる 不要 — PAT のみ
プライバシー・アップロードなし Figma がデータを処理 プラグインにより異なる クライアントサイド、api.figma.com のみ

Figma Dev Mode — 正しいことと間違っていること

Dev Mode のコードパネルは、スペーシング値をすばやく確認したり、デザイナーとフォントスタックを確認したりする必要がある人間の開発者にとって本当に便利です。変数リンクは正しい方向への一歩です。Figma ファイルが Variables を適切に使用している場合、Dev Mode は変数名と解決された値の両方を表示します。

AI ワークフローで不十分な点：

Figma インスペクタープラグイン — ランドスケープ

Figma インスペクタープラグインには大まかに 3 つのカテゴリがあります。

  1. プロパティビューア — Dev Mode の右パネルが表示するものを複製します。多くの場合、Dev Mode アクセスがない無料ティアユーザー向けです。例：Figma Inspect、Handoff。
  2. コードジェネレーター — 選択されたノードからフレームワーク固有のコードを生成します。例：Figma to Code、Anima、Locofy。これらは個別選択からコードを生成するものであり、全ファイル構造化エクスポートではありません。
  3. トークンエクスポーター — Figma Variables からデザイントークンをエクスポートします。例：Tokens Studio（旧 Figma Tokens）、Variables2JSON。これらはトークンエクスポート問題を解決しますが、レイアウト IR やエージェントスペック問題は解決しません。

figmascope はこれらのカテゴリのどれでもありません。精神的には「トークンエクスポーター」カテゴリに近いですが、より広い問題を解決します。AI エージェントがスクリーン全体を正しく実装するために必要な完全な構造化コンテキストを生成します。

プラグインランドスケープの詳細な内訳については figmascope vs Figma plugins をご覧ください。

何をいつ使うか

これらのツールは相互排他的ではありません。現実的なワークフロー：

区別は同期的なインスペクション（人間が一度に 1 つのノードを読む）とバッチエクスポート（エージェントが 1 つの構造化ドキュメントで全体像を得る）です。

PAT — アクセスできるもの、できないもの

figmascope は REST API を通じてファイルを読み取るために Figma Personal Access Token を使用します。トークンはブラウザで入力され、セッションのブラウザメモリに存在し、api.figma.com へのヘッダーとしてのみ送信されます。サーバーはそれを受け取りません。タブを閉じると消えます。

必要な最小スコープは File content: read-only です。figmascope は Figma に書き込まず、コメントを作成せず、トークンが読み取り権限を持つ範囲を超えてチームファイルにアクセスしません。完全な脅威モデルについては PAT セキュリティと figmascope をご覧ください。

実際のプロジェクトでの出力

エクスポート後、コンテキストバンドルはソースコードの横に配置されます。

myapp/
├── src/
│   ├── screens/
│   └── components/
├── design/
│   ├── CONTEXT.md          ← agent reads this first
│   ├── tokens.json         ← typed design tokens
│   ├── _meta.json          ← export manifest, warnings
│   ├── components/
│   │   └── inventory.json  ← canonical component names + ids
│   ├── screens/
│   │   ├── Home.json       ← layout IR
│   │   ├── Home.png        ← 2× render
│   │   ├── Profile.json
│   │   └── Profile.png
│   └── strings.json        ← all UI copy, dot-notation keys
└── package.json

これがコミットし、CLAUDE.md または .cursorrules で参照し、エージェントに向けるアーティファクトです。1 回のエクスポートで、必要なすべてのコンテキストが揃います。

典型的なインスペクターワークフローと比較してみましょう。開発者が Figma を開き、ノードを一つずつクリックし、値をコードにコピーし、変数名を見逃し、モバイルパディングのスペーシングを間違え、デザインと実装を突き合わせるのに 20 分費やす。構造化されたエクスポートはエージェントが実装する場合、そのループを完全に取り除きます。

プロジェクトの AI 設定でバンドルを参照する

Claude Code はセッション開始時に CLAUDE.md を読みます。Cursor は .cursorrules を読みます。どちらも AI が何かをする前に方向付けるプロジェクトレベルの指示ファイルをサポートしています。design/ ディレクトリを指す短い design セクションを追加します。

# For CLAUDE.md (Claude Code)
## Design context

All design data is in `design/`. Before implementing any UI:
1. Read `design/CONTEXT.md` for scope and token conventions
2. Use `design/tokens.json` for all color, spacing, radius, and typography values
3. Use `design/components/inventory.json` for canonical component names
4. Use `design/strings.json` for all UI copy — reference by dot-notation key
5. Validate against `design/screens/*.png` renders
# For .cursorrules (Cursor)
Always read design/CONTEXT.md before implementing UI.
Token values are in design/tokens.json — never hardcode colors or spacing.
Component names come from design/components/inventory.json.
UI strings come from design/strings.json with dot-notation keys.

これらが設定されると、プロジェクト内のすべてのエージェントセッションが、繰り返しのプロンプトなしに、design ディレクトリが存在し、どのように使用するかを自動的に認識します。

MCP の代替 — なぜ同じものではないのか

Figma 自身の Model Context Protocol（MCP）サーバーを使うと、AI が Figma API に直接接続してノードをオンデマンドでクエリできます。これは探索的な作業には便利です。「このボタンの色は何？」をライブ会話で尋ねるような場合です。しかし再現可能なバージョン管理されたアーティファクトを生成しません。エージェントが実行するたびに、変更されている可能性のある Figma ファイルを再読み込みします。スコープを説明する CONTEXT.md はありません。安定した名前を持つ事前生成されたトークン辞書はありません。異常なレイアウトの警告システムもありません。

figmascope と Figma MCP は異なる問題を解決します。MCP はオンライン、ライブで、インタラクティブな探索に適しています。figmascope は実装時の決定論的なコード生成に適した、オフライン、バージョン管理済み、構造化されたアーティファクトを生成します。詳細な比較については figmascope vs Figma MCP を参照し、AI デザインワークフローのさらなる詳細については figmascope ブログをご覧ください。