ハクソク

世界を動かす技術を、日本語で。

クロードデザインに関する考えと感情

7時間前原文(samhenri.gold)

概要

  • Figmaのデザインシステムの複雑化と限界についての考察
  • Claude Designの新アプローチと、設計と実装の融合の可能性
  • デザインツールが**「コード中心型」と「自由表現型」**の二極化へ進む予測
  • Figmaの現状と今後の競争環境に対する批判
  • SketchやFigmaチームへの率直なメッセージ

Figma時代の終焉とClaude Designの台頭

  • プロダクトチームの規模拡大に伴うデザインのシステム化要求
    • Figma独自のコンポーネント、スタイル、変数、プロップスなどの導入
    • 一部はプログラミング概念を流用、しかし完全な対応は困難
  • システムの進化と移行作業の蓄積
    • 自動化を目指しても質の低いプラグインしかない現状
    • デザインシステム専門職の誕生
  • Figmaとコード間での**「ソース・オブ・トゥルース」**の葛藤
    • FigmaはSketchに勝利したが、独自形式の閉鎖性が裏目に
    • LLM（大規模言語モデル）はコード中心で学習、Figmaのプリミティブは学習対象外
  • コードの書きやすさ向上とエージェント技術の発展
    • **「真のソース」**が再びコードへ回帰
    • Figmaが築いた複雑なインフラの価値低下

Figmaの複雑性の現実

  • Figma公式デザインシステムファイルの実例
    • 946色変数、8つのモード、12種類のバリアント、8つのプロップス
    • CSS変数との対応付けのためだけに独自スタイル名を付与
    • 多層ネストやライブラリスワップ、インスタンスごとの上書き
  • デバッグの困難さ
    • 変数の参照元を辿るだけで精神的消耗
    • コードで直接管理した方が明快という実感

デザインツールの今後の分岐

  • Figma Makeの立ち位置
    • 既存Figma資産に依存、「デザインファイルが正」とする世界観
    • システム内に留まることを選ぶ人向け
  • Claude Designのアプローチ
    • HTMLとJSを基盤とし、「素材に忠実」なArts and Crafts的思想
    • Claude Codeとのシームレスな連携
      • リポジトリのインポート対応、設計と実装の往復が容易
  • もう一つの対極的なツール像
    • コードを意識せず自由に表現できる環境
      • iPadやPencil対応のスケッチアプリ
      • 高精細な合成やエフェクト重視のPhotoshop的進化
    • CSSの限界を超えた表現力を追求

FigmaとSketchへのメッセージ

  • Figmaへの皮肉
    • 「もし採用してくれていたら、こんな投稿はなかった」
  • Sketchへの叱咤激励
    • 「パーティクルエフェクトやデボス、メッシュ変形、メタルシェーダーなど、もっと攻めろ」
    • 「Macネイティブの優位にあぐらをかくな」
  • 母親への謝罪
    • 「悪い言葉を使ってごめんなさい」

参考情報

  • @jonnyburch（Twitter）による類似のブログ投稿紹介

Hackerたちの意見

このデザインツールのスペースは、InVisionが閉鎖してデジタルホワイトボードに方向転換した時に、私にとってはもう終わったな。ほんとに難しい分野だよね。でも根本的な問題は、デザインシステムを長期的にうまく作るのが難しいってこと。特に、コードや使ってるコンポーネントライブラリと密接に絡んでるから、デザイナーはその部分には触れないし。Claude Designが再利用可能で見栄えのいいコンポーネントやレイアウトをデザインするための根本的なStorybookの問題を解決するとは思えないけど、Figmaや他のツールもそれを解決するとは思えない。解決策は何だろう？コンポーネントレベルでより深く修正する必要がある気がする。
└
もしアプローチが再利用可能じゃなくて、再構築可能だとしたらどうなる？私たちは、新しいデザインにプラグインできるコンポーネントを作るという考え方に縛られている。好きなコンポーネントができたら、その定義をマークダウンで作成するようツールに頼んでもいいんじゃない？後で、そのコンポーネントを再利用したい新しいデザインをする時に、ツールにマークダウンを読ませて、そのコンポーネントを使う時にそれを使うように指示すればいい。未来はもっと柔軟で面白くなると思う。
└
> クラウドデザインが再利用可能で見栄えのいいコンポーネントやレイアウトをデザインする根本的なストーリーブックの問題を解決するとは思えない。FWIW、クラウドコードは良いサンプルがあればそれを基にスキャフォールディングするのは得意だけど、今後は変更や抽出がほぼ「無料」になるから、そういうのは必要ないっていう意見もある。私はあまり納得してないけど、その意見は理解できる。
いい記事だね、最後の数段落で笑っちゃった！物事が別の何かに見せかけないで、正直にそのままの姿でいるって部分が好き。PenPot（https://penpot.app）がこの新しいエージェンシー時代にうまくやってるんじゃないかと思ったんだけど、彼らはデザインを実際のマークアップとして扱う方向に進んでるから、figのキャンバスアプローチとは違うし、彼らにとって興味があることなのかな。
└
PenpotのUI自体はSVGで作られてなかったっけ？それとも途中で変えたのかな？
ちょっと確認させて（私が50歳で、子供の頃から開発者だけど、CSSが全くできないって設定で）開発者、特にフロントエンド開発者が、ロゴやランディングページのアイデアをスケッチするだけじゃないデザイナーと話さなきゃいけないお店ってあるの？そのデザイナーはFigmaを使って、製品全体の「デザイン」を「スタイルデータベース」で管理してるってこと？で、そのデザイナーたちは開発者じゃないから、コードを変えずに見た目を調整できるはずってこと？それとも、普通はフロントエンド開発者だけがこのFigmaを扱ってるけど、コードとのギャップが嫌なんだろうか？
└
私が出会ったUXデザイナーたちは、主に製品全体の一貫性を確保する役割を担ってたよ（多くの開発者はスペーシングやフォントサイズに対してかなり無頓着だから）。時々、特に製品に新しい色を加える必要があるときに、新しいフローやレイアウトを提案してくれる。だからFigmaみたいなツールは、その点では便利だね。いろんなプロパティをいじるだけだから、反復が簡単なんだ（簡単なものから難しいものへ：ホワイトボード|紙にスケッチ、Balsamiqのようなワイヤーフレームツール、Figma|Sketch、CSSコード）。Figmaは直接フィードバックが得られるけど、コードはコンパイルが必要な場合もあるしね。
└
笑った。少なくともエージェンシーの世界では、ここ数年の一般的なアプローチは、デザイナーがFigmaでピクセルパーフェクトでコンポーネントベースの真実のソースを作成することだった（これも進化する！静的で完璧に納品されるわけじゃない）。これがクライアントが見るものでもあり、承認するものでもあるし、少なくとも彼らはFigmaデザインを取り入れたブランドデッキのスライドを見ることになる。とにかく、フロントエンドはFigmaからCSSに再実装するんだけど、通常は最良の近似（ピクセルパーフェクトじゃない）になる。なぜなら、Figmaが要素の「CSSをコピー」することを許可しても、それはほとんど使えないインラインCSSだから（親子関係やCSSで維持している変数、クラス階層などには気づいてないことが多いし）、測定単位も両者で必ずしも同じではないから。さらに、複数のフロントエンド開発者が独立してコンポーネントを再作成することが多くて（チーム作業として）、それがドリフトや異なる実装を引き起こすことがあって、面白いよね。で、技術スタックによっては、フロントエンドがStorybook [0]のような「フロントエンドの真実のソース」でこれらのコンポーネントを構築していることもあって、それがReactやNextJSアプリに直接注入されたり、時にはCMSのバックエンドコンポーネントに部分的または完全に再実装されたりすることもある（例：Sitefinity）。その後、人々はどれが真実のソースかを尋ねるけど、実際には「電話ゲーム」のような真実のソースの連鎖になっていて、典型的な「ブランドバイブル」には見えないんだ。さらに、メインプロジェクトの外にホストされたプロモーションランディングページのような、アウトオブボックスの将来のクライアントの取り組みが加わると、同じデザインの一部が全く異なるシステムで再実装されることになるかもしれない。[0] https://storybook.js.org
└
「コードを変えずに」というのはよくわからないけど、Figmaが製品に対して何か権威的なものを表しているという考え方は見たことがある。製品が自分自身のために権威的であるべきなのに。私も似たような経歴を持っているから、この見方にはアレルギー反応が出るんだ。
└
@kevinsyncの答えは100%正しいし、少なくともここ20年くらいはずっとこうだったよね。前は「フォトショップのファイルが（デザインの）真実を持っている」って言われてたけど、今はフィグマだ。でも、確かに「デザインからコードへのギャップ」は、デザイナーの意図が台無しにされるところで、フロントエンド開発者がデザインを見て「この文字列はもっとスペースが必要だ」とか、「コンポーネントに要素が多すぎたり少なすぎたりしたらどうする？」とか、「実際にどうスクロールするべきか」とか、「さまざまな画面サイズにどう反応するか」とかを考えなきゃいけないところだよね。この短いミーム動画は面白い/面白くないけど、あまりにも身近すぎて笑えない - https://www.youtube.com/shorts/r6JXc4zfWw4 - でも、確かに「デザイナーはコードを書かず、開発者はデザインをしない」って感じで、もちろん両方を上手くやる人もいるけど、そういう人はかなり珍しいよね。 :-)
└
そうだね、Figmaは大企業（と一部の小企業）でデザイナーがUIデザインを開発者に引き渡すための事実上の標準になってる。正直言って、あんまり良くないけど、前の選択肢よりはマシかな。でも、コードと直接連携して、視覚デザインをコードに翻訳する手間をほとんど自動化するツールには勝てないよね。Claude Designは試したことないけど、Figmaは楽しめないって感じてる（デザイナーってほどでもないし、GUIのページやオプションの山よりはコードの方が楽だな）。
└
大きな会社ではそうだね。エンジニアがスタイルの違いなく、同じ方法で実装することが求められるから。
Claude Designがデザイン周りのすべての複雑さを取り除くとは思えないな。Claudeを使ったバイブコーディングアプリはシンプルに見えるけど、実際はシンプルだからそう見えるだけ。特定のユースケースに合わせた非常に特化したUIコンポーネントを持つ巨大な製品スイートではないからね。「シンプルさ」は、自転車（バイブコーディングアプリ）と飛行機（Figmaのようなアプリ）の複雑さを混同しているから生まれる幻想なんだ。コードで同じデザインシステムコンポーネントを作るのとFigmaで作るのでは、コードの方が少し簡潔になるけど、Figmaのプリミティブにはコードのような条件分岐や制御フローがない。だけど、コードは画面に描くよりも柔軟性が低いし、クリエイティブな自由度を得るのが難しい。UIは、コードがFigmaほど柔軟でないと感じるギャップを埋めることができるけど、複雑さは人間が作り出す世界から来るもので、人間はどうやら4つの製品に対して8つのモードと2つのライト/ダークモードを作りたがっているみたい。Claudeで同じ設定をしたいなら、少しはメンテナンスが楽になるけど、あまり複雑さは減らないよ。
└
ほとんどの人は自転車か車が欲しいだけだよね。みんなが飛行機を必要としてるわけじゃない。これはフィグマにかなり影響するだろうな。
昨日、クラウドデザインでシンプルなロゴ（シンボルだけ）を作ってもらおうと1時間くらい頑張ったんだけど、全然うまくいかなかった。UIみたいな特定のことには良いと思うし、クラウドコードもそうだけど、このクラウドデザインはデモって感じがして、製品っていうよりはまだまだだなって思う。いつか良くなるといいな！
└
クラウドデザインは明らかに製品のUIデザインに特化してる。ロゴを作るための製品を目指してるわけじゃないんだよね。
└
アンスロピックには画像生成モデルはないよね？CSSや絵文字、もしかしたら自転車に乗ったペリカン（SVG）を使ったLLMがあるけど。
└
Claude Designはただの意見満載のプロンプトだよね。https://www.lobsterpack.com/blog/claude-design-trenchcoat/ それに、SVGを描くのがあまり得意じゃないって自覚してるから、無理にやらせない限りはやらないみたい。ロゴを作るなら、バニラのClaude Codeで別プロジェクトみたいに描いてみるのがいいよ。「デザインエージェンシー」に質問をしてもらって、それに答えて、描きたいものの詳細なブリーフを作って、何をどこに描くかの正確な計画を出力させて、最後にチャットボットに個々のコンポーネントを描かせるためのサブエージェントを使って実際に描かせるのがいいと思う。それに「ラスタにレンダリングして、ちゃんと見えるか確認する」ステップも追加してね。
└
QuiverのArrow SVGモデルを試してみて。あれはその手のことに特化して作られてるから、もっと良いはずだよ。
今日は、以前作ったデザインシステムをロゴやブランディング、フォントなどと一緒に見てみた。いろいろ調整して、やっと満足できるものができた。でも、使用状況を見たら、今週のクラウドデザインの使用量が95%に達してるって表示された！これは本物のツールじゃないよ。もしこれが提供されてる例なら、ただの遊び道具だね。
└
そうそう、あれは彼らのプレイグラウンドを基にしてるから、「遊び道具」って表現がぴったりだね。あれはその周りのラッパーみたいなもんだ。Claude Codeからのデザイン出力は確かに良くなってるけど、真剣なデザインの競合を置き換えるにはまだまだ時間がかかりそう。
└
一つのデザインシステムをちゃんと設定した後、すぐに使用量がなくなった経験があるよ。二つ目もかなり近いところまで行ったけど。でも、これはリサーチプレビューだから、きっと変わるよね。最初のデザインシステムで作ったものには結構満足してる。IPAASスタートアップのために新しいフッターセクションが欲しかったんだけど、四つのオプションを生成してくれて、その中の四つ目がかなり良かった。少し改良してからClaude Codeに取り込んで（その統合機能はめっちゃクール）、CCが作って、デプロイして、完了！興味があったら、https://tediware.com/の下の部分を見てみて。「Origin story」が左にあって、右にサインアップパネルがあるところだよ。特に複雑な構築ではなかったけど、彼が発展させたコンセプトが気に入ったし、すごく簡単に実現できた。UIのアイデアはすごくいいと思う。まだ粗いけど、これがどこに行くかは見えるし、ポテンシャルがめっちゃあるね。
└
これはリサーチプレビュー中だよ。制限が低いのはわざとだと思う。参考までに、アプリの異なるページのスクリーンショットを12枚渡したら、すごく良い感じに修正してくれた。週のクォータの40%しか消費しなかったけど、まだ高いね。ただ、これは人によるかもしれない。
└
> 今日は、ロゴやブランディング、フォントなどを含む、以前に作ったデザインシステムを見直すために使ったよ。この言語を使ってるってことは、たぶん普通の人よりも進んでるし、期待も高いんだろうね。義理の妹が小さなアパレル会社をやってるんだけど、彼女は過去6年間でかなりのスキルを身につけたけど、最初は本当に苦労してた。素晴らしいアイデアはあったけど、それを実際に適用するのが難しかった。彼女を助けるために何かあれば、絶対に試す価値があったと思う。
└
注意すべきこと: • Claude DesignはOpus 4.7を使っていて、以前のモデルより高価だよ。 • まだ2日目だから、完成品じゃない。Anthropicの進化の速さには驚かされるね。 • もしClaudeをしばらく使ってるなら、Designはもう君のスタイルや好みを把握してるよ。他のAIデザインツールを使うなら、最初からやり直しになる。長い目で見れば、それが良い結果を生むと思うよ。
└
10分で素晴らしい結果が出たんだけど、その後の使用制限がきつくて、今は1週間待たなきゃいけない。ZIPファイルのエクスポートはできたけど、ZIPの中身をStitch With Googleに入れてみたけど、あんまりうまくいかなかった。
└
Claude Designを使って、数週間取り組んできたデザインをどう出力するか見てみたんだ。十分なプロンプトと要件書を与えたら（ビジュアルは与えなかったけど）、出力はかなり良かったよ！スタイルには全然合わなかったけど、論理的なコンテンツのグルーピングやIAの決定をしてくれたから、自分の探索に取り入れることにした。全体的に良い印象を持ったよ。それからTwitterをスクロールしてたら、他の誰かが自分の「成功ストーリー」を投稿してて、そのデザインがClaude Designが作ったモックアップとほぼ同じだった。笑。均質化の問題は、AI生成のテキストやコード、画像が均質的なトーンや感触を持つのと同じように、こういうツールにもあるだろうね。
最近フィグマプロトコルを逆解析してた者として、> フィグマはエージェント時代に関連性を持たせるためのトレーニングデータから自らを除外してしまったって意見には完全に同意する。彼らのバイナリ形式は「すべてを再発明しよう」って感じで、ウェブデザイン、Androidアプリデザイン、iOSデザイン、何でもデザインできるツールだから、オールラウンドな存在になってしまったんだよね。それをウェブにマッピングするのは完璧な1:1の翻訳じゃないし、エージェントにとって役立つためには、フィグマを実装したUXの人は、ほとんどのフィグマデザインの意図を人間ですら正確に理解できないって知ってるから、LLMがどうやって理解するのかって話になる。UXの人でも答えられない質問の共通の例：1. このボタンは見栄えがいいけど、ドイツ語だとどうなるの？ 2. 実際、このボタンはCSSに入れると見栄えが悪くて、2行に折り返しちゃう。文字間隔でまた騙したの？ 3. iPhoneじゃない電話だとどう見えるの？ 4. CSSでグラデーションのボーダーはできないって知ってるから、何を入れればいいの？ 5. 4K画面だとどう見えるの？ 6. などなど。これらの質問のほとんどはプロップスやオートレイアウトで答えられるのはわかってるし、最近はこれらがあるフィグマで上記の5つの質問をしてみたけど、UXの人は「フィグマを正しく使う方法を知っている神話の生き物」ってわけじゃないから、HTMLの裏にあるツールが追いつくのが待ち遠しいよ。特にプロンプトがあればもっといいな。（開発者として、プロダクトマネージャーがUXの人に出したプロンプトを見たことがない）[0]https://github.com/allan-simon/figma-kiwi-protocol
これ、GoogleのStitchと比べてどうなの？Anthropicのとは違って、Googleの太っ腹のおかげで無料だよね。 https://stitch.withgoogle.com/
└
わあ、これはかなり悪い結果を生んだね（アプリ）。Claude Designの方がずっと役立つけど、どちらも20分くらいしか使ってないんだ。
昨日Claude Designを試してみたんだけど、今作ってるアプリのUIを入力して、すでに作ったものも見せたんだ。6つの新しい「レイアウトスキン」を異なる色やアイコン、ボタンの配置、雰囲気を使ってモックアップしてもらったら、6つの良いデザインが高解像度の画像とClaude Codeの指示、ZIPファイル付きで出てきたよ。使用制限には引っかからなかったし、約1時間かかった。全体的にすごく良かったし、プロセスや思考の構造、質問の仕方も気に入った。
ここ数年デザインツールに関わってきたけど、この記事はデザインの領域とFigmaという会社について根本的に誤解してると思う。いくつかの考えを挙げると: - Figmaは常に成功した製品よりも成功した会社を作ることを重視してた。Figmaはもっと野心的な目標から始まって、Evan Wallaceのような才能を通じて実現できたんだ。多くはブラウザでのwebglの能力を示すことから始まった。でも、3D機能みたいなものは存在しないのは、会社全体が高い席代を持つことを考慮して、特定の収益を上げるものに集中する意識があったから。 - 本当に、Figmaはデザインツールが二の次で、ビジネスが使う製品を最優先にしてる会社だよ。その点で、IPOを通じてすでに成功してるし、その後の市場がどうなるかは誰にもわからない。Figmaが戦争のための資金を持っているのは、技術的に印象的なデモが消えてしまうよりもはるかに良い。 - Figmaの人たちは、この記事の内容を100%理解してるよ。Figmaの人だけじゃなくて、デザインツールを作ろうとした人はみんなこういう考えを持ってる。UI/UXはデザイン、開発、PMの交差点にあるのは明らかだし、真実の源、つまりコードに近づくべきだとも明らかだ。 - 問題は、これらのアイデアを実行するのが非常に大きな課題であることを過小評価していることで、デザインツールだけでなく、コーディングやデータ管理、アーキテクチャなどのツールを作ることにすぐに流れ込んでしまうから。 - 課題や潜在的な解決策について長々と話せるけど、それは今は関係ないね。 - AIについては、他の人の予想も私のと同じくらいだと思うけど、私の直感ではデータは重要だけど、最先端のAIは一般的すぎて、基本モデルや彼らができる思考は、たくさんのカスタムデータを持つよりも優れていると思う。特にUIデザインは対面しているから、プライベートな財務文書や法的文書とは対照的に、ウェブをスカウティングするだけで済む。