はじめに
Webアプリケーション開発において、入力フォームは最も基本的で、かつ最もスパゲッティコードが生まれやすい場所です。
特に、前の回答によって次の設問がダイナミックに変化する「ドリルダウン（動的な条件分岐）」を実装しようとすると、フロントエンドのロジックは if 文の迷宮と化します。
「Q1がAで、かつQ2がBなら、この設問を表示し、かつ必須にする」
こうしたロジックを命令的に書き連ねるのではなく、コンピュータサイエンスの古典的な知恵である「グラフ理論」と「宣言的UI」の視点から整理すると、驚くほどスッキリとした設計が見えてきます。
1. フォームは「有向非巡回グラフ（DAG）」である
ドリルダウンが複雑になったフォームは、単なる設問の羅列ではありません。それは、数学における有向グラフ（Directed Graph）そのものです。
- ノード（点）：各設問（Q1, Q2, Q3...）
- エッジ（線）：設問間の依存関係（「Q1の回答がQ4の表示に影響する」という矢印）
ここで重要なのが、このグラフがDAG（Directed Acyclic Graph：有向非巡回グラフ）でなければならないという点です。もし「Q1がQ2に依存し、Q2がQ1に依存する」という循環参照（Cycle）が発生すると、システムは無限ループに陥り、計算順序を決定できなくなります。
システムはこのグラフを解析し、トポロジカルソート（Topological Sort）というアルゴリズムを用いて、「どの順番で設問を評価・表示すべきか」を自動的に導き出します。私たちが「ドリルダウン」と呼んでいるものは、実のところグラフの依存関係の解消プロセスなのです。
2. 確立された手法：「宣言的」なメタデータ定義
では、このグラフ構造をどうデータとして保持すべきか。歴史的に導き出された「正解」の一つは、「If文を書かずに、制約（Constraint）を記述する」というアプローチです。
以下のように、設問自体に「自分がどういう条件下で有効か」というメタデータを持たせます。
{
"id": "Q4_coupon",
"title": "限定クーポンをご利用になりますか？",
"visibleIf": "{Q1_first_time} == 'いいえ' && {Q2_satisfaction} >= 4 && {Q3_count} >= 10",
"isRequired": true
}
この設計思想には、20年以上にわたるアカデミックな積み重ねがあります。
W3C XForms (2003〜)
2000年代初頭、W3CはWebフォームの標準規格としてXFormsを提唱しました。ここで確立されたのが、UIとロジックを分離し、設問の属性として relevant（表示条件）や required（必須条件）を定義するという手法です。
「特定の条件下でのみ設問が有効になる」というロジックにXPathなどの評価式を用いる考え方は、現在のモダンなフォーム設計の原点と言えます。
CDISC ODM (臨床試験データ標準)
データの厳格な整合性が求められる治験・医療分野では、CDISC ODMという規格が世界標準となっています。ここでは設問間の依存関係（Skip Logic）を FormalExpression というメタデータで記述します。
これは「データの信頼性を守るためには、表示ロジックがコードではなく、データ（スキーマ）の一部として定義されていなければならない」という学術的な要件に基づいています。
現代のデファクト：SurveyJS や Form.io
現在、多くのエンタープライズ製品で採用されているフォーム基盤も、この系譜を受け継いでいます。プログラミング言語による命令的な記述を廃し、JSONベースの評価式によってドリルダウンを制御する手法が、最もメンテナンス性の高いデファクトスタンダードとして定着しています。
3. なぜ「If文」ではなく「プロパティ」なのか
プログラムの中に if (Q1 == 'A') { show Q2 } と書く（命令的）のと、Q2に属性として visibleIf: Q1 == 'A' と書く（宣言的）のとでは、設計の堅牢性に天と地の差が出ます。
- 自己記述性（Self-Descriptive）：設問項目を見ただけで、その出現条件という「制約」が完結しています。
-
リアクティブ・エンジンの実装：
「依存関係グラフ」を内部に持っていれば、Q1が変わった瞬間に、下流にあるすべての評価式を自動で再計算する「エクセルの再計算」のような挙動を簡単に実装できます。 -
スキーマの進化（Schema Evolution）への対応：
複雑に連結されたグラフにおいて、ある項目のIDや選択肢を変更することは、ノードの破壊を意味します。
※ここでバージョン管理を怠ると、過去の回答データが「変更後の新しいグラフ」で正しく評価できなくなるという致命的な不整合を招くため、スキーマの世代管理もセットで考えるのが定石です。
まとめ
複雑なドリルダウンの実装に直面したとき、それは単なるUIの実装である以上に、「データ間の依存関係をどうモデリングするか」というグラフ理論の課題です。
先人たちが XForms や CDISC ODM で築いてきた「宣言的に制約を記述する」という知恵を借りることで、私たちは複雑な要件に対しても、堅牢で美しいシステムを提供できるようになります。
次にフォームを作るときは、一度手を止めて、その裏側に隠れた「依存の地図」を一本引いてみてはいかがでしょうか。
参考キーワード
- DAG (Directed Acyclic Graph)
- Topological Sort
- W3C XForms / CDISC ODM
- Constraint Satisfaction Problem (制約充足問題)
- Schema Evolution