制約型デザインによるUIの個別最適化

概要

認知特性についての個人情報を入力し、UIの基本的な設計原則や安全性・アクセシビリティの条件と、人の特性に関する研究知見を参照して、その人に合わせたUIを生成する仕組みを提案した。

人間が守る条件と適用範囲を設計し、その内側で生成AIが具体的な案をつくる「制約型デザイン」の考え方を用いた。カーナビを題材に、感覚・身体特性も含む13種類の架空ペルソナからUIを生成し、別工程で条件への適合を検査するPoCを実装した。

比較では、身体特性による明確な画面構成の変化を一例で確認した一方、多くの生成物に大きな視覚的変化は見られなかった。実際の使いやすさや安全性は未検証だが、生成AIに判断を任せられる範囲と、個別化の余地を狭めていた設計条件を明らかにした。

背景 —— 一つのUIで、どこまでカバーできるか

多くの製品は、できるだけ多くの人が使える共通のUIを設計し、提供する。けれども、情報を一度に把握できる量、注意の向けやすさ、言葉の理解しやすさ、細かな操作のしやすさには個人差がある。共通のUIが多くの人に配慮されていても、その一人に合っているとは限らない。

集団としての評価にも限界がある。たとえば、米国NHTSAが2013年に公表した任意ガイドラインでは、視線に関する各受入基準について、24人中少なくとも21人が満たすことを求めている。全員が同じように使えることを意味する条件ではない。[1]

文字サイズや表示量を変えられる製品であっても、利用者は設定の存在に気づき、自分の使いにくさと結びつけ、適切な調整を選ばなければならない。設定機能が十分に活用されず、合わない状態のまま使われているのではないか。この疑問が出発点だった。

カーナビでは、画面を見ることや操作することが、運転への注意と競合する。[1] UIとの不適合がその負担を増やす可能性があるなら、利用開始時にその人に合う状態を用意することには、使いやすさと安全の両面で検討する価値がある。

生成AIを利用して、個人の情報と設計知識からUIを具体化する工程を試作できるようになった。そこで、一人ずつ人手で画面を設計する負担を減らしながら、個人に合わせたUIを届ける方法を考えた。

※ 設定機能の利用率と、UIとの不適合が事故に与える影響は、本プロジェクトでは検証していない。

提案 —— 個人の情報と、二種類の設計知識をつなぐ

入力するのは、そのユーザーの認知特性についての情報。AIはそれを、あらかじめ整理した二種類の知識と照合する。一つはUIの基本的な設計ルール、もう一つは人の特性に応じた推奨UIにつながる知識である。

これらをもとに、AIが許容される範囲でUIを具体化し、条件への適合を検査する。出力は、その人に合わせたUIと、どこを、なぜ変えたかの説明である。

入力：その人についての情報

たとえば、一度に情報を覚えて扱うことの得意・不得意、ほかの刺激に注意を取られやすいか、どのような説明を理解しやすいか。実装では、見え方や手指の操作特性も対象に含めた。診断名だけで画面を決めるのではなく、UIの利用に関係する個人の情報を扱う。

参照する知識A：UIとして成立するためのルール

一貫性、操作へのフィードバック、情報のまとまり、文字や操作対象の見やすさなど、UIの基本的な設計原則を整理する。さらに、車載UIの操作制限やアクセシビリティ上の条件を、適用する状況とともに定義する。

参照する知識B：特性から推奨UIへつながる知識

研究で示された人の特性を、情報提示の原則へ、さらにUIの設計へ結びつける。たとえば「情報を保持しながら操作することに負担がある」という特徴に対して、「覚えておく必要を減らす」という方向を考え、必要な情報を画面上に残すといった設計へつなぐ。

ただし、特性についての研究が、そのままカーナビの設計値を与えてくれるとは限らない。研究で分かっていることと、そこからこのプロジェクトが導いた設計判断を区別する。 全員に共通して有効な改善は基本ルールに含め、個別化の成果として数えない。

理想のUX —— 最初の乗車で、使いやすさを一緒に確かめる

※ 将来構想。 会話による初期設定は、今回のPoCでは実装していない。

車を買い、初めて運転席に座ったとき。停車した状態で、AIエージェントが使い方について尋ねる。利用者は専門的な設定項目を選ぶ代わりに、普段の困りごとや使いやすいと感じる方法を話す。

1. 初回乗車：会話を始める

   AI「使いやすい画面に合わせるために、普段の使い方をいくつか教えてください。後から始めることもできます。」

   利用者は目的を理解し、始めるか、後にするかを選ぶ。

2. インタビュー：困りごとを話す

   AI「案内が続くとき、どんなところで分かりにくくなりますか？」

   利用者「次の説明が来ると、さっきの内容を忘れてしまうことがあります。」

   AIは具体的な場面を尋ね、情報の保持や注意の向け方に関係する使いにくさを整理する。

3. 理解の確認：AIの受け取り方を直せる

   AI「手順を覚えて進むより、必要な情報が画面に残る方が使いやすそう、という理解で合っていますか？」

   利用者はその理解を確認・訂正する。会話で得た自己申告は、認知機能の測定値や診断とは分けて扱う。測定が必要な項目には、別途確かめる方法を用意する。

4. 提案と試用：理由を聞いて、画面を試す

   AI「覚えておく負担を減らすため、現在の操作と次の手順を確認できる画面を提案します。」

   利用者は停車中に目的地の選択などを試す。「前の方が分かりやすい」「ここは言葉を変えたい」と伝え、必要なら提案を調整したり、元のUIへ戻したりできる。

5. 利用開始：確認したUIを使う

   利用者が確認したUIを初期状態として保存する。走行中は、利用者が覚えた基本構成を維持する。見直したくなったときは、停車中に再調整できる。

会話の目的は、利用者を一度で分類することではない。その人が説明・訂正できるやり取りを通して、使い始めの状態を整えることである。

実装 —— 守る条件と、AIに任せる判断を分ける

今回実装したのは、個人の特性情報を受け取り、UIを生成し、検査・描画・比較するまでの仕組みである。会話での聞き取りを置き換える入力として、特性の異なる13種類の架空ペルソナを定義した。

カーナビは、画面の面積、操作対象の大きさ、表示できる情報量、走行中の操作といった条件を具体的に扱えるため、検証の題材に選んだ。

制約型デザインという進め方

このプロジェクトでいう制約型デザインは、人間が守る条件と適用範囲を設計し、その内側でAIが具体的な解を提案する方法である。

ルールベースのパラメトリックな変更では、入力に対する値や選択肢の対応をあらかじめ定める。今回の構想では、対応をすべて埋める代わりに、許される範囲と判断の根拠を定め、未確定の具体値や表現に生成AIの裁量を残す。実装は、計算で決める部分と生成AIが決める部分を組み合わせた。

研究知見をUIへ落とし込む際は、出典、適用条件、設計判断を記録した。UIと一緒に変更理由を出力することで、「なぜその人に対してその画面になったのか」をたどれるようにした。

生成したUIを、別工程で検査する

UIは、画面要素や配置を持つ構造データとして生成し、そのデータから描画する。数値や構造の条件はコードで、意味の解釈を要する一部の条件はLLMによる別の検査で確認する。自動判定の対象外や、材料が足りず確認できない項目も記録する。

検査が確認するのは、定義した条件への適合である。実際に使いやすいか、安全性が向上するかは、利用者による評価が必要になる。

設計段階で条件の矛盾が見つかった場合には、AIが該当箇所を示し、人間の判断で条件を見直す。生成するたびに、AIが条件を都合よく変更する仕組みにはしない。

UI比較 —— 大きく変わった例と、ほとんど変わらなかった例

比較の基準は、個人の特性を入力せず、共通の既定値でつくったUIである。同じ機能セットに対して、個人の特性を入力したときの出力を比べた。

※ 以下の画像はプロトタイプの出力であり、市販カーナビの改修前後ではない。 ペルソナも実在の利用者を再現したものではなく、特性の影響を確かめるための架空の入力である。

操作対象が大きくなった例

PS-12｜細かなタッチ操作が難しいという身体特性を持つペルソナ

基準となるPS-01と、年齢・認知・感覚特性を揃え、手指の操作特性を変えた。掲載画像では、各操作対象が大きくなり、画面中央に並ぶ項目が7件から4件になっている。下部の固定ボタンは、この件数に含めていない。

共通の既定UI

個人特性を入力して生成したUI

操作対象を大きくすることには、同じ画面で一度に選べる項目が減るという代償がある。機能セットは維持する設計だが、この一枚だけで、後続画面への移動のしやすさまで評価することはできない。

構成がほとんど変わらなかった例

PS-01｜基準として設定したペルソナ

文字の大きさには小さな違いがあるものの、項目数、配置、タッチ領域の大きさはほぼ同じだった。今回のルールと入力の組み合わせでは、共通の既定UIから構成を大きく変える結果にはならなかった。

共通の既定UI

個人特性を入力して生成したUI

結果と考察 —— 生成の自由度は、どこに残ったか

生成AIならではの価値は、十分には示せなかった

作者の目視比較で、画面構成の明確な変化として認識できたのはPS-12だった。ほかの出力には語彙や設定上の差もあったが、画面の見た目から大きな価値の違いを認識するには至らなかった。

PS-12の変更も、表示サイズや表示量を調整する設定で実現しうる範囲だった。自分で設定を探さずに初期状態が整うという体験には可能性がある。一方、その体験の価値と、UIの生成に生成AIが必要であることは別に検証しなければならない。

今回のPoCでは、認知特性に合わせることで操作成績が改善したことや、生成AIがルールベースより優れたUIをつくったことは示していない。

今回つくったデザイン空間は狭かった

文字や操作対象に必要な大きさを確保し、画面面積や表示量の条件を適用すると、選べる構成が限られていった。実装上、計算や固定の構成で決まる部分も多く、AIが複数の妥当な案から選ぶ余地は小さかった。

語彙の言い換えには自由度が残ったが、その違いは画面構成ほど目に見えず、今回の目視評価では価値を十分に捉えられなかった。生成AIの価値を確かめるには、選べる案に幅があり、その違いが利用者の体験に意味を持つことが必要だと考えた。

この結果は、今回集めたルール、採用したUIパラメータ、実装した表現の範囲についての結果である。カーナビ全般や、個別化UI全般の限界とはいえない。

また、JIS・ISO等の関連規格すべての本文を直接確認したわけではなく、論文、公的なガイダンス、公開データ、一部の規格本文やプレビューなど、入手できた資料をもとに設計知識を構成した。参照範囲が、採用できた設計上の選択肢に影響した可能性はある。ただし、規格本文の精査で自由度が広がるのか、追加の条件でさらに限定されるのかは、今後確かめる必要がある。

AIとの作業は、ルール自体の改善につながった

成果が現れたのは、生成に使う条件を設計し、検査可能にする過程でもあった。

AIが問題を指摘し、人間が判断し、設計に反映する。その往復によって、何を共通に守り、どこを個人に合わせられるのかが明確になった。

今後 —— 体験の価値と、生成AIの価値を確かめる

次は、二つの問いを分けて検証したい。

一つは、自分で設定しなくても使い始めのUIが整う体験に、どれだけ価値があるか。会話による聞き取り、理解の訂正、試用までを実装し、入力情報の確かさと、利用者にとっての負担を確かめる。

もう一つは、どのような設計対象なら、生成AIによって得られる案の違いが体験の改善につながるか。必要な条件を保ちながら、情報構成や操作の流れに複数の妥当な案が残る対象へ広げたい。

実ユーザーによる評価では、共通の既定UI、個人情報からルールベースで調整したUI、生成AIで具体化したUIを、同じタスクで比較する。操作時間、誤操作、視線、主観的な負担などから、個人に合わせたことの効果と、生成AIを使ったことの効果を分けて調べる。

また、関連規格の確認を進め、研究で確かめられたことと設計判断の境界を更新する。条件を検査できることに加えて、その内側に、利用者にとって意味のある選択肢を残すことを次の課題とする。