2026年10月15日、FigmaはConfig Indiaで新しい制作フローを発表しました。中心はCode Layers、Figma Specs、そしてFigma MCPの強化です。デザインキャンバスの上でコードを動かし、仕様を書き、AIエージェントがそれを読んで実装する。Figmaは「デザインを見る場所」から「設計・コード・仕様・エージェントのコンテキストが同居する場所」へと性格を変えつつあります。
この記事では、Config India 2026の発表を実務目線で整理します。Code LayersとSpecsで何が変わるのか、Payload連携はどこまで現実的なのか、そして「今すぐ使うか、様子見か」の判断までまとめます。
30秒でわかる結論
- Code Layersは、デザインフレームからインタラクティブなコードレイヤーを作るオープンベータ。GitHubリポジトリの取り込み、Chrome拡張でのサイトキャプチャ、プロンプト生成に対応。
- Figma Specsは、意図・ビジュアル・技術仕様を1箇所にまとめ、チームとエージェントの両方が参照できる仕様書。
- Figma MakeがPayloadバックエンドを自動構築。CMS、DB、API、認証、管理画面までプロトタイプから本番へつなげる。
- Figma MCPはコードレイヤー作成、Specs編集、画像生成に対応し、20の新パートナーを追加。
- 方向性は強い。ただしCode LayersとSpecsはベータで、有料プラン前提。本番導入は「探索用」から始めるのが安全。
何が起きたのか:Config India 2026の発表
今回の発表は、大きく4つの層に分かれます。第一がCode Layers。Figma Design上で、デザインレイヤーをコードレイヤーに変換し、インタラクティブなプロトタイプとして動かせます。第二がSpecs。文章の意図、ビジュアルの探索、技術的な詳細を1つの面にまとめます。第三がPayload連携。Figma MakeがCMS、データベース、メディア、API、認証、管理画面を備えたバックエンドを生成します。第四がMCPの強化です。
既存のFigmaエージェントも10月6日に一般提供され、デザインライブラリにガイドラインを追加してエージェントに読ませられるようになりました。9月30日にはFigma MotionがLottie/dotLottie書き出し、音声、テキストアニメーションに対応しています。デザイン、モーション、コード、仕様、コンテンツが同じプラットフォームに寄ってきたのが今回の特徴です。
何が変わるのか:設計→実装のループ
これまでのFigmaは、デザインを共有し、Dev Modeで数値を確認し、実装はIDEで行うものでした。Code LayersとSpecsが入ると、Figmaの中で「動く方向性」を複数作り、仕様を書き、エージェントに渡せるようになります。
工程 | これまで | Config India後 |
|---|---|---|
方向性の比較 | 静止画のフレームを複数作る | Code Layerを複製して動くUIを並べる |
仕様の共有 | NotionやIssueに分散 | Specsに意図・ビジュアル・技術詳細を集約 |
実装への引き渡し | Dev Modeの数値をコピー | MCP経由でエージェントがCode Layer/Specsを参照 |
コンテンツ駆動の検証 | 別途CMSを用意 | MakeがPayloadバックエンドを生成 |
重要なのは、Code Layersが「実装の正」になるわけではないことです。探索の速度を上げるための素材であり、最終的なコードはリポジトリでレビューする必要があります。
Code Layers:キャンバスでコードを試す
Code Layersは、デザインフレームを変換する、GitHubリポジトリをインポートする、Chrome拡張で既存サイトをキャプチャする、プロンプトから作る、という4つの入口を持ちます。オープンベータで、有料プランなら11月4日まで編集無料とされています。
実務では「1画面だけ、2案を並べる」使い方が現実的です。たとえば料金表のカードを、コードレイヤーでホバーやレスポンシブまで含めて作り、デザインフレームと並べて比較します。デザインシステムのコンポーネントを使っているなら、Code sourcesでGitHubリポジトリやnpmパッケージを取り込み、実際のトークンやコンポーネントに寄せられます。
Code LayersとFigma Makeの違いは?→ Code Layersは「Figmaキャンバス上でコードを素材として扱う」機能、Figma Makeは「プロンプトからアプリを作る」機能です。探索とプロトタイプはCode Layers、データや認証を含むアプリ生成はMake、と使い分けるのが分かりやすいです。
Specs:チームとエージェントのための仕様書
Specsは、文章の意図、ビジュアルの探索、技術的な詳細を1箇所にまとめる仕組みです。これまで仕様はNotion、Figmaのコメント、Issue、Slackに分散しがちでした。SpecsはそれをFigma内に寄せ、エージェントが参照できるコンテキストにします。
デザインライブラリにガイドラインを追加すると、エージェントはライブラリを有効にしたプロンプトのたびにそれを読みます。禁止パターン、推奨パターン、アクセシビリティのルールをmarkdownで書いておけば、Code Layerの生成品質を安定させやすくなります。
最初から全部の仕様を書こうとせず、デザインシステムの「やってはいけないこと」を10個だけ書くのがおすすめです。エージェントの出力が変わったかを測りやすく、Specsの効果を判断できます。
Payload連携:プロトタイプから本番バックエンドへ
Figma MakeがPayloadバックエンドをネイティブに生成できるようになりました。CMS、データベース、メディア、API、認証、管理画面が含まれ、Figmaがホストします。コンテンツとデータが、デザインと同じ場所に置かれるイメージです。
これは制作会社にとって大きい変化です。これまで「デザイン → フロント実装 → CMS構築 → コンテンツ投入」と分かれていた工程を、Make上で一気通貫に近づけられます。ただし、本番運用ではバックアップ、権限、監査、移行性の確認が必要です。プロトタイプの速度と、本番CMSの堅牢さは別物として評価してください。
Figma MCP:エージェントからキャンバスを操作する
Figma MCPは、コードレイヤーの作成、Specsの編集、画像生成をAIツールから実行できるようになりました。20の新パートナーに対応し、パフォーマンスも改善されています。Claude CodeやCursorから、Figmaのデザインシステムを参照しながらコードを生成する使い方が現実味を帯びます。
FigmaのSpecsを読み、既存のデザインシステムに沿って
料金表セクションのCode Layerを作ってください。
禁止パターン(影の多用、12px未満の文字、青以外のCTA)は避けてください。ポイントは、MCPに渡す前にSpecsとガイドラインを整えることです。コンテキストが曖昧なままエージェントに投げると、それらしいが設計意図と違うコードが出てきます。
注意点:ベータとロックインをどう扱うか
- Code LayersとSpecsはオープンベータ。本番の唯一の正にしない。
- Code Layersの編集無料は期間限定。料金体系は契約前に確認する。
- PayloadはFigmaホスト。データ移行とエクスポートの道を確認する。
- 生成コードは必ずレビューし、リポジトリ側の規約・テスト・型チェックに通す。
- デザインシステムのガイドラインは、エージェント向けに短く具体的に書く。
最初の検証は「1画面、2案、1週間」で十分です。Code Layerで探索し、Specsに判断理由を書き、実装は従来どおり人間がレビューする。この範囲なら失敗しても被害が小さく、効果は測れます。
対応状況と使う判断
機能 | 提供状況 | 実務での扱い |
|---|---|---|
Code Layers | オープンベータ(有料プラン) | 探索・比較用。実装の正にしない |
Figma Specs | オープンベータ(有料プラン) | 仕様とガイドラインの集約に使う |
Payload in Make | 全プランで順次 | プロトタイプ検証向け。本番は移行性を確認 |
Figma MCP | 利用可能 | Code Layer/Specs連携に使う |
Code sources | クローズドベータ | デザインシステム連携の要。提供待ち |
自分なら使うか:条件付きで使う。 まずは社内プロジェクトか、クライアントの探索フェーズで試します。Code Layersは「実装の正」ではなく「方向性を早く比較する道具」、Specsは「エージェントに渡す短い設計意図」として使います。本番実装は従来どおりリポジトリで管理し、Code Layersのコードをそのまま納品しない線引きが必要です。
まとめ
- Figmaはデザインだけでなく、コード・仕様・コンテンツ・エージェントのハブになりつつある。
- Code Layersは探索を速くする。ただし実装の正ではなく、レビュー前提。
- Specsはチームとエージェントの共通コンテキスト。短く具体的なガイドラインが効く。
- Payload連携はプロトタイプから本番バックエンドへの距離を縮める。移行性の確認は必須。
- 今はベータ前提で、1画面・2案・1週間の小さな検証から始めるのが現実的。






