KUZEN→Phoenix 移行 / REBOOST・セルフコア・ザビジョン 申込決済 統合EC ブループリント
MIZUKARA
◆ DX BLUEPRINT ・ KUZEN→Phoenix 移行 ・ 2026-06-23

LINEシナリオ地獄の申込・決済を、
顧客の状態を理解する「統合ECサイト」へ。

REBOOST / セルフコア / ザビジョンの複雑な申込・決済フローを n8n で“再現”せず、受講履歴に応じた商品の出し分け・クーポン自動適用・決済パターン別案内を1サイトに集約する。移行コスト・保守・オペレーション・顧客UX —— 四方の勝ち筋を、KUZEN移行という同じ一回の工事で取りに行く構想。

4,600回/月
申込決済案内の発火数=最複雑ステップ
3
サービス×同一ロジック(リブースト/セルフコア/ザビジョン)
~70%
部品は commune-integration / FUZEN に既存
1tap
LINEミニアプリSSOでログイン
対象: データ戦略推進課 / セルフコア事業部 ・ 想定読者: 経営層・事業部・開発(田端/稲川/舟瀬/西川)・ 読了目安 15分 ・ 種別: 戦略ブループリント(叩き台)
★ Governing Thought
REBOOST/セルフコア/ザビジョンの申込・決済は、LINE UIの制約が生んだ“分岐の無限増殖”が本質的な複雑性。これを n8n で再現するのではなく、顧客の受講履歴を読んで商品・価格・クーポン・決済フローを自動で出し分ける統合ECサイトへ寄せる。移行コスト・保守・オペ・顧客UXが同時に改善する“四方良し”で、KUZEN移行と同じタイミングでしか取れない勝ち筋。

この主張を支える4つの理由(Key Line)。「なぜ?」で下に降りると各セクションの根拠に繋がります。

KEY LINE 1 — 移行コスト
作り直しではなく「横展開」
認証(LINEミニアプリ)・Stripe決済・決済状態ゲーティング・クーポンは commune-integration で実装済み。枠管理画面・時間差リマインドは田端さんがセルフコアで4月に先行実装済み。ゼロからではなく既存資産の転用
KEY LINE 2 — 保守運用
エンティティ増殖から解放される
LINEボタン上限・状態保持の縛りが「複数版/非複数版の二重実装」「再判定の挟み込み」を生んでいた。Webなら分岐はコードと管理画面に集約。クーゼの巨大シナリオを目視で追う検証地獄が消える
KEY LINE 3 — オペ/事業部
枠・クーポンが管理画面で完結
日程・枠はSalesforceマスタ→管理画面へ、クーポンはStripe標準機能へ移管。事業部が自分で操作できる。マーケはLINE側の告知URLだけ差し替えればよい。
KEY LINE 4 — 顧客UX
“Amazonで買う感覚”の申込体験
クソ長いLINE申込フロー+月4,600回のエラー再送(「もう一度日程選択を…」)から、状態に合った商品が並ぶECへ。セット販売(REBOOST+セルフコア+ザビジョン一括)も自然に実現。
4方良し
移行 / 保守 / オペ / 顧客
トレードオフが少ない稀な構想
±0〜−
実装工数(再現比)
検証コストを含めるとむしろ得
回避できる検証負荷
量3倍×複雑さ=検証は5倍しんどい(稲川)
7→2026
着手は7月、移行と同期
今やらないと二度手間になる
この資料の読み方 AS-IS(現状の複雑性)→ 既存資産 → TO-BE(統合EC)の順。論点は「ユーザーフロー観点/オペレーションフロー観点/システム処理フロー観点」の3レイヤーで整理しています(§4・§6)。図はMermaidで描画(ネット接続が必要)。専門用語は初出時にかっこ書きで補足します。

Why nowなぜ“今”やるのか — now or never

「クーゼ乗り換えのタイミングでさらに開発を上乗せする変な提案」に見えて、実は別々にやる方が高くつく。KUZEN移行では結局この申込決済フローに手を入れる。ここで「再現」を選ぶと、巨大シナリオを n8n に作り直し→目視検証(バーソン側確認含め長期)が必要。EC化を選べば、その作り直し工数を“前向きな資産”に振り替えられる。

①再現ルートの罠
複雑シナリオをn8n移植 → 抜け落ちリスク高・検証が最難関(“CC3体分以上”)
②EC化ルート
同工数を新サイトに投下 → 検証は「ECの状態を見る」方が圧倒的に楽(稲川)
③タイミング縛り
セット販売・LINE認証統一・枠/クーポン移管は“今この工事で”しか綺麗に入らない
正直な前提(誇張しない) 「実装工数 ±0〜マイナス」は検証コストを織り込んだ場合の見立てです。新規UI/UX・Stripe移行・データ連携の作り込みは発生します。確実なのは「部品が既存」「検証が楽になる」の2点で、純工数の正確な比較は 論点①(LINE/Web境界)と③(スコープ)の決定後に出します。

REBOOSTはすべてルートシナリオ経由。共通処理(流入履歴・Lead作成)の後に「申込決済案内」ライブラリが「申込種別判定」ライブラリとセットで動く。申込に必須の3情報=①開催日程/②選択日程/③クーポンを、3つのステータス(参加済/通常新規/日程変更)に分岐させながら組み立てる。

図1-1. AS-IS:KUZEN REBOOST 申込決済フロー(赤=複雑化ホットスポット / 紫=外部連携 / 青=共通)
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
共通/起点複雑化ホットスポット派生分岐外部連携(SF/フォーム/決済)
UX症状として表面化している 「申込決済案内」は月4,600回発火し、「予約を受け付けました→次の日程選択でエラー→もう一度日程選択を」という再送が多発。状態保持と外部連携の縛りが、そのまま顧客体験の悪化として出ている。

So Whatどこで・なぜ・どれだけ複雑化しているか

田端さんの言葉:「分岐の複雑さが増すと“エンティティ無限増殖”の世界に近づく。それを逃がすために外部連携(Salesforce/外部フォーム)をしていた」。複雑性は5つの構造要因に分解できる。

複雑化の要因どこで効くかなぜそうなるか(根因)どれだけ
LINE UIの制約日程提示・キャンセル待ちボタン上限4 → 月2回開催で最大5日程を出せず「複数版」を別実装。テキストで滑らかに出す縛り。二重実装
状態保持できない再判定ステップLINEメッセージ間で状態が保てない → 期間を置いて再開すると枠が埋まっている → 申込断面で“最新状態の再ジャッジ”を何度も挟む。多重チェック
クーゼにDBがない枠マスタ・クーポンマスタ枠数・クーポンをSalesforceに持たせ、クーゼから都度問い合わせ。複合キーは文字列連結で表現。外部連携前提
組合せ爆発申込種別判定 全体3ステータス × 日程 × クーポン × 満枠 × キャンセル待ち × 複数/非複数 × JCC遺産。掛け算で増殖
×3サービス全フローREBOOST/セルフコア/ザビジョンで同じことを3回。1アカウントに3サービス=“ケルベロス”。物量3倍
検証コストの非線形性 稲川さん:「量は3倍だが、複雑さが増すので検証は5倍しんどい」。=このフローこそ移行の最大ボトルネック。だからこそ“再現”ではなく“作り替え”が効く。

実測“どれだけ”を数字で裏取り(KUZEN GraphQLライブ抽出)

ログインして KUZEN editor の GraphQL(serviceSteps)から実データを取得。サービス全体で4,323ステップ、うち申込決済クラスタだけで約570ステップ。「申込決済案内」本体は138ステップで、16の流入経路から呼び出されている(JCC専用先行案内 / YouTube経由 / キャリスピ受講者 / 自己理解コース受講者 / ナーチャリング配信設定 / お問い合わせ など)。

ライブラリ(申込・日程・決済クラスタ)ステップ数役割
申込決済案内(98603)138本体。種別×日程×クーポン×決済の司令塔
日程変更(98740)147申込後の日程変更オペ
フォーム回答完了(98764)94決済フォーム送信後の処理
申込可能日程判定(97308)47SF開催マスタから空き日程判定
申込可能日程判定_複数(108121)444日程超に対応する「複数版」
クーポンコード判定(98741)33SFクーポンマスタ照合
申込可能日程判定_251212(106904)29別バージョン(重複の疑い)
申込種別判定(97479)245ステータス判定(本体から3回再呼出)
REBOOST2回目以降受講(109400)11最受講判定
【使用禁止】申込案内※旧フロー(97348)34遺産(要退避)
合計(旧フロー除く)約570=この申込決済1機能のためのステップ群

「申込決済案内」138ステップの内訳(種類別)— 分岐と変数操作が支配的

種類意味種類意味
ConditionEntity22条件分岐Intent11ボタン応答
ManipulateEntity21変数の代入・整形Text11テキスト送信
End20終端Jump11別ステップへ飛ぶ(ループ/エラー戻り)
FlexMessage16リッチ表示(出し分け)Button6選択肢
Library13別ライブラリ呼出Notification5Slack通知
DataIntegration1SF書込Start1起点
実分岐の中身(ライブ取得した条件ラベル) 申込種別=5分岐:参加済 / 通常新規 / JCC新規 / 通常日程変更 / JCC日程変更。 申込可能日程数=4分岐(6つ/5つ/4つ/3つ)=LINEボタン上限を超えるための“複数版”の存在理由。 さらに 該当クーポン数(0/1)・フロー通過日時(価格改定前/後)・Rebbost2回目以降受講判定新しい日程公開通知判定(elseはキャンセル待ち)。 FlexMessageは流入別に枝分かれ:reboost-entry版×8 / スクワッドビヨンド版×2 / キャリスピ2.0顧客向け×1 =申込導線そのものに“出し分け”が埋め込まれている。
月4,600回エラーの正体(実メッセージ) エラーノードの本文は実際にこう:「日程選択でエラーが発生しました。もう一度日程選択をお願いします。」。申込案内ノードも「10分以内に…エラーが発生した場合は最初からお申し込みをやり直してください。=状態保持できないがゆえに、エラー時はフロー先頭へ戻すしかない。これが発火数と離脱の主因。
🔍 “状態をURLに詰めて外部フォームへ投げる”構造(reboost-entry の実URL)— EC化で一掃する対象

REBOOSTの申込フォームURLは、11個の状態を全部クエリパラメータに詰めて外部(mizukara.com/reboost-entry)へ渡している(田端さんの言う「すごいいっぱいパラメーターを持ったURL」の実体)。これは「DBが無い→状態をURLで運ぶ」AS-ISの象徴で、EC化すれば“サーバが状態を保持して出し分ける”に置き換わり、この詰め込みは消える

パラメータ中身パラメータ中身
dt_avail申込可能日程判定日時s_cdtype割引コード種別
s_uiduser_ids_fcdフォーム判定コード
d_fd申込日程_日付dt_cccheckクーポンコード判定日時
s_cc適用クーポンコードs_campaign施策名(流入)
form_base_id申込フォームIDs_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

mizukara-corp/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)

このリポ/Phoenix XA データ面
  • 受講履歴の真実源接続: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(田端・先行実装)

6/22定例ヒアリング由来 ※コード未確認
  • 独自申込フォーム+Stripe決済(セルフコアは既にストライプ先行)
  • 枠数管理の管理画面:大店定員・確定・決済未完了の人数把握
  • 時間差リマインド:Cloud Tasks / Pub/Sub(4月に仕込み済み)
  • → 1個手前にサービス選択を挟めば REBOOST へほぼそのまま横展開可
統合の方向性(田端さんの狙いと一致) 「全部の入り口」を1つに:顧客=LINEミニアプリSSO(コミューンと同じシングルサインオン)、運営=Google SSO(Phoenix XAと共通のログイン基盤)。ログインは今後あらゆる新規プロダクトで出てくるので、ここを共通化しておくと後々効く。
確度の明示(誇張しない) ★★★ 確実=commune-integration / FUZEN の各部品は実コードで存在を確認済み。★★ 観測=セルフコアEC(枠管理/リマインド)は6/22定例の田端さん説明に基づく(当該リポは未取得)。提案部分=「commune(POTENTIALサブスク)で実証したパターンを、REBOOST等のセミナー申込決済に転用する」点は“実証済みパターンの新規適用”であり、転用可否はPoCで確定する。

役割を綺麗に分ける:LINE/n8n=接客と通知EC(連携層オーケストレーター)=状態判断・出し分け・決済Salesforce=受講/会員の真実源(読取)Stripe=決済とクーポン管理画面=枠とモニタ。下図は色=担い手(エンティティ)で固定。

図3-1. TO-BE 全体アーキテクチャ(色=担い手:緑=LINE / 水色=EC連携層 / 橙=決済 / 紫=データ真実源 / 灰=運営)
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
LINE/n8n(接客・通知)EC連携層Stripe(決済)データ真実源運営管理画面
🏠 たとえると
今は「電話オペレーターが分厚いマニュアルを1ページずつめくりながら受付」している状態。TO-BEは「ログインしたら“あなたが買えるもの”だけが棚に並ぶネットショップ」。マニュアル(分岐)はレジ裏のシステムに隠れる。

AS-IS → TO-BE の置き換え対照

論点AS-IS(KUZEN)TO-BE(統合EC)
申込の判断LINEシナリオの多段分岐(再判定を多重に挟む)サーバの純関数1箇所(受講履歴×枠×クーポン)
日程・枠管理Salesforceにマスタ+クーゼが都度参照管理画面(Cloud SQL)に集約。事業部が操作
クーポンSalesforceクーポンマスタ+分岐Stripe標準クーポン/プロモコード(自動適用)
決済セルフコア=Stripe / REBOOST=外部フォーム+PayPalStripeに統一(サブスク/単発/セット)
認証LINE上のやり取りで都度識別・状態保持に苦労LINEミニアプリSSO(1tap)+運営Google SSO
セット販売困難(個別フローを跨げない)カートで一括決済(REBOOST+セルフコア+ザビジョン)
リマインドクーゼ起点Cloud Tasks/n8n(セルフコア実装を流用)
受講状況での出し分け分岐で都度判定ログイン時にSalesforce/BQから引いて棚に反映
なぜ3レイヤーに分けるか事業部・オペ・開発で「気にしている層」が違う。ユーザーフロー=顧客体験オペレーションフロー=事業部/運営/マーケの作業システム処理フロー=技術の責務分担。各層がクリアになると論点(§6)が噛み合う。
USER FLOW

4-1. ユーザーフロー —— “Amazonで買う感覚”

顧客は LINE で告知を見て「申し込む」をタップ → ミニアプリが1tapログイン → 自分が受けられるサービスだけが並ぶ → 日程選択 → クーポン自動適用 → 決済 → LINEに戻る。離脱しても入口は1つなので迷子にならない。

図4-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
出し分け①
受講可能なサービスだけ“買える棚”に。済みは最受講価格、未受講は通常価格
出し分け②
満枠はキャンセル待ち、合わない日程は新着通知登録(AS-ISの良い部分は継承)
出し分け③
セット販売=一括決済。クーポンは顧客状態から自動適用(コード手入力を極小化)
論点に直結(§6-A)「どこまでをLINE UIで、どこからWeb UIで」は申込率に直結する設計判断。例:日程選択をLINE画面で出したい(事業部)vs Webで出す。ユーザーフローはこの境界線で形が変わる。
OPS FLOW

4-2. オペレーションフロー —— 事業部が自分で回す

運営はサービスを選んで管理画面に入り、枠・日程を登録し、申込/決済状況を見る。クーポンはStripe、告知URLはマーケがFUZENで設定。エンジニアにシナリオ改修を依頼する世界から、セルフサービスへ。

図4-2. オペレーションフロー(運営/事業部/マーケ)
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で完結(有効期間・割引)
開発分岐改修・巨大シナリオ検証出し分けロジックの単体テスト中心(純関数)
SYSTEM FLOW

4-3. システム処理フロー —— 責務の分担

commune-integration の確定設計(S-01)を、REBOOST の「受講履歴での出し分け」「枠判定」に拡張したシーケンス。クライアントの自己申告を信用せず、ID トークンをサーバ検証するのが肝。

図4-3. システム処理フロー(申込→決済→確定→リマインド)
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でリマインド/完了通知
設計のキモ(commune由来・実証済み)入口は1つ(ミニアプリ)で決済状態によりルーティング。② 顧客IDはサーバ検証oauth2/v2.1/verify+aud一致)。③ Stripe顧客はline_uidで重複防止。④ 決済完了はwebhookで状態へ投影(冪等)。⑤ 有料/無料(クーポン100%off)でも処理経路は同一=分岐を増やさない。

顧客側はメール/パスワード登録なし。ミニアプリで「ログイン」を1回押して承認するだけ(コミューンと同じシングルサインオン)。運営側はPhoenix XAと同じGoogle SSO。ログイン基盤を共通化しておくと、今後の新規プロダクト全部の入口になる。

図5-1. 認証シーケンス(LINEミニアプリ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ミニアプリ / LIFFliff.getIDToken()→サーバがapi.line.me/oauth2/v2.1/verifyで検証、sub=line_uid。aud=ログインチャネルID(LIFF_CHANNEL_ID)を二重確認。ミニアプリchannelは公式アカウントと同一プロバイダー配下が必須。
運営ログインGoogle SSOFUZEN は NextAuth v5+Google OAuth、@ドメイン許可リストで運営限定(Phoenix XAと同型)。EC運営画面も同基盤を流用=共通ログイン基盤。
顧客↔内部IDFirestore/CloudSQL マップline_uid をキーに Stripe Customer / 決済状態 read model を引く(commune は Firestore customer_ids / payment_status)。重複Customer生成を防止。
サービス間連携Cloud Run IAMEC↔FUZEN↔n8n はサービスアカウントID トークン(IAM)で内部認証。既にFUZENで稼働中。
“コネクティング・ドット”稲川さんがコミューンで作ったLINE SSOが、そのままこのECの認証になる。田端さん:「全部繋がってきた」。今ミニアプリで作っておくと後々すごく効く。

「決まっていないこと」を隠さず明示します。★が最重要(先に決めると後段が連鎖的に決まる)

#論点主たる観点選択肢 / トレードオフ叩き台の方向性
★1LINE 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観点観点ごとに「何を握れば前に進むか」

ユーザーフロー観点

LINE/Web境界(★1)
日程選択・申込のどこを各UIで出すか。申込率テストの設計。
セット販売の見せ方(7)
単品→セットの推奨、前提未充足のロック表現。
クーポンの自動適用UX
コード手入力をどこまで消すか(状態から自動)。

オペレーションフロー観点

スコープ段階(★2)
REBOOST先行→横展開の順序と事業部合意。
枠/クーポン移管(5)
SF→管理画面/Stripe。誰がいつ操作するか。
検証/リリース(9)
段階公開・確認担当・期間。25日に頭出し可。

システム処理フロー観点

基盤の持たせ方(★3)
commune core共通化の範囲、リポ構成。
認証/決済(4・6)
ミニアプリSSO・Stripe統一の確定と実機検証。
データ真実源(8・10)
受講正準キー・初回判定・Zoom参加経路。
隣接論点(このECとは別だが連動) マーケコード履歴/流入経路の取り込み(n8nシナリオのDB化=非共通行をDBに落としFUZEN API経由で更新)は別アジェンダですが、“ハードコーディングを増やさず管理画面/DBに寄せる”思想は同じ。EC化と同じ方向の投資です。
Phase 0 — 方針合意・PoC〜7月上旬
論点★1/★2/★3を決定。commune coreのREBOOST転用PoC(受講履歴出し分け×Stripe×ミニアプリ認証)。25日に事業部へ頭出し。
Phase 1 — REBOOST EC(最小)7月〜
REBOOST申込決済をEC化。枠管理=セルフコア管理画面に1個手前のサービス選択を追加して流用。Stripe/ミニアプリ/出し分けロジック。新機能“付与”でJCC本番に非干渉。
Phase 2 — セルフコア/ザビジョン横展開+セット販売8月〜
同core上に3サービスを載せる。受講状況での組合せ制御、一括決済。リマインドはCloud Tasks流用。
Phase 3 — 全社入口の統合将来
JCC/キャリスピも公式LINEからECへ送客。LINE SSO/運営Google SSOを“全プロダクトの入口”に。お客様は他商品も回遊できる。
本番影響の遮断(舟瀬さんの懸念に対応) JCCとREBOOSTは当面別環境。新しい受け口(Webフック/APIの口)を“生やす”形で機能追加すれば、既存の本番動作を壊さず付加できる(純粋な機能追加=負荷だけ)。共通化しすぎてJCC本番に影響するのは避ける。

タブ切替(顧客側ミニアプリEC / 運営側管理画面)と画面遷移を、別HTMLでモック化しました。デザインは特定クライアント色を出さず汎用的なSaaSトーン。業務SaaSのUI/UX作法(状態チップ・縦型タイムライン・淡色tintカード・ステータスタブ)を踏襲。

🖥️ 画面イメージ(タブ切替・画面遷移)を開く →
位置づけ画面モックは「叩き台のイメージ」。確定仕様ではなく、論点★1(LINE/Web境界)を絵で議論するための素材です。
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. 論点★1(LINE/Web境界)→ ユーザーフロー確定 → 画面仕様。
  2. 論点★2(スコープ)→ ロードマップ確定 → 工数の正確な見積り。
  3. 論点★3(基盤の持たせ方)→ リポ構成・共通core範囲。
  4. 受講状況の正準キー(キャリスピ/JCC/組織開発でオブジェクトが違う)。
  5. セルフコアECリポの取得と現物確認(枠管理/リマインドの再利用度)。
  6. Zoomセミナー参加判定の取り込み経路(BQ→ユーザー行動履歴)。
この資料の位置づけ叩き台(ブループリント)です。明日の定例(田端さん)で当てて、事業部(25日)に頭出しするための素材。数値・工数は論点決定後に精緻化します。