Lead Formに「会社規模」を追加したり、「問い合わせ内容」の表現を変えたりする作業は、画面上の文言修正に見えます。しかし提出者の連絡先がGoogle SheetsやNotionへ送られているなら、その項目は下流データ構造の一部です。フォームだけを先に変えると、新しい値がどの列に入るのか、既存の数式と担当者が同じ意味で読んでいるのかを後から確認することになります。
フォーム変更は独立したデザイン修正ではなく、収集画面と送信先の間にあるデータ契約のバージョン変更として扱います。変更理由、適用時刻、マッピング、テスト、責任者を一つのバージョンにまとめます。
現在のスキーマを複製して基準線を作る
変更前に、現在のフォーム項目と送信先の列・プロパティを一つの表に置きます。各行には、フィールドキー、表示ラベル、必須かどうか、値の形式、送信先の名前、利用する業務、担当者を記録します。閲覧者に見える質問と下流で使う名前が異なる場合は、別々の項目として残します。
さらにスキーマバージョンとeffectiveAtを付けます。複雑な番号である必要はありません。2026-08-31-v2のように、どの提出から新しい構造で読むかを区別できれば十分です。変更依頼には、追加・変更・削除のどれか、理由、影響を受ける数式やレポートを記載します。
固定列とフォーム項目の列を分ける
FeatPaperからGoogle Sheetsへ送られる構造は、27個の固定列と情報入力フォーム項目の数だけ追加される列で構成されます。閲覧が続くと、関心度、閲覧回数、滞在時間、完了率、最新閲覧時刻などの累積項目が同じ行で更新される場合があります。一方、フォーム項目は提出時に受け取った値です。
公式ガイドは、必要な列がヘッダー右端に追加され、利用者がシートへ直接作成した列は変更されないと説明しています。それでも下流の処理が自動的に安全になるわけではありません。列位置に依存する数式、固定範囲を読むインポート、似た名前の独自列がないかを確認します。
フィールド名の変更や削除が既存の列・プロパティにどう影響するかは、フォームと送信先の両方で直接検証します。公式情報が説明していないrename、delete、migrationの動作を一般規則として作りません。
送信先はリンクではなく文書単位で見る
NotionとGoogle Sheetsへの連絡先送信先は文書ごとに指定します。同じ文書のリンクごとに別の送信先を付ける構造ではありません。あるリンクのフォーム項目だけを変えるつもりでも、その文書全体の提出フローと選択済みの送信先を確認する必要があります。
送信されるのは、情報入力フォームを提出した連絡先です。個別追跡リンクの受信者、匿名閲覧者、フォーム未提出の閲覧者まで同じ送信先へ自動的に届くとは考えません。この境界を明記することで、スキーマ変更が広すぎるデータ収集の期待を生むのを防ぎます。
各フィールドを利用者までつなぐ
新スキーマの各フィールドには、送信先の列・プロパティだけでなく、誰が何に使うかも記録します。必須のメールアドレスはフォローアップ時の識別に、任意質問は相談準備に使えるかもしれません。ただし利用目的があることと、法的適合性が保証されることは別です。個人情報の収集・保管方針は組織の別途確認範囲です。
変更は三方向で確認します。
- 入力：表示ラベル、必須条件、値の形式が意図どおりか
- 送信：提出値が指定したNotionデータベースまたはGoogle Sheetへ届くか
- 利用：数式、フィルター、ダッシュボード、通知、担当者の作業が新しい列・プロパティを正しく読むか
この契約を汎用CRM同期やSalesforce・HubSpotのネイティブ連携へ広げません。公式情報が確認するNotionとGoogle Sheetsへのフォーム提出者連絡先の送信範囲に限定します。
実際の提出一件で切り替えを確認する
新しいバージョンを保存する前に、変更時刻とロールバック条件を決めます。可能なら業務量の少ない時間帯に適用し、識別しやすい値を入れたテスト提出を一件送ります。送信先で新しい行とフィールド値を確認し、下流担当者が関連する数式やビューを確認します。
Google Sheetsでは一件の提出が一行を作り、閲覧が続くとその行の累積項目が更新される場合があります。必要な項目があるなら最初の到着だけで終えません。反対に、過去行が新スキーマへ自動でbackfillされる、または既存値が無損失で移行されるとは考えません。過去データの移動には別の移行計画と検証が必要です。
フォーム保存と下流承認を分ける
変更ログには、フォーム保存時刻、スキーマバージョン、実際の送信先、テスト提出の識別値、到着結果、利用側の検証、未解決の例外、承認者を残します。どのバージョンからどのマッピングが適用されたかを追跡できる必要があります。
最も安全な順序は、表示する質問を先に直すことではありません。現在のスキーマを固定し、マッピングと影響に合意し、フォームと送信先を一緒に変更し、新しい提出で確認します。この順序によって、フォームは孤立したUIではなく、変更責任が明確なデータ契約になります。
