ヘッドレスフォームの理解 – 概念と FAQ understanding-headless-forms
このガイドでは、ヘッドレスフォーム全般に関するよくある質問と、ヘッドレスアダプティブFormsがAEMにどのように適用されるかについて回答します。 これを使用して、ヘッドレスアプローチを使用するタイミングと、スタックでフォームを実装、スタイル設定および統合する方法を決定します。
基本と理解 basics-understanding
ヘッドレスフォームライブラリとは何ですか？
ヘッドレスフォームライブラリ は、フォームロジック （状態、検証、ルール、送信）を プレゼンテーション （UI コンポーネントとスタイル設定）から分離するフォームソリューションです。 「head」は表示可能なフォーム UI です。「headless」は、ライブラリが固定 UI を指示または出荷しないことを意味します。 代わりに、次を公開します。
- フォームモデル （多くの場合、JSON）：構造、フィールド、制約、ルール。
- API またはフック：フォーム状態の読み取り、更新、検証の実行、送信の処理を行います。
- イベントとライフサイクル を使用すると、UI を変更に対応させることができます。
AEM ヘッドレスアダプティブFormsでは、フォームはAdobe Experience Managerにホストされた JSON 構造 です。 Forms Web SDK （クライアントサイドランタイム）は、ビジネスルールプロセッサー、ステート管理、検証などのロジックレイヤーを提供し、アプリはその構造をレンダリングする UI を提供します。
ヘッドレスフォームと従来のフォームライブラリの違いは何ですか？
AEM ヘッドレスアダプティブFormsを使用すると、AEMで 1 回 フォームを作成して公開 できます。任意のクライアント（React、Angular、ネイティブモバイル、チャットボット）は フォーム JSON を取得 し、そのチャネルに適した UI でレンダリングできます。
UI ベースのフォームソリューションではなく、ヘッドレスフォームを使用する必要があるのはなぜですか？
ヘッドレスフォームは、必要に応じて適しています。
- システムの一貫性を設計 - ライブラリのデフォルトと競合することなく、既存のコンポーネントとブランドを使用します。
- マルチチャネル - Web、モバイル、その他のタッチポイント用の 1 つのフォーム定義（ 概要 を参照）。
- CMS駆動型またはバックエンド駆動型のフォーム – 作成者は、コードをデプロイせずに、フォーム構造とルールを変更します。アプリは JSON のみを使用します。
- フレームワークの柔軟性 - AF-core ライブラリはフレームワークに依存しません。React バインディングは便宜上提供されていますが、他のフレームワーク用のバインディングを構築できます。
- バックエンド機能 – 特定の UI スタックにロックすることなく、事前入力、検証、送信、ワークフローおよびForms データモデルにAEM Formsを活用できます。
ヘッドレスアプローチを使用すると意味があるのはいつですか？
ヘッドレスフォームを使用するのは次の場合です。
- 強力なデザインシステムやコンポーネントライブラリが必要な場合。
- Formsは、開発者以外（CMS内など）によって作成され、複数のアプリやチャネルで機能する必要があります。
- Web、モバイルまたは他のクライアント全体で同じフォームロジック（検証、ルール）が必要です。
- 再レンダリングを最小限に抑え、フォームロジックを UI に依存せずにテスト可能にしておきたい場合。
次の場合は、UI が含まれる従来のフォームライブラリを検討してください。
- 1 つの web アプリ内に作業フォームがすばやく必要であり、カスタム UI やマルチチャネルを気にする必要がありません。
- チームが、1 つのフレームワーク内のコードでのみフォームを定義することを希望している。
「ヘッドレス」は単なる流行語ですか、それとも実際の問題を解決しますか？
これは、アーキテクチャの実際の問題を解決します。
- 関心の分離 - フォーム構造、ルールおよび検証は、データとロジックレイヤーに存在します。UI レイヤーは、ユーザーのアクションのみをレンダリングおよびディスパッチします。 これにより、テストの安定性と再利用が向上します。
- チャネルの独立性 - 1 つのフォーム定義が異なる UI （React web、React Native、Angular、音声など）を使用できます。 AEM ヘッドレスアダプティブFormsは、React、SPA、web、モバイルなどをまたいで 1 回ビルド、配信 を行うために構築されています。
- コードを使用しないオーサリング - ビジネスユーザーは アダプティブフォームエディター でフィールドとルールを変更できます。開発者は、コンテンツの変更のために再デプロイする必要はありません。
- 既存のスタックとの統合 – 設計システム、状態の管理、ルーティングを維持できます。ヘッドレスレイヤーは、フォームの状態、検証、送信のみを処理します。
実装と技術的な質問 implementation-technical
ヘッドレスフォームは状態をどのように管理しますか？
AEM ヘッドレスアダプティブFormsでは、状態は Forms Web SDK によって管理されます。
- ビジネスルールプロセッサー - JSON 形式を受け入れ、フィールドの状態を管理し、JSON で定義されたルールとイベントハンドラーを実行します。
- React バインダー - コントローラーに対してフック（
useRuleEngineなど）を提供するので、React コンポーネントは現在の状態とハンドラーを受け取ります。同じ状態を、コア API を使用して React 以外の UI で利用できます。 - State には、フィールド値、表示/非表示、有効性、フォームモデルで定義されているカスタムプロパティが含まれます。
UI コンポーネントは状態とハンドラー（例：[state, handlers] = useRuleEngine(props)）を受け取ります。ユーザーがやり取りする際に、state からレンダリングし handlers 呼び出します。 ランタイムは、フォーム定義とルールと同期した状態を維持します。 アーキテクチャ および カスタムコンポーネントを使用したヘッドレスフォームのレンダリング を参照してください。
ヘッドレスフォームの設定で検証はどのように機能しますか？
検証は、フォームロジックレイヤーの一部です。
- 制約 は JSON 形式で定義されます（必須、最小/最大、パターンなど）。 Forms Web SDKは、これらの制約を適用し、検証のステータス（有効/無効、エラーメッセージなど）をコンポーネントに公開します。
- クライアントサイド検証 は、フォーム構造に基づいてSDKによって適用されます。UI には、状態のエラーが表示されます。
- サーバーサイド検証 は、AEM API （validate エンドポイントなど）を介して利用できます。送信前または送信中に検証できます。
UI に検証ロジックを実装するのではなく、ランタイムが提供する検証状態とメッセージのみを表示します。
ヘッドレスフォームをスキーマ検証（Yup、Zod、Joi）と統合することはできますか？
組み込みの検証は、フォームの JSON 制約によって決まります。 Yup、Zod、Joi などを使用するには：
- ヘッドレスアダプティブフォーム JSON をスキーマから 派生または生成 することができます（例：JSON スキーマをフォーム JSON に変換）。これにより、1 つの信頼できるソースでスキーマの検証とフォーム構造の両方を実現することができます。
- カスタム検証 の場合、フォーム JSON の他に、イベントハンドラーまたは送信前に独自のバリデータ（Yup/Zod/Joi）を実行し、結果をフォーム状態またはブロック送信にプッシュできます。 統合ポイントは、状態と送信に使用するフック/API と同じです。
アダプティブ Formsの仕様 と JSON 式 は、ランタイムで使用されるルールと制約モデルを定義します。
非同期検証（ユーザー名の可用性など）はどのように処理しますか？
非同期検証は、アプリケーションレイヤーに実装できます。
- フィールドの変更時に、JSON 形式 ルールまたはイベントハンドラー を使用してロジックをトリガーします（サポートされている場合）。
- カスタムコンポーネント で、同じ状態/ハンドラーフックを使用してバックエンド（例：ユーザー名と可用性の API）を呼び出し、フィールドの有効性を更新するか、ランタイム API または UI に表示されるローカル状態を介してエラーを表示します。
- または、非同期チェックが失敗した場合は、カスタムメッセージを使用して、チェック ぼかしまたは送信前 を実行し、フィールドの状態を無効に設定します。
正確なパターンは、アプリと ビジネスルールプロセッサー およびカスタムコンポーネントとの統合方法によって異なります。
ヘッドレスフォームを使用してデータを API に送信するにはどうすればよいですか？
送信は、UI から切り離されます。
- AEM送信アクション - REST エンドポイント、メールまたは統合（Microsoft Dynamics、Salesforceなど）に送信するようにAEMのフォームを設定します。 フォームは、実際の HTTP/バックエンド呼び出しを処理するAEMを通じて送信されます。 イベントを使用したフォームデータの処理と送信 を参照してください。
- クライアントサイド送信 - アプリは、送信をリッスンしたり、ランタイム状態からフォームデータを収集して独自の API に送信したりできます。 HTTP API は、送信ステータスをドキュメント化し、取得、検証、送信およびトラッキングします。
- 事前入力 - REST エンドポイントまたはサーバーサイドを使用して、フォームの読み込み時に状態が既に入力されるように、データを事前入力できます。 ストーリーブック – 事前入力の例 を参照してください。
UI とデザインコントロール ui-design-control
独自のデザインシステムやコンポーネントライブラリをヘッドレスフォームで使用できますか？
はい。 これは、ヘッドレスフォームの主なメリットです。 AEM ヘッドレスアダプティブFormsを使用する場合：
- 独自のコンポーネントをフォームモデルに マッピング します（フィールドタイプまたはリソースタイプによる）。 詳しくは カスタムコンポーネントを使用してヘッドレスフォームをレンダリングする および Google Material UI React コンポーネントを使用してヘッドレスフォームをレンダリングする を参照してください。
- ランタイムは 状態とハンドラー を提供します。コンポーネントはデザインシステムを使用してレンダリングされ、ハンドラーが呼び出されるので、フォームロジックは同期されたままになります。
- React Spectrum、Material UI、Chakra UI、または任意のカスタムコンポーネントライブラリを使用できます。 仕様 は、カスタムコンポーネント（Chakra UI、Vue.js など）用に拡張できます。 FAQ - カスタムフレームワーク を参照してください。
ヘッドレスフォームはアクセシビリティサポート（ARIA、キーボード処理）を提供しますか？
アクセシビリティは、指定した UI レイヤー に実装されています。 ヘッドレスレイヤーは DOM をレンダリングしないので、ARIA やキーボード動作はそれ自体は追加されません。 アクセシビリティの入手方法：
- デザインシステムまたはライブラリからの アクセス可能なコンポーネント の使用（多くは ARIA とキーボードサポートを含む）。
- カスタムフィールドコンポーネント ラベル、エラーメッセージ、フォーカス管理、キーボードナビゲーション）での アクセシビリティのベストプラクティス」に従います。
- 受け取るフォーム構造と状態（必須、無効、表示など）が、コンポーネントの ARIA 属性および動作に確実に反映されます。
標準の React Spectrum ベースのコンポーネントを使用する場合は、組み込みのアクセシビリティのメリットが得られます。
複雑な UI コンポーネント（日付ピッカー、カスタムドロップダウン）はどのように処理しますか？
それらを、JSON 形式の対応するフィールドタイプまたはカスタムリソースタイプにマッピングされた カスタムコンポーネント として扱います。
- 他のフィールドコンポーネントと同じ prop/state/handlers を受け入れるようにコンポーネントを実装します（
useRuleEngineなどを使用）。 - 値、表示および有効性には state を使用し、値およびトリガーの検証を更新するには handlers を使用します。
- 選択した UI ライブラリで日付選択またはカスタムドロップダウンをレンダリングします。変更時に、フォームの状態が正しいままになるように、新しい値でハンドラーを呼び出します。
フィールドタイプとリソースタイプでマッピングする方法については、 カスタムコンポーネントを使用してヘッドレスフォームをレンダリングする を参照してください。
フィールド（動的フォーム）を動的に追加または削除することはできますか？
フォーム構造は、サーバーから返される フォーム JSON によって定義されます。 動的動作は次の方法で実現されます。
- JSON 形式のルール – 式に基づいて、値の表示/非表示、有効化/無効化または設定を行います。 ビジネスルールプロセッサー はこれらのルールを実行し、コンポーネントは
state.visibleなどに反応します。 - サーバー駆動型の構造 – 異なるユーザーやコンテキストが異なるフォーム JSON を受け取る場合（例：異なるステップやセクション）があるので、「動的」とは、「リクエストごとに異なるフォーム定義」を意味します。
- クライアントサイドの変更 - アプリでフォームモデルを変更できる場合（繰り返し可能な構造の項目の追加や削除など）、ランタイムにその内容が反映されます。正確な機能は、フォームスキーマとランタイム API によって異なります。
ストーリーブック には、動的動作の例が含まれています。
条件付きフィールド（入力に基づく表示/非表示）はどのように処理しますか？
条件付き表示は、JSON 形式の rules によって駆動され、ビジネスルールプロセッサーによって評価されます。 条件を定義します（「フィールド A が X に等しい場合、フィールド B を表示」など）。ランタイムは状態を更新します（例：state.visible）。 コンポーネントで必要なのは 状態に従う （例：if (!state.visible) return null;）のみです。 状態からのレンダリング以外の表示/非表示を行うために、追加の UI ロジックは必要ありません。 カスケードおよび条件付き動作は、 アダプティブ Formsの仕様 に記載されており、Storybook - カスケードフィールド で実演されています。 FAQ - カスケードフィールド も参照してください。
パフォーマンスおよびスケーラビリティ performance-scalability
ヘッドレスフォームは従来のフォームライブラリよりもパフォーマンスが高いですか？
可能ですが、実装環境によって異なります。
- ターゲットを絞った更新 – 適切に設計されたヘッドレスランタイムは、変更された状態のみを更新し、それに依存するコンポーネントのみを通知します。これは、モノリシックフォームコンポーネントと比較して不要な再レンダリングを減らすことができます。
- 小さい UI バンドル – 使用する UI コンポーネント（デザインシステム）のみを出荷し、ライブラリコンポーネントの完全なセットは出荷しません。
- 遅延読み込み – 必要に応じてフォーム JSON を取得できます。初期バンドルのサイズを小さく保つことができます。
また、パフォーマンスはコンポーネントの実装方法（不要な再レンダリングの回避、メモリ化など）によっても異なります。
再レンダリングを最小限に抑えるにはどうすればよいですか。
- 状態図形 - ランタイムは、詳細な更新が可能な構造でフォーム状態を保持するので、ツリーの影響を受ける部分のみを再レンダリングする必要があります。
- フックのデザイン -
useRuleEngineなどのフックは、コンポーネントを使用する状態にのみ登録するように実装できるので、親または兄弟の変更によってすべてのフィールドが強制的に再レンダリングされるわけではありません。 - お客様の責任 - カスタムコンポーネントで React のベストプラクティス（
React.memo、安定したコールバックなど）を使用して、再レンダリングをさらに最小限に抑えることができます。
大規模な複数ステップのフォームの場合、ヘッドレスフォームは適切にスケーリングされますか？
はい、適切に設計されている場合は、次のとおりです。
- フォーム定義 – 大きなフォームは、JSON 内でステップまたはセクションに分割できます。UI で完全にアクティブにする必要があるのは、表示されているステップ/セクションのみです。サポートされている場合は、非表示セクションのルールを遅延評価します。
- 状態 - ランタイムは、1 つの一貫性のあるフォーム状態を保持します。ステップナビゲーションは、データを複製せずに、セクションを表示/非表示にしたり、「現在のステップ」を更新したりするだけです。
- チャンクと遅延読み込み - フォーム JSON をチャンクで取得したり、ステップの進み具合に追加のセクションを読み込んだりして、初期ペイロードと解析コストを低く抑えることができます。
非常に大きなフォームの場合は、構造（ウィザードの手順など）、サーバー駆動型のフォームのバリアント、実際のペイロードを使用したレンダリングとルールの実行の測定を検討します。
統合とエコシステム integration-ecosystem
ヘッドレスフォームは Next.js/SSR/サーバーアクションで機能しますか？
- Next.js / React – はい。 React レンダラーとフックは React 環境で機能します。 クライアントコンポーネントでForms web SDKを使用します。必要に応じて、サーバーまたはクライアント上でフォーム JSON を取得します。
- SSR - サーバー上のフォーム JSON を取得し、クライアントに渡して、フォームがデータをハイドレートするようにできます。 フォームのインタラクティブ機能（状態、検証、ルール）は、SDKが読み込まれるクライアントで実行されます。 SSR 中に、クライアントのみの状態に依存するフォームフィールドをレンダリングしたり、クライアントでハイドレートするプレースホルダーを使用したりしないでください。
- サーバーアクション（Next.js） – 送信ハンドラーからサーバーアクションを呼び出すことができます。ユーザーが送信すると、クライアントコードは（ヘッドレス状態から）フォームデータを収集し、AEM送信エンドポイントの代わりに、または追加でサーバーアクションを呼び出します。
ヘッドレスフォームをCMS、ヘッドレスコマース、バックエンドシステムと統合する方法
- CMS - AEMはフォーム定義のCMSです：作成者はフォーム JSON を作成して公開します。 他の CMS は、フォーム URL または API を参照したり、フォームにリンクしたりできます。 アプリはAEM（または CDN）からフォームを取得し、オプションで別のCMSからコピーやレイアウトを取り込みます。
- 事前入力と送信 - 事前入力 と送信は REST エンドポイントにヒットする可能性があるので、CRM、DAM、Commerce バックエンドから事前入力して、同じシステムまたは異なるシステムに送信できます。 AEM Formsは、Microsoft DynamicsとSalesforce、REST、メール、カスタム送信アクションもサポートしています。
- Forms データモデル - AEM Formsは、異なるデータソースに接続するForms データモデルを提供します。ヘッドレスフォームでは、すべての統合を自分で構築することなく、これらの機能を使用して事前入力、検証、送信を行うことができます。
モバイルやオフラインのシナリオでは、 独自のアプリを作成して、ヘッドレスのアダプティブ Forms API を介してフォーム定義を取得する ことが推奨されます。