Google I/O 2026で発表されたGoogle StitchとDESIGN.md。
多くの人は「Figma対抗のデザインツールが出た」と受け取ったかもしれない。しかし私には、それ以上に大きな変化の予兆に見えた。
Googleが本当に狙っているのはFigmaではない。
DESIGN.mdの向こうにある、「意図を直接AIへ渡す世界」である。
今回はGoogle Stitch、DESIGN.md、そしてFigma文化の未来について考えてみたい。
Googleが投げ込んだDESIGN.mdという爆弾
2026年のGoogle I/Oは、例年以上にAI一色だった。
Geminiの進化、エージェント機能の強化、検索体験の変化など話題は数多かったが、その中でも個人的に強い違和感を覚えた発表がある。
Google Stitchだ。
一見すると、ただのUI生成ツールに見える。
自然言語や音声で要件を伝えると、AIが複数の画面デザイン案を自動生成し、そのままReactやHTMLへ落とし込める。ここだけ聞けば、最近よくあるAIデザインツールの一つに思えるだろう。
しかし、発表内容をよく見ていると、Googleが本当に作ろうとしているものは別に見えてくる。
その象徴が「DESIGN.md」だ。
README.mdがプロジェクトの説明書なら、DESIGN.mdはデザインの説明書である。
色やレイアウトだけではない。
なぜその画面が必要なのか。
誰のための画面なのか。
何を優先し、何を犠牲にするのか。
そうした「意図」を構造化してAIへ渡すための文書だ。
ここで少し立ち止まって考えてみる。
これまでの開発現場では、
要件定義
↓
ワイヤーフレーム
↓
デザイン作成
↓
Figma共有
↓
実装
という流れが当たり前だった。
しかしGoogleが提示している世界では、
要件定義
↓
DESIGN.md
↓
Stitch
↓
実装
になる。
Figmaが消えている。
もちろん明日からFigmaがなくなるわけではない。
だがGoogleが提示した未来図の中で、Figmaは中心ではなくなっている。
これは単なる新機能の追加ではない。
開発プロセスそのものへの挑戦だ。
そして私は、この発表を見た瞬間に別の出来事を思い出した。
Universal Commerce Protocol（UCP）である。
Googleは近年、一貫して同じ方向へ進んでいるように見える。
検索結果一覧を短縮する。
ECサイトを飛び越える。
そして今度は、デザインツールを飛び越えようとしている。
もしそれが正しいなら、DESIGN.mdは単なるMarkdownファイルではない。
AI時代の新しい設計言語なのかもしれない。
なぜFigmaは神格化されたのか
最初に断っておきたい。
この記事はFigma批判ではない。
むしろFigmaは、過去10年のソフトウェア開発において最も成功したツールの一つだったと思う。
だからこそ、Googleの動きが大きな意味を持つ。
もし相手が無名のツールなら誰も気にしない。
しかし今回揺らいでいるのは、業界標準そのものだからだ。
少しだけ時代を振り返ってみよう。
Figma以前のUIデザインは混沌としていた。
Photoshopで画面を作る。
Illustratorで作る。
Sketchを使う。
Adobe XDを使う。
それぞれが独自形式で管理され、共有も面倒だった。
デザイナーが作った画面を開発者が見て、
「この余白は何ピクセルですか？」
「この色コードは何ですか？」
「このボタンのホバー状態は？」
と延々と確認する。
そんな光景は珍しくなかった。
そこへ現れたのがFigmaだった。
ブラウザだけで動く。
複数人で同時編集できる。
URLひとつで共有できる。
そしてコンポーネントによる再利用やデザインシステムの構築が容易だった。
当時としては革命だった。
特に大企業や大規模サービスでは絶大な効果を発揮した。
ボタンのデザインを変更すれば全画面へ反映される。
複数のデザイナーが同じルールで作業できる。
開発者はDev Modeから情報を取得できる。
デザインと実装の距離が大きく縮まった。
Figmaが神格化されたのは当然だったのである。
実際、求人票を見ても「Figma必須」という記載は珍しくない。
デザイン会社の採用要件にも必ずと言っていいほど登場する。
単なるツールではなく、
「モダンな開発プロセスを理解している証明書」
のような扱いになっていった。
しかし、ここで興味深い現象が起きる。
ツールが普及すると、人々は目的ではなく手段を最適化し始める。
本来の目的は、「良い製品を作ること」だったはずだ。
ところが次第に、
Auto Layoutをどう組むか。
Variantをどう設計するか。
コンポーネントをどう管理するか。
デザインシステムをどう構築するか。
といった、Figma内部の作法そのものが重要視されるようになった。
もちろん、それらには価値がある。
大規模開発では必要な技術でもある。
しかし個人開発や小規模チームから見ると、時に奇妙な光景にも映る。
画面を作るためにツールを使っていたはずが、
いつの間にかツールのために時間を使っている。
そんな逆転現象が起き始めていた。
Googleが今回狙っているのは、おそらくそこだ。
Figmaそのものではない。
Figmaが前提となった開発プロセスである。
そして、その話をする前に、もう少しだけ踏み込んでみたい。
Figmaが生み出したのは優れたツールだけではない。
「Figma文化」と呼べる新しい開発文化そのものだったのである。
Figma文化が生んだもの
Figmaが普及した結果、生まれたのは単なるデザインツールの標準化ではない。
私はむしろ、
「Figma文化」という新しい職能領域が誕生したことの方が大きいと思っている。
例えば昔のWeb制作では、
デザイナーがPhotoshopで画面を作り、
エンジニアがHTMLとCSSで実装する。
役割分担は比較的単純だった。
ところがFigma時代になると事情が変わる。
コンポーネント設計。
Auto Layout。
Variant。
Design Token。
デザインシステム。
Dev Mode。
UIライブラリ管理。
これらを適切に運用するための知識が必要になった。
その結果、
「画面をデザインする人」
とは別に、
「Figmaを管理する人」
が必要になった。
大規模組織では当然の流れだった。
数百画面規模のサービスを開発するなら、統一ルールは欠かせない。
デザインシステムがなければ運用は破綻する。
Figmaはその問題を見事に解決した。
だからこそ急速に業界標準となった。
しかし一方で、副作用もあった。
本来、
「どんなサービスを作るのか」
が重要だったはずなのに、
次第に
「Figma上でどう表現するか」
へ重心が移っていったのである。
これは開発現場だけの話ではない。
採用市場にも現れていた。
求人票を見ると、
React
TypeScript
AWS
と並んで、
Figma
が当たり前のように登場する。
デザイナーだけではない。
フロントエンドエンジニアですらFigma経験を求められる。
つまりFigmaは、
単なるツールではなく、
開発文化の共通言語になった。
だからこそ、多くの人がFigmaを学び、
多くの企業がFigmaへ依存するようになった。
しかしAIが登場すると、この前提が揺らぎ始める。
AIはAuto Layoutを学びたがらない。
AIはVariantの作法にも興味がない。
AIが欲しいのは、
「何を作りたいのか」
という情報だけだからだ。
例えば、
「中小企業向け顧客管理システム」
という要件がある。
従来なら、
要件を整理する。
ワイヤーフレームを描く。
Figmaで高精度化する。
レビューする。
実装する。
という流れだった。
しかしAIは違う。
要件を読む。
UIを生成する。
コードを書く。
終わりである。
途中にFigmaを必要としない。
もちろん現在のAIは完璧ではない。
ブランドガイドラインの厳密な運用や、複雑なデザインシステムの管理では依然としてFigmaが強い。
しかし重要なのはそこではない。
GoogleがStitchやDESIGN.mdで示したのは、
「まずFigmaで考える」という常識を崩す可能性だった。
これまでFigmaは、
開発プロセスの中心にいた。
だがAI時代には、
Figmaは中心ではなく、
必要に応じて利用する一つのツールへ戻るかもしれない。
そして、その変化の本質はデザインツールの置き換えではない。
もっと根深い。
Googleが本当に壊そうとしているのは、
「人間向け中間表現」
そのものだからである。
Googleは何を破壊しようとしているのか
Stitchの発表を見て、多くの人はこう考えたと思う。
「GoogleがFigma対抗製品を出した」
しかし私は少し違う見方をしている。
Googleが本当に狙っているのは、Figmaそのものではない。
もっと大きなものだ。
それは、
「人間向けの中間表現」
である。
少し乱暴な言い方をすると、これまでのソフトウェア開発は翻訳作業の連続だった。
顧客が要望を伝える。
PMが要件に翻訳する。
デザイナーが画面に翻訳する。
エンジニアがコードに翻訳する。
それぞれが異なる言語を話している。
その翻訳装置としてFigmaは極めて優秀だった。
だから業界標準になった。
しかしAIが登場すると状況が変わる。
AIは翻訳を必要としない。
要件を直接理解できるからだ。
例えば、
「小規模事業者向けの顧客管理システムを作りたい」
という要求があるとする。
従来なら、
要件定義書を書く。
ワイヤーフレームを描く。
Figmaで整える。
レビューする。
実装する。
という工程が必要だった。
だがAIは違う。
要件を読む。
画面を生成する。
コードを書く。
終わりだ。
もちろん実際には細かな修正や検証は必要だろう。
しかし本質的には、
途中の翻訳工程が大幅に削減される。
GoogleがStitchで見せたのは、まさにその未来だ。
そしてDESIGN.mdは、その未来を支える重要な部品に見える。
DESIGN.mdはデザインデータではない。
Figmaファイルでもない。
画像ですらない。
そこに書かれるのは、
- 目的
- 構造
- 優先順位
- 利用者
- 操作フロー
といった「意図」だ。
つまりGoogleは、
ビジュアルより前の段階を重要視している。
もっと言えば、
ビジュアルを一時的な生成物として扱おうとしている。
これは非常に大きな発想転換だ。
これまでUIは成果物だった。
しかしAI時代には、
UIは出力結果になる。
必要なら何度でも生成し直せる。
ユーザーごとに変えることもできる。
デバイスごとに最適化することもできる。
そのとき価値を持つのは、
画面そのものではなく、
画面を生み出す設計思想だ。
だからGoogleはDESIGN.mdに力を入れる。
だからStitchを作る。
だからGeminiと統合する。
すべては同じ方向を向いている。
「人間が絵を描いて伝える時代」から、
「意図を記述してAIへ渡す時代」への移行だ。
もしこの流れが本格化するなら、
Figmaが消えるかどうかは本質ではない。
本当に変わるのは、
ソフトウェア開発そのものの前提なのである。
UCPと同じ匂いがする
ここまで読んで、
「なるほど、GoogleはFigmaを脅かそうとしているのか」
と思った人もいるだろう。
しかし私は、この話を単なるデザインツールの競争だとは思っていない。
むしろ最近のGoogleの動きを見ていると、同じ思想が様々な分野で繰り返し現れているように見える。
例えばUniversal Commerce Protocol（UCP）だ。
UCPの思想を極端に単純化すると、
「ECサイトを見なくても買い物できる世界」
である。
これまで人間は、
検索する。
ECサイトを開く。
商品を探す。
比較する。
カートに入れる。
決済する。
という長い工程を踏んでいた。
しかしAIエージェントが普及すると話が変わる。
「安い順で買っておいて」
と言うだけで良くなる。
そのとき重要なのはECサイトのUIではない。
商品情報や在庫情報へアクセスできるプロトコルだ。
つまりGoogleは、
人間向けの画面より、
AI向けの接続方法を重視し始めている。
そして私は、StitchやDESIGN.mdにもまったく同じ匂いを感じる。
従来の開発では、
要件
↓
Figma
↓
コード
だった。
しかしGoogleが見せている未来は、
要件
↓
DESIGN.md
↓
コード
だ。
ここでも中間レイヤーが消えている。
興味深いのは、これが最近のGoogle製品全体に共通していることだ。
検索では、検索結果一覧よりAI Overviewが前面に出てくる。
Geminiでは、複数サービスを横断するエージェント化が進む。
UCPでは、ECサイトそのものを迂回しようとしている。
Stitchでは、デザインツールを経由しなくなる可能性を示した。
一見するとバラバラな施策に見える。
しかし共通する思想は明快だ。
Googleは、
「人間向けの中間工程」を削減し続けている。
検索結果を読む工程。
ECサイトを巡回する工程。
Figmaで画面を作る工程。
そうした工程をAIへ置き換えようとしている。
もちろん、これはGoogleだけの話ではない。
OpenAIのCodexを見ても同じだ。
HyperFramesを触ったときにも同じ感覚を覚えた。
最初に存在するのはコードや意図であり、
画面や動画はそこから生成される。
人間は結果を見るだけだ。
以前は、
画面が主役だった。
今は、
意図が主役になり始めている。
だから私は、このDESIGN.mdという名前に妙な未来感を覚える。
単なるMarkdownファイルではない。
Googleが考える次世代の設計言語。
そう考えると、今回の発表はFigmaへの挑戦状というより、
「AI時代の開発プロセス宣言」
だったのかもしれない。
コラム：DESIGN.mdとは何か？
ここまで何度もDESIGN.mdという言葉を使ってきた。
しかし実のところ、多くの開発者にとってもまだ馴染みの薄い存在だろう。
名前だけ見ると、
「README.mdの親戚かな？」
くらいの印象かもしれない。
実際、その理解はそれほど間違っていない。
README.mdがプロジェクトの説明書なら、
DESIGN.mdは設計思想の説明書である。
例えばGitHubには様々なMarkdown文化が存在する。
README.md
プロジェクト概要
CHANGELOG.md
更新履歴
CONTRIBUTING.md
開発参加ルール
最近ではさらに、
AGENTS.md
CLAUDE.md
COPILOT.md
など、
AI向けの説明書も増え始めている。
DESIGN.mdも、その流れの延長線上にある。
ただし目的は少し違う。
DESIGN.mdが扱うのは、
画面の見た目ではなく、
画面の意図だ。
例えば従来なら、
デザイナーがFigmaを開き、
画面を作り、
レビューし、
開発者へ渡していた。
しかしAIにとって重要なのは、
「どんな画面なのか」
ではない。
「なぜその画面が必要なのか」
である。
例えば顧客管理システムなら、
目的：
顧客情報を効率的に検索・編集したい
対象：
中小企業の事務担当者
レイアウト：
左サイドバー
右メイン領域
優先事項：
一覧性
検索速度
入力ミス防止
デザイン方針：
シンプル
余白多め
学習コストを低くといった情報の方が重要になる。
AIはこれを読んで、
画面を生成し、
コードを書き、
改善案まで提案できる。
ここで面白いのは、
DESIGN.mdが画像を持たないことだ。
Figmaは視覚情報を保存する。
DESIGN.mdは意図を保存する。
似ているようで全く異なる。
極端な言い方をすると、
Figmaは「どう見えるか」を記録する。
DESIGN.mdは「なぜ作るのか」を記録する。
そしてAI時代になるほど、
後者の価値が高まっていく。
実際、最近のAIコーディングを触っていると、
画像より説明文の方が重要になる場面が増えている。
Codexでもそうだ。
HyperFramesでもそうだ。
生成AIはピクセルより文脈を好む。
だからGoogleはDESIGN.mdを推しているのだろう。
単なるMarkdownファイルに見えて、
その実態はAI時代の設計思想書なのかもしれない。
Figmaは本当に消えるのか
ここまで読むと、
「Figma終了のお知らせなのか」
と思われるかもしれない。
結論から言うと、それは違う。
少なくとも数年単位で見れば、Figmaが消える未来は考えにくい。
むしろ大規模開発の現場では、今後もしばらく重要な地位を維持するだろう。
数百画面規模のサービス。
厳格なブランドガイドライン。
複雑なデザインシステム。
複数部署によるレビュー体制。
こうした環境では、依然としてFigmaの価値は大きい。
Google自身ですら、社内で何らかのデザイン管理基盤を持ち続けるはずだ。
問題はそこではない。
私が注目しているのは、
「Figmaが必要になるタイミング」
の変化である。
これまでFigmaは開発プロセスの入口にいた。
要件が決まる。
Figmaで画面を作る。
レビューする。
実装する。
この流れが一般的だった。
しかしAI時代には順番が変わるかもしれない。
要件を書く。
DESIGN.mdを書く。
AIが画面を生成する。
AIがコードを書く。
必要ならFigmaで調整する。
この流れになると、Figmaは入口ではなく出口に近づく。
主役ではなく補助役になる。
これは決して価値の消失ではない。
立ち位置の変化だ。
例えるならPhotoshopに近い。
Photoshopは今でも強力なツールである。
しかしWeb制作の中心ではなくなった。
かつてはPhotoshopが制作工程の中心だった。
今は必要な場面で使う専門ツールになっている。
Figmaも似た道を歩む可能性がある。
もちろん反論もあるだろう。
AIが生成するUIは品質が低い。
ブランド表現が不十分だ。
大規模運用には耐えられない。
その指摘は現時点では正しい。
しかし重要なのは現在の完成度ではない。
Googleが進もうとしている方向である。
検索もそうだった。
翻訳もそうだった。
音声認識もそうだった。
最初は不完全だった。
しかし方向性そのものは変わらなかった。
今回も同じかもしれない。
AIによるUI生成が完璧になるかどうかは分からない。
だがGoogleは明らかに、
「まず画面を描く」という文化から離れようとしている。
そして、その変化はFigmaという製品の問題ではない。
もっと大きな話だ。
本当に終わりを迎えるのは、
ある特定のツールではなく、
私たちが長年当たり前だと思ってきた開発プロセスそのものなのかもしれない。
本当に終わるのはFigmaではない
この記事では、Google StitchやDESIGN.mdの登場をきっかけに、Figma文化の変化について考えてきた。
しかし最後にもう一度整理しておきたい。
私自身は、Figmaがなくなるとは思っていない。
今後も多くの企業で使われ続けるだろう。
大規模開発では重要な役割を担い続けるはずだ。
だからこれは、
「Figma終了論」
ではない。
むしろ私が感じているのは、その逆である。
GoogleはFigmaを攻撃しているのではない。
Figmaを経由する理由を消そうとしている。
そこが恐ろしい。
これまでソフトウェア開発では、
仕様書を書く。
ワイヤーフレームを描く。
デザインを作る。
実装する。
という工程が当たり前だった。
それぞれに専門職が存在し、
それぞれに専用ツールが存在した。
しかしAIが登場すると事情が変わる。
AIは仕様書を読む。
AIはUIを生成する。
AIはコードを書く。
そして必要なら、AI自身がUIを修正する。
その世界では、
画面は成果物ではない。
一時的な出力結果になる。
必要なら何度でも作り直せる。
利用者ごとに変えることもできる。
デバイスごとに変えることもできる。
そうなると価値を持つのは、
画面そのものではなく、
画面を生み出す意図になる。
だからGoogleはDESIGN.mdを作る。
だからStitchを作る。
だからGeminiと結びつける。
すべて同じ方向を向いている。
最近のGoogleを見ていると、私はある共通点を感じる。
UCPではECサイトを飛ばそうとしている。
AI Overviewでは検索結果一覧を飛ばそうとしている。
Gemini Agentでは操作画面を飛ばそうとしている。
そしてStitchではデザイン工程そのものを飛ばそうとしている。
どれも、
人間向けの中間工程を削減する試みだ。
その意味では、今回の話はFigmaの話ですらないのかもしれない。
DESIGN.mdが象徴しているのは、
「人間が絵を描いて意思を伝える時代」
から、
「意図を記述しAIへ渡す時代」
への移行だからだ。
もしGoogleの描く未来が実現するなら、
将来振り返ったとき、
2026年のStitchやDESIGN.mdは単なる新機能ではなく、
ソフトウェア開発の前提が変わり始めた瞬間として記憶されるのかもしれない。
