Figmaと実装の乖離は怠慢ではなく、構造の欠陥である｜Matz

結論デザインと実装の乖離は、運用の頑張りでは解決しません。Figmaとコードはパラダイム（表現の仕組み）が違うため、どちらか一方を「正」にした時点で、乖離は構造的に発生するからです。 私の答えはこうです。正はFigmaにもコードにも置かず、Component Spec（コンポーネント仕様書） という文書に置く。Figmaとコードは、Specから生成される派生物と捉える。 派生物はいつでも原本に立ち返れます。だから乖離は「頑張って同期するもの」ではなく、「検出して、生成し直せば消えるもの」に変わります。 なぜこの考えに至ったのか、市場の動きから順に説明します。 AIがデザインを「生成」する時代が来た大きな流れとして、言うまでもなくAIがあります。 Figma Make、Pencil、Claude Design、Figma Agent。この1年で、これまで人間が手作業で作っていたデザインを、A

[strawberryhunter]

HTML/CSSの表現力を持たないFigmaをWeb開発に使うのは最初から間違いだし、スマートフォンアプリについては今やFigmaを使う必要も無いのでは、と思う。1年以上経ってまだ使ってるのが逆に興味深い。

[Magicant]

そもそも何で Figma と実装両方要るの? 生成するならなほさら

[yushph]

課題意識は激しく同意。Specの維持コストは想像以上に高そう。

[atsushieno]

仕様記述言語の目下の課題は説得力のある標準技術の不在なんだろうと思っているけど、そういう話はやったことある人がしたほうがいいやつだな

[tacamula]

初期はFigmaレベルの柔軟さで検討と探索したいし、中後期からは構築を意識した作りにしたい。その隙間をどう埋めるかでLLM前提に文章化するのは面白い試み

[unknownlabel]

Claude Design生成レベルでOKならそもそも最初から不要。自分は手作業デザイン側の人間なので絶対必要

[araen]

Spec駆動のUI開発でFigma言及するのは微妙かなと思った/書いた: https://araen.hatenablog.com/entry/2026/07/21/124518

[pchatsu]

via https://x.com/Matz_Tak/status/2078730900960129161

[eriotto]

俺も真剣に悩んで試行錯誤している。チームのスタッフが作成したPDFからHTMLを一発生成するプログラムを自作してみたりしているが、そもそもCloud Designで生成できる程度のデザインならFigmaの出番は無く悩む事もないのでは

[Listlessness]

ClaudeDesignで作ったモックをFigmaに取り込んでMCPでつないで実装に回すのはどうかな？とGeminiに聞いたらClaudeDesignで作ったHTMLをそのままLLMに渡した方が(Code to Codeが)ええでって言ってた。Figma経由はノイズになるだけだってさ

[mak_in]

figmaは初期の柔軟に考えたいフェーズで使いたいのだと思うのだが、今のLLMは視覚的に思考するのでなく、文章として思考するので、そもそも相性が良くないと思っている。figmaからHTMLへ、でなく視覚的思考からHTMLへ

[tomono-blog]

figma挟まるの本当になんとかしてほしい。憲法にしたがる勢力がいる。

[manimoto]

合わせて読みたい。Storybookを使用した話だが課題感は同じ。Figmaを正とする運用に構造上無理が来ている。 ■「Figma と違う」をなくす Storybook 運用 https://zenn.dev/micin/articles/54cf1c16773056

[pochi-taro00]

figmaの通り実装したら iOSのフォントサイズの変更に対応できなくて詰んだ

[fn7]

Rubyの人ではない

[chaoschk]

デザインの要件/要求定義と非機能機能の仕様化の話。「実装」が何を指してるのか曖昧で混乱した。Figmaもコードも実装の一種。構造の欠陥というより、詳細設計が無く、その設計根拠が曖昧なことが問題。仕様書化は良い

[dd41kk]

Rubyの人かと思った

[nguyen-oi]

パラダイムの違いって指摘はかなり納得感ある。でも仕様書という中間生成物のメンテコストを誰が払うかで結局揉める未来が見える