- 仕様書作成やFigmaモックアップの代わりに、頭の中のアイデアをそのまま動くプロトタイプ機能として直接作るデザインワークフローへ移行
- 以前はCopilot、Cursor、GeminiなどのLLMに懐疑的だったが、Jane Streetに加わってからAI支援が不可欠だと実感
- Claudeは無料・無制限の反復を許してくれるため、50回変更しても文句ひとつ言わず、Submitボタン・ショートカット・文言修正など細かな改善を可能にした
- デザイナーもエンジニアのように**動く概念実証（POC）**を自分で作り、他の人が実際に使って評価できるようにする
- 実際の成果物そのものにすべての労力を集中し、中間段階の付随作業を取り除く新しい協業モデルにつながっている
LLMへの懐疑からの転換
- 長いあいだLLMに懐疑的で、使うたびに結果に失望していた
- 昨年、自分で作ったゲームを修正するためにCopilotとCursorを試したが、どちらも動く変更を生成できなかった
- 前職ではGeminiでプロダクトブリーフの概要やワイヤーフレームを作ったが、どれも破棄した
- LLMを試した領域はどれも自分がすでに得意な仕事で、自分でやるより結果が悪かった
- 昨年の夏にJane Streetへ加わってから、AI支援が不可欠だと実感した
- OCamlやBonsaiなど、新しくてまだ不慣れな領域が多かったため
- 最も驚いたのは、自分が最も得意としていたデザインワークフローそのものが変わったことだった
プロトタイプ中心のワークフロー
- 仕様書、Figmaモックアップ、提案書作成、開発者との実装レビューの代わりに、意図した機能をそのまま果たすプロトタイプ機能を自分で構築する
-
実際の作業フロー
- 問題と提案を文章で書く
- エディタを開き、ビルド・サーバー・Claudeを起動し、書いた説明をプロンプトとして使う
- 可能性を証明するため、まず基本機能を動かす
- 望むだけ反復する
- 変更を開発環境にプッシュしてユーザーの意見を集める
- 意図した見た目と挙動を備えたfeature（この会社でのpull requestに相当）を提出する
- 実際のコードベース内にあるプロトタイプは、モックアップや文書よりほぼあらゆる面で優れていた
JSQL入力プロトタイプの事例
- 最近、JSQL入力にLLMプロンプティングを追加するプロトタイプを作成した
- JSQLはさまざまなユーザー向けツールで使われている社内SQL方言
- 実際に動作し、数日間使ってテストしながら付き合った
- Claudeは無料・無制限の反復を許してくれるので、50回目に気が変わったり小さな修正を頼んだりしても気にしない
- Submitボタンの調整、キーボードショートカットの追加、文言修正、プロンプト調整、生成的な確認メッセージの追加
- 前職であれば数日から数週間のエンジニアリングとデザインの往復が必要だったか、そもそも実現しなかった改善だった
- すべての労力が実際の成果物の改善に注がれ、Figmaコンポーネント作成や文書整形のような付随作業には費やされない
ワークフローが定着するまで
- このやり方にたどり着くまでには時間がかかった
- 参加当初はUXの細かな不具合修正のような小規模作業にしかAIを使っていなかった
- より大きなアイデアには依然としてFigmaや文書を使っており、Claudeで試しても失敗していた
- ここ2か月でFigmaに手を伸ばす場面は激減した
- モデル改善、自分の習熟、適切なスコープ選びが組み合わさり、大きな作業でもAIが機能するようになった
- JSQLプロンプト以外にも、ユーザー向け・データモデル・ライブラリ変更を扱うプロトタイプを多数作成し、その一部は2000行以上のdiffになった
- Figmaで設計してからインタラクティブなプロトタイプを実装することもあれば、一部の新規アプリではFigmaを完全に飛ばし、最初からClaudeでビジュアルデザインを反復することもある
デザイナーにもたらす力
- エンジニアはアイデアが浮かべば動く概念実証を自分で作れるが、デザイナーは他人を説得しなければならない
- 「JSQL入力内での直接LLMプロンプティング」のようなアイデアは、開始時点では実現可能性すら不明で、誰かにプロトタイプを頼めば時間の無駄になる可能性がある
- ユーザーニーズを明確に満たさない提案かもしれない
- Claudeでアイデアを実際に実装すると、他の人が直接使って評価するのがはるかに容易になる
レビュー方式の課題
- 欠点は、レビュアーが完成した機能を受け取ることになる点
- 機能に対する入力権なしにコードだけをレビューすることになるのでは、という疑問
- デザインの文脈で、PMが作った詳細なワイヤーフレームを渡されて「見栄えよくするだけでいい」と言われるのに似ている
- 提案はできるだけ明確かつ完全にしつつ、エンジニアの同僚にもFigmaモックアップのように一緒にデザイン領域で反復してほしい
-
現在の解決策
- featureの見方を変え、説明に短い案内を書く
- プロトタイプは生きた提案書であり、コードは使い捨て、レビュアーの役割はデザインとユーザー体験に関するフィードバックを出すこと
- 最終的にはレビュアーがアイデアを引き継ぎ、別のfeatureで実装し、プロトタイプを参照しつつプロダクションコードを自ら所有する
- 何が妥当で、何がしっくりくるのかはまだ模索中
懸念と見慣れた緊張感
- Claudeでデザインすると、柔軟で創造的な思考から離れ、Claudeが作れると思い込んだ結果に閉じこもる反復的思考にとどまってしまうのではないかという不安がある
- 変化が漸進的な成熟ツールには問題ないが、新しいものを扱うときにはアイデアを取りこぼすかもしれない
- これは見慣れた緊張関係であり、2011年の「デザイナーはコードを書くべきか」という議論につながる
- 批判者たちは、プログラミングを始めるとアイデアに大きな変化を加えにくくなると主張していた
- しかしWebサイト制作とプログラミングの両方が好きで、書き続けてきた
- Reactのようなフロントエンドフレームワークが一般化し、開発が複雑化するにつれて専門化を選んだ
- 個人プロジェクトは今でもReactで作っており、開発者とのコミュニケーションに役立っている
- 業務時間の大半はFigmaと文書に費やしていた
- LLM以前にJane Streetへ加わっていたなら、Figmaにさらに深く埋没していただろう
- JavaScriptにはある程度経験があるが、OCamlとBonsaiは完全に新しく、技術的な貢献は手の届かないものに感じられただろう
- その代わりに実際の成果物を再び作るようになり、その媒体に戻ってこられたことをすばらしく感じ、何でも試せる自由をより強く実感している
1件のコメント
Hacker Newsのコメント
ビジネス側はすでに要件を自分たちで考えた解決策の形で持ってくることが多く、たいていはルーブ・ゴールドバーグ装置のような代物なので、対話を通じてリバースエンジニアリングしないと本当の要件にたどり着けない
今後は、すでに「準備できていて」「動く」解決策を持ってきて、設計やアーキテクチャを全体として見直そうという話にはさらに乗り気でなくなりそう
「こう作ればいいだけじゃないか。ほとんどできてるのに、なんでX人日も必要なんだ？」となりそう
欠点は、ビジネス側がそのアプリをそのまま本番デプロイしてはいけない理由を理解しないこと
「AIなら速く進められるだろ」という圧力が強まり、結局は健全な組織力学にかかってくる話になりそう
利点は、ナプキンスケッチよりもアイデアがずっと徹底的に検証されている点
Claudeはすでに境界ケースや設計上の判断について質問していたはずで、どこかの時点で「それは気にしなくていい、そう仮定して」や「何度か使ってみたけどこのインタラクションはよくないので変えて」と明示していた可能性が高い
今は「何が問題なんだ、そのままデプロイしろ」という圧力が強く、愚かで士気をくじくので純損失に近いが、安定してくれば将来のプロジェクトでは純利益になるかもしれない
その細かな修正というのが、ブラウザ幅がちょうど1920pxでないとレイアウトが崩れる問題、フィルタやソートがたまに正しく動かない問題、ある操作のあと新しい値がアプリに正しく反映されない問題だったりする
問題の大きさに関係なく、ビジネス側は自分たちでもう95%はやったと思っているので、「熟練開発者ならすぐ直せるはずだ」と最初から見積もっている
人は自分の手元の成果物に慣れてしまい、新しいプロのミックスで変わる部分を受け入れにくくなる
顧客の問題を使い勝手のよい製品機能へ翻訳する感覚を持つPM、CSM、TAMもいるが、問題定義を飛ばして別の機能組織に解決策を作らせると、たいていはエンジニアリングや他のリソースを大きく浪費する惨事になる
誰かが解決策を持ち込むと、数か月かけて運用可能なソフトウェアを作ったあとで、顧客がそれを嫌い、問題を解決していないか、新しい問題を生んでいると判明するリスクが高い
今の職場ではなく前にいた会社だが、データ損失やセキュリティ問題を抱えたまま本番デプロイまでされた
Jane StreetがAnthropicの投資家だと認識しているので、その点は割り引いて考える必要がある
2025年7月には、インド証券取引委員会SEBIがJane Streetについて、複数の法人を使って市場操作を行ったと主張し、市場アクセスを禁止したという点もある
巨大な金の流れにはダッシュボードが大量に必要なのだろう
ここではデザイナーが間違ったアプローチをしているようで、プロトタイプをできるだけ深く現実的に作り込みたいというエンジニア志向への憧れに陥っているように見える
でもそれはデザイン業務で最も重要な部分ではない
最も重要なのは、正しいものが作られること
「なぜJSQL入力ボックスが必要なのか？ 本当に欲しいものは何か？ 別のやり方は何か？」といった問いは、ペンと紙のスケッチ、会議、観察、議論で解くほうがうまくいくことが多い
特定のデザインにあまりに早く絞り込み、ボタンが左か右か、LLMの細かな挙動がどうかといった議論に入るよりよい
もちろん、まさにそう考えてほしいと思っているのかもしれないが
たまにこれを感じる
LLMは現状、反復の先を見ることができないので、私が枠の外で考えて「この観点から見たらどうだろう？」とやらないと、突然新しい設計のやり方は出てこない
ときには、LLMに自分の進行段階の先を見せるためにフローチャートを作る必要がある
「Claudeは、私が50回目の気変わりや細かな修正を頼んでも気にしない、無料で無制限の反復をくれた」という話だが、Claudeの費用を払っていないのか？
小規模なデザインスタジオも似たようなもので、開発者のような時間課金ではないことが多い
正直に、私は本当にデザインが苦手で、デザインシステムを外挿するのにも問題があると答えた
まともに見えるところまで持っていくのがあまりに難しく、その過程でほとんどいつもかえって悪くしてしまう
面接していたデザイナーはそれを個人的に受け取り、私を問い詰めてきた
以前にも似たことがあった
デザイナーたちはどう見えるべきかについて絶えず質問されるのを嫌い、一度渡したら終わりという引き渡しを望んでいた
マーケティング・広告代理店でも、デザイン仕様にないものがどう見えるべきか、サンプルを出してくれと何度も争わなければならなかった
私が正しかったと言いたいわけではないが、私にとっては大きなアキレス腱だ
だから「無料、無制限の反復、気にしない」と聞くと、お金より先に時間と忍耐が思い浮かぶ
私がプロトタイピングに使うBoltは怒らない
最高のデザインを作るわけではなくても、私にできるものよりはるかによく、終わったら本物のデザイナーにもっと良くしてもらえばいい
それまでは、誰かを怒らせる心配をしなくて済む
フロントエンドで Claude Design を使ってきた。
仕上がりの見た目や雰囲気は十分よいが、デザインがしばしば似通って見え、だいたい現代的なウェブのありふれたパターンに従う。
これで非定型な創造的試みをした人がいるのか気になる。
ここまでで約3週間かけていて、まだ未完成だが雰囲気は伝わるはず。
過去10年間に SaaS ボイラープレートがあったように、インターネットで学習されたLLM ボイラープレートもある。
それでも十分に手を入れれば、まだ何でも可能。
要件を与えれば合わせてくる点と、方向性を与えないと無難な選択をする点が面白い。
出力の美学やユーザー体験・コンテンツを評価するつもりなのに、美学面のプロンプトをほとんど与えなければ、無難なデフォルトしか返ってこない。
bootstrap/tailwind のコピーっぽいデザインはうまく作るが、その部分は意識的に押し込む必要がある。
単純なウェブページでは、初期の反復の唯一の焦点を視覚スタイルに置き始めた。
標準的に見えないよう具体的に指示して、望むウェブサイトのスタイル例を渡せばよい。
少し格闘すればやや創造的に感じられるようになるが、プロンプト作業は必要。
とても尊敬され経験豊富なデザイナーたちに勧められたが、彼らは今ではほぼ全面的に Claude でプロトタイプを作り、気に入ったら Figma で整えている。
そもそも詳細なスタイルのプロンプトなしに一般的な UI を求めれば、一般的なデザインが出てくるのは当然。
ここでの利点は、デザイナーがコーディングを学ぶこと。
ソフトウェアがどう作られるかを知らないままデザイナーがソフトウェアを形作るというのは、ずっと奇妙だと思っていた。
ちなみに自分もデザイナー。
ただし、コードでデザインするのは技術優先のアプローチだ。
デザインの目的が人間の目的に合わせて成果物を形作ることだとすれば、コードの厳格な規則から始めないほうがよいとも言える。
見栄えのよい成果物のためではなく、思考を前に進めるという点では、いまだにペンと紙に勝つのは難しい。
今では実質的に声でコーディングできるようになり、再びバイブコーディングとプロダクト作りに戻っていて、本当に楽しい。
上司はこの新しい状況をまだ把握中だが、古い役割分担は死に始めている気がする。
交差点にいるのが今は一番いい立ち位置だと思う。
自分の人生全体がこの瞬間の準備だったように感じる。
デザイナーにとっては、結果を見てビジュアルエディタの代わりに言葉で修正する Figma に近いだろう。
うちの妻は FAANG でプロダクトマネージャーをしているが、チームは本来 Word や Excel のようなものでやっていたはずのソフトウェア断片を、AI でバイブコーディングすることに極度に依存している。
彼らはコーディングを学ばず、コードを1秒たりとも見ない。
「プロトタイプは生きた提案書であり、コードは捨ててよく、レビュアーの仕事は設計とユーザー体験にフィードバックを与えることだ。
最終的にレビュアーがアイデアを引き継いで別機能として実装し、プロトタイプは参考にしつつ、本番コードは自分で所有する」というアプローチは、自分があらゆる POC で経験していた問題を解決してくれる。
本当に良いやり方。
特定の製品の特定の課題を扱うときは「提案書」と呼びやすい。
だが今でも無数のデザイナーが Figma を使って、製品とプラットフォーム全体にまたがるデザインシステムを定義・維持しており、その場合 Figma が真実の源泉だ。
うちのチームもこうしていて、自分はフロントエンドエンジニアだが、正直以前のやり方が本当に恋しい。
書かれた仕様が動くプロトタイプに置き換わったことで、今ではコードを読んで意図された変更が何で、捨てるべきノイズが何かを判断しなければならない追加の認知負荷が生じている。
生成された PR を受け取って必要な変更をするか、最初から作り直すかを決めなければならず、どちらにしても摩擦がある。
意図しない変更が大量に生成されたこともあり、自分が再実装に時間をかけて移し替えたあとで、「あっ、すみません、それは変えるつもりじゃなかったんです」となることもあった。
権限を与えるという点は理解するが、以前の仕事で感じていた楽しさの一部を奪い、厄介ごとに変えてしまっている。
デザインとプロダクト側が Claude で機能や体験をバイブ設計・コーディングして、素早くプロトタイプを作り、最小限のエンジニアリング時間で顧客の前に持っていってフィードバックを得る。
すばらしい。
だが全体として、より速く出荷する助けにはあまりなっていないという点は意外かもしれない。
理由は、その過程で思考を失ったからだと思う。
かなりの思考がいまや言語モデルに外注されている。
プロンプトの隙間を塗りつぶし、明示されていない動作を幻覚で埋めてしまう。
以前なら「これはあまり合っていない」「このアイデアをどう伝えよう」「このケースではどうなる？」と立ち止まっていたはずのものが消え、今ではそうした細部はちゃんと作ったあとへ先送りされる。
もちろんプロセスを改善し、この新しい手法をもっとうまく使う方法を振り返ることはできるが、以前よりよいかと言われると微妙。
廃れていく。
今ではバックエンドの人たちもフロントエンドをやる。
そこが思い違いだ。
コンパイラが生成したアセンブリをのぞき込むか？ 見ない。
ではなぜこのコードを見ているのか？
私たちは抽象化レイヤーを上へ持ち上げたのだ。
私も同じアプローチをよく使う
AI以前から手作業でこうしていた
まずユーザーと一緒にペンと紙だけを持って座り、その次にフロントエンドのPOCやデモを素早く作り、ユーザーに触ってもらって、望む通りに動くまで調整していた
私にとっては、本番品質ではない高速なフロントエンドのデモをコードで作るほうが、Figmaで正確なインタラクションを作るより、すでに速いことが多かった
完全なインタラクションが可能なので、ユーザー体験におけるエッジケースをはるかに多く拾えた
今ではClaude Codeのおかげで捨てる前提のプロトタイプを作る速度がさらに上がったが、とてつもない差というほどではない
ユーザーと議論し、どう動くべきかを考える時間が全体の80%なので、Claudeは自分で素早く作る場合と比べて、残り20%を半分にしてくれる程度だ
最初のバージョンは速くなるが、完全に理解できていないときの反復はむしろ遅くなる
Edwin、投稿が上がっているのを見てうれしい
2012/2013年ごろに一緒にハッカソンをやった記憶がある
動くプロトタイプまでより早く到達できる力は、未完成のアイデアをそのままリリースしたくなる誘惑があるとしても、非常に大きな後押しになる
デザインやユーザー体験の要件は、ストーリーボードやワイヤーフレームを超えて、実際のフローを触って体験できるときに大きな恩恵を受ける