仕組みと技術構成｜AKAZAWA AFURECO STUDIO

DATA FLOW

データの流れ：重い処理だけを外に出す

ブラウザで完結できる部分はブラウザで、AI解析だけを外部APIに任せます。サーバーは「解析の中継役」に徹し、音声も結果も保存しません。

ブラウザ
アップロード動画／音声を画面に投入。ファイルは端末内に保持

ブラウザ
音声を抽出動画から音声だけを取り出し、解析用に軽量化

薄いサーバー
AI解析話者分離＋文字起こしを外部APIで実行。結果のみ返却

ブラウザ
4トラック＋台本タイムスタンプを受け取り、タイムラインと台本を生成

ブラウザ
ミュート再生・録音Web Audio APIで再生制御と低遅延録音

ブラウザ
重ねて書き出し他キャラ＋自分の声をWAVにしてローカル保存

サーバー側の保存はゼロ。アップロードした音声・解析結果・録音は、ブラウザのメモリ上にだけ存在します（ページを閉じると消えます）。解析APIへ送る音声も、処理後に事業者側で保持されない設定（学習利用オフ・保持期間の短縮）を選定条件にします。

HOW MUTE WORKS

話者分離が返すのは「誰が、何秒から何秒まで話したか」という時間区間です。声そのものを切り分けた音声ではありません。そのため、今回のMVPの「ミュート」はその話者の発言区間を消音する方式になります。下の図で違いを確認してください。

話者Aをミュートする

話者A

話者B

BGM・効果音（同じ音声に混ざっている）

聞こえる音（結果）

起こりうること①

Aの発言中にBが被さっている区間は、Aを消すとBも一緒に消えます。スタジオ画面でも、重なり区間を赤い斜線と警告で明示します。

起こりうること②

1本に合体した音声にBGMが入っていると、消音区間ではBGMも消えます。BGMを別ファイルで受け取れる教材づくりが理想です。

対策

ステップ1で実際の教材動画を使い、重なりの頻度・BGMの有無・声質の近さを測定。区間ミュートで教室運用に十分かを判断します。

TECH STACK

採用案と、その理由です。AI解析エンジンだけは、PoCの結果を見て最終決定します。

領域	採用案	理由・メモ
フロント	TypeScript + React（Vite） Web Audio API / AudioWorklet / Canvas	録音・再生・波形描画は端末側で完結させ、遅延を最小化。型付きで、将来のアカウント画面追加もしやすい。
音声の抽出	ブラウザ内 ffmpeg.wasm 大容量はサーバー側ffmpegに切替可	動画から音声だけを取り出して軽量化。サーバーへ送る量とAPI費用を抑える。
AI解析	外部API（話者分離＋文字起こし一体型）を第一候補自前の pyannote.audio ＋ Whisper は第二候補	自前運用はGPUサーバーの費用・保守が重く、MVPの制約（保存なし・単一画面）と相性が悪い。PoCで両方式を同じサンプルで比較する。
サーバー	薄いAPI層（Cloudflare Workers / Node） DBなし・ステートレス	APIキーの秘匿と解析の中継だけを担当。将来は同じ層に認証とDB接続を足す。
将来のDB・認証	PostgreSQL ＋認証基盤ユーザー／セッション／録音メタの器を設計だけ先行	「空のユーザーエンティティ」を置き、リポジトリ層で保存先を差し替え可能にしておく（拡張設計ページ参照）。
配信・品質	静的ホスティング（CDN）＋ E2Eテスト Chrome / Safari 最新版の実機確認	共通URLで誰でもアクセス。ブラウザ差（後述）は自動テストと実機で潰す。

LOW LATENCY RECORDING

録音した声のズレは、次の3つの遅れの合計で決まります。スタジオ画面の「音ズレ補正」は、これを実測して差し引く仕組みです。

出力遅延	音を出す指示から、実際にスピーカー／ヘッドホンが鳴るまで（Bluetoothは特に大きい）
入力遅延	声を出してから、ブラウザがマイクの音を受け取るまで
処理遅延	ブラウザ内の音声処理のバッファ。AudioWorkletで最小化

BROWSER SUPPORT

ブラウザ	対応	確認・対処するポイント
Chrome（最新版）	対応	AudioWorklet・低遅延録音とも標準。開発の基準環境。
Safari（最新版・macOS）	対応	音声コンテキストの開始にユーザー操作が必須／録音フォーマットの差／マイク許可の挙動を実機で確認。
Edge（最新版）	動作想定	Chromiumベースのため同等。回帰テストに含める。
スマホ・タブレット	今回は対象外	今回はPC版のみ。画面はレスポンシブにしておき、将来拡張に備える。