申込フォーム・参加前リマインド

0. 複数開催を上書きしない保存先

固定の公開名・日時・Zoom案内は開催専用テンプレートへ保持できる。差し込みが必要な値は、開催IDを含む専用の友だち情報欄を候補とし、既設の正当な共有欄と区別する。

欄を増やす前に実際の参照が必要か確認する。新開催を既存TS_A/TS_Bの同じ欄へ代入して、他開催の本文・条件を変えない。共通表示用の「状態」だけで開催別の開始・停止を判定しない。申込・回答・初回起動の証跡は開催別タグで保持する。

同じ人が異なる2開催へ申し込む場合を両順序で検証する。両方の日時・Zoom・リマインダが保持されることを確認してから並行利用する。

1. 日程別資産を先に作る

開催日時ごとに次を1対1で持つ。

• 同じZoom URLを使う複数日程でも、日程別計測が必要なら短縮URLと訪問タグを分ける。
• 訪問タグ名は、報告上「実参加」ではなく「Zoom入室URL訪問」と区別する。
• 外部用短縮URLの訪問時アクションに日程別訪問タグを追加する。既存の最終反応日更新など正常な共通アクションは維持する。
• 保存後に最終URL、短縮URL、タグ完全一致名・ID、訪問時アクションを読む。

2. 参加前リマインダを作る

1開催日時につき1リマインダを作る。基準日時は開催開始の年月日、時刻、JSTと完全一致させる。

• 同じ時間帯の直近正常例を使う。朝開催へ夜開催の固定時刻を流用しない。
• 開催後になる当日ステップは作らない。通数より、全配信が開催前であることを優先する。
• 申込時点ですでに過ぎた相対ステップの挙動を正常例または仕様で確認する。
• お礼と全リマインドの参加URLを、該当日程の外部用Zoom短縮URLへ統一する。
• テンプレート本文にURLを貼るだけで終えず、Lステップの URL読み込み 後に保存する。
• 絶対日付、曜日、本日、明日、あと○時間 を配信タイミングから再計算する。
• 差し込み変数が文字列ではなく実トークンであることを確認する。
• リマインダ設定は最下部の「設定を保存する」まで実行し、再読み込み後に全ステップの順序、基準、時刻、テンプレート、リンク設定が残ることを確認する。

最終配信タイミングから共通120分クッションへ接続

トレンドセミナーの参加前リマインダを作るときは、開始時や30分前ではなく、開催開始時刻に配信する最後のタイミングの「アクション設定」で、【クッションシナリオ】【共通】トレンドセミナーリマインド→終了後シナリオ接続(120分)（ID 1302041）を開始する。9/20専用クッション（ID 1304038）は別開催へ複製しない。リマインダのメッセージ本文や申込フォームの回答直後アクションへ置かない。

共通クッションは開始から2時間後にアクションを実行し、【共通・本番】TS-セミナー終了後シナリオ（ID 1275158）へ接続する。接続前に今回の終了時刻との整合、両シナリオの配信可状態、2時間後の実行内容・終了接続、QRなど別起点からの二重起動と予約済み除外を確認する。時刻や対象が合わない開催では、合わない理由と接続の未完を記録して設定を確定しない。

保存後はリマインダIDから開き直し、最終タイミングのアクション要約が共通クッションの完全一致名を示すことを確認する。アクション詳細の条件ON/OFF、遷移設定、発動2回目以降の実行設定も確認し、QRなど別起点がある場合は同じ初回証跡での除外を読戻す。クッションと下流シナリオもそれぞれIDから読戻し、設定の読戻しと実発火を分けて記録する。

2a. 19:30開催の画像・本文パック

採用する直近の同方式モデルの全タイミングをプレビューし、画像と本文をメッセージ単位で照合する。2026/09/19の19:30開催モデルでは次の順序を基準とし、開催ごとの採用特典・配信時刻に合わせて調整する。既存のパックへ追加すると末尾に入るため、追加後に「並び替え」を保存し、一覧と一括プレビューを再取得する。

• サムネイルの年月日・曜日・開始時刻、特典の名称と実際の配布物、ハンドブックの文章URLを今回の正本と照合する。モデルの旧開催画像や旧Zoom値はコピーしない。特典を約束する文面だけで配布完了としない。
• すべてのCR画像は「リンク設定：リンク1」「領域A：使用しない」で登録する。画像ごとに保存後の両選択状態を読戻す。画像のタップを促す通知文は使わず、必要なリンクは本文URLから案内する。
• アンケートは今回専用の回答フォーム実トークンを挿入し、プレビューで FORM の今回値を確認する。申込直後にも案内する構成では回答済みの人への重複を確認する。メッセージ単位条件を設定できない場合は、同時刻の画像とZoom案内をリマインダに残し、アンケートだけを開催別予約完了タグあり・開催別回答済みタグなしの動的絞り込みを持つ別配信へ分ける。条件確定時の人数で固定せず、送信時点のタグで判定する。元リマインダの無条件アンケートは重複送信を防ぐため外し、両経路を保存後に読み戻す。別配信では同時刻の厳密な到着順を保証できないため、順序が必須なら送信時刻を分けて確認する。「未回答の方へ」という文言だけを技術的な除外とみなさない。
• LINE本文の空行は意味の切れ目に1行までとし、連続する空段落、見出しとURLの間の過剰な改行、画像の前後の不要な空白をなくす。本文を編集した後も URL読み込み の設定行と回答フォーム実トークンを保持する。
• 追加した各画像・本文は承認済み固定テスト先へテスト送信し、成功表示を確認する。登録後に編集画面と一括プレビューを再取得し、通数・順序・画像・リンク・最大連続空段落数を監査する。

3. 複製元フォームを選ぶ

直近の同タイトル・同方式の開催から、正常確認済みのフォームを選ぶ。前回の未完事項を確認し、開催専用の新しいフォームへ複製する。

同じ用途の直近トレンドセミナーから、通常のLINE募集で使った本番フォームを優先する。

• 通常版とメルマガ版がある場合、フォーム後の動作が同じなら通常版を正本とし、媒体計測は流入経路側で行う。
• 回答数、公開状態、用途、日程選択肢、選択肢別アクション、フォーム全体の回答後アクションを読む。
• 複製元の旧企画名、旧日程、タグ、友だち情報、参加URL、リマインダ、お礼、回答後ページを一覧にする。
• 旧資産を新フォームへ持ち越さない。共通の正常アクションだけを維持する。

4. 複製先フォームを今回開催へ更新する

申込フォームの完了後は、今回の個別相談型なら同時申込LPまでを必須の接続先として設計する。回答後アクション・サンクス画面・短縮URLの確認と、参加前アンケートを含む全件監査は フォーム完了後と同時申込LPの再発防止・監査 に従う。

• 正式企画名、説明文、日程、所要時間、参加条件を今回値へ変える。通常版・広告版・旧フォームが併存する場合は、最新の修正記録と全募集入口から今回の正フォームを特定する。
• 日程選択を必須にする。
• 今回開催の日程を登録する。他開催の日程を複製先に残さない。
• 日程に依存しない共通アクションだけをフォーム全体の回答後アクションへ置く。
• 日程に依存する値は、日程選択肢ごとのアクションへ置く。

日程選択肢ごとに設定するもの:

• 開催日、開始時刻、企画名、参加URLなど必要な友だち情報
• 該当日程の申込タグ
• 該当日程の参加前リマインダ開始

フォーム全体に残せるもの:

• [一斉配信_申込日] など、どの日程でも同じ値
• 全回答者共通の集計処理
• 採用した未申込フォローの停止（流入・募集 C5）。開催専用フォームの全体処理へ置く場合も今回資産だけを対象にする

フォーム全体に日程固定のタグ、参加URL、リマインダ開始がある場合、複数日程対応として不合格にする。

4a. SEO固定入口のFlexから接続する

SEO固定入口のFlexからフォームへ接続する場合、カードは開催専用フォームを直接参照する。各カードの公開名・日時・サムネイルは選択先フォームの現行開催と一致させ、フォームの作成・読戻し前にカードだけを先行公開しない。フォーム回答時に開催ID、申込タグ、日程別リマインダを確定し、固定SEO入口では開催を先付けしない。

新開催の掲載時は、フォームの保存後読戻し、Flexカード差替え、CTA到達、受付終了カードの非掲載を同じ公開チェックに含める。

5. お礼を1経路に統一する

フォーム直送のお礼を参加前リマインダ開始時へ移す場合は、次の順序を守る。

• 日程別リマインダへ開始時お礼を追加して保存する。
• お礼の差し込み値とURLを開き直す。
• 全フォームの日程選択肢へリマインダ開始を追加して保存する。
• 日程とリマインダIDの対応を開き直す。
• 重複する旧お礼直送だけを解除する。
• お礼が0回でも2回でもなく、リマインダ開始経由の1回であることを確認する。

新経路確認前に旧お礼を外さない。途中で失敗した場合は、0回になる状態を避けて停止する。

6. 全選択肢を総当たりする

各フォームに実在する日程選択肢をすべて確認する。期待行数は、各フォームの選択肢数の合計。

• 日程Aの選択肢に日程Bのタグ、URL、リマインダが1つでも混ざれば不合格。
• 同じ開催日時へつながる複数フォームは、同じ日程別リマインダを使う。
• 非公開・旧版フォームは、利用しない理由と一斉配信から未参照であることを記録する。

6a. 同じ開催への再申込

今回申込タグ・リマインダの登録・過去の開始履歴を別々に確認する。タグだけを見て再開始可能と判断しない。初回申込はお礼とリマインダが1回、再申込は承認された再案内方式になり、二重配信・必要通知の欠落がないことを確認する。テストのために本番利用者の登録やタグを無断で解除しない。

7. 既存回答者を分けて扱う

• フォーム連携前の回答者数を、フォーム別・日程別の集計だけで確認する。
• 後付けしたフォームアクションは既存回答者へ遡及しない。
• 既存回答者をリマインダへ追加する場合は、対象条件、件数、日程別リマインダ、重複防止条件を提示し、別途承認を得る。
• 登録済み、開催済み、キャンセル済み、日程不明を一括追加しない。

フォーム保存後に再認証画面が出たら、操作範囲と承認 に従い、認証せずブラウザの「戻る」を押す。同じフォーム管理URLを再取得して変更内容を読戻し、一致すれば保存済みとして続ける。確認できない場合のみ「保存未確認」と記録する。

8. 保存不能な過去フォーム

開催済みフォームや過去ゴール日時を持つリマインダは、Lステップの未来日時検証によりフォーム全体が保存不能になることがある。

• 過去フォームの日時を未来へ書き換えず、次回の複製先で今回の日時を設定する。
• 稼働済み接続を削除しない。
• 未保存変更を破棄して現状を保全する。
• 改善は次回用の複製または新規フォームへ適用する。

完了条件

• 個別相談型では申込フォームと参加前アンケートの回答完了後に、今回同時申込LPへの経路が保存後読戻しで確認済み。未確定・未確認なら申込導線全体は未完とする。
• 開催日時数 = 日程別リマインダ数 = 外部用Zoom短縮URL数 = 入室URL訪問タグ数。例外は理由付き。
• 公開予定フォームの全選択肢が日程別リマインダへ接続済み。
• 開始時お礼が1経路。
• 全参加URLが日程別短縮URL。
• 保存後の値を全件読戻し済み。
• 既存回答者の非遡及件数または対応結果を記録済み。

開催別の複製運用

開催の追加と複製 に従い、直近の同タイトル・同方式から開催専用フォームと資産を作る。過去開催の資産を次回へ上書きせず、複製元・理由・変更点・未完事項を 運用データ/events/*.json に記録する。既存の実設定名は履歴として保持し、新開催の設定は並行開催への干渉を確認する。

コンテンツ経由の申込計測（2026/09/15）

• 開催の既存タグフォルダで [企画ID]_コンテンツ経由予約完了 を検索し、なければ作成する。正本 [企画ID]_予約完了 は維持し、この部分集合タグを合算しない。
• 日程選択肢アクションの正本予約完了タグ付与より前に、計測タグ追加を置く。条件は共通 TS_コンテンツ流入履歴 あり AND 今回の正本予約完了タグなし。完全一致の個別タグ指定にする。
• 元の動作・日時・参加URL・リマインダを維持する。再回答時の後付けを防ぐため、正本予約完了タグを解除しない。
• 保存後に同じフォームIDを再取得し、計測タグ・AND条件・正本より前の順序・既存動作を読戻す。実発火は別途確認する。
• 開催JSONの tagBindings.contentReservation に名前・ID・設定URL・確認範囲を記録し、displayResources.sns へ集計先と状態を表示する。
• 新開催へ前回の計測タグIDや除外タグIDをコピーしない。今回専用IDへ差し替え、共通履歴タグだけ共有する。実績・検証済み状態を複製しない。

集計は開催別の計測タグ保有人数。初回申込までの接触履歴によるため媒体間で重複し得る。設定前の予約、未設定の入口は対象外。シート自動転記は別工程で、タグ設定だけで連携済みとしない。

セミナー予約完了タグの契約（2026/09/15）

• 正式名は [企画ID]_予約完了。申込完了、申込済、申込済みへ言い換えない。接尾辞の原本は funnel.json の tagDefinitions.seminarReservation。
• 開催別JSONの tagBindings.seminarReservation に正本の name、tagId、settingsUrl を一度だけ記録する。図のフォーム・リマインドはこの定義から生成する。
• 作成前に今回の完全一致名を検索する。既存の正本があれば同じIDを使い、別名のタグを増やさない。前回のIDを次回へコピーしない。
• フォーム付与、再申込の除外、未申込フォロー停止、集計の採用IDを同じ正本IDへそろえる。references に用途・管理URLまたはコード所在・採用ID・確認日・状態を記録する。未採用は理由付き、未確認は未確認のまま残す。
• 改名は同じタグIDの名称だけを変更する。名前の文字列照合があれば呼出し側も直す。保存後にタグ名・ID・付与人数と参照設定を読み戻す。改名の成功だけで実発火を確認済みにしない。
• 過去の二重タグは正本と 予約完了_旧補助タグ に区別し、legacyTags に旧名・ID・現在名を記録する。削除・統合・一括付与・既存アクションの停止は改名に含めない。補助タグの人数を正本に足さない。
• 開催JSONの現行 stages.form.tags には開催別正本1件だけを記載し、全開催共通タグは funnel.json.tagDefinitions.trendSeminarRegistrant から図・検証へ合成する。過去の付与動作・人数・当時の仕様は履歴として保持する。新開催では旧補助タグの付与を複製しない。
• build-dashboard.py --check と verify-dashboard.py で、役割参照、ID一致、二重正本、他開催ID混入を確認する。本番の接続確認は別途必要。

全トレンドセミナー申込者の共通タグ契約（2026/09/18）

• 共通タグの正式名は TS-申込済み、IDは 10528829、所属は既存フォルダ トレンドセミナー。原本は funnel.json の tagDefinitions.trendSeminarRegistrant とし、別名・別ID・単一タグ専用フォルダを増やさない。
• 意味は「少なくとも1回トレンドセミナーへ正常申込した友だち」。開催別の申込日時、参加日程、リマインド、取消、着座・実参加は表さない。開催別人数の正本は引き続き [企画ID]_予約完了。
• 新規・複製フォームの各日程選択肢に、開催別正本タグとは別アクションで TS-申込済み を無条件追加する。タグフォルダで指定 はOFF、2回目以降実行は既存フォーム方針を維持する。共通タグを条件付きの媒体計測タグより前提にしない。
• 保存前に選択チップと タグ[TS-申込済み]を追加 の要約を確認する。外側のフォーム保存後、同じフォームIDを再読込し、全日程選択肢で共通タグ、条件OFF、既存開催別タグ・日時・URL・リマインダが維持されていることを読む。実回答による付与は別のE2E証拠。
• 過去分の遡及付与は、各開催の正本予約完了タグを起点に対象友だちを抽出し、共通タグを一括追加する。開催間重複を単純加算せず、最終の共通タグ保有人数をユニーク人数として記録する。元タグ人数と操作可能人数が違う場合は両方を残し、非表示・削除済みなど理由不明の差を推測で補わない。
• 一括付与後は各バッチの成功表示と、共通タグ管理画面の最終人数を読戻す。個人名・LINE名・メール等は実装記録へ残さない。タグ付与の成功をフォーム自動付与の実発火確認へ読み替えない。

企画別タグフォルダと個別タグ指定（2026/09/15）

• 1開催のタグは1つの企画別タグフォルダへまとめる。新しい単一タグ専用フォルダは作らない。
• フォーム、短縮URL、流入経路、シナリオ、カレンダーのアクションでは タグフォルダで指定 をOFFにし、対象タグを個別に選択する。
• 候補が表示されない場合は、日本語を含む完全名を直接入力せず、ASCIIの接頭辞だけを1文字ずつ入力する。開催別は例として TS-1930-20260916_、共通タグは TS- で絞り、表示された候補から日本語の末尾まで一致するタグを選ぶ。
• 入力欄に文字が入っただけでは選択完了ではない。対象タグの選択チップと、タグ[... ]を追加 または 解除 のアクション要約を確認してから内側の決定と外側の保存を行う。保存後は同じ管理IDを再表示し、タグフォルダ[...] が残っていないことを確認する。
• 2026/09/15の実画面試験ではSafariの画面操作で候補読込と個別選択を確認した。当時はChrome拡張とPlaywrightで入力または候補読込が安定しなかった。2026/09/23以降の操作はChrome拡張機能のみを使い、同症状では別ブラウザへ切り替えず、未保存のまま状況を報告する。単一タグ専用フォルダを回避策にしない。
• 既存の単一タグ専用フォルダを統合する順番は、参照アクションを個別タグ指定へ置換、保存後読戻し、タグを企画別フォルダへ移動、旧フォルダ件数0の確認とする。旧フォルダの削除は別判断とし、参照確認前に削除しない。
• 終了済みで参照置換を行わないフォルダは、名称の先頭へ 【終了・後にまとめます】 を付ける。名称変更だけを行い、フォルダID、タグ所属、既存アクション参照は維持する。

TS共通友だち情報の改名後の確認（2026/09/16）

承認済みの同一ID改名：TS-公開セミナー名（2780601）、TS-セミナー参加日時（2782178）、TS-セミナー参加URL（2782179）、TS-セミナーID（2782180）。TS-開催ID（2780599）は改名済みを維持する。未確認のTS_A/TS_B項目は一括改名しない。

• フォームの外側要約に旧名が残る場合、アクションを開いて選択チップ・見出しの正式名と代入値を確認する。表示更新だけのためにフォーム全体を再保存しない。
• 本文の名前依存差込は自動追従を前提にせず、エディタ読込と正式トークン変換を待って新名称を確認する。
• 他の名前差込・フォームコード・段落・URL・訪問時アクションを維持し、保存後に各本文を再度開いて照合する。読戻しと実送信の展開確認は区別する。
• 過去記録と適用済み版は保持し、変更項目・確認した参照先だけ現在の証拠へ追加する。

原本：references/registration-flow.md
この画面は原本から生成されています。