ユーザビリティテストを実施した後、チームが最初に直面する問いがある。「なぜユーザーはそこで詰まったのか」だ。

行動ログには「ボタンAをクリックせず、ボタンBを3回クリックした」と記録される。しかしそこに至るまでユーザーの頭の中で何が起きていたかは、行動だけを観察していても分からない。シンクアラウド・プロトコル（Think-Aloud Protocol）は、この「観察できない思考の過程」を言語として記録する手法だ。

シンクアラウド・プロトコルとは

シンクアラウド・プロトコル（TAP）は、ユーザーがタスクを実行しながら頭に浮かんだことをそのまま声に出してもらう調査手法だ。「発話思考法」とも呼ばれる。

理論的な基盤を提供したのは、心理学者の K. Anders Ericsson と Herbert A. Simon である。1980年に彼らが構築した口述報告のプロセスモデル（“Verbal Reports as Data”, 1980, Psychological Review）は、人間が思考を言語化するメカニズムを認知科学的に解明し、TAP の信頼性を支える根拠となった。Ericsson と Simon のモデルは、人が短期記憶から情報を引き出すときに言語化が比較的自然に行われることを示し、適切な条件下では思考の発話が認知プロセスを大きく歪めないと論じた。

ユーザビリティ領域では Jakob Nielsen が 1990 年代から強力に推進し、現在もコスト対効果の高い定性調査手法として広く使われている。

2種類のTAP：ConcurrentとRetrospective

TAP には実施タイミングが異なる2つのバリアントがある。

Concurrent TAP（同時発話法）

タスクを実行しながらリアルタイムで発話を続ける。思考と行動が同時進行するため、認知的な負荷が高い。しかしその瞬間の思考が記録されるため、データの鮮度が高いのが最大の強みだ。

主な特徴：

データ収集効率が高い（タスクと発話が1セッションで完結）
発話に注意が向くことでタスクパフォーマンスが変化する可能性がある
ファシリテーターがリアルタイムで沈黙を拾いやすい

Retrospective TAP（回想発話法）

タスクを一通り終えた後、録画を見返しながら「このとき何を考えていたか」を語ってもらう。認知的負荷が低く、タスク中の自然な行動が保たれる利点がある。一方で、記憶の再構成が起こりやすく、発話がタスク完了後の合理化になるリスクがある。

観点	Concurrent TAP	Retrospective TAP
発話タイミング	タスク実行中	タスク完了後
認知的負荷	高い（二重タスク）	低い
データの鮮度	高い	低い（記憶の再構成）
推奨場面	UIのマイクロインタラクション検証	複雑な操作フローの全体把握

どちらが優れているかという問いより、検証したいインサイトの種類で選ぶのが実態に近い。

実施手順

Step 1：タスクシートの設計

タスクシートはTAPの品質を決める最重要要素だ。ユーザーにどのシナリオを実行してもらうかを、具体的で自然な文脈として書く。

良いタスクの条件：

「〜してください」という指示形ではなく、「あなたは〜の状況にいます。〜を探しています」という状況文として書く
正解の手順を含意しない中立的な文体にする
1タスク30分以内に完了できるスコープに絞る

悪い例：「ナビゲーションメニューからカートに商品を追加してください」良い例：「誕生日プレゼントとしてブルーのマグカップを購入しようとしています。購入手続きを完了してください」

Step 2：イントロダクション（事前説明）

セッション開始前の説明が、その後の発話量を左右する。ユーザーに伝えるべきことは2つだ。

「製品のテストであり、あなたの能力のテストではない」 という点と、「間違えることも含めて、すべての思考を声に出してほしい」 という点だ。

多くのユーザーは、「正しい答えを言わなければ」「賢く見せなければ」という意識から発話を抑制する。この意識を緩めるためには、ファシリテーター自身がまず練習セッションを1〜2分やって見せると効果的だ。「例えばこんな感じで、コーヒーを入れながら声に出してみます」という自己実演が、ユーザーの心理的ハードルを下げる。

Step 3：タスク実行と発話の促進

タスク実行中、ファシリテーターの役割は最小限の介入で発話を維持することに絞られる。

沈黙が30秒以上続いたら、「今どのようなことを考えていますか?」と中立的に問いかける。「なぜそのボタンをクリックしましたか?」という過去形の問いかけは、行動への介入になるため避ける。

誘導しない問いかけの例：

「今考えていることを教えてください」
「声に出し続けてもらえますか」
「今どこを見ていますか」（視線追跡なしの場合）

誘導になる問いかけの例（避ける）：

「分かりにくかったですか?」
「このボタンは見つけにくかったですか?」
「何か探していましたか?」

Step 4：データ記録

録音・録画に加え、ファシリテーターまたは記録係が以下を手書きでメモする。

タスク完了時間（秒単位）
タスク成功・失敗・部分成功の判定
発話した具体的な言葉（特に感情を示す言葉）
行動と発話の不一致（「簡単です」と言いながら3回間違えるなど）

記録係がいない場合は録画に徹し、分析は後から行う。セッション中に「これは重要なインサイトだ」と解釈まで踏み込まない。解釈は分析フェーズで行う。

Step 5：デブリーフ（セッション後ヒアリング）

タスク完了後、5〜10分のデブリーフで補足情報を収集する。Concurrent TAP の場合、発話を意識していたことで「言えなかった思考」が存在する可能性がある。

有効な質問：

「今日体験した中で、最も印象に残ったことはどこですか?」
「もし友人に使い方を教えるとしたら、どこで詰まりそうだと思いますか?」
「全体を通じて、うまくいったと感じた部分はどこですか?」

分析：インサイトの抽出

録画の書き起こしとタグ付け

録画を書き起こしたテキストに対して、以下のカテゴリでタグを付ける。

カテゴリ	例
混乱・困惑	「えっ、これ何?」「どこにあるんだろう」
期待の不一致	「ここをクリックすると戻ると思った」
正の反応	「あ、これ便利」「なるほど」
仮説・推測	「たぶんここかな」「いつもはこうするから」
諦め・回避	「もういいや、別の方法でやります」

同じカテゴリの発話が複数のユーザーに見られる場合、それは設計上の構造的な問題である可能性が高い。

アフィニティダイアグラムとの組み合わせ

複数ユーザーのTAPデータを統合する際は、アフィニティダイアグラムが有効だ。発話の書き起こしを付箋に転記し、類似パターンでグルーピングすることで、個別の発言から「繰り返し現れるテーマ」を浮かび上がらせる。

よくある失敗パターン

失敗1：沈黙に耐えられず誘導してしまう

ファシリテーターが沈黙を埋めようとして「難しかったですか?」と聞く。これは観察ではなく誘導だ。沈黙はユーザーが考えている証拠であり、データの一部だ。30秒を目安に、中立的な促しのみを行う。

失敗2：ユーザーの意見を「修正」しようとする

「実は、このボタンはこういう意味なんです」と説明してしまうケースがある。TAPのセッション中にプロダクトの使い方を教えてはならない。ユーザーの誤解こそが設計上の問題を示すデータだ。

失敗3：発話の質よりタスク完了を優先する

「タスクを最後まで完了してもらう」ことが目的になり、発話が止まってもそのまま進めてしまう。TAPのゴールはタスク完了ではなく、思考プロセスの記録だ。発話が止まったら、タスクを中断してでも声に出す習慣を取り戻してもらう。

失敗4：分析を「印象」で終わらせる

「全体的に使いにくそうだった」という印象で報告を終わらせる。TAPデータは、発話した具体的な言葉と、それが発生したタスクの場面・タイミングとセットで扱わなければ、設計改善に直接結びつかない。「Step 3のドロップダウン選択時に、4名中3名が『どこにあるのか分からない』と発話した」という粒度で記録する。

ユーザビリティテストの他手法との位置づけ

手法	測定対象	TAPとの関係
Desirability Testing	感情的印象・審美的評価	補完：TAPで操作性を、DTで印象を測る
Test Card 実験設計法	仮説の反証可能性	前後関係：テストカードでTAPの設計を構造化できる
ヒューリスティック評価	UIの原則違反	代替：専門家レビューでユーザーテストを削減できるが、実際の発話は代替不可
アイトラッキング	視線移動・注視点	組み合わせ：TAPに視線データを加えると思考と視線の対応が分析できる

AI録画ツールとの組み合わせ

Otter.ai・Notion AI・Fireflies など、発話の自動書き起こしと要約機能を持つツールを使うと、録画からインサイト抽出までの時間が大幅に短縮できる。特に英語での実施ではこれらのツールの精度が高い。

日本語での利用では、書き起こしの誤変換が分析を誤らせるリスクがある。自動書き起こしをそのまま分析に使わず、重要な発話は必ず手動で確認することが原則だ。

ただし、ツールに依存しすぎると「要約されたインサイト」が生成される一方で、「ユーザーが実際にどの言葉を使ったか」という生のデータが失われる。TAP の価値は、設計者が想定しなかった言語でユーザーが語る瞬間にある。ツールはその記録を補助するものであり、分析を代替するものではない。

まとめ

シンクアラウド・プロトコルは、ユーザーの行動の背後にある思考を記録する最も直接的な手法だ。特別な機材も不要で、スマートフォンの録画と適切なタスクシートがあれば実施できる。初期フェーズのプロトタイプ検証から完成品の最終確認まで、幅広い段階で使える。

重要なのは、ユーザーの発話を「フィードバック」として解釈しないことだ。「使いにくい」という発言は意見ではなく、設計の構造的な問題が引き起こした認知的な摩擦の証拠だ。その発言がどのタスク・どの操作ステップで生じたかと組み合わせて初めて、改善のための情報になる。

TAPで収集したデータは、次の設計サイクルの問いを立てる材料になる。「なぜそこで詰まったのか」への答えを持って、チームは問題定義フェーズに戻ることができる。

シンクアラウド・プロトコル — ユーザーの思考を声にするテスト手法