デザイナーと同じ Figma ファイルで新しい画面を見ている。以前なら、そこにあるのは主に frame、ボタン、テキスト、コンポーネント、プロトタイプのリンクだった。画面がどう見えるか、押したらどこへ進むかを示すものだ。
code layer が変えるのは、この日常的な画面だ。あるインタラクション自体が、動かせる UI code として Figma のキャンバス上に置かれる。デザイナーはそれを複製し、別案を作り、複数の動き方を比べられる。エンジニアやプロダクトマネージャーも、同じキャンバス上で「実際に動くとどう感じるか」を見られる。
設計ファイル、インタラクティブなプロトタイプ、アニメーション検証、実装実験が別々のツールに散らばっていたことを考えると便利だ。ただし便利さは新しい問いも生む。キャンバス上のものがすでに動き、製品のように見えるとき、それがまだ探索なのか、エンジニアに渡せる状態なのかを誰が判断するのか。
Figma は 2026 年の Config で、code layers、Figma Motion、shader fills/effects、generative plugins、Weave tools、より文脈を読める Figma agent を発表した。code layers は、実行できる、または編集できるコードをキャンバス上の設計素材として扱うものだ。shader fills/effects はコードでリアルタイムに計算される視覚効果や素材を指す。Weave tools は AI 画像処理を再利用できるツールとしてまとめる仕組みだ。複数のテックメディアも、Figma が設計、コード、アニメーション、AI ワークフローを一つの共同作業キャンバスに集めようとしている点に注目した。
このミニ講座は、新機能をすぐ導入すべきかを決めるものではない。必要なのは引き継ぎの基準だ。「探索キャンバス」と「納品仕様」を分ける。
まず分ける：キャンバスは自由でよいが、納品は曖昧にしない
Figma は code layers を、コードを新しい設計素材として扱うものだと説明している。重要なのは「Figma が少し CSS を書き出す」ことではない。コードが画像、コンポーネント、テキストと同じように、キャンバス上で議論し、複製し、比較できる素材になることだ。設計レイヤーをインタラクティブな code layer に変えたり、複数案を複製して比べたり、コード内のフローを編集可能な設計レイヤーへ戻したりできる。Motion ではタイムライン、キーフレーム、書き出し形式を Figma 内に置ける。shader や generative plugins は、プロンプトから視覚効果やカスタムツールを作れるようにする。
これらは探索には向いている。チームは「こうしたらどう見えるか」を早く確認できる。デザイナー、プロダクトマネージャー、エンジニアは、すべてが確定するまで待たずに方向を話せる。
しかし、探索が完成品のように見えるほど、引き継ぎリスクは見落とされやすい。キャンバス上の効果が動くことは、次のことを意味しない。
- そのコードが製品アーキテクチャに合っている。
- アニメーションがすべての端末やブラウザで安定する。
- AI が生成したプラグインや効果をチームが保守できる。
- どこが設計意図で、どこが一時的な実験なのかをエンジニアが判断できる。
だから正式な引き継ぎには、明確な確認欄が必要だ。
一つの表で探索キャンバスと納品仕様を分ける
完成度が高く見える Figma プロトタイプを見たら、すぐに「エンジニアに渡せるか」と聞く前に、次の表で分ける。
| 確認項目 | 探索キャンバスで許容できること | 納品仕様で補うべきこと |
|---|---|---|
| コード | code layer でインタラクション案を比べ、実現可能性を確かめる | どのコードがプロトタイプ専用で、どのロジックを正式実装で書き直す、または引き継ぐのかを示す |
| アニメーション | Motion でリズム、遷移、3D 変化、雰囲気を先に見せる | 時間、発火条件、アクセシビリティ代替、性能上の制限を列挙する |
| AI 生成内容 | agent が効果、プラグイン、複数案の生成を助ける | AI 生成部分を明示し、保守性、ライセンス、ブランド整合性を確認する担当者を置く |
| 外部ツール連携 | Notion、Slack、GitHub などから文脈を取得して試す | データ元、権限境界、自動で読ませてはいけない文書を確認する |
| 最終責任 | チームでコメントし、方向性を試す | 引き継ぎ範囲、変更履歴、差し戻し条件を決める責任者を指定する |
この表はプロセスを遅くするためではない。「見た目が完成している」を「納品できる」と誤解しないためのものだ。
導入するなら、まず隔離されたテスト環境として扱う
安全な始め方は、この種の新しいキャンバス機能を「隔離されたテスト環境」として扱うことだ。そこでインタラクション、アニメーション、AI 生成効果を試してよい。ただし、それを正式な製品コードやデザインシステムの代わりにしてはいけない。
小さなチームなら、まず三つのルールを置ける。
第一に、すべての code layer を「探索」「エンジニアリングで書き直し」「参考のみ」のどれかに分類する。コードだけ渡して、どれが使えるのかをエンジニアに推測させない。
第二に、すべての Motion や shader 効果に「失敗したらどうするか」を一行追加する。低性能端末では無効にするのか、スクリーンリーダーには別の説明が必要か、アニメーションが止まってもページは操作できるのか、という確認だ。
第三に、AI が生成したプラグイン、効果、素材には人間の確認担当を置く。ブランド、ライセンス、保守コスト、エンジニアリング引き継ぎを判断できる人であるべきだ。
すぐに切り替えないほうがよい場合
- チームに明確な引き継ぎテンプレートがない。新ツールの前に仕様欄を補う。
- プロトタイプのコードを正式製品に入れてよいか、設計とエンジニアリングの合意がない。先に責任を分ける。
- 製品に高いアクセシビリティ、性能、セキュリティ要件がある。アニメーション、shader、外部ツール連携は先に制限テストをする。
- デザインシステムがすでに混乱している。AI は標準を整理してくれるのではなく、より多くのバリエーションを速く作るだけだ。
このミニ講座の結論
Figma がコード、アニメーション、shader、プラグイン、AI agent を同じキャンバスに置いたことは、設計協業にとって大きな変化だ。早期探索を速くし、プロダクトマネージャー、デザイナー、エンジニアが早い段階で同じ方向を見られるようにするかもしれない。
しかし、引き継ぎ品質は自動では上がらない。本当に時間を節約するのは、キャンバスが完成品のように見えることではない。何が探索で、何が納品可能で、何を作り直すべきで、何を人間が確認すべきかをチームが明確に言えることだ。
Figma のこの新機能群を試すなら、「ツールを乗り換えるべきか」と聞く前に、こう問うほうがよい。同じキャンバスで探索しながら、曖昧ではない納品仕様を残せるか。
生活四コマ
- 共有キャンバスでは、インタラクション、アニメーション、AI 効果が完成品に近く見える。
- チームは、デモを本番可能なものと見なす前に、探索と納品を分ける。
- それぞれの効果を、コード、動き、権限、責任者、代替動作の確認欄に戻す。
- エンジニアに渡すのは、隠れた前提を含む美しいプロトタイプではなく、整理された仕様パッケージだ。
AI 整理カード
この記事の状況に合わせて、AI に整理してもらう
自分の AI チャットツールに貼り付けると、このミニクラスを自分用のチェックリストにできます。BMC は、あなたが AI に貼り付けた内容を見ることはありません。
参考資料
- Figma Blog：Config 2026: New Materials, New Tools and a More Expressive Canvas — https://www.figma.com/blog/config-2026-recap/
- TechCrunch：Figma adds code layers, support for animations, more AI features in new update — https://techcrunch.com/2026/06/24/figma-adds-code-layers-support-for-animations-more-ai-features-in-new-update/
- The Verge：Figma now has AI motion graphics and shader tools — https://www.theverge.com/tech/955831/figma-code-design-tools-config-2026-announcements
