リンクをコピーしました

数日前に唯我くんから送られてきた PK shampoo のブログを何度も読み返してしまう。文章の勢いがいい。雑に書かれているようだが、引き込まれ、読ませられる。特に後半の思考の反芻をそのまま垂れ流しているようなところが好きだ。

https://pkshampoo.jp/%e4%b8%83%e6%9c%88/

俺は昔、家に居場所がなくて学校も大嫌いで、気質的に欲しいものも買いたいものも全然ないタイプだから働くことにも絶望的に向いてない自分にほとほと嫌気がさしてたけど、頼んでもないのに私はあなたの味方だよ、学校なんて辛かったら行かなくてもいいんだよ、みたいことを言いながら猫撫で声で擦り寄ってくるタレントやミュージシャンには絶対感化されたくなかったし、だからどんなにクソな人間関係や教育制度の荒波に飲まれようと真っ向から学校を卒業して絶対に社会に迷惑をかけてやるぞと目を閉じ耳を塞ぎ息を止めながら青春時代を早足で歩き抜けたのだが、このバンドはやっぱりその先というか道中で、つまりはどうしようもない大学生活の中で偶然出会った俺以上にバカな奴らとの縁で出来上がったものだし、アレは嫌だ!コレは失敗だ!とかgdgd言いながらでもとにかく続けてたらやっぱりその先というか道中で何か素晴らしいものに出会えるかもなあ、なんてことをぼんやり期待したりもする。まぁ実際にはこの先おもしろいことなんて何一つなくて、サルに当たりの確率下がっていくボタンを押させまくる実験みたいな状態に陥ってるのかもしれないし、さっさと関西戻ってレコードかけれるBARでもやりてえなあ、と三日に一回くらいは思うけど、それでも月に一回くらいは、たとえば今回のZepp DiverCityの時なんかは、やっぱり続けてて良かったなあと思ったりするものだ。

とあるプロジェクトの打ち合わせで、「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の出力を必ず批評・修正するプロセスを挟むことが、実務での健全な使い方として整理されている。

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

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

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

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

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

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


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