【内製開発Summit 2026】内製開発の"共通言語"としてのFigma ─ AI時代のプロダクトづくり
2026年2月25日、ファインディ株式会社が主催するイベント「内製開発Summit 2026」が、浜松町コンベンションホールにて開催されました。
本記事では、Figma Japan株式会社 デザイナーアドボケートの谷 拓樹さんによるセッション「内製開発の"共通言語"としてのFigma ─ AI時代のプロダクトづくり」の内容をお届けします。
セッションでは、生成AIによって開発速度が上がる一方で、チーム内の「分断」が進むリスクが指摘されました。Figmaが提供するFigJam、Figma Make、Dev ModeなどのプラットフォームとAI機能を活用し、アイデアからリリースまでを一貫してつなぐワークフローの実現について、デモを交えて紹介されました。
■プロフィール
谷 拓樹
Figma Japan株式会社
デザイナーアドボケート
中小企業向けのSaaS、フリーランスでの受託、起業やスタートアップでの開発チーム立ち上げを経験。Webのフロントエンド開発や、UI・UX設計を行う。現在はFigmaのマーケティングやリソースの設計・開発に取り組んでいる。
UIデザインツールを超えたFigmaプラットフォームの全体像
谷:Figma Japanのデザイナーアドボケートという仕事をしています、谷と申します。普段はイベントでの講演やお客様とのワークショップセッション、ソーシャルメディアでの新機能アップデートの発信などをやっています。
Figmaというツールが出てからしばらく経ってはいるものの、FigmaのイメージはいわゆるUIデザインをするツールという印象が強いかなと思っています。同時編集で多くの編集者が同じキャンバスにアクセスして、かなりキビキビ動くパフォーマンスで使えるコラボレーションツールとなっています。ブラウザでも動くので、多くのステークホルダーがデザインにアクセスしやすい環境を提供しています。
ただ、FigmaはUIデザインツールというだけにとどまりません。たとえば建築に置き換えて考えると、まず設計図を描き、構想を練って、プロトタイプやモックアップを作り、光の当たり方をシミュレートしたり暮らし方を考えたりしながらデザインして、そこからようやく構築に入ります。この大きな流れはデジタルプロダクトでも同じです。まずアイデアを出してスケッチし、ワイヤーフレームを描いて、UIデザインを作り込み、プロトタイプを作って検証して、開発者にデータを渡してコード実装し、リリースするという流れがあります。

Figmaは視覚化やUIデザインの作り込みだけでは足りないことは私たちもわかっていましたので、どんどん製品を拡大してきました。アイデアを生み出すところから構築・リリースまでをカバーするプラットフォームへと進化しています。その基盤にはAIやデザインシステムがあります。
内製開発×生成AIが生み出す新たな「分断」
内製開発が変えるものとして、一つは分断の解消があります。企画・設計・開発の工程が分かれてしまうことで認識のずれが起きやすいところを、内製開発によって職種を超えて同じ環境で議論できるようになり、部門間の分断を和らげる可能性があります。それに関連して、分断されていることで検証や開発が鈍化するという問題もあります。合意形成に時間がかかるとその分スピードも遅れてしまうところが、内製化に向かっていけばアジャイル的な開発もやりやすくなりますし、意思決定も前に進みやすくなります。
その上で、今や生成AIが内製開発を加速させています。プランニングやコーディングなどでAIを使うことによってかなり高速化が進んでいると皆さんも実感はあるかと思います。ただ一方で、その速さが分断を加速させるという可能性も秘めています。

具体的には、AIを使うことによってチームの動きはかなり速くなっていますが、足並みが揃っていない可能性があります。AIのツールを使ったアイデアの探索作業がバラバラのツール上で行われ、唯一の信頼できる情報源がない状態でどんどん進んでいくのです。そうすると、最終的なデリバリーが加速するどころか、AIが生み出したものを再調整したり手戻りしたりと、結果的に時間的なコストがかさんでいる可能性があります。
少し掘り下げると、プロダクトマネージャーはテキストのプロンプトでフローや要件定義を進め、デザイナーはFigmaで絵作りをしながらアイデアを考え、エンジニアはコードで直接プロトタイピングをする。それぞれの職種がそれぞれのツールでアイデアを出しますが、デザインシステムのような共通言語に紐付いていないと、結局手戻りが起こりうる。分断が実は進んでいるのではないかということです。

一方で、プロトタイプを作るというところに関しては、高精度のプロトタイプがかなり早く作れるようになりました。ですが、チームが普段使っているツールの外で行われることが多い。プロトタイプができたと言っても、デザインのレビューがスムーズにいかなかったり、デザイナーがまた作り直すという新たな作業が生まれたりして、結局製品を磨いていく時間が失われてしまいます。
一見スピードが上がったと思っても、その分手戻りも増えている可能性があります。それはデザインの工程だけではなく、エンジニアリングでも起きています。デザインとコードのギャップによって、UIコンポーネントやブランド要素がコードと紐付いていないと、また作り直すことになる。その結果、QAのコストがかさんだりバグが増えたり、いつリリースできるのかわからない状態も生んでしまいます。
効率化の裏に潜むリスクとして、広く引いてみれば市場投入のスピードが低下している、早く届けられたとしてもプロダクト品質が伴っていない、アウトプットは増えるがイノベーションは減少している、チームメンバーの時間を非効率に消費している、といったことが起こりえます。ただスピードだけでは失われる品質が多くあるということです。
AIネイティブなプロダクト開発に求められる3つの要件
AIネイティブなプロダクト開発に求められるものを3点挙げています。1つ目は、デザインシステムや開発パターンなどの共有の資産を管理・拡張できる信頼基盤。2つ目は、さまざまなコンテキストに基づいてより良い意思決定を前に進められるAI。3つ目は、ツールを絶えず切り替えることなくチームが連携して一貫したコラボレーションができるプラットフォームです。
Figmaの目標としては、創業当初からアイデアがどこから生まれたとしてもチームが一つのプロダクトを作るというところへ向かっていけるよう支援したいと思っています。現在のFigmaプラットフォームは、チームを一つに結びつけるためのさまざまな機能、特にAIを使ったものも含めて提供しています。実際にどのように活用できるのかをここからお話しします。
FigJamとAIによるアイデアの発散と収束
1つ目は、Figmaはキックオフからリリースまでの一貫した認識合わせを推進できるということです。FigJamはデジタルのホワイトボードツールで、物理的なホワイトボードの代わりというだけではありません。付箋を貼ったり、タイマーを測ったり音楽を流したりしながらアイデアを生み出しやすい環境をデザインしています。ここにもAIを導入しています。真っ白なキャンバスからアイデアを考えるのはなかなか大変ですが、最初のテンプレートをAIで生み出すことができますし、たくさん集まった付箋をAIにサマライズしてもらうこともできます。AIに委ねることであえてバイアスなしにサマライズできるので、よりフラットにアイデアを考えることも可能です。

最近ではChatGPTやAnthropicのClaudeとの連携も進んでいます。ChatGPTでテキストのアイデアを壁打ちする中で、ユーザー登録のワークフローや認証プロセスを可視化したいと指示すると、FigJamで編集可能なダイアグラムを作ってくれます。
生成されたダイアグラムはそのままFigJamを開いて編集することができるため、AIが出力したものをそのまま使うのではなく、チームで議論しながら自分たちのコンテキストに合わせて磨き込むことが可能です。

Claudeも同様で、対話しながらアイデアを膨らませ、フレームワークに基づいた絵を描いてほしいと依頼できます。重要なのは、ただ画像を生成しているわけではなく、FigJamのツール上に持っていって編集できるという点です。ブランドのトンマナに合わせたものに作り直すといったことも可能です。
またFigma Slidesというプレゼンテーション機能もあり、発散したアイデアを集約して社内ピッチに活用することもできます。こうした一連の成果物が同じプラットフォーム上にあることで、さまざまなステークホルダーが常に進行中の作業を確認でき、意思決定も加速します。
Figma Makeで実現するプロンプトからプロトタイプへ
2つ目は、どこからでも確実にアイデアを探求できるという特徴です。アイデアの探索はFigma上で直接行うことができます。テキストから始めるだけでなく、すでにビジュアライズされたデザインからも、そしてコードからもアイデアを生み出すことが可能です。全てがFigma上で完結することによって、コラボレーションを前提にしたプロセスが作れますし、成果物が散らばるのではなく集約されるので、無駄になりません。
Figma Makeは比較的新しいAI製品で、テキストのプロンプトからコード生成ができ、アプリケーションを作ることができるものです。

生成するときにはClaudeやOpenAIなど、さまざまな最新モデルを選ぶことができます。ここからは実際にデモを動画でお見せしながら説明します。テキストだけでプロジェクト管理サイトのようなものを試してみると、Claude Opus 4.6(講演時点でのバージョン)のようなモデルでかなりのクオリティのものが完成します。
ただ、ここで生成したものはテキストだけのアイデアからのゼロイチです。社内にデザイナーがいて、具体的にブランド化されたデザインがある場合は大きく異なります。Figma Designで展開されたデザインをコピーして、Figma Makeの補足情報として添付すると、Figma Makeはデザインの構造を理解しながら作ることができます。画像ではなく編集可能な状態のものをそのまま渡すので、Figma Makeはデザインの構造を理解しながら作ることができます。テキストプロンプトが99%同じでも、デザインを添付したことで作られる成果物は変わります。これはちゃんと機能するプロトタイプなので、クリックすれば画面遷移もしますし、遷移先も添付したデザインに基づいてかなり忠実に作られます。
Figma Makeで作ったアイデアをさらにデザインキャンバス上で編集したい場合、Makeのコピー機能でFigma Designに編集可能な状態で持ってくることができます。たとえばプロダクトマネージャーがMakeでリードしてトップページのレイアウトを作り、それを縦積みのレイアウトに変えたいといった追加のプロンプトも可能です。デザイナーはそのアイデアをもとにFigma Designという自分たちのフィールドでさらにブラッシュアップし、場合によってはまた再びMakeに戻して作っていくこともできます。アイデアのイテレーションがFigma上で全て完結します。
品質を伴わせるためには、デザインシステムという皆さんのプロダクトのデザイン資産・ブランド資産をプロトタイプに反映できると好ましいです。

Makeの場合、NPMパッケージを利用してReactで作られたコードベースのデザインシステムをMakeに与えることができます。先ほどのデモでは、AIが自らの判断でFigma Makeに組み込まれているデフォルトのフレームワークで実装していましたが、皆さんがコードベースのデザインシステムを持っていれば、それをMakeに与えることによって、実際の本番プロダクトにかなり近いプロトタイプを作ることが可能です。
コードベースのものでなくても、FigmaのライブラリのコンポーネントをMakeに取り込むことも将来的には可能になります。現時点ではクローズドベータ版として提供しています。

MakeにはMCPという、AIが解釈しやすいようにするためのプロトコルも対応しています。たとえばNotionのURLを渡すだけで、Figma MakeはNotion側を見に行って、それをもとに何かを作ったりすることができます。実際には要件定義書がNotion側にあるというケースも多く、できればそのNotionを直接見に行ってもらいたい。そういった場合にMCPが活躍します。MCPサーバーによっては、Makeで作った情報をそちらに書き込むこともでき、かなり幅広い活用が可能です。さらに最近では自社でカスタムMCPサーバーを作られることも増えており、自社のナレッジをため込んだMCPサーバーをMakeと連携するといったことも今後できるようになっています。
Figma DesignのAI機能とデザインシステムの進化
3つ目は、品質やクラフトを犠牲にせずにスピードを持ってデザインするということです。ただスピードだけでは失われる品質が多くあります。Figma Designにも多くのAI機能が備わっています。レイヤー名を文脈に応じて自動でリネームする機能や、意外と面倒なダミーコンテンツを作る機能、画像周りを編集する機能もすでに実装されています。Nano Bananaなどかなり精度の高いモデルを使った画像生成がFigmaの中でできるようになっており、写真の中の一部要素を取り除く機能や、画像の足りない部分をAIに補填してもらう機能もあります。すべて他のツールに移動せずにFigmaの中で完結できることがかなり増えています。
Figma Drawというベクターデータを高度に編集できる製品も備わっています。AIを使って写真などの画像をベクターデータ化するベクタライズ機能が最近登場し、パス化することで色を自在に変えたり形を変えたりできるようになりました。マーケティングウェブサイト上のグラフィックの作り込みもFigma内で完結します。
デザインシステムに関連する機能も進化しています。Variablesを使えば、一元管理された色やフォントの定義を管理しつつ、開発に受け渡すときにもシームレスに一貫性を保つことができます。スロットと呼ばれるコンポーネント設計の機能や、Check Designというデザインのアクセシビリティチェックやハードコードされていないかといったクオリティチェックをする機能も今後提供予定です。アイデアだけが一人で走っていっても、生まれたアイデアを翻訳したり手戻りして直したりするコストがかかると、デザイナーがプロダクトを磨いていく時間が全くなくなってしまいます。結果的に凡庸なものが生まれてしまうことも少なくないため、デザイナーの無駄な手間をAIの力で減らし、差別化に時間を使えるようにすることが重要です。
デザインからコードへ、コードからデザインへ ─ 双方向ワークフロー
最後の4つ目は、デザインからコードへスムーズに移行できるか、それをリリース予測可能なものにしていくかというところです。FigmaはDev Modeという開発者向けのツールを提供してきました。元々は人間のデザイナーが人間のエンジニアにデザインのスペックをスムーズに渡すための機能でしたが、今やAIエージェントが開発の一人一人のステークホルダーとして増えているということで、さまざまな機能を拡張しています。その中で最も重要な機能の一つがFigmaの公式MCPサーバーです。

MCPサーバーは、Figma DesignやFigJam、Figma Makeなどで作られたデザインのコンテキストをAIエージェントに渡すためのものです。単にテキストプロンプトで「マップアプリを作って」と言えばそこそこのものはできますが、自社のコードベースに基づいたものをもとにAIが作ることで忠実度が上がります。
ただそれでも自社のデザインコンテキストやブランド要素は欠けています。テキストプロンプトだけ、コードコンテキストだけでは、自社ブランドに忠実なUIは生まれません。そこに関する情報を渡せるのがFigmaのMCPサーバーです。

加えてCode Connectという機能があります。Figma上でデザインされたボタンやカードなどのコンポーネントに対応する実際のコードを紐付ける機能です。パッと見ボタンというデザインがあったとき、3人のエンジニアがいたら3人が違うコードを書いてしまうかもしれません。しかしデザインシステムという唯一の情報源となるコード資産と紐付いていれば、どんなエンジニアでもこのボタンを再現するコードはこれだと約束されるので、かなり忠実度が高い形で、より素早くデザインをコード化することが可能になります。これは対人間だけでなく、AIにとってもかなり有効です。Code Connect UIというGUI上でデザインコンポーネントとGitHub上のコードを紐付けることもできます。
デモではClaude Codeを使い、すでに自社のコードが用意されているReactプロジェクト上で実演しました。Figmaデザインにあるサイドパネルのデザインリンクをコピーし、「このデザインをDemo Panel.tsxに実装してほしい」とプロンプトを書くと、MCPサーバーと連携してデザイン情報を取りに行きます。その中でサンプルコードの準備や、コードコネクトの紐付け情報のやりとりが行われ、たった一回のプロンプトでかなり再現度の高いものが実装されました。コードコネクトで紐付けた使ってほしいコンポーネントがちゃんと使われていることも確認できます。

そしてかなり最近リリースされたCode to Canvasという取り組みがあります。Claude Codeを通じて、コードでレンダリングされた実装結果をFigmaのデザインに持っていくというものです。今はいきなりコードから始めてアイデアを作り始めるケースも増えていますが、コードで作った具体的なプロトタイプをただ一つの画面で見ても、なかなかアイデアが膨らみづらいところがあります。コードで作ったプロトタイプの画面を一つ見ても、なかなかアイデアが膨らみづらいことがあります。アイデアを膨らませるためには、いろんな画面を横に広いキャンバスに並べてAとBを比べたり、アイデアを混ぜ込んだりする方がアイデアは膨らみやすい。Figmaのデザインキャンバスでそれができるとなお良いだろうという思想で生まれた機能です。
仕組みとしては、ローカル環境で動いている画面をキャプチャするスクリプトを挿入し、ブラウザ上でレンダリングされたUIコードを取得して、画像ではなく編集可能なデザインとしてFigmaに残すことができます。特定の要素だけをキャプチャしてデザインキャンバスに持ってくることも可能です。キャンバス上でアイデアを膨らませた後、再びAIにデザインリンクを渡して「このデザインをもとに実装を変えてほしい」とすれば、AIが並び替えなどを把握して実装を完了させます。

このようにデザインからコードへ、そしてコードからデザインへというイテレーションが実現し、開発プロセスの形が変わり始めています。現時点ではClaude Codeとの対応ですが、今後も対応範囲を拡大していく予定とのことです。コードからデザインという入り口ができたことによって、アイデアの元となるところがかなり広がり、可能性が広がっています。
速さの先にある「正しいものを作る」という問い
内製化や生成AI以前の開発では、ちょっとした仕様決めやボタンの文言を決めることさえもかなり多くのやりとりが必要でした。今はAIによって実装やアイデアの創出が早くなり、内製化によって組織がまとまってディスカッションしやすくなったことで、多くのボトルネックは減ってきています。
ただ、その裏にはさまざまなリスクやコスト、そして品質が伴っているのかという問いがあります。速さが出ても方向性がない速さは事故を起こしてしまうかもしれません。最初の段階で共通言語を持って、それを共創できる場所があって、それでこそ価値があると考えています。
問いとしては「どうやって作るか」以上に「どうやって正しいものを作るか」というフェーズに入っています。これは昔から言われていることではありますが、開発速度がこれほど速くなった今ではより一層重要になっています。

Figmaはこれまでチームのデザインのあり方やコラボレーションを再定義してきました。今ではさまざまな製品を加え、私たち自身もAIの力を借りながら、皆さんにAIネイティブなワークフローを形づくり提供することに努めています。
私のセッションは以上となります。ありがとうございました。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
内製開発Summit 2026
※動画の視聴にはFindyへのログインが必要です。






