なぜ共有するかWhy I’m sharing this
つくる人が、そのまま動かす人でもある。
Config のサイドイベントで見たのは、まさにそういう現場でした。The person who makes it is also the one who ships it—
that was the scene I saw at a Config side event.
Cursor のデザイナーが、コードをほとんど書かずに、Cursor 自身のオンボーディングを組み立てていく。仕上がった手法の披露ではなく、途中で止まって、直して、また進む。その"作りかけ"のままの実演が、いまの私たちにいちばん近いと感じました。A Cursor designer building Cursor’s own onboarding — with barely any code. Not a polished technique on display, but the real thing: it stalls, gets fixed, keeps going. That “work-in-progress” quality is what felt closest to where we are right now.
持ち帰りたい問いは、3つ。
デザイナーは、動くものまでどこまで担えるのか。
作り込んだカンプを渡す前提は、まだ必要なのか。
そして、うまくいった依頼の仕方を、どう残していくのか。Three questions I want to bring back.
How much can a designer own?
Do we still need to hand off polished comps?
And how do we keep the “ways of asking” that worked?
特に印象に残った3つThree things that landed
デザイナーが、フロー全体を「持てる」A designer can own the whole flow
題材は、Cursor 自身のオンボーディング。
彼はそれを「Baby Glass」と呼ぶ Cursor の開発中ビルド(社内版)の中でつくっていきます。機能はすべて出し分けのスイッチ(feature flag)になっていて、試したい案があればコードを書かずに左のメニューへ項目を一つ足すだけでよい。だから、デザイン案がそのまま切り替え可能な機能として本番同然に並ぶ。つまりデザイナーが、案を機能として自分で持てるのです。The subject was Cursor’s own onboarding.
He builds it inside “Baby Glass,” an internal working build of Cursor. Every feature is a toggle — a feature flag. To try an idea, you just add one more item to the menu on the left. Design ideas sat there as switchable features, all but production — an idea a designer can hold, as a feature of his own.
実演は、こう進みます。認証した直後に「何をしに来たのか」を尋ねる。「デザイナーで、コーディングではなくタスクのために来た」と答えると、画面はその人に合った提案を返します——Slack、Gmail、Datadog、Linear。ふだん使う道具ばかり。使わないものは、その場で外せる。エンジニアとして入り直すと、提案は GitHub 連携やコーディング寄りの画面に変わりました。The demo went like this. Right after you authenticate, it asks what you came to do. Answer “a designer, here for tasks rather than coding,” and the screen returns suggestions tuned to you — Slack, Gmail, Datadog, Linear. All the tools you actually use. The ones you don’t, you drop on the spot. Sign back in as an engineer, and the suggestions shift to GitHub and coding-oriented screens.
目を引いたのは、この出し分けの画面そのものを、John がコードではなく言葉だけでつくっていたことでした。「Connect Slack ボタンのあるチャット画面をつくって」と頼み、返ってきたものを直しながらかたちにしていく。しかもそれはモックではなく、実際に動いて URL で人に配れる状態でホストされている。デザイナーがつくれる範囲は、静止したモックを越えて、動いて配れるものにまで及んでいました。What caught my eye: he built the role-based screens themselves — with words alone, not code. “Make me a chat screen with a Connect-Slack button,” then shape it by correcting what comes back. And it’s hosted for real — he can send someone a link right away. A designer’s reach had extended past the mock, all the way to something that runs.
「私はまさに Cursor でフロー全体を組み立てている。ほとんどは“つくって”と頼むだけだ」 “I’m really using cursor to build out an entire flow. Most of this stuff, I’m just asking it to do.” John Bai・3:07
ここから考えるWhat it asks
デザイナーが動くものまで手を伸ばせると、担当の線引きはあいまいになる。実際このデモでは、要件を決める役と画面をつくる役が、一人に重なっていた。役割の線は、どこに引き直されるのか。どこまでを一人で、どこからを一緒に進めるのか。When a designer can reach all the way to something that runs, the line between roles blurs. In this demo, the person deciding requirements and the person building screens were one and the same. So where does the line get redrawn — how far does one person go alone, and where does working together begin?
Figma を下書きにして、実装は Cursor に委ねるFigma for the sketch, Cursor for the build
John のつくりかたは、こうでした。まず Figma でラフを描く。ただし彼はそれを「散らかっている」と言います。思いつきを置くだけで整えないのです。ここでは、オートメーションの使い方を伝えるバナーをモックしていました。
そして、それをそのまま Cursor に渡して「つくって」と頼み、返ってきたものを見ながら方向づけていく。作り込んだカンプを引き渡すという前提そのものが、ここにはありませんでした。
(Cursor にも plan・debug・canvas という作業モードがあり、John はそれにも触れていました。canvas は Cursor 内でビジュアルを扱う機能で、Figma とは別物です。)His process went like this. A rough idea in Figma first — “messy,” he calls it. Just a place to drop thoughts, never tidied. Here, a mock of a banner teaching people how to use automations.
Then he hands it straight to Cursor: “build it.” From there he steers by watching what comes back. The premise of handing over a polished comp simply wasn’t there.
(Cursor has work modes too — plan, debug, canvas; canvas handles visuals inside Cursor, apart from Figma. John touched on that as well.)
「これが最近の私の Figma。ほんとうに散らかっている。これをそのまま Cursor に落として“つくって”と言う。あとは出てきたものを私が方向づけていく」 “This is my figma these days—really messy. I just drop this into cursor and tell it to build it. It’ll do its best and then I direct it from there.” John Bai・2:30
ここから考えるWhat it asks
作り込んだカンプを渡す前提を、私たちはどこまで手放せるのか。ラフを早く動かして直していく進め方に寄せるなら、デザインレビューは絵の完成度を確かめる場ではなくなる。では、何を見る場に変わるのでしょうか。How far can we let go of handing over polished comps? If we lean into getting something rough moving early and fixing from there, design review stops being where we check how polished the mock is. So what do we look at there instead?
「どう頼めばよかったか」を、エージェントに聞くAsk the agent how you should have asked
残り時間わずかで、John が一番伝えたかったことがこれでした。
多くの人は、エージェントに一つずつ指示を出しては行き詰まってしまう。そもそも、エージェントに「助けて」と頼むことすら思いつかない。彼のやりかたは逆でした。何度もやり直してようやくうまくいったあと、エージェント自身に聞くのです。「この結果を一発で出すには、どう頼めばよかった?」と。
返ってきた答えは、使いまわせる skill として残しておく。うまくいった依頼の仕方を個人の勘で終わらせず、チーム全員で使えるかたちにしていくのです。With little time left, the one thing John most wanted to land.
Most people fire one instruction at a time and hit a wall — and it rarely occurs to them to ask the agent for help at all. His habit is the reverse. After many tries, once something finally works, he asks the agent itself: “What should I have asked to get this in one shot?”
He keeps the answer as a reusable skill. A “way of asking” that worked doesn’t stay a private knack — it becomes something the whole team can use.
「何かをデザインして、何度も試してやっとうまくいったあと、エージェントに聞くんだ。“この最終結果を出すには、どう頼めばよかった?”とね」 “Once I’ve designed something and it took a lot of tries… I’ll ask the agent, what would you have asked to get the end result I ended up with?” John Bai・4:53
ここから考えるWhat it asks
苦労して見つけたうまくいく依頼の仕方は、いま誰か一人の中に留まっていないでしょうか。それを持ち寄って残す場所が、要るのかもしれません。A hard-won way of asking may be stuck inside one person right now. Perhaps we need a place to pool those ways of asking — and hold onto them.
そして、壇上でデモは数回止まったAnd on stage, the demo stalled several times
最後に、もう一つ。
このデモは、途中で数回止まりました。GitHub 連携から先へ進もうとした場面で画面が固まったのです。John は取り乱さず、「まあ、こういうこともある」と言って、朝つくった別のバージョンに切り替えました。
仕上がった手法を見せるのではなく、止まっては直してまた進む。この止まりながら進む実演こそ、AI と一緒につくっている私たちの毎日に、いちばん近いのだと思います。One last thing.
This demo actually stalled in places. Trying to move past the GitHub connection, the screen froze. John didn’t flinch — “that happens too” — and switched to another version he’d made that morning.
Not a finished technique on display, but stalling, fixing, moving on again — that “work-in-progress” state may be the closest thing to our own days building alongside AI.
「あ、壊れた。まあ、こういうこともある。大丈夫、別のを見せる。これは今朝つくったものだ」 “Oh, it broke. That happens too. It’s okay—I’ll show you a different one. This is the one that I did this morning.” John Bai・1:37
この5分の全体像The whole five minutes
ここまでの3つは、5分のデモから抜き出したものです。前後にどんな流れがあったかは、下を開くと時系列でたどれます。These three points came out of a five-minute demo. Open the section below to follow the whole thing in order.
全体の流れを時系列で開く(0:00 → 4:53)Open the full timeline (0:00 → 4:53)
- 0:00エージェントを並走させるRun agents in parallel
複数のデザイン変更を同時に。コツは同じ画面を複数エージェントに触らせないこと。Several design changes at once. The trick: don’t let multiple agents touch the same surface.
“Once we have them avoid overlapping, so if you’re working on one single surface, sometimes it gets a little dicey. Our agents are improving every day, every week.” - 0:51題材=オンボーディングSubject: onboarding
技術者でない人には用語が難しい。開発の流れはデザイナーの流れと違う。だから onboarding を作っている。The terms are hard for non-technical people; the dev flow differs from how designers work. Hence onboarding.
“I’ll show you agentic onboarding. Or agentic unboxing.” - 1:13これは本物This is real
認証直後に「何をしたいか」を尋ねる新フロー。サイトにホスト済みでリンク共有できる。A new flow that asks “what do you want to do” right after auth. Hosted, shareable by link.
“By the way, now this is real. This is all in baby glass.” - 1:37壊れたIt broke
コードベースの流れで GitHub 連携 → Continue で停止。慌てず朝作った別版へ。On the code-base path, GitHub connect → Continue froze. Calmly switched to a version made that morning.
“Oh, it broke. That happens too… I’ll show you a different one.” - 1:53役割で出し分けTailored by role
デザイナーには Slack / Gmail / Datadog / Linear、エンジニアには GitHub とコーディング画面、と提案が変わる。Designers get Slack / Gmail / Datadog / Linear; engineers get GitHub and coding screens.
- 2:21canvas モードCanvas mode
plan / debug / canvas モードに言及。Figma のラフ → Cursor → 修正のループ。Mentions plan / debug / canvas modes. Figma rough → Cursor → fix loop.
- 4:36skillsskills
「どう頼めばよかったか」をエージェントに聞いて skill 化(上の 03)。Ask the agent how you should have asked, and make it a skill (point 03 above).
※ 書き起こしは録音から。読みやすく整え・訳しています。タイムコードは目安。Transcribed from the recording; lightly edited and translated for reading. Timecodes are approximate.
つくるより、届くReaching, more than making
彼が選んだ題材は、オンボーディングだった。
はじめての人に、どう届くか。
つくる話のようでいて、ほんとうは、届ける話。
言葉がむずかしい人にも、
つくり手とちがう流れで動く人にも——
ちゃんと届くように。
動くものをつくれること以上に、
それが誰かに届くかどうか。
つくるより、届く。
そこにデザインの重さを置いていきたいと思っています。
The thing he chose to build was onboarding.
How does it reach someone arriving for the first time?
It looks like a story about making — but really, it’s about reaching.
For the ones the words are hard for,
for the ones who move through a different flow than the makers—
so it reaches them, properly.
More than being able to make the thing that runs,
whether it reaches a person.
To reach, more than to make.
That’s where I want to place the weight of design.