AIでUIをデザインするウェブアプリ「Stitch」、公開共有機能を追加（gihyo.jp）
AIでUIデザイン案を生成できるGoogleのWebアプリ「Stitch」に、作成したデザインをURLで公開・共有できる機能が新たに追加された。
公開共有を有効にすると、アカウントを持たない第三者でもブラウザ上で生成したデザインを閲覧できるようになる。
共有ページでは、完成したUIの見た目だけでなく、生成時に入力したプロンプトや条件も確認でき、どのような指示からそのデザインが生まれたのかを追える構成になっている。これにより個人の試行錯誤に留まっていたAI生成UIを、レビューやアイデア共有、学習目的などで外部と共有しやすくなった。
Stitchのこの機能は既にFigma Makeにもあるものだけれど、生成AIのこうした機能によって、制作のプロセスを可視化し、他者に見せる前提で扱えるようになった点が面白いと思う。
九段理江がAIを使って小説を書き、そのプロンプトごと公開するという企画があったけれど、まさにこうした新しい制作環境を活かしたうまい企画だと思う。
ドキュメントを手作業で保守する時代は終わり──Googleが「Code Wiki」を公開プレビュー（窓の杜 / Forest Watch）
Googleが「Code Wiki」の公開プレビューを発表。AIを活用して、パブリックなソースコードリポジトリからドキュメントを自動生成・自動更新するサービスとしてリリースされた。
Code Wikiは、コード自体を解析し、そこからコメントや説明、使用例などのドキュメントを生成してオンラインでホストする仕組み。ソースコードが変更されると、ドキュメントも継続的に更新される仕組みになっていると伝えられている。
このサービスは、手作業でドキュメントを書いたり更新したりする負担を減らすことを目的としており、コードベースの変化に即応するドキュメント保守の自動化を狙っている。
合わせて、Code Wikiと連携する形で「Gemini CLI」の拡張機能も開発中で、これを使えばローカルリポジトリでも同様の自動ドキュメント生成・管理が可能になる予定という。
なお現在はまだ公開プレビュー段階であり、正式リリース前の試用的な提供だが、公開リポジトリを基点にした継続的ドキュメント生成プラットフォームとして期待が示されている。
とりあえずウェイティングリストに登録したが、ほんまかいな感がすごい。
AIデザインツール「Layermate」の特長を紹介 Goodpatchデザイナーによる活用事例も
とあるプロジェクトの打ち合わせで、「AI生成の画面デザインって、どうしてAIっぽく感じるんですかね？」と聞かれた。これは、プロダクトデザインに関わる人たちにとっては、結構いい酒のつまみになる話だと思う。
デザイナーである僕の感覚的な話になるが（専門外の人が同じ違和感を抱くかどうかは分からないが）よく感じるのは、「ただ、結果だけが立ち上がって見える」という、妙な手触りのことだと思う。
僕は、アプリケーションやWebサービスの画面を見たときに、制作者がどんな順序で考え、何を解こうとしていたのかを想像することができる。あるいは、どこがまだ詰めきれていないのか、どこで思考が止まっているかも、それなりに見抜くことができる。こだわりを感じるところや、迷いのあるところは触れば分かるし、そこに制作のプロセスが痕跡として残っているからだ。
人間のデザイナーはたいてい、何を作るのか、どう使われるのか、情報や構造はどうあるべきか、といった低いレベルの問いから順番に積み上げていく。その結果として、画面全体に一貫した思想がにじむのだが、AIが生成した画面は、第一印象はいかにもいい出来に見えるものの（余白や配色、コンポーネント単体の完成度は高い）しばらく眺めていると、この画面で何をしてほしいのか、この情報はなぜこのように置かれているのか、といった根本的な意図が不明瞭であることに気づく。
単に設計が甘い、という感じとも少し違う。人間が考えきれなかったときのような、迷いの跡がなく、判断の来歴が見えない。どこか空洞を覗き込んでいるような感触だ。
言葉にしていて気づいたが、これは「AIっぽさ」というより、「素人がAIを使って作った感じ」のことを言っているのだと思う。
デザイナーがAIを使う場合は、基礎的な設計や前提をAIとの対話の中で詰め、それを共有したうえで生成させる。そうすると、この種の空洞感はかなり薄れていく。（実際、去年の夏頃から僕が作ったものは、ほとんどそうやって作られている。）
また、「AIっぽいかどうか」は本質的な問題ではない。重要なのは、使いやすいかどうかであり、利用者にとっては制作の方法や背景よりも、目の前の体験がすべてである。利用者が支障なく使えるのであれば、専門家の目に「AIっぽさ」が映ったとしても、ひとまず問題視するべきではないだろう。
だから、僕が「AIっぽさ」を気にしているのは、そこに「使いづらさ」があるからだ。まず「使いづらさ」が先にあって、その使いづらさの原因を専門家として見たときに「これはAI生成に起因しているな」と分かってしまうために、「うーん、いかにもAIぽいですねえ」などと口走ってしまっているに過ぎない。
これは自戒も込めて書いておくのだけど、決して「AIっぽさ」そのものを問題視したいわけではないので、AI生成物をレビューするシチュエーションにおいては、それがどんなAIでどう生成されたか……といった話題にうつつを抜かさず、可及的すみやかに話題の中心を「使いづらさ」とその解決方法に移行するよう努めていきたい。
「考えなくていいUI」は、ユーザーが何を次に見るべきかを判断する必要がなく、システムが注意の向け先を決めてくれるUI体験のこと（例：Slackのキャッチアップ、TikTok）。
こうしたUIは「タイムライン的UI」と呼べる特徴（一直線の並び、目的が完結、順序付け、優先度の制御）を持ち、人間の注意を誘導する設計になっている。
一方で、自由に探索して考える「トポグラフィ的UI」には創造性や管理性の利点があり、両者のバランスがデザインで重要になる。
なぜ『みらい議会』はユーザーの支持を集めた？ソフトウエアが飽和する時代の「優れたUIデザイン」に必要な四つの要素（type）
国会で「いまどんな法案が検討されているか」をわかりやすく伝えるプラットフォーム「みらい議会」がリリースされ、SNS上で「使いやすい」という評価が多く集まった背景を、開発を主導したエンジニア・村井謙太とデザイナー・山根有紀也へのインタビューで掘り下げている。
UIを「画面の見た目」ではなく「政治とのインターフェース」と捉え直し、機能要件・情報設計・トンマナ・ビジュアルを一体で設計したこと、理解度が人によって違う前提でストレスなく理解が進むインタラクションを重視したことが語られている。
具体的な「わかりやすさ」の手当として、法案の一覧表示に加え、「やさしく／詳しく」切り替え、AIアシスタントによる解説、ルビ機能、議論の進捗が見えるステータス表示などを挙げ、これらは開発チーム自身が法案原文を読み解く中で感じた「つまずき」から必要性を判断した、と説明されている。
「つまずき」をプロダクトに落とし込む方法として、まず作り手がファーストユーザーとして原文を読み、元官僚のメンバーから初歩的なところをレクチャーしてもらいながら理解を積み上げたこと、そこで出た疑問（結局どこがポイントか／経緯は／誰に影響があるか等）をそのまま解説の導入ポイントにしたこと、写真を先に置くなど直感的な理解の足場を作る工夫が紹介される。
開発体制面では、議員・元官僚・エンジニア・デザイナーの4人が分業の線引きをせず、プロトタイプを触ってフィードバックする「気持ちをもつ会」も挟みつつ、表示速度やタップ時アニメーションなど、境目で抜け落ちやすい非機能要件まで含めて体験の継ぎ目を埋めた。
「優れたUIはデジタルの外まで設計されている」という観点として、同種の機能自体は他でも作れる一方で、「みらい議会」は実世界で活動する「チームみらい」という実体が信頼の土台となっていることが特徴。ソフトウェア／情報／AIフェイクが飽和する時代には、Web上の設計と物理的な活動がハイブリッドに噛み合うことが重要だと述べられている。
CSS Masonryについて（sakupi01 blog）
CSS Masonryは、Pinterest型の段組みレイアウトを、JavaScriptによる配置計算ではなく、CSSのレイアウトモデルとしてネイティブに扱おうとする仕様提案で、DOM順やアクセシビリティを保ったまま、高さの異なる要素を列方向に詰めて配置することを意図している。
記事では、CSS Gridは行を揃える二次元レイアウトであるがゆえにカードUIでは余白が生じやすく、Multi-columnは視覚順と読み順が乖離し、JS Masonryは再計算コストやDOM操作による保守性の問題を抱えてきた、という整理がされている。
その上でCSS Masonryは、「自然な視覚配置」と「構造的な正しさ」を両立できる可能性を持つ一方、配置の予測可能性や制御性が下がるというトレードオフも含んでおり、意味的な行・列を持たないカード一覧などに用途を限定して考えるべきものとして位置づけられている。
