Figma Agentの新機能、AIとキャンバスの間にデザインルールを配置

Figmaは、予測しにくい挙動を伴うAIの出力に対し、チームがより細かく管理できるようにする新たなFigma agent機能を導入した。このリリースにより、エージェントは同一プラットフォーム内で、文書化された仕様、デザインライブラリ、コードソース、動作するプロトタイプと連携できる。

これは、単に別のアシスタントにコマンドが追加されたという話ではない。Figmaは、生成されたインターフェースがプロダクトチーム全体に広がる前に、エージェントを取り巻く運用環境を定義しようとしている。同社は、制限のない生成能力よりも、共有コンテキスト、可視化された作業、適用可能なデザインルールのほうが重要だと見ている。

この立場により、Figmaはデザイナーと、Claude Code、Codex、GitHub Copilot、Cursorといった外部コーディングエージェントの間に位置することになる。モデル性能だけで競うのではなく、エージェントが何を構築すべきかをチームが決めるためのコントロールプレーンとして、自社のキャンバスを据えようとしている。

新たなFigma Agent機能は、生成前にルールを定義する

Figmaは、エージェントの管理を個別のプロンプトから、共有されたプロダクト基盤へと移そうとしている。

同社は、インドで初開催したConfigイベントで、拡張されたワークフローを発表した。その中心となる追加機能が、プロダクト要件、意思決定、参照資料、技術的コンテキストを記録するためのMarkdownベースのワークスペース、Figma Specsだ。

仕様書は独立したFigmaファイルとして作成することも、キャンバス上の作業と併置することもできる。チームは、すべてを切り離されたテキストに還元することなく、デザイン、FigJamダイアグラム、コードレイヤー、その他の資料を参照できる。

この構造が重要なのは、エージェントの失敗が弱い言語生成だけに起因することはまれだからだ。多くの場合、要件、視覚コンポーネント、コード実装、過去のチーム判断の間にある関係性を欠いている。

従来のMarkdownファイルでも、こうした関係性を記述することはできる。しかし、それらを自動的に維持するわけではない。リンクは古くなり、画像は文脈を失い、異なるファイルが矛盾する指示を示すこともある。

Figma Specsは、こうしたつながりをネイティブに扱えるよう設計されている。同社のローンチ概要によれば、チームは大まかなアイデアを詳細な仕様へと変え、FigmaのMCPサーバーを介してコーディングエージェントに渡せる。

Model Context Protocol、すなわちMCPは、AIシステムを外部ツールや構造化されたコンテキストに接続するための標準である。Figmaの実装では、キャンバスと対応する開発エージェントの間でプロダクト情報をやり取りできる。

ワークフローは、エージェントがコードを書く前から始まる。チームは仕様内で要件、ダイアグラム、デザイン参照、コードコンテキストをまとめ、その資料を生成時に活用できる。

同じコンテキストは、Figmaキャンバス上で動作するコードを基盤としたインタラクティブなプロトタイプであるコードレイヤーも支援できる。これにより、プロトタイプを、それを生み出したデザインや意思決定と並べて検証できる。

Figmaは、デザインシステムを通じて利用できる情報も拡張した。チームは公開済みライブラリに文書化されたガイドラインを追加し、GitHubリポジトリまたはnpmパッケージからコードソースを接続できる。

ガイドラインには、ルール、推奨パターン、禁止すべき表現、実装の詳細を記録できる。関連するライブラリが有効化されている場合、エージェントはその資料を読み取れる。

コードソースは、さらなる根拠付けのレイヤーを加える。エージェントは、スクリーンショットや視覚フレームからすべてのインターフェース要素を推測するのではなく、実装済みコンポーネントにアクセスできる。

この組み合わせは、コンテキストの階層を生み出す。仕様はチームが構築しようとするものを説明し、デザインライブラリは視覚言語を定義し、コードソースはソフトウェア上で要素がどのように機能するかを示す。

エージェントに関する発表では、デザインライブラリ、コードライブラリ、ガイドラインの一元管理も強調された。Figmaによれば、エージェントは作業の作成や編集時にこのシステムを参照できる。

これらの管理機能は、生成型インターフェースに繰り返し生じる問題に対応する。モデルはもっともらしい画面を生成できても、組織のコンポーネントルール、インタラクションパターン、アクセシビリティの実践を無視する可能性がある。

洗練された結果が、必ずしも有効なプロダクトの成果であるとは限らない。見た目は正しくても、重複コンポーネント、未対応の状態、あるいは後で開発者が置き換えなければならない実装作業を生み出す場合がある。

Figmaの答えは、プロンプトをなくすことではない。1回のチャットを開始する人物ではなく、チームに属する永続的なコンテキストでプロンプトを囲むことだ。

これにより、プロンプト自体の役割も変わる。エージェントとプロダクトの間に立つ唯一の指示ではなく、統制されたワークスペース内の要求となる。

Figma Code Layersが動作するソフトウェアをキャンバスにもたらす

Figma code layersは、キャンバスを視覚表現をレビューするだけの場ではなく、振る舞いをテストする場へと変える。

コードレイヤーは、このリリースの一環としてクローズドベータからオープンベータへ移行した。Figmaによれば、この機能は各プランで段階的に展開されているが、個々のアカウントでアクセスできる時期は異なる可能性がある。

コードレイヤーには、実行中のコードを基盤とする機能的なインターフェースが含まれる。チームは従来のデザインフレームの横に配置し、複製し、異なる方向性をテストし、インタラクティブな状態を検証できる。

この違いは重要だ。従来のプロトタイプは、リンクされたフレームを通る経路をシミュレートできるが、実際のコンポーネントの振る舞いを表していない場合がある。

動作する実装は、読み込み時の挙動、空の状態、エラー、レスポンシブレイアウト、複雑なインタラクションを明らかにできる。こうした詳細は、静的な画面では未解決のまま残るプロダクト上の問いを浮き彫りにすることが多い。

コードレイヤーのガイドでは、複数の始め方が説明されている。ユーザーはFigma agentを通じてレイヤーを生成するほか、デザインを変換したり、コードをインポートしたり、既存チームのコードベースから開始したりできる。

デザイナーは、確立済みのチェックアウトフローを選び、別の配送オプションを追加するようエージェントに依頼できる。生成されたコードレイヤーでは、バリデーション、読み込み、成功、失敗時の挙動を示せる。

その後、チームはこのバージョンを複製し、別のインタラクションを横に並べてテストできる。プロダクトマネージャー、デザイナー、エンジニアは、1つの共有ファイル内で動作する選択肢を比較することになる。

Figmaによれば、変更はコードレイヤーに戻すことができ、対応するワークフローでは接続済みのコードベースにも反映できる。この約束は、単純なデザインからコードへのエクスポートよりも重要な意味を持つ。

エクスポートは通常、引き渡し用の成果物である。一方、接続されたコードレイヤーは、デザイン探索と実装の間で行われる反復的なループの一部として残ることを意図している。

Figmaは2026年6月、クローズドベータで初めてコードレイヤーを導入した。それ以前のキャンバスプレビューは、GitHubインポート、ローカルフォルダ、テンプレート、Figma Makeの出力、エージェント生成の出発点をサポートしていた。

オープンベータは、このモデルをより広い利用者層へもたらす。同時に、コードを基盤とするコラボレーションが、慎重に選ばれたチームの外でも機能するかどうかを試す機会にもなる。

当面のユースケースは、生成されたコードを自動的に出荷することではない。プロダクト探索の段階でコードを使えるほど低コストにすることだ。

Figmaのチーフデザインオフィサー、Loredana Crisanは、コード作成と実際のリリースの間に広がる隔たりについて言及した。彼女はTechCrunchに対し、組織が生み出すコードは17倍に増えた一方、リリースは1.3倍しか増えていないと語った。

これらの数値は企業が提示したものであり、独立した業界ベンチマークとして扱うべきではない。それでも、Figma code layersの背後にある戦略を説明する材料にはなる。

生成コードは、最終的に本番環境へ届かない可能性を探索するために、ますます利用されている。Figmaは、その探索的な作業を、チームがともに確認し、議論し、改善できる場所で行わせたいと考えている。

これは、コードを最終的な実装媒体からデザイン素材へと捉え直すものだ。プロダクトチームは、本番アーキテクチャへのコミット前に、何を構築すべきかを明確にするため、動作するソフトウェアを利用できる。

このアプローチは、ターミナルベースのエージェントセッションが共有しにくい場合が多いことも認識している。開発者は複数のインターフェースを素早く生成できるが、共同作業者が後から受け取るのはリンクや録画だけかもしれない。

このプロセスでは、結果の背後にある代替案、プロンプト、トレードオフが見えなくなる。動作するバージョンをキャンバスに載せることで、探索を可視化し、検討しやすくなる。

ただし、可視性がプロトタイプのコードを本番対応にするわけではない。チームには依然として、エンジニアリングレビュー、テスト、セキュリティ管理、アクセシビリティ検証、保守可能なアーキテクチャが必要だ。

したがって、コードレイヤーの価値は、チームが出力をどう位置付けるかに左右される。探索的な成果物として使えば、生成されたプロトタイプを完成したソフトウェアと見なすことなく、フィードバックループを短縮できる。

本当の競争は、共有コンテキストと孤立したエージェントチャットの間にある

Figmaは、どのエージェントが最速で初稿を生成するかよりも、統制されたコンテキストのほうが重要になると賭けている。

この文脈における主要な対抗相手は、別のデザインベンダーではない。プロダクト作業を非公開のチャット、ターミナル、切り離されたブラウザセッションに置く、孤立したエージェントワークフローである。

コーディングエージェントはすでに、テキストや画像からインターフェースを生成している。その速度は、参加者全員が異なる指示とローカルコンテキストに基づいて作業する際に、新たな調整問題を生み出す。

あるデザイナーは最新のコンポーネントライブラリを添付するかもしれない。開発者は古いリポジトリブランチを使い、プロダクトマネージャーは別文書からコピーした要件を提供する可能性がある。

各エージェントはもっともらしい回答を返せる。それでも、システムが同じ唯一の信頼できる情報源を受け取っていないため、出力は競合しうる。

Figma Specsは、コンテキストに可視化された居場所を与えることで、この分断を減らそうとしている。要件を、それらが参照するダイアグラム、デザイン、コードレイヤー、意思決定の近くに置く。

デザインシステムの拡張は、関連する問題に取り組むものだ。Figmaはエージェントに、利用可能なコンポーネントだけでなく、その使用を規定するルールも理解させようとしている。

ライブラリには複数のボタンバリアントが含まれていても、破壊的な操作にはどれを使うべきか説明されていない場合がある。ガイドラインは、欠けているその判断ロジックを補える。

同様に、コードソースへのアクセスは、コンポーネントがすでに存在するかどうかをエージェントに示せる。これにより、互換性のない振る舞いを持つ、視覚的に似た代替品を生成したくなる誘惑を減らせる可能性がある。

Figmaの既存エージェントは現在、ファイル横断検索、プラットフォーム上のコンテンツの添付、ライブラリ要素の参照、複数プロンプトの同時実行に対応している。エージェントのドキュメントでは、組み込みエージェントと外部MCPクライアントも区別されている。

組み込みエージェントは、デザインファイル内で直接動作する。外部エージェントは、Figmaのキャンバス書き込み機能を使用し、コードベースや他のAIプロジェクトのコンテンツをプラットフォームへ持ち込める。

この区別により、Figmaは1つのアシスタントにすべての作業を担わせることなく、複数のエージェントをサポートできる。同社は、変化し続けるモデルや開発ツール群の下にある共有レイヤーとして存在できる。

同社によれば、MCPのサポートには現在、20社を超える新しいパートナーが含まれる。発表されたリストには、OpenCode、Dia、Meta Muse、インドのAIスタートアップSarvamが含まれている。

Figmaはすでに、Claude Code、Codex、GitHub Copilot、Cursorを、ファイルへ書き込める外部エージェントの例として挙げていた。拡大されたパートナーサポートは、モデル中立性をプラットフォーム戦略の一部にする。

モデルの順位は急速に変化するため、これは擁護可能な立場だ。チームは、インターフェースコードにはあるエージェントを、リサーチ、ドキュメント作成、画像生成には別のエージェントを好むかもしれない。

Figmaは、共有されたプロダクトコンテキストを握ることができれば、すべてのモデル比較で勝つ必要はない。エージェントにFigmaのファイル、ライブラリ、ルールを信頼できる入力として扱わせればよい。

同社のMCPキャンバスアップデートは、その狙いを明確にしている。スキルにより、外部エージェントへワークフローの実行方法、手順の順序、チームの慣習への従い方を指示できる。

ここでいうスキルとは、エージェントの振る舞いを形づくる再利用可能な命令セットだ。本来なら個々の従業員のプロンプト履歴にとどまる運用知識を、そこに組み込める。

デザインシステムチームは、フォーム構築用のスキルを作成できる。そこには、承認済みのフィールドコンポーネント、アクセシブルなラベル、文書化されたバリデーション状態、特定のスペーシングトークンを使うことを求める指示が含まれるかもしれない。

外部のコーディングエージェントは、アセットを作成または更新する際に、そのルールを適用できる。成果物は、より広いチームがすでに協業しているFigmaのキャンバス上に表示される。

これは構造化されたエンジニアリングナレッジベースに似ているが、コンテキストがプロダクトアーティファクトへ直接結び付いている点が異なる。違いは、意思決定が実行可能になる場所にある。

したがって、新たに生まれつつある競争の焦点はオーケストレーションだ。デザインツール、コードエディタ、リポジトリ、ドキュメンテーションシステムはいずれも、エージェントが信頼できるコンテキストを受け取る場所になろうとしている。

多くのインターフェース上の意思決定がすでにキャンバス上に存在するため、Figmaには優位性がある。ただし、その優位性が維持されるのは、プラットフォームがそれらの意思決定を本番コードと同期させ続けられる場合に限られる。

予測可能なエージェントも不完全な入力に依存する

Figmaはエージェントの振る舞いを制約できるが、すべてのルールが完全で最新かつ正しく解釈されることまでは保証できない。

同社がこれらの制御を導入するのは、生成AIが依然として非決定的だからだ。同じ要求でも、実行ごとに構造、詳細、実装上の選択が異なる場合がある。

ガイドラインはそのばらつきを狭められる。しかし、特に命令が衝突したり、新しい状況をカバーできなかったりする場合、それを取り除くことはできない。

チームがエージェントに推奨コンポーネントの使用を指示していても、接続されたリポジトリには実装が2種類存在するかもしれない。デザインライブラリが一方のバージョンを示していても、本番コードはもう一方に依存している可能性がある。

仕様は別の保守責任も生む。構造化された仕様が役立つのは、その要件が現在の意思決定を反映している場合に限られる。

古いコンテキストは、エージェントを一貫して誤らせる可能性がある。この失敗は、明白なハルシネーションより危険だ。出力が統制され、信頼に足るものに見える場合があるためだ。

デザインシステムチームには、エージェント向け命令の所有権ルールが必要になる。誰がガイドラインを公開し、コードソースを接続し、競合を解決し、変更を承認できるのかを決めなければならない。

Figmaは、マップとシステムチェックを備えた集中型デザインシステム管理をプレビューしている。これらのツールは、説明やインタラクション状態の欠落を含め、依存関係と不足を明らかにすることを意図している。

エージェントアクセスは不十分なシステム文書化の影響を拡大するため、この管理レイヤーは必要だ。かつて、文書化されていないコンポーネントを人が正しく使うことはより困難だった。

現在では、エージェントがその誤解を数分で多数の画面に再現できる。生成の高速化は、優れた標準と放置された標準の双方を増幅する。

アクセス制御も別の懸念となる。エージェントをデザイン、仕様、リポジトリ、外部サービスに接続すれば、独自のプロダクト情報を含む領域が広がる。

Figmaは、MCP機能が同社のセキュリティおよび信頼性の制御から恩恵を受けるとしている。それでもエンタープライズチームは、権限、データ保持、接続クライアント、リポジトリアクセスを検討する必要がある。

このプラットフォームでは管理者がAI機能を無効化できるが、一部の組織にとっては利用可能な制御が広範すぎる可能性がある。Figmaのサポート文書によれば、コードレイヤーを無効化すると他のAI機能も無効になる場合がある。

チームは、プロジェクトの機密性、リポジトリ、モデルプロバイダー、ユーザーの役割に基づく、より細かなポリシーを求めるかもしれない。ガバナンスの有効性は、そうした制御がどのように発展するかに左右される。

導入も依然として不透明だ。デザイナーは、エージェント向け命令を保守したり、インポートしたリポジトリの問題を解決したりは望まず、コードに裏打ちされた探索だけを評価するかもしれない。

開発者は、もっともらしく見えても既存アーキテクチャと衝突する生成構造に抵抗する可能性がある。プロダクトマネージャーは、同期が必要な別の文書になってしまう詳細な仕様を作るかもしれない。

初期のユーザー議論ではすでに、リポジトリのインポート、インフラストラクチャエラー、AI機能が長年のプロダクト要望から注意をそらすかどうかについて疑問が提起されている。こうした事例だけで、広範なプロダクト品質を判断することはできない。

しかし、オープンベータで何を検証すべきかは示している。Figmaは、コードレイヤーが実際のリポジトリと日常的なチームの制約のもとで信頼性高く機能することを証明する必要がある。

このプラットフォームには概念上のリスクもある。要件、デザイン、コード、コンテンツ、エージェント制御を組み合わせれば分断は減らせるが、Figma自体をより複雑にする可能性もある。

共有キャンバスが成功するのは、各参加者がすべての基盤システムを習得せずとも、関連する状態を理解できるときだ。重なり合う表面が増えすぎれば、1つのプロダクト内部で再び調整の問題を生み出してしまう。

より高品質でブランドに沿った生成に関するFigmaの主張にも、独立した証拠が必要だ。同社が示したのは、コンテキストがワークフローに入る方法であり、エージェントがそれにどれほど一貫して従うかではない。

チームは、当然のことと考えるのではなく、成果を測定すべきだ。有用な指標には、コンポーネントの再利用、アクセシビリティの欠陥、手戻り、レビュー時間、プロトタイプと本番コードの乖離が含まれる。

中心的な問いは、エージェントが魅力的な画面を生成できるかどうかではない。その画面が、実際のデザインシステムとコードベースに接しても成立するかどうかだ。

Figma Specsはプラットフォームをデザインファイルの先へ広げる

Specsは、Figmaのエージェント戦略を、キャンバスの前後にあるプロダクト上の意思決定を担う、より広範な取り組みへと変える。

プロダクト仕様は従来、ドキュメントツール、チケット管理システム、またはリポジトリに置かれてきた。視覚的な作業はFigmaへ移り、技術的な実装は別の場所へ移った。

移行のたびに翻訳のステップが生まれた。要件はニュアンスを失い、デザインは承認済みの振る舞いからずれ、開発者は不完全なハンドオフメモを異なる形で解釈する可能性があった。

Figma Specsは、その分離に挑む。Markdownを柔軟な媒体として扱いつつ、それをFigmaの視覚的・技術的アーティファクトのネットワーク内に埋め込む。

プロダクトマネージャーは要件を作成し、FigJamの図を参照できる。デザイナーは関連する画面を接続し、エンジニアはGitHubからコードコンテキストを追加できる。

その後、エージェントは組み合わされた素材を使ってコードレイヤーを作成したり、MCPを通じて仕様を転送したりできる。仕様は、人だけがレビューする文書ではなく、能動的な入力となる。

これにより、Figmaが対象とするワークフローは広がる。プラットフォームは、インターフェースデザインの作成と開発チームへの引き渡しだけに限定されなくなる。

Figmaは、プロダクト定義、プロトタイピング、実装コンテキスト、コンテンツ運用に関与したいと考えている。表面が1つ増えるごとに、共有コンテキストはエージェントにとってより価値を持つ。

FigmaのPayload統合は、その方向性を強めている。Payloadは、2025年にFigmaに加わったオープンソースのヘッドレスコンテンツ管理システムだ。

この新しい統合は、PayloadをFigma Make（プラットフォームのプロンプトベースのアプリケーションおよびウェブサイトビルダー）と接続する。チームは、ビジュアルプロトタイプをコンテンツモデルから切り離すことなく、データに裏打ちされた体験を作成し、コンテンツを管理できる。

Figmaによれば、Payloadのダウンロード数は過去12か月間で6倍に増加した。これは同社が報告した指標であり、新しい統合を利用するプロジェクト数を明らかにするものではない。

それでも、この組み合わせは生成されたウェブサイトの実用上の制約に対応する。コンテンツがハードコードされたまま、または公開ワークフローから切り離されたままでは、洗練されたページの価値は下がる。

Payloadは、コンテンツストレージ、API、ワークフロー、管理インターフェースを提供する。Figmaによれば、マーケターはコンテンツを管理でき、開発者はオープンソースフレームワークへのアクセスを維持できる。

これは、探索のために作ることと、出荷のために作ることの違いも明確にする。使い捨てのプロトタイプは、アイデアを検証するのに十分な振る舞いだけを必要とする。

本番サイトには、永続的なコンテンツ、権限、データ構造、運用ワークフローが必要だ。CMSを統合することで、Figma Makeは後者のカテゴリに近づく。

同社は退出経路を残すことにも慎重だ。Figmaは、チームがPayloadベースの作業をFigmaの外へ持ち出せるとしており、これはプラットフォームロックインを懸念する開発者にとって重要だ。

ただし、移植性は実際のプロジェクトを通じて評価しなければならない。エクスポート可能なコードであっても、それを生成した環境なしに保守しやすいとは限らない。

この広範な戦略は、複数のカテゴリに同時に圧力をかける。ドキュメントツールは仕様を管理し、コーディングエージェントは実装を生成し、ウェブサイトビルダーはビジュアル編集とデプロイを組み合わせる。

Figmaは、それらすべてを1つのモデルで置き換えようとしているわけではない。それぞれの出力が接続される共有基盤になろうとしている。

このアプローチは、同社の既存のコラボレーションモデルに合致する。Figmaがプロダクトチームの中心となったのは、ファイルがマルチプレイヤー編集、コメント、コンポーネント、共有ライブラリを支えていたからだ。

エージェントは新たな種類の参加者を加える。人間の共同作業者と異なり、エージェントは広い範囲を迅速に変更し、機械可読なインターフェースを通じてツールをまたいで動作できる。

したがって、プラットフォームはコラボレーションと制約の両方を支えなければならない。エージェントの作業を可視化しながら、誤った命令が広がる範囲を制限する必要がある。

Figma Specs、コードソース、ガイドラインは別々の機能だが、併用すると価値が積み重なる。それぞれがコンテキスト問題の異なる部分に対応する。

Specsは意図を説明する。ライブラリは再利用可能なデザイン上の意思決定を表現し、コードソースはそれらの意思決定を実装に根付かせる。

コードレイヤーは、結果を検証する実行可能な場所を提供する。MCPはそのプロセスを、別の場所で動作するエージェントへ接続する。

これが、同社の新たなモデルにおけるFigmaエージェントの働き方だ。単にプロンプトを受け取り、画面を生成するわけではない。

エージェントは、プロダクトコンテキスト、共有ルール、作業アーティファクト、人間によるレビューの連鎖の中で動作する。その連鎖こそがプロダクト戦略だ。

Figmaのエージェント戦略が機能するかを示す3つのシグナル

次の検証点は、統制されたエージェントワークフローが、別の保守レイヤーを増やすことなく、実際のチーム成果を改善できるかどうかだ。

最初のシグナルは、オープンベータ展開後のコードレイヤー導入だ。アクセスできることだけでは、価値を証明できない。

チームは、キャンバス上で動作するプロトタイプを繰り返し作成、複製、レビュー、改善する必要がある。継続的な利用は、コードに裏打ちされた探索が実際のコラボレーション課題を解決していることを示唆する。

最も有用な証拠は、導入前後のワークフローを比較するものだ。レビューサイクルの短縮、ハンドオフ修正の減少、インタラクティブな状態の表現向上は、Figmaの主張を裏付ける。

放棄されるインポート、信頼性の低い実行、外部ツールでの頻繁な作り直しは、その主張を弱める。オープンベータは、Figmaにこうした問題を発見するためのより大きな利用者集団を与える。

2つ目のシグナルは、デザインガイドラインとコードソースがエージェントのエラーを減らすかどうかだ。チームでは、承認済みコンポーネントの再利用が増え、ブランドや実装上の不一致が減るべきだ。

Figmaの10月のリリースノートは、エージェントがライブラリガイドラインを読み、ファイルを検索し、プラットフォームコンテキストを添付し、カスタムスキルをサポートできることを確認している。これらの機能が示すのは仕組みであって、成果ではない。

決定的な証拠は、繰り返される本番利用から得られる。成功するシステムであれば、ユーザーがプロンプトのたびに慣習を言い直すことなく、エージェントが慣習に従う助けとなるはずだ。

また、競合も可視化すべきです。デザインライブラリとコードリポジトリの内容が食い違う場合、どちらが正当な情報源なのかをチームが特定できるよう、システムが支援しなければなりません。

そうでなければ、追加のコンテキストは曖昧さを増やしかねません。エージェントは情報を多く受け取るほど、従うべき指示への確信を失う可能性があります。

3つ目のシグナルは、外部エージェント支援がどのように発展するかです。チームがデザインコンテキストを再構築せずにモデルを切り替えられるようになれば、Figmaのプラットフォームとしての主張はより強固になります。

より多くのMCPクライアントへの対応は配布力を生みますが、互換性は基本的な書き込みアクセスを超えなければなりません。外部エージェントには、コンポーネント、変数、ガイドライン、画像、コードの関連性へ確実にアクセスできることが求められます。

Figmaは、Plugin APIとのより広範な機能同等性を目指して取り組んでいると述べています。この進展によって、外部エージェントが完全な協働者になるのか、それとも限定的なインポートツールにとどまるのかが決まるでしょう。

競合側の対応も重要です。コードエディタや開発プラットフォームは独自のデザイン統合を深められますし、ドキュメントシステムは仕様をよりエージェントが読み取れる形にできます。

これらのツールがFigmaを経由せずにコンテキストを維持できるなら、チームは分散型のワークフローを選ぶかもしれません。Figmaは、集約によって単にプラットフォームへの依存度が高まるだけでなく、より明確な意思決定が生まれることを証明する必要があります。

デザイナーにとって実務上の問いは、キャンバスが判断を下す場であり続けるかどうかです。エージェントは、デザインレビューを成果物の後始末に変えてしまうことなく、バリエーション作成や定型的な編集を加速させるべきです。

開発者にとっての問いは、コードレイヤーが有用な実装コンテキストを維持できるかどうかです。生成されたプロトタイプはトレードオフを明らかにしつつ、レビュー済みの本番コードと誤認されないようにしなければなりません。

プロダクトリーダーにとって、価値はトレーサビリティにあります。要件は、それを形作ったデザイン、プロトタイプ、コードソース、意思決定とつながっているべきです。

Figmaのエージェント機能は、現在、そのワークフローを構成する要素を提供しています。今後数か月で、チームが日常的なプレッシャーの下でもそれらの要素を同期し続けられるかが明らかになるでしょう。

オープンベータは、運用上の実験として扱ってください。範囲を限定したワークフローを1つ選び、現在の情報源を接続し、責任の所在を定めたうえで、拡大前に手戻りを測定します。

重要な問いは、もはやAIエージェントがインターフェースを描けるかどうかではありません。重要なのは、そのインターフェースがなぜ自社チームの基準に従っているのかを説明でき、従っていない場合に修正できるかどうかです。