思考発話法とは？やり方や活用方法も解説（プロトコル分析：ユーザビリティ調査：手順など）

思考発話法は、利用者が画面を操作するときに考えていることを言葉にしてもらい、サービスや製品の使いやすさを調べる調査手法です。

アンケートやアクセス解析だけでは見つけにくい迷い、誤解、不安を把握できるため、Webサイト、アプリ、業務システム、ECサイトなどのユーザビリティ調査で活用されています。

ただし、参加者に自由に話してもらうだけでは、必要な情報が十分に集まらないこともあります。

適切な課題設計、進行役の声かけ、発話内容の分析までを一連の手順として整えることが重要でしょう。

この記事では、思考発話法の意味、具体的なやり方、プロトコル分析の進め方、実務での活用方法をわかりやすく紹介します。

思考発話法の意味と調査で得られる結論

それではまず思考発話法について解説していきます。

利用中の思考を言語化する調査手法

思考発話法とは、参加者が操作中に頭の中で考えていること、見ている場所、判断の理由、戸惑いをできる限り口に出してもらう方法です。

英語ではThink Aloud Protocolと呼ばれ、日本語では発話思考法、発話プロトコル法などと表記される場合もあります。

たとえば予約サイトで日程を選ぶ場面では、「このカレンダーは空き状況を示しているのかな」「次へ進むボタンが見つからない」「料金は後から変わるのではないか」といった心の動きが現れます。

画面録画だけでは、参加者が何に注目していたのか、なぜ操作を止めたのかまでは判断しにくいものです。

発話を記録すれば、行動の背後にある認知や期待を読み取れるようになります。

つまり思考発話法は、単に操作の成否を確認するものではありません。

利用者がどのように情報を理解し、どの時点で判断に迷うのかを捉えるための定性調査と考えるとわかりやすいでしょう。

ユーザビリティ上の課題を発見しやすい理由

ユーザビリティとは、利用者が目的を効率よく、迷わず、満足して達成できる度合いを指します。

思考発話法では、完了までの時間やクリック回数に加え、利用者自身の言葉から問題の原因を探れます。

たとえば申込フォームの離脱が多い場合でも、入力項目が多いからなのか、必須項目がわかりにくいからなのか、個人情報の扱いに不安を感じるからなのかで改善策は変わります。

数値だけを見ていると、原因を推測だけで決めてしまう危険があります。

参加者の発話は仮説を検証する材料となり、改善の優先順位を考える際にも役立ちます。

観察法やインタビューとの違い

観察法は、参加者が何をクリックし、どこで立ち止まり、どのような順序で操作したかを確認する方法です。

一方でインタビューは、利用後に感想や印象、要望を聞き取る方法になります。

思考発話法はその中間に位置し、実際に操作している最中の考えを取得できる点が特徴です。

利用後のインタビューでは、参加者があとから理由を補って説明することがあります。

そのため、操作時点の気持ちや視線の動きと異なる回答になる可能性もあるでしょう。

手法	主にわかること	向いている場面
行動観察	クリック、操作時間、失敗箇所	導線や画面遷移の確認
思考発話法	判断理由、理解、迷い、不安	問題の原因を深く探る場面
事後インタビュー	印象、満足度、利用意向	体験全体の評価を聞く場面
アンケート	回答傾向、比較可能な評価	多数の利用者の意見収集

これらを組み合わせれば、行動、理由、感想を多角的に把握できます。

思考発話法の実施準備

続いては思考発話法を始める前の準備を確認していきます。

調査目的と検証仮説の整理

思考発話法を始める前に、何を明らかにしたいのかを具体化します。

「サイトを使いやすくしたい」という目的だけでは、観察すべき内容が広がりすぎてしまいます。

「初めて訪れた利用者が料金プランを理解できるか」「購入手続きで配送条件を見つけられるか」「管理画面で月次レポートを作成できるか」のように、利用場面と達成したい行動を定めることが必要です。

あわせて、課題になりそうなポイントを仮説として用意します。

ただし仮説は参加者を誘導するためではなく、観察の焦点を整えるためのものです。

調査前に答えを決めてしまわず、予想外の発話も重要な発見として扱うことが欠かせません。

参加者条件と人数の考え方

参加者は、実際にサービスを利用する可能性が高い人から選びます。

法人向け会計ソフトであれば経理担当者や個人事業主、子育て支援サービスであれば保護者など、利用文脈に近い条件を考慮します。

社内の関係者だけで試すと、業界用語や社内事情を知っているため、一般の利用者が感じる難しさを見落とすことがあります。

定性調査では、必ずしも大人数が必要とは限りません。

まずは5人前後を目安に実施し、同じ問題が繰り返し見つかるかを確かめる進め方がよく用いられます。

対象者の属性が大きく異なる場合は、属性ごとに必要な参加者を確保するとよいでしょう。

タスクと調査環境の設計

タスクとは、参加者に実行してもらう具体的な課題です。

「商品を探してください」よりも、「予算五千円以内で、翌日に届く贈り物を一つ選んでください」のように、目的と条件を含めたほうが自然な判断を観察できます。

ただし、達成経路まで細かく指示すると、画面の問題を見つけにくくなります。

参加者が自分で探し、比較し、決められる余地を残すことが大切です。

オンラインで実施する場合は、画面共有、音声録音、同意取得、通信環境を事前に確認します。

対面であれば、操作用端末、録画機材、観察者の位置、参加者が落ち着いて話せる環境を整えます。

思考発話法のやり方と進行手順

続いては思考発話法の具体的な手順を確認していきます。

開始時の説明と同意取得

調査の冒頭では、参加者に目的と進め方を簡潔に説明します。

このとき、「あなたの操作能力を試す調査ではなく、サービスのわかりやすさを確認する調査です」と明確に伝えることが重要です。

評価されると感じると、参加者は失敗を隠したり、遠慮して本音を話さなくなったりします。

録画や録音を行う場合は、取得する情報、利用目的、保管方法、公開範囲を説明し、同意を得なければなりません。

個人情報や機密情報を入力しないテスト用の環境を用意する配慮も必要でしょう。

安心して迷いや違和感を話せる状態をつくることが、質の高い発話データにつながります。

発話を促す進行役の声かけ

参加者には、画面を見て考えたことをできるだけその場で話してもらいます。

「見えているものや、次にしようと思っていることを声に出してください」と最初に例を示すと、発話の負担が下がります。

途中で沈黙が続いた場合は、「今、どのようなことを考えていますか」「この表示を見てどう感じましたか」と中立的に促します。

「このボタンを押すべきではありませんか」のような誘導は避けるべきです。

進行役の言葉が答えを示してしまうと、本来の導線では起きるはずの迷いを消してしまいます。

場面	望ましい声かけ	避けたい声かけ
沈黙が続く	今考えていることを教えてください	次は右上の項目ですね
操作を迷う	どのように選ぼうとしていますか	そのメニューを開いてください
失敗した	今の画面をどう受け取りましたか	正しい操作は別にあります
完了した	完了したと判断した理由を教えてください	簡単でしたよね

観察と終了後の振り返り

実施中は、発話内容だけでなく、操作の順序、カーソルの動き、停止時間、戻る操作、表情の変化も記録します。

観察者が複数いる場合は、進行役と記録担当を分けると、聞き漏らしを減らせます。

タスク終了後には、利用中に気になった点、期待と違った点、改善してほしい点を短く聞きます。

ただし、終了後の質問を長くしすぎると、当初の目的から話題が広がりやすくなります。

調査終了後すぐに、進行役と観察者で気づきを共有する時間を設けることも有効です。

録画を見返す前の印象を残しておくと、後の分析で注目すべき場面を絞りやすくなります。

プロトコル分析による発話データの整理

続いてはプロトコル分析によるデータ整理を確認していきます。

録音と画面記録の書き起こし

プロトコル分析では、録音した発話と操作記録を時系列で書き起こします。

発言だけを文字にするのではなく、クリック、画面遷移、スクロール、長い沈黙、入力のやり直しなども対応づけると、状況を正確に理解できます。

たとえば「これで申し込みかな」と言った直後に戻るボタンを押しているなら、完了画面の認識に不安があった可能性を検討できます。

書き起こしは手間がかかりますが、印象だけで課題を判断しないための基盤です。

発話、行動、画面状態を同じ時間軸で扱うことが、プロトコル分析の精度を左右します。

発話の分類とコード化

書き起こした内容は、意味の近い発話ごとに分類します。

分類の観点には、理解できた、意味が不明、選択肢を比較している、情報を見落とした、不安を感じた、期待と異なった、といったものがあります。

この分類作業はコード化とも呼ばれます。

最初から細かく分類しすぎると、整理そのものが目的になってしまいます。

調査目的に合わせて、改善判断に使える粒度から始めるとよいでしょう。

課題の重要度と改善優先順位

見つかった問題は、発生頻度だけで順位を決めるものではありません。

目的達成を妨げる深刻さ、事業への影響、修正に必要な工数も含めて評価します。

一人だけが迷った問題でも、購入や申込を断念する重大な障害であれば、優先的に改善する価値があります。

反対に、多くの人が気づいた軽微な表現の違和感は、ほかの改善とあわせて対応する判断も考えられます。

評価観点	確認する内容
頻度	複数の参加者に同じ問題が起きたか
深刻さ	目的達成、購入、申込、登録を妨げるか
影響範囲	特定画面だけか、多くの導線に関係するか
改善難易度	文言修正で済むか、機能改修が必要か

思考発話法の活用方法と実務上の注意点

続いては思考発話法の活用方法と注意点を確認していきます。

WebサイトとECサイトの改善

Webサイトでは、情報を探す際の迷い、見出しの理解、問い合わせ導線の発見しやすさを確認できます。

ECサイトでは、商品比較、絞り込み、カート投入、送料確認、決済入力といった購買プロセスの調査に向いています。

参加者が「この商品は自分の条件に合うのかな」と繰り返す場合、商品情報の並びや検索条件に不足があるかもしれません。

購入ボタンが目立っていても、返品条件や到着予定日がわからず不安になれば、コンバージョンにはつながりにくいでしょう。

利用者の不安を解消する情報が、必要なタイミングで見えているかを確認できる点が大きな利点です。

アプリと業務システムへの応用

スマートフォンアプリでは、画面が小さいため、アイコンの意味や操作導線の理解が特に重要になります。

利用者が機能名を誤解していたり、スワイプで操作できることに気づかなかったりする問題は、ログ分析だけでは把握しにくいことがあります。

業務システムでは、担当者が独自の回避手順を使っている場面が発見されることもあります。

たとえば、検索機能を使わずに一覧を手作業で確認しているなら、検索条件の名称や配置に課題がある可能性があります。

現場の業務フローを理解したうえでタスクを設計すれば、画面上の使いにくさだけでなく、業務効率の改善にもつながります。

発話が行動に与える影響への配慮

考えを声に出すことは、普段は無意識に行う操作を意識させる可能性があります。

そのため、通常より操作に時間がかかったり、慎重になったりすることがあります。

これを反応性と呼び、思考発話法の限界の一つとして理解しておく必要があります。

また、話すことが苦手な参加者には負担が大きく、発話量の違いをそのまま理解度の違いと判断してはいけません。

必要に応じて、操作後のインタビュー、アクセスログ、ヒートマップ、アンケートなどと組み合わせると、結果の偏りを抑えやすくなります。

思考発話法を活かすためのまとめ

思考発話法は、利用者が操作中に考えていることを言葉にしてもらい、使いにくさの原因を深く探るユーザビリティ調査です。

行動ログだけでは見えない迷い、誤解、不安、期待とのずれを確認できるため、Webサイト、アプリ、ECサイト、業務システムの改善に役立ちます。

実施時は、調査目的に沿ったタスクを設計し、参加者が評価されていると感じないように説明することが大切です。

進行役は発話を促しながらも、答えや操作を誘導しない姿勢を保つ必要があります。

収集した発話は、操作記録とあわせて書き起こし、理解不足、不安、見落としなどの観点で分類します。

そのうえで、問題の頻度、深刻さ、影響範囲を評価すれば、改善の優先順位を決めやすくなるでしょう。

利用者の言葉から理由を理解し、画面や導線の改善へ結びつけることが、思考発話法を成果につなげるポイントです。