「Config 2026」から読み取れるFigmaの思想とは？──“Code is material（コードは素材だ）”が意味するもの《綿貫佳祐のFigma思考ラボ｜Vol.11》

はじめに：6つの新機能に込められたFigmaの考えとは？

2026年6月23日から25日にかけて、アメリカ・サンフランシスコでFigmaの年次カンファレンス「Config 2026」が開催されました。

基調講演では、今回の目玉である6つの新プロダクト・新機能が発表されました。コードそのものをデザインレイヤーとして扱える「Code layers」、タイムラインでアニメーションをつくれる「Figma Motion」、プロンプトベースで高度な視覚効果を表現できる「Custom shader effects and fills」、AIに要件を伝えるだけで独自のFigmaプラグインを生成できる「Generative plugins」、画像生成や編集などのAIワークフローをFigma上で利用できる「Weave tools」、そしてチーム固有の文脈を踏まえた作業を支援する「Figma agent」の6つです。

詳しくは、公式のリキャップ記事やキーノートの動画（Config 2026 Keynote with Dylan Field）にまとまっているほか、Web Designingでは現地取材を通じたレポート記事を公開しています。

発表全体を通じてボリュームがあり、とても一度では把握しがたい内容でした。私の周りでも「すごい！」という声と同じくらい「多すぎて把握できない」「自分にどれが関係あるのかが、わからない」という声が上がっていました。

本連載では改めて発表内容を取り上げますが、機能を個別に紹介するのではなく、キーノートの冒頭で語られた「Code is material（コードは素材だ）」という言葉を手がかりに、発表全体に通底するFigmaの考え方について読み解いていきます。前回の記事で、「機能の裏側を考える習慣」が「Figmaをちゃんと使いこなすことにつながる」視点の重要性に触れました。今回はその実践編とも言える内容です。

モノづくりの上限を引き上げるのは「つくり手」という宣言

まず、読み解きの素材となる言葉を正確に見ておきます。キーノートでCEOのDylan Field氏は、次のように述べました。

Code is material, just like images, vectors and design layers.
拙訳: コードは、画像やベクター、デザインレイヤーと同様に、素材である。

さらに公式のリキャップ記事では、次のように記されています。

For years, the design industry has talked about “design versus code,” and tools (including Figma!) have forced a choice. But this is a false debate.
拙訳: 長年、デザイン業界は「デザイン対コード」を語り、ツールは（Figmaも含めて！）その二者択一を迫ってきた。しかし、これは誤った議論である。

デザインとコードのどちらが主導権を持つべきか？

デザイナーはコードを書くべきか否か？

こうした「デザイン対コード」を巡る議論を、私も何度も目にしてきましたが、Figmaはその構図自体を否定したということです。 「Figmaも含めて（including Figma!）」と、自分たちがこの対立を助長してきたことまで認めているところに、この宣言の本気度がうかがえます。

AIについての言葉も印象的でした。

AI has lowered the floor, it has not raised the ceiling. Designers, creatives, builders: You will raise the ceiling.
拙訳: AIは床を低くした一方で、天井は上昇させていない。デザイナー、クリエイティブ、ビルダー：あなたたち（こそ）が天井を上げるでしょう。

AIが誰でもモノづくりを始めやすくした一方で、天井（上限）は上がっていない。天井を上げるのはデザイナーであり、クリエイターであり、開発者あるあなたたちだ、という趣旨です。機能の発表そのもの以上に、こうした言葉を用いていることに、Figmaの現在の考えが表れていると私は考えます。

次からは、こうした言葉の選び方の根底に通じる、「Code is material」の「material（素材）」という言葉について掘り下げます。

なぜ「material（素材）」という言葉を用いたのか？

コードに関する機能を発表するだけなら、「コードと連携する」「コードを生成できる」といった言い方でもよかったはずです。実際、これまでの類似機能はそのように説明されてきました。

しかし今回は、以前のような言い方ではなく「Code is material（コードは素材だ）」と言い換えたところに意図がある、と私は解釈します。素材とは加工の対象であり、行き来できるものです。画像はキャンバスに置いて、切り抜きや色調整ができます。ベクターは描いた後から何度でも編集できます。これらと同様に、コードもキャンバス上に置いて、修正して、戻せる対象（素材）にするという世界観の表現ではないのか、と思ったのです。

これまでの制作フローを思い出してみましょう。デザインをつくり、ハンドオフし、実装するという一連の流れの中で、コードは常に「成果物」でした。デザインツールの外側にあり、一度実装されたものをデザイン側から直接触る手段はなく、デザインからコードへは一方通行です。

「material（素材）」宣言は、この「一方通行の関係を終わらせる意思表示ではないか？」というのが、私の見立てです。

前回の記事とのつながり

この見立ては、前回の記事と関連しています。順を追って説明します。

前回、WebサイトをFigmaに取り込む公式Chrome拡張機能を題材に、制作フローの変化について書きました。AIによる制作支援が進む中で、まずコードや動く画面が生まれるため「実装済みの状態こそが『仕様の定義（設計の基準）』であり、Figmaはその後から始まる」という流れが増えていく可能性がある、という話でした。

この変化をFigmaの立場から眺めると、どう見えるでしょうか。

Figmaの強みは、制作フローの出発点であることでした。設計図としてのデザインデータがFigmaにあり、実装はそこから始まります。ところが、フローがコードから始まるようになれば、Figmaを経由しないという選択肢が現実味を帯びてきます。「仕様の定義（設計の基準）」が実装側へ移る流れは、Figmaにとって、出発点としての地位の揺らぎでもあるわけです。

このときFigmaが取りうる方針は、大きく2つが考えられます。

1. 「Figmaデータこそが『仕様の定義（設計の基準）』であるべきだ」と、従来の地位を守りにいく方向
2. どちらが「仕様の定義（設計の基準）」かという争いから降りて、コードそのものを自分のキャンバスに取り込んでしまう方向

「Code is material」という宣言や、後述するCode layersから、後者（2）を選んだのだと私は読んでいます。

コードが「仕様の定義（設計の基準）」になった世界でも、Figmaがデザインとコードを行き来する作業場であり続けられるように、土俵そのものを組み替えたのではないでしょうか。前回の記事で書いた流れの変化に対して、Figmaからの回答が示されたように見えます。

念のため補足すると「回答」といっても、Figmaが何か個別の議論に答えたという意味ではありません。制作フローの変化は業界全体で起きていることで、Figmaも当然それを見ています。同じ変化を見て、Figmaはこう動いた、という意味での「回答」です。

「Code is material」の視点で新機能を眺め直す

「コードも、その先にあるものも、すべて加工できる素材にしていく」という視点を持って、主要な発表を眺め直してみます。ここでは、個別の操作を解説するのではなく、それぞれの機能が「Code is material」の思想のどの部分の現れになるのかについて、見ていきます。

Code layers：デザインとコードの往復を前提にした機能

Code layersは、デザインレイヤーをクリックひとつでインタラクティブなコードレイヤーに変換できる機能です。

コードレイヤーからデザインレイヤーへ切り替えて編集すれば、その変更はコードにも反映されます。デザインからコードへ、コードからデザインへという往復が、キャンバスの中で完結します。これを「ハンドオフが楽になる機能」と捉えることもできます。

ただ、ここまでの読み解きを踏まえると、むしろ「素材としてのコード」の最も直接的な実装として見るのが自然だと思います。コードが成果物としてフローの末端にあるのではなく、デザインレイヤーと並んでキャンバスに置かれ、相互に変換できるということで、まさに画像やベクターと同じ扱いです。ロールアウトは2026年7月から段階的に進み、ベータ版は現在ウェイトリスト制です。

実際の使い勝手や、現場のワークフローにどう組み込めるかの検証は、触れるようになった段階で改めて取り上げる予定です。

Figma Motion：モーションも「定義」の対象になる

Figma Motionは、Figma Designにタイムラインを追加し、キーフレームでモーションをつくれる機能です。

注目したいのはエクスポート形式で、MP4やGIFといった映像だけでなく、CSS、JSON、Reactなど実装で使える形式に対応しています。映像として書き出すだけなら、モーションは「見せるためのもの」で終わります。「実装可能な形式で書き出せる」ことは、モーションを「実装に引き継ぐ定義」として扱うということです。以前の記事（Vol.5）で、バリアブルとデザイントークンについて「何を『定義』すべきか」という観点から書きました。これまでは色やサイズをトークンとして定義し、デザインと実装で共有するのが主流の考え方でした。

Figma Motionは、この「定義して共有する」対象にモーションが加わったものとして位置づけられます。デザインシステムの構成要素として、モーションも管理する時代が近づいているのかもしれません。

Shader Fills & Effects：コードが「塗り」になる

Shaderでは、ノイズやグラデーション、光の揺らぎといった表現をコードで記述して描画できます。

こうした表現は、これまでWebGLなどを扱えるエンジニアの領域で、デザインツールの外側にありました。Figmaでは、欲しい表現を言葉で説明するか、参考にしたい画像を渡すと、Figma Agentがシェーダーを組み立ててくれます。

注目したいのは、出来上がったシェーダーの扱われ方です。生成されたシェーダーは、最初からパラメーター化されており、キャンバス上のコントロールから調整できます。

中身はコードですが、触っている感覚は色や質感を選ぶ操作に近いものになるでしょう。「Code is material」という宣言において、最も文字通りに表わされた機能ではないでしょうか。

Generative plugins：道具そのものが素材になる

Generative Pluginsは「どんな動きをさせたいか」「どんな操作項目を持たせたいか」を言葉で説明するだけでプラグインをつくれる機能です。

プラグイン開発のためにAPIの知識を学ぶ必要ありません。つくったプラグインはファイル内で共有でき、将来的にはチームやコミュニティへの公開も予定されています。Weaveでは、つくり方が素材になりました。Generative Pluginsでは、作業に使う道具そのものが人に渡せる素材になります。

これまでプラグインの世界には「つくる側」と「使う側」という明確な境界がありました。開発知識を持つ一部の人が作り、多くの人はそれを使う、というものです。この境界が薄くなると「自分の作業のためだけの小さな道具」を誰もが持てるようになります。

今ある中から道具を選ぶのではなく、自分のための道具を仕立てるという感覚に近づいていくのかもしれません。

Weave Tools：AIの出力も、その「つくり方」も素材になる

AIメディア生成環境であるFigma Weaveとの連携も発表されました。

先に現状を正確に押さえておくと、現時点でFigma内でWeaveがフルに使えるわけではありません。Figma内で使えるのは、スタイルの変換、ブランドに沿ったアイコン生成、背景の置き換えといった特定のツールです。それでも、ここにも同じ思想を読み取れると考えています。

注目したいのは、Figmaに追加されたこれらのツールの正体です。公式ブログによれば、これらはWeaveで組まれたワークフローをプリセットとして固めたものです。つまり、誰かが組み立てた生成の「つくり方」が、ツールという形に姿を変えてFigmaに届いています。実際、Weaveで組んだカスタムワークフローはFigma Communityに公開でき、公式ブログはそれを「コンポーネントライブラリのように機能する」と説明しています。

連携を強める方向も予告されています。FigmaのフレームをWeaveのキャンバスに貼り付けてワークフローに接続できる「Figmaノード」が予定されており、Figma側でフレームを編集すると、その変更がWeaveのワークフローにリアルタイムで反映されるとのことです。

どれも、成果物だけでなく「つくり方」も素材になるという話です。この視点は、次の2つの機能を見るときにも有効です。

Figma agent：手順や知見が素材になる

Figma Agentの強化では、Skillsという仕組みが加わりました。個人やチーム、コミュニティのワークフロー指示を保存し、繰り返し使えるようにするものです。また、ConnectorsによってNotion、Slack、GitHubといった外部ツールと連携し、Attachmentsで関連資料を参照させることもできます。

ここまで来ると、素材化の対象は道具からさらに広がり「仕事の進め方」や「チームの知見」にまで及んでいます。うまくいったやり方をSkillとして残せば、それは個人の頭の中にある暗黙知ではなく、チームで共有し、改良していける素材になります。

予想はあくまで予想である、という留保

ここまでの読み解きは、キーノートや公式ブログといった公開情報に基づく、私の解釈です。Figmaの公式見解ではありません。

また「素材としてのコード」という考え方が、現場にそのまま浸透するかも未知数です。コードレイヤーを誰がどこまで触るのか、実装チームとの責任分担はどうなるのか、運用上の課題はこれから見えてくるはずです。

念のため付け加えると、これはデザイナー全員がコードを扱うべきだという話でもありません。現場の体制や役割分担によって、この変化との距離感は変わって当然です、それでも、ツール提供者の思想を読んでおくことにはメリットがあると私は考えています。新機能が出るたびに慌てて評価するのではなく、「この機能はあの方針の延長線上にある」と位置づけられるようになるからです。

自分の現場では、デザインとコードの間にどんな境界線が引かれているでしょうか。そして、その境界線はこれからも同じ場所にあり続けるでしょうか。

まとめ

ここまでの内容を、まとめていきましょう。

・Figma Config 2026の発表は、機能の数で捉えると圧倒されるかもしれないが、「Code is material」という思想で捉えると見通しが良くなる

・コードを「成果物」から「素材」へ捉え直すことは、デザインからコードへの一方通行の関係を終わらせる意思表示と読める

・前回書いた「実装済みの状態が『仕様の定義（設計の基準）』になる」という流れの変化に対して、Figmaは「仕様の定義（設計の基準）」を争うのではなく、コードをキャンバスに取り込む方向で回答したと言える

・6つの新機能のうち、Code layers、Motion、Weave Tools、Generative plugins、Figma agentの5つは、いずれも「素材の範囲を広げる」という同じ方向を向いている

コードが素材になり、モーションが定義の対象になり、AIの出力が加工できるものになり、道具がつくれるものになり、手順や知見までもが共有できるものになりました。一つひとつはバラバラの機能に見えても、この軸で並べると、同じ方向を向いていることがわかります。

次回からは、Code layersをはじめ、実際に触れるようになった機能から、手を動かして検証していく予定です。思想の読み解きが実際の機能とどこまで一致しているのか、を確認していきます。

著者プロフィール

文：綿貫佳祐