視線追跡とUIデザイン｜利用者の視線データを設計改善へつなげる実践ガイド

視線追跡は、利用者が画面のどこを見たか、どの順番で見たか、特定の領域へ到達するまでにどれほど時間がかかったかを記録する調査方法です。利用者が口頭では「すぐにボタンを見つけた」と答えていても、実際には複数の領域を行き来した後で発見している場合があります。反対に、画面上の重要なメッセージを視線が通過していても、利用者が内容を理解していないこともあります。視線追跡は、自己申告だけでは捉えにくい探索過程を可視化できる一方、視線だけから意図や理解を断定できないという限界を持っています。

UIデザインに視線追跡を取り入れる目的は、赤く表示された視線密度図を作り、注目を集めた場所を示すことではありません。利用者が目的の情報へどのように到達したか、どの部分で探索が停滞したか、視覚的な優先順位が操作目的と一致していたかを、仮説とタスクに基づいて検証することが重要です。視線が集まった場所は魅力的だった可能性もありますが、分かりにくくて何度も確認された可能性もあります。そのため、クリック、入力、完了時間、誤操作、発話、事後インタビューなどの情報と組み合わせなければ、改善理由を正確に説明できません。

また、視線追跡には、デザイン評価のために視線を記録する用途と、視線そのものをポインターとして利用する視線入力の用途があります。両者は同じ技術を使うことがありますが、デザイナーの責任は大きく異なります。調査では測定条件や解釈の妥当性が重視され、視線入力では誤作動、選択確認、代替操作、疲労、アクセシビリティが重視されます。本記事では、この二つを混同せず、UI調査と操作設計の双方から視線追跡を解説します。

1. 視線追跡がUI設計で明らかにできること

視線追跡は、利用者の内面を直接読み取る技術ではなく、画面上における視線位置と時間変化を観測する方法です。デザイナーは、記録できるものと推測にとどまるものを分けたうえで、UI上の探索、発見、比較、迷いを分析する必要があります。

1.1 視線位置から観測できる行動

視線追跡によって直接観測できるのは、ある時点における推定視線位置、特定領域への滞在、視線の移動順序、まばたきや瞳孔径など、機器が取得可能な信号です。一般的な分析では、視線が比較的安定している区間を注視、注視点の間を高速に移動する眼球運動を跳躍運動として扱います。ただし、注視と跳躍運動を区別する方法には複数の判定方式があり、速度などのしきい値によって分類結果が変化します。したがって、異なる調査結果を比較するときは、機器だけでなく判定方式も確認しなければなりません。

UI調査では、この時系列データを画面要素と関連付けます。例えば、購入ボタンへ視線が到達するまでの時間、価格と送料を行き来した回数、入力エラー表示へ視線が到達した割合などを確認できます。視線位置の記録だけを大量に集めるのではなく、研究目的に対応した画面領域を事前に定義することで、デザイン上の問いへ答えやすいデータになります。

1.2 発見可能性を評価する

重要な操作部品が存在していても、利用者が必要なタイミングで見つけられなければ、UI上では実質的に利用できません。視線追跡では、目的の要素へ最初に到達するまでの時間、到達した参加者の割合、到達前に確認した領域などを分析できます。これにより、「ボタンが小さい」「色が弱い」といった印象論ではなく、探索過程と発見の遅れを具体的に確認できます。

ただし、視線が到達しない理由を、要素の目立ち方だけに限定してはいけません。利用者が別の場所に同じ機能があると予測していた、タスクの意味を理解していなかった、画面上部の情報だけで判断を終えたなど、複数の理由が考えられます。視線記録を操作映像やインタビューと組み合わせ、どの期待が実際の配置と食い違っていたのかを調べる必要があります。

1.3 情報を読む順序を確認する

画面上の要素は、制作側が想定した順序で読まれるとは限りません。デザイナーが見出し、説明、料金、行動ボタンの順番で理解してほしいと考えていても、利用者は最初に価格を確認し、その後で条件を読み、最後に見出しへ戻る場合があります。視線軌跡を確認すると、どの情報が入口となり、どの情報同士が比較され、どこで読み戻しが発生したかを把握できます。

読み順が想定と異なること自体は、必ずしも問題ではありません。利用者の目的に合った効率的な読み方であれば、制作側の想定を変更すべき場合もあります。問題となるのは、重要な前提条件を読まずに危険な操作へ進む、料金と契約期間の関係を理解できずに往復するなど、読み順が誤解や失敗へつながっている場合です。

1.4 比較行動と迷いを観察する

料金プラン、商品一覧、設定画面などでは、利用者が複数の要素を比較します。視線が二つの領域を何度も往復している場合、慎重に比較している可能性もあれば、情報の対応関係が分かりにくい可能性もあります。行き来の回数だけでは理由を決められませんが、比較対象と操作結果を合わせることで、どこで判断負荷が高まったかを推測できます。

例えば、機能名と料金を交互に確認した後で誤ったプランを選択している場合、列見出しの固定、情報の近接配置、差分表示の改善が必要かもしれません。一方、複数の候補を往復した後で正しく選択し、本人も比較しやすかったと評価しているなら、その往復は必要な比較行動です。視線の複雑さを自動的に悪いUIの証拠として扱わないことが重要です。

1.5 見ていることと理解していることを分ける

視線がある要素へ向いていても、利用者がその内容へ意識を集中させ、意味を理解しているとは限りません。近年の研究でも、視線が対象へ向いていることと、注意が維持されていることを同一視できない問題が扱われています。周辺視野で情報を認識する場合や、対象を見ながら別のことを考えている場合もあるため、視線位置を注意や理解の完全な代替指標として使うことはできません。

デザイナーは、「注視されたから理解された」「注視されなかったから存在に気付かなかった」という単純な結論を避けます。理解を確認したい場合は、内容の説明、選択理由、記憶、操作結果などを追加で調べます。視線追跡は、質問すべき場所を発見するための手掛かりであり、利用者の思考内容を自動的に確定する装置ではありません。

2. 視線追跡と通常のユーザビリティ調査の違い

視線追跡と通常のユーザビリティ調査は競合する方法ではなく、異なる種類の証拠を提供する方法です。視線追跡は探索過程を細かく記録できますが、利用者がなぜそのように行動したのかを直接説明できないため、他の調査方法との役割分担が重要になります。

2.1 発話データとの違い

ユーザビリティテストにおける発話は、利用者が認識している問題、期待、判断理由を言葉として取得できます。しかし、人は自分の視覚探索を完全に把握しているわけではなく、後から合理的な理由を作る場合もあります。視線追跡は、本人が説明しなかった探索や見落としを観測できますが、その視線が何を意味していたかは自動的に分かりません。

両者を組み合わせる際には、調査中の発話が視線行動を変える可能性にも注意します。複雑な読み取り課題で常に考えを話してもらうと、通常よりゆっくり画面を見たり、発話のために視線を止めたりすることがあります。自然な探索を優先する場合は、タスク後に録画を見ながら振り返ってもらう方法も検討します。

2.2 クリック分析との違い

クリック分析は、利用者が最終的に選択した場所や、誤ってクリックした場所を大量に収集できます。視線追跡は、クリックに至る前の探索や、見たものの選択しなかった要素を確認できます。クリックされなかった要素についても、認識されたが選ばれなかったのか、そもそも発見されなかったのかを調べる手掛かりになります。

一方、視線が集まっていてもクリックされないことには多くの理由があります。操作部品だと認識されなかった、内容を読んだ結果不要だと判断した、選択条件を満たしていなかったなどです。クリック分析と視線分析を同じ参加者単位で重ねると、発見、検討、実行のどの段階に問題があるかを区別しやすくなります。

2.3 アクセス解析との違い

アクセス解析は、ページ移動、離脱、完了率、滞在時間、利用端末などを大規模に確認できます。視線追跡は、少数の参加者について、画面内でどの情報を見ながら行動したかを細かく確認します。アクセス解析で特定画面の離脱率が高いと分かっても、原因となる要素は特定できないことがあります。その原因候補を調査する方法として視線追跡を利用できます。

反対に、少数の視線追跡参加者で見つかった問題が、実際の利用者全体へどの程度影響しているかは分かりません。視線追跡で仮説を作り、アクセス解析や実験で規模を確認する流れが有効です。両者を混ぜて「多くの利用者が見ていない」と断定せず、調査対象と母集団の違いを明確にします。

2.4 アンケートとの違い

アンケートは、満足度、理解度の自己評価、好み、利用意向などを効率的に集められます。しかし、「見つけやすかった」と回答していても、実際には長時間探索している場合があります。利用者が感じた体験と、観測された行動は異なる側面を表すため、一方を正解として扱うべきではありません。

視線追跡で探索が長かったにもかかわらず満足度が高い場合、その探索が楽しい比較体験だった可能性があります。反対に、素早く目的へ到達していても、デザインに不信感を持っている場合があります。行動効率と主観評価を分けて計測することで、速度だけを改善して体験価値を損なう判断を防げます。

2.5 予測型の注目図との違い

画像解析や学習済みモデルによる予測型の注目図は、実際の参加者を集めず、画面の視覚的な特徴から注目されやすい位置を推定します。初期案の比較や、極端に目立つ要素の確認には使える場合がありますが、実際の利用者の目的、知識、タスク、操作履歴をそのまま表すものではありません。予測結果は、特定条件に基づく仮説として扱う必要があります。

実測の視線追跡でも万能ではありませんが、参加者が実際にタスクを行った際の視線を記録できます。予測型の図と実測データを同じ名称で扱うと、証拠の性質を誤解させます。報告書では、「実参加者の視線データ」「視覚的特徴に基づく予測」のどちらであるかを明記します。

3. 視線データを正しく読むための指標

視線追跡では多くの指標を算出できますが、数値が多いほど良い分析になるわけではありません。調査目的に対応する指標を事前に選び、数値が増減したときにどのような解釈候補があるかを定めておく必要があります。

3.1 注視回数

注視回数は、特定の関心領域で注視が何回発生したかを示します。回数が多い場合、その領域が繰り返し確認された、重要な情報が存在した、内容の理解が難しかったなど複数の可能性があります。単純に回数が多い領域を「人気がある」と判断することはできません。

UI改善では、注視回数をタスク成功や発話と組み合わせます。例えばエラー説明の注視回数が多く、その後も修正に失敗しているなら、文章が理解しにくい可能性があります。注視回数が多くてもすぐ修正できているなら、必要な確認行動として機能している場合があります。

3.2 注視時間

注視時間は、一回の注視の長さや、関心領域内での注視時間の合計として分析されます。長い注視は、情報を丁寧に読んでいる、理解に時間がかかっている、判断が難しいなどの可能性を示します。瞳孔径や注視時間などは認知負荷研究でも利用されますが、単一の指標だけで負荷を断定することはできません。

文章量が異なる領域を比較する場合、合計注視時間だけでは公平ではありません。長い文章は自然に注視時間が長くなるため、文字数、表示時間、タスク上の必要性を考慮します。改善前後を比較する場合も、文言や情報量が変わったことを分析条件へ含めます。

3.3 初回注視到達時間

初回注視到達時間は、画面やタスクが始まってから、対象領域へ最初に注視が到達するまでの時間です。重要な通知、主要操作、価格、検索欄などの発見可能性を検証する際に利用できます。短いほど常に良いわけではなく、利用者が最初に読むべき内容に応じて評価します。

例えば危険な削除ボタンへ最初に視線が集中するUIは、目立ちやすくても適切とは限りません。利用者が説明を確認してから操作へ進む必要がある場合は、情報の順序を含めて評価します。目標は最短時間ではなく、目的に合ったタイミングで必要情報が発見されることです。

3.4 滞在注視時間

滞在注視時間は、利用者が関心領域へ最初に入ってから外へ出るまで、または複数回の訪問を含めた総滞在として計算されます。料金カード、商品画像、入力説明などにどれほど視覚的な処理時間が使われたかを把握できます。ただし、計算定義が調査ツールによって異なる場合があるため、報告書には集計方法を記載します。

滞在が長い領域は関心が高い場合も、理解しにくい場合もあります。視線軌跡で領域内の読み方を確認し、操作結果や質問への回答と組み合わせます。タイトルだけを繰り返し見ているのか、説明文を順に読んでいるのかによって、同じ滞在時間でも意味が異なります。

3.5 再訪と視線移動

一度離れた領域へ戻る再訪は、比較、確認、記憶の補完、迷いなどを示す手掛かりになります。価格と機能、入力欄と説明、商品名と画像など、どの領域間で再訪が起きているかを分析すると、情報の依存関係を理解できます。

再訪が多い場合、関連情報を近くへ配置する、列見出しを固定する、選択中の内容を保持するなどの改善候補があります。しかし、比較画面では再訪そのものが必要な行動です。再訪をゼロにすることではなく、不要な記憶負担や位置探索を減らすことを目標にします。

4. 調査目的と仮説を先に設計する

視線追跡は取得できるデータ量が多いため、目的を決めずに実施すると、後から都合のよい特徴を探す分析になりやすくなります。調査前にUI上の問い、比較条件、成功基準、利用する指標を定義する必要があります。

4.1 UI上の問いを具体化する

「この画面は見やすいか」という問いは広すぎるため、どの視線データを見れば答えられるか決まりません。「初回利用者は送料情報を確認してから購入へ進めるか」「エラー後に修正方法を見つけられるか」のように、利用者、情報、行動を含む問いへ変換します。

具体的な問いがあれば、関心領域、タスク、事後質問を設計できます。送料情報を調べる場合は、送料領域への到達、購入ボタンとの視線順序、内容理解を確認します。単なる注目度ではなく、意思決定に必要な情報が適切に使われたかを評価できます。

4.2 検証可能な仮説を作る

仮説は「新しいデザインの方が良い」のような抽象的な文章ではなく、観測可能な差として記載します。「見出しの変更によって、料金説明への初回注視到達時間が短くなる」「入力例を欄外へ表示することで、説明と入力欄の往復が減る」といった形です。

ただし、一つの指標だけで仮説を判断しないようにします。到達時間が短くなっても、誤った選択が増える可能性があります。主要指標と補助指標を設定し、効率、正確さ、主観評価を組み合わせます。

4.3 タスクを現実的にする

「このボタンを見つけて押してください」と指示すると、参加者はボタンを探すことに集中し、実際の利用状況と異なる視線になります。現実的な目的を提示し、「来週到着する方法で商品を購入してください」のように、必要情報を自分で探索してもらいます。

一方、タスクが広すぎると、参加者ごとに目的が異なり、視線データを比較しにくくなります。自由度と比較可能性のバランスを取り、必要な背景情報を統一します。実利用に近い判断を残しながら、調査対象となる機能へ到達できるタスクを作成します。

4.4 成功条件を複数用意する

タスク完了だけを成功条件にすると、長時間迷った末に偶然完了した参加者と、迷わず完了した参加者を同じ成功として扱ってしまいます。完了、正確さ、時間、誤操作、重要情報の確認、主観的な確信など、複数の条件を設定します。

視線指標も成功条件の一部として利用できますが、視線だけを最終目標にしないことが重要です。目的のボタンを早く見つけても、誤った契約を選んでいれば成功ではありません。製品上の成果と視覚探索を結び付けます。

4.5 分析計画を調査前に作る

調査後に関心領域を自由に変更し、都合のよい指標だけを選ぶと、偶然の差を重要な結果として扱う危険があります。主要な関心領域、除外条件、指標、比較方法を事前に記載します。

探索的な分析を行うこと自体は問題ではありませんが、事前仮説の検証と、後から見つけた傾向を区別します。報告書でも、確定的な結果と次回検証すべき仮説を分け、デザイン判断の確実性を正しく伝えます。

5. 参加者・環境・機器を適切に設計する

視線データは、UIだけでなく、参加者の視力、眼鏡、姿勢、照明、画面サイズ、較正状態、機器性能などの影響を受けます。調査条件を記録し、取得できなかったデータを無理に補完しない姿勢が必要です。

5.1 対象利用者を募集する

視線追跡機器で安定して計測できる人だけを集めると、製品の実際の利用者構成と異なる可能性があります。年齢、経験、視覚特性、利用端末など、製品上重要な条件を優先して募集します。

特定参加者の計測が困難だった場合、その事実自体が製品や調査方法の包摂性に関する情報になります。取得率だけを高めるために参加者を除外するのではなく、誰のデータが欠落したかを報告します。

5.2 眼鏡やコンタクトレンズを考慮する

眼鏡の反射、レンズ形状、まつ毛、アイメイク、瞳の特徴などは、機器によって計測品質へ影響する場合があります。参加者へ普段と異なる状態を強制すると、自然な利用条件から離れるため、使用機器の対応範囲を事前に確認します。

計測できない参加者が出ることを想定し、通常のユーザビリティテストへ切り替えられる手順を用意します。視線データが取れなくても、操作、発話、完了結果から重要な洞察を取得できるようにします。

5.3 較正を参加者ごとに行う

視線追跡では、眼球の特徴と画面上の位置を対応付ける較正が必要です。Webカメラ型の推定でも、画面上の複数点を見たりクリックしたりする較正が利用されます。WebGazerの関連資料でも、9点較正を用いて精度を評価する例が示されています。

較正が完了したかだけでなく、画面全体で誤差が許容範囲にあるかを確認します。中央では正確でも端でずれる場合があるため、重要な操作が配置される領域を含めて検証します。セッション中に姿勢が変わった場合は、再較正が必要になることもあります。

5.4 調査環境を記録する

照明、画面の反射、カメラ位置、参加者との距離、椅子の高さなどは、計測品質へ影響します。比較調査では、可能な限り条件を統一し、異なる条件で行った場合は記録します。

遠隔調査では、利用者ごとにカメラや照明が異なるため、研究室型より精度のばらつきが大きくなります。大まかな画面領域の比較に向くのか、小さなアイコン単位の評価が必要なのかを考え、機器の精度と研究課題を一致させます。

5.5 データ品質の除外条件を決める

視線が取得できた割合、較正誤差、瞬間的な欠測、頭部移動などを確認し、分析へ含める条件を事前に決めます。結果を良く見せるために、デザイン仮説と合わない参加者だけを除外してはいけません。

除外した人数と理由を報告し、除外によって参加者属性が偏っていないかを確認します。例えば眼鏡利用者の多くが除外された場合、分析結果は眼鏡を使わない参加者を強く反映する可能性があります。

6. UI要素と注視の関係を分析する

視線が集まりやすい要素には、文字、画像、顔、動き、強いコントラストなどさまざまな特徴があります。しかし、注視を集めることと、製品目的を達成することは同じではありません。必要な情報へ適切な順序で注意を導く設計が求められます。

6.1 見出しの役割を評価する

見出しは、内容を要約し、利用者が読むべき領域を選ぶための入口になります。見出しを飛ばして本文へ直接視線が移る場合、見出しが抽象的すぎる、本文の数字や画像が強すぎるなどの可能性があります。

見出しへの注視を増やすこと自体を目標にせず、見出しが内容選択を助けているかを確認します。見出しを読まずに必要情報へ到達できる構造が適切な場合もあります。見出しを読んだ参加者と読まなかった参加者で、理解や選択結果が異なるかを分析します。

6.2 行動ボタンの発見可能性を評価する

主要な行動ボタンは、必要な情報を確認した後で発見できる必要があります。画面表示直後にボタンだけへ視線が集中すると、説明や条件を読まずに操作される危険があります。反対に、内容を理解した後もボタンが見つからなければ、完了を妨げます。

ボタンの位置、文言、余白、周囲の要素とのコントラストを分析し、視覚的な優先順位を調整します。色だけを強くするのではなく、ボタンがどの内容に対応しているかを近接配置やグループ化で示します。

6.3 アイコンの理解可能性を評価する

アイコンへ視線が到達していても、意味が理解されているとは限りません。参加者がアイコンを長く見た後で別の操作を選んだ場合、発見はできたものの意味が伝わらなかった可能性があります。

アイコン単独と、文字ラベルを併記した案を比較し、視線だけでなく選択の正確さを確認します。一般的に見える記号でも、製品分野や利用者経験によって解釈が異なるため、社内担当者の理解だけで判断しません。

6.4 画像と装飾の影響を確認する

大きな画像や強い装飾は視線を引き付けますが、重要な操作や説明から視線を奪う場合があります。視線密度図で画像が赤くなっていることを成功と判断せず、その後の操作へ役立ったかを確認します。

画像を見た参加者が商品理解や選択を改善しているなら、視線誘導が価値を生んでいます。画像を長く見ても内容を説明できず、主要情報を見落としている場合は、サイズ、配置、装飾強度を見直します。

6.5 広告と主要内容の競合を確認する

広告、キャンペーン表示、追加提案などが主要タスクより強く注視されると、短期的なクリックは増えても、利用者の目的達成を妨げる可能性があります。特に入力や決済の途中で強い視覚刺激を配置すると、作業文脈が中断されます。

視線追跡では、広告を見たかだけでなく、その後に元のタスクへ戻れたか、完了時間や誤操作が増えたかを確認します。ビジネス指標と利用者タスクの両方を評価し、注意を奪うことを成果として扱わないことが重要です。

7. 情報階層とレイアウトを改善する

レイアウトは要素を美しく並べるだけでなく、どこから読み始め、どの情報を関連付け、どの順序で判断するかを支える構造です。視線の順序と再訪から、視覚階層が利用目的に合っているかを検証できます。

7.1 視覚的な入口を確認する

画面へ入った直後にどの領域へ視線が向くかは、画像、見出し、余白、位置、以前の利用経験などに影響されます。最初の注視点だけで全体を判断せず、数秒間の探索順序を確認します。

利用者が最初に見るべき領域は画面の目的によって異なります。警告画面では危険内容、検索結果では検索条件や結果概要、決済では金額と確定操作など、タスクに合った入口を設計します。

7.2 関連情報を近接させる

利用者が二つの情報を頻繁に往復している場合、視覚的に離れすぎている可能性があります。入力欄と説明、商品名と価格、プラン名と対象者など、判断時に同時確認する情報を近くへ配置します。

ただし、近づけるだけで情報量が過密になる場合があります。余白、境界線、見出しを用いてグループを明確にし、関連性と読みやすさを両立させます。視線移動距離だけでなく、選択精度と主観評価も確認します。

7.3 列と行の対応関係を明確にする

比較表や一覧では、利用者が現在どの列や行を見ているかを保持できなければ、情報を誤って対応付ける可能性があります。横幅が広い表では、列見出しと値の間を何度も往復する視線が見られることがあります。

見出しの固定、行の区切り、項目名の繰り返し、重要差分の強調などを検討します。背景色だけに依存せず、拡大表示や白黒表示でも対応関係を追える構造にします。

7.4 空白領域を機能として扱う

余白は空いている場所ではなく、グループの境界と情報優先度を伝える要素です。余白が不足すると、別の機能が一つの塊として認識され、視線が必要な領域へ入りにくくなる場合があります。

一方、余白が広すぎると、関連情報が別のセクションと認識され、画面移動が増える可能性があります。視線のまとまりと操作結果を確認しながら、内容単位が自然に認識される間隔を設計します。

7.5 長いページの視線変化を確認する

ページ上部と下部では、利用者の目的や注意状態が変化します。上部だけの視線密度図を見て全ページの設計を判断せず、スクロール位置と時間を同期させて分析します。

下部の重要情報が見られない場合、位置だけでなく、上部で目的を達成した、途中で離脱理由が生じた、下へ続く手掛かりが不足したなどの可能性があります。スクロール記録、操作結果、終了理由を組み合わせます。

8. ナビゲーション・検索・フォームを検証する

ナビゲーション、検索、フォームは、利用者が目的へ到達するための中核的なUIです。視線追跡を使うと、候補の探索、入力説明の確認、エラー修正など、完了結果だけでは見えない過程を分析できます。

8.1 ナビゲーション項目の予測可能性を確認する

利用者が目的の項目を探して複数のナビゲーションラベルを行き来する場合、分類や文言が期待と合っていない可能性があります。視線が項目へ到達しても選択されない場合は、意味が曖昧、候補同士が似ているなどの問題を調べます。

ナビゲーションの改善では、視線だけでなく、最初に選んだ項目、戻る操作、最終到達先を確認します。目的項目が注視されていても、別項目を選択しているなら、ラベルの理解に問題がある可能性があります。

8.2 検索欄の発見と利用を分析する

検索が主要な利用方法である製品では、検索欄が必要なタイミングで発見されるかを確認します。ただし、検索欄への到達が遅いことが必ずしも問題とは限らず、利用者がナビゲーションで目的へ到達できている場合もあります。

検索候補が表示される場合は、入力欄、候補、結果数、補足説明の視線順序を確認します。候補へ視線が移動しても選択されない場合は、文言、強調、キーボード操作、候補の関連性を調べます。

8.3 入力ラベルと説明の利用を確認する

入力エラーが多い項目では、説明が見られていないのか、見ても理解できないのかを区別します。説明へ視線が到達しない場合は配置や表示タイミング、到達しても失敗する場合は文章や入力形式を改善します。

入力中に説明が消えるプレースホルダー形式では、利用者が値と条件を再確認できません。視線の戻り先が存在せず、入力削除や試行錯誤が増えている場合は、常時表示ラベルと説明を用意します。

8.4 エラー修正の流れを分析する

エラー表示後に、利用者がエラー概要、対象入力欄、修正説明、送信ボタンをどの順序で見るかを確認します。エラー文へ到達せず入力欄だけを変更している場合、問題の原因を推測している可能性があります。

エラー文を長く見ても修正できない場合は、専門用語、否定表現、抽象的な説明を見直します。視線がエラーと入力欄を往復する回数だけでなく、修正成功と再送信結果を評価します。

8.5 完了画面の理解を確認する

送信や購入の完了後、利用者は処理が成功したか、次に何をすべきかを確認します。完了メッセージよりも広告や別のボタンへ視線が集中すると、結果を認識できないまま次の操作へ進む可能性があります。

完了状態、受付番号、次の手続き、戻る方法を明確な順序で配置します。視線が集まることだけでなく、参加者が処理結果を正しく説明できるかを確認します。

9. モバイル・応答型画面・動的UIを検証する

画面サイズ、端末の持ち方、スクロール、表示変化は視線行動へ大きく影響します。デスクトップで得た視線結果を、そのままモバイルUIへ適用することはできません。

9.1 端末ごとに関心領域を作り直す

応答型画面では、同じ要素でも位置、幅、表示順序が変わります。デスクトップ用の座標をモバイルデータへ適用すると、異なる要素を同じ領域として集計する危険があります。

関心領域は意味単位で管理しつつ、端末ごとの画面位置へ対応付けます。固定座標だけでなく、要素識別子や表示状態を記録できる仕組みを検討します。

9.2 スクロールと視線位置を同期する

スクロール中は、画面上の座標と文書内の要素位置が変化します。視線座標だけを保存すると、どの内容を見ていたかを正確に復元できません。

スクロール位置、画面サイズ、要素の境界情報を同時に記録します。固定ヘッダーや追従ボタンがある場合も、その表示領域を考慮して分析します。

9.3 展開・折りたたみ状態を記録する

アコーディオンやメニューが開閉されると、同じ画面座標に異なる内容が表示されます。視線データだけでは、どの状態を見ていたか判断できません。

開閉時刻、選択状態、表示された内容を出来事として保存し、視線と同期します。状態を無視した視線密度図は、異なる画面を重ね合わせた誤解しやすい結果になります。

9.4 動画とアニメーションを時間軸で分析する

動く要素は視線を引き付けやすいため、静止画の視線密度図だけでは影響を評価できません。どの時点で何が表示され、視線がどのように移動したかを動画として確認します。

アニメーションへ視線が集まっても、内容理解や操作に役立っていなければ、不要な注意の奪取になっている可能性があります。動きを減らした案と比較し、主要タスクへの影響を調べます。

9.5 表示速度の影響を分ける

要素の読み込みが遅いと、利用者は先に表示された領域を見るため、視線順序がデザイン意図ではなく読み込み順序によって決まることがあります。画像やボタンの遅延表示が視線移動を引き起こしていないか確認します。

比較調査では、表示速度を可能な限りそろえます。実際の速度差を評価対象にする場合は、読み込み出来事と視線を同期し、レイアウトと性能の影響を分けて解釈します。

10. 視線入力UIと誤作動を防ぐ設計

視線入力では、見ることがポインター移動や選択へつながります。しかし、人は情報を確認するためにも視線を向けるため、意図的な命令と通常の観察を区別しなければなりません。

10.1 ミダスタッチ問題を理解する

視線入力では、利用者が単に見ただけの要素が選択される問題を、ミダスタッチ問題と呼びます。視線は知覚のために常に移動するため、視線位置をそのままクリックへ変換すると、意図しない操作が大量に発生します。この問題は視線操作研究で長く扱われ、滞在時間や入力方式の切り替えなど複数の対策が提案されています。

デザイナーは、注視された瞬間に破壊的操作を実行してはいけません。視線で対象を指し、スイッチ、音声、まばたき、別の確認領域などで確定する方法を検討します。操作速度だけでなく、誤作動の影響と取り消しやすさを重視します。

10.2 滞在時間による選択を設計する

一定時間対象を見続けることで選択する滞在方式は、追加機器を必要としない利点があります。しかし、時間が短いと誤作動が増え、長いと操作速度が低下し、待ち時間による疲労が発生します。

一律の滞在時間をすべての操作へ適用せず、重要度や頻度に応じて調整します。選択までの進行を円や枠で表示し、完了前に視線を外せばキャンセルできるようにします。

10.3 選択と実行を分ける

視線で項目を選択状態にし、別の確定操作で実行する二段階方式は、誤操作を減らせます。特に削除、購入、送信など結果が大きい操作では、視線だけで即時実行しない設計が必要です。

ただし、すべてを二段階にすると操作数が増えます。文字入力や頻繁な選択では効率が重要になるため、取り消し可能な低危険操作と、確認が必要な高危険操作を分けます。

10.4 視線対象を十分に大きくする

視線推定には誤差があり、隣接する小さな操作部品を正確に選びにくい場合があります。Webカメラ型は専用機器より環境差の影響を受けやすく、WebGazerの初期研究も一般的な視線位置の近似を目的としていました。

操作対象の間隔を広げ、誤差を吸収する領域を設けます。小さな閉じるアイコンや密集した文字リンクを視線入力の主要操作にせず、大きな選択領域と明確なフィードバックを用意します。

10.5 取り消しと回復を容易にする

視線入力では誤選択を完全に防ぐことは困難であるため、取り消しや前の状態へ戻る操作が重要です。誤操作のたびに複雑な確認画面を通る設計では、利用者の負担が増えます。

直前の操作を取り消す領域、一定時間内の取り消し、変更履歴などを提供します。取り消し操作自体も視線で誤作動しないよう、位置、滞在時間、確認方法を慎重に設計します。

11. アクセシビリティと代替入力を守る

視線入力は、手を使いにくい利用者にとって重要な操作手段になり得ます。一方で、眼球運動や視線維持が難しい利用者もいるため、視線操作だけに依存しない設計が必要です。

11.1 視線入力を唯一の方法にしない

2026年3月公開のWCAG 3.0草案には、機能を視線追跡だけに依存させず、視線を利用できない人のための代替操作を提供する開発中の要求が含まれています。ただし、WCAG 3.0は完成した勧告ではなく、草案として扱う必要があります。

視線、スイッチ、キーボード、タッチ、音声など、利用者が自分に合った入力方法を選べる構造を検討します。視線入力を導入することで、既存のキーボード操作や画面読み上げ操作を壊してはいけません。

11.2 ドラッグ操作へ代替手段を用意する

視線ポインターで押下状態を維持しながら対象を移動する操作は、負担が大きく誤差も生じやすくなります。WCAG 2.2のドラッグ操作に関する解説でも、視線ポインターなどではドラッグが困難で誤りやすいことが示されています。

並べ替えには「上へ移動」「下へ移動」ボタン、スライダーには数値入力、地図には拡大縮小ボタンを提供します。ドラッグが便利な利用者には残しながら、単純な選択で同じ結果を達成できるようにします。

11.3 経路を要求するジェスチャーを避ける

特定の形や方向へポインターを動かす操作は、視線入力で正確に行いにくい場合があります。WCAGのポインタージェスチャーに関する解説でも、視線システムなどでは複数点や経路に依存する操作が難しいため、単純なポインター操作の代替が求められています。

スワイプだけでページを切り替えるのではなく、前後ボタンを用意します。形を描く認証や複雑な軌跡操作を唯一の方法にせず、単一の選択で実行できる方法を提供します。

11.4 視線維持が難しい利用者を考慮する

眼振、疲労、視野特性、注意状態などによって、特定位置を長時間見続けることが難しい利用者がいます。長い滞在時間を要求すると、誤操作を減らせても利用不能になる可能性があります。

滞在時間を調整できる設定、別の確定方法、対象領域の拡大を提供します。設定画面自体も視線で操作しやすくし、初回設定で利用者が行き詰まらないようにします。

11.5 フォーカスと視線位置を区別する

視線ポインターが要素上にあることと、キーボードフォーカスがあることは別の状態です。両方を同じ見た目にすると、現在どの入力方法が有効か分からなくなります。

視線による候補状態、選択準備、確定済み、キーボードフォーカスを区別します。複数の入力方法を切り替えた際にも、現在位置が失われず、操作状態が矛盾しないようにします。

12. プライバシー・同意・データ管理

視線データは、利用者が画面のどこを見たかを細かく記録するため、一般的なクリック記録よりも慎重に扱う必要があります。映像、視線座標、瞳孔情報、画面録画、発話を組み合わせると、個人を識別できる情報や機微な行動が含まれる可能性があります。

12.1 調査目的を具体的に説明する

参加者には、「UX改善のために利用する」だけでなく、カメラ映像、視線座標、画面録画、音声のうち何を取得するかを説明します。保存期間、閲覧者、外部サービスへの送信の有無も伝えます。

同意文を長い規約の中へ埋め込まず、参加判断に必要な内容を読みやすく示します。カメラ権限の許可だけを研究参加への同意とみなさず、目的とデータ利用に対する明示的な同意を取得します。

12.2 必要最小限のデータを取得する

視線座標だけで目的を達成できる場合、顔映像を保存しない方法を検討します。瞳孔径が不要なら取得・保存しないなど、調査目的に必要な項目へ限定します。

WebGazer.jsはブラウザー内で処理し、映像をサーバーへ送信せずに動作させられると公式資料で説明されていますが、開発者が座標や別のデータを保存する実装は可能です。クライアント内処理であることだけで安全と判断せず、実際の保存・送信処理を確認します。

12.3 同意撤回の手段を用意する

参加者が調査途中で中止したり、後からデータ削除を希望したりする場合の手順を説明します。中止によって不利益が生じないことも明確にします。

視線取得を一時停止できる操作を用意し、休憩や個人的な画面表示時に記録を止められるようにします。取得状態を常に確認できる表示も必要です。

12.4 報告資料で個人を特定させない

視線録画に顔映像、氏名、入力内容、アカウント情報が含まれる場合、社内資料でも閲覧範囲を制限します。発表用の映像では、不要な個人情報を隠します。

視線軌跡が特徴的であっても、参加者を面白い事例として扱わないことが重要です。個人の失敗ではなく、UIがどのような条件で問題を生んだかを報告します。

12.5 保存期間と削除手順を定める

データを「今後の研究のため」に無期限保存すると、利用目的が拡大しやすくなります。分析、再確認、監査に必要な期間を設定し、期限後に削除します。

派生データ、バックアップ、外部調査会社が保有するデータも対象に含めます。削除担当者と記録方法を決め、方針だけでなく実行可能な運用を作ります。

13. ブラウザー上の視線計測を試作する

Webカメラを利用したブラウザー型視線推定は、専用機器より手軽に試作できますが、環境差と精度の制約があります。重要な製品判断では、試作結果を絶対的な測定値として扱わず、利用目的に合った精度かを事前に検証します。

13.1 WebGazer.jsを利用する際の注意

WebGazer.jsは、一般的なWebカメラからブラウザー上の視線位置を推定するJavaScriptライブラリです。クリックやポインター移動を利用して自己較正する仕組みを持ち、映像処理をブラウザー内で実行できます。

ただし、公式サイトとリポジトリは、2026年2月24日以降も動作する一方で、公式更新は保証されず、保守が終了したと案内しています。新規の本番機能へ依存する場合は、セキュリティ、ブラウザー対応、代替ライブラリ、社内保守能力を確認する必要があります。

Webカメラ視線推定を開始するコード例

<button id="start-tracking" type="button">  視線計測を開始 </button> <p id="tracking-status" role="status">  視線計測は停止しています。 </p> <script src="/assets/webgazer.js"></script> <script>  const startButton = document.querySelector('#start-tracking');  const status = document.querySelector('#tracking-status');  startButton.addEventListener('click', async () => {    try {      status.textContent = 'カメラの許可を確認しています。';      await webgazer        .setGazeListener((data, elapsedTime) => {          if (!data) return;          console.log({            x: data.x,            y: data.y,            elapsedTime          });        })        .begin();      status.textContent = '視線計測を開始しました。';      startButton.disabled = true;    } catch (error) {      console.error(error);      status.textContent =        '視線計測を開始できませんでした。カメラ設定を確認してください。';    }  }); </script>

13.2 視線サンプルを間引く

視線推定は短い間隔で大量の座標を返すため、すべてをそのまま保存すると、データ量と処理負荷が増えます。調査目的に応じて一定間隔で抽出し、必要な時間精度を確保します。

間引き間隔が長すぎると短い注視を失い、短すぎるとノイズを多く保存します。事前試験でサンプル頻度、機器精度、分析単位を確認し、報告書へ記載します。

一定間隔でサンプルを保存するコード例

const gazeSamples = []; let lastSavedAt = 0; const saveIntervalMs = 100; function saveGazeSample(data, elapsedTime) {  if (!data) return;  if (elapsedTime - lastSavedAt < saveIntervalMs) {    return;  }  gazeSamples.push({    x: Math.round(data.x),    y: Math.round(data.y),    elapsedTime,    scrollX: window.scrollX,    scrollY: window.scrollY,    viewportWidth: window.innerWidth,    viewportHeight: window.innerHeight  });  lastSavedAt = elapsedTime; }

13.3 関心領域を要素から取得する

固定座標で関心領域を作ると、画面サイズやスクロールで位置がずれます。DOM要素の境界を取得し、表示時点の座標と関連付ける方法が有効です。

動的に表示される要素では、表示開始と終了も記録します。非表示だった時間の視線を、その要素への注視として集計しないようにします。

UI要素を関心領域として判定するコード例

function getArea(element, name) {  const rect = element.getBoundingClientRect();  return {    name,    left: rect.left,    right: rect.right,    top: rect.top,    bottom: rect.bottom  }; } function isInsideArea(sample, area) {  return (    sample.x >= area.left &&    sample.x <= area.right &&    sample.y >= area.top &&    sample.y <= area.bottom  ); } const purchaseButton = document.querySelector('#purchase-button'); const purchaseArea = getArea(  purchaseButton,  '購入ボタン' ); const samplesInsidePurchaseButton = gazeSamples.filter(  sample => isInsideArea(sample, purchaseArea) );

13.4 滞在時間を計算する

単純な滞在時間は、連続する視線サンプルが関心領域内にある時間を合計して求められます。ただし、この方法は正式な注視分類ではなく、視線推定の揺れによって領域の出入りが頻発する可能性があります。

実務では、短い欠測や境界付近の揺れを許容する規則を設定します。正式な研究では、利用する注視判定方式やツールの定義に従い、独自集計との違いを明確にします。

関心領域内の概算滞在時間を求めるコード例

function calculateApproximateDwellTime(  samples,  area,  maximumGapMs = 250 ) {  let dwellTime = 0;  for (let index = 1; index < samples.length; index += 1) {    const previous = samples[index - 1];    const current = samples[index];    const previousInside = isInsideArea(previous, area);    const currentInside = isInsideArea(current, area);    const gap = current.elapsedTime - previous.elapsedTime;    if (      previousInside &&      currentInside &&      gap <= maximumGapMs    ) {      dwellTime += gap;    }  }  return dwellTime; }

13.5 生データを直接UI改善へ使わない

座標データを取得できても、較正誤差、欠測、スクロール、表示状態を処理しなければ、意味のある分析にはなりません。小さな要素単位の差を比較する前に、推定誤差より十分に大きな領域かを確認します。

また、ブラウザー型の計測結果は、専用機器を用いた管理環境の結果と同じ精度を保証しません。大きな領域の探索傾向、試作品の比較、遠隔での仮説形成など、技術特性に合った用途へ限定します。

14. 分析結果をUI改善へ変換する

視線追跡の価値は、きれいな視線密度図ではなく、どの設計判断をなぜ変更するかを説明できることにあります。数値、映像、発話、操作結果を結び付け、再検証可能な改善案へ変換します。

14.1 視線密度図だけで結論を出さない

視線密度図は、複数の視線を色の濃淡として示すため、全体傾向を説明しやすい可視化です。しかし、時間順序、個人差、操作結果が失われるため、赤い場所だけを見て判断すると誤解が生じます。

体系的なレビューでも、視線データだけでは行動理由を理解できず、定性的・定量的な別の方法と統合する必要性が指摘されています。視線軌跡、完了結果、事後質問を併用します。

14.2 個人差を確認する

集約図では、全員が同じ領域を見たのか、異なる参加者が別々の領域を見た結果なのか区別できません。参加者単位の視線軌跡を確認し、共通問題と個別行動を分けます。

経験者と初心者、成功者と失敗者、端末別などに分けると、意味のある差が見つかる場合があります。ただし、少人数を細かく分割すると偶然の影響が大きくなるため、探索的結果として扱います。

14.3 問題の原因候補を複数出す

重要要素へ視線が到達しない場合、位置、コントラスト、文言、利用者の期待、タスク理解など複数の原因が考えられます。一つの原因へ即断せず、証拠に合う候補を列挙します。

候補ごとに改善案と検証方法を作ります。位置を変更する案、ラベルを変更する案、情報構造を変更する案を試作し、どの変更が行動と成果を改善するかを再確認します。

14.4 改善優先度を製品影響で決める

視線上の問題が見つかっても、すべてを同じ優先度で修正する必要はありません。発生頻度、タスクへの影響、誤操作の重大性、対象利用者数、修正コストを評価します。

重要な同意内容を見落とす問題と、装飾画像を少し長く見る問題では影響が異なります。視線指標の差の大きさだけでなく、製品上の結果を基準に優先順位を決めます。

14.5 改善後に同じ条件で再検証する

変更後の画面を別のタスクや異なる参加者条件で測定すると、改善効果と条件差を区別できません。可能な範囲で同じタスク、機器、環境、指標を使用します。

視線指標が改善しても、完了率や理解が悪化していないかを確認します。見つけやすさを高めた結果、説明を飛ばして操作する人が増える場合もあるため、複数の成果を評価します。

15. 視線追跡に対するデザイナーの責任

視線追跡は調査担当者だけが扱う技術ではありません。何を測定し、どの行動を成功とし、結果をどのようにUIへ反映するかには、デザイナーの判断が深く関わります。

15.1 測定目的を設計課題へ結び付ける

デザイナーは、「視線密度図を見たい」という依頼を、そのまま調査目的にしてはいけません。どの設計判断に迷っているのか、何を変更できるのか、どの利用者行動を理解したいのかを明確にします。

変更できない画面を測定しても、結果が意思決定に使われない可能性があります。調査前に、結果ごとの対応案と意思決定者を決めます。

15.2 視線を注意や感情と断定しない

報告時に「利用者はここへ興味を持った」「この画像を好んだ」と断定すると、視線データの範囲を超えます。観測事実と解釈を分けて記載します。

「参加者8人中6人が購入前に送料領域を注視しなかった」は観測結果ですが、「送料を気にしていない」は解釈です。インタビューや選択結果で裏付けがあるかを示します。

15.3 アクセシビリティを同時に確認する

視線追跡で目立ち方を改善するとき、色、動き、サイズを強めるだけでは、感覚過敏、低視力、注意障害など別の利用者へ問題を生む可能性があります。視線誘導とアクセシビリティを別工程にしないことが重要です。

重要情報は視覚的な目立ち方だけでなく、文書構造、名前、キーボード順序、画面読み上げでも利用できるようにします。視線で発見しやすいことと、複数の方法で操作できることを両立させます。

15.4 調査結果をデザインシステムへ戻す

複数画面で同じボタンやフォーム説明の問題が見つかった場合、個別画面だけを修正すると再発します。共通コンポーネント、余白、文言規則、状態表示へ結果を反映します。

ただし、一つの調査結果をすべての文脈へ一般化しないようにします。どの利用者、端末、タスクで確認された結果かを記録し、適用範囲を明確にします。

15.5 倫理と利用者の尊厳を守る

視線データは、参加者が意識していない行動まで記録する可能性があります。デザイナーは、技術的に取得できるからという理由で、目的のない計測や過剰な保存を行ってはいけません。

利用者を「見なかった人」「理解できなかった人」と評価するのではなく、UIが必要情報を提供できたかを評価します。視線追跡は利用者を監視するためではなく、設計側の仮説を検証し、障壁を減らすために使用します。

おわりに

視線追跡は、利用者がUIのどこを見て、どの順番で情報を確認し、どの領域を行き来したかを観測できる強力な調査方法です。特に、重要な操作の発見可能性、情報階層、比較行動、エラー修正など、自己申告だけでは捉えにくい視覚探索を確認できます。しかし、視線が向いたことは、理解、好意、注意、意思決定を直接証明するものではありません。視線データだけで利用者の思考を断定せず、操作結果、発話、インタビュー、アクセス解析などと組み合わせる必要があります。

UIデザイナーに求められるのは、視線を多く集める画面を作ることではありません。利用者の目的に必要な情報が適切な順序で発見され、関連情報を無理なく比較でき、重要な操作へ安全に到達できる構造を設計することです。視線密度図の赤い領域を成果とみなすのではなく、その視線が理解、正しい選択、作業完了へつながったかを確認しなければなりません。

視線入力をUI操作として利用する場合には、見ることと実行することを区別し、ミダスタッチ問題、対象サイズ、滞在時間、確認、取り消し、代替入力を設計する責任があります。さらに、カメラと視線データを扱う以上、明確な同意、必要最小限の取得、保存期間、削除手順も欠かせません。視線追跡を派手な分析資料や監視技術としてではなく、設計仮説を慎重に検証し、より多くの利用者が目的を達成できるUIへ改善するための方法として扱うことが重要です。