Claude Designについての考えと所感
(samhenri.gold)- デザインのシステム化が強まるにつれて、Figmaはコンポーネント、スタイル、変数、propsのような独自単位を中心とした複雑な構造を拡大させ、実際の実装媒体との距離が生まれてしまった
- Figmaの独自フォーマットはLLMの学習データから自然に除外され、エージェント時代にコードベースのツールが台頭することで、デザインの原本(source of truth)が再びコードへ移動
- Claude DesignはHTML/JSを直接扱う正直な媒体として、Figmaのようにコードの損失を伴う近似(lossy approximation)を経ず、実際の実装媒体上で直接作業するアプローチ
- Claude Codeとの兄弟関係により、デザインと実装のあいだのフィードバックループを一つの対話に統合できる構造的な強みを持つ
- デザインツール市場がコードベースのツールと純粋な探索ツールへと分岐する中で、FigmaがSketchの轍を踏む可能性が出てきた
**Sketch moment**
Figma体系化のパラドックス
- プロダクトチームの規模が大きくなるにつれ、デザインはエンジニアリング組織の中で存在意義を正当化する必要が生まれ、そのために**体系化(systematization)**の方向へ押し進められた
- Figmaはそのためにコンポーネント、スタイル、変数、プロップなどの独自プリミティブを発明したが、一部はプログラミングから借用し一部はそうではないため、どれにもきれいに対応しない構造になっている
- ガイドラインは絶えず変わり、マイグレーションは積み重なり、自動化しようとすると品質の低いプラグイン数個に依存せざるを得ない状況
- このシステム自体を管理することに特化したデザイン職能が別途生まれるほど複雑性が増大
Source of Truthの移動
- Figmaとコードの間には、何が原本(source of truth)であるべきかをめぐる緊張関係が常に存在してきた
- FigmaはSketchに勝利する中で、自社ツールが**正本(canonical)**になるという立場を取った
- しかしこの勝利には隠れた代償があった。ロックダウンされた(locked-down)、しかも大半が文書化されていないフォーマットはプログラムから扱いにくく、LLMの学習データから自然に除外された
- LLMはコードで学習しており、Figmaプリミティブで学習したわけではないため、モデルはFigmaの体系を学べなかった
- コードを書くことがデザイナーにとっても容易になり、エージェントも進化するにつれて、source of truthは自然にコードへ回帰する流れを見せている
- Figmaが過去10年で導入してきた複雑なインフラは、それと比べると過剰に見えざるを得ない
「陶器を作りたいのに、なぜ陶器の水彩画を描いているのか？ ただ粘土をこねればいいのではないか？」
Figma自身のデザインシステムの複雑さ
- 実務では、コード側で直接修正したデザイン変更をFigmaへ逆移植(back-porting)する作業が非常に骨が折れる
- Figma自身のプロダクトのデザインシステムファイルを例として挙げ、最も有能なデザインシステムチームが作った成果物であっても極端に複雑な状態だと示している
- 946個の色変数が"bg/desktopBackgrounded"のような入れ子グループで構成され、1つの変数にLight、Dark、FigJam-Lightなど8種類のモード別の値がある
- モーダルフッターコンポーネントには12個のバリアントがあり、"DS Library Swap"、"QA Plugin"などの値を持つドロップダウンと8個のプロップを含む
- スライダーコンポーネントのエフェクトスタイルには、0.5pxのドロップシャドウ1つのためだけに別名のスタイルが存在する — CSS変数との対応関係を文書化する唯一の方法だからだ
- コンボ入力コンポーネントには16個のバリアントがあり、レイヤー名は"Default, Default, Close Button=False"のような形式
- 色の見え方がおかしいときのデバッグ工程として、コンポーネント確認 → 変数確認 → エイリアス(alias)された別の変数確認 → モード確認 → インスタンスレベルのオーバーライド確認 → ライブラリスワップが適用されたネストされたコンポーネント確認という多段階の追跡が必要
Figma Make vs Claude Design
- source of truthがコードへ移動する中で、Figmaは受動的でエージェント以前(pre-agentic)のシステムを抱えたままの気まずい立場に置かれている
- 今後のデザインツールは2つの明確な形へ分かれていく可能性がある
- 2016年にFigmaが答えた問い、すなわち「デザイナーである自分のアイデアを最速で引き出せるツールは何か？」をめぐる競争が再び始まる
- Figma Makeは、すでにFigmaの体系に慣れた人たちのためのツール
- Figmaスタイル、コンポーネントライブラリ、独自プロップ(Prop Props)を読み込み、この新しい環境でもなおデザインファイルが正本であると仮定する唯一のツール
- システムの中にとどまりたい、あるいはとどまらざるを得ない人たちのためのツール
- Claude Designは正反対の賭け
- アーツ・アンド・クラフツ運動の**"truth to materials"**原則、つまり物はそのもの自体と作られ方に対して正直であるべきだという考えに合致する
- Figmaはこれとは逆に、極度に硬直したスキーマの上へ自由な「バイブ」の外皮をかぶせた形 — タイプA気質の人が無理にリラックスしているふりをしつつ、内心ではフレームのネストやトークンの分離に叫んでいるようなものにたとえられる
- Claude Designは粗削りではあるが、少なくとも自分が何であるかについて正直だ。最後までHTMLとJSなのだ
Claude Designの構造的強み
- Claude Designの兄弟がコードを巧みに扱うClaude Codeであることが、核心的な構造上の利点
- 最終的にはClaude DesignからClaude Codeへ直接渡したり、その逆が可能な構造
- Claude Designのオンボーディングにはすでにリポジトリ(repo)取り込み機能がある
- デザインと実装の間にある（歴史的に常に摩擦の原因だった）フィードバックループが一つの対話へ収束する
コードと無関係な別種のツールが現れる可能性: 純粋な探索環境
- 分岐のもう一方では、コードへの期待がまったくないツールが登場する可能性がある
- 四角形を置き、レイヤースタイルを重ね、ブレンドモードやグラデーションを自由に扱い、システムやプロンプト規則に縛られない純粋な探索環境
- iPad + Pencil対応アプリで素早く四角形をスケッチする形かもしれず、37signalsが面白い試みをできる領域でもある
- 反対方向には、Photoshopのように高忠実度(high-fidelity)の合成へ全振りし、CSSエフェクトの限界から想像力を解放するツールへ向かう可能性もある
- Figmaがその寿命の90%にわたってレイヤーエフェクトとしてドロップシャドウやブラーだけしか提供してこなかったのは奇妙に感じられる
Figmaの「Sketchモーメント」
- FigmaのSketchモーメント（かつてSketchがFigmaに押しのけられたように、今度はFigmaが押しのけられる瞬間）が急速に近づいている
1件のコメント
Hacker Newsの意見
以前作ったデザインシステムを、ロゴ、ブランディング、フォントまで入れて今日見直してみたが、腹が立つほど修正を重ねた末に、ようやく満足できる結果を得られた。
ところが使用量を見たら、週次の Claude Design 制限の**95%**をすでに使い切っていた。
これでは実戦向けツールというより、サンプル用のおもちゃに近いと感じた。
私たちの求めるスタイルとはまったく合っていなかったが、コンテンツのグルーピングや IA の判断のいくつかは自分の作業にも取り入れられそうだった。
全体として印象は良かったが、後で Twitter で他人の成功事例を見たら、自分が受け取ったモックアップとほとんど同じで笑ってしまった。
こうした画一化の問題は、AI が作るテキスト、コード、画像と同じように今後も付きまとうと思う。
妻の妹は小さな衣料会社を経営しているが、この6年間で腕はかなり上がったとはいえ、最初の頃はアイデアを実際の成果物に落とし込むのに本当に苦労していた。
そういう人にとっては、初期参入障壁を下げてくれるどんなツールでも十分試す価値があると思う。
それでも今はresearch preview段階なのだから、今後変わると思う。
最初のデザインシステムでは、自分の iPaaS スタートアップ向けに新しいフッターセクションを作り、4案のうち4つ目がかなり良かった。
その後 Claude Code と連携して少し整え、コードを生成してそのままデプロイまで終えた。興味があれば tediware.com のフッターセクション で、左の "Origin story" と右の登録パネル部分を見ればよい。
複雑な実装ではなかったが、出てきたアイデアと連携フローが非常に簡単で、大きな可能性を感じた。
Claude Design はOpus 4.7を使っているので、以前のモデルより高価だ。
まだ公開2日目で完成品ではなく、Anthropic はもともと非常に速いペースで改善する会社だ。
しかも Claude を長く使ってきたなら、すでに私の好みやスタイルを理解しているので、別の AI デザインツールに乗り換えるとまた最初からやり直しになる。
ただ ZIP エクスポートはできたので、そのファイルを Google の Stitch に入れてみたが、互換性はあまり良くなかった。
私は Claude Design がデザインの複雑さをすべて取り除いてくれる、という主張にはあまり同意しない。
Claude でバイブコーディングしたアプリが単純に見えるのは、実際には製品のスコープが単純だからだ。
自転車と飛行機を同じ基準で比べて、単純さを取り違えているようなものだ。
同じデザインシステムのコンポーネントをコードと Figma で作れば、コードのほうが条件分岐や制御フローのおかげでより簡潔にできることはある。
だがコードは、画面上で直接描くより柔軟性に欠け、創造的自由度を出すのも難しい。
結局のところ複雑性は、人が4つの製品に8つのモードとライト/ダークテーマを重ねるような形で、自分たちで生み出している場合が多い。
Claude が保守を少し楽にしてくれることはあっても、複雑性そのものを大きく取り除いてくれるわけではないと思う。
だからこの流れは Figma にかなり大きな打撃になると思う。
それを実現するソフトウェアが最終的には勝つと思う。
自分の理解が合っているのか聞きたかった。
私は子どもの頃から開発してきたが CSS は得意ではなく、実際に開発者、さらにはフロントエンド開発者であっても、単なるロゴやランディングページのスケッチではなく、製品全体のデザインを Figma のようなもので管理するデザイナーと協業する組織が多いのか気になっていた。
そして、そうしたデザイナーは開発者でないまま、何らかのスタイルデータベースのようなものを維持し、コード変更なしに見た目を扱うことを目指しているのか、それとも通常はフロントエンド開発者が Figma も一緒に扱うが、コードと分離されている点を嫌っているのか知りたかった。
クライアントもそれを直接見たり、少なくともその Figma の成果が反映されたブランディング用スライドを見て承認したりする。
その後フロントエンドは Figma を見て CSS で再実装するが、Figma の CSS コピペ機能は実質的に使い物にならないinline CSSレベルなので、ほとんどの場合は最善の近似で作り直すことになる。
単位系も合わず、親子関係や CSS 変数、クラス階層なども反映されない。
複数のフロントエンド開発者がそれぞれコンポーネントを別々に実装していくと、ドリフトも生じる。
だから Storybook のような Storybook で別のフロントエンドの基準点を作り、そこから React や NextJS に組み込んだり、CMS コンポーネントとして再実装したりもする。
そうなると、何が本当の source of truth なのかという問いが出てくるが、実際には伝言ゲームのようにつながった複数の基準点の連鎖に近い。
メインプロジェクトの外で別途作るプロモーション用ランディングページまで出てくると、また別のシステムで同じデザインをもう一度実装することになる。
結局、デザインからコードへ移るhandoff のギャップの中でデザイナーの意図が損なわれたり、開発者が文字列の長さ、要素数の変化、実際のスクロール、さまざまな画面サイズへの対応といった現実的な問題を後から背負わされたりする。
この短いミーム動画が面白いのに笑えないのは、まさにその現実をあまりに的確に突いているからだ。
一般にデザイナーはコードを書かず、開発者はデザインをせず、その両方がうまい人は本当にまれだ。
正直かなりひどいやり方だが、以前の代替手段よりはましだと感じる。
それでも、ビジュアルデザインをコードに翻訳する退屈な作業の大半を自動化し、コードと直接つながるツールには及ばない。
私は Claude Design はまだ使っていないが、Figma の大量の GUI オプションよりコードのほうがずっと楽な人間だ。
私も質問者と似た経歴だからか、そうした視点には本能的な拒否感がある。
時間がたってもすべてのエンジニアにスタイル差なく一貫した実装をさせるには、ある程度の中央集権的な基準が必要だからだ。
私は最近 figma-kiwi-protocol でFigma プロトコルをリバースエンジニアリングしているので、「Figma はエージェント時代に必要な学習データを自ら排除した」という話には本当に共感した。
Figma のバイナリ形式は、すべてを作り直すような発想になっていて、Web・Android・iOS・その他あらゆるデザインを扱うぶん万能ではあるが、Web とは完全な 1:1 対応にならない。
そしてエージェントに役立つためには意図が明確である必要があるが、実際に UX デザイナーが作った Figma を実装したことがある人なら分かるように、人間ですらデザイン意図を正確に読み取るのが難しいことが多い。
ドイツ語のように文字が長くなったらボタンはどうなるのか、CSS に移したら2行に崩れた場合はどうするのか、iPhone 以外の端末ではどうなるのか、CSS では不可能なグラデーションボーダーは何で代替するのか、4K 画面ではどうなるのか、といった問いが次々に出てくる。
props や autolayout で一部は答えられるとしても、現実の UX 担当者が常に Figma を完璧に使いこなす神話的存在というわけではない。
だから内部が HTML ベースのツールが早く追いつくことを期待しているし、できればプロダクトマネージャーが UX 担当に渡したプロンプトまで一緒に見られるとよいと思う。
文章自体は良かったし、最後の数段落は本当に面白かった。
特に、何か別のもののふりをせず、自分のアイデンティティに正直であるべきだというくだりが気に入った。
そのうえで PenPot がこのエージェント時代にかなり有利な立場にあるのではないかと思った。
fig 系のキャンバス的アプローチとは違って、実際のマークアップベースのデザインの方向に進んだからで、もしその方向に関心があるならなおさら可能性がありそうだ。
InVision が閉鎖されてデジタルホワイトボード方面へ転換した時点で、私にとってこのデザインツール市場は事実上終わった感があった。
それだけ難しい市場だと思う。
もっと根本的には、デザインシステムを長期的にきちんと維持するのがあまりに難しく、特にコードやコンポーネントライブラリに深く結びついているのに、その層にはデザイナーがほとんど触れない。
Claude Design も Figma も他のどんなツールも、再利用可能で見栄えのよいコンポーネントとレイアウトをめぐるStorybook 地獄を根本的には解決できない気がする。
解決策はもっと下の層、つまりコンポーネントレベルで変わるべき問題のように思える。
今は新しいデザインごとに差し込むコンポーネントを作っておく、という考え方に縛られている。
気に入ったコンポーネントができたら、その定義を markdown に保存しておき、次のデザインではツールにその markdown を読ませて必要なときにそのコンポーネントを使ってもらえばいい。
そうすれば、もっと柔軟で面白いフローになると思う。
スクリプト可能で、直接描画もできるべきで、デザインを変えればフロントエンドコードが即座に変わり、コード変更も同じレベルでデザインに反映されるべきだ。
最終形は、デザイナーとフロントエンドエンジニアがhandoff なしの共同執筆者になるモデルだと思う。
ただ今後は修正、抽出、整理がほぼタダ同然になるので、そうした構造化自体の重要性が下がるという主張もある。
私はまだ完全には納得していないが、そういう話が出てくる理由は理解できる。
私はここ数年デザインツールを自分で作ってきた立場からすると、この文章はデザイン領域と Figma という会社の両方をかなり根本的に誤解しているように感じた。
Figma はもともと、成功する製品と同じくらい成功する会社を作ることに焦点を当てていた。
当初はもっと野心的な方向もあり、Evan Wallace のような人材のおかげで実行力もあったが、結局は WebGL のデモよりも金になる具体的な製品に集中したからこそ今のビジネスになったのだ。
3D 機能などがないのも、その選択の結果だと思う。
Figma はデザインツール自体より先に、企業が実際に使う製品を作る会社であり、IPO まで行った時点でその目標はすでにかなり達成されていた。
今後市場がどうなるかは分からないが、技術的に派手なデモよりも戦争資金を持つ側のほうがはるかに有利かもしれない。
そして記事で挙げられている問題は、Figma の中の人たちも、実際デザインツールを作ったことのある誰もが、すでによく理解していることだ。
UI/UX がデザイン・開発・PM の交差点にあることも、コードのようなsource of truthに近づくべきだということも、どれも自明だ。
問題は、それを本当に実装しようとすると、デザインツールの範囲を超えて、コーディング、データ管理、アーキテクチャツールにまで広がる巨大な難題になることだ。
AI については私も確信はないが、最近の SOTA モデルはあまりに汎用性が高く、専用データよりベースモデルの推論力のほうが重要かもしれないと感じる。
UI デザインは外に出ている情報が多いので、Web から収集することもできるからだ。
この争いに私は特別な利害関係はないし、元記事の分析が正しいのかもよく分からない。
それでも「独占的なファイル形式のせいで出遅れた」という話には、いつ聞いても少しシャーデンフロイデを感じる。
いくつかの指摘は良かったが、全体として完全には同意しない。
Sketch が Figma に負けたのはデザインツーリングとマルチプレイヤー体験のためだったと思う。
物理製品でも実際に作る前にまず設計するように、デジタル製品でも設計という段階そのものはなくならないと思う。
むしろ Figma はあれもこれもやろうとするのではなく、自分が正確に何になるのかというアイデンティティを早く決めるべきだと思う。
Mac アプリをインストールして特定のファイルを開かせる方式は、時間がたつほどファイルも古び、アクセス性も落ちていった。
関連して、最近の HN スレッドに Claude Design があり、2026年4月時点でコメント732件も付くほど反応が大きかった。