UXを自動で評価したい
NTTドコモの西村です。
皆さん、Vibe Codingしていますか？ ←既にちょっと古い響きですね...
コーディングに限らず、Vibe Writing・Drawing・Composing等々、AIを試していると共通の悩みがあると思います。
- AIが作った大量の成果物をいちいち読みたくない
- （知見のない分野だと）どれが良いアウトプットなのかが判断できない！
そう。AIが深く考えて計画してくれるようになって、爆速で作ってくれるようになったのに、このままじゃ生産はスケールしないですよね。十分な知見を有した人材の、判断能力という資源がボトルネックです。
ということで次の世界に進むためには、PDCAのCheckの自働化が必要です！
と、そんな想いだけを持って色々取り組んだ、ここ1年半の奮闘記になります。
書くもの
- 新規企画に挑戦した学び
- ドコモの入社2-3年目のリアル
- AIでUXを測りたいと考える人に転ばぬ先の杖になる検討過程
詳しく書かないもの
- ドコモの海外研修の詳細
- 作成したプロダクトのUIや実装の具体
- プロダクトの実践での適用例
AWS全冠（2026 Japan All AWS Certifications Engineers基準）
現在入社3年目（2023年卒）で、開発部の横通し組織に所属し、昨年紹介したリリース短縮の取り組みや、部門の中期戦略の策定と円滑な実現のサポートを担っている。
加えて、FY25は複数の生成AI活用施策をドライブしている。
↓昨年の記事 nttdocomo-developers.jp
目次
【はじまり】オープンイノベーション研修 in シリコンバレー への参加
ドコモには、社員の知見を広げるための多様な施策があります。
一例をあげると新規事業系だと、座学やアイデアのブラッシュアップ補助から始まり最後はコンテストの場提供から独立するための投資まで一貫で支援してくれるようなプログラムもあります。
docomo STARTUP CHALLENGE｜docomo STARTUP
その内の１つとして、シリコンバレーに出張し最新デバイスを体験したり大企業/ベンチャー/インキュベーターを視察する。結果として新技術活用により中長期計画に寄与する施策を創出し、会社幹部にプレゼン/事業化させていくという施策があります。 幸運なことに開発・運用部門を代表して参加する機会をいただき課長と2人で参加しました。
その中で本記事の内容に挑戦していきました。
無から始めて自分の行動だけで推進していくというお仕事は、当時入社2年目7月の西村には初めてで、大変右往左往することとなりました↓↓↓
【第一の挑戦】テーマ決めには自身のWILLも必須
なんと、初っ端のテーマ決めから大苦戦します。
「部門の中長期計画に寄与する施策」というところから、まずは現在の部門の中計や各サービス毎の開発内容を調べましたがそこには、何が課題かという西村が求めていた情報はありません。
というのも、部門の課題として既に具体化できているものは一介の若手がやるまでもなくどこかのチームが取り組んでいるし、また各開発チームの課題は横通し組織の西村たちが取り組む意義がないからです。
とはいえ綺麗に整理をして周囲の大先輩方に持っていくとお言葉をいただきました。
- 米国のグループ会社CEO：総花的でどうしたいのかが分からない
- 本研修のメンター：西村君自身が何をすべきと思っているのかが聞きたい
- 組織長：新技術導入は一蓮托生するくらいの覚悟が必要
・・・(T⌓T)
振り返ってみて思うところは、新しいことを始める/導入するなんていうのはそうそう上手く進まず
- どんな壁が来ても停滞させず前に動かし続けるという気持ち、当事者意識
- 周りが後押ししてくれるだけの明確な自組織への利点/取り組むべき理由
- 周囲の人が助け方が浮かぶくらいクリアなビジョン
が求められていたのだろうなと思います。
と、全体像が腑に落ちるのはその後壁に当たっていく中でのことで当時は1つ1つのコメントにただ全力タックルでアンサーを考えていきました。
自部門の戦略資料を立ち上げ時から経過で追って読んでみる、全社ニュースに流れてくる経営層の会議でのアジェンダを読んでいく、その資料についてカンパニー全体の戦略チームに今後の考えていることを聞きに行く、
更に並行して自分がやるべきと信念を持てることを考える。
結果として、カンパニー全体の方針、現在の自部門の流れ、個人的なWILLすべてからやるべきと言える重なり部分を自分なりに見つけて、アメリカに渡航していきます。
結論を簡単に言うと、ドコモでは今CX（顧客の体験）向上を重視して取り組んでいますが、最前であるwebサイト・アプリのUXを誰も全社全プロダクト横断では見れていませんでした。単純に多すぎるせいです。
ならば、そこを自動評価できること、それにより全社のプロダクトに定量的なUXのスコアという概念を持ち込み議論可能な状態にする
それが当時の自社の0.5歩先のアクションとして必要になるだろうというテーマでした。
西村の所属するプロダクトデザイン部はカンパニーの横通し組織として、100を超えるシステム・100を超えるアプリを開発運用することと、加えてそれらのQCDを横断的に可視化することで全社に貢献してきており、VQCDの結果指標といえるUXの横断的可視化に挑む組織として最適と考えました。
また西村個人も、新技術を社会で活用することで人々のゆとり（時間・精神的負荷の排除）を増やし、各人が個性的な価値を発揮する世界を目指しており、冒頭のPDCAループ自働化に資する本テーマはわくわくするものでした。
【参考】カンパニー方針とプロダクトデザイン部取り組みについてはAWS summitで発表しているのでご視聴ください。
・3:00~ CX向上
・11:50~ PD部の可視化取り組み
「変化を競争力に変える」アジャイルとクラウドで実現する、自立的に成長し続ける組織のつくり方（CUS-45）
テーマも定まったことでいよいよ渡米。
アメリカ現地の話は、書き始めると終わらないので割愛します。
【第二の挑戦】やりたいことの解像度を上げよう
さて、そうして走り出したものの、もちろん先ほどまでの検討では施策は前に動きませんでした。
当時の西村は無邪気にベンチャー出資を担うグループ会社の方と相談をしたり
担当内で意見を募集しましたがうまく進みません。
というのも解像度が粗すぎました。
- デザインが良いとはどういう状態を指すのか？
- UXとはどの範囲を想定しているのか？
- UXを上げるメリット（アウトプット指標）を何だと捉えているのか？
- 何を対象として評価するのか？アプリ？サイト？全ての遷移ルート？
- 誰が作業者と想定しているのか？
- 評価結果はどういう粒度、どういう出力があれば良いのか？
- アクセス数分析、ヒートマップ分析、それらは違うのか？
- 誰がどう困っているペインを解消したいのか？
- デザインの良さとはトレンドで変わるものではないか？
大変遅ればせながら、UXと呼んでいたものについて、定義・測り方など勉強をしました。
社内にはデザインを専門とする支援部隊がおり、伴走支援の流れや課題を見せていただいたりもしました。
結果としては、サイトを対象として、Nielsenの10原則のブレークダウン項目の〇△×をチェックして、達成項目割合をカウントすることで定量評価ができるのであると全体像を定められました。
当時アクセシビリティの自動評価はできていたため、ユーザビリティと合わせることで、プロダクトのUXを仮に測れると考えました。
もう少し詳しく説明すると、デザインの評価は、大別すると専門家による評価（ヒューリスティック評価、認知的ウォークスルー）、ユーザーからデータを集めるもの（ユーザビリティテスト、パフォーマンス測定）があり、
いずれもテーマとしての適不適はあるのですが、今回はヒューリスティック評価の自働化を実現したいテーマとして絞り込みました。
まずヒューリスティック評価は、平たく言えばチェックリストに適・不適合をつけるものなので、良いデザインと悪いデザインという曖昧なものに対して、一定の合意された指標での評価として受容してもらいやすく、その結果も集計すれば定量スコアにできます。
またヒューリスティック評価の現在の実施は課題感を抱えており現場にペインがありました。というのも、ヒューリスティック評価は1度の実施で最低3名以上の専門知識を持ったデザイナーによるそれなりに時間をかけた目検が必要です。そのため、ヒューリスティック評価はいわば労働集約的であり、専門家リソースがどうしてもボトルネックになってしまいます。
実際社内でも一部アプリは実施できているものの、デザイナーチームの稼働という上限があり、ドコモに3桁のサービスがある中で極少数のアプリの、更に絞った数タスクシナリオの導線しか見れていませんでした。
また加えると、仮にデザイナーが大量にいたとしても、彼ら同士での感性をすり合わせる必要があり、企業が求める全社プロダクトの共通指標での横並び評価に適用するには難しい部分がありました。
技術的な観点で見ても、ユーザビリティ評価はアクセシビリティと違い既存で自働化できていないだけの困難点があり挑戦するだけの新規性がありました。
①Nielsenの10原則の評価はチェックリストとは言いつつも一定の主観性を含む
②DOM（HTML）やテキストでの確認では満たせず、画像での確認が必要
③ただ画像を見るのでは満たされず、意図を持った操作によるフィードバック確認が必要
まとめると、既に一定認められビジネスで利用されている方法の模倣によって定量評価ができ、現場でも課題感があることから自働化ニーズがありなおかつそこをクリアすれば全社利益に繋がることが想像され、新規性も含むチャレンジということで妥当と考え設定しました。
＜参考＞Nielsenの10原則に基づいたヒューリスティック評価とは
Nielsenの10原則とは、ユーザビリティを上げると言っても何からすればいいの？という悩みに対して、一般的に良いとされる特徴を並べたものです。
- システム状態の可視化 (Visibility of system status)
- 実世界とシステムの一致 (Match between system and the real world)
- ユーザー主導の自由な操作（User control and freedom）
- 一貫性の維持と、標準（Consistency and standards）
- エラーの防止（Error prevention）
- 記憶に頼らず理解できる（Recognition rather than recall）
- 柔軟性と効率性を与える（Flexibility and efficiency of use）
- ミニマルで美しいデザイン（Aesthetic and minimalist design）
- エラーの認識と回復方法の提供（Help users recognize, diagnose, and recover from errors）
- ヘルプとドキュメントの原則（Help and documentation）
読んで分かるようにNielsenの10原則そのままではざっくりとしすぎていて判断が難しいので、通常ヒューリスティック評価の際は具体的にブレークダウンしてチェックリストにします。
これは各専門家部隊の経験値から作成されていて、いわば各デザインチームの秘伝のタレのような部分です。
例えば「1.システムの状態を可視化する」だと、「ユーザーの操作の後に結果や状態の変化等わかりやすいフィードバックがある。」とか「アクションに対する処理状況のステータスを表示できている。進行状況のバーや％表示、実行中・完了などのステータスなど。」とか。「4.一貫性と標準性を保持する」だと「サービス種別、またはWeb, アプリ, OSにおいて一般的なUIを具備し、初見でどのような操作になるかユーザーが想像できること」とかになります。
こういったものが、弊社では既に整えられており、何十項目と良いデザインの基準がありました。
【第三の挑戦】新しい挑戦ではソリューションが市場にない
求めるものが明確化できて、あとは答えをぶつけるだけ・・と思いきや、むしろここからがスタートでした。
なぜならば解決できていない課題は解決できていないだけの理由があり、SaaSどころか容易に利用可能な技術レベルですらどこにもソリューションがないという壁に当たりました・・
というところで、新技術のウォッチを続けることになります。
一旦話を【第二の挑戦】に戻ると、実は前項の解像度が粗いという課題も、実際のところはタイミングによってはこの米国スタートアップでいけるのではないかと具体化されていたこともありました。
しかし突き詰めてみるとこういう使い方はできないといった制約とぶつかったりして。。
一方向で進められたわけではなく第二と第三の壁は何度も往復（いわゆるPIVOT）を繰り返しました。
例えばペルソナを大量に作成して、意見を出し合って多数決を取るとか、あえて多様な立場で会話をさせるとかの案もありました。
（今では特定パターンに対して利用可能なツールなども企業が発表し始めていますね！）
他にも、「LLMを活用して意味理解処理で評価をする」系のソリューション案だけでも、Good/Bad画像を自作するとか、社内デザインルールを入れてみるとか、過去のABテスト結果を学習させるとか、色々なアイデアが出ましたが
元データがあるか、精度を確保できるか、既存と違いやりたいニーズを満たせるのか等々都度壁があり、、沢山案が出てそして沢山没になりました。
さて戻ると、本業の傍らで新情報ウォッチを続けていた日々の中、忘れもしない2025年2月21日、OpenAI社から今では普通になったAIエージェントの走りである「Operator」がやっと日本でも公開されました。
ここでやりたいことと技術が初めてマッチしました！！
該当技術はずっと有力候補として目をつけていて、ついに使えるようになり、更には有力な結果が出た時のやっっっと先行きがひらけたぞという時の安堵は得も言えませんでした。
先ほどの既存技術ではクリアできなかった課題点と見比べてみると、
①Nielsenの10原則の評価はチェックリストとは言いつつも一定の主観性を含む。従来AIではできない
→LLMならば過去の集合知とコンテキストインプットにより例えば「ドコモサービスで、ヘルスケア系のサイトとして、一般的に人々が想起した行動を取れるUIか？」という曖昧な指示を判断可能
※もちろん最新のデザイントレンドを追ったアドバイスなどはできないので、減点項目を探す使い方で想定
②DOM（HTML）やテキストでの確認では満たせず、画像での確認が必要。優秀なreasoningモデルだったとしても非マルチモーダルモデルでは対応できない
→VLMならば画像の処理が可能 ※当時はマルチモーダルかつreasoningモデルはまだ希少
③ただ画像を見るのでは満たされず、意図を持った操作によるフィードバックの確認が必要。例えばローディングが出るか？アニメーションは自然か？誤った入力を入れたら分かりやすいエラー表示が出るか？は操作をしないと分からない
→browser useアビリティを含んだサービスならば、調査項目から自主的に実施するべきことを判断して、確認行為が可能
さて、可能性が見えてからは手を動かしてプロンプトを改善、あとはひたすら何十もあるプロンプトを回しまくり精度を検証。試した結果は西村の評価としては下記でした。
- エラー表示の有無の確認という項目に対して、通常フィードバックがあるべき場所まで自分で遷移（ホーム→ログイン→メアド入力）
- 自分でテスト項目を考えて、ダミーメアドを入力、カーソルを外したりログインを押して反応を確認
- 環境制約上AIエージェントが不可なタスクでも（機内モードでの反応を見るとか）、サイト上の記載などから結果を予測できないか関連情報を報告してくる
- 分からない項目や本サイトと関係ない調査項目について、ハルシネーションをせずしっかり調査結果で回答をしてくる
- 追加調査が必要そうであれば、XX画面でログインした後の結果を調べてくださいと、必要な操作を予想して人間に依頼
- 画像では不可能なアニメーションも調査可能 ←びっくり
- これらを、そのサイト用に練ったプロンプトでなく、一般的な指示をするのみで自律的に考えて実行
すごい！！！
先ほどのデザインチームにも結果をぶつけてみて、非常に好意的な反応をいただけて
インタビューをさせていただきプロダクト化に向けた改善示唆ももらえました。
とはいえこれをそのまま渡せば業務フローが改善されるとはとてもいきません。
西村が人力で実施している、起動処理やプロンプトでの条件付けなどを、省人化・非属人化した形にしないとデザインチームが使いたい時に使えませんしスケールしません。
プロダクト化するべく、粒度をあげた施策の概要と試行の結果を持ってマネージャーに説明、ある程度の稼働と開発費枠を使って頑張っていいよと応援をいただけました！
そういえば思い出話なのですが、周囲に本施策を説明してアドバイスを仰ぐかたわら、Computer Useという技術及びAIエージェントという概念について、動作の動画を撮ったりして周囲に必死に説明して覚えた方が良いよとアピールしていました。今となっては部内で知らない人なんていそうにもなく、たった1年弱なのに中々隔世の感があります
世の中短期的にみると遅々としているようでも、振り返ると生成AIもすごい勢いで浸透してきていますね
【第四の挑戦】「技術的に可能」から「実用」の間にある多くの制約
やりたいことがきっちり定められて、技術的にも可能と見えてきて、第一利用者見込みの人たちともコミュニケーションが取れている。ゴールが見えてきたかと当時の西村は思っていたのですが
むしろここからがスタートでした。（n回目のスタート）
最初は自作することを目指していきました。
Playwrightを勉強して、APIキーの使い方を学び、for文を書き・・そして様々な限界にぶつかりました。
0→1企画やアプリケーション作成どころか、プロダクト開発に携わることすらはじめてだった西村には
実用となると途端に考えることが膨れるということや、中長期ロードマップを引いたうえでマイルストーンと優先度を決めて進めなければならないというところを分かっていなかったためです。
（こちらも今振り返れば何も先が浮かんでいなかったんだなと分かります。無謀でした。）
さて、よく分からないままに行き詰まった西村ですが、社内の週一エンジニア自由発表会で「音声会話のみでAIエージェントにコーヒー買わさせてみた」を話されていたスペシャリスト人材の方を思い出しました。
2025年1月というAIエージェントという言葉がにわかに駆け巡り始めた頃の実演で大変感動したことを覚えています。
※スペシャリストグレード（通称SG）については過去ニュース記事（NTTが挑む「脱・年功序列」の改革 実力主義の専門人材登用と次世代経営層育成とは）を参考ください
その方に考案中の本件の話をしてみてアドバイスを伺ってみたところ、課題設定と適用技術に妥当性が高く、今の市場状況を見て新規性もあると評価していただけました。その上、ちょうどその方のFY25注力領域と近かったことから なんとプロダクト開発に協力していただけることになりました。 そこからは二人三脚で（というよりはスペシャリストの方が、西村へ適切なプロダクトの開発の流れを導いていただきつつ、更に開発も進めていただいた感じですが）少しずつプロトタイプが完成していきます。
実利用に向けたプロダクト化というところで非常に沢山の気にするべき観点があることを学びました。
- コスト
- セキュリティ
- UI・データベース・AIエージェントの動作環境・AIエージェントに対するオブザーバビリティ環境の分離
- 社内整理（セキュリティ申請、プロダクト管理申請、所掌組織の建付け）
- 利用者の利用シーンを考える（作業制約、既存のフロー、作業で出そうとしているアウトプット）
- 履歴・操作動画・試行回数でのタスク完了率
- 複数回の実利用の制約（テストを繰り返していると、詳細は不明ですが、CAPTCHAでアクセス不可となる、当時強力なAPIであったCUA(ベータ版)が利用不可となる等）
コストとクオリティの問題はやはり大きく、エージェントの作業回数に制約をかける・エージェントで撮影した画像を使い回す・一部項目はDOMのみで対応可能と峻別するなどの工夫がありました。
またCAPTCHAによる失敗、すなわちAIエージェントの認証の問題は大きく残っています。
※より具体については、もしもきちんとしたプロダクトとして実現できたらそこでご確認いただきたいです。
おわりに
AIでのデザイン評価で悩んでいる方に、考え方の参考になる部分が1つでもあれば幸いです。
課題も技術も0の中から、やりたいテーマを定め、課題を具体化し、実現できる新技術を見つけて、それを実用可能な粒度まで形にできました！
若手のうちから、自由に動いてやりたいことに挑戦する機会をもらえて会社に感謝します！
最新技術をもっと社会で使えば社会はより良くなると無邪気に思っていましたが、オープンイノベーションの難しさを感じました。
また、アドベントカレンダーに記載していて、周囲の大先輩たちにアドバイスを貰いにいける環境のおかげで各タイミング前に進んでいたことを感じました。
今も、自組織の変化に伴いより大きなデザイン部隊に相談をもちかけ、もっと大規模な開発チームが類似プロダクトの開発に興味がありそうと繋いでもらえました。
引き続きAIの最新技術を追って、会社への活用で頑張っていきます！
