
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. 新しい開発・デザインワークフロー
実際の現場における具体的な工程は以下の通りです。
- 課題と提案の定義: 問題提起と内容を示すテキストを作成。
- 環境構築: エディタを開き、ビルドサーバーと Claude を起動。作成した記述をプロンプトとして入力。
- 可行性確認: プロトタイプの基本機能を実装し、「実装可能である」ことを自らに証明する。
- 反復改良: 望むだけ詳細を微調整してiterate(反復)する。
- 外部連携: コード変更を環境へプッシュし、ユーザーのフィードバックを収集。
- 提出: 目指す見た目と挙動を達成した状態でプルリクエスト相当として提出。
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 が執筆しました。