#ui設計

最初に思ったのは、やっと「選ばせない」方向に振ったか、ということでした。 生成AIのUIって、便利になればなるほど「ここはチャット、ここは作業場、ここはデザイン」と分かれていきがちです。でも実際の仕事はそんなにきれいに分かれない。調べながら考え、まとめながら直し、最後は資料にする。記事を読んでいて、その面倒さをプロダクト側がようやく真正面から受け止めた感じがしました。 特に引っかかったのは、「どこにタスクを置くか」をユーザーに考えさせない、という発想です。これ、地味だけど大きいです。人はタスクの種類を先に判断してから動くより、とりあえず投げて、必要なら途中で修正したい。Cowork と chat を分けていたころの不便さは、まさにその逆をやらされていたわけで、そこを溶かしたのは自然だと思います。 しかも Docs、Slides、Design まで会話の流れの中に入れてしまう。これは単なる機能追加というより、「会話が作業の中心になる」という宣言に見えました。 一方で、少し気になったのは、ここまで一体化すると“任せる”範囲が広がるぶん、ユーザーが途中経過をどう把握するかです。記事では進捗確

最初に思ったのは、「AIに実装させると、デザインが崩れるのはそりゃそうだよな」ということだった。 人間のチームでも、コンポーネントをちゃんと共通化していないとボタンの角丸や余白が少しずつズレていく。そこに coding agent が入ると、毎回“それっぽい最適解”を新しく作ってしまう。この記事は、その当たり前の厄介さをかなり実感のある形で書いていて、妙に納得した。 特に引っかかったのは、著者が「デザインの問題」ではなく「コードベースの構造の問題」として見ているところだ。 見た目がバラつくのは、AIのセンスが悪いからというより、参照すべき標準がコードの中に存在しないからだ、という発想はかなり筋がいいと思う。UIを shared folder に寄せて、そこ以外で勝手に新しい部品を作らせない。これは地味だけれど、AI時代のフロントエンドではかなり重要な統制だろう。 一方で、少し怖さもある。 「このフォルダ以外で新しいUIを作るな」と厳しく縛るのは有効だけれど、運用を間違えると今度は柔軟性が死ぬ。新しい表現が必要な場面まで既存部品に押し込めると、アプリが逆に窮屈になるはずだ。だから本当に大

この記事を読んでまず思ったのは、「AIで機能を作る」より先に、「機能の迷いどころを潰す」ほうがずっと大事なんだなということでした。 しかもその迷いどころって、実装の細部ではなくて、UIの振る舞いとか、既存データを触っていいのかとか、あとで見返したときに意味が残るか、みたいなところなんですよね。 特に腑に落ちたのは、筆者が skills を「賢くする魔法」ではなく、人間が後回しにしがちな面倒を整理する道具として扱っている点です。 `grill-me` で曖昧な要件を質問の分岐に落とし、`grill-with-docs` でその決定を glossary や ADR に残し、`Ponytail` で「本当に新しい抽象化が必要か」を疑う。ここ、かなり実戦的だと思いました。AI にコードを書かせる話って、つい生成速度のほうに目が行くけれど、実際に時間を食うのは「あとで困る設計を最初に作ってしまうこと」なので。 もうひとつ面白かったのは、デザイン系の skills を使う流れです。見た目を整える、ではなくて、同じアプリの中で UI の人格がブレないようにするために使っている