Figma Code Layers Beta、動作するプロトタイプで共同探索を実現
Figmaによると、code layers betaは現在ユーザーの100%に提供されており、チームがすでにデザインをレビューしているキャンバス上に、動作するプロトタイプを直接配置できるようになった。実行中のコードに支えられたインタラクティブプロトタイプであるcode layersは、見た目と並べて挙動を比較するための共有スペースをデザイナーに提供する。この変更は、別の場所で実験を作成し、全員が評価できるようリンクを持ち帰るという、なじみ深いワークフローに見直しを迫る。
今回の発表は、まったく新しいローンチというより提供範囲の拡大に関するものだ。Figmaの11月4日のワークフロー投稿では全面展開が説明されている一方、ドキュメントでは最初のオープンベータを2026年10月15日としている。この違いは重要だ。直近の問いはアクセス可否から、実用性へと移っているためである。チームは現在、共有キャンバスが設計と実装の間に新たな経路を設ける価値を正当化するほど、意思決定を改善するかどうかを評価できる。
Framerはすでにキャンバス上でcode componentsを提供しているため、ビジュアルワークスペース内でコードを動かすこと自体は新しくない。Figmaの訴求の中心は共同探索にある。実装を確定する前に、代替案を保持し、外観を編集し、アイデアを組み合わせることだ。中核となる緊張関係は、プロトタイプを議論しやすくすることと、その変更をリリース可能な状態にすることの間にある。
Figma Code Layers Beta、共有レビューの対象領域を拡大
重要な変化は、動作する実験を、周囲のデザインと同じレビュー空間の一部にできることだ。
Figmaはcode layers workflowで、コードのインポート、代替案の生成、抽出したデザインの調整、探索結果の組み合わせについて説明している。デザインファイル内の対話型AIアシスタントであるFigma agentが、こうした変更の実行を支援する。この投稿では、Pickupという架空のマーケットプレイスを例に、デザイナーが既存の地図体験と並行して配送先住所の選択を検討する様子を示している。
架空の例は、結果を証明せずともワークフローを説明できる。PickupはFigmaが意図する手順を理解するうえでは有用だが、独立して測定された導入事例と捉えるべきではない。この発表には、すべてのチームで開発サイクルが短縮される、あるいはより良いインターフェースが生まれると結論づける根拠は示されていない。
それでも、実験を置く場所によって、レビュアーが議論できる内容は変わる。スクリーンショットが捉えられるのは特定の時点での見た目だ。動作するプロトタイプなら、誰かがインタラクションを試し、周囲のデザインに戻り、より広い視覚的文脈を失うことなく別の方向性と比較できる。
たとえば、住所選択UIをめぐって意見が割れるレビューを考えてみよう。魅力的なレイアウトでも、場所を選んだ後の遷移が不自然であることを隠してしまうかもしれない。反対に、視覚的には簡素な代替案のほうが、タスクを明確にする可能性もある。挙動を外観の隣に置くことで、議論にはより直接的な根拠が加わる。
だからといって、フィードバックが自動的に正確になるわけではない。レビュアーは依然として、何を試したのか、なぜその違いが重要なのかを特定して説明する必要がある。目的を誰もラベル付けしなければ、動作する代替案で埋まったキャンバスは、プロトタイプへのリンクで埋まったフォルダと同じくらい混乱しうる。
機会となるのは、実験とともに問いを可視化し続けることだ。あるバリエーションは、ユーザーが入口を理解できるかを検証するものかもしれない。別のものは、確認前にどこまでの情報を提示すべきかを検証するかもしれない。両方のプロトタイプに似た画面が含まれていても、これは異なるプロダクト上の問いである。
この区別は、生成された出力が意思決定そのものになるのを防ぐことにも役立つ。agentはもっともらしい代替案を提示できるが、どの案がユーザーに最も適しているかまでは確立しない。評価基準を選び、不足している証拠を見極める責任はチームに残る。
したがって、この展開を評価する読者にとって、提供開始は出発点にすぎない。より重要な問いは、共有スペースによって意見の対立を解決しやすくなるかどうかだ。全員が代替案を見られても、誰も選択理由を説明できなければ、ワークフローは移動しただけで説明責任は高まっていない。
Figma code layers betaは、より広い利用者層にとってこの問いを実践的なものにする。チームはFigmaのワークフローデモンストレーションを検証すべき提案として扱いながら、共同作業モデルを直接評価できる。
デザイナーと開発者はより早い段階でのすり合わせに直面する
共有プロトタイプは、方向転換のコストがまだ比較的低い段階で、実装に関する会話の一部を前倒しする。
Figmaのcode layers documentationでは、デザイン、プロンプト、ウェブページ、または接続されたコードから始める方法が説明されている。また、編集可能なデザインレイヤーを抽出し、その変更をcode layerへ戻すこともサポートしている。ドキュメントでは、code layersがすべてのリポジトリで機能するわけではないと注意を促している。
この最後の条件が、誰に影響が及ぶのかを明確にする。デザイナーはインタラクションを具体化する別の手段を得るが、開発者はその実験が実際のプロダクトをどこまで反映しているかを判断しなければならない。プロダクトマネージャーは、説得力あるデモと、合意された実装範囲を区別する必要がある。
隠れた依存関係を明らかにできるなら、開発者の早期関与には価値がある。プロトタイプでは、ユーザーの操作後に即座に応答するように見えるかもしれない。しかし本番プロダクトでは、サービスの応答待ち、権限確認、ローカルでは取得できない情報の処理が必要になる場合がある。
これらは、Figmaの機能で文書化された不具合ではなく、工学的な懸念を例示したものだ。動作するインターフェースが、すべての実装上の問いに答えられない理由を示している。プロトタイプが確立するのは実験内で誰かが体験できることだが、本番レビューは組織が信頼して提供できることを確立する。
この圧力はレビューのプロセスそのものにも及ぶ。デザイナーが動作する代替案を会議に持ち込めるなら、「もっと明確にしてほしい」という曖昧な要求は維持しにくくなる。参加者はインタラクションを指し示し、どの部分が不確実性を生むのかを説明できる。
一方で開発者は、同じ議論を使って、視覚的な判断とアーキテクチャ上の判断を分けられる。ボタンラベルであれば、すぐに採用できるかもしれない。新たなリクエストの流れには、より広範な技術的変更が必要になる可能性がある。こうした判断を分けておくことで、有望なインターフェースに非現実的な納期の約束が付随するのを防げる。
したがって、Figma agent prototypingは責任を変えるというより、共同作業のタイミングを変える。デザイナーは引き続きデザイン上の判断を担う。エンジニアは引き続き実装を評価する。プロダクトリーダーは、提案された体験が取り組む価値のある問題を解決するかを引き続き判断する。
参加に関する問いもある。プロトタイプを生成する人だけが評価方法を理解しているなら、共有ワークスペースの価値は限られる。レビュアーは毎回説明付きの案内を必要とせず、関連する挙動を探索できるだけの文脈を得る必要がある。
組織にとって有用な導入シグナルは、レビュー後に判断がより明確になることだ。成功したセッションでは、望ましい方向性、未解決の前提、リリース前に必要な作業を特定できるはずである。より多くの代替案を生み出すことは、それらが意思決定を改善する場合にのみ有用だ。
既存のワークフローが圧力を受けるのは、実験と集団評価を分離しているからである。Figmaのアプローチは、それらの活動をより近づける。この近接が手戻りを減らすかどうかは、各チームが自らのプロジェクトを通じて確かめるべきことだ。
Agentは視覚的探索と動作する挙動をつなぐ
Figmaの提案で最も強い部分は、周囲の議論から離れずに、挙動と視覚的な詳細の間を行き来できることだ。
分析的に言えば、これはフィードバックループである。チームはインタラクションを試し、デザイン上の問題に気づき、該当する外観を修正し、更新された挙動を評価する。重要なのは、それぞれの修正を、そのきっかけとなった問いと結び付け続けることだ。
この区別が重要なのは、インターフェースの品質が局所的な詳細とより大きな一連の流れの両方に関わるためである。余白は、操作が利用可能に見えるかどうかに影響する。文言は、選択後に何が起こると人が予想するかを変えうる。遷移は、視覚的にバランスの取れた画面が、誤ったタイミングで情報を求めていることを明らかにするかもしれない。
こうした論点の間を移る場面で、レビューはしばしば精度を失う。会話は観察可能な問題から始まり、その後、スタイルに関する一般的な好みへと変わる。動作する体験を視覚的探索の近くに保つことで、参加者は元の根拠に立ち返る手段を得られる。
Figmaの顧客向け資料は、この解釈をある程度支持している。customer prototype examplesでは、Checkout.comのデザイナーであるKris Murphyが画面を抽出して一緒に確認し、その後に視覚的編集をプロトタイプへ戻した事例が紹介されている。同じコレクションでは、SupersideのLeonardo Ricaが、インタラクティブなカードのコンセプトを探索する際に、正確な寸法とモーションの詳細を提供したことも説明されている。
これらはFigmaが公開した、実名の顧客による説明であり、独立した比較ではない。機能の利用方法を示してはいるが、典型的な成果を確立するものではない。共通して有用なのは具体性だ。誰かが何を検査または修正すべきかを理解しているとき、ワークフローはより意味を持つ。
たとえば、チェックアウトのインタラクションを評価するチームは、文言に関する不確実性とナビゲーションに関する不確実性を分けることができる。両方を同時に修正すると、なぜ結果が良く感じられるのかを理解しにくくなる。比較を残しておくことは、検証している意思決定に議論の焦点を保つのに役立つ。
これは比較による分析上の利点であり、Figmaが自動的に統制実験を行うという主張ではない。チームは依然として、条件を十分に一貫させる必要がある。異なるサンプルコンテンツや欠けた状態によって、無関係な理由から一方の代替案が優れて見える場合がある。
探索を組み合わせる場合も、同じ注意が必要となる。魅力的な機能をまとめても、結果が一貫性を保つとは限らない。個々には妥当な選択でも、ナビゲーション、用語、次に起きることへの期待を共有すると衝突する可能性がある。
したがって、組み合わせたプロトタイプには、それ自体についてもう一度レビューが必要だ。構成要素が以前に承認されたから受け入れるのではなく、完全な体験として評価すべきである。生成が速くなっても、ここではデザイン判断が中心であり続ける。
Figma agent prototypingが最も有用なのは、agentが具体的な検討を支援するときだ。特定のインタラクションを探索する依頼は、チームに評価可能な対象を残す。全般的により良い体験を求める依頼では、評価すべきことの多くが明示されないままになる。
実務上の含意は、共有キャンバス上での探索が明確な意図に依存するということだ。実行中のコードは、挙動を検査可能にする。それが、どの挙動を残すべきかを決めるわけではない。
キャンバス上のコードはすでに競争領域になっている
キャンバスベースのコードはすでに他社にも存在するため、Figmaの競争上の主張はチームレビューの連続性にかかっている。
Framerのcode componentsは、JavaScriptライブラリで記述された再利用可能なインターフェース要素であるReactコンポーネントで、キャンバス、プレビュー、公開済みサイト上でレンダリングされる。同社のドキュメントでは、視覚的なプロパティコントロールとコンポーネント共有についても説明されている。
これは、製品を同一視することなく、関連する歴史的な参照点を示すものだ。Webサイトビルダーを拡張するコンポーネントと、プロダクトデザインファイル内で検討されるプロトタイプは、目的が一部重なる一方で異なる。価値は、チームが何を提供しようとしているかによって決まる。
公開済みWebサイトを構築するチームは、ビジュアル編集と最終的なサイトとの関係を優先するかもしれない。アプリケーションの変更を検討するプロダクトチームは、代替案、周辺画面、そして採用した方向性を説明する議論を優先する可能性がある。
どちらの要件が本質的に高度というわけでもない。両者は異なる到達点を表している。コードを生成できるかどうかだけでツールを比較すると、生成後に続く作業や、参加する必要のある人々を見落としてしまう。
この点から、Figmaの位置づけはより明確になる。Figmaにとっての機会は、共有デザインファイルを、動作するアイデアをレビューするための有用な場所にすることだ。問われるのは、そこへコードを持ち込む労力を上回るだけの文脈を、その場所が保持できるかどうかである。
別のコーディング環境も、インターフェースを検討する有効な場所になり得る。エンジニアは、プロジェクトの慣例や開発チェックがすでに存在する場所で実験することを好むかもしれない。デザイナーは、デザインワークスペースで得られる、より広い視覚的な俯瞰を好む可能性がある。
こうした好みを、ビジュアルツールとコードツールの人為的な対立にしてはならない。実務上の論点は、特定の判断をどこで明確に行えるかだ。同じプロジェクトでも、異なる段階で異なる環境を使うことには合理性がある。
主な対抗対象は、依然として分断された探索である。この分断は、プロトタイプ、周辺デザイン、フィードバック、根拠を結び付けにくくなったときに現れる。アプリケーションの切り替えは症状の一つにすぎない。一つのアプリケーション内にも、切り離された作業は存在し得る。
だからこそ、削減されたツール切り替え回数だけを数える評価は不十分だ。チームは移動の頻度を減らしても、最新バージョンを特定する時間をより多く費やすかもしれない。別のチームはツールを分けたままでも、根拠と判断の間に明確なつながりを維持できる可能性がある。
Figmaの事例で説明されるコードレイヤーは、空間的な答えを提示する。すなわち、代替案と議論を同じ場所に置くという考え方だ。関係性が可視化されている場合、空間的な近接は有用である。だが、拡大するキャンバスがその関係性を曖昧にする場合には、有用性が低くなる。
したがって、競争圧力は生成能力と同じくらいレビューの質に関わる。Figmaは、プロトタイプをその中で動作させられるようにすることで、既存の協働環境がより有用になることを示す必要がある。アイデアから根拠のある実装判断まで、チームにより明確な道筋を与える場所では、競合するアプローチも依然として説得力を持つ。
動作するプロトタイプにもコードとアクセスのレビューが必要
共有ファイル内で動作するプロトタイプは、その実装と可視性の両方についてレビュー上の責務を生む。
FigmaのGit integrationドキュメントでは、リポジトリのクローン、ブランチ、マージ前にレビューへ提出されるプルリクエストについて説明されている。また、ファイル閲覧者はコードレイヤーのプレビューとプレビューソースを閲覧できることも説明している。ファイル編集者は、対応するGitHub権限がなくても、基盤となるリポジトリコードにアクセスできる。
非公開プロジェクトをインポートする前に、この可視性モデルには注意を払うべきだ。関連する対象者は、デザインファイルへアクセスできるグループである。チームは、その対象者が導入するコードの想定対象者と一致しているかを評価すべきだ。
これは文書化されたアクセス特性であり、セキュリティインシデントの証拠ではない。実務上の重要性は、リポジトリと共有の取り決めに依存する。独自コードを扱う組織は、インポートを日常的なデザイン操作として扱う前に、その取り決めを理解する必要がある。
実装には別の境界もある。Figmaはリポジトリレビューへ戻る経路を文書化しているが、その経路が存在することは、生成された変更が正しいことを保証しない。提案された変更は、依然としてプロジェクトの要件に照らして評価する必要がある。
住所選択機能であれば、レビュー担当者は利用できない場所をどう扱うのか、リクエスト失敗後も確認内容が明確に保たれるかを問うかもしれない。これらは例示的なレビュー上の問いである。目的は、実験で説得力のある動作と、現実の条件下で信頼できる動作を区別することにある。
アクセシビリティにも同じ区別が必要だ。インターフェースは、ポインターなしでは操作しにくいままでも、見た目には説得力を持ち得る。キーボード操作、フォーカス順序、理解しやすいフィードバックは、視覚的な完成度から推測するのではなく、直接評価する必要がある。
プロトタイプコードと既存プロジェクトの慣例との関係も重要である。局所的な変更は妥当に見えても、他の場所で維持しにくいパターンを導入する可能性がある。プロトタイプが意図した動作を明確に示していても、文脈の中で変更をレビューする必要は残る。
したがって、懐疑的な見方は具体的だ。実演が容易になることで、時期尚早な確信が促される可能性がある。関係者は、動作する画面を、残りの作業がわずかである証拠と解釈するかもしれない。実験によって重要な依存関係が未解決のまま残されている場合、その解釈には異議を唱える必要がある。
有用なレビューでは、どの動作が実装済みか、どの動作がシミュレーションか、どの前提が未検証かを明らかにすべきだ。これにより、プロトタイプを偶発的な約束に変えてしまうことなく、その価値を保てる。
意思決定記録は、会議後にもその区別を維持するのに役立つ。代替案を比較するチームは、関連する技術文書とともに、検索可能なナレッジベースへ根拠を残せる。重要な情報は、なぜ方向性が変わったのか、そして何がなお検証を必要としているかである。
したがって、Figma code layers betaは、エンジニアリングレビューへ到達する提案変更の質によって評価されるべきだ。理解しやすいプロトタイプは有用である。明示的な前提とレビュー可能な実装を伴うプロトタイプは、より強い成果となる。
導入状況、修正の忠実度、探索の経済性を注視する
次に必要な証拠は、チームがより明確な判断に到達できるか、意図した変更を維持できるか、初期実験後もこのワークフローを継続できるかを示すべきだ。
最初のシグナルは、実際のプロジェクトにおける協働利用の反復である。今後数か月間でより強い証拠となるのは、チームメイトが代替案を比較し、選んだ方向性を実装レビューへ持ち込んだ事例だ。反復利用は、キャンバスが継続的な調整上の問題を解決するというFigmaの主張を裏付けるだろう。
印象的なデモの集まりは、より弱い裏付けにとどまる。デモは、ワークフローが魅力的な結果を生み出せることを示す。しかし、プロジェクトの制約が厄介になったときに、チームがそのワークフローへ戻るかどうかについては、あまり明らかにしない。
この違いは、導入事例を評価する購入者の指針になるべきだ。どの判断が明確になったのか、誰が参加したのか、プロトタイプレビュー後に何が起きたのかを尋ねるべきである。こうした詳細は、実験が速く感じられたという一般的な説明より有用だ。
二つ目のシグナルは修正の忠実度である。つまり、ビジュアル編集とコードの間を作業が移る際、変更が意図した外観と動作を維持できるかどうかだ。これは公開済みのFigmaベンチマークではなく、提案する評価基準である。製品の約束を支える中心的な仕組みに焦点を当てている。
修正作業が限定的だったという証拠は、その約束を強める。無関係な変更、失われた詳細、難しい調整に関する報告が繰り返されれば、その約束は弱まる。いずれの結果にも、プロジェクトの複雑さや試みられた変更についての文脈が必要である。
三つ目のシグナルは、実際のクレジット消費下での探索の継続性だ。FigmaのAI credit rulesによれば、コードレイヤーへのリクエストは変動するクレジットを消費する。同社はまた、AIタスクの実行前に正確な消費量を予測することはできないとしている。
そのため、完全なレビューサイクルが評価における重要な単位となる。代替案の生成、改善、修正はいずれも、利用可能な判断に到達するための一部である。最初の出力だけを評価すると、その後の労力は見えなくなる。
継続利用は、チームが必要なリソースに見合う価値を結果に見いだしていることを示唆するだろう。初期試行後に比較を放棄する傾向が見られれば、再現性に疑問が生じる。どちらの結論も、ロールアウト発表だけから確立することはできない。
これらのシグナルは、予測を観測可能な成果に結び付ける。Figmaは、共有デザイン環境内で動作する探索を利用可能にした。残る問いは、周辺のプロセスが、チームが使い続けるのに十分なほど明確になるかどうかだ。
次のレビューでは、すでに意見の不一致を生んでいるインタラクションを選び、評価の問いを明示したままにしよう。同じユーザータスクに照らして代替案を比較し、選択した方向性の根拠を残し、エンジニアリングが検証すべき前提を特定する。動作する比較が判断を変えたのか、それともプレゼンテーションをより魅力的にしただけなのかを、レビュー担当者に尋ねよう。その後、提案変更を実装レビューまで追跡し、途中で必要となった修正を記録する。Figma code layers betaを、チームがどのように意思決定を行うかを検討する機会として扱おう。参加者がトレードオフを理解しやすくなり、開発者により明確でレビュー可能な提案が残るなら、そのワークフローを維持すべきだ。
