---
title: "システムユーザビリティスケール（SUS）とは？"
description: "SUSの調査向け定義と、プロダクトのユーザビリティ調査におけるチームでの活用方法について解説します。"
canonical_url: "https://getminds.ai/glossary/ja/what-is-system-usability-scale"
last_updated: "2026-07-02T00:25:44.817Z"
---

# システムユーザビリティスケール（SUS）とは？

システムユーザビリティスケール（SUS）は、ユーザーがプロダクトやプロトタイプを操作した後の主観的なユーザビリティをベンチマーク評価するためのUX評価ツールです。これにより、リサーチチームは、曖昧なビジネス上の問いを、回答者が一貫して答えられる選択肢、尺度、タスク、またはプロンプトへと規律ある方法で変換できます。この手法の価値は、その名称自体にあるのではなく、それがもたらす規律にあります。つまり、定義されたターゲット層、明確な意思決定、現実的な刺激策、そして回答が得られる前に決定された分析計画です。

Mindsのワークフローでは、システムユーザビリティスケールを実地調査前の計画テンプレートとして扱います。まずターゲット層を選択し、次にその対象者に適したサブセクション、質問の文言、セグメントの切り口、および解釈におけるリスクを提案するようMindsに求めます。これは、チームにリサーチの意図はあるものの、回答者に提示できる具体的な言葉にまだ変換できていない場合に有用です。

## どのような場合に使用するか

システムユーザビリティスケールは、プロダクト体験がそのまま進めてよいほど明確であるか、あるいはユーザビリティの修正が必要であるかを判断するリサーチの意思決定に適しています。チームが対象母集団と刺激策を明確に説明できる場合に最も効果を発揮します。ターゲット層の定義が曖昧な場合、最初のタスクは調査質問を作成することではありません。最初のタスクは、Mindsを使用してターゲット層の定義を検証し、見落とされているサブセグメントを洗い出し、実際の調査を実施する前にどの仮定に裏付けが必要かを特定することです。

システムユーザビリティスケールは、チームが単に幅広いブレインストーミングを行いたいだけの場合、それほど有用ではありません。その場合は、パネルディスカッションや定性インタビューの流れを設計する方が、通常はより有用な素材を得られます。このテンプレートは、回答を比較、ランク付け、スコア化、診断、または構造化されたリサーチブリーフに変換する必要がある場合に使用すべきです。

## 質問と設定

まず、ターゲット層から始めます。誰が回答すべきか、彼らがどのような状況に置かれているか、およびプロダクト、カテゴリ、またはブランドについてすでに何を知っているかです。次に、刺激策を定義します。刺激策には、コンセプトの説明文、ランディングページ、価格表、機能リスト、メッセージセット、カスタマージャーニー、プロトタイプのスクリーンショット、または日記のプロンプトなどがあります。最後に、出力形式を定義します。システムユーザビリティスケールにおいて有用な出力は、ユーザビリティスコアの方向性と、そのスコアの背景にある定性的な理由です。

Mindsは、スクリーナーロジック、導入の質問、主要タスク、フォローアップの深掘り、セグメンテーションの切り口、分析ノートなどのサブセクションのドラフトを提案できます。最も確実な方法は、一度に1つのセクションずつ求めることです。実際の回答者に調査を実施する前に、誘導的な文言、二重質問（ダブルバレル）の表現、非現実的な仮定、選択肢の不足がないか、各質問を批評するようMindsに依頼してください。

## Mindsがどのようにワークフローに適合するか

Mindsは、正式なリサーチシステムに移行する前に位置づけるべきです。ブリーフをより強固な調査設計へと変換し、異なるセグメントが刺激策をどのように解釈するかをリハーサルし、最終的なアンケートで測定すべき懸念事項を見つけ出すために使用します。このプラットフォームは、プログラミング、リクルート、またはモデレーションに予算を費やす前に、その手法がターゲット層に適しているかどうかを判断するのに特に役立ちます。

実践的なワークフローはシンプルです。ターゲット層を作成または選択します。リサーチフレームワークとしてシステムユーザビリティスケールを選択します。刺激策を貼り付けるか、意思決定の内容を記述します。Mindsにセクション、質問、および設定の提案を求めます。リサーチャーがジュニアアナリストの最初のドラフトをレビューするように、そのドラフトをレビューします。その後、意思決定に正式な裏付けが必要になった段階で、完成した調査票を実際の回答者を対象とした調査、インタビュー、または専門ツールに移行します。

## 限界と検証

システムユーザビリティスケールには、依然として調査手法における判断が必要です。Mindsは、文言の作成、ターゲット層の論理的根拠、および想定される解釈を支援できますが、代表性のある統計データ、規制上の主張、正確な市場規模の把握、正式な効用推定、または最終的な価格弾力性を得るための最終的な情報源として使用すべきではありません。金銭的またはコンプライアンス上のリスクが高いほど、実際の回答者と適切な調査設計を用いて検証することが重要になります。

主なリスクは、見せかけの正確さです。洗練された合成回答は、根拠となる証拠が示す以上の確実性があるように聞こえることがあります。これに対処するには、仮定をリストアップし、実際の人間によるデータが必要な箇所を特定し、定性的な解釈と定量的な測定を区別するようMindsに求めてください。

## スターターテンプレート

- ターゲット層：プロダクトの文脈において現実的なタスクを完了できるユーザー。
- リサーチにおける意思決定：プロダクト体験がそのまま進めてよいほど明確であるか、あるいはユーザビリティの修正が必要であるか。
- 主な刺激策：動作するプロダクト、プロトタイプ、クリック可能なフロー、または現実的なタスクシナリオ。
- 主なタスク：タスク実行後に10項目のSUS質問を行い、混乱した箇所についてフォローアップする。
- 分析の視点：ユーザビリティの認識、タスクにおける摩擦、自信、および繰り返し発生する懸念事項。
- 検証における注意点：出力結果を最終的な外部への主張の裏付けとする場合は、実際の回答者または専門的な統計ワークフローを使用してください。

## 次のステップ

このページを、プロダクト内テンプレートの最初のドラフトとして使用してください。プロダクト版では、ユーザーがターゲット層を選択し、システムユーザビリティスケールを選択すると、その対象者や目前の意思決定に合致したセクション、質問、デフォルト設定、および警告の提案を受け取れるようにする必要があります。