MARK-60 / v0.4 / オンボ大幅簡素化 + 三指標並列管理

Path D オンボ設計 v0.4

招待メンバー（Path D）活性化率 0% の打破。
単一フロー（役割選択廃止、全員非管理者扱い）+ tp-5 系メール 3 種で 0% → 15%（v0.1、 N≥10）→ 25%（v2.0、 N≥15）→ 40%（Phase 2） を目指す。 CEO 裁定 2026-05-22。

更新: 2026-05-22 v0.4 原典: strategy/deliverables/onboarding-path-d-invited-member-2026-05.md v0.4 連動: PRD v2.3 / A/B v0.4 / Layer 2/3 v0.3 / MARK-3 / MARK-22 / MARK-44

At a Glance

数字で見る Path D 問題

現状 Path D 活性化率

baseline-2026-04 で発覚

統合フロー

v0.3 役割選択廃止、全員非管理者扱い

Path D 専用イベント

welcome_shown 追加 / role_selected 廃止

24h

tp-5b リマインダー

v0.2 で 48h → 24h 前倒し（維持）

なぜ Path D が最重要か

「ユーザー数無制限」USP はチームで使われて初めて意味を持つ。Path D 活性化 0% を放置すると Layer 3（50_monthly_active_team）に永遠に到達しない。オーナーが「nanco はチームに浸透しない」と判断して解約するリスクもある。

Root Cause

なぜ活性化 0% か（仮説）

Path A/B/C との根本的な違い

観点	Path A / B / C	Path D（招待メンバー）
サインアップの動機	自分で必要性を感じて登録	オーナーに「これ使って」と言われた
アプリへの期待	「在庫管理を楽にしたい」	「義務感」or「とりあえず入っとく」
初回ログイン時の状態	空っぽ → 何かしないと	既にアイテムある → 何していいか分からない
アクション	自分のニーズで動く	オーナー指示待ち

既存オンボがそのまま動く問題

エンプティステートが表示されない: 既存環境に入るためアイテム数 > 0
ウェルカム「最初のアイテムを追加する」CTA が違和感: 既存ユーザーがいる中で？
質問駆動「業種は？」が違和感: オーナーが既に決めている
スタートガイド 4 項目に「メンバー招待」がある違和感: 招待メンバーは管理者ではないので不要（v0.3 で Path D は 3 項目に簡素化）

Design Principles

基本設計 / Owner オンボとの違い

設計 5 原則（v0.3 単一フロー版）

「招待された」自覚を即座に提示（誰に / どのワークスペースに / 何をしてほしいか）
~~「自分の役割」を最初に決めさせる~~ → 役割選択 UI は廃止（v0.3）。ワークスペースを作った人 = オーナー = 管理者、招待メンバーは全員非管理者として同じ扱い。権限の出し分けは「管理者かどうか」で行う
既存環境を尊重（エンプティ表示しない、サンプル生成しない）
「最初のアクション」を全員共通で提示（{オーナー名} 登録のアイテムを 1 つ見る → +1 / -1 を試す。メンバー招待などの管理者機能は表示しない）
オーナーとの繋がりを意識（「○○さんと一緒に在庫管理」という文脈）

Owner オンボとの比較（v0.3 単一フロー版）

要素	Owner オンボ	Path D オンボ
ウェルカム文	「nanco へようこそ」	「{招待者名} さんに招待されました」
エンプティステート	表示（アイテム 0 個時）	非表示（既存環境に入る）
質問駆動 Q1	業種は？	~~役割は？~~ → 廃止（v0.3）
質問駆動 Q2	アイテム情報の取捨選択	（なし）
サンプル生成	アイテム 1 個 + フォルダ 1 個	なし（既存環境を変えない）
最初のアクション	アイテム追加	「{オーナー名} 登録のアイテムを開く → +1 / -1 を試す」（全員共通、単一フロー）
スタートガイド	4 項目（アイテム追加 / 入出庫 / 招待 / バーコード）	3 項目（全員共通）（在庫を見る / 入出庫 / バーコード）
メール tp-1	「最初のアイテムを追加する」	tp-5-path-d-welcome（招待された旨 + 最初のアクション CTA）

5-Step Flow

Path D 専用フロー（5 ステップ）

招待メール

オーナーが「メンバーを招待」を実行。 SendGrid（Knock 経由）でメール + 必要なら SMS が自動配信される。

サインアップ画面

招待リンク経由で到達。オーナー名 / ワークスペース名 / 業種 / 既存メンバー数を最初に提示。

ウェルカム（役割選択なし、 v0.3）

初回ログイン直後。「{オーナー名} さんと一緒に」 + 最初のアクション CTA を 1 つだけ提示。役割選択 UI は廃止（v0.3）。

最初のタスク（全員共通）

ダッシュボードに共通の「{オーナー名} 登録のアイテムを開く → +1 / -1 を試す」カードが表示。管理者機能は表示しない。

Path D スタートガイド（全員共通）

3 項目共通（在庫一覧 / 入出庫 / バーコード）。役割別の出し分けは廃止（v0.3）。

ステップ 2: サインアップ画面（招待リンク経由）

┌──────────────────────────────┐ │ │ │ {オーナー名} さんに招待されました │ │ │ │ ワークスペース: {ワークスペース名} │ │ 業種: {業種名} │ │ 既存メンバー: {N} 人 │ │ │ │ [メールアドレスで参加] │ │ [Google で参加] │ │ [SMS で参加] │ │ │ └──────────────────────────────┘

ステップ 3: ウェルカム（役割選択なし、 v0.3 単一フロー版）

┌────────────────────────────────────┐ │ │ │ ようこそ、{ユーザー名} さん │ │ │ │ {オーナー名} さんと一緒に、 {ワークスペース│ │ 名} の在庫管理を始めましょう。 │ │ │ │ このチームでは {N} 個のアイテムを管理して │ │ います（業種: {業種名}）。 │ │ │ │ まずは「{オーナー名} さんが登録した在庫」 │ │ を 1 つ見てみましょう。 │ │ │ │ ┌──────────────────────┐ │ │ │ [最初のアイテムを開く →] │ │ │ └──────────────────────┘ │ │ │ │ [あとで（一覧から自分で開く）] │ │ │ └────────────────────────────────────┘

v0.3 改訂: 役割選択 3 ボタン UI を撤回。「最初のアクション」を全員共通で提示する単一フロー版。権限の出し分けはサーバー側で「管理者かどうか」のみで判定。

Single Flow（v0.3）

最初のタスク（単一フロー、 v0.3）

v0.3 改訂: 役割選択廃止 → 単一フロー化

姉崎判断（2026-05-22）: 「ワークスペースを最初に作った人 = オーナー = 管理者、招待されたメンバーは全員非管理者として同じ扱い」。 v0.2 までの 3 役割設計（viewer / editor / co_owner）は撤回。招待メンバー全員に同じ「最初のタスク」と「3 項目チェックリスト」を提示する。

✏

単一フロー（全員共通）

{オーナー名} 登録のアイテムを開く → +1 / -1 を試す

招待メンバー全員に共通で提示。「在庫を見る」と「動かす」を 1 つの動線に統合 = フロー内の意思決定点を減らす（離脱対策）。権限上「動かせない」場合はサーバー側でボタンを非活性化。

「{オーナー名} さんが登録したアイテムの 1 つで、まず開いてみて、 +1 / -1 ボタンを試してみましょう」
[最初のアイテムを開く]

期待 KPI（暫定、観察モードで補正）: アイテム詳細画面表示 50-60% / 数量変更（活性化）15-25%

活性化条件（v0.3）: 30_update_count 1 回以上で統一（Layer 1）。役割別分岐は廃止

Path D 専用スタートガイド（3 項目、全員共通、 v0.3）

チェック 1	チェック 2	チェック 3
在庫一覧を見る `30_view_item_list`	入出庫を記録 `30_update_count`	バーコードを試す `30_barcode_scanned`

v0.3 改訂: 役割別の出し分けテーブル（viewer 1 項目 / editor + co_owner 3 項目）を撤回。全員に 3 項目を提示する。権限上「動かせない」ユーザーでもチェックリスト上は表示し、サーバー側で非活性化（自分は今何ができないかを明示する透明性設計）。メンバー招待 / アラート設定は管理者権限が必要なため Path D には非表示。

参考: v0.2 までの役割別想定値（viewer 50% / editor 30% / co_owner 20%）は観察モード補正用のメモとして §10 改訂履歴に残す（実装には用いない）。

tp-5 Series

メール / 通知連動（tp-5 系 3 種）

文面の SoT はオンボメール v2 の tp-5 セクション参照。ここでは Path D 固有の設計思想と差分を記述。

tp-5tp-5-path-d-welcome — サインアップ直後（即時）

トリガー: 10_register かつ signup_path = path_d_invited / チャネル: メール + In-App

件名: {招待者名} さんに招待されました。 nanco へようこそ

ワークスペース情報 + 最初のアクション CTA（在庫を 1 つ開く）を提示（v0.3 改訂、役割選択 3 CTA を単一 CTA に統合）。 Path D 専用フローの起点。

開封率 50% アクション着手率 30%

tp-5b tp-5b-path-d-action-reminder — 最初のアクション未着手時（v0.3 改題） v0.3 単一フロー

タイミング: 24h（v0.2 で 48h → 24h 前倒し、維持）、かつアプリ未操作（最初のアイテムを一度も開いていない）

件名（v0.3 改訂）

{ユーザー名} さん、 {オーナー名} さんのチームの在庫を覗いてみませんか?

本文（v0.3 改訂）

{オーナー名} さんに招待されたワークスペースで、まだ在庫を見てもらえていません。 3 秒で OK です: [{オーナー名} 登録のアイテムを 1 つ開く →] ────────────────── 開くだけでも構いません。数字を動かす必要はありません。 nanco 代表姉崎祐樹

v0.3 変更内容（役割選択廃止に伴う改訂）

v0.2 までは「役割選択 3 択リマインダー」だったが、役割選択 UI そのものを廃止（論点 2 / CEO 裁定）したため、件名・本文を 「最初のアクション（アイテムを開く）リマインダー」 に書き換え。

24h 前倒し（v0.2）は維持。発火条件「アプリ未操作（最初のアイテムを一度も開いていない）」も維持。

tp-5c tp-5c-path-d-no-action-7d — 7 日経過で活性化なし

タイミング: 7 日経過、役割は選んだが Layer 1 未達（30_view_item_list または 30_update_count 未発火）

件名

{ワークスペース名} の在庫を、一度だけ見てみませんか?

本文

{オーナー名} さんに招待されてから 7 日経ちました。 nanco で {ワークスペース名} の在庫がどうなっているか、一度だけ見てみませんか? [ワークスペースを開く] 「忙しくて時間がない」という方も、 1 分だけ。アプリを開いて画面を眺めるだけでも構いません。 ────────────────── nanco 代表姉崎祐樹

Measurement

計測 / Path D 独立 KPI

フェーズ別目標

現状 baseline

2026-04 baseline で発覚

v0.1 リリース後 1 ヶ月

15%

2026-07 / N≥10 充足時のみ判定

v2.0 リリース後 1 ヶ月

25%

2026-08 / N≥15 充足時のみ判定

Phase 2 長期

40%

2026-12 / 月 50 件サインアップ達成後評価

CEO 裁定 (2026-05-22) で確定。リリース版別タイミング + Traction 指摘の母数条件 N≥10/15 を併記（少サンプル時の偽改善判定を回避）。 N<閾値は「計測不可・継続観察」。 Path D は PLG 健全性指標（Layer 3 観測）、 Owner SEM 獲得が月 30 件超えるまで Traction 一次 KPI ではない。

期待活性化率（単一フロー、 v0.3）

マイルストーン	期待 `30_path_d_first_action` 発火率	期待 `30_path_d_activation`（= `30_update_count` 1 回以上）
v0.1（応急処置）	30-40%	15%（§5.3 目標と整合）
v2.0（ガイデッドセットアップ + Knock 統合）	50-60%	25%
Phase 2	60-70%	40%

v0.3 改訂: 役割選択廃止に伴い、 viewer 50% / editor 30% / co_owner 20% の役割別期待値テーブルを撤回。単一フローの暫定期待値に差し替え。観察モード（A/B doc v0.4）で補正予定。
母数条件（CEO 裁定 + Traction 指摘）: 上記の判定は N≥10（v0.1 後）/ N≥15（v2.0 後）を充足する場合のみ。 N<閾値は「計測不可・継続観察」。

Path D 専用イベント一覧（v0.3、単一フロー版）

イベント名	発火タイミング	プロパティ
`30_path_d_invite_link_clicked`	招待リンクをクリック	`inviter_id`, `workspace_id`
`30_path_d_signup_completed`	Path D 経由でサインアップ完了	`signup_path = path_d_invited`
`30_path_d_welcome_shown` ★ v0.3 追加	Path D 専用ウェルカム表示	`inviter_id`, `workspace_id`
`30_path_d_first_action`	最初のタスク（在庫を見る or 動かす）完了	`action_type` ∈ {view_list, update_count, barcode_scan} v0.3 で `role` プロパティ削除
`30_path_d_activation`	Layer 1 到達 = `30_update_count` 1 回以上で統一 v0.3 で役割別分岐を撤回	—
~~`30_path_d_role_selected`~~ ★ v0.3 廃止	役割選択 UI が無くなったため、発火元が消滅

PostHog HogQL: Path D 活性化率クエリ（v0.3 単一フロー版）

v0.3 改訂: 役割選択廃止に伴い path_d_role CTE と role 別 COUNT を削除。単純な活性化率（30_update_count 1 回以上）に簡素化。母数判定列 sample_status（N≥10 / N≥15 / 計測不可）を追加。

WITH path_d_cohort AS ( SELECT person_id, timestamp AS register_at, properties.inviter_id AS inviter_id FROM events WHERE event = '10_register' AND properties.signup_path = 'path_d_invited' AND timestamp >= '2026-06-15' AND timestamp < '2026-07-15' ), path_d_activated AS ( SELECT DISTINCT person_id FROM events WHERE event = '30_update_count' AND timestamp >= '2026-06-15' ) SELECT COUNT(c.person_id) AS path_d_cohort_size, COUNT(a.person_id) AS activated, ROUND(COUNT(a.person_id) * 100.0 / NULLIF(COUNT(c.person_id), 0), 2) AS activation_rate, -- 母数条件の判定（CEO 裁定 2026-05-22 / Traction 指摘） CASE WHEN COUNT(c.person_id) >= 15 THEN 'N>=15 (v2.0 後の有意判定可)' WHEN COUNT(c.person_id) >= 10 THEN 'N>=10 (v0.1 後の有意判定可)' ELSE '計測不可・継続観察（N<10）' END AS sample_status FROM path_d_cohort c LEFT JOIN path_d_activated a ON c.person_id = a.person_id;

Implementation

実装仕様

実装範囲

範囲	対象
nanco-flutter	Path D 専用サインアップ画面 / ウェルカム（役割選択なし、 v0.3）/ Path D スタートガイド（3 項目共通）
nanco-next	Web 版 + 招待リンク経由のランディング画面
サーバー側	`signup_path` プロパティの記録、「管理者 / 非管理者」の 2 階層権限（v0.3、詳細役割は廃止）、 Knock Workflow tp-5 系の起動
Knock	tp-5 / tp-5b（v0.3 改題: action-reminder）/ tp-5c Workflow 実装

招待リンク URL パラメータ

https://nanco.io/invite/{token}?inviter={inviter_id}&workspace={workspace_id}

権限のサーバー側保存（v0.3 単一フロー版）

テーブル	カラム
`workspace_members`	`user_id`, `workspace_id`, `role` ∈ {owner, member} v0.3 改訂: viewer / editor / co_owner の細分化を撤回。「管理者か非管理者か」の 2 階層に簡素化（姉崎判断 2026-05-22）。 `path_d_role_selected_at` も廃止

役割	権限
owner（管理者）	すべての操作可（メンバー招待 / アラート設定 / ワークスペース設定等）
member（非管理者）	在庫の閲覧 / 数量変更 / バーコードスキャン可。メンバー招待 / 管理機能は非表示

v0.3 改訂: 「出す出さないは管理者かどうかでいい」という姉崎判断（論点 2）に従い、 viewer / editor / co_owner の細かな権限分岐を撤回。 UI 上は member 全員に同じ画面を出し、管理者機能のみサーバー側で非表示・非活性化。

v2.0 スコープに昇格: オーナーへの活性化通知（PLG 指摘 #4）

招待メンバーが初アクションを取った瞬間にオーナーへ通知する Knock ワークフローを v2.0 スコープとして追加する。通知例: 「{招待メンバー名} さんが {ワークスペース名} の在庫を見ました」。 Layer 3 KPI（50_monthly_active_team）の観察 + USP「ユーザー数無制限」の実質証明に直結。

Connected Tasks

連動 task

Task	種別	内容
MARK-1	親	PRD v2.3 オンボ刷新（セクション 4.5.2 Path D 別フロー反映）
MARK-3	兄	オンボメール v2 / tp-5 〜 tp-5c の文面 SoT（tp-5b は v0.3 で action-reminder に改題）
MARK-22	兄	Layer 2/3 イベント定義 v0.3 / Path D 計測連動（`role` 分岐撤回反映済）
MARK-44	兄	観察モード v0.4 / Path D 活性化率を月次 KPI に組み込み（N≥10/15 条件付き）
MARK-17 / 18	弟	Knock セットアップ + 実装（tp-5 系の実装基盤）
NANCO-??	起票推奨	Path D 専用サインアップ画面 / 単一フローウェルカム（v0.3、役割選択なし）/ Path D スタートガイド 3 項目共通 / Path D 専用イベント 5 件

残課題（v0.3 更新）

1. 招待リンクの現状実装確認（Path D 専用フローへの切り替え工数）。
2. ~~権限制御の実装範囲（viewer / editor / co_owner の細かな権限定義）~~ → v0.3 で解消（owner / member の 2 階層に簡素化、姉崎判断 2026-05-22）。
3. SMS 補完（SMS auth リリース後、8 月以降）。
4. ~~役割変更フロー~~ → v0.3 で不要（役割選択 UI 自体を廃止したため）。
5. オーナーへの活性化通知（v2.0 スコープに昇格済み）。

v0.3 改訂サマリ（2026-05-22）

論点 2（姉崎判断）: 役割選択（viewer / editor / co_owner）を廃止 → 招待メンバーは全員非管理者として同じ単一フローに統合
論点 4（CEO 裁定）: §5.3 目標値を候補 B で確定（0% → 15%/25%/40%、リリース版別、母数 N≥10/15 併記）
影響章: §2.1 設計原則 / §2.2 比較表 / §3.3 ウェルカム / §3.4 最初のタスク / §3.5.1 チェックリスト / §5.1 イベント / §5.2 HogQL / §5.3 目標 KPI / §5.4 期待値 / §6 実装範囲 + 権限定義
関連 SoT 同期: PRD v2.3 §2 / A/B v0.4 §3.2 §3.4.2 / Layer 2/3 v0.3 §8 / decision-log/2026-05-22-path-d-kpi-consolidation.md / pattern-library/win-patterns.md P-009