概要
これまでWebアプリのデザインは、UI/UXデザイナーがユーザビリティ・視覚的な階層・導線設計・情報の優先度といった観点をもとに設計していました。「ユーザーが迷わず目的に辿り着けるか」「重要な情報が一目でわかるか」を念頭に置きながら、画面を作り込んでいきます。
生成AIの登場により、フロントエンドの見た目(UI)の画像をアップロードするだけで、ある程度の評価(レイアウトの問題、視認性の課題など)を生成AIに任せることができるようになりました。しかし、ユーザーが実際にどう操作するか・どこで迷うかというユーザー体験(UX)評価の部分では、私も含めてあまり使うことはありませんでした。
そこで試してみたのが、動画フレーム + ログを同時に生成AIに送信して、UI/UX両面を一度に評価させるアプローチです。AWS上のアーキテクチャ(Lambda、Bedrock、S3 Bucket)とReactで構築したWebアプリを使って実験してみました。

UI/UXの表記順について
本記事のタイトル・概要では、一般的な表記に倣い「UI/UX」としていますが、これより下の文章では「UX/UI」と記載します。これは、ユーザー体験(UX)の設計がユーザーインターフェース(UI)の実装よりも優先されるべきという考え方を重視しているためです。
生成AIを使ったUX/UI評価のアイデア
従来のアプローチ(静止画評価)
- 1枚のスクリーンショットをアップロード → AIが見た目をチェック
- メリット:シンプル、高速
- デメリット:操作の流れがわからない、ユーザーが実際にどこで困るのかが不明
なぜフロントエンドの見た目(UI)だけでは不十分か
フロントエンドの見た目(UI)のチェックは「デザインの品質」を確認するには有効ですが、ユーザーが実際にどう感じるかを評価するには不十分です。たとえば、ボタンが見やすくても「どの順番で押せばいいかわからない」という体験上の問題は、静止画ではなかなか捉えられません。
そこで必要になるのがユーザー体験(UX)の評価です。UX評価では、ユーザーが「誰か」「何をしたいのか」という文脈を定義した上で、その体験が適切かどうかを確認します。
ユーザー体験(UX)評価に欠かせない2つの視点:
- ユーザー属性:対象ユーザーの特性(年齢層、ITリテラシー、利用頻度など)
- シナリオ:ユーザーが何を目的に、どのような状況でアプリを使うか
具体例
| ユーザー属性 | シナリオ | 注目すべき観点 |
|---|---|---|
| 初めて使うユーザー | アカウントを作って初回ログインしたい | 手順のわかりやすさ、エラー時のガイダンス |
| 慣れた業務ユーザー | 毎日使う機能を素早くこなしたい | 操作ステップの少なさ、ショートカットの有無 |
| シニア層 | 写真をアップロードして送りたい | テキストの大きさ、ボタンの押しやすさ |
このようにユーザーが「誰か」「何をしたいのか」をプロンプトに付け加えることで、生成AIがその文脈を踏まえた上で評価してくれるのではないかと考えました。
UX/UIを評価するアイデア(UI + ログの評価)
- 動画フレーム(数秒の画面遷移)+ 操作ログをセットでアップロード
- AIが「何をしようとして」「どの画面にいて」「何が起きたか」を理解できる
- メリット:ユーザーの実際の行動フロー、つまずきポイント、デザインとの齟齬を発見しやすい
- デメリット:データサイズが大きい、分析に手間がかかる
静止画では、生成AIに「今この画面にどんな問題があるか」という質問しかできませんでした。このアイデアでは動画フレーム+ログを組み合わせることで、時系列の文脈を持った問いを生成AIに投げます。よって、以下のような点を評価できるのではないかと考えました。
1. 操作が意図したものか
静止画では「ボタンが押されたか」はわかりません。ログと突き合わせることで、ユーザーが想定外の順番で操作していないか、意図しない画面に迷い込んでいないかを生成AIが指摘できます。
2. 「迷い」や「やり直し」の検出
同じ操作を繰り返す、戻るボタンを何度も押すといった行動は、ログにパターンとして現れます。生成AIはその時系列を読んで、「このステップでユーザーが詰まっている可能性がある」という判断ができます。
3. 画面遷移のタイミングと体験の齟齬
動画フレームがあることで、「ボタンを押してから結果が表示されるまでの間」に何が起きているかを生成AIが把握できます。読み込み中の表示が不十分で、ユーザーが不安を感じる箇所なども指摘対象になります。
システム構成
全体像
各サービスの役割
S3 Bucket
- Webアプリからアップロードされた動画フレーム画像のみを保存
- 操作ログはS3 Bucketには保存せず、Lambda呼び出し時のリクエストに含める
- 役割:動画フレームの一時保存
Lambda
- Webアプリから直接呼び出される(S3 Bucketアップロード完了後のタイミング)
- リクエストには、S3 Bucketに保存した画像のKey+ログのセットが含まれる
- 受け取ったデータをもとにBedrockへのリクエストを組み立てて送信
- 役割:Bedrockへリクエストを投げる
Bedrock
- Lambdaから基盤モデル(今回の検証では、Claude Sonnet 4.6を利用)を呼び出して推論を実行
- 動画フレーム+操作ログを同時に入力として与え、UX/UI評価を実行
- 「このフロー、ユーザーはここで迷いそう」などの指摘を生成
- 役割:生成AIの推論エンジン(基盤モデルのAPIを提供)
フロントエンド(React)
- 動画、操作ログのアップロード画面
- 動画フレームとログのセットを作成
- S3 BucketへのアップロードとLambdaの呼び出し
- 評価結果の可視化・表示
- 役割:ユーザーインターフェース
使用イメージ
作成したフロントエンド
各部品の説明
STEP 1: ファイルの読み込み
アプリの操作動画とログファイルをアップロードするコンポーネントです。
各ボタンをクリックするとファイルをアップロードできます。
STEP 2: コンテンツの確認
アップロードしたアプリの操作動画とログファイルを確認できるコンポーネントです。
STEP 3: 解析指示の設定
システムプロンプトと対象ユーザーを入力します。
生成AIには、「対象ユーザーは{対象ユーザーに入力した文字列}。{システムプロンプトに入力した文字列}。」としてプロンプトが作成されます。
検証のために作成したアプリ画面
今回はSwiftで簡単なログイン画面を作成して試してみました。
操作手順
- ログイン画面を開く
- ユーザーIDを入力する
- パスワードを未入力のままログインボタンをタップする
- パスワードを入力して、「ヘルプが必要ですか?」のラベルをタップして、ヘルプを表示する
- ログインボタンをタップして、ログインが成功する
通常プライベートなテキスト入力にはSecureFieldを使用しますが、SecureFieldは画面収録に表示されません。今回は検証のためTextFieldを使用してマスクをする実装にしています。
操作動画
プロンプト
システムプロンプトと対象ユーザーには以下のような文字列を入力して試しました。
| 入力した文字列 | |
|---|---|
| システムプロンプト | UIの観点(フォントサイズ、色、レイアウト)から修正案を指摘してください。UXの観点(ユーザー体験、操作性、フィードバック)から修正案を指摘してください。Apple Human Interface Guidelines(HIG)への準拠を確認してください。 |
| 対象ユーザー | 初めてこのアプリを使う非エンジニアのユーザー |
検証結果
検証結果の考察
ハルシネーションが発生することを前提として、UX/UIの評価に絞って考察します。
また生成AIの最大出力トークン数を超えてしまったことで、最後の指摘における改善内容が表示されていません。
1. 動画フレームとログからUXに対する評価は成功
「〜どちらの欄が未入力かが視覚的に明示されておらず(未入力欄の枠が赤くなるなどの強調がない)〜」や「〜入力が足りない状態でも押せてしまう設計がユーザーの焦燥感を高めている」などUXに対する指摘は成功したと考えています。
2. 標準UIコンポーネントを判別できない
ログイン処理中に表示するインジケータは標準のProgressViewに背景色を追加して使用しました。しかし、「UIActivityIndicatorViewではなく、レガシーな「歯車型スピナー」に見える」の指摘がありました。
今回はシングルエージェント構成で行いましたが、以下の様なエージェントが連携するようなマルチエージェント構成として作成しても良いかもしれません。
・標準UIコンポーネントを使用しているか判別するエージェント
・UIを評価するエージェント
・UXを評価するエージェント
・改善内容を提案するエージェント
。
3. 動画を動画フレームに切り出すタイミングによっては残像が残る
「〜ダイアログがキーボードと画面コンテンツに挟まれた不自然な位置に中途半端に表示〜」のように、アニメーションの一部が指摘されています。
この点については改善案がないので、結果を見て人間が「問題ない」とする必要がある点と考えています。
検証で分かったこと
1. 動画 + ログの併用が効果的
- 単なるUIチェックではなく、「ユーザーが迷いそう」という定性的な問題を発見できる
- ログが時系列で記録されていると、AIが「実はこのタイミングで問題が起きてる」と指摘しやすい
2. ユーザー属性・シナリオの指定が効く
- 同じアプリでも「初めてのユーザー」「頻繁に利用しているユーザー」では見えるUIの課題が違う
- 対象ユーザーをプロンプトに付け加えることで、より現実的な評価が得られる
- 例:
「対象は初めてアプリを使う非エンジニアのユーザーです。」というテキストをプロンプトの冒頭に加えることで、対象ユーザーに沿った指摘を行うことができる
3. 改善内容を出力することで結果の議論を行いやすい
- 改善内容を具体例を含めて出力することで結果からどのような修正が必要かイメージできる
まとめ
生成AIを使ったUX/UI評価は、単なる「見た目チェック」ではなく、実際のユーザーの行動フローを理解する糸口になると考えます。動画+ログというデータをAIに与えることで、人間が見逃す細かい問題や、改善のヒントが見つかりました。
これからのアプリ開発では、定期的に生成AIに「このUX/UI、どう見えます?」と聞き、その指摘をチームで議論する——そういう使い方が当たり前になると考えています。



