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

---

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

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

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

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

---

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

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

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

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

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

AIを活用したプロトタイピング、期待される効果と注意すべき課題（Nielsen Norman Group）

• AIを用いたプロトタイピングは、ワイヤーフレームやUI案の生成、文言やレイアウトのバリエーション出しなどを短時間で行える点に強みがあり、探索フェーズのスピードと量を大きく押し上げる。特に「白紙から考える」負担を下げる用途では効果が高い。

• 一方で、AIが生成するプロトタイプは、ユーザー課題や利用文脈への理解が浅いまま、視覚的に完成度の高いアウトプットを出しやすく、見た目に引きずられて設計判断が甘くなる危険が指摘されている。

• 動画では、AI生成物をそのまま「解決策」として扱うのではなく、仮説を考えるための素材や比較対象として使うことが重要だと説明される。プロトタイプはあくまで検証の道具であり、完成度の高さは必須ではない。

• また、AIを使うことで、なぜその構造・導線・要素配置になったのかという設計意図がブラックボックス化しやすく、チーム内での合意形成やレビューが難しくなる点も落とし穴として挙げられている。

• そのため、AIを使う前提として、ユーザー課題、シナリオ、制約条件などを人間が明確に言語化しておくこと、そしてAIの出力を必ず批評・修正するプロセスを挟むことが、実務での健全な使い方として整理されている。

The Psychology of User Experience: How Small Design Tweaks Can Cause Big Behavioral Changes

https://www.uxmatters.com/mt/archives/2025/11/the-psychology-of-user-experience-how-small-design-tweaks-can-cause-big-behavioral-changes.php

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

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

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

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

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

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

---

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

AIデザインツール「Layermate」の特長を紹介　Goodpatchデザイナーによる活用事例も

https://goodpatch.com/blog/2025-11-layermate

MVPで進めるプロジェクトマネジメント—スコープの再定義と合意形成プロセス（MonotaRO Tech Blog）

• MVPを単に「実装量を減らした初期版」ではなく、「仮説を検証するために必要十分な単位」と定義し直し、その前提でプロジェクトをどう進めるか、とマネジメントの視点から整理している。（MVPを開発手法ではなく、プロジェクトマネジメント視点で見ているのがおもしろい！）

• まず、実際の開発現場において、要件は必ず途中で増えたり揺れたりするものだという前提に立つ。最初に決めたスコープを守るのではなく、検証結果や状況の変化に応じてスコープを更新できるようなプロセスがあることが重要。

• ポイントは、技術的制約、ビジネス上の期待、運用負荷といった異なる制約条件を一度すべて言語化し、「今回は何をやらないのか」と「どこまでできれば検証として十分か」を関係者全員が同じ言葉で共有すること。スコープを変更する必要がある場合も同様に、その理由と判断基準をきちんと説明する。

• 検証したい仮説を明確にした上で、そのための機能の洗い出しと優先度の整理を行い、MVPを構想する。MVPの作成を、あるフェーズにおける一度きりのものではなく、意思決定と合意形成を繰り返しながら前に進むための運用フレームとして捉える。

---

生成AIの発達によって検証用のモノを作るコストが圧倒的に下がりつつある中で、こういうアイデアはとても参考になる。

この一年は、誰かが生成AIで作った画面を差し出して「こんな感じでどうですか！」と合意を取ってプロジェクトが進行してしまう、という話を聞くことが多かった。そこで合意が得られているのは、単なる見た目や雰囲気であり、検証内容ではないのだろう。つまり、戦略的なレイヤーで合意を得るというプロセスが抜け落ちてしまっているのだと思う。

モノタロウの記事が示しているのは、MVPを「形」ではなく「問い」として扱おうとする姿勢だ。いま目の前にあるそれは、いったい何を検証するためのものなのか。その点を曖昧にしたままでは、それっぽいものができあがりはするものの、ユーザーの「必要」に接近することは難しい。