Figma、仕様書・ライブラリ・アクセス管理でAIエージェントのガードレールを詳説

Config India 2026で、Figmaは、自社のエージェントとサードパーティ製エージェントが同社プラットフォーム内でどのように動作できるのかについて、これまでより明確な枠組みを提示した。リリースノートとTechCrunchの報道を通じて同社が説明したのは、エージェントにより多くの文脈を与えると同時に、より多くの制約も与えるための一連のツールである。具体的には、Markdownベースの新しいエディタ「Specs」、デザインライブラリに付与するガイドライン、コードソース、集中管理されたデザインシステム、そしてFigma MCPを通じたより広いサポートが挙げられる。これらに通底する主題はガバナンスだ。Figmaは単にAI機能を追加しているだけでなく、ルール、ファイル、共有参照情報によって、チームがエージェントのふるまいをどのように形づくれるかを定義しようとしている。

こうしたガードレール重視の姿勢は、Figma自身が認めているAIの限界と結び付いているようだ。TechCrunchによれば、Figmaは前週にキャンバス上のエージェントをより広いユーザー層へ提供した後、AIが非決定的であることを踏まえ、より予測可能な結果へ導くためのツールもあわせて提供しているという。この位置づけは重要だ。エージェントを最初から完全に信頼できる存在として示すのではなく、文脈とシステム上のルールを、結果のばらつきを抑える手段として位置づけているからである。

意図と文脈のためのネイティブな置き場

発表の中心にあるのがFigma Specsだ。Figmaのリリースノートでは、Specsは文脈のためのネイティブなホームと説明されており、文章で表現された意図、ビジュアル上の探索、技術的な詳細を、チームとエージェントのために一つにまとめるものだとされている。TechCrunchはこれに加えて、これはMarkdownエディタであり、ユーザーが自分たちのデザイン言語をシンプルな方法で定義できると報じている。その報道によれば、SpecsはFigma内で単独のファイルとして存在することも、キャンバスに並置されることも可能で、ユーザーはキャンバス要素、FigJamの図、コードレイヤー、デザインなど、Figma内のほかの要素を参照できる。

両者をあわせて見ると、Specsは人間向けにプロジェクトを文書化する以上の役割を担うよう設計されていることがうかがえる。Figma内で動くAIシステムにとって、機械可読な文脈になることも意図されているのだ。リリースノートは、ほかのFigmaオブジェクトの埋め込みや参照といった実装面について、TechCrunchほど技術的な詳細には踏み込んでいない。しかし、より大きな役割については両ソースで一致している。すなわち、エージェントは人間の共同作業者と同じ文章的・視覚的文脈を参照できるべきだ、という考え方である。

利用可能性については、ほかの発表項目よりもここが比較的明確だ。Figmaによれば、Specsは有料プラン向けにオープンベータとして現在展開中である。この区別は、組織内でガバナンスを検討するうえで重要になる。この機能は一般提供済みとは説明されておらず、すべてのプラン向けに提供されているとも書かれていないからだ。

ライブラリ、ガイドライン、コードを制約として使う

FigmaはSpecs以外にも、ほかの制御レイヤーを制度化しつつある。リリースノートによれば、チームは公開済みのデザインライブラリにガイドラインを追加でき、これによってエージェントは確立済みのパターンに従い、アンチパターンを避けられるようになる。この機能は現在、オープンベータとして展開中だ。さらにFigmaは、GitHubリポジトリやnpmパッケージのコードをコードソースとして取り込み、実際のデザインシステムを反映したコンポーネントやコードレイヤーの構築・編集をエージェントが支援できるようにすると説明している。この機能は現在、クローズドベータとして提供されている。

TechCrunchもおおむね同じ構図を示している。チームはデザインに関するより多くの文脈、すなわちデザインライブラリ、コードライブラリ、ガイドラインを持ち込み、デザインシステムの文脈を管理でき、エージェントはこの集中管理されたシステムを参照してルールに従うことができる、という説明だ。一方で、Figma自身のリリースノートは製品構成の説明がより具体的である。そこでは、集中管理されたデザインシステムとは、デザインライブラリ、コードライブラリ、ガイドラインを単一のデザインシステムに束ねたものであり、作成者にとっては保守を容易にし、利用者全体にとっては準拠を容易にするものだと説明されている。ただしFigmaは、この集中管理されたデザインシステムをプレビュー段階に限るものとして位置づけている。

• Specs：有料プラン向けオープンベータ。
• 公開済みデザインライブラリ内のガイドライン：オープンベータ。
• GitHubリポジトリまたはnpmパッケージ由来のコードソース：クローズドベータ。
• 集中管理されたデザインシステム：プレビューのみ。
• 20の新規パートナーに対応したFigma MCP：現在利用可能。

この切り分けは重要である。なぜなら、ガバナンスに関する全体像は、成熟度の異なる複数機能にまたがって成立しているからだ。すでに有料顧客が比較的広く使える制御もあれば、限られた利用者にのみ開放されているものもあり、まだプレビューの段階にとどまるものもある。現時点でFigmaのエージェントに対して、どこまで方針やプロセスを実際に強制できるのかを評価したい企業は、発表された方向性と、今日利用できる実装とを切り分けて考える必要がある。

コードレイヤーがエージェントの行動範囲を広げる

Figmaは、指示を厳密にするだけでなく、エージェントにできること自体も拡張している。TechCrunchによれば、コードレイヤーは6月にプライベートベータとして最初に発表された機能だが、現在は両ソースの説明どおり、オープンベータとして展開されている。Figmaの説明では、コードレイヤーは、デザインフレームの変換、GitHubリポジトリのインポート、Figma Chrome拡張機能によるウェブサイトの取り込み、あるいはゼロからのプロンプト入力を通じて、キャンバス上にコードに裏打ちされたインタラクティブなプロトタイプを作成する方法である。

TechCrunchは、ガバナンスの観点で見逃せない別の点も補っている。ユーザーはエージェントに対し、デザインをコードに変換するよう求めたり、コードの一部を変更してプロトタイプを反復改善するよう依頼したりできるという。言い換えれば、エージェントは単なるブレーンストーミング支援ではなく、構築のための作業面により近づいている。Figmaのリリースノートもこの方向性を裏づけており、Figma MCPは外部のAIツールから利用できるようになり、コードレイヤーの作成、Specsの編集、キャンバス上での画像生成が可能になったと述べている。

この組み合わせには二つの含意がある。第一に、エージェントが静的なデザイン成果物だけでなく、コードに支えられたプロトタイプへ影響を及ぼせるようになるほど、文脈を制御する仕組みの重要性は増す。第二に、相互運用性それ自体がガバナンス上の論点になる。Figmaによれば、MCPは現在、より高速なパフォーマンス、より多くのFigma製品への対応、そして20の新規パートナーへの対応を備えている。TechCrunchは、追加されたツールとしてOpen Code、Dia、Grok Bot、Sarvamの名を挙げている。Figmaのノートの抜粋にはそれらの名前は列挙されていないため、このパートナー名に関する詳細はTechCrunchに由来する。

Payload統合と、プロトタイプからアプリへの移行

今回の発表のもう一つの要素は、デザインガバナンスを超えてアプリケーション提供の領域にまで及んでいる。Figmaによれば、Makeは現在、Payloadバックエンドをネイティブにスキャフォールドでき、CMS、データベース、メディア、API、認証、管理パネルを提供する。さらにFigmaがそれをホスティングすることで、コンテンツとデータは、それらを形づくるデザインと同じ場所に置かれることになる。リリースノートによれば、これはすべてのプランで展開中である。

TechCrunchも同様に、FigmaがPayloadをFigma Makeに統合し、動的なウェブサイトの生成とコンテンツの直接管理を可能にしていると報じている。記事ではまた、Figmaが昨年、オープンソースのヘッドレスCMSであるPayloadを買収したことにも触れている。この統合は、主としてエージェント・ガバナンス機能として語られているわけではない。しかし今回の一連の発表の背後にある、より大きな製品ロジックを強めるものではある。すなわち、デザインの文脈、コードの文脈、コンテンツの文脈が、エージェントが行動できる一つの環境へ引き寄せられているということだ。

確認されたことと、まだ方向性にとどまること

各ソースを通して見ると、中核的なメッセージは一貫している。Figmaは、明示的な文脈とルールをエージェントに与えることで、チームがそのふるまいを定義できるようにしたいということだ。ただし、二つの点では慎重さが必要である。第一に、いくつかの機能はまだ全面的には利用可能ではない。オープンベータ、クローズドベータ、プレビューのみは、運用上、同じ意味ではない。第二に、実装の詳細の一部は片方のソースにしか現れない。たとえばTechCrunchは、SpecsがMarkdownベースで、埋め込まれたFigma要素を参照できると説明している一方で、Figmaのリリースノートは、その正確な仕組みよりも、より広い製品上の目的に重点を置いている。

また、両ソースは強調点にも違いがある。TechCrunchは、AIが非決定的であり、Figmaが結果をより予測可能な方向へ導こうとしているという理屈を前面に出している。これに対してFigmaのリリースノートは、ワークフローと製品カバレッジを強調し、コードを用いた構築と共同作業、文脈の取得と共有、実データとコンテンツを用いた構築の方法を説明している。両者は両立する説明だが、同一ではない。

実務面で見れば、Figmaはチームに対して、エージェントが何を見てよいのか、どのルールに従うべきか、どこで行動を許されるのかを、これまでより具体的に決めるためのレバーを提供しつつある。現時点では、Specsに意図を記述し、公開ライブラリに指針を付与し、コードに裏打ちされたワークフローをオープンベータで試すことがその具体例となる。ただし同時に、一部の制御はなおクローズドベータまたはプレビューにとどまることも認識しておく必要がある。要するに、組織はエージェントのふるまいを場当たり的なプロンプト運用ではなく、デザインシステムの統治対象として扱い始めることができるようになりつつあるが、その志向を実際の運用に移すには、各機能の現在の提供状況と照らし合わせて見極める必要がある。