ハクソク

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

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

2026年4月19日原文(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のページやオプションの山よりはコードの方が楽だな）。

└

大きな会社ではそうだね。エンジニアがスタイルの違いなく、同じ方法で実装することが求められるから。

Hacker Newsで議論の続きを見る