Claude Media
Claude CodeでFigmaプラグインを開発する手順
Claude Codeチュートリアル

Claude CodeでFigmaプラグインを開発する手順

Figma Plugin APIをClaude Codeで実装する手順を、manifest.jsonの設定からUI構築、サンドボックスの制約まで扱います。

読了目安 約11分

Figmaのプラグインは、JavaScriptとHTMLだけでFigmaのエディタ機能を拡張できます。公式のPlugin APIドキュメントが示す手順に沿って環境を作れば、あとはmanifest.jsonの設定・TypeScriptでのロジック実装・HTMLのUI構築をClaude Codeとの往復で進められます。ここでは公式クイックスタートの流れをベースに、Claude Codeを使う場合の具体的な手順を示します。

Figmaプラグインとは何をするものか

Figmaプラグインとは、Figmaのエディタ内で動作し、ファイルの内容を読み書きするプログラムです。ロジックはJavaScript、UIはHTMLで書きます。Plugin APIはfigmaというグローバルオブジェクトを通じて公開され、レイヤー(ノード)の色・位置・階層・テキストといったプロパティを操作できます。

対応エディタはFigma Design・FigJam・Dev Mode・Figma Slides・Figma Buzzの5種類で、manifest.jsonのeditorTypeフィールドで指定します(詳細は後述の表)。

ユーザーが同時に実行できるプラグインとアクションは1つだけで、バックグラウンドで動き続けるプラグインは作れません。処理が終わったらfigma.closePlugin()を必ず呼び、Figma側に終了を伝える必要があります。

開発に必要な前提知識と環境

Figmaプラグインの開発にはJavaScriptとHTMLの基礎知識が必須で、公式はTypeScriptとVisual Studio Codeの組み合わせを推奨環境として案内しています。

  • Figmaデスクトップアプリ: プラグイン開発とテストはデスクトップアプリでのローカルファイル読み込みが前提です。ブラウザ版だけでは開発フローが完結しません。
  • Node.jsとnpm: TypeScriptや@figma/plugin-typings、ESLint設定などの依存関係をインストールするために使います。
  • Visual Studio Code(または任意のエディタ): TypeScriptの型補完を活かすなら、公式が推奨するVS Codeが扱いやすい環境です。

この環境が整った状態でClaude Codeを使うと、プラグインのプロジェクトフォルダを直接編集し、npm installやtscのビルドコマンドをターミナル越しに実行できます。Figmaデスクトップアプリとエディタを何度も往復せずに、コードの修正とビルドを1か所で完結させられるのが実務上のメリットです。

Claude Codeで進める開発の流れ

手順は次の6ステップです。Figma側のGUI操作とClaude Code側のコマンド操作が交互に発生します。

  1. Figmaデスクトップアプリで新規デザインファイルを開き、Plugins > Development > New pluginからFigma designとCustom UIを選んでプラグインの雛形を作成する
  2. 生成されたフォルダ(manifest.json・code.js・ui.html・package.jsonを含む)をClaude Codeの作業ディレクトリとして開く
  3. Claude Codeに依存関係のインストールを指示する
  4. manifest.jsonを要件に合わせて編集する(networkAccess・editorType・documentAccessなど)
  5. code.tsにロジック、ui.htmlにUIを実装し、TypeScriptのビルドを回しながら反復する
  6. Figmaデスクトップアプリでプラグインを実行し、挙動をClaude Codeに伝えて修正を繰り返す
cd my-figma-plugin
claude

作業フォルダでClaude Codeを起動したら、依存関係のインストールを任せます。

npm install

このコマンドでtypescript・@figma/plugin-typings・@figma/eslint-plugin-figma-pluginsがpackage.jsonのdevDependenciesからインストールされます。Plugin APIの型定義が入るため、Claude CodeがAPIのメソッド名や引数を確認しながらコードを書けるようになります。

TypeScriptのビルドはVS Codeのビルドタスク(Ctrl+Shift+B、MacはCommand+Shift+B)からwatch-tsconfig.jsonを選ぶとウォッチモードで動きます。生成されたプロジェクトにはtsconfig.jsonが含まれるため、Claude Codeのターミナルから直接ビルドしたい場合はnpx tsc --watchでも同じ結果になります。

manifest.jsonの主要フィールド

プラグインの挙動はmanifest.jsonで宣言します。新規作成時にFigmaが最小限の雛形を自動生成しますが、公開まで進めるなら次のフィールドを把握しておく必要があります。

フィールド型役割
name型string役割メニューに表示されるプラグイン名
id型string役割Figmaが発行する一意のプラグインID
api型string役割対象とするPlugin APIのバージョン
main型string役割プラグインロジック(JS)へのパス
ui型string役割UI用HTMLへのパス(figma.showUI(__html__)で参照)
editorType型string[]役割対応エディタ(figma/figjam/dev/slides/buzz)
documentAccess型"dynamic-page"役割ページの動的読み込みに対応することを示す必須フィールド
networkAccess型object役割プラグインがアクセスできるドメインの許可リスト

公式ドキュメントが示す最小構成の例は次のとおりです。

{
  "name": "MyPlugin",
  "id": "737805260747778092",
  "api": "1.0.0",
  "editorType": ["figma", "figjam"],
  "main": "code.js",
  "ui": "ui.html",
  "documentAccess": "dynamic-page",
  "networkAccess": { "allowedDomains": ["none"] }
}

documentAccessを省略すると、プラグイン起動のたびにファイル内の全ページを読み込もうとし、「Loading n pages for plugin…」という通知がユーザーに表示されます。新規プラグインではdynamic-pageを必ず指定します。

networkAccess.allowedDomainsは["none"](外部通信なし)から["*"](全ドメイン許可)まで指定できます。["*"]を使う場合はreasoningフィールドが必須です。fetchでアクセスするドメインを絞り込むほど、コンテンツセキュリティポリシー(CSP)エラーを避けやすくなります。

UIを構築する — showUIとpostMessage

UIはHTMLファイル1枚で完結させます。figma.showUI(__html__)を呼ぶと、Figma内の<iframe>にそのHTMLの内容が表示されます。プラグイン本体(main threadのcode.js)とUI(iframe内)は別プロセスなので、postMessageによるメッセージパッシングでやり取りします。

UIからプラグイン本体へ送る場合、HTML側は次のように書きます。

<script>
  parent.postMessage({ pluginMessage: "anything here" }, "*")
</script>

プラグイン本体側で受け取るには次のように書きます。

figma.ui.onmessage = (message) => {
  console.log("got this from the UI", message)
}

逆方向(プラグイン本体からUIへ)は次のように送ります。

figma.ui.postMessage(42)

UI側で受け取るには次のように書きます。

<script>
  onmessage = (event) => {
    console.log("got this from the plugin code", event.data.pluginMessage)
  }
</script>

公式はライト/ダークテーマへの追従のため、figma.showUI()のthemeColorsオプションを使い、それが提供するCSS変数をUI側で使うことを推奨しています。

実行環境の制約 — サンドボックスとiframe

プラグイン本体(main thread)はセキュリティのため、サンドボックス化されたJavaScript環境で動きます。ES2020以降の言語機能(async/await・オプショナルチェイニング・BigIntなど)は使えますが、fetch・XMLHttpRequest・setTimeout・DOM操作といったブラウザAPIには直接アクセスできません。

ブラウザAPIを使いたい場合やカスタムUIを表示したい場合は、figma.showUI()で作る<iframe>側にコードを書きます。iframe側は逆にFigmaのシーン(レイヤーの階層)にアクセスできないため、「UIはブラウザAPI担当、本体はFigmaのデータ担当」という役割分担になります。

networkAccessでドメインを制限している場合、許可リストに無いドメインへのアクセスはCSPエラーとしてブロックされます。プラグインが処理を終えたらfigma.closePlugin()を呼ぶ必要があり、呼び忘れるとユーザーには「Running[プラグイン名]」というトースト通知が表示され続けます。

公開前に知っておく制約

Figmaはプラグインの利用状況やエラー・クラッシュのレポートを提供していません。利用状況を把握したい場合は、自前の分析基盤や監視サービスを組み込む必要があります。

サポート窓口もプラグイン開発者が自分で用意する仕組みです。審査申請の際に、メールアドレスかWebサイトのいずれかを連絡先として登録する必要があります。

公開後のアップデートは、Figmaの初回承認さえ通れば再審査なしで即時反映されます。ただしユーザー側から旧バージョンへ戻す手段は無く、変更を取り消したい場合は開発者自身が古いバージョンを再公開する必要があります。

審査に出す前には、想定外の状態でプラグインがどう振る舞うかも確認しておく必要があります。公式のチェックリストは主に次の観点を事前に洗い出すよう案内しています。

  • 選択なし・複数選択・コンポーネントを選択した状態での挙動
  • テキストレイヤーのフォントが見つからない場合の挙動
  • ネットワークがオフラインのときの挙動
  • レイヤーが回転している場合の位置計算
  • ファイルが非常に大きい場合の読み込み範囲

バンドラーを使っている場合は、出力サイズをリリースモードのビルドで確認することも挙げられています。

よくあるつまずき

  • documentAccess: "dynamic-page"を書き忘れると、複数ページのファイルでプラグイン起動のたびに全ページ読み込みが走り、体感速度が落ちます
  • fetchをmain thread側(code.ts)で直接呼んでエラーになります。ネットワーク処理はUIのiframe側に書く必要があります
  • networkAccessのallowedDomainsにアクセス先を登録し忘れ、CSPエラーで通信がブロックされます
  • figma.closePlugin()を呼び忘れ、「Running」通知が消えないまま残ります
  • manifest.jsonのidを手で書き換えてしまうケースがあります。idはFigmaが発行する値なので、新規プラグインの作成フローの外で編集しません
  • 選択中のノードの種類を決め打ちで実装すると、ユーザーが何も選択していない場合や、想定外の種類のノードを選択している場合にエラーになります

自作プラグイン以外にもFigmaとClaudeを繋ぐ方法はあります。デザインからコードを生成したいだけならFigma MCPサーバーの使い方が近道です。Cowork経由でコードとデザインを往復させる運用はCowork Figma連携でコードとデザインを往復させる手順にまとめています。Claude DesignとFigmaの役割分担が気になる場合はClaude DesignとFigmaの違いを確認してください。

まとめ

Figmaプラグインの開発は、Figmaデスクトップアプリでの雛形作成とClaude Codeでのコード編集を往復する形になります。manifest.jsonのdocumentAccessとnetworkAccess、UIとのpostMessageによるやり取り、サンドボックス起因の制約の3点を押さえておけば、公式クイックスタートの流れに沿って実装を進められます。まずCustom UI付きのプラグインを1つ作り、npm installから動かしてみるのが最短ルートです。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →