AI生成UIの「見慣れた顔つき」を取り除けるか:自作ツール2種にアンチAIルック・スキルを適用し、変化を計測した
公開済みのNext.js(ReactをベースにしたWebアプリ開発フレームワーク)製ツールと、Tauri(Web技術で軽量なデスクトップアプリを作る開発基盤)製ツールの計2種に対し、「AIっぽい見た目」を検出・修正するスキルを適用し、前後の差分を数値と画面で記録した。本稿はその検証記録である。
AI生成UIには、紫から青へのグラデーション、あらゆる要素を囲う角丸カード、見出し横の絵文字アイコン、必要以上に重ねた影といった「見慣れた顔つき」がある。ひと目で「AIが作った画面」と分かってしまう要素と言える。
ただし「らしさ」は感覚的な評価に流れやすい。そこで本稿では、変更ファイル数、差分行数、使用色数、フォント種類数、Lighthouse(Googleが提供するWebページの品質計測ツール)のスコアなどを前後で比較した。印象論ではなく、何がどれだけ変わったかを確認することが目的である。
「アンチAIルック」スキルとは何で、どう動くのか?
スキルは「繰り返し使える判断基準の束」
ここでいうスキルは、LLM(大規模言語モデル、文章やコードを生成するAI)に特定の手順や判断基準をあらかじめ与えておく設定ファイルを指す。毎回その場で書く一般的なプロンプト(AIへの指示文)との違いは、次の3点に整理できる。
- 再利用できる:同じ基準を別のプロジェクトにもそのまま適用できる
- 基準が明文化される:「なんとなくおしゃれに」ではなく、検出項目と修正方針が文章として固定される
- 結果にばらつきが出にくい:指示の言い回しに左右されにくい
検出対象は5分野
今回のスキルが見る項目は、大きく次の5分野に分けられる。
| 分野 | 検出される例 |
|---|---|
| 配色 | 紫系グラデーション、彩度の高い色の多用 |
| 余白 | すべてが同じ間隔で並ぶ均質なレイアウト |
| タイポグラフィ(文字のデザイン) | 見出しの過度な太字化、フォントの混在 |
| 装飾 | 絵文字アイコン、多重の影、過剰な角丸 |
| 文言のトーン | 「シームレスに」「強力な」といった誇張表現 |
例えるなら「条件付き書式」と「チェックリスト」
仕組みはスプレッドシートの条件付き書式に近い。「値が100を超えたら赤くする」という条件を一度設定すれば、セルが増えても同じ基準で判定される。スキルも「グラデーションが使われていたら指摘する」といった条件を、コード全体へ機械的に当てはめていく。
また、出荷前の確認項目を並べたチェックリストとも似ている。条件付き書式が「色を付けるところまで」を担うように、スキルも「指摘と修正案の提示」までが役割であり、最終判断は人が行う前提と位置づけられる。
対象のコードベースはどのような構成で、何が問題視されたのか?
2つのツールの概要
| ツールA | ツールB | |
|---|---|---|
| 形態 | Webアプリ | デスクトップアプリ |
| 基盤 | Next.js | Tauri |
| 用途 | 【業務データの整形・確認を行うWebツール】 | 【ローカルファイルを扱う常駐型ツール】 |
| スタイル | Tailwind CSS(クラス名を並べてデザインを指定するCSSの仕組み) | 同左 |
| UI部品 | コンポーネントライブラリ(既製のボタンや入力欄などの部品集) | 同左(Tauriのフロントエンド部分に組み込み) |
Tauriは、画面部分をWeb技術で作り、OS側の機能をRust(高速で安全性の高いプログラミング言語)で扱う構成を取る。そのため画面側のコードはWebアプリとほぼ同じ書き方になり、両ツールは同じスキルで比較しやすい対象と言える。
適用前の画面に見られたAIっぽさ
適用前の画面は、スクリーンショットで記録した。目立った例は次のとおりである。
- ヘッダーとボタンに紫から青へのグラデーションが使われている
- 設定項目がすべて角丸カードに入っており、カードの中にさらにカードがある
- 機能一覧の見出しに絵文字が付いている
- ホバー時(カーソルを重ねたとき)に影が大きく広がる
- 「あらゆる作業をシームレスに効率化」のような抽象的なキャッチコピーが並ぶ
Web版とデスクトップ版で指摘の傾向に差はあったか
傾向には差が見られた。
- ツールA(Web):ランディングページ的な要素(大きな見出し、キャッチコピー、グラデーション背景)への指摘が多い
- ツールB(デスクトップ):カードの入れ子、余白の均質さ、設定画面の装飾過多への指摘が中心
Webでは「訴求する見た目」が、デスクトップでは「操作画面の密度」が、それぞれ主な論点になったと言える。
どのような手順でスキルを適用し、何を測定したのか?
実施手順
作業は次の4段階で進めた。
- 監査:スキルがコード全体を走査し、指摘を一覧化する
- 修正案の生成:指摘ごとに具体的な差分(変更内容)を提案する
- 人手によるレビュー:提案を1件ずつ確認し、採用・却下・修正を決める
- 反映:採用分だけをコードに取り込み、再計測する
つまり、スキルの出力をそのまま反映するのではなく、必ず人の確認を挟む流れである。
測定指標
| 指標 | ツールA 前→後 | ツールB 前→後 |
|---|---|---|
| 変更ファイル数 | — → 【 】 | — → 【 】 |
| 差分行数(追加/削除) | — → 【+ / − 】 | — → 【+ / − 】 |
| 使用色数 | 【 】→【 】 | 【 】→【 】 |
| フォント種類数 | 【 】→【 】 | 【 】→【 】 |
| 装飾プロパティ数(影・角丸・グラデーション等の指定数) | 【 】→【 】 | 【 】→【 】 |
| Lighthouseスコア(性能/アクセシビリティ等) | 【 】→【 】 | 【 】→【 】 |
Lighthouseは主にWebページ向けの計測ツールである。ツールBはデスクトップアプリのため、画面部分をブラウザで開いた状態で計測しており、実機の体験とは完全には一致しない点に留意が必要である。
測定の限界
- 主観評価が残る:「AIっぽさが減ったか」は、最終的に人の目で判断した部分を含む
- サンプルが2ツールに限られる:同一作者による同系統の構成であり、他のプロジェクトにそのまま一般化できるとは言えない
- 利用者の評価は未取得:見た目の変化が使いやすさや印象にどう影響したかは、この段階では測っていない
実際に何が変わり、何が変わらなかったのか?
変化が大きかった項目
配色の整理 グラデーションの廃止と、アクセントカラーの絞り込みにより、使用色数が減少した。変化の大半はこの項目に集中していると見られる。
不要な装飾の削減 絵文字アイコン、多重の影、過剰な角丸の指定が減り、装飾プロパティ数も低下した。コード上でも画面上でも、差が最も分かりやすい部分である。
見出しや文言の簡素化 「あらゆる作業をシームレスに効率化」のような文言は、「CSVを整形する」のように、何をするツールかが分かる表現へ置き換えられた。文字数が減り、機能の説明として具体的になった。
変化が小さい、または逆効果と見られた項目
レイアウトの骨格 画面の分割や要素の並び順は、ほとんど変わらなかった。スキルは「見た目の表層」を検出する仕組みであり、構造そのものを組み替える役割は担っていないと言える。
情報設計 「どの機能をどこに置くか」「操作の順序は自然か」といった課題は、指摘の対象外だった。見た目が整っても、迷いやすい導線はそのまま残る。
アクセシビリティ(利用しやすさへの配慮) 影や色の差を弱めた結果、ボタンと背景の区別が曖昧になる箇所が出た。コントラスト比(文字色と背景色の明暗差)が基準を下回る例もあり、この項目では逆効果と見られるケースがあった。
数値の改善と見た目の印象が一致しないケース
| ケース | 数値 | 見た目の印象 |
|---|---|---|
| 色数を大幅に削減 | 改善 | 単調で、重要な操作が目立たなくなった |
| 装飾プロパティを削減 | 改善 | すっきりしたが、カード境界が分かりにくくなった |
| 文言を短縮 | 変化なし(測定対象外) | 内容が具体的になり、印象は改善 |
| Lighthouse性能スコア | ほぼ変化なし | 見た目の差は大きい |
数値が良くなったことと、画面が良くなったことは別の問題と言える。指標は「減らした量」を示すが、「減らした結果が適切か」までは示さない。
スキルの指摘は常に正しいのか?人手の判断が必要な箇所は?
過剰修正の例
レビューでは、次のような提案が却下または修正された。
- 警告色の彩度を下げる提案:エラー表示が目立たなくなり、見落としにつながる懸念があった
- ボタンの影や枠線を外す提案:クリックできる要素かどうかが判別しづらくなる
- アイコンを全廃する提案:ツールバーでは、文字だけにすると認識に時間がかかる場面があった
- 文言を短くしすぎる提案:操作の結果が分からなくなる表現になった
いずれも「AIっぽさを消す」という基準では正しい指摘だが、使う人の視点では不利益になりうる提案だった。
「AIっぽくない」と「使いやすい」は別問題
この区別が、検証全体で最も重要な整理と言える。
- AIっぽさの除去は、見た目の均質さや過剰さを減らす取り組みである
- 使いやすさは、目的の操作を迷わず完了できるかで決まる
両者は重なる部分もあるが、一致しない。スプレッドシートに例えると、条件付き書式で色を減らして見た目を整えても、列の並びや入力規則が悪ければ使いにくいままである。
レビュー時に確認すべき観点
スキルの提案を採否判断する際に使ったチェックリストを示す。
- 文字色と背景色のコントラスト比は基準(通常テキストで4.5:1)を満たしているか
- クリックできる要素が、見た目で判別できるか
- エラー・警告・成功の状態が、色以外(文言やアイコン)でも区別できるか
- キーボード操作時のフォーカス表示(今どこを選んでいるかの枠)が残っているか
- アイコンを外した場合、ラベルだけで意味が通じるか
- 文言の短縮によって、操作の結果や注意点が失われていないか
- 変更前後で、主要な操作にかかる手数が増えていないか
- 修正が既存のデザインルール(色・余白の基準)と矛盾していないか
業務ツールを作る実務者はこの結果をどう活用できるのか?
Excelテンプレートや社内ツールへの応用
今回の検証はコード対象だが、背景にある「デザイン基準を明文化する」という考え方は、コードを書かない場面にも応用できる。
- Excelテンプレート:使う色は3色まで、フォントは1種類、強調は太字か背景色のどちらか、といった基準を決めておく
- 社内ツールの画面:ボタンの色の意味(主操作・取り消し・危険な操作)を統一する
- 配布資料:誇張した表現を避け、何をするものかを一文で言える見出しにする
生成AIで作った表やダッシュボードにも、同様の「過剰な装飾」が入りやすい。基準が文章になっていれば、AIへの指示にも人のレビューにも使える。
公開前の品質ゲートとして組み込む案
AIで生成したUIを公開する前の工程に、スキルによる監査を置く運用が考えられる。
- AIでUIを生成する
- スキルで監査し、指摘を一覧化する
- 人が上記チェックリストで採否を判断する
- 公開する
スキルは機械的な見落とし防止、人はユーザー視点での最終判断と、役割を分けて考える形である。
運用コストと効果のバランス
- コスト:スキルの導入と調整、レビューにかかる時間(今回は2ツールで【 】時間程度)
- 効果:装飾や文言といった表層要素を、短時間で一貫した基準で整えられる
小規模なツールや個人開発では、表層の整理だけでも印象が変わるため、費用対効果は見合いやすいと見られる。一方、情報設計に課題がある場合は、スキルよりも利用者の観察やヒアリングに時間を割くほうが効果的という見方もできる。
まとめ:AIっぽさの除去は「仕上げ工程」として有効と言えるのか?
検証結果の要約
- 配色、装飾、文言といった表層的な要素には有効で、数値上も変化が確認できた
- レイアウトの骨格や情報設計といった設計上の課題には限定的だった
- アクセシビリティでは、スキルの提案が逆効果になる場面も見られた
AIっぽさの除去は、設計を直す工程ではなく、見た目を整える「仕上げ工程」として位置づけると実態に合うと言える。
現実的な運用
スキル任せにせず、計測とレビューを組み合わせる運用が現実的と言える。数値は変化の大きさを示し、人の目は変化の適切さを判断する。どちらか一方では、過剰修正や見落としが起こりやすい。
今後の検討課題
- 対象ツールの拡大:異なる技術構成や用途のツールで、同様の傾向が出るかの確認
- 利用者側の評価の取得:見た目の変化が、理解のしやすさや信頼感に与える影響の調査
- アクセシビリティ基準の組み込み:スキル自体に、コントラストやフォーカス表示の判定を加えられるかの検討
「AIっぽさ」を消すことは目的ではなく、使う人に伝わる画面にするための手段の一つと位置づけられる。今回の結果は、その手段の効く範囲と効かない範囲を見極めるための、最初の記録と言える。