生成したコードの可視化は何を意味するのか──Figma シェーダー/生成プラグインとCode is Materialの接続《綿貫佳祐のFigma思考ラボ｜Vol.13》

はじめに：前回は生成までしか見ていなかった

11回目の記事では、Config 2026で発表された新機能について「Code is Material」という1つの考え方を通じて読み解きました。この記事でもシェーダーや生成プラグインについて取り上げましたが、扱えたのはFigmaエージェントにプロンプトを渡すと生成できるという部分まででした。

しかし、2026年9月に行われた直近のアップデートでは、生成した後までコントロールできるようになったのです。その新機能により、「Code is Material」の考え方がより広がっていると感じました。そのため、今回はアップデート内容を含めて、シェーダーと生成プラグインの生成について紹介します。

なお、以前の記事では正式な日本語訳が出ていなかったので英語表記のままにしていましたが、現在はFigmaの公式表記でも「シェーダー」と「生成プラグイン」という名称に固まっているため、以降はこちらで表記します。

シェーダーと生成プラグイン、それぞれ何を生成しているのか

シェーダーと生成プラグインは、どちらもFigmaエージェントへのプロンプトから生成されるという点は共通していますが、生成されるものの性質は異なります。

シェーダーは、レイヤーに適用する塗りやエフェクトです。GPU上で毎フレーム計算されるピクセル単位の視覚効果で、色や強さなどのパラメータをGUIから変更できます。Config 2026のアップデートで初めてFigmaの機能として搭載されました。

一方プラグインは、Figma内で動く小さなツールです。ベクターやテキストといった実際の要素をFigma上に生成・編集・操作するものです。こちらは以前から機能としては存在し、人の手で作られたものがコミュニティに公開されています。通常のプラグインに対して、AIを使って作れるようになったものが生成プラグインという区分です。

ただ、どちらもプロンプトで生成された時点でFigmaの通常の機能として扱えるようになるという点は共通しています。ここまでを踏まえた上で、生成された後の中身がどう扱えるようになったのかを見ていきましょう。

生成したコードを閲覧・ダウンロードできるように

「はじめに」で触れたように、Figmaの2026年9月1日のアップデートでは、新たな機能が追加されました。

その中でも特に、生成したもののコードを閲覧・ダウンロードができるようになったことと、MCP経由で外部のコーディングエージェントから編集できるようになったことは大きな意味を持つと感じます。

それは、「プロンプトから生成し、Figmaの中だけで完結していた」状態から「生成された結果をもとにして実際のコードや外部ツール上でブラッシュアップができるようになった」という変化です。

今回は、シェーダーと生成プラグインの生成・ブラッシュアップについて1つずつ例を示します。

マウスに反応する水面のようなシェーダー

水面のような模様が、時間経過とともに動き、マウスの位置に追従して揺れるシェーダーを作成しました。今回はこちらを例に使い方を見ていきましょう。

色、波の大きさやスピード、水面の模様の強さなどをGUIから変更可能です。変化させる要素自体も、AIに渡す指示によって変えることができます。

作成した際のプロンプトは以下のようになっています。最初のプロンプトを含め、合計6回の指示で作成しました。途中、選択肢を提示されて質問されることもあるので自分の望むものを回答します。

1回目の指示	2〜4回目の指示	5〜6回目の指示

生成されたコード

生成されたコードは、Figma上での閲覧、手元へのダウンロード、またMCP経由での編集ができます。逆に、Figma上で手動で書きかえてシェーダーを変更することはできません。

生成されたコードはWGSL（WebGPUのシェーディング言語）で書かれています。

ファイル冒頭の defineProperties と、そこで使われている figma:shaders からのインポートはFigma独自のAPIで、GUIで動かしていた色やスライダーの正体はここに定義されたパラメータです。

本体は setup と render という2つの関数で構成されていて、setup は初期化時に1回、render は毎フレーム呼び出される仕組みになっています。

render の中で経過時間とマウス座標を計算してGPUに送り fs_main という関数がピクセルごとの色を計算する、という流れです。水面や光の揺らめきは noise2 や flowNoise といったノイズ関数を何層にも重ねて作られていて、マウス位置は mouseEase という値で滑らかに追従が遅れるよう調整されています。

ただ、このコードがそのまま実際のWebサイトやアプリケーションで動くかというと、そうではありません。

defineProperties や figma:shaders からのインポート、setup/render が受け取る device や frame といった引数は、いずれもFigmaがシェーダーを動かすために用意している独自の枠組みで、実コードには存在しません。移植する際は、これらを取り除いた上で、WebGPUのデバイスやキャンバス、描画パイプライン、uniformバッファの用意、マウス位置の取得と平滑化といった土台の部分を自分で書く必要があります。

一方で、wgsl文字列として書かれているシェーダー本体は、Figma固有の書き方ではなく標準的なWebGPUのシェーディング言語なので、素材としては持ち出せます。ただし device.createShaderModule() を用意するだけでは動かず、@group/@binding の宣言やuniform構造体のフィールド順序を実装側と一致させ、fs_main だけでなく対応する頂点シェーダーも自分で書く必要があります。またWebGPUはWebGLほど広く使われている技術ではないため、対応ブラウザを広げたい場合はWebGL（GLSL）への書き変えも視野に入ります。

まとめると、コピー＆ペーストで動くわけではないものの、表現の核となるロジック自体は素材として持ち出せる状態にある、と言えます。

ランダムな流体シェイプを描画するプラグイン

また、サイズや複雑度合いを指定してランダムな流体シェイプを描画するプラグインを作成しました。

作成した際のプロンプトは以下で、1回の指示で完成しました。

実行するたびに違う形になる、ランダムな有機的形状（ブロブ）を生成するプラグインを作ってください。色は常に#000。

生成されたコードを閲覧・編集できる範囲や方法はシェーダーと同様です。

コードは code.ts（Figmaのサンドボックス内で実際にレイヤーを操作するロジック）と ui.html （パラメータパネルのUI）に分かれていて、両者は figma.ui.postMessage / onmessage でメッセージをやり取りしています。これはサンドボックスとiframeの関係の実例です。

形状生成のロジックは createRandomBlobPath という関数にまとまっています。円周上に等間隔で点を配置したあと、それぞれの半径を「irregularity」の割合でランダムにずらし、点と点の中間点を通る二次ベジェ曲線でつなぐことで、角のない有機的な輪郭を作っています。生成した形状には使用パラメータが保存されるので、同じ要素を選んで再実行すると前回の設定が引き継がれる、という配慮もされています。

AI登場以前、シェーダーやプラグイン開発はなぜ難しかったのか

私自身は、過去に地道にシェーダーを書いたりFigmaプラグインを作成したりしたことがあるのですが、これらはかなり難度が高いのです。

いくつか理由はありますが、大きな要素として、情報自体が少ないことと、実際に動かすまでに必要な専門的知識が多いことが挙げられます。

たとえば、「JavaScriptで〇〇を実現したい」といった場合、少し調べればコピー＆ペーストで動くようなサンプルが出てきます。しかし、シェーダーやプラグインではそこまでの情報は出てきません。しっかりと理解して、自分の頭で再構成する必要がありました。

また、シェーダーでいえばGPUの計算の仕方が、プラグインでいえばサンドボックスとiframeとの関係が、簡単には理解しづらいはずです。個人的には、CSSでの描画は画面上の見た目との対応関係が分かりやすく、人間のメンタルモデルに合致しやすいのですが、シェーダーやプラグインの仕組みは内部的な仕組みへの理解が求められるため、より難易度が高いのでは、と考えています。

上記を説明するために、例として「黒から赤へ、斜めにグラデーションする背景」をCSSとWebGLで書くとしましょう。

まずはCSSですが、これは自然言語的に理解しやすいと思います。「背景色がグラデーション、45度の方向に黒から赤へ変化」といった具合です。

.element {
  background-image: linear-gradient(45deg, #000, #f00);
}

次にシェーダー、ここではWebGLです。細かな説明はここではしませんが、背景色を描画する範囲を指定しつつ r (=赤の値) がどの座標ではどの値になるかを考えて指定するといった仕組みです。これは、慣れていないと描画結果を予想することが難しいはずです。

// 頂点シェーダー
#version 300 es

in vec2 aPosition;
out vec2 vTextureCoord;

void main() {
  gl_Position = vec4(aPosition, 0.0, 1.0);
  vTextureCoord = aPosition * 0.5 + 0.5;
}

// フラグメントシェーダー
#version 300 es
precision highp float;

in vec2 vTextureCoord;
out vec4 outColor;

void main() {
  float r = (vTextureCoord.x + vTextureCoord.y) / 2.0;
  outColor = vec4(r, 0.0, 0.0, 1.0);
}

プラグインにしても同様で、単にHTML, CSS, JavaScriptを組み合わせて手元で動くツールを作るよりも、ずっと多くのことを理解していなければいけません。

こういった背景で、AIの登場以前ではシェーダーやプラグイン作成は一部の専門性の高い人のみに閉じていたのです。それが、AIの登場によりグッと作成のハードルが下がりました。

Code is Materialとのつながり

11回目の記事で扱った「Code is Material」は、コードもキャンバス上に置いて、修正して、また戻せる素材として捉え直す考え方でした。

シェーダーや生成プラグインは、Figmaエージェントへの指示によって「つくる」ことまではすでに間口が開かれていました。ただし、最後の「気持ちよさ」や「馴染み方」の調整はAIだけでは完結せず、手動で仕上げたい場面も多かったはずです。生成された後の中身が見えず、置き直すこともできない状態は、素材というには扱いづらかったのです。

それが今回のアップデートで状況が変わります。コードを閲覧・ダウンロードできるだけでなく、MCP経由で外部のコーディングエージェントで手を加えた内容を、Figma上のシェーダーやプラグインに反映できます。
Figma Developers-Tools and prompts

つまり専門性の高いシェーダーや生成プラグインの領域でも、キャンバス上に置いて、修正して、戻せるようになったということです。これは、11回目の記事で見立てた「一方通行の関係を終わらせる」というCode is Materialの方向性が、そのまま具体化した事例だと言えそうです。

まとめ

今回のポイントは以下です。

・シェーダーはConfig 2026で新しく登場した機能で、プラグインは以前から存在した機能がAIによって素早く作れるようになったもの、という前提の違いがある

・2026年9月のアップデートで、どちらも生成したコードを閲覧・ダウンロードでき、MCP経由で外部のコーディングエージェントからも編集できるようになった

・シェーダーもプラグインも、AI以前は専門知識のハードルが高く、一部の専門性の高い人に閉じた領域だった

・Figmaエージェントによって「作る」ことの間口はすでに開かれていたが、今回のアップデートで「キャンバス上に置いて、修正して、戻す」という行き来までできるようになった

・これは11回目の記事で扱った「Code is Material」という思想が、より広い範囲に及んできたと言える

AIが生成できる範囲が広がるほど、その中身にどれだけ踏み込めるかが「素材」としての価値を左右するようになっていくのではないでしょうか。

著者プロフィール

文：綿貫佳祐