「作ってから検証しよう」——この順番が大きな手戻りを生む。
開発には時間とコストがかかる。作り込んでから「ユーザーが求めていない」と気づいても遅い。方向転換は困難で、沈没コストが判断を鈍らせる。
コンセプトテストは作る前に検証する。アイデア段階で、ユーザーが「欲しい」と思うか、「理解できる」か、「使いたい」と感じるかを確認する。開発前に方向性を検証し、失敗のリスクを下げる。
1. 手法の定義
新しい製品・機能・サービスのコンセプトをユーザーに提示し、受容性・理解度・購入/利用意向を検証する調査手法。
実際の製品ではなく、コンセプトの説明（文章、ビジュアル、動画等）を見せて反応を収集する。開発前に「作るべきか」「どう作るべきか」を判断する。
2. いつ使うか
適している場面
- 新製品の企画段階: 開発前に方向性を検証
- 新機能の優先順位付け: 複数案のどれを作るか
- メッセージングの検証: 価値提案が伝わるか
- 価格感度の初期確認: いくらなら払うか（初期的な受容感触を見る）
向いていない場面
- 操作性の検証 → ユーザビリティテスト
- 詳細なUIの評価 → ユーザビリティテスト
- 行動の予測 → コンセプトへの好意と実際の行動は異なる
3. 設計判断の核
「欲しい」と言っても買わない——コンセプトテストの限界を知る。
ユーザーが「いいね」「使いたい」と言っても、実際に使うとは限らない。コンセプトテストは「方向性の検証」であり、「成功の保証」ではない。
よくある誤解 「コンセプトテストで好評ならヒットする」
実際 態度（言うこと）と行動（すること）は別。コンセプトテストは「明らかな失敗」を避けるためのスクリーニング。成功を約束するものではない。
4. 調査タイプ
| 軸 | 内容 |
|---|---|
| データ | 定性 + 定量 |
| 対象 | 態度（反応・意向） |
| サンプル | 定性: 5〜10人（反応の理由を深く理解）、定量: 100人以上（傾向の安定性を確認） |
| 実施フェーズ | Define / Design（企画〜設計初期） |
手法のポジション
製品の成熟度
↑
A/Bテスト（リリース後）
↑
ユーザビリティテスト（プロトタイプ）
↑
コンセプトテスト（アイデア段階）
→ 開発の進捗
コンセプトテストは最も早い段階で実施。方向性を固めてから開発に進む。
5. 実施プロセス
1. コンセプトの明確化
コンセプトの構成要素
- ターゲット: 誰のためか
- 課題: 何を解決するか
- 解決策: どう解決するか
- ベネフィット: 何が得られるか
- 差別化: なぜこれを選ぶか
2. 提示物の作成
コンセプトボード
- 1枚の資料にまとめる
- ビジュアル + テキスト
- 簡潔に（読み込まないと理解できないのはNG）
提示方法のバリエーション
- 文章のみ
- ビジュアル + 文章
- 動画
- ランディングページ風
3. テスト実施
定性（インタビュー）
- コンセプトを見せる
- 理解度を確認（「何のサービスかわかりましたか？」）
- 反応を聞く（「どう思いましたか？」）
- 利用意向を確認（「使いたいと思いますか？」）
定量（サーベイ）
- 複数のコンセプトを比較
- 5段階や7段階のスケールで評価
- 購入/利用意向を数値化
4. 分析
- 理解度: コンセプトが伝わっているか
- 魅力度: 惹かれるか
- 独自性: 他との違いが明確か
- 利用意向: 使いたいと思うか
5. 判断
「4. 分析」の結果をもとに、Go（開発に進む）・Pivot（伝え方かコンセプトを作り直して、もう一度テストする）・Kill（このコンセプトは中止）のどれかを選ぶ。どれとも決められないときは保留とする。保留は判断をやめることではなく、足りない材料を足してから、同じ3つを選び直すことである。
線はテストの前に引く
「どうなったら次に進むか」を、コンセプトを明確化する段階（このプロセスの1）で書き出しておく。書き出すのは、次のような一文である。
- 参加者のうち何人以上が、説明を足さずに用途を言えたら進むか
- 利用意向の答えを「使いたい」「条件つきで使いたい」「使わない」の3つに分けて記録し、「使いたい」が何人以上なら進むか（段階つきのスケールを使う場合は、何段階以上を「使いたい」と数えるかも先に決める。有料の製品なら「買いたいか」も同じ形で線を引く）
- こちらが想定した課題と同じ使い道を、何人以上が自分から語ったら、課題の置き方は外れていないと見なすか
線に達したかどうかは「以上」で見る。ちょうど線と同じ人数なら達したものとして扱う。線は、達したか届かなかったかという粗い合図として使う。参加者が1人違えば結果が入れ替わりうることは承知のうえで先に決めておき、細かい差の意味は後述の「理由を読む」側で補う。サーベイを、割合で線を書けるだけの人数（「4. 調査タイプ」の目安では100人以上）で行う場合は、人数ではなく割合で同じ形の線を書く。
この数値に一般的な正解はない。方向を外したときに失う開発コストが大きいものほど線を高くする（必要な人数を増やし、「使いたい」と数える段階も上げる）。作り直しが軽いものは低くてよい。
結果を見てから線を引くと、判断はGoの側へ流れる。手元にあるのは、自分たちが通ってほしいと思って作ったコンセプトである。だから、好意的な回答だけを拾う読み方は後からいくらでも作れてしまう。線を先に引くのは、その余地をなくすためである。だから線は口頭で決めず、コンセプトボードと同じ場所に書いて関係者に見せておく。テストのあとで線を動かすなら、動かした理由も一緒に残す。
判断を分ける3つの観点
「4. 分析」で見た4項目を、判断では次の3つに組み直す。魅力度と利用意向は、どちらも「使いたいと思ったか」を測っているので受容性としてまとめる。独自性は3つの観点には入れず、受容性が線に届かなかったときに「他との違いが伝わっていなかったのではないか」を見直す手がかりとして読む。
| 観点 | 何を見るか | 低かったときに疑う対象 |
|---|---|---|
| 理解度 | 説明を足さずに「何をするものか」を言えた人がどれだけいたか | 提示物（伝え方） |
| 受容性 | 惹かれたか、使いたいと答えたか（魅力度・利用意向） | コンセプトそのもの |
| 想定との合致 | 参加者が語った使い道が、こちらの想定とどれだけ合っているか | 課題設定（何を解決すべきと決めたか） |
3つ目の「想定との合致」は分析の4項目には無いので、材料を自分で用意しておく。3のインタビューに「どんなときに使いますか」を1問足し、参加者が語った使い道をそのまま書き留めておけばよい。
読む順番は理解度が先である。何をするものか伝わっていない相手の「使いたい」は、こちらのコンセプトへの評価ではない。その場で相手が想像した別のものへの評価である。
Go / Pivot / Kill の分かれ目
PivotとKillを分けるのは、受容性の高さそのものではない。受容性が低かった理由が「理解されていない」のか「理解されたうえで要らないと言われた」のかで分かれる。この2つは「反応が悪い」という同じ見え方をするが、次にやることは逆になる。
- Go: 理解度・受容性・想定との合致が、どれも事前に引いた線に達している。開発に進む。ただしこれは「明らかな失敗ではない」という判断であり、成功の見込みではない（「3. 設計判断の核」を参照）
- Pivot（伝え方を作り直す）: 参加者が用途を言い当てられない。理解度が線に届かないときは、受容性がどうであってもこれを選ぶ。理解されていない以上、コンセプトの良し悪しはまだ測れていないからである。提示物を作り直し、同じコンセプトで再テストする
- Pivot（コンセプトを寄せ直す）: 参加者は用途を言えるが、語った使い道がこちらの想定と違う。その使い道のために、参加者が今すでに他の道具や手作業でしのいでいるなら、困りごとは実在していて、こちらの課題設定のほうがそれを外している。1で書いた「課題」を、参加者が語った使い道から立て直し、解決策とベネフィットも書き直して、あらためてテストする。受容性が線に達していても同じである。使いたいと言った人が想像しているものは、こちらが作ろうとしているものではないので、そのまま作れば期待外れになる。一方、しのいでいる様子も無い（そもそも困っていない）なら、その使い道にも需要は無く、寄せ直す先が無い
- Kill: 受容性が線に届かず、その理由が「理解されていない」でも「使い道の想定が違っていた」でもない。つまり、何をするものか正しく伝わり、使い道の想定も合っているのに要らないと言われている。あるいは、語られた別の使い道にも困りごとが無く、寄せ直す先も無い。コンセプトそのものが求められていないため、伝え方を変えても結果は変わらない。中止する。ただし「他と同じに見えた」という声が繰り返し出ているなら、違いが伝わっていないだけの可能性があるので、先にPivot（伝え方を作り直す）を試す
サンプルが小さいときの扱い
コンセプトテストは企画段階で行うため、参加者は少ない（定性で5〜10人）。この規模では割合を細かく比べない。
どれを選ぶかは、まず上の3観点と線で決める。理由を読むのは、線との差が1人か2人しかないときと、線の判定と聞き取りの中身が食い違うときである。差が小さいときに数だけで決めないのは、参加者が1人違うだけで「10人中6人」は5人にも7人にもなるためである。
このとき読むのは割合ではなく理由である。用途を言えなかった人は、コンセプトのどこでつまずいたか。使いたくないと答えた人は、代わりに何を使っていると言ったか。同じ理由が何人からも繰り返し出てくるなら、それがPivotとKillのどちらを選ぶかの根拠になる。理由がばらけて根拠にならないなら保留とし、参加者を数人足して同じテストを続ける。参加者を足したときは、線も同じ割合で引き直す（10人で6人の線なら、13人では8人）。足しても同じ理由が集まらないなら、聞き方が理由を引き出せていないので、質問を作り直して聞き直す。
複数のコンセプトを比べる場合も、「使いたい」と答えた人数が1人か2人違うだけなら優劣の判断には使わない。片方にだけ「今こう困っている」という具体的な理由が集まっているときに、そちらを先に作る。
Pivotは無限に繰り返さない。提示物やコンセプトを作り直して再テストしても、同じ理由で線に届かないなら、直している場所が原因ではない。そこでKillにする。
定量（サーベイ）を、割合で線を書けるだけの人数で併用した場合は、割合そのものを比べられる。ただし、なぜその回答になったのかは定性側にしか出てこない。割合が線に達していても理由を説明できないなら、保留にして、定性で数人に理由を聞き直してから決める。
実施の前後で抜けが無いかは、「6. 実務チェックリスト」で確認する。
6. 実務チェックリスト
最低ライン（Must - これがないと失敗）
理想ライン（Better - プロの品質）
7. 関連リンク
関連するUXリサーチ手法
関連するUX心理
- 社会的望ましさバイアス
- 意図と行動のギャップ
関連する用語
まとめ
コンセプトテストは開発前に製品・機能の方向性を検証する手法である。コンセプトボードやプロトタイプを見せ、理解度・魅力度・利用意向を確認する。「作ってから検証」では遅い——アイデア段階で失敗を検出し、手戻りを防ぐ。ただし「好評=成功」ではない。態度と行動は別物であり、コンセプトテストは「明らかな失敗を避ける」スクリーニングとして位置づける。
