GENERATION SKILL

トレンドセミナー生成スキル

開催ごとの企画情報から、複製・生成・接続・検証を進める共通手順です。実装で見つけた改善を手順へ戻し、次の開催に引き継ぎます。

レビュー・完了判定ゲート

ファネル全体レビュー、改修後の再監査、できた / 完了 / 修正箇所なし の報告前に読む。ファネル仕様・検証表 のチェック項目を、どの証拠で合格にするかを定める。

1. 完了状態を証拠で分ける

次を同義にしない。

状態必要な証拠
作成済み対象資産が存在する
保存済み保存完了を確認した
読戻し済み画面を閉じ、完全一致IDから開き直して期待値を確認した
接続監査合格上流の接続元と下流の接続先を両方開き、同じIDで接続を確認した
分岐監査合格対象集合が重複なく全分岐へ割り当てられ、未到達集合がない
E2E合格承認済みテストアカウントで入口から期待する副作用まで実発火した
利用可 / 完了必須工程が上記の必要段階まで合格し、利用を止める残課題がない

保存通知、編集前DOM、プレビュー、ローカル台帳、子タスクの最終報告、テスト送信成功だけでは 接続監査合格 や E2E合格 にしない。テスト送信は本文・CRの送達確認であり、URL訪問アクション、タグ、友だち情報、シナリオ開始、予約完了アクションを発火しない場合がある。

実発火していない工程は 設定読戻し済み・実発火未検証 と書く。未検証が残る状態で できた、完全合格、修正箇所0件 と断定しない。

2. 値の意味を先に監査する

キャンペーン台帳の値の契約 で確定した申込経路・正式面談名・カレンダーを照合する。文字列の一致だけでなく、企画帰属と予約サービスの意味が正しいことを確認する。共通仕様にある例示名だけで実カレンダー確認を省略しない。既に確定した契約を別の台帳へ再作成しない。

3. 期待経路を先に固定する

実画面を見る前に、入口・対象状態・期待副作用・出口を1行ずつ書く。

申込フォームと参加前アンケートの完了後は、今回同時申込LPへの経路を別々の必須行にする。開催横断の棚卸し、欠落判定、保存後証拠は フォーム完了後と同時申込LPの再発防止・監査 を使う。フォームやリマインダの完成だけでこの行を合格にしない。

経路入口対象状態期待副作用出口
LINE本文本文CTA申込前本人識別を保ったフォーム表示申込フォーム
LINE CRCR全クリック領域申込前クリック計測と本人識別申込フォーム
QRセミナー中QR全員・初回 / 再読取読取・初回起動証跡、再起動なし同じ終了後シナリオ
個別相談CTA入口フォームサンクス / 本文 / CR / 動画新規予約可能 / 既予約 / 予約中開催ID×導線のLP遷移タグを保存開催別LP
開催別LP内CTA今回LPの全CTALP到達済み経路・面談名を更新(予約中除外)共通カレンダー
予約完了カレンダー完了有効予約完了証跡、セミナー後停止、リマインド開始個別相談リマインド

期待表にない旧入口やフォールバックが実画面にあれば、意図を確認するまで残置を正常扱いしない。

4. 分岐が集合を完全に分けることを証明する

表示されている分岐名だけで判断せず、条件式を述語として書き出す。全対象がちょうど1分岐へ入ることを確認する。

QRは会員・予約状態による行き先分岐を作らず、全員の同一終了後接続を監査する。

  • 会員、非会員、予約中、会員かつ予約中の各初期状態が同じ接続先へ到達する。
  • 本文・シナリオ開始・タグ操作で同じ初回ガードを使う。
  • 開催専用QRは、初回だけの シナリオ開始 → シナリオ中・起動済み追加、無条件の QR読取追加、最後の 初回起動証跡追加 の順である。
  • 再読取と停止・完了・予約後の再読取で再送、再開始、シナリオ中タグ復活がない。永続する初回証跡と解除されるシナリオ中タグを分ける。
  • 共通予約状態と会員状態を変えず、予約中の経路・面談名を上書きしない。
  • QR以外で採用する分岐は、条件の重複・漏れと状態不明の扱いを別途確認する。

5. トリガー移行は新旧の両側を監査する

固定時刻起動からQR起動、旧シナリオから新シナリオなどへ移す場合:

  • 変更前の全開始トリガー、全停止トリガー、接続先IDを列挙する。
  • 新シナリオを最初から配信可で作り、本文・CR・動画・条件・終了接続・稼働状態を読戻す。
  • 新入口から新シナリオへの接続を保存・読戻しする。
  • 制御されたテストで新経路を確認する。
  • 承認済みの旧時刻起動、旧フォールバック、死んだアクションを解除する。
  • 旧シナリオを停止または 現在不使用 と識別し、現行入口から未参照であることを確認する。
  • 新旧の二重起動、空タイミング、本文0件の残骸、削除予定アクションが0件であることを再読込する。

新経路を確認する前に旧経路を外さない。一方、新経路が合格した後も旧トリガーを残したまま 移行完了 としない。

6. URLは表示先だけでなく本人識別と副作用を確認する

クリック可能領域ごとに、次を最後まで解決する。

本文 / CR / 動画 / QR
  → LステップURLまたは外部URL
  → LP
  → LP内CTA
  → フォームまたはカレンダー
  → タグ・友だち情報・シナリオ開始
  • LINE内フォームは、フォームが表示できるだけで合格にしない。保存後読戻しでは全日程選択肢に開催別正本タグと共通 TS-申込済み の個別追加があることを確認する。承認済みテスト友だちによるE2Eでは、回答者が本人へ紐づき、両タグと参加前リマインダが開始することを確認する。
  • 外部配信用短縮URLや _anonymous 化するURLを、LINE内CRへそのまま流用しない。直近正常例とURL形式、本人識別、訪問時アクションを比較する。
  • 1通目を直した場合、同じ目的の2通目以降、本文、CR全領域、通知文を全件確認する。
  • LP・CTAは 現行標準 に従う。開催ID×導線別にLPを接続し、各LPの6個のCTAを共通化する。LP入口は遷移タグ、LP内CTAは申込経路・正式面談名の更新(予約中除外)とクリックタグ・最終反応日を記録する。 フォーム・本文・CRから短縮URL、公開LP、全6CTAを実際に確認する。
  • 予約先URLの正本と実効転送先は LP・CTAの現行標準 の「予約カレンダーURLの取得と照合」に従って確認する。PCで到達したQR案内URLを予約先に登録している場合は要修正。正式予約URLでもPCではQRが出る場合があるため、PCの表示だけで誤設定と断定しない。
  • LINEアプリ内の承認済みテスト友だちでLIFFがカレンダーへ到達することを確認する。PCでの確認だけなら、保存後読戻しの結果と分けて LINE内カレンダー表示未検証 と記録し、E2E合格にしない。
  • 開催別専用LPのCTAが他開催へ誤帰属しないこと、LPの識別不能な流入を推測で帰属させないこと、URLに個人情報がないことを確認する。
  • WordPressなど外部LPのCTA差替え前に候補URLの設定と遷移を確認し、別流入経路・旧カレンダーへ飛ばないことを確認する。QR表示の場合は、上の予約URL照合とLINE内確認で判定する。誤遷移時に戻せるよう変更前URLを記録する。

7. 参照先を深掘りする

シナリオ画面に表示される名前だけで合格にしない。

  • 全タイミングから参照される本文、テンプレート、CR、動画、回答フォームを開く。
  • 期待する媒体種別を固定する。動画枠に画像、回答フォーム枠に裸URLなど、種類が違えば不合格にする。
  • 旧企画名、旧日程、旧Zoom、旧LP、旧面談名、旧特典を参照先本文まで検索する。
  • 配信順、同時刻内の順番、動画の再生先、CRの全クリック領域を確認する。
  • 空タイミング、無条件の残存アクション、条件だけ違う重複アクションを数える。
  • SEO固定入口は恒久URL、既設クッション、共通案内、受付中カード、開催専用フォームを両方向にたどる。募集配信が対象外でも省略せず、カードの公開名・日時・画像/ボタンの接続・代替テキスト・掲載状態を読戻す。
  • 終了後シナリオの開始直後CTAは1件であり、複製元テンプレートと今回テンプレートが連続していない。
  • 終了後シナリオの最終処理は完了タグ追加とシナリオ中タグ解除を行い、シナリオが配信可であることを確認する。
  • 予約完了の開催別2動作は 個別相談_申込経路 が <開催ID>_ を含む 条件を持ち、無条件の開催別タグ操作がない。共通カレンダーへ直接保存できない場合は、解除可能な共通予約状態タグの追加時アクションから開催専用の無送信シナリオへ接続し、反復設定・最短遅延・2動作を読戻す。既設の全シナリオ停止に停止操作を重ねない。
  • 開催タグは1つの企画別タグフォルダに集約し、単一タグ専用フォルダを新設しない。フォーム、短縮URL、流入経路、シナリオ、カレンダーの各アクションを保存後に開き直し、選択タグのチップと タグ[...] の追加/解除要約を確認する。タグフォルダ[...] が残る場合は移行未完とする。
  • TS-申込済み は共通の申込経験者タグとしてだけ使い、開催別のリマインド・人数・取消・実参加条件に混入していないことを確認する。遡及付与は各一括操作の成功表示と共通タグの最終ユニーク人数を証拠にし、開催別人数の合計を成功人数と断定しない。

8. 保存後の実読戻しと工程間引継ぎ

改修担当の保存前表示を証拠にしない。保存後検証の引継ぎ に従い、保存後に閉じて完全一致名・IDから開き直した結果を使う。同一タスク内の同じ保存状態は再利用できる。別タスクの完了報告しかない場合や状態の一致を判断できない場合は、親の最終監査で本番画面を再取得する。

最終表は各行について次を持つ。

期待値 / 実値 / 完全一致ID / 設定リンク
保存後読戻し / 接続元 / 接続先
分岐の重複・漏れ / 実発火結果
残課題 / 利用可否

不合格を直したら、変更項目とその影響先を再検証する。共通条件・テンプレート・生成規則に問題があれば、その影響を受ける全件を再走査する。合格項目数ではなく、必須経路に不合格または確認不能が1件でも残るかで完了を決める。

9. E2Eは事前状態と各分岐を分ける

承認済みテストアカウントを使う前に、今回企画のタグ、友だち情報、購読中シナリオ、予約状態を記録する。過去テストの起動済みタグや申込経路が残ったまま、今回の副作用とみなさない。

  • 解除が必要なら今回企画専用の証跡だけを対象にし、会員判定、共通予約状態、他企画タグを勝手に外さない。
  • 会員、非会員予約済み、非会員未予約を同じ初期状態で連続テストしない。状態ごとのテストアカウントまたは承認済みリセット手順を使う。
  • 各テスト前後で、入口クリック、付与タグ、友だち情報、開始・停止シナリオ、予約状態を差分として記録する。
  • テストできなかった分岐を、別分岐の合格から推測して合格にしない。
  • テスト後に残す値と戻す値を決め、実運用の判定を汚さない。

原本:references/review-and-completion-gate.md
この画面は原本から生成されています。