大きな流れで見ると、データ定義とUI定義の関係は、次の4段階で発展してきたと整理できます。
- HTMLフォームから、モデルとUIを分けたい時代
出発点は HTML Forms です。W3C が 2000年代初頭に進めた XForms は、従来のフォームの限界に対して、データモデル・インスタンスデータ・UI を分離する考え方を前面に出しました。W3C は XForms を「presentation と content を分離し、強い型付けを持ち、スクリプト依存を減らす次世代フォーム」と位置づけていました。つまり、あなたが感じている XSLT 的な「データと見せ方を分ける」発想は、かなり早い段階から正面課題だったわけです。 この段階で解決しようとした問題は、HTMLフォームが見た目とデータ構造を強く結びつけすぎていたことです。型、検証、再利用、マルチデバイス対応をきれいに扱いたかった。 ただし課題は、XML/XForms は強力だが重く、Web開発の主流に乗り切れなかったことです。思想は先進的でも、開発者体験とブラウザ実装の広がりで苦戦しました。 2. 調査票・現地収集の世界で、定義を「非プログラマでも書ける」ようにした時代 次の大きな流れは ODK / XForms / XLSForm です。 ここでは「高度なフォーム定義」をそのまま XML で書くのではなく、Excel で書ける表形式のDSL に落としたのがポイントでした。XLSForm は、人間が読み書きしやすい Excel 形式でフォームを定義し、それを ODK XForm に変換する標準として説明されています。スキップロジック、制約、外部データ参照、多言語、地理型まで扱えます。 このアプローチが解いたのは、専門家しかフォーム定義を書けない問題です。現場調査、保健、開発援助、GIS 収集などで、開発者ではない担当者でも入力票を作れるようにした。さらに ODK はその後、Entities によってフォーム間で共有される対象データを扱えるようにし、ケース管理や縦断データ収集に拡張しました。2022年以降の Entities 機能や、2025年の Web Forms・地図機能拡張を見ると、単発アンケートから継続的業務フローへ進化しているのがわかります。 ただし課題も明確です。 XLSForm は強力ですが、表形式DSLゆえに複雑なレイアウトや高度なUI表現には弱い。また、フォームロジック、データモデル、運用上のワークフローが徐々に1つの定義に詰め込まれやすくなります。さらに Entities の発展過程からもわかるように、大きい共有データ・権限制御・同期・競合解決は今も難所です。ODK 自身も 2025 年時点で、Entity アクセス制御や大規模配布が採用障壁だと認めています。 3. JSON時代になり、「データ契約」と「フォーム生成」を近づけた時代 API やSPAが主流になると、中心は XML から JSON Schema に移りました。 JSON Schema は本来、JSON の構造検証や注釈のための仕様ですが、公式でも semantic annotation や domain-specific language への利用が挙げられています。つまり「型定義」から一歩進んで、機械可読なメタデータとしてUI生成やDSLに使う流れが生まれました。 この流れの代表が react-jsonschema-form (RJSF) や JSON Forms です。 RJSF は、JSON Schema だけではレンダリング方法を十分表せないために uiSchema を導入したと明言しています。JSON Forms はさらに明確で、schema、uischema、data を分け、uischema で Controls / Layouts / Rules を定義します。ルールで表示・非表示や有効・無効も扱え、配列には detail 表示のような仕組みもあります。 この段階で解けた問題は、バックエンドのデータ契約とフロントのフォーム定義を近づけられることです。型、required、enum、validation を共通化しながら、UI側で追加の見せ方を持てるようになった。特に JSON Forms は、あなたが今やっている schema + layout + data の考え方にほぼそのまま対応します。 一方で課題は、JSON Schema だけではUIの意味を十分持てないことです。だから uiSchema や独自テンプレートが必要になる。RJSF でもこの限界があり、最近の v6 では Layout Grid や多数のテンプレートを追加して補っています。つまり、この系統は「データ定義からフォームは作れるが、複雑なレイアウトや業務特有の振る舞いは別レイヤーが必要」という課題を今も抱えています。 4. 大規模業務フォームの時代：高性能・リアクティブ・ローコード化 さらに複雑な業務画面に対応するために出てきたのが Formily や SurveyJS のような方向です。 Formily は公式 README の Background で、React の controlled mode では大規模フォームでツリー全体の再レンダリングが問題になるとし、フィールド単位の状態管理、リアクティブ計算、副作用管理、動的JSON Schemaフォームを重視しています。つまり、単に定義からフォームを出すだけでなく、項目間連動・性能・フォームビルダーまで射程に入れたアプローチです。 SurveyJS は別方向で、動的 JSON ベースフォームに加え、Dynamic Panel や Dynamic Matrix、条件分岐、式言語、Webhook、Builder を備えています。近年のリリースでも Dynamic Panel の可視条件、Matrix/Panel 由来の choices、要素プロパティ参照など、メタデータと式でフォームをどんどん動的化する方向に進んでいます。 この段階で解いた問題は、複雑な項目連動と運用速度です。 従来のスキーマ駆動フォームではつらかった「Aを変えるとBの候補が変わる」「繰り返しブロックが増減する」「GUIでフォームを設計したい」に強くなりました。 ただし課題は、フォーム定義が“UIロジックのプログラム”に近づいてしまうことです。式、依存、レンダラ差し替え、ビルダー設定が増えると、今度は「何がドメイン知識で、何がUI都合か」の境界が曖昧になります。Formily が schema だけでなく reactions や effects を必要とするのは、その複雑さの裏返しでもあります。 ここまでの大きな流れ 流れを一言で言うと、こうです。 HTML直書き → モデル/ビュー分離（XForms） → 現場向けDSL化（XLSForm/ODK） → JSON Schemaベースの自動生成（RJSF/JSON Forms） → リアクティブ・ローコード・メタ駆動業務フォーム（Formily/SurveyJS）。 現時点で、どの方面で取り組みが進んでいるか 今は大きく5方向です。
- データ契約とUI定義の接続強化
JSON Forms や RJSF のように、JSON Schema を核にしてUI定義を重ねる方向です。 狙いは、API契約・検証・フォーム生成を近づけることです。 2. レイアウトDSLの強化 単純な縦並びから、グリッド、グループ、配列詳細、ルールベース表示へ進んでいます。RJSF の Layout Grid や JSON Forms の UI Schema / Rules がその例です。 3. 繰り返し・業務ワークフロー対応 SurveyJS の Dynamic Panel / Matrix、ODK の Entities など、単発入力ではなく継続的ケース管理や繰り返し構造を扱う方向です。 4. パフォーマンスとリアクティブ性 Formily のように、大規模フォームの再レンダリングや依存計算を制御する方向です。 5. 設計ツール・ローコード化 SurveyJS Creator や Formily Builder に見られるように、フォーム定義そのものをGUIで編集する方向が進んでいます。 いま未解決の課題 現時点でも、根本課題はかなり残っています。
- データ定義とUI定義の境界
どこまでを共通スキーマに持たせ、どこからをUI専用にするかは未だ定石がありません。 JSON Schema は構造検証には強いですが、UI意味論には不十分で、結局 uiSchema や独自DSLが必要になります。 2. ドメイン知識の置き場所 条件分岐や項目依存が増えるほど、業務ルールがフォーム定義に埋まる問題が出ます。 Formily や SurveyJS はそれを扱う機能を持ちますが、「扱えること」と「綺麗に分離できること」は別です。 3. 複雑レイアウトの可搬性 同じデータ定義でも、Web、モバイル、表形式、カード形式、地図付きUIで要求が違います。XForms 以来の「presentation からの独立」は理想ですが、現実にはレンダラ差・デザインシステム差が大きいままです。 4. 繰り返し構造と長期的データ管理 配列や繰り返しパネルはかなり進化しましたが、フォームをまたいだエンティティ管理、競合解決、権限制御、大規模同期は難しいままです。ODK Entities の最近の改善と課題認識がその典型です。 5. “宣言的”であり続ける難しさ 複雑になるほど、定義ファイルは式やイベントを持ち始め、事実上プログラムになります。 すると「ノーコードに見えるが、実際は難しいDSL」になる危険があります。SurveyJS の式機能拡張や Formily のリアクティブ設計は強力ですが、そのぶん学習コストと保守コストも上がります。 まとめ いまの全体像はこうです。 XForms は「モデルとUIを分ける」思想を明確にした。 ODK/XLSForm は、その思想を現場向けDSLに落として実用化した。 JSON Schema 系は、API時代にデータ契約とフォーム生成を近づけた。 Formily / SurveyJS / JSON Forms は、そこにレイアウト、依存関係、ビルダー、性能、繰り返しUIを積み上げてきた。 そして未解決なのは、 「データ定義・UI定義・業務ルール・運用ワークフロー」を、どこでどう分けるのが最も保守しやすいか です。 技術はかなり進みましたが、ここはまだ各製品が別々のバランスを取っている段階です。 必要なら次に、これをあなた向けに 「工場業務画面を作るなら、どの層を schema / layout / reaction / workflow に分けるべきか」 まで落として整理します。