MaxDiff（最大差異尺度）の設計ガイド — 優先順位を測る

「どの機能が一番優先順位高いですか？」と聞いて、リッカートで 全項目が『非常に重要』に並んだレポート——リサーチを 1 年もやっていれば、一度は出くわす景色です。「全部重要って言ってる…意思決定に使えない…」と頭を抱える瞬間。

この 天井効果（Ceiling Effect） を構造的に回避する手法が、MaxDiff（最大差異尺度、Best-Worst Scaling）です。本稿では、リッカートで優先順位がつかない理由から、MaxDiff の基本構造、実験デザインの作法、サンプルサイズの判断、スコア計算（カウント vs 階層ベイズ）、コンジョイント・PSM との使い分けまでを、実装ベンダーの現場と学術原典の両方 を踏まえて整理します。

1. なぜリッカートでは優先順位がつかないか

「重要度を 5 段階で評価してください」と 10 項目並べて聞くと、ほとんどの項目に『重要』『非常に重要』が並びます。これがリッカート尺度の構造的な弱点です。

主な原因は 3 つ:

• 天井効果: 回答者は「どれも大事」と感じている時、上限近くに張り付く。10 項目全部 5 点なら、優先順位は識別できない
• 社会的望ましさバイアス: 「セキュリティ」「品質」「サポート」など、否定しにくい項目は実際の優先度以上に高く出る
• 回答負荷の手抜き: 10 項目に 1 つずつ星をつける作業は単調で、後半は適当になる

結果として、「全部重要」というデータが集まり、意思決定に使えない という状況に陥ります。

詳細は リッカート尺度の設計ガイド でリッカート自体の使い方を扱っていますが、「順位をつけたい」用途にはリッカートは構造的に不向き——これが MaxDiff を使う動機です。

2. MaxDiff の基本構造 — ベスト & ワーストを選ぶ

MaxDiff は、1 度に 4〜5 項目を提示し、最も重要なもの（ベスト）と最も重要でないもの（ワースト）を選んでもらう 手法です。これを 10〜15 ブロック繰り返すことで、各項目の相対的な優先順位を統計的に推定します。

設問の見え方

例: 10 項目を比較したい場合、回答者には次のような画面が 12 回表示されます。

次の 4 項目のうち、最も重要なものと最も重要でないものを 1 つずつ選んでください。

[ ] 価格の安さ        最も重要 [○]  最も重要でない [ ]
[ ] サポート品質      最も重要 [ ]  最も重要でない [○]
[ ] 機能の豊富さ      最も重要 [ ]  最も重要でない [ ]
[ ] 操作のしやすさ    最も重要 [ ]  最も重要でない [ ]

各回答者は 項目を直接的に比較せざるを得ない ため、リッカートのような「全部 5 点」の逃げ道がありません。結果として、項目間の相対的な強弱が明確に出ます。

なぜこの形式が機能するのか

Louviere, J. J., & Woodworth, G. (1990). Best-worst analysis が示した重要な洞察は、「相対的な選択は絶対評価より人間にとって自然」 という心理学的な事実です。我々は「これは 7 点」と決めるのが苦手な一方で、「A と B、どっちが好き？」には即答できます。MaxDiff はこの認知特性を素直に使った設計です。

3. 実験デザイン — 不完備ブロックデザインの作法

MaxDiff の核心は 実験デザイン です。10 項目を比較するときに、すべての組合せ（45 通り）を回答者に見せるわけにいかないので、Balanced Incomplete Block Design（BIBD、平衡型不完備ブロックデザイン） で項目をランダムに分散させます。

設計の基本ルール

• 1 ブロックに 4〜5 項目: 多すぎると選択が困難、少なすぎると比較情報が薄い
• 各項目が同じ回数登場する: 10 項目を 12 ブロックに分散するなら、各項目は約 5 回登場
• 各項目ペアが同じ回数共起する: 「価格」と「サポート」が同じブロックに出る回数を均等化
• 項目位置をランダム化: 表示順効果を防ぐ

実装の現実

完璧な BIBD を手計算で作るのは現実的でないため、専門ツール を使うのが標準です:

• Sawtooth Software Lighthouse / Discover: MaxDiff の業界標準ベンダー、デザイン自動生成
• R パッケージ support.BWS: オープンソース、研究用途で広く使用
• SurveyEngine / Conjoint.ly: クラウド型、テンプレート対応

これらは入力した項目数からブロック設計を自動生成します。ゼロから手作りしない のが鉄則です。

4. サンプルサイズと反復回数の決め方

「何人聞けば十分か」「1 人に何回ブロックを見せるか」は MaxDiff の実務で最も悩む論点です。

反復回数（1 人あたりブロック数）の目安

• 項目数 × 3 / 4 が業界の経験則。例: 10 項目なら 1 人あたり 7〜8 ブロック、15 項目なら 11〜12 ブロック
• 反復が少なすぎると個人レベル推定が不安定になり、多すぎると回答負荷で離脱率が上がる
• 回答時間 5〜10 分を上限 に逆算するのが実務感覚

サンプル数の目安

• 集団レベル分析のみ: N=200〜300 で十分
• セグメント別の階層ベイズ推定: セグメントあたり N=100 以上、合計 N=400〜500
• 個人レベル推定（重要顧客の詳細分析）: N=500 以上

Orme, B. K. (2010). Getting Started with Conjoint Analysis (2nd ed.) は、MaxDiff のサンプル設計を Sawtooth Software の実装経験から整理した実務書で、現場での標準ガイドラインとして参照されます。

詳細は アンケートのサンプル数の決め方 でサンプルサイズ計算の基礎を扱っています。

5. スコア計算 — カウント分析 vs 階層ベイズ

MaxDiff の回答データから「各項目の優先度スコア」を計算する方法は、大きく 2 つあります。

カウント分析（簡易版）

• 各項目について「ベストに選ばれた回数 − ワーストに選ばれた回数」を集計
• 集計後、項目間で比較
• Excel でできる、解釈もシンプル、集団レベルの大まかな順位を見たい場合に有効

ただし、カウント分析では 個人レベルのスコア や セグメント別の精緻な比較 はできません。

階層ベイズ推定（HB, Hierarchical Bayes）

• 各回答者の個人スコアを 事前分布（集団平均）+ 事後修正（個人の選択） で推定
• 個人レベルのスコアが出るため、セグメンテーション・クラスタリングに使える
• 標準的には Sawtooth Software の HB モジュール、または R の bayesm / ChoiceModelR パッケージで実施

Marley, A. A. J., & Louviere, J. J. (2005). Some probabilistic models for best, worst, and best-worst choices は、ベスト・ワースト選択の数理モデル（ランダム効用モデル、MNL）を整理した文献で、HB 実装の理論的基礎です。

実務での選び方

• 役員プレゼン用に「機能 A は機能 B の 3 倍重要」と示したい → HB 推定（個人スコア → 平均で示す）
• 5 セグメント別の優先順位を比較したい → HB 推定（セグメント別事後分布）
• 「Q1 で何が最優先か」を社内に簡潔に共有したい → カウント分析で十分

ベイズ推定の理論的詳細は アンケート集計と有意差判定 — クロス集計・カイ二乗検定・効果量の使い方 を併読すると、頻度論との対比で理解しやすくなります。

6. MaxDiff / コンジョイント / PSM の使い分け

価格・優先順位調査の 三大手法 として、MaxDiff・コンジョイント・PSM はよく並べて議論されます。それぞれが解く問いと向いている場面は異なります。

実務での選択フロー

1. 「何を最優先で開発するか」を決めたい → MaxDiff
2. 「この価格 + 機能セットで売れるか」を見たい → コンジョイント
3. 「初期価格を 3,000 円 / 5,000 円 / 8,000 円のどれにすべきか」を探りたい → PSM

並列で使うケースもあります。MaxDiff で機能優先度を絞り込んだ後、上位 3 機能を組み込んだコンジョイント、価格レンジは PSM、という設計が中規模プロジェクトの標準パターンです。

詳細は コンジョイント分析の実務 と Van Westendorp PSM 設計ガイド を併読すると、三兄弟手法の使い分けが見えてきます。

7. 編集部の視点 — MaxDiff 実装で必ず効く 5 点

業界事例と公開ベンダー記事を継続的に追っている立場から、MaxDiff の実装で必ず効く 5 点。

1. 項目は 10〜20 個に絞ってから始める

「30 個全部 MaxDiff にかけたい」という要望はよくありますが、30 項目だと 1 人あたり 22 ブロック程度 が必要になり、回答負荷が破綻します。MaxDiff の前に「明らかに残す / 明らかに削る」を内部で議論 して、20 項目以下に絞ってからかけるのが現場の作法です。

2. 項目の粒度を揃える

「価格の安さ」と「お問い合わせフォームの使いやすさ」を同列に並べると、抽象度が違いすぎて回答者が比較できません。項目の粒度（抽象度）を意識的に揃える こと——例えば全部「機能カテゴリ」レベル、または全部「具体的なタッチポイント」レベルに統一。

3. 「重要度」と「満足度」を混ぜない

MaxDiff で「重要度」と「現状の満足度」を同じ調査で取りたい場合、別ブロックに分ける こと。同じブロック内で「重要かつ満足できるもの」を選ばせると、回答者は混乱します。Kano モデル分析を併用するなら、別調査として設計するのが安全です。

4. プレテストでブロック表示を実機確認

MaxDiff のブロック画面は モバイル端末で項目文が改行されて見にくくなる ことが頻発します。本配信前に必ず iOS / Android 両方で表示確認を。詳細は アンケート公開前チェックリスト で公開前検証のフレームを整理しています。

5. レポートでは「スコア + 順位 + 効果量」の 3 点セット

経営層に「機能 A は 28.5 ポイント」と数字だけ示しても伝わりません。「スコア」「順位」「機能 A vs 機能 B の差は統計的に有意か」 の 3 点を 1 枚に並べる。HB 推定なら事後分布の重なりで有意性が直感的に示せます。

8. アンケートツール Kicue での MaxDiff 実装

⚠️ 重要な前提: Kicue には MaxDiff 専用の設問タイプはありません。一般的なリサーチ専門ツール（Sawtooth Software / SurveyEngine / Conjoint.ly）と比べると、設計・分析の自動化機能は限定的です。

Kicue で MaxDiff を実装する 2 つの選択肢

選択肢 A: Kicue で代替実装する

単一回答設問の 反復ブロック で MaxDiff の挙動を再現できます:

• 「次の 4 項目のうち最も重要なもの」を単一回答設問で 12 回繰り返し
• 「次の 4 項目のうち最も重要でないもの」を単一回答設問で 12 回繰り返し
• ブロックごとに項目セットを変える（事前に Excel / R で BIBD を生成し、各設問の選択肢にコピペ）
• 回答収集後、CSV エクスポート → R の bayesm / ChoiceModelR パッケージで HB 推定

この方法は 「専用ツールにコストをかけられない初期プロジェクト」「項目数 10〜15 で簡易検証したい場合」 には十分実用的です。

選択肢 B: 専門ツールと併用する

本格的な MaxDiff プロジェクトでは:

• Sawtooth Software Discover / Lighthouse: 業界標準、設計から HB 分析まで一気通貫
• SurveyEngine / Conjoint.ly: SaaS 型で導入しやすい
• これらで本調査を実施し、Kicue は スクリーニング設問 や 追加プロファイリング設問 に使い分け

Kicue で対応できない範囲

• BIBD の自動生成 → 外部ツール（R support.BWS / Sawtooth）で事前生成し、Kicue にコピペ
• 階層ベイズ推定 → CSV エクスポート → R bayesm / Sawtooth HB モジュール
• 個人レベルスコアのダッシュボード表示 → 外部 BI ツール（Tableau / Looker）
• ブロック表示の自動ランダマイズ → Kicue の選択肢ランダム機能で部分対応、項目間ペアの均等化までは手動制御

関連記事として Van Westendorp PSM 設計ガイド・コンジョイント分析の実務・リッカート尺度の設計ガイド・スクリーニング設問の設計 を併読すると、三兄弟手法の使い分けと、MaxDiff の前段スクリーニング設計まで見えます。

機能優先順位や要望項目のランキングを精度高く測りたい方は、無料のアンケートツール Kicue を試してみませんか。単一回答設問の反復ブロックで MaxDiff の代替実装、選択肢ランダム機能でブロック内の表示順制御、CSV エクスポートで R / Sawtooth との連携まで、MaxDiff の初期検証フェーズを 1 アカウントで開始できます（BIBD 自動生成・階層ベイズ推定・個人レベル分析は Sawtooth Software / SurveyEngine / R bayesm などの専門ツールとの組み合わせ運用となります）。