リンクをコピーしました

とあるプロジェクトの打ち合わせで、「AI生成の画面デザインって、どうしてAIっぽく感じるんですかね?」と聞かれた。これは、プロダクトデザインに関わる人たちにとっては、結構いい酒のつまみになる話だと思う。


デザイナーである僕の感覚的な話になるが(専門外の人が同じ違和感を抱くかどうかは分からないが)よく感じるのは、「ただ、結果だけが立ち上がって見える」という、妙な手触りのことだと思う。

僕は、アプリケーションやWebサービスの画面を見たときに、制作者がどんな順序で考え、何を解こうとしていたのかを想像することができる。あるいは、どこがまだ詰めきれていないのか、どこで思考が止まっているかも、それなりに見抜くことができる。こだわりを感じるところや、迷いのあるところは触れば分かるし、そこに制作のプロセスが痕跡として残っているからだ。

人間のデザイナーはたいてい、何を作るのか、どう使われるのか、情報や構造はどうあるべきか、といった低いレベルの問いから順番に積み上げていく。その結果として、画面全体に一貫した思想がにじむのだが、AIが生成した画面は、第一印象はいかにもいい出来に見えるものの(余白や配色、コンポーネント単体の完成度は高い)しばらく眺めていると、この画面で何をしてほしいのか、この情報はなぜこのように置かれているのか、といった根本的な意図が不明瞭であることに気づく。

単に設計が甘い、という感じとも少し違う。人間が考えきれなかったときのような、迷いの跡がなく、判断の来歴が見えない。どこか空洞を覗き込んでいるような感触だ。


言葉にしていて気づいたが、これは「AIっぽさ」というより、「素人がAIを使って作った感じ」のことを言っているのだと思う。

デザイナーがAIを使う場合は、基礎的な設計や前提をAIとの対話の中で詰め、それを共有したうえで生成させる。そうすると、この種の空洞感はかなり薄れていく。(実際、去年の夏頃から僕が作ったものは、ほとんどそうやって作られている。)

また、「AIっぽいかどうか」は本質的な問題ではない。重要なのは、使いやすいかどうかであり、利用者にとっては制作の方法や背景よりも、目の前の体験がすべてである。利用者が支障なく使えるのであれば、専門家の目に「AIっぽさ」が映ったとしても、ひとまず問題視するべきではないだろう。

だから、僕が「AIっぽさ」を気にしているのは、そこに「使いづらさ」があるからだ。まず「使いづらさ」が先にあって、その使いづらさの原因を専門家として見たときに「これはAI生成に起因しているな」と分かってしまうために、「うーん、いかにもAIぽいですねえ」などと口走ってしまっているに過ぎない。

これは自戒も込めて書いておくのだけど、決して「AIっぽさ」そのものを問題視したいわけではないので、AI生成物をレビューするシチュエーションにおいては、それがどんなAIでどう生成されたか……といった話題にうつつを抜かさず、可及的すみやかに話題の中心を「使いづらさ」とその解決方法に移行するよう努めていきたい。

AIでUIをデザインするウェブアプリ「Stitch」、公開共有機能を追加(gihyo.jp)

  • AIでUIデザイン案を生成できるGoogleのWebアプリ「Stitch」に、作成したデザインをURLで公開・共有できる機能が新たに追加された。

  • 公開共有を有効にすると、アカウントを持たない第三者でもブラウザ上で生成したデザインを閲覧できるようになる。

  • 共有ページでは、完成したUIの見た目だけでなく、生成時に入力したプロンプトや条件も確認でき、どのような指示からそのデザインが生まれたのかを追える構成になっている。これにより個人の試行錯誤に留まっていたAI生成UIを、レビューやアイデア共有、学習目的などで外部と共有しやすくなった。


Stitchのこの機能は既にFigma Makeにもあるものだけれど、生成AIのこうした機能によって、制作のプロセスを可視化し、他者に見せる前提で扱えるようになった点が面白いと思う。

九段理江がAIを使って小説を書き、そのプロンプトごと公開するという企画があったけれど、まさにこうした新しい制作環境を活かしたうまい企画だと思う。

統計的には正しいが、人間的には間違っている──AI駆動UXにおけるデータの限界(UX Matters)

  • AIを用いた体験設計において、「データに基づく判断が統計的には正しくても、ユーザー体験としては不適切になるケースがある」という問題提起。筆者はこれを「Statistically Right, Humanly Wrong」(統計的には正しいが、人間的には間違っている)という言葉で表現している。

  • AIは過去の行動データを集計し、「多くの人が選んだ」「成功率が高かった」選択肢を返すのが得意だが、それは平均的なユーザー像に最適化されているにすぎない。UXの観点では、ユーザーは常に平均的ではなく、そのときどきの目的・感情・制約を抱えており、その文脈が無視されると違和感が生じてしまう。

  • また、レコメンドや自動判定が「確率的に正しい答え」を出すことで、ユーザーの選択肢を狭めたり、意図を先回りしすぎたりする点が問題視されている。たとえば「多くの人がそうしたから」という理由で提示された結果は、本来あるべきユーザー自身の思考を蔑ろにしてしまっている。

  • 筆者は、データが扱えるのは「何が起きたか」「どの行動が多かったか」までであり、「それがユーザーにどう感じられるか」「尊重されていると感じるか」といった心理的・倫理的な側面は捉えにくい、と明確に線を引いている。(UX設計において、定量データだけに依存する危険性を指摘している。)

  • UX的に重要なのは「ユーザーがその結果を理解できるか、納得できるか」という点だが、AI駆動のUX設計では「なぜこの結果になったのか」がブラックボックス化しやすい。そのため、予測精度の高さだけでなく、説明可能性(なぜそう判断したかを示すこと)や、ユーザーが介入・修正できる余地を意図的に残すことが重要。

  • 筆者は、統計的な正解と人間にとっての納得感は別物であるという前提を置いた上で、そのズレを埋めるのがUXの役割だ、と整理している。AIは最終判断者ではなく、判断材料を提示する補助的な存在として活用されるべきだという主張。

Cursorへの課金が、いよいよもって止まらない。

これまでは、月額60ドルの「Pro+」プランをベースに、足りなくなったら都度払いするという小市民的スタイルで凌いできた。しかし、現実は非情である。10ドル、また10ドルと積み重なる課金も、AIの計算資源の前では焼け石に水であった。そして今日、今週四度目となる「You've hit your usage limit」のアラートが画面に表示されたとき、嗚呼、これが年貢の納め時というものか、と僕は静かにまぶたを閉じ、「Ultra」プランへのアップデートボタンを押し込んだのであった。

月額200ドル。 今のレートならざっと32,000円。繰り返すが、毎月である。十年少し前にAdobeが月額課金になったとき、月5,000円という金額で騒いでいたのが懐かしい。デザインツールならまだしも、テキストエディタに毎月三万円を払うことになるなんて、あの頃には考えられなかっただろう。

明日からはもやしを食べてコードを書こうと思う。

ここ数日、僕のこのブログが閲覧できない状態が続いていたようだ。

原因は、Netlifyで契約しているクレジット量(1,000クレジット)が上限に達してしまったことで、「クレジットを追加しない限りサイトは停止したままです」という通知が届いていた。なんてこった。

管理画面のCredit usage breakdownを確認すると、Production deploysで1,470クレジットを消費している。つまり、ほぼすべてがデプロイ由来の消費ということになる。1回のデプロイにつき、本番ビルド+本番CDNへの反映+メタデータ処理が走り、約15クレジットが使われている計算だ。

昨年11月にCMSをContentfulへ移行したことで、更新回数が増えたのが大きな要因だろう。Contentfulはエントリーを保存するたびにWebhookを飛ばし、Netlifyはそれを検知するたびに自動でデプロイを実行する。それが記事の微修正であっても例外ではない。

言葉を少し直すたびに15クレジットが消費されていたと考えると、これはなかなかに大ごとだ。推敲しやすい環境を手に入れたと思ったら、同時に課金が加速しやすい構造を作ってしまっていた。今さらながら、CMS × Netlifyというのはかなりマズい組み合わせであることに気がついた。

対策としてデプロイを手動に切り替える方法も考えられるが、それでは問題を解決する代わりに利便性を手放すことになる。NetlifyをやめてCloudflare Pagesを使うのがよさそうに思えるが(確か公式にHugo対応していたはず?)今度詳しく調べてみよう。