1. ホーム
2. UIデザインの指標・ユーザビリティとは
3. UIの品質（ユーザビリティ）を評価・改善する方法

ユーザーテスト（ユーザビリティテスト）とは

やり方・人数のポイントを解説

ユーザーテスト（ユーザビリティテストとも）とは、サイトやアプリをその想定ユーザーに操作してもらい、その行動と発話を観察して、問題の所在と原因を特定するUI評価手法です。アクセス解析では離脱が「どこで起きたか」はわかっても「なぜ起きたか」はわかりません。それを明らかにしてUIの改善につなげます。

• 株式会社イード リサーチ事業本部
• 2026年10月20日

ユーザーテストとは：目的とわかること

ユーザーテスト（ユーザビリティテスト）の主な目的は、開発者やデザイナーが気づきにくいサイトやアプリの「わかりにくさ」「使いにくさ」を、ユーザーの実際の行動から見つけて改善につなげることです。作り手は画面を熟知しているため、はじめて使う人がどこで迷うかを想像しにくいのです。

1. ユーザーテストでわかること

テストでは、たとえば次のようなことがわかります。

• 目的の情報や機能にたどりつけない箇所
• 文章やボタンの文言が意図どおりに理解されていない箇所
• 実際の操作手順が想定とは異なるという事実
• 迷い・ためらい・誤操作が起きる瞬間とその理由

評価の観点は、UIが「ユーザーの思考・利用状況・目的に合っているか」だけでなく、「ビジネス側の目的（購入・申し込み・問い合わせなど）を達成できる設計か」にも及びます。

2. 評価対象：サイト・アプリ・組み込みシステムの、現行版でもプロトタイプでも

評価は、参加者が簡易的にでも操作できるUIがあれば可能です（画面でも機械でも音声UIでも）。

ユーザーテスト（ユーザビリティテスト）によって、一般の消費者向けのサイトやアプリのUIを評価することはもちろん可能です。また、業務用のシステム、たとえば、金融機関職員向けの機械や、小売店の管理者向けの機械などの操作性を評価することもできます。

現行版のUIの問題を探すことを目的に現行版を評価することもできますし、リリース前の改善のために新規やリニューアルの開発最中のプロトタイプを評価することもできます。

---

ユーザーテストの5つのステップ

2から5までの各ステップについて、これから詳しく説明します。

---

タスク・シナリオの作り方と例

タスクとは、参加者に実行してもらう課題です。人がサイトやアプリを使うときには何らかの背景・目的があるため、それを短いシナリオとして提示します。この内容・指示説明・順序を考えるのが調査設計です。

• 現実的な状況・目的を設定：ユーザーが実際に直面しそうな状況や目的を与え、自然な行動を引き出す
• スタートとゴールを明確に：「どこから始め、どうなれば完了か」をあいまいにしない
• 操作箇所や手順を伝えない：ボタン名や操作手順を伝えて誘導せず、ユーザーの自然な行動を観察する

1. タスク・シナリオ例（ECサイトの場合）

• シナリオ：普段履いているスニーカーが古くなったため、新しいものへの買い替えを検討しています。
• タスク：1万円以内の軽量なスニーカーを複数比較し、最も欲しいと思った商品を購入してください。
• スタート：ECサイトのトップページ
• ゴール：条件に合ったスニーカーが買い物かごに追加された状態

2. ダメなタスクの例

• シナリオ：来週、トライアスロンの大会に出場するため、競技用のシューズの購入を検討しています。
• タスク：左上の「≡」メニューから「スポーツ＆アウトドア」の「シューズ」を開き、一覧の中からどれでもいいので商品詳細ページを開き、右側の「買い物かごに入れる」を押してください。
• スタート：ECサイトのトップページ
• ゴール：何らかのスポーツ用シューズが買い物かごに追加された状態

このシナリオは多くの人にとって現実的ではなく、参加者がこの状況を自分ごととして捉えられません。また、タスクは操作手順の指示に終始しています。そのため、ユーザーが自然に商品を探し、比較・検討する行動を観察できず、目的達成のしやすさではなく、決められた操作を実行できるかしか評価できません。

---

モデレーターの役割と注意点

モデレーターはユーザーテスト（ユーザビリティテスト）の司会進行役です。タスクの説明、参加者の操作の観察、思考発話（何を考えながら操作しているのかを言葉にすること）の促し、操作意図の確認を行い、事前のプロフィール確認や終了後の総括的な質問も行います。

1. 参加者が安心して率直に話せる関係を作る

• 評価対象はUIであり、参加者の操作スキルではないことを伝える
• わかりにくい／操作しにくい点を率直に話してもらうことがUIの改善につながることを伝える

2. 行動を観察し、その背後にある理由を把握する

• タスク実行中、何を考えながら操作しているのかを言葉にするよう、参加者に促す
• 参加者の操作の意図が不明なときは、適切なタイミングで質問する（誘導的な確認をしないように）
• 参加者に原因分析や改善提案をさせない（参加者はUIデザインの専門家ではなく、当てにならない）

3. 参加者の思考や行動をゆがめない（バイアスをかけない）

• 参加者に操作方法を聞かれても答えず、迷っている行動を観察する
• 誘導的な「ここがわかりにくいのですね？」ではなく、オープンに「何を考えていますか？」と尋ねる

参加者の本音を引き出しつつ結果をゆがめない進行には、専門的な技量と細心の注意が必要です。

---

参加者として、どんな人を何人集めるか

1. 想定ユーザーに近い人に参加してもらう

ユーザーテスト（ユーザビリティテスト）では、「誰にテストしてもらうか」が結果を大きく左右します。評価対象物の想定ユーザーに近い人に参加してもらうため、年代や職業といった属性だけでなく、評価対象物や類似サービスの利用経験・利用意向などの条件に基づいて参加者を募集します。

通常は、インターネットアンケートを設計・作成した上で、アンケートパネルに配信して多くの方に回答してもらい、その中から条件に合う人を選定します（スクリーニング）。その候補者に電話して参加日時を調整します（リクルート）。

もし、評価対象物の想定ユーザーとは知識・経験・ニーズが異なる人がテストに参加すると、タスク実行時の思考や判断が実際のユーザーとは異なり、結果の妥当性を疑うことになります。そのため、スクリーニングの条件設定、アンケートの設問・選択肢の設計、リクルート時の電話確認を慎重に行うことが重要です。

2. 5人程度によるテストを、改善のたびに繰り返す

定性的なユーザーテスト（ユーザビリティテスト）の目的は問題の発見ですが、5人の参加者で主要な問題の多く（全体の約85%）を発見できるとされています（Nielsen and Landauer, 1993／下図）。

また、同じUIを評価対象としたテストへの参加者を5人より多く増やしていっても、次第に新たな問題は見つかりにくくなっていきます。同じUIを十数人でテストするよりも、まず5人程度でテストし、見つかった問題を改善し、新たなUIをテストするというサイクルを繰り返すほうが、効率よく品質を高められます。

---

分析・レポーティング

ユーザーテスト（ユーザビリティテスト）では、参加者の行動や発話から、タスクの達成を妨げた原因を分析し、改善案につなげていきます。

1. 行動を観察し、問題を抽出する

イードでは、モデレーターとは別のスタッフが、参加者の行動、ユーザーが迷ったり、立ち止まったりした場面、思考発話、モデレーターからの質問に対する回答をその場で記録します。テスト後、観察メモと、必要に応じて録画データを見返しながら、UI上の問題を抽出します。

確認項目	内容
発生箇所・状況	どのタスク中の、どの画面・ページで、何をしようとしていたときに発生したか
参加者の行動	止まる、戻る、探し回る、迷う、違うところに進む、あきらめるなど
参加者の発話	「意味がわからない」「見つからない」「確信が持てない」など
該当者	その問題に遭遇したのはどの参加者か、何人に共通して見られたか

2. 問題の原因を分析する

発生箇所・状況、参加者の行動・発話から、原因を分析します。

たとえば、タスクを遂行するのに必要なボタンを参加者が押さなかったとき、その原因は「そもそもボタンが目に入らなかったから」かもしれませんし、「ボタンは目に入っていたが、ボタンの文言を読んで押すべきボタンとは判断しなかったから」かもしれません。

なお、このような原因は行動や思考発話から明らかな場合もありますが、そうでない場合は、テスト中にモデレーターが参加者に質問して確認しておく必要があります。根拠なしに断定しないようにしましょう。

また、参加者の行動と発話が一致しないことあります。その場合は、発話より行動を優先して分析します。

3. 問題の深刻度を評価する

発見された問題に対して、その深刻度（影響の大きさ）を評価します。

深刻度	内容
効果	先に進めない、理想のルートからはずれるなど、独力でのタスクの達成を困難にする問題
効率	理解・操作に時間がかかる、（独力で回復できるが）理想のルートからはずれるような問題
満足度	迷わず理解・操作はできるものの、ネガティブな印象や不満を感じるような問題

問題が多数発見された場合、どの問題の改善から手を付けるべきか、優先度の判断に用いられます。

4. 改善案を提示する

改善案は、問題の原因に基づいて作成します。論理的に飛躍した（原因として挙げたことに基づいていない）改善案にならないようにします。

同じ問題に対して複数の改善方法が考えられる場合もあります。改善案が複数考えられる場合は、原因との対応関係を明確にしておきます。

改善案はあくまで仮説であるため、改善案をUIデザイン案に具体化してから、追加のユーザーテスト（ユーザビリティテスト）で問題が解消しているかどうかを確認するとよいでしょう。

---

自社で行うか、専門のリサーチ会社に依頼するか

ユーザーテスト（ユーザビリティテスト）は、社内でも手軽に始められます。一方で、参加者募集や進行、分析には専門的な知識や経験が求められるため、重要な意思決定に活用する場合は専門のリサーチ会社への依頼を検討する企業も少なくありません。

項目	自社で実施	専門のリサーチ会社に依頼
費用	外注費は抑えられる（社内工数はかかる）	外注費がかかる
スピード	社内で調整しやすく、すぐ始めやすい	発注手続きや社外との打ち合わせが必要
評価対象物の理解	深く理解している	学習が必要
参加者	社員や知人を集めると想定ユーザー像からずれやすい上、社員は社外の人より自社商品を知っている	条件に合う参加者をスクリーニングして集められる
進行	作り手が進行すると、ポジティブな方向に誘導しやすい	第三者が比較的中立に進行できる
分析	問題発見や原因分析に経験が求められる	多数の経験を踏まえて分析できる
客観性	開発・運営側の視点や方針、評価対象物への理解の深さが、評価に影響を与えやすい	外部の視点から評価できる
社内説明	「身内の評価」と受け取られやすい	第三者（外部の専門家）の結果として説明しやすい

自社で実施しやすいケース

• まずは小規模に実施し、ユーザーの反応を把握したい
• 日常的な改善のために、短いサイクルで繰り返し実施したい
• 社員や既存顧客など、参加者を確保しやすい
• 結果を改善のヒントとして活用し、大きな意思決定の根拠にはしない
• 社内にユーザーテストの経験を持つ担当者がおり、継続的にノウハウを蓄積したい

専門会社への依頼を検討したほうがよいケース

• リニューアルや大型改修など、結果を重要な意思決定や投資判断に活用する
• 特定の商品の利用者、特定の職種など、条件に合う参加者を自力で集めることが難しい
• テスト設計や進行、観察・分析の経験を持つ担当者がいない
• 発見された問題の背景や原因まで分析したい
• 経営層や関係部署に対して、第三者の視点を含めた根拠を示したい

依頼先を選ぶときの確認ポイント

• 誰がテスト設計・進行・分析を担当するか（ユーザビリティ評価やUXリサーチの経験があるか）
• 対象ユーザーをどのように募集するのか（スクリーニング方法や対応可能な条件）
• 結果報告に、発見された問題だけでなく、その背景や原因の分析が含まれるか
• 問題の深刻度や、改善の方向性まで整理されるか
• 映像記録などの一次データを確認できるか
• 対面・オンラインなど、目的に応じた実施方法を選択できるか

---

テストの実施に必要な期間と費用

1. 期間の目安

ユーザーテスト（ユーザビリティテスト）の実施には、参加者のスクリーニングとリクルーティング、テスト設計、テスト実施、分析・レポーティングまで含めて、一般的には1.5か月程度かかります。

参加者のスクリーニングとリクルートに3〜4週間程度を要し、その期間に並行してテストタスクや質問内容を設計します。テスト実施後は、観察結果や発話内容を分析し、通常2週間程度でレポートを作成します。

参加者の条件が緩い場合や、簡易なレポートでいい場合は、より短期間で実施できることもあります。

2. 費用の目安

ユーザーテスト（ユーザビリティテスト）の費用は主に、評価範囲、参加者の条件と人数、実施方法と環境、レポートの内容によって変わります。

• 評価範囲
  評価対象の画面やページの範囲、実施するタスク数によって、1人あたりのテスト時間と、テスト結果を分析する工数が変わります。たとえば、短い時間で完了するタスクが数個であれば、タスク前後のヒアリングも含めて1人あたり30分で済むかもしれません。一方、時間のかかるタスクがたくさんあれば1人あたり60分以上かかるかもしれません。
• 参加者の条件と人数
  特定の商品・サービスの利用者や、特定の職種の人など、条件が限定されるほど参加者のスクリーニングの難易度と費用が上がります。また、異なるユーザーグループ（たとえば、初心者とヘビーユーザー）ごとにテストしたい場合は、それぞれのグループで参加者を集める必要があるため、リクルートする人数とその費用が増え、テスト結果を分析する工数が増えます。
• 実施方法と環境
  オンラインで実施するか、対面で実施するかによって費用が変わります。対面の場合は、自社の会議室を利用するか、インタビュールームをレンタルするかによっても費用が異なってきます。
• レポートの内容
  発見された問題と原因を整理するだけなのか、問題が発生した状況や改善案まで含めるのかによって工数が変わります。具体的には、評価対象のスクリーンショットと問題・原因の付箋を貼ったMiroボードなのか、一覧形式のExcelファイルなのか、問題ごとに詳細にまとめたPowerPointファイルなのか、といった、必要なアウトプット形式によって工数が異なってきます。

---

調査手法の違い

1. 定性的なテストと定量的なテストの違い

ユーザーテスト（ユーザビリティテスト）には、定性的なものと定量的なものとがあります。

項目	定性的なユーザーテスト（一般的）	定量的なユーザーテスト
目的	問題の所在と原因を特定し、改善策を探る（形成的評価）	使いやすさを数値で測り、比較・判定する（総括的評価）
主なデータ	行動の観察、思考発話、事後ヒアリング	タスク成功率、所要時間、エラー数、満足度スコア
人数の目安	5人程度	統計的な分析に足る人数（数十人規模）
向いている場面	改善点を見つけたい、改善を繰り返したい	リニューアル前後や競合との比較（ベンチマーキング）

本ページでは、より一般的な定性的なユーザーテストを中心に解説しています。

2. 対面テストとリモート（オンライン）テストの違い

ユーザーテスト（ユーザビリティテスト）は、従来から対面で行われてきましたが、最近ではリモート（ZoomやMicrosoft Teamsなどのウェブ会議）でも行われるようになりました。

行うことは基本的に同じですが、対面かリモート（オンライン）かというやり方の違いによって異なってくる点があります。

項目	対面テスト	リモート（オンライン）テスト
参加者	テスト会場の近くに住む・勤務する人に限られる	全国どこからでも参加できる
観察可能な範囲	表情や手の動きを直接見られて、非言語的な戸惑いや違和感に気づける。スマートフォンでの指の迷いや誤タップもわかる	画面と音声が中心。表情、指の迷い、スマートフォンでの誤タップが把握しにくい
コスト	会場費・交通費がかかる	会場費がかからない。地域によってはモデレーターの出張費も不要
リスク・準備	当日の技術トラブルは少ない	通信・音声・画面共有の技術トラブルが起こりうる
情報管理	未公開のプロトタイプを管理しやすい	秘密保持契約を結んでも、スクリーンショットの撮影などを防ぎにくい

表情やスマートフォンでの細かな操作を観察したい場合や、評価対象物の機密性が高い場合は対面テストが適しています。一方、テスト参加者の居住地域を広げたい場合や、1か所での開催では条件に合致する参加者を集めにくい場合はリモートテストが適しています。

ウェブ会議での通信・音声・画面共有などの技術トラブルを極力防ぐため、イードではユーザーテストの前に参加者と接続テストを行っています。ただ、その分、対面テストより実施までに追加の日数を要します。

なお、イードは本社が東京にありますので、対面テストはそこで行うことが多いですが、大阪や兵庫での出張テストの実績もあります。

3. 他の調査・評価手法との違い

手法	何がわかるか	向いている場面
ユーザーテスト	実際の操作で、どこでなぜつまずくか	UI上のわかりにくさ・使いにくさの原因を特定し、改善したいとき
ヒューリスティック評価	専門家が経験則に照らして見つける問題点	短期間・低コストでUI上の問題を洗い出したいとき
アクセス解析	どのページで何が起きたか（数値）	問題のありそうな箇所の見当をつけたいとき
A/Bテスト	2つの案のどちらが成果が高いか	公開後に案を比較して選びたいとき
ユーザーインタビュー	利用の背景、ニーズ、価値観	何を作るべきか、なぜ使われるかを知りたいとき

アクセス解析やA/Bテストでは「何が起きたか」や「どちらがよいか」はわかりますが、「なぜか」はわかりません。ユーザーテスト（ユーザビリティテスト）は、その「なぜ」を明らかにする手法で、想像ではなく事実に基づいた改善策の検討に役立ちます。

また、ユーザーを深く理解し、ユーザーが何を求めているのかを探る場合にはユーザーインタビューが適しています。一方、ユーザーがうまく使えるのかを確かめ、問題があれば改善する場合はユーザーテスト（ユーザビリティテスト）が必要です。

---

ユーザーテストに関するよくあるご質問

Q　ユーザーテストはユーザビリティテストとは違うのですか？

A　いいえ、ユーザーテストとユーザビリティテストは、呼び方が違うだけで同じ手法です。どちらも、想定ユーザーに実際に操作してもらい、つまずく箇所とその原因を明らかにする手法を指します。本ページでは「ユーザーテスト」と表記していますが、「ユーザビリティテスト」と読み替えていただいてかまいません。JIS（日本産業規格）では「ユーザビリティテスト」と言います。なお、ソフトウェアの受け入れテストの1つである「ユーザー受け入れテスト」（UAT）とは異なります。

Q　テストの参加者の人数はどのくらい必要ですか？

A　問題発見・原因究明というUIの改善が目的のテストなら、1回あたり5人程度が目安です。UIの改修後に再度テストを繰り返すことをおすすめします。

Q　テストを実施するには、どのくらいの期間がかかりますか？

A　通常、1.5か月程度です。内訳は、スクリーニング・リクルート（テスト参加者として想定ユーザー像に合致した人を探す）に3～4週間程度（それと並行してテスト設計）、テスト実施後、分析とレポーティングに2週間程度です。スクリーニング条件を緩めたり、レポートを簡素化することで短縮も可能です。

Q　自分たちでテストを行うことはできますか？

A　はい、簡易的なテストであれば可能です。ただし、参加者の確保、テストの設計、進行、結果の分析を適切に行うには専門的なスキルが必要です。

Q　テストはオンライン（リモート）でも実施できますか？

A　はい、できます。オンラインであれば全国から参加者を集められるメリットがあります。一方で、参加者の表情や、スマートフォン上の指の動きが観察しにくいなどの違いがあります。

Q　完成前のプロトタイプでもテストできますか？

A　はい、できます。Figmaなどのプロトタイプでもテストは可能で、早い段階ほどUIの修正が容易です。

Q　アンケートやアクセス解析とは何が違うのですか？

A　アンケートは意見、アクセス解析は「どこで何が起きたか」を定量的に把握します。問題発見のためのユーザーテスト（ユーザビリティテスト）では定量的な把握はできませんが、実際の操作を観察するため、「なぜ起きたか」という原因が把握でき、UIの改善につなげることができます。

Q　評価すべき項目が決まっていなくても相談できますか？

A　はい、ご相談いただけます。現状の課題を伺い、テストで確かめるべきことを整理・提案します。

---