リンクをコピーしました

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

ドキュメントを手作業で保守する時代は終わり──Googleが「Code Wiki」を公開プレビュー(窓の杜 / Forest Watch)

  • Googleが「Code Wiki」の公開プレビューを発表。AIを活用して、パブリックなソースコードリポジトリからドキュメントを自動生成・自動更新するサービスとしてリリースされた。

  • Code Wikiは、コード自体を解析し、そこからコメントや説明、使用例などのドキュメントを生成してオンラインでホストする仕組み。ソースコードが変更されると、ドキュメントも継続的に更新される仕組みになっていると伝えられている。

  • このサービスは、手作業でドキュメントを書いたり更新したりする負担を減らすことを目的としており、コードベースの変化に即応するドキュメント保守の自動化を狙っている。

  • 合わせて、Code Wikiと連携する形で「Gemini CLI」の拡張機能も開発中で、これを使えばローカルリポジトリでも同様の自動ドキュメント生成・管理が可能になる予定という。

  • なお現在はまだ公開プレビュー段階であり、正式リリース前の試用的な提供だが、公開リポジトリを基点にした継続的ドキュメント生成プラットフォームとして期待が示されている。


とりあえずウェイティングリストに登録したが、ほんまかいな感がすごい。

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

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

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

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

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

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

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

「考えなくていいUI」を考える

  • 「考えなくていいUI」は、ユーザーが何を次に見るべきかを判断する必要がなく、システムが注意の向け先を決めてくれるUI体験のこと(例:Slackのキャッチアップ、TikTok)。

  • こうしたUIは「タイムライン的UI」と呼べる特徴(一直線の並び、目的が完結、順序付け、優先度の制御)を持ち、人間の注意を誘導する設計になっている。

  • 一方で、自由に探索して考える「トポグラフィ的UI」には創造性や管理性の利点があり、両者のバランスがデザインで重要になる。

なぜ『みらい議会』はユーザーの支持を集めた?ソフトウエアが飽和する時代の「優れたUIデザイン」に必要な四つの要素(type)

  • 国会で「いまどんな法案が検討されているか」をわかりやすく伝えるプラットフォーム「みらい議会」がリリースされ、SNS上で「使いやすい」という評価が多く集まった背景を、開発を主導したエンジニア・村井謙太とデザイナー・山根有紀也へのインタビューで掘り下げている。

  • UIを「画面の見た目」ではなく「政治とのインターフェース」と捉え直し、機能要件・情報設計・トンマナ・ビジュアルを一体で設計したこと、理解度が人によって違う前提でストレスなく理解が進むインタラクションを重視したことが語られている。

  • 具体的な「わかりやすさ」の手当として、法案の一覧表示に加え、「やさしく/詳しく」切り替え、AIアシスタントによる解説、ルビ機能、議論の進捗が見えるステータス表示などを挙げ、これらは開発チーム自身が法案原文を読み解く中で感じた「つまずき」から必要性を判断した、と説明されている。

  • 「つまずき」をプロダクトに落とし込む方法として、まず作り手がファーストユーザーとして原文を読み、元官僚のメンバーから初歩的なところをレクチャーしてもらいながら理解を積み上げたこと、そこで出た疑問(結局どこがポイントか/経緯は/誰に影響があるか等)をそのまま解説の導入ポイントにしたこと、写真を先に置くなど直感的な理解の足場を作る工夫が紹介される。

  • 開発体制面では、議員・元官僚・エンジニア・デザイナーの4人が分業の線引きをせず、プロトタイプを触ってフィードバックする「気持ちをもつ会」も挟みつつ、表示速度やタップ時アニメーションなど、境目で抜け落ちやすい非機能要件まで含めて体験の継ぎ目を埋めた。

  • 「優れたUIはデジタルの外まで設計されている」という観点として、同種の機能自体は他でも作れる一方で、「みらい議会」は実世界で活動する「チームみらい」という実体が信頼の土台となっていることが特徴。ソフトウェア/情報/AIフェイクが飽和する時代には、Web上の設計と物理的な活動がハイブリッドに噛み合うことが重要だと述べられている。