【Skill配布あり】(おそらく)AIのUI出力精度を劇的に上げる方法

今日の記事は最近実験中のAIでのUI検討方法についての記事です。

AIにUIを作らせると、それっぽい見た目で動くUIが出てくるんですが…どことなく違ったり物足りなかったりします。

最近Claude Codeで検索UIを実装してみて、色々指摘していい感じのUIにしたのですが、この時ふと疑問を覚えました。
「なーんでAIはこれを最初から出せないんだ？」

最初は「AIはUXを理解していないから」「人間の感情の機微がわからないから」「ユーザー起点で考えていないから」浅いものが出てくるんだと思っていたのですが…最近ちょっと違う仮説にたどり着きました。

その原因は多分、「AIがUIの検討前にベストプラクティスを棚卸ししていないから」です。

この検討方法に関してClaudeのskillにしたので後続で配布しています。
それでは始めてみましょう。

手癖問題

例えば「検索UIを作って」とAIに頼んでみると、最近のAIはすぐに実装してくれます。
入力フィールドに虫眼鏡アイコンがあり、他にもいくつか機能があり、ちゃんと動くものです。

しかし何回か同じプロンプトで生成していくとあることに気づきます。

生成が安定しないのです。一口に検索UIを作ってといっても出力は安定せず、あぁこういう機能もあるのか…と思わされるわけです。

今までこれを思考停止で「AIは出力にブレがあるからな…」と受けていましたが、よくよく考えるとこれはおかしな話です。

仕様検討はロジカルシンキング

UIを作り慣れている人なら知っていることですが、UIの検討というのは思いの外ロジカルに検討されています。

例えばUIの検討はこんな風にを説明できるはずです。

UIには美的要素が含まれこのあたりになると感覚的になってしまいますが、少なくとも利便性の高い機能というのはロジカルに類推可能なわけです。

となるとここで一つの疑問が湧いてくるわけですね。

「なぜロジカルの権化たるAIは、ロジカルなUI検討を毎回同じ形に収束させられないのか？」

そうです。
つまり感覚的に作っているのではなく、ユーザーのことを理解してロジカルシンキングで検討しているのであれば、ある程度のクセはあれどどのディレクターがやっても、どのAIがやっても、ロジカルでさえあればUIは高確率で同じ形に収束するはずなのです。

が、現実は同じAIですら出力がブレるわけですね。

あれ？ロジカルじゃないじゃん？これはなぜなのか？

AI、手癖でUIを作ってるんじゃないかぁ？

ここでAIの仕組みについて思いを馳せてみますが、AIは確率論的に回答を生成しているので、厳密にはロジカルに決めているわけではありません。
UIを段階を追って検討させるというプロンプトわたしていなければ反射的にレスポンスを返していることになります。

もう少し正確に言うとこれは系列生成と言われる問題です。
ざっくりいうとAIは次のトークンを生成するとき、直前のコンテキストに想起が引きずられます。
なので「検索UIを作って」と言われた瞬間、AIの中で「よく見る検索UIパターン」への引力が強くなって、それ以降の展開はその初動に影響されるというわけです。

これが手癖の正体で、さながら「お！検索UI作るのね！思いついたわぁ。これです！」みたいな感じなわけですね。

棚卸しはその初動をベストプラクティスの列挙によって意図的に制御する操作なので、AIの構造的にワークするはずです。

ユーザー起点の問題だと思っていたが…

さて、この問題を最初私は「AIはユーザーの気持ちがわからない≒AIにいれるコンテクストやサービスの情報が足りない-AIがユーザーの気持ちを理解することが出来ない」…からだと思っていたのですが、ここにもう一つ落としありそうです。

それって、同じコンテクストを与えたらブレなくUIが出ることになりませんか？

もちろんコンテクストの密度によって解釈の幅があり生成のブレがある…ということは事実ですが、同じユーザー像-状況を与えても違う検索UIが出る理由にはなりません。

となるとAIがいいUIを作れないのは感情の点だけでなく別の問題があることになります。

UXデザインに大事な２つの要素

ここでちょっとUXデザインの話をしますが、そもそもUIを検討する際に、あるいはUXデザインを考えるときに大事な要素が２つあります。

私が思うに、基本的にUXデザインの本質は下記です。

この前者がUXリサーチ-後者がUXデザインと言われるのですが、ユーザー像をイメージさせるというのはこの前者にあたります。

では後者は？

良いアイディエーションにはインプットが必要

ではどのように良い解決のアプローチを思いつくのでしょうか。

みなさんは良いアイディエーションをするのに一番大事なことはなにか？と言われたら何だと思うでしょうか。

ブレスト？バイアスをなくすこと？数を出すこと？

私の意見は「良いインプット」です。

例えば昨今だとAIがわかりやすいですね。
AIは紙に書いてあることをOCR的に読むことが出来ますが、このことをあなたが知らなければ、あなたは電子化のシステムを考えているときに「紙をAIに読ませればいいじゃん！」とアイディアを思いつくことができません。

知識はアイディエーションの種であり、知識があるからいいアイディアを思いつき、知識を持つことで課題の解像度があがります。

だからAIにもUIを作成させる前にインプットが必要です。
検索UIを検討させる前に、検索UIにはどのような実装パターンが有るかが必要なのです。

手癖ということはAIの引き出しがあいてない！

そこでまたおかしなことに気づきます。

でもよ、AIこれだけ情報持ってるから、検索UIやナビゲーションのベストプラクティスぐらい知っているんじゃね？

そうですね。AIはちゃんとこれらのベストプラクティスを知っていますし、検索でdebounceが必要なことも、XSS対策が必要なことも、0件のときに誘導文を出すべきことも、全部知っています。

でも知っているのに出てこないのです。
なぜなら手癖で作っているから。

実装に入る前に「このUIで何を検討すべきか」を一度も展開しておらず、知識がアイディエーションに使われていないのです。

というわけでAIに作業させる前にベストプラクティスの棚卸しをさせる必要があります。これが私の考える(おそらく)AIのUI出力精度を劇的に上げる方法です。

検討させるべきレイヤー

ここからはどのようにUIのベストプラクティスをAIに検討させるべきなのか解説。最後にClaudeのSkillもあります。

まずUIには「見た目」以外にもいくつかの検討レイヤーがあります。
例えば5つぐらいに分けてみましょう。

検索UIの検討レイヤー
L1  見た目・レイアウト　　　 コンポーネント配置、空状態、レスポンシブ
L2  インタラクション・挙動   debounce、アニメーション、フォーカス制御
L3  ロジック・アルゴリズム   前方一致/完全一致/曖昧一致、AND/OR/NOT
L4  セキュリティ・信頼設計   エラーの情報開示レベル、入力サニタイズ
L5  バックエンド責務の境界   どのレイヤーで処理するか、APIの契約

肌感としてAIが手癖で出してくるUIは、L1〜L2しか見えていません。
L3以降はバックエンドよりですしね。

たとえばログインフォームで「IDが違います」「パスワードが違います」と個別に教えるのは、L4の設計ミスです。

これは攻撃者にとって「このIDは存在する」という情報になってしまうので、セキュリティ界隈では、「IDまたはパスワードが違います」と曖昧に返すというTipsが言われています。
でも手癖で作ると、親切心から自然に個別のエラーを出してしまいます。

これはバグではなく、設計の決定が省略された結果なのではないでしょうか。

棚卸し

実装の前に引き出しを全部開けさせましょう。

この棚卸しとは、知識を増やす作業ではありません。
すでに持っている知識をL1からL5まで意識的に引きさせ、その後にAIに「このUIで検討すべきことは何か」を判断させるのです。

実際にやってみる：ECサイトの商品検索UI

ではAIに指示してみましょう。

今回紹介のSkillを使うとこうなります。

長いので雰囲気掴んでくれれば大丈夫です。
UIスタックについては後で説明します。

とまぁこんな感じで、本来UIには検討すべきことがこれだけあるのです。

ここまでが棚卸しです。

棚卸しが何を変えるのか

手癖の問題を別の角度から言うと、「選択/判断しない」です。

我々もUIを作るときにいくつかの選択肢からロジカルに選んで、UIを決定します。
選ぶためには比較対象が要ります。AIは比較対象を洗い出していません。だからUIに根拠がなく(乏しく)、だから便利ではないのです。

根拠のない設計は修正できません。
「なんとなくこうした」に対しては「なんとなく直す」しかなくなる。修正依頼が来るたびにゼロから作り直すのは、「選んでない」からです。

Skill作ったよ

というわけで棚卸しがいかに重要か伝わりましたでしょうか。
この棚卸しをさせるClaudeのSkillを作りました。

以下はskillの解説。まずSkillはこの構成になっています。

Skill.md

このスキルにはまずいくつかの重要なコンセプトが書かれています。
ざっとこんな感じ。

でその後に思考プロセスを書いてます。

使ってみた他の人によるとStep2とか3とかは省略されることがあるみたいですが、Step1だけは必ず行うように言明しています。正直これしてくれればあとはなんとでもなる気がする。

examples.md

棚卸し出力のフォーマットなど
執拗網羅的に棚卸しさせるため

ui-stack.md

UIスタックはScott Hurffという人が提唱したUIのよくある状態を5つにまとめたものです。

必ずしも毎回5つに収束するわけでもないが、まぁ考えやすい。
さっきのベストプラクティス-実装の棚卸しとはまた別に、そもそもどういうUI状態があり得るのか？の検討をなくすために。

novel-ui.md

このスキルはちょっと特殊。
先程からベストプラクティスや既存パターンと言っているが、実はここに一つ課題があります。というのもベストプラクティスは「先人の失敗の集積」であり、実装される概念そのものが新しい場合、既存パターンに乗り切らない可能性があるわけです。

例えば検索UIで「キーワードだけじゃなくて、ユーザーが今どういう状況かを加味して結果を変えたい」みたいな要件が出てきたとします。

キーワード検索のベストプラクティスは豊富にありますが、「状況を加味した検索」のパターンはまだほとんど言語化されていません。
このとき既存パターンに引き寄せると、結局「フィルターを増やす」「タグを付ける」という方向に収束してしまって、本来表現したかった概念が歪みます。

このときに真にUI検討で判断すべきは「既存パターンで実装できるか」ではなく「既存パターンで概念の意味が保存されるか」なわけです。
ままならないときにパターンからではなく概念から逆算して未知のUIを作る必要が出てきます。

このスキルにはその判断フローを入れています。
AI時代、みんなが自分のツールを作るようになれば前例のない概念のUIが生まれることはあるわけで、そのときにワークする（はず）です。

終わりに：

AI時代、UIを「サッと作れる」はAIの強みなので全部捨てろとは言いません。
なぜなら速いことは価値なわけです。しかし早くとも失敗しない方法はあるわけです。

思うに、AIはすでにUXに関しての知識は十分です。
なのでプロンプトに「UXを考えて」と書くより、「棚卸しをしてから実装して」と書くほうがおそらく効きます。

まだ試作段階なので正直なところはわかりませんが、今のところは何だか機能している気がします。

是非使ってみての感想を教えてください。

補遺

多分なんだけどAI手癖問題はUIに限らず汎用的な課題な気がする。
なんでも棚卸しさせることが重要カモ