今はFigmaよりもClaudeを使ってデザインしています

2026/06/07 14:04

今はFigmaよりもClaudeを使ってデザインしています

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

Jane Street に勤務するデザイナー、エドウィンは、AI ツール(Claude など)に対する姿勢を懐疑から重度の依存へと転換させ、OCaml と Bonsai の学習ならびに設計ワークフローの革命においてこれらを手放せない道具として捉えています。以前は静的な仕様書や Figma モックアップで苦戦していた彼ですが、現在は LLM を活用してコード内で機能的プロトタイプを直接構築し(例:複雑な JSQL 入力)、実現可能性を確認しながら迅速に反復しています。このアプローチにより、ボタン、コピー機能、ショートカットなどの機能改良において、前職で見られたような典型的なエンジニアリング/設計双方の往復を必要とせずに行うことができます。過去数ヶ月を通じて、Figma を必要とする状況は大幅に減少し、新しいアプリに対して Figma を全く使用せずに済むようになっています。AI は大規模なコード変更量(2,000 行以上)を処理し、即座にユーザー評価用のインタラクティブなプロトタイプを生成する役割を担っています。トレードオフとして、レビュー担当者はプルリクエストで実装された機能をそのまま受け取るため、編集可能なモックアップではなく、その結果として設計空間における反復検討の可能性が制限されます。したがって、エドウィンはこれらのアートを「生きた、使い捨て」の文書として位置づけ、フィードバックは実装上の前に行う UX に焦点を当てています。批判者たちがこの方法を意図的にデザイナーに制約された反復的思考を保持させると懸念する一方で、エドウィン自身はコードベースに対する相対的な新しさにも関わらず以前よりも自由で、新しいことを試すことが可能になり、エンジニアとデザイナーの間における歴史的な緊張関係を、AI に駆動された簡素化された創造プロセスへと変革しています。

本文

LLM によるデザインワークフローの変革:Jane Street デザイナーの実践報告

1. 懐疑から実用への転換

長らく大規模言語モデル(LLM)には懐疑的でしたが、最近では不可欠なツールとなっています。

過去の失敗体験

  • ゲームの微調整: Copilot や Cursor を使用したが、実行可能なコード変更が生成されなかった。
  • 製品ブレブの概要書・ワイヤフレーム: Gemini を使用した試みはすべて廃棄された。
  • パフォーマンス比較: LLM が得意とする領域であっても、個人の能力の方が上回るケースが多かった。

変化のポイント

  • 今年夏の加入後: AI サポートが必須となった。
  • 最大の驚き: 「デザインワークフロー」の変容。
    • 仕様書作成、Figma マークアップ構築、提案書執筆など従来の苦役から解放された。
    • **「exact な機能を持つプロトタイプ」**を直接実装するスタイルへ移行した。

2. 新しい開発・デザインワークフロー

実際の現場における具体的な工程は以下の通りです。

  1. 課題と提案の定義: 問題提起と内容を示すテキストを作成。
  2. 環境構築: エディタを開き、ビルドサーバーと Claude を起動。作成した記述をプロンプトとして入力。
  3. 可行性確認: プロトタイプの基本機能を実装し、「実装可能である」ことを自らに証明する。
  4. 反復改良: 望むだけ詳細を微調整してiterate(反復)する。
  5. 外部連携: コード変更を環境へプッシュし、ユーザーのフィードバックを収集。
  6. 提出: 目指す見た目と挙動を達成した状態でプルリクエスト相当として提出。

3. プロトタイプ作成の実例:JSQL プロンプティング

内部 SQL 弁言語である JSQL への LLM プロンプティング機能を例に取ります。

開発プロセス

  • 期間: 数日間をかけてテストと実装を行った。
  • 対応力: Claude は思考の切り替えや、無料・無制限な反復に対応した。
  • 微調整事例:
    • Submit ボタンのデザイン洗練
    • キーボードショートカット追加
    • 説明文の調整
    • プロンプトの改行
    • 自動生成の確認メッセージ追加

効果比較

パターン従来の職場(エンジニア×デザイン)新しいワークフロー(LLM アシスタント)
所要時間数日〜数週間、または実現しないことも多く即座に実装可能
リソースマークアップや仕様書の二次的な作業に労力が分散すべての労力をアーティファクト改善へ集中

4. ワークフローの進化と拡大

導入段階(昨年の夏)

  • 利用範囲: UX のような小規模な問題解決のみ。
  • 大規模プロジェクト: Figma や仕様書に依存しており、Claude による制作は失敗が頻発した。

現在の状態(過去 2 ヶ月間)

  • Figma 依存の減少: 手を入れる状況が急激に減った。
  • 成功要因: モデル性能向上 × 自身の習熟度向上 × 適切な範囲選択。
  • 達成事例:
    • 十数もの大規模プロトタイプを生成(ユーザー向け、データモデル、ライブラリ変更など)。
    • コード差分が 2,000 行以上となるケースも存在する。

Figma をスキップしたアプローチ

  • 新規アプリでも「デザイン→実装」ではなく、Claude でインタラクティブプロトタイプを実装
  • ビジュアルデザイン自体を Claude と共にゼロから反復改良していく場合も増えている。

5. デザイナーとしてのメリット:Empowering

エンジニアはアイデアがあれば概念証明(POC)を作成できるが、デザイナーは他者に説得する必要があります。

LLM 活用による変化

  • 実現可能性の可視化: 「JSQL 入力への直接プロンプティング」など未確認なアイデアでも、迅速に検証可能。
    • 時間を無駄にするリスクを大幅に低減。
  • ユーザーニーズの具体化: 明確でない提案も AI によって実像化しやすくなった。
  • 評価の促進: 「実際に動くもの」を見せることで、他者が評価しやすく、「使いやすさ」を即座に伝達できる。

6. 課題と解決策:コードレビューの見直し

現状のジレンマ

  • レビュアーへは完成した機能が渡される(機能内容への介入ゼロ)。
  • レビュー担当者の任務は「デザイン・UX に関するフィードバック」に限られ、コーディング自体は求めていない。
  • これは、「詳細なワイヤフレームを受け取って美しさを高める」という PM の役割に近い状況で、レビュー作業が最も嫌われることになっている。

解決策:視点の転換

記述欄には以下のリマインダーを記載する。

プロトタイプは生きている提案ドキュメント。コードは使い捨てのものとする。レビュアーの任務は、デザインとユーザー体験に関するフィードバックを与えること。」

  • 最終的にはレビュー担当者がアイデアを引き継ぎ、別機能として生産コードを実装する。
  • エンジニアチームが「Figma マークアップのように共同で反復改良」できる状態を目指しているが、最適解の調整は現在進行中である。

新たな懸念:創造性の低下

  • LLM と共に作業することで、流動的・創造的なマインドセットから離れ、「Claude が生成できる結果に制約された反復的マインドセット」へ陥る可能性がある。
  • 対策: 成熟したツールでは問題ないが、新規分野のプロジェクトでは重要なアイデアを見失うリスクがあるため注意が必要。

7. 結論:自由への回帰

キャリア経緯との比較

  • 2011 年からのキャリアで長らく「デザイナーがコーディングすべきか」議論があり、専門化(Figma 中心)を選択していた。
  • もし LLM が存在していなかったら: OCaml や Bonsai の技術的障壁から諦め、さらに Figma への没入が深かった可能性が高い。

現在の実感

  • JavaScript に限らず、OCaml や Bonsai で実物を制作する機会が戻った。
  • 再びメディアの中で作業しているのは驚くほど素晴らしい。
  • かつてないほどの自由でアイデアを試せる状態にある。

この記事は、Jane Street のオプションデスク所属デザイナーである Edwin が執筆しました。

同じ日のほかのニュース

一覧に戻る →

2026/06/08 4:01

Linear がなぜこれほど速いのか?技術的な解説

## Japanese Translation: # リニア革命:ウェブアプリケーションのパフォーマンス革新 リニアは、データベースをブラウザ内に完全に実行する(IndexedDB を使用)ことで、従来の CRUD アプリのデータ読み込み時間である約 300ms を数ミリ秒に短縮します。この「ローカルファースト」アーキテクチャでは、標準的なネットワークループが逆転し、デバイス上で変更を即時適用し、WebSocket を経由で非同期でデルタをプッシュすることで、アップデート待ちの地味な网络待ち時間を排除します。共同創設者のトゥオマス・カンカレは、この自社工程エンジンをゼロから構築することを強く推奨しました。タンスタッククエリや SWR などの一般的な楽観的な更新ライブラリを使用せず、サーバーを単なる同期ターゲットとして厳密に扱うアプローチを採用しています。JavaScript のサイズを最小限に抑えるため(圧縮後の JS は約 21MB にまで削減され、ルートレベルのチャンクに分けられている)、チームはバンドルパイプラインを 4 回も移行しました(Parcel → Rollup → Vite → Rolldown)。これにより、配送されるコード量は約 50% 削減されました。重要資産には、フォント(単一の可変 Inter ファイル)、数百のルートチャンクが含まれており、サービスワーカーと `<head/>` に設定された並行モジュールプレロードリンクを通じて事前キャッシュされます。これにより、オフライン時や繰り返し訪問時でも即座にレンダリングが可能になります。さらに、重要な CSS、JavaScript、認証ロジックは HTML に直接埋め込まれており、認証にはセッショントークンの即時取得ではなく、ローカルストレージ内の存在を確認する方式を採用しています。该系统は、50 件のイシューリストが変更された場合、わずか 50 セルだけを更新するなどの粒度の細かなリレンダを達成します。これは、データをプロパティごとの MobX オブザーバブルに水浸げすることで実現されており、標準的なフレームワークでは追いつけない優れた速度優位性を保証しています。

2026/06/08 3:33

依存症、逮捕、犯罪歴からの再起:ゼロから立ち直すまで

## Japanese Translation: 最も重要な示唆は、技術分野における採用決定において過去の過ちよりも将来の可能性を優先させるべきであるという点です。堅い身元調査は無視できない課題を乗り越えた有能な個人が不当に排除されるためです。著者は自らの驚異的なキャリア回復の実例によってこの主張を具体化しています:未成年の逮捕歴(監禁中に最大保安施設で Schedule II 指定薬物への所有および製造・頒布意図に関する 17 の起訴を含む)から、現代の技術産業における高位な技術職に就くまでです。当初、企業の「前科者なし」という採用ポリシーにより 8 社のオファーが撤回されましたが、彼は後に、ワークリリースインターンシップ期間中やハスラ(現在は PromptQL)で創設者から felony conviction の開示を受け入れた際に再雇用されるなど、採用管理者が大きなリスクを冒して彼を採用したことで成功を果たしました。彼の journey はまた、試行錯誤を通じて学んだ特定の教訓も強調しています:Techtonic での不当な解雇とその後 Slack の履歴を調べて正当化されたことや、Hasura などのコミュニティ主導のツールの発見とその仕事が不可欠になったことなどです。この個人的な物語は、犯罪記録を超えて才能が存在し、支援的なリーダーシップが人生を変えうることを説得力のある証拠として提供します。これからの未来において、業界リーダーは候補者の履歴に基づいて自動的に不合格にするのではなく、実証されたスキルを評価するよりニュアンスのある採用慣行を採用すべきです。功績基準による評価システムへとシフトすることで、技術セクターは見逃された膨大な talent の蓄水池を活用できるほか、更生と労働市場への再統合を積極的に支援し、より包摂的な環境を構築できます。

2026/06/08 3:54

LLM が人間のような属性を持つなら、同じく「エイジ オブ エンパイア2」もそうだ

## Japanese Translation: 本文書(arXiv:2605.31514)は、Adrian de Wynter 氏によるものであり、大規模言語モデル(LLM)に独自の人間のような(擬人化された)特性を帰属させることは欠陥のある仮定であると論じます。その理由は、そのような特性は「Age of Empires II」といったリアルタイム戦略ゲームでトレーニングされたニューラルネットワークを含む、あらゆる十分に複雑なシステムにおいて現れる可能性があるためです。著者は「Age of Empires II」が機能的かつチューリング完全であることを認めつつも、レゴの組み立てやグレート・ボストン地域など他のエンティティを、同様の擬人化的特性を示し得る強力なサブストレートの例として挙げています。基本的な証拠は、根本的な応答特性は一定のままでも、観測される行動の解釈はサブストレートによって変化する可能性があることを示しています。擬人化された属性が存在するかどうかを、サブストレートに依存せずに仮定することは循環的な結論や情報不足の結論につながります。著者は「null(零)」という仮説を提唱しており、明示的な測定がそれを否定するまで、LLM をこれらの特性において非特異であると扱うよう提案しています。この転換は、技術業界に対して、ニューラルネットワークだけでなく他のシステムにも人間のような性質を見出さないよう警戒することを促します。これを裏付けるために、本稿では分野の概要調査、潜在的な異議への言及、そして「null」仮説を適用する具体例について論じています。本研究は、オープンネスとユーザーデータのプライバシーを重視する arXivLabs の取り組みの一部です。