「AIリーダブルなFigma」とは？——viviONのAI駆動開発 | UI+FE合流点レポート

2026.4.10

マンガ、ゲーム、VTuber などなどの二次元領域の事業を40以上展開し、プロダクト開発に関わる人員が200名以上という株式会社viviON さんは、全プロダクトで「AI駆動開発」に取り組んでいるそうです。

3月23日、そんな取り組みをされている viviON さんと Gaji-Labo の共催で「フロントエンドの Claude Code とデザイナーの Figma をつなぐコミュニケーション」というテーマのイベントを開催しました。本記事では、その内容をレポートします。

トークイベント『UI＋FE合流点』は、名前の通り UI デザインとフロントエンド開発の「合流点」を目指したイベントです。（読み方は『ユーアイ・エフイー・ジャンクション』です）

今回は AI時代の合流点を探るイベントとして、viviONさんの「Figma MCPを活用するためのデザインハンドブック」を作ってきたプロジェクトメンバーに、座談会形式でお話しいただきました。

FigmaとClaude Codeの間を、人間がどうつなぐか。

命名規則、Auto Layout、アノテーション設計などの Figma のデザインデータの構造化を「AI のために整理した」デザインハンドブックです。

viviONさんが公開している「Figma をどう設定すると、Claude Code や AIエージェントが理解しやすいか」をまとめたガイドブック。

viviON さんの AI駆動開発の取り組みとして、UIデザイナーの設計意図を AI に伝えるための情報をまとめたのだそうです。

動きのある1ページが「Figmaの指示通りに実装される」デモ。

AI駆動開発と聞くと華やかですが、今回語られたのは泥臭い実務のお話でした。
Figma のどのデータを整えると AI の実装精度が上がるのか。どこまでやると効果が出て、どこでつまずくのかを数ヶ月かけて検証したというお話です。

登壇いただいたのは、「Figma MCPを活用するためのデザインハンドブック」を作ってきたプロジェクトメンバー4名。

川島慶さん（viviONプロダクトデザインチーム UI/UXデザイナー）
福里優気さん（viviON フロントエンド開発チーム）
坂本彬さん（viviON 社長室 PM）
野口隆誠さん（viviONプロダクトデザインチームサブマネージャー）

イベントは、川島さんが実際に Figma データを Claude Code に渡して見せるデモをするところから始まりました。
画面共有が Figma から実装結果に切り替わると、カルーセルやホバーなどのインタラクション、レスポンシブ対応まで含めた1ページがまるごと出力されていました。

司会の Gaji-Labo 原田が「これ、人間がコードをまったく触ってないんですか？」と聞いてみたところ、川島さんは「人間は触ってないです。プロンプトもほぼ工夫せず、Figma側の指示をメインに出力させています。」とのこと。つまり、動きのある1ページが「Figma の指示通りに実装された」ということです。

ただし、これは「何もしなくても AI が完璧にやってくれる」という話ではありません。このデモの精度を出すために、Figma のデザインデータをどう整えれば良いのかをひたすら検証するプロジェクトをやった———というのが、今回の座談会の本題です。

「AI を活用する」ではなく「開発フローを見直す」

そもそもなぜ AI 向けの Figma デザインルールを作ろうという話になったのか。
viviON のフロントエンドエンジニア福里さんの説明が印象的でした。

viviON の「AI駆動開発」は、AI 活用というよりは、AI を取り入れて開発フロー自体を見直していこうという取り組みなんですけど、その中でもボトルネックになりそうな部分が、デザインを実装に起こすっていうところだった。
——— viviON 福里さん（フロントエンドエンジニア）

そして、面白かったのは、この話がフロントエンド側から出たわけではなく、フロントエンドチームの外から持ち込まれたというエピソードです。

これって、フロントエンドエンジニアが楽になる取り組みじゃないですか。

でも、フロントエンド側からやりましょうって提案したわけじゃなくて、チームの外の人がフロントエンドにこの話を持ってきてくれたんですよ。
それがまず嬉しかったですね。
——— viviON 福里さん（フロントエンドエンジニア）

ただ、プロジェクトが始まったはいいものの、最初は手探りだったそうです。
このプロジェクトが始まったばかりのときは、Figma MCP を使っているという情報は沢山あったけれど「こうすればうまくいく」という情報は検索しても出てこない時期だったとのこと。

いざ Figma のデザインを AI に実装させてみても、意図通りに実装されないし、コード品質も悪い。使う AI によって結果がバラバラ。

そんな状態から、UIデザイナーとフロントエンドがタッグを組んで、「Figma 側を整えれば、指示をほとんど出さなくても実装できる状態」を目指すことになります。
このプロジェクトの PM をやった坂本さんは、かなり不安だったと言います。

みんなプロダクト開発と兼任でやっていて本当にリソースがない。どこがゴールなんだろう、どうなったら成功なんだろう、みたいな状態で、すごく不安だった。
——— viviON 坂本さん（PM）

それでも、プロジェクトメンバーは頑張って、AI駆動開発に詳しい社内のエンジニアを募って、検証する意味がありそうな仮説をリストアップ。
その検証項目に合わせて UIデザイナーの川島さんが Figma を準備し、フロントエンドエンジニアチームの3〜6人がコードレビューをする。それを繰り返したそうです。

そんな地道な検証を数ヶ月続け、命名規則、デザイントークン、アノテーション、なにをしたら AI が読める Figma になるのかが少しずつわかってきたのだそうです。

「推測を減らす」という考え方

福里さんによると、AI による実装精度を向上させるための観点は「AI が正しい情報を取得すること」と「AI が取得した情報を正しく使うこと」のふたつがあり、それをわけて検証したことに意味があるとのこと。

AI でフロントエンドの実装精度を上げるというのは、MCP で言い換えると get_code とか get_design_context を叩いた時に返ってくるレスポンスを綺麗にしましょうっていうこと。

実装側の Claude Code で工夫することもできるんですが、「AI が取得した情報を正しく使うこと」と混ざってしまう。

このプロジェクトでは「どの AI モデルに渡しても、それなりの精度で実装される AI の指示となる Figma デザインデータ」だけを検証しました。
——— viviON 福里さん (フロントエンドエンジニア)

Figma のデータがやや粗かったとしても、既存のコードベースから推測して AI は実装しようとする。しかし、それでは「どんなときに上手くいき、どんなときにダメなのか」を理解できず、AI を使いこなす技術レベルが上がらない。
なにをしたら「AI が正しい情報を取得する」のかを自分たちが説明できる必要があると考えたそうです。

川島さんからは「推測を減らす」という観点をお話しいただきました。

「AI が正しい情報を取得する」ためには、AI が推測するところをなるべく少なくさせることが重要で。

コンポーネントの役割をちゃんと命名に入れてあげるとか、そういうことだけでもだいぶ変わることがわかりました。
——— viviON 川島さん（UI/UXデザイナー）

名前が曖昧だと AI は推測する。アノテーションがなければ推測する。

推測して実装してくれるのだが、推測することが多いほど、出力はブレる。
出力のブレをなくすには、Figma のデータを AI に伝わる具体的な指示にし、自分たちのコントロール下に置くことが必要だったのです。

ブレイクスルーは、アノテーション。

AI がほぼ仕上げてくれれば、少し人間がやるべき調整が残っていても、実務的に「使えるレベル」になると判断し、このプロジェクトでは「80%くらいまで AI がやってくれる」を目標にしたそうです。
※80%は、複数のエンジニアによる「どこまで実装されているか」の感覚的な評価であり、定量的な指標ではないそうです。

ずっと50%とか60%ぐらいを行ったり来たりしてて。

「MCP 経由だと半分くらいしか実装されないな」ってところから、アノテーションの良い書き方がわかったら、急に80%に伸びたんですよね。
——— viviON 川島さん（UI/UXデザイナー）

具体的なアノテーションの書き方はハンドブックに書いてあるので、ぜひご覧いただければと思いますが、川島さんはその中でも「カテゴリをちゃんと設定するのが大切」と言います。

川島さんが会場の参加者に「Figma でアノテーションを書く時にカテゴリーをちゃんと設定していますか？」と聞いてみたところ、手が挙がったのはごくわずかでした。

それに対する川島さんの説明。

カテゴリーを設定しないと、アノテーションにスタイルのことが書いてあったり、インタラクションのことが書いてあったり、メモ書きみたいになっちゃう。

でも、カテゴリーをつければ、AI の推測が減る。それでやっとアノテーションが AI への指示に変わるんですね。
——— viviON 川島さん（UI/UXデザイナー）

ただし、福里さんによると Figma MCP の公式情報として「アノテーションを書けば従う」と説明があるものの、アノテーションが無視されることも多いとのことです。

この日は、会場の参加者向けに「無視されにくいアノテーションの書きかた」もお話しいただきました。
この方法は最近発見されたもので、現状版のガイドには書かれていないそうですが、アップデート版で公開されるかもしれないとのことです。

組織で活用していくのは、まだまだこれから。

全社展開の話になったとき、福里さんが「正直な話をしていいですよね」と前置きしたのが印象的でした。

正直、ぜんぜん社内には浸透してなくて。 Figma の AI 向けガイド作ったよってことは周知してて、社内で認識してもらってるんですけど。

まだまだ一部の感度の高い人だけが取り組んでくれてる程度で、多くのプロダクトチームが使っているとは言い難い感じです。
——— viviON 福里さん（フロントエンドエンジニア）

福里さんはそう言ってるけど、感度が高いメンバーにはちゃんと火が灯っている、というのは PM の坂本さん。

社内に周知して、すぐに Slack に「#Figmaルールを語る部屋」ってチャンネルが作られて、一部の人ではありますが活発に「こういうときはどうなんだ」って議論されるようになりました。

そのおかげで、公開してすぐに次のアップデートを出せたくらいには、社内で注目されて、これを使っていこうという動きはあると思います。
——— viviON 坂本さん（PM）

忙しい現場で「新しいことに時間を割けない」のはどこの会社でもある話です。
だからこそ、全部を一度にやるのではなく小さく始めることが繰り返し勧められていました。

ボタンみたいな小さなコンポーネントだけやって試してみて。それでうまくいって精度高くなったら、社内で話を通しやすくなるじゃないですか。

「こんなに効果あったんで、これに工数割かせてください」って。
——— viviON 川島さん（UI/UXデザイナー）

ガイドラインも前半のほうが手軽に試せる項目になっているとのこと。全部やる必要はなく、効きやすいものからひとつずつ試すのが現実的な入り方のようです。

合流点を「一部の工夫」から「チームの再現性」へ

今回の座談会は、万能なソリューションの紹介ではありませんでした。

AI駆動開発のための地道な取り組み、そしてそれはまだ浸透していない。これらを隠さず話してくれたことが、いちばんの収穫だったように思います。

Figma のデータを整えることは、AI のためだけでなく、チームの情報共有やメンテナンス性にも効く———という言葉も印象に残りました。

まず、ひとつのコンポーネント、小さなところから試してみる。
手応えを感じたら、そこから広げていく。今回の話を聞いて、それくらいの温度感で始められそうだと感じた方も多かったのではないでしょうか。

具体的なFigmaデータの整え方を知りたい方は「Figma MCPを活用するためのデザインハンドブック」をご覧になってみてください。

『UI+FE合流点』は今後もさまざまなテーマで続けていきます。

「参加したかったけど知らなかった」「次も参加したい」という方は、Gaji-Labo の X（Twitter）アカウントをフォローするか、connpass の Gaji-Labo グループのメンバーになっていただけると次回の情報を見逃さずにキャッチできると思いますので、ぜひフォローよろしくお願いいたします。

懇親会での議論や交流もとても盛り上がりました（ある意味、懇親会が合流のための本番というイベントなので、盛り上がってホッとしました）。