EXTENSIBILITY & SCHEDULE

拡張設計とスケジュール

今回はアカウントも保存機能も入れません。ただし、将来「生徒・講師アカウント」「個別データの保存」「サブスク決済」を足すときに、作り直しにならない設計にしておきます。

ROADMAP

PoCからSaaSまでの4段階

DESIGN FOR GROWTH

今回入れる「差し込み口」

機能は入れなくても、あとから足すための受け皿を最初から用意します。ここを怠ると、将来ほぼ作り直しになる部分です。

今回実装

ブラウザ内の練習セッション（メモリ上）
解析API中継（ステートレス）
WAV書き出し（ローカル保存）
拡張設計書（この画面のER図・境界定義）

差し込み口だけ用意

認証の入口（今は常に「ゲスト」）
保存先の抽象化（今はメモリ実装のみ）
全データに所有者ID（空でOK）を持たせる
機能フラグ（accounts / persist / billing）
APIのバージョン管理（/v1）

将来（今回は作らない）

ログイン・ユーザー管理
DB・ファイルストレージ
講師コメント・教室管理
サブスク決済・利用制限
// 今回：常に「ゲスト」。将来ここに認証を差し込むだけで全体が対応する
export async function getCurrentUser(): Promise<User | null> { return null; }

// 保存先の抽象化：今回はメモリ実装のみ。将来はDB実装に差し替える
interface SessionRepository {
  save(s: PracticeSession): Promise<void>;
  listByOwner(ownerId: string): Promise<PracticeSession[]>;
}
export const repo: SessionRepository = features.persist
  ? new PostgresSessionRepository()
  : new InMemorySessionRepository();
DATA MODEL

データベース設計（ER）：空のユーザーから始める

今回は保存しませんが、テーブル設計は最初に確定します。User は空の器として置き、すべてのデータがowner_id（未設定可）でユーザーにつながる形にします。

users 空の器

  • id uuid PK
  • role student | teacher
  • display_name text?
  • created_at timestamp

materials 今回はメモリ

  • id uuid PK
  • owner_id FK users?
  • title text
  • duration_sec float
  • source_kind audio | video

speakers 今回はメモリ

  • id uuid PK
  • material_id FK
  • label SPEAKER_00…
  • display_name text?
  • color text

segments 今回はメモリ

  • id uuid PK
  • material_id FK
  • speaker_id FK
  • start_sec / end_sec float
  • text text

practice_sessions 将来

  • id uuid PK
  • material_id FK
  • owner_id FK users
  • muted_speaker_ids uuid[]

recordings 将来

  • id uuid PK
  • session_id FK
  • latency_ms int
  • offset_sec float
  • file_ref storage key

comments 将来

  • id uuid PK
  • recording_id FK
  • author_id FK users
  • at_sec float
  • body text

subscriptions 将来

  • id uuid PK
  • user_id FK
  • plan text
  • status text
  • renews_at timestamp

枠の色：オレンジ＝今回のデータ構造（保存はメモリ） ／ 青＝空の器として先に用意 ／ 点線＝将来追加

SCOPE PROPOSAL

予算内で確実に収めるための機能の整理（ご質問1への回答）

ご提示の機能はすべてスコープに収まる想定です。そのうえで、優先度の考え方と、追加をおすすめしたい小さな機能をご提案します。

機能区分コメント
動画／音声のアップロード必須動画は音声だけを取り出して解析します。
AI話者分離（最大4人）とタイムライン必須PoCの結果で使用エンジンを決定。
自動台本化必須一体型APIなら話者分離と同時に取得でき、追加コストが小さい。
ミュート／ソロ必須区間ミュート方式（重なり・BGMの制約は「仕組み」ページ参照）。
台本の同期ハイライト必須クリックで再生位置へジャンプも実装。
低遅延録音・音ズレ補正必須最も工数と検証が要る部分。Chrome／Safariの実機確認を含む。
プレビュー・WAV書き出し必須WAVで保存。MP3は後回しでも支障なし。
話者名・台詞の簡易手直し追加をおすすめ（小）AIの取り違えや誤字は必ず出るため、講師が直せる最低限の編集があると実運用が安定します。
映像プレビュー（動画も表示）ご相談アフレコは映像を見ながら行うことが多いため、映像の同期表示をご希望かご確認したい点です。
MP3書き出し／スマホ対応後回し将来フェーズで対応。
声そのものの分離（BGM・重なりの除去）スコープ外別技術。PoCの結果次第で、必要性を判断します。
ログイン・保存・決済スコープ外ご要望どおり今回は実装せず、設計のみ先行。
SCHEDULE

納期（10/30）から逆算したスケジュール目安

PoCの結果でGo/No-Goを判断できるよう、前半にPoCを置きます。ご契約日により前後します。

  • 9/29 – 10/6

    ステップ1：PoC

    サンプル受領、複数エンジンの比較、レポート作成。

  • 10/7 – 10/8

    報告・Go/No-Go

    結果のご説明と、本開発への進行判断・設計確定。

  • 10/9 – 10/24

    ステップ2：本開発

    解析連携・タイムライン・ミュート・台本同期・録音・書き出し。途中で動くものを都度ご確認いただきます。

  • 10/25 – 10/28

    ブラウザ検証・受入

    Chrome／Safariでの動作確認、音ズレの実機調整。

  • 10/29 – 10/30

    修正・引き渡し

    ソース一式・設計書・操作手順書をお渡しします。

台本を手に立つ俳優
まずは「動くもの」を見ながら、一緒に磨いていきます

実際に触って、イメージを確かめてください。

スタジオ画面は、本開発で作るアプリの完成イメージそのものです。

スタジオを開く