mustash ・ 設計書(社内)

航海モード 設計書

mustash 事業進行管理 × ゲーミフィケーション × AIエージェント


0. TL;DR


1. 目的と北極星

mustashの基本思想=テナントがAIに聞きながら自走し、齋藤(KF)は手を動かさないfeedback-mustash-ai-selfserve)。航海モードは、その思想を製品化した装置。狙いは、事業者が「事業が育っている」と感じながら、迷わず前進できること。最終形は、AIが事業者ごとに目標と道筋を設計し、必要作業を提案・実行して、運営が自動でカスタマイズされていく状態。


2. 用語と世界観

用語 意味
その事業者専用の事業構造=DB(Vision/Phase等の実データ)。「船を持つ」=データがある状態
進水式 オンボーディング。AIが質問→船を生成して授ける儀式
ブリッジ(船橋) ダッシュボードのトップ=常設モニター(地図+状況)
Milestone(到達地点)。一つ出るたび次が現れる
航路 進んできた道=成長履歴
計器 ブリッジ上のパネル(売上メーター・顧客レーダー等)。進捗/プランでアンロック
北極星 Vision(最終的な理想)。常にうっすら見える

3. UX原則

3大原則(絶対に守る)

  1. 段階的開示(Progressive Disclosure):全体マップを見せない。次の島だけくっきり、Visionはうっすら。UIは3つ(現在地/次のゴール/今日やること)に絞り、6階層は裏に隠す。
  2. 作業 ≠ 成果:Task完了(例:Instagram3投稿)と、事業成果=Milestone(例:Instagram経由で初予約)を混同しない。進捗と成果は別軸。
  3. AIを誇張しない:因果が証明できない「AIが売上○円を生んだ」は禁止。計測可能なもの限定(AI作成ページ経由の予約・AI配信経由の予約・推定削減時間 等。"推定"は明記)。

補助原則


4. 全体アーキテクチャ(既存mustashへの乗せ方)

既存は Next.js16 + Supabase + Stripe(Express) + Tailwind、マルチテナント([slug] = sites)。航海モードは書き直しでなく自然な拡張として乗せる:

既存 航海モードでの役割
sites(テナント) 各船の所属先。site_id で全データを紐付け
ai-chat-logs AI Activity Log に発展(実行内容・差分・状態を追加)
feature-toggles / custom-features AI権限・プラン制御のゲーティングに流用
shop/orders/booking/line 成果の自動判定の"データ源"(初予約・初売上・LINE登録数 等)
プラン(FREE/Pro/Starter/Business) 航海モードのAI能力の上限を決める

新規追加は「進行管理オントロジー(Vision..Task)+AI活動ログ+AI権限」の3群。


5. データモデル

5.1 ER(親子)

sites (既存, テナント)
 └ voyages         … 事業者ごとの"航海"(1 site : 1〜N。通常1、複数拠点で複数)
    └ vision       … 最終理想(1 voyage : 1)
    └ phases       … 大きな成長段階(instance)
       └ stages
          └ milestones   … 到達地点=島
             └ quests     … 目的を持った挑戦(AI生成)
                └ tasks    … 具体作業(担当・権限・判定を持つ)

※ Phase/Stage/Milestone は テンプレ(業種別マスター) を持ち、進水式で voyage に インスタンス化→AIが個別カスタマイズ。テンプレ=スケール、インスタンス=個別最適の両立。

5.2 主要テーブル(列は要点のみ)

phase_templates / stage_templates / milestone_templates(業種別マスター) - id, industry(業種), order, title, description, default_completion_type

voyages - id, site_id(FK), title, status(active/paused/archived), created_at

visions - id, voyage_id(FK), statement(理想の状態), source(onboarding/edited), created_at

owner_profiles(事業者プロファイル=好き嫌い/やりたくないこと。進水式で取得し、AI提案の制約に使う。世界観の押し付け防止の要) - id, voyage_id(FK) - vibe(大事にしたい雰囲気・トーン) - likes(好きな手段/チャネル/やり方), dislikes(嫌いな手段/チャネル/やり方) - avoid(やりたくないこと=Quest/Task提案から除外) - dislike_reasons("なんで嫌いか"=価値観。JSON。例:{sns:"自分を切り売りしたくない"}) - updated_at / ※対話で随時更新(航海しながら好みは変わる)

phases(instance) - id, voyage_id(FK), template_id(FK,nullable), order, title, status(locked/active/done), started_at, done_at

stages - id, phase_id(FK), order, title, status

milestones(島) - id, stage_id(FK), title, description - completion_type(auto / self_report), auto_signal(例:shop.first_order / site.published / stripe.connected) - achieved_at(nullable)… 達成日時=成長履歴に残す - status(locked/open/achieved)

quests - id, milestone_id(FK), title, why(提案理由), status(suggested/active/done/dismissed) - generated_by(ai/human), generated_at, completion_rule(例:全必須Task完了 かつ 特定Task=公開/送信 完了)

tasks - id, quest_id(FK), title - assignee(enum: owner / ai / collab / staff / partner) - exec_level(0-4, 後述11) - completion_type(auto / self_report / ai_done / approved) - status(todo / in_progress / awaiting_approval / done / failed / undone) - estimated_minutes(標準/推定作業時間。AI貢献の時間削減集計に使用) - done_by(owner/ai/…), done_at - links: {phase_id, stage_id, milestone_id, quest_id}(横断参照用の非正規化)

ai_activity_log(AI Activity Log) - id, site_id(FK), agent_role(後述), action(実行内容), target_feature, target_ref(対象データ) - linked: {phase_id, stage_id, milestone_id, quest_id, task_id} - trigger(auto / user_requested), before_after(差分 JSON), status(success/failed/awaiting_approval) - reversible(bool), undo_ref, credits_used, created_at

ai_permissions(テナント×機能/役割ごと) - id, site_id(FK), scope(feature or agent_role), max_exec_level, auto_execute(bool), updated_by, updated_at

plan_capabilities(プラン→上限。データで持つ) - plan, capability_key(下記7参照), limit_value(int/bool/期間)


6. AIループ(12ステップ)とデータ契約

1 Vision・現状把握      → visions + 各種データ源(shop/booking/line…)を読む
2 現在Phase/Stage判定   → milestones.achieved_at と auto_signal から算出
3 次Milestone提案       → 未達 milestone を優先度づけ
4 Quest生成             → milestone に紐づく quests を AI 生成(why付き)
5 Task分解              → quest→tasks(assignee/exec_level/推定時間 付与)
6 AI実行可Task判定      → exec_level と ai_permissions を突合
7 承認不要は自動実行    → exec_level>=3 かつ 権限OK → 実行+ai_activity_log
8 承認必要は下書き/待ち → awaiting_approval で保留
9 人限定Taskを提示      → owner/staff の todo として表示
10 結果を計測           → 成果の自動判定(10)+活動ログ集計
11 Milestone達成判定    → auto_signal 発火 or self_report
12 次を再生成           → 達成に応じて次Phase/Stage/Questを更新

Quest/Task生成(4-5)は必ず owner_profiles を制約として尊重:嫌いな手段・トーン・"やりたくないこと"は提案しない/除外する。=世界観の押し付け防止。同じMilestone(例:初予約)でも、SNSが嫌いな人にはSNS導線を出さず別ルート(紹介・チラシ・既存客)を提案する。 ※ 事業は最初から全道筋を引けない。11→12で"進みながら次が決まる" = 段階的開示が演出でなく実態と一致(信頼の源)。


7. 進水式(オンボーディング)フロー

  1. 登録直後はダッシュボードを見せない(船=データが無いため)。
  2. AIが会話形式で数問(フォームでなく、答えに応じて次が変わる。短く):
  3. 業種/今どんな状態か/一番の悩み/理想(Vision)
  4. 大事にしたい雰囲気・トーン(どんな空気で事業を育てたいか)
  5. 好き嫌い(特に "何が嫌いか・なんで嫌いか・どうしたくないか") ← 押し付け防止の要
    • ※人は「やりたいこと」より「やりたくないこと・嫌いなこと」の方をハッキリ持っている。嫌いは道の"境界線"を引く
    • 「なんで嫌いか」まで聞くと"価値観"が分かる(例:SNSが嫌い→"自分を切り売りしたくない"のか"時間がない"のかで、AIの対応が真逆に変わる)。
  6. 回答→業種テンプレを選び voyage にインスタンス化→AIが個別カスタマイズ→vision/phases/最初のmilestone を生成。※このとき owner_profile(好き嫌い/やりたくないこと)を制約に反映し、嫌いな手段・トーンは道筋から外す。
  7. 【進水式演出】「あなたの航海図ができました」→最初の島だけを提示→航海開始。
  8. 以後、航海が進む(データが増える)ほど船=提案精度がアップグレードされる。

8. ブリッジ(常設モニター)+計器アンロック

画面構成イメージ(上→下)

[現在地] Phase2 公開準備 / Stage3 予約環境を整える
[次の島] 予約受付開始  ── 進捗 72%(Quest2・Task5 残)
[今日やること] あなた: … / mustash AI: … / 承認待ち: …
[AIの成果] 今週AI完了12 / 推定削減3h20m / Quest貢献2
──(以下、アンロックされた計器)──
[売上メーター] [顧客レーダー] …

9. 進捗率とAI貢献の算出


10. 達成判定(自動 vs 自己申告)

milestone.completion_type で分岐: - auto(システムが判定):ホームページ公開/Stripe接続/初予約(予約データ)/初売上(orders)/LINE登録100(line)等 → auto_signal 発火で achieved_at 記録。 - self_report(自己申告):店舗写真を撮影/お客様にヒアリング 等 → 事業者チェックで記録。 - 成長履歴の信憑性は auto を背骨に(自動判定できるものは自動で。self_reportは補助)。


11. AI実行権限・承認・監査

実行レベル(Taskごと)

Lv 内容
0 提案のみ
1 下書き作成
2 ユーザー承認後に実行
3 設定範囲内で自動実行
4 継続的に分析・改善・実行

ルール(安全側)

AIエージェントの役割(初期は"ラベル"でOK)

Business Partner / Marketing / Booking Manager / Customer Support / Content Creator / Analyst / Operations / Finance Assistant。初期は同一AI基盤にrole属性を持たせ、UIで担当領域を見せるだけでよい。独立実装は将来。


12. プラン別制御(データ構造で持つ)

plan_capabilities で以下の軸を制御(具体値は後決め・構造だけ先に): - AI相談回数 / Quest生成回数 / Task生成数 / AI実行可Task数 / 自動実行の可否 / Activity Log保存期間 / AI役割数 / 接続データ数 / 分析対象期間 / 月間AIクレジット / 同時実行数 / 承認フロー設定 / カスタムVision・Phase・Stage / チームTask割当 / 高度成果分析 / 外部連携

方向性(仮)


13. セキュリティ / 誤動作時の停止・取消・復元


14. 段階実装ロードマップ

Phase 内容 AI依存
P1 進捗管理の基礎 Vision/Phase/Stage/Milestone/Quest/Task+進捗表示+手動完了+ブリッジ最小 なし
P2 AI提案 現在地分析・Quest提案・Task生成・理由説明・下書き作成 提案
P3 AI作業ログ AI担当Task・Activity Log・推定削減時間・承認待ち管理・AI成果表示 記録
P4 AI実行 承認後実行・一部自動実行・実行権限・取消/復元・プラン制御 実行
P5 自律型パートナー 継続分析・Quest自動更新・複数AI役割・チーム協働・継続改善 自律

P1 MVP(最小スコープ)=最初に作るのはこれだけ


15. 検証方針(先行組・NELCAFE第1号・オズの魔法使い)


16. 未決事項・次アクション

この設計書は「データモデルを先に固める」ためのもの。フル実装はNELCAFEでの検証後、P1から段階的に。