この主張を支える4つの理由(Key Line)。「なぜ?」で下に降りると各セクションの根拠に繋がります。
commune-integration で実装済み。枠管理画面・時間差リマインドは田端さんがセルフコアで4月に先行実装済み。ゼロからではなく既存資産の転用。Why nowなぜ“今”やるのか — now or never
「クーゼ乗り換えのタイミングでさらに開発を上乗せする変な提案」に見えて、実は別々にやる方が高くつく。KUZEN移行では結局この申込決済フローに手を入れる。ここで「再現」を選ぶと、巨大シナリオを n8n に作り直し→目視検証(バーソン側確認含め長期)が必要。EC化を選べば、その作り直し工数を“前向きな資産”に振り替えられる。
REBOOSTはすべてルートシナリオ経由。共通処理(流入履歴・Lead作成)の後に「申込決済案内」ライブラリが「申込種別判定」ライブラリとセットで動く。申込に必須の3情報=①開催日程/②選択日程/③クーポンを、3つのステータス(参加済/通常新規/日程変更)に分岐させながら組み立てる。
flowchart TB classDef root fill:#e0f2fe,stroke:#0891b2,color:#0f172a; classDef hot fill:#fee2e2,stroke:#dc2626,color:#7f1d1d; classDef warn fill:#fef3c7,stroke:#b45309,color:#78350f; classDef ext fill:#ede9fe,stroke:#7c3aed,color:#3730a3; start(["ルートシナリオ 開始
共通: 流入履歴・Lead作成"]):::root inflow{"流入経路で分岐"}:::root apply["申込決済案内 (138ステップ・16流入から呼出)
月4,600回エラー発火・最複雑"]:::hot kind{"申込種別判定 (24ステップ)
参加済 / 通常新規 / JCC新規
通常日程変更 / JCC日程変更 =5分岐"}:::hot avail["申込可能日判定
SF開催マスタ参照(有効期間)"]:::ext cap{"満枠判定
SF: 可能枠 vs 申込者数"}:::ext dates{"申込可能日程数判定
3/4/5/6日程で分岐
(LINEボタン上限4→複数版を増設)"}:::hot wait["キャンセル待ち
(複数版/旧版が併存)"]:::warn notify["日程が合わない
→新日程オープン通知登録"]:::warn recheck{"再判定
申込断面で最新枠を再チェック
(状態保持の縛り)"}:::hot retake{"2回目以降 受講判定"}:::warn coupon["クーポン判定
SFクーポンマスタ参照"]:::ext formA["最受講価格フォーム"]:::ext form["外部フォームURL生成
状態を11パラメータに詰め
mizukara.com/reboost-entry へ"]:::ext pay["外部決済
セルフコア=Stripe / REBOOST=PayPal"]:::ext start --> inflow --> apply --> kind --> avail --> cap cap -->|空きあり| dates cap -->|満枠| wait dates -->|合わない| notify dates -->|選択| recheck --> retake retake -->|最受講| formA --> pay retake -->|新規| coupon --> form --> pay
So Whatどこで・なぜ・どれだけ複雑化しているか
田端さんの言葉:「分岐の複雑さが増すと“エンティティ無限増殖”の世界に近づく。それを逃がすために外部連携(Salesforce/外部フォーム)をしていた」。複雑性は5つの構造要因に分解できる。
| 複雑化の要因 | どこで効くか | なぜそうなるか(根因) | どれだけ |
|---|---|---|---|
| LINE UIの制約 | 日程提示・キャンセル待ち | ボタン上限4 → 月2回開催で最大5日程を出せず「複数版」を別実装。テキストで滑らかに出す縛り。 | 二重実装 |
| 状態保持できない | 再判定ステップ | LINEメッセージ間で状態が保てない → 期間を置いて再開すると枠が埋まっている → 申込断面で“最新状態の再ジャッジ”を何度も挟む。 | 多重チェック |
| クーゼにDBがない | 枠マスタ・クーポンマスタ | 枠数・クーポンをSalesforceに持たせ、クーゼから都度問い合わせ。複合キーは文字列連結で表現。 | 外部連携前提 |
| 組合せ爆発 | 申込種別判定 全体 | 3ステータス × 日程 × クーポン × 満枠 × キャンセル待ち × 複数/非複数 × JCC遺産。 | 掛け算で増殖 |
| ×3サービス | 全フロー | REBOOST/セルフコア/ザビジョンで同じことを3回。1アカウントに3サービス=“ケルベロス”。 | 物量3倍 |
実測“どれだけ”を数字で裏取り(KUZEN GraphQLライブ抽出)
ログインして KUZEN editor の GraphQL(serviceSteps)から実データを取得。サービス全体で4,323ステップ、うち申込決済クラスタだけで約570ステップ。「申込決済案内」本体は138ステップで、16の流入経路から呼び出されている(JCC専用先行案内 / YouTube経由 / キャリスピ受講者 / 自己理解コース受講者 / ナーチャリング配信設定 / お問い合わせ など)。
| ライブラリ(申込・日程・決済クラスタ) | ステップ数 | 役割 |
|---|---|---|
| 申込決済案内(98603) | 138 | 本体。種別×日程×クーポン×決済の司令塔 |
| 日程変更(98740) | 147 | 申込後の日程変更オペ |
| フォーム回答完了(98764) | 94 | 決済フォーム送信後の処理 |
| 申込可能日程判定(97308) | 47 | SF開催マスタから空き日程判定 |
| 申込可能日程判定_複数(108121) | 44 | 4日程超に対応する「複数版」 |
| クーポンコード判定(98741) | 33 | SFクーポンマスタ照合 |
| 申込可能日程判定_251212(106904) | 29 | 別バージョン(重複の疑い) |
| 申込種別判定(97479) | 24 | 5ステータス判定(本体から3回再呼出) |
| REBOOST2回目以降受講(109400) | 11 | 最受講判定 |
| 【使用禁止】申込案内※旧フロー(97348) | 34 | 遺産(要退避) |
| 合計(旧フロー除く) | 約570 | =この申込決済1機能のためのステップ群 |
「申込決済案内」138ステップの内訳(種類別)— 分岐と変数操作が支配的
| 種類 | 数 | 意味 | 種類 | 数 | 意味 |
|---|---|---|---|---|---|
| ConditionEntity | 22 | 条件分岐 | Intent | 11 | ボタン応答 |
| ManipulateEntity | 21 | 変数の代入・整形 | Text | 11 | テキスト送信 |
| End | 20 | 終端 | Jump | 11 | 別ステップへ飛ぶ(ループ/エラー戻り) |
| FlexMessage | 16 | リッチ表示(出し分け) | Button | 6 | 選択肢 |
| Library | 13 | 別ライブラリ呼出 | Notification | 5 | Slack通知 |
| DataIntegration | 1 | SF書込 | Start | 1 | 起点 |
🔍 “状態をURLに詰めて外部フォームへ投げる”構造(reboost-entry の実URL)— EC化で一掃する対象
REBOOSTの申込フォームURLは、11個の状態を全部クエリパラメータに詰めて外部(mizukara.com/reboost-entry)へ渡している(田端さんの言う「すごいいっぱいパラメーターを持ったURL」の実体)。これは「DBが無い→状態をURLで運ぶ」AS-ISの象徴で、EC化すれば“サーバが状態を保持して出し分ける”に置き換わり、この詰め込みは消える。
| パラメータ | 中身 | パラメータ | 中身 |
|---|---|---|---|
dt_avail | 申込可能日程判定日時 | s_cdtype | 割引コード種別 |
s_uid | user_id | s_fcd | フォーム判定コード |
d_fd | 申込日程_日付 | dt_cccheck | クーポンコード判定日時 |
s_cc | 適用クーポンコード | s_campaign | 施策名(流入) |
form_base_id | 申込フォームID | s_price | 割引後適用価格 |
s_friend_id | 紹介者_友人ID | ※キャリスピ2.0向けは cbgw.kuzen.io/line_auth/liff_fwd_to_login 経由でLINE認証を挟む別系統 | |
含意:この11パラメータは、そのままECの注文ドメインモデルになる(顧客・日程・クーポン・価格・紹介者・流入)。AS-ISの“URL詰め込み”は、TO-BEの“サーバ状態”へ1:1で写せる。
遺産・重複の棚卸し(複数版 / 非複数版 / JCC分岐)
- 複数版 vs 非複数版:月2回開催で4日程超を出すため後発の「複数版」を実装。旧「非複数版」は直近発火0回=実質未使用の見込み(香川/田端さんに確認依頼中の論点)。
- JCC 0円クーポン分岐:JCC時代の遺産。キャリスピ2.0のREBOOSTありプランは「0円クーポン」で対応=本質的な意味はない分岐。EC化で解消。
- → いずれもEC化で“分岐そのものが消える”類のもの。移行前にKUZEN上で延命する価値は低い。
この構想が“±0〜マイナス工数”たり得る根拠は、認証・決済・データ連携・運営基盤の部品が既に動いていること。新規に書くのは「状態に応じた出し分けロジック」と「申込・カートのUI」に絞られる。
commune-integration
- LINEミニアプリ/LIFF認証+ID トークンのサーバ検証(
oauth2/v2.1/verify・aud二重チェック) - Stripe Checkout(サブスク/単発・顧客重複防止・規約同意・無料期間anchor)
- 決済状態ゲーティング(
/gateでpaid判定し導線分岐) - Stripe標準クーポン/プロモコード・webhook→決済状態read model
- BDD(cucumber)・WIFキーレスCI/CD・Cloud Run/Tasks/PubSub/BQ
FUZEN(line-segment-delivery)
- 受講履歴の真実源接続:Salesforce(jsforce・
LINE_ID__c/LINEID__c) - 行動履歴:BigQuery
line_events / line_users - LINE送信:n8nシナリオトリガ・segment/delivery worker(リマインド起点)
- 運営ログイン基盤:NextAuth Google SSO(ドメイン制限)
- Next.js15 + Drizzle + Cloud SQL + Terraform + dev/prod自動デプロイ
セルフコアEC(田端・先行実装)
- 独自申込フォーム+Stripe決済(セルフコアは既にストライプ先行)
- 枠数管理の管理画面:大店定員・確定・決済未完了の人数把握
- 時間差リマインド:Cloud Tasks / Pub/Sub(4月に仕込み済み)
- → 1個手前にサービス選択を挟めば REBOOST へほぼそのまま横展開可
役割を綺麗に分ける:LINE/n8n=接客と通知、EC(連携層オーケストレーター)=状態判断・出し分け・決済、Salesforce=受講/会員の真実源(読取)、Stripe=決済とクーポン、管理画面=枠とモニタ。下図は色=担い手(エンティティ)で固定。
flowchart TB
classDef line fill:#dcfce7,stroke:#16a34a,color:#14532d;
classDef ec fill:#e0f2fe,stroke:#0891b2,color:#0c4a6e;
classDef pay fill:#ffedd5,stroke:#ea580c,color:#7c2d12;
classDef data fill:#ede9fe,stroke:#7c3aed,color:#3730a3;
classDef ops fill:#f1f5f9,stroke:#475569,color:#1e293b;
subgraph L["接客・通知(LINE / n8n・FUZEN)"]
rich["公式LINE 告知・リッチメニュー"]:::line
n8n["n8n / FUZEN
リマインド・告知送信"]:::line
end
subgraph E["統合ECサイト(連携層オーケストレーター)"]
mini["LINEミニアプリ フロント
受講履歴で商品/価格を出し分け"]:::ec
orch["状態判断ロジック(純関数)
受講状況×枠×クーポン×決済"]:::ec
admin["運営 管理画面
サービス選択→枠/日程/モニタ"]:::ops
end
subgraph P["決済(Stripe)"]
stripe["Stripe Checkout
サブスク/単発/セット・標準クーポン"]:::pay
rm["決済状態 read model"]:::pay
end
subgraph D["データ真実源"]
sf["Salesforce
受講履歴・会員(読取)"]:::data
cloudsql["Cloud SQL
枠・日程・注文"]:::data
bq["BigQuery
行動履歴・分析"]:::data
end
rich -->|"申込タップ→line_id付与"| mini
mini -->|"id_token検証"| orch
orch -->|"受講状況 照会(読取)"| sf
orch -->|"空き枠/定員"| cloudsql
orch -->|"出し分け結果"| mini
mini -->|"Checkout生成"| stripe
stripe -->|"webhook"| rm
rm -->|"確定→受講予約 upsert"| sf
rm -->|"行動/決済イベント"| bq
rm -->|"リマインド予約"| n8n
admin -->|"枠/日程 登録・モニタ"| cloudsql
stripe -.クーポン管理.- admin
n8n -->|"配信"| rich
AS-IS → TO-BE の置き換え対照
| 論点 | AS-IS(KUZEN) | TO-BE(統合EC) |
|---|---|---|
| 申込の判断 | LINEシナリオの多段分岐(再判定を多重に挟む) | サーバの純関数1箇所(受講履歴×枠×クーポン) |
| 日程・枠管理 | Salesforceにマスタ+クーゼが都度参照 | 管理画面(Cloud SQL)に集約。事業部が操作 |
| クーポン | Salesforceクーポンマスタ+分岐 | Stripe標準クーポン/プロモコード(自動適用) |
| 決済 | セルフコア=Stripe / REBOOST=外部フォーム+PayPal | Stripeに統一(サブスク/単発/セット) |
| 認証 | LINE上のやり取りで都度識別・状態保持に苦労 | LINEミニアプリSSO(1tap)+運営Google SSO |
| セット販売 | 困難(個別フローを跨げない) | カートで一括決済(REBOOST+セルフコア+ザビジョン) |
| リマインド | クーゼ起点 | Cloud Tasks/n8n(セルフコア実装を流用) |
| 受講状況での出し分け | 分岐で都度判定 | ログイン時にSalesforce/BQから引いて棚に反映 |
4-1. ユーザーフロー —— “Amazonで買う感覚”
顧客は LINE で告知を見て「申し込む」をタップ → ミニアプリが1tapログイン → 自分が受けられるサービスだけが並ぶ → 日程選択 → クーポン自動適用 → 決済 → LINEに戻る。離脱しても入口は1つなので迷子にならない。
flowchart TB classDef u fill:#e0f2fe,stroke:#0891b2,color:#0c4a6e; classDef d fill:#fef3c7,stroke:#b45309,color:#78350f; classDef g fill:#dcfce7,stroke:#16a34a,color:#14532d; a["LINEで告知/リッチメニュー
『申し込む』をタップ"]:::u b["ミニアプリ起動
1tapログイン(承認のみ)"]:::u c["ホーム:受けられるサービス一覧
受講履歴で出し分け"]:::u d{"受講可否"}:::d e["REBOOST/セルフコア/ザビジョン
選べる商品が並ぶ"]:::u f["前提未充足はロック+理由表示
(例: 先にREBOOST受講が必要)"]:::d g["日程選択
空き枠表示/満枠はキャンセル待ち"]:::u h["カート:セット割/参加済割を自動適用"]:::u i["Stripe決済(規約同意)"]:::u j["完了→LINEに戻る
リマインド予約済み"]:::g a-->b-->c-->d d -->|受講可| e --> g --> h --> i --> j d -->|前提未充足| f
4-2. オペレーションフロー —— 事業部が自分で回す
運営はサービスを選んで管理画面に入り、枠・日程を登録し、申込/決済状況を見る。クーポンはStripe、告知URLはマーケがFUZENで設定。エンジニアにシナリオ改修を依頼する世界から、セルフサービスへ。
flowchart LR
classDef ops fill:#f1f5f9,stroke:#475569,color:#1e293b;
classDef pay fill:#ffedd5,stroke:#ea580c,color:#7c2d12;
classDef line fill:#dcfce7,stroke:#16a34a,color:#14532d;
subgraph OP["運営/事業部"]
o1["Google SSOログイン"]:::ops
o2["サービス選択
REBOOST/セルフコア/ザビジョン"]:::ops
o3["日程・枠登録(定員設定)"]:::ops
o4["申込/決済モニタ
確定/未決済/キャンセル待ち"]:::ops
o5["当日運営・参加確認
(Zoom連携)"]:::ops
end
subgraph MK["マーケ"]
m1["LINE告知の流入URL/パラメータ設定
(FUZEN)"]:::line
m2["リマインド文面・タイミング設定"]:::line
end
subgraph PC["クーポン"]
c1["Stripeダッシュボードで発行/管理
(SFクーポンマスタ廃止)"]:::pay
end
o1-->o2-->o3-->o4-->o5
m1-.->o4
c1-.->o4
| 担い手 | AS-IS の作業 | TO-BE の作業 |
|---|---|---|
| 事業部/運営 | 枠はSalesforceで管理、変更はエンジニア確認も必要 | 管理画面で日程・定員を直接編集。状況も一画面で把握 |
| マーケ | KUZENシナリオのデプロイ作業が残る | LINE告知URL/パラメータの設定のみ(FUZEN)。同一シナリオはオン1URLに統一 |
| クーポン担当 | SFクーポンマスタを編集+分岐確認 | Stripe標準UIで完結(有効期間・割引) |
| 開発 | 分岐改修・巨大シナリオ検証 | 出し分けロジックの単体テスト中心(純関数) |
4-3. システム処理フロー —— 責務の分担
commune-integration の確定設計(S-01)を、REBOOST の「受講履歴での出し分け」「枠判定」に拡張したシーケンス。クライアントの自己申告を信用せず、ID トークンをサーバ検証するのが肝。
sequenceDiagram autonumber actor U as 顧客 participant LI as LINEミニアプリ(LIFF) participant EC as EC連携層(Orchestrator) participant SF as Salesforce(読取) participant DB as Cloud SQL(枠/注文) participant ST as Stripe participant N8 as n8n/FUZEN Note over U,LI: 入口=リッチメニュー→ミニアプリ(URI) U->>LI: 申し込むをタップ LI->>LI: liff.init(自動ログイン)→getIDToken LI->>EC: POST /entry (IDトークン添付) EC->>EC: IDトークン検証→sub=line_uid 確定 EC->>SF: 受講履歴/会員を照会(読取) EC->>DB: 空き枠・定員を取得 EC->>EC: 出し分け(純関数)
受講状況×枠×クーポン×価格 EC-->>LI: 買える商品・日程・適用クーポンを返す U->>LI: 商品/日程を選択 LI->>EC: POST /checkout EC->>ST: Customer(line_uid重複防止)+Checkout Session
(metadata=line_uid・クーポン自動適用) ST-->>LI: Checkout URL U->>ST: 決済(規約同意) ST->>EC: 決済完了 Webhook(署名検証) EC->>DB: 注文・枠確定を記録 EC->>SF: 受講予約を upsert(必要時) EC->>N8: リマインド予約(Cloud Tasks) N8-->>U: LINEでリマインド/完了通知
oauth2/v2.1/verify+aud一致)。③ Stripe顧客はline_uidで重複防止。④ 決済完了はwebhookで状態へ投影(冪等)。⑤ 有料/無料(クーポン100%off)でも処理経路は同一=分岐を増やさない。顧客側はメール/パスワード登録なし。ミニアプリで「ログイン」を1回押して承認するだけ(コミューンと同じシングルサインオン)。運営側はPhoenix XAと同じGoogle SSO。ログイン基盤を共通化しておくと、今後の新規プロダクト全部の入口になる。
sequenceDiagram
autonumber
actor U as 顧客
participant LA as LINEアプリ
participant LI as ミニアプリ(LIFF着地)
participant EC as EC連携層
participant LV as LINE verify API
U->>LA: リッチメニュー(URI)をタップ
LA->>LI: ミニアプリを開く
LI->>LI: liff.init(自動ログイン)
alt 未ログイン
LI->>LA: liff.login()→LINEログイン
LA-->>LI: 戻る(再実行)
end
LI->>LI: getIDToken()
LI->>EC: POST /entry (Authorization: Bearer IDトークン)
EC->>LV: POST verify (id_token + client_id=channelId)
LV-->>EC: 署名/exp/iss/aud 検証OK + sub
EC->>EC: aud再確認 + 形式チェック(U+32hex)→line_uid確定
EC-->>LI: 本人確定 → 出し分け/導線へ
Note over EC: クライアント取得値(getProfile)は信用しない
=公式の禁止事項を順守
| 対象 | 方式 | 根拠/出典(commune-integration / FUZEN 実コード) |
|---|---|---|
| 顧客ログイン | LINEミニアプリ / LIFF | liff.getIDToken()→サーバがapi.line.me/oauth2/v2.1/verifyで検証、sub=line_uid。aud=ログインチャネルID(LIFF_CHANNEL_ID)を二重確認。ミニアプリchannelは公式アカウントと同一プロバイダー配下が必須。 |
| 運営ログイン | Google SSO | FUZEN は NextAuth v5+Google OAuth、@ドメイン許可リストで運営限定(Phoenix XAと同型)。EC運営画面も同基盤を流用=共通ログイン基盤。 |
| 顧客↔内部ID | Firestore/CloudSQL マップ | line_uid をキーに Stripe Customer / 決済状態 read model を引く(commune は Firestore customer_ids / payment_status)。重複Customer生成を防止。 |
| サービス間連携 | Cloud Run IAM | EC↔FUZEN↔n8n はサービスアカウントID トークン(IAM)で内部認証。既にFUZENで稼働中。 |
「決まっていないこと」を隠さず明示します。★が最重要(先に決めると後段が連鎖的に決まる)。
| # | 論点 | 主たる観点 | 選択肢 / トレードオフ | 叩き台の方向性 |
|---|---|---|---|---|
| ★1 | LINE UI と Web UI の境界線 | ユーザー | どこまでLINE画面で出し、どこからWebか。例:日程選択をLINEで出したい(申込率懸念)vs Web。 | 申込率がKPI。顧客テストで決める。原則は「判断・決済はWeb、告知・リマインドはLINE」。 |
| ★2 | スコープ:REBOOSTのみ か 全商品か | オペ | REBOOSTだけ先行 vs セルフコア/ザビジョン/JCC/キャリスピまで一気に。 | REBOOSTで型を作り→横展開(慎重に議論。リブーストはEC化ありで合意寄り)。 |
| ★3 | 実装基盤の持たせ方 | システム | 別プロジェクトのまま / 一部共通化 / 全部乗せ替え(commune coreにどこまで統合)。リポ/コードの持たせ方。 | 認証・決済・連携層は共通core化。サービス固有(枠/日程/セミナー)はモジュール。 |
| 4 | 認証の採用 | システム | LINEミニアプリSSO(推奨)。運営はGoogle SSO共通基盤。 | ミニアプリで確定方向(commune実証済み)。実機検証(外部ブラウザ復帰/LIFF遷移)必須。 |
| 5 | 枠・クーポンの所在 | オペ | 枠:SF→管理画面へ移管。クーポン:SF→Stripe標準へ。 | 移管で確定方向。SFは受講/会員の真実源として読取に残す。 |
| 6 | 決済の統一 | システム | Stripeに統一(セルフコア先行)。REBOOST現行のフォーム+PayPalをどう移すか。 | Stripeへ寄せる。サブスク/単発/セットの料金設計を整理。 |
| 7 | セット販売/一括決済の実現 | ユーザー | カートで複数商品を1決済。受講状況での組合せ制御。 | Stripeのline_items複数で実現。前提条件(受講順)をロジックで制御。 |
| 8 | データ真実源の確定 | オペ | 受講状況=Salesforce(複数オブジェクトに散在)。LINE_ID充足6-7割。Zoom参加判定の経路。 | line_uidをjoinキーに。受講状況の正準キーは要確定(キャリスピ/JCCで持ち方が違う)。 |
| 9 | 検証期間とリリース戦略 | オペ | 1週間では無理。段階リリース+バーソン/事業部の確認期間。 | 段階公開+長めの検証窓。新機能を“付与”する形で本番影響を遮断(既存JCCに非干渉)。 |
| 10 | 初回/2回目判定・カットオーバー前データ | システム | follow vs リフインフローの入替り。BQはカットオーバー以降のみ→初回判定が難しい。 | カット時の友だち一覧と突合で初回判定。コーディング時に要考慮(決め事として明示)。 |
3観点観点ごとに「何を握れば前に進むか」
ユーザーフロー観点
オペレーションフロー観点
システム処理フロー観点
タブ切替(顧客側ミニアプリEC / 運営側管理画面)と画面遷移を、別HTMLでモック化しました。デザインは特定クライアント色を出さず汎用的なSaaSトーン。業務SaaSのUI/UX作法(状態チップ・縦型タイムライン・淡色tintカード・ステータスタブ)を踏襲。
🖥️ 画面イメージ(タブ切替・画面遷移)を開く →A. 出典と確度(proposal-rigor)
- ★★★ 一次(実コード):commune-integration(LIFF認証/Stripe/ゲーティング/BDD/CI-CD)、FUZEN(Salesforce/BQ/n8n/segment-delivery/NextAuth)は実装を直接確認。
- ★★ 観測(ヒアリング):セルフコアEC(枠管理画面/Cloud Tasksリマインド)は6/22定例の田端さん説明。当該リポは未取得=PoCで現物確認すべき。
- ★★★ 一次(ライブ抽出):AS-IS KUZENフローは KUZEN editor の GraphQL(
serviceSteps)から実データを抽出済み=ステップ数(138/約570)・分岐ラベル(申込種別5分岐 等)・実メッセージ・URLパラメータは実測値。6/22文字起こしと整合。 - 提案:「commune(POTENTIALサブスク連携)の実証パターンを、REBOOST等のセミナー申込決済へ転用」。サブスクとセミナー(日程/枠/キャンセル待ち)は概念差があり、転用の細部はPoCで確定。
B. KUZENライブ抽出(実施済み・方法)
当初は auth.kuzen.io/sign_in のログイン壁でブロックされていたが、提供いただいた認証情報でログインして解消。KUZEN editor は editor.kuzen.io/graphql の GraphQL API(イントロスペクション有効)で動いており、serviceSteps(serviceId) が全ステップ(id/name/type/message/branches/parentLibraryId/jump…)を返す。これを parentLibraryId でライブラリ単位に集計して AS-IS を裏取りした(源に近い層を叩く/DOMスクレイピングは不使用)。
抽出範囲:申込決済クラスタ(98603 ほか)のステップ数・種別分布・条件分岐ラベル・代表メッセージ・外部フォームURLパラメータ。さらに深掘り(各ノードの全メッセージJSON、SF連携の具体クエリ、日程変更147ステップの詳細)も同じ手段で取得可能。
C. 用語
- LIFF / LINEミニアプリ:LINE内で動くWebアプリ。ログイン状態を引き継げる(=1tap認証)。
- ID トークンのサーバ検証:本人確認(=本人かどうかをサーバで確かめる)。クライアントの自己申告は信用しない。
- read model / payment_status:決済状態の“写し”。入場可否を即判定するための軽い参照テーブル。
- オーケストレーター(連携層):複数SaaSの間に立って状態判断を一元管理する“司令塔”。
- billing_cycle_anchor:初回満額請求日(無料期間の終わり)をそろえるStripe設定。
D. 残課題(決める順)
- 論点★1(LINE/Web境界)→ ユーザーフロー確定 → 画面仕様。
- 論点★2(スコープ)→ ロードマップ確定 → 工数の正確な見積り。
- 論点★3(基盤の持たせ方)→ リポ構成・共通core範囲。
- 受講状況の正準キー(キャリスピ/JCC/組織開発でオブジェクトが違う)。
- セルフコアECリポの取得と現物確認(枠管理/リマインドの再利用度)。
- Zoomセミナー参加判定の取り込み経路(BQ→ユーザー行動履歴)。