「条件分岐があると便利なので、あれもこれも分岐させたい」——アンケート設計でよくある考え方ですが、条件分岐は乱用すると管理不能なフォームになる 構造を持っています。
本記事では条件分岐の設計フロー、テストの作法、そして 「分岐すべき場面」と「フォームを分けるべき場面」の判断基準 を整理します。
条件分岐の本来の目的
条件分岐の本来の役割は：
- 回答者にとって 無関係な質問を非表示 にして体験を改善
- 回答者の 特性に応じた深掘り をする
- 回答時間を 短縮 する
- データの 質を上げる（不適合な回答を排除）
つまり 「回答者のため」 の機能であって、設計者の利便性のためではありません。
分岐の3つの基本パターン
パターン1：スクリーニング型
冒頭で対象者を絞り込み、対象外なら早期終了。
Q1：当社サービスを利用したことがありますか？
- はい → Q2 へ
- いいえ → 「ご協力ありがとうございました」で終了
回答者にとっても、データ集計者にとってもメリットが大きい 最も推奨される分岐パターン。
パターン2：属性別深掘り型
属性に応じて、関連する詳細質問だけを表示。
Q1：あなたの属性は？
- 個人 → 個人向け詳細質問へ
- 法人 → 法人向け詳細質問へ
1つのアンケートで複数の属性に対応 したい場合に有効。ただし設計が複雑化しやすい。
パターン3：スコア・選択肢別深掘り型
特定の回答に応じて、深掘り質問を表示。
Q1：当社サービスへの満足度は？
- 4〜5（高評価）→ 「特に良かった点」を深掘り
- 1〜3（低評価）→ 「改善してほしい点」を深掘り
NPSやCSATなど、評価スコアに応じて聞き分け たい場面で有効。
設計フロー — 分岐を組む前に紙で書く
ステップ1：紙またはマインドマップで全体構造を書く
ツールに直接入力する前に、フローチャートを手書き する。
[Q1: 利用経験]
├─ あり → [Q2: 業種] → [Q3: 規模]
│ ↓
│ [Q4: 満足度]
│ ├─ 高 → [Q5: 推薦理由]
│ └─ 低 → [Q5: 改善要望]
│
└─ なし → [Q6: 興味のある分野] → 終了
これを書いてから実装すると、実装中に迷うことが激減 します。
ステップ2：階層を数える
分岐の階層数を数えます：
| 階層 | 規模 | 評価 |
|---|---|---|
| 1階層 | スクリーニング1段 | ◎ シンプル |
| 2階層 | スクリーニング+属性別 | ○ 標準的 |
| 3階層 | 属性×状況×スコア | △ 複雑 |
| 4階層以上 | 多段の絞り込み | × フォーム分割を検討 |
3階層を超えたら、フォームを分けるべきサイン。
ステップ3：パターン数を計算
各階層の選択肢数を掛け合わせ：
Q1（3択）× Q2（2択）× Q3（3択）= 18パターン
18パターンすべてを テストできるか が運用の現実性を決めます。30パターンを超えたら、テスト工数が爆発的に増えるため、構造の見直しを推奨。
ステップ4：ツールに実装
設計が固まってから、ツールに実装。設計しながらツール上で組む のは事故の元。
ステップ5：全パターンを通してテスト
公開前に 全分岐パターンを実際に通して 動作確認。
パターン1：個人 + 高評価 + 利用1年未満
パターン2：個人 + 低評価 + 利用1年以上
パターン3：法人 + 中評価 + 利用1〜3年
...
このテストパターン表を作って、チェックを残します。
ここからが本題 — 「分岐できるからやる」が招く事故
事故1：分岐が複雑すぎて管理不能に
5階層・50パターンの分岐を組んだ結果：
- 設計者が引き継ぎ時に説明しきれない
- バグ（特定パターンで質問が飛ぶ等）が発見されない
- 修正のたびに全パターンテストが必要で運用負荷が高い
「複雑な分岐を組めること」と「複雑な分岐を運用できること」は別物。
事故2：分岐忘れで回答者が混乱
Q1：個人 → Q2 へ移動
Q1：法人 → Q3 へ移動
Q1：その他 → 移動先未設定 → 次の質問にデフォルト遷移
↓
本来見せるべきでない質問が出る
設計時に 「該当しない場合」の流れを忘れる のが頻発。
回避策：
- すべての選択肢に 明示的に遷移先を指定
- 「指定なし」を残さない
- 全パターンのテストで未設定を発見
事故3：「念のため分岐」が増殖する
「これも分岐しておこう」「これは万が一のために」と 不要な分岐が積み重なる。結果、極めて少数の人にしか表示されない質問が大量にある状態に。
回避策：
- 「全員に表示しても問題ない質問は、分岐させない」を原則に
- 想定回答者の 70%以上が見る質問だけを基本に 配置
- 例外的なケースは 別フォームに切り出す 検討
事故4：分岐に依存した分析が困難
分岐すると、各セグメントで 回答した質問が異なる：
個人セグメント：Q1, Q2A, Q3A, Q5
法人セグメント：Q1, Q2B, Q3B, Q4B, Q5
横断的な集計（全員の Q5 など）は可能ですが、「Q3」を比較したいときに、Q3AとQ3Bの違いが見えにくい。
回避策：
- セグメント別の質問は 明確に列名で区別
- 共通質問は 全員に必ず聞く 設計
- 集計時のセグメント別分析を予め設計
「分岐」と「フォーム分割」の判断基準
すべてを1つのフォームに収めるか、複数フォームに分けるかの判断軸：
1フォーム + 分岐 にすべきケース
- 共通する質問が多い
- 回答者が どのセグメントか分からない 状態でアクセスする
- 回答中にセグメントが 動的に決まる
- セグメント間で 集計を比較したい
フォームを分けるべきケース
- セグメント別に 大幅に異なる質問 が必要
- 配信チャネルが セグメント別に分かれている
- 集計結果も セグメント別で別々に活用
- 4階層以上の分岐になる
- 50パターン以上のテストが必要
分岐パターン別の設計のコツ
スクリーニング型のコツ
コツ1：スクリーニング質問は冒頭3問以内に
コツ2：「対象外」の場合は短い感謝メッセージで終了
コツ3：「対象外」回答者にも、関心があれば連絡先を残せる選択肢を
属性別深掘り型のコツ
コツ1：属性質問はQ1〜Q3 で確定させる
コツ2：属性後の分岐は最大3経路に絞る
コツ3：分岐後の質問数を経路間で揃える（不公平感を防ぐ）
コツ4：最後は全員共通の質問で締める
スコア・選択肢別の深掘り型のコツ
コツ1：高評価/低評価で分岐するなら、両者に同じ重みの質問を
コツ2：「中立評価」も独立した経路として扱う
コツ3：スコア閾値を後から変更できないツールでは、分岐閾値を慎重に設計
分岐機能のツール別比較
| ツール | 分岐単位 | 複雑度 | 全体可視化 |
|---|---|---|---|
| Googleフォーム | セクション単位 | 低 | △ |
| Microsoft Forms | 質問単位 | 中 | △ |
| SurveyMonkey | 質問単位 | 中 | ○ |
| Typeform | 質問単位 | 中 | ○ |
| Qualtrics | 質問単位 + ロジック式 | 高 | ◎ |
| レポアン | 質問単位 + 数値範囲 + 複数選択 | 高 | ◎ |
複雑な分岐を組むなら、全体可視化ができるツール が必須。詳細：
分岐設計のチェックリスト
公開前に必ず確認：
- 紙やマインドマップで全体構造を書いたか
- 階層数は3以内か
- パターン数は30以内か
- すべての選択肢に遷移先が指定されているか
- 「対象外」の早期終了が用意されているか
- 全パターンを実際に通してテストしたか
- 分岐後の質問数が経路間で大きく違わないか
- 集計時のセグメント分析を想定しているか
- 引き継ぎ時に他の人が理解できる構造か
レポアンの分岐機能
レポアンは「複雑な分岐をノーコードで組める」ことを志向しています。
- 質問単位の柔軟な分岐 — Microsoft Forms 同等以上
- 複数選択ベースの分岐 — 「AかつBの場合」が組める
- 数値範囲・スコア計算分岐 — リッカート合計やNPSスコアでの分岐
- AIによる分岐設計支援 — 「Aを選んだ人だけに詳細を聞きたい」と日本語で指示すれば自動でロジック生成
- フローチャート形式の全体ビュー — 設計の全体像を可視化
- 分岐パターンの自動テストツール — 全経路を自動シミュレーション
まとめ
アンケートの条件分岐は：
- 回答者の体験向上のために使う（設計者の都合ではない）
- スクリーニング型 / 属性別深掘り型 / スコア別深掘り型 の3パターン
- 設計前に紙で全体構造を書く
- 階層3以内、パターン30以内に抑える
- 「分岐できるからやる」が事故の元
- 4階層以上ならフォームを分割する判断
- 全パターンテストは必須
「分岐機能を使いこなす」より「分岐を最小限に抑える」のが、運用しやすいアンケート設計の本質です。