サイトごとのフォーム実装を、共通の運用基盤へ。

再利用できるフォーム基盤が必要だった背景

対象は、複数のWebサイトで問い合わせやアンケートを運用するマーケティング企業です。案件ごとにフォームを個別実装すると、文言や項目の変更にも開発作業が必要になり、回答データの管理先も分散します。

AMELAは、埋め込み型SDK、ノーコードの作成画面、公開・回答管理CMS、データ収集API、クラウド環境のコード化を担当しました。企業名、プロジェクト名、画面内の情報は、機密保持のため承認済みの仮名・モックに置き換えています。

埋め込みコードとフォーム定義を分離した実装

既存サイトには、フォームIDを含むスクリプトタグを設置します。フォームの項目や公開状態は作成画面で管理するため、サイト側のコードとフォーム定義を分離できます。バックエンドにはFastAPI、MongoDB、Redisを用い、AWS ECSとTerraformで環境構成を管理しました。

この事例の根拠と読み方

• 根拠：AMELAの移行元ケース資料、CMS登録内容、2026年8月23日に確認した公開デモの動作と画面。
• 対象期間：公開資料に記載された開発範囲と、上記確認日時点のデモ。
• 確認できること：埋め込み型SDK、作成画面、回答フォーム、管理画面、データ収集API、AWS ECSとTerraformを含む構成。
• 確認できないこと：本番利用量、作業時間の削減率、売上・CVへの寄与、SLA、障害実績、認証・法令適合の水準。
• 公開上の扱い：企業名、プロジェクト名、画面、数値は機密保持のため仮名またはモックです。実在する顧客や個人を示すものではありません。

導入条件は、サイトごとに別途確認が必要です

埋め込み型フォームは、タグを貼れば設計が終わるわけではありません。Cookieや同意文言、個人情報の保存期間、アクセス権、迷惑送信対策、CSP・CORS、アクセシビリティ、エラー時の案内は、設置先サイトの要件に合わせて決める必要があります。

公開デモは機能の流れを説明するためのものです。本番環境のセキュリティ設定、監視、バックアップ、復旧手順を証明する資料ではありません。

読者が使える実践ツール

要件定義の前に、次の責任分界・受入確認シートを一項目ずつ埋めると、サイト側とフォーム基盤側の境界を整理できます。各項目は、この事例から確認できる記入例と、導入時の確認事項を組み合わせています。

• 設置単位：フォームID付きスクリプトタグ。設置ページとタグ変更の責任者を決める。
• フォーム定義：作成画面で項目と公開状態を管理。承認者、版管理、公開前レビューを決める。
• 回答データ：収集APIを通じてCMSで管理。保存期間、閲覧権限、削除手順を決める。
• 環境分離：開発・検証・本番をコードで管理。本番反映条件と差分確認方法を決める。
• 受入確認：入力・送信・管理の一連を確認。同意、エラー、重複、通知、出力を試す。

数値効果を評価する場合は、変更依頼から公開までの時間や修正回数について、導入前後で同じ条件の測定方法を別途定義してください。