minedia-www 変更点

3 行サマリ

全体像 — 何が core へ移り、何が残るか

① エンティティの変化

変化は 3 パターンに畳める。

• 移管 外部化テーブルは「core の正本」と「www の薄い参照」に分かれる（4 組）。ログ類はコピーを持たず都度取得。
• 変更 www に残る事後処理モデルは、物理 FK belongs_to :ot_archive を recording_uuid（文字列参照）へ繋ぎ直す。
• 新設 前身のない同期基盤（outbox・Webhook 冪等受信・エンジン切替フラグ）を足す。

新設テーブルは 5 つ。Project 系の中心は 01 のアンカー、即席は 02 の実体テーブルが同じ役を担い、03〜05 は core uuid を介してこの 2 つにぶら下がる。

残留モデルの繋ぎ直し — 物理 FK → recording_uuid

動画再生 URL：ot_archive.video_s3_key → 新エンジンは core GET /recordings/{id}/download-url（短命の署名 S3 URL）。旧 OpenTok 案件は ot_archive のまま（二重運用）。

① 読み取り経路の変化 — 統一インターフェース

二重運用期（OpenTok 既存＋新基盤）の分岐は Slot#interview_room が吸収する（B-DEC-01）。呼び出し側はエンジンを知らない。

Slot#interview_room
  ├─ engine == opentok → OpentokRoom.new(room)        # 既存ローカル Room をラップ・無変更
  └─ engine == livekit → LivekitRoom.new(interview_room_ref, core_api_client)

共通インターフェースは 6 メソッド：#chat_messages(usage:) / #entry_histories / #recordings / #playback_events / #access_url(role:) / #movie_duration_sec

各アダプタの実装イメージ

OpentokRoom — 既存のローカル Room / OtArchive をそのまま読む薄いラッパ。挙動は無変更。

class OpentokRoom
  def initialize(room) = @room = room

  def chat_messages(usage:) = @room.room_chat_messages.where(usage:)
  def entry_histories       = @room.room_entry_histories
  def recordings            = @room.ot_archives
  def playback_events       = @room.playback_events
  def access_url(role:)     = @room.room_access_token(role)
  def movie_duration_sec    = @room.ot_archives.sum(:file_duration_sec)  # DB集計
end

LivekitRoom — 一覧・集計は recording_refs で即返し、詳細はその場で core API を叩く。API 障害時はデグレード値を返す。

class LivekitRoom
  def initialize(ref, client)
    @ref, @client = ref, client
  end

  # 一覧・集計：API を叩かずローカル行キャッシュで即返し
  def movie_duration_sec = @ref.recording_refs.sum(:duration_sec)

  # 詳細：core API on demand。障害時は「一時的に取得できません」＋uuid
  def chat_messages(usage:)
    @client.get("/rooms/#{@ref.core_room_uuid}/chat-messages", channel: usage)
  rescue Core::ApiError
    Core::Degraded.new(@ref.core_room_uuid)
  end

  def entry_histories   = @client.get("/rooms/#{@ref.core_room_uuid}/entry-histories")
  def recordings        = @client.get("/rooms/#{@ref.core_room_uuid}/recordings")
  def playback_events   = @client.get("/rooms/#{@ref.core_room_uuid}/room-events", type: "handout")
  def access_url(role:) = Core::RoomAccessToken.sign(room: @ref.core_room_uuid, role:) # 自己署名（core への往復なし）
end

主な読み取り書き換え

② 新基盤との結合点

結合は www → core の REST（①命令 ②取次ぎ ③参照）と core → www の Webhook（④通知）の 2 方向だけ。core が www を同期呼び出しすることはなく、core 側に www 専用の公開 API も追加しない。

権威の分界（B-DEC-05）— 衝突時の勝者を先に決めておく

「GET が真実の源泉」は事実系にのみ適用され、ライフサイクル系は逆向き。この非対称の明文化が勝者規則の本体。LWW（タイムスタンプ比較）は採らない。

www → core（命令・取次ぎ・参照）

core → www（Webhook 5 種）

Session の終了に push はない。終了検知は GET /sessions（status は時刻からの導出値）。

整合性担保の三層防御

FK を持たない uuid 境界では、削除・同期の整合を DB が保証しない。以下の三層で担保する（🧩 タスクとして実装フローに割り付け済み）。

即席調査の入室 To-Be — ロール偽造の封じ込め

即席実査は extemporary_sessions（① §02）で実体化するが、入室トークンの持ち方だけは As-Is の穴を引き継がないよう作り替える。即席は User / Answer ドメインを持たず、パネリスト・モデレーター・見学者・運用が同じ枠へ入るため、ロールを詐称されやすい。

To-Be — ロール別トークン ＋ サーバー確定署名

単一トークン＋ロールクエリをやめ、ロールごとに別トークンを発行する。?interview_role= は廃止。入室時、www（tenant 0 = 発行者）がトークンからロールを引き当て、ロールを participant JWT のクレームに封入して署名する（Model B）。基盤コアは署名を検証するだけで、ロールの申告は下流に一切流れない。参加者はロールを選べず、署名後は改ざんできない。

実装は extemporary_sessions に紐づく www 側のロール別トークン表で持つ。ロールの権威は www に閉じ、core は関与しない（core は JWT の role クレームを検証するだけ）。

索引：unique [extemporary_session_id, role] / unique [access_token]。枠作成時（webrtc_engine=livekit）に 4 ロール分を一括生成。単一 access_token は本表に置き換える——「トークンが当たれば申告ロールを信じる」構造を、トークン自体がロールを担う構造へ。

入室フロー（認証ページ「即席調査」タブに対応）

1. 配布 URL（ロール別トークン）クリック → www が access_token から (session, role) を確定。revoked_at / 時間窓を検証。?interview_role= は読まない。
2. www が core Room uuid を確定し、participant JWT {tenant:0, room, participant, role, exp, jti} を tenant 0 の秘密鍵で署名（基盤への往復なし）。
3. フラグメント付きリダイレクト → room SPA が JWT を回収。
4. core が署名・クレーム・越境・失効を検証 → RoomPolicy から grants 導出 → LiveKit トークン発行。
5. 入室待機画面で表示名のみ入力（即席は identity 不要の形式）。

移行とスコープ

• エンジン選択は extemporary_folders.webrtc_engine（フォルダ単位・default opentok）。opentok フォルダの即席枠は現行 legacy 経路（単一トークン＋ロールクエリ）のまま——手を入れず OpenTok 撤去まで併存する。livekit フォルダの新規枠から本方式に乗る。既存配布 URL は壊れない。
• 本 To-Be のスコープはロール偽造（権限昇格）の防止のみ。name（入室待機画面で入力する表示名）と uuid（接続識別用の派生 ID）は身元を主張せず、即席は identity 不要の形式のため、identity なりすましの残余リスクは実質存在しない。
• 入室時、www はトークン照合（現行の入室ページ認可の継承）を経てから署名する。ロール別トークン化はその上に「申告ロールを信じない」構造を足すもの——トークンが当たっても、名乗ったロールではなくトークンに紐づくロールで署名される。

③ 追加で必要な開発 — 実装フロー

主軸は A主軸ハイブリッド：既存を壊さない継ぎ目（統一 IF）を先に完結させ、新エンジン部は契約モックで先行 TDD し、core を待つ。core 依存度で 4 フェーズに割れる。

依存関係

Phase 0 (seam) ──┐
                 ├─► Phase 2 (contract-first, mock) ──► Phase 3 (core 結合) ★core稼働待ち
Phase 1 (schema)─┘

• Phase 0 / 1 は core 非依存で先行完了できる。
• Phase 2 は core の OpenAPI 公開が着手条件＝稼働サービスは不要だが契約公開は必要（minedia-www は pure consumer）。
• Phase 3 のみ core 稼働がブロッカー。

付録 — 確定 14 論点（B-DEC-01〜14）

現行画面の実査（Operator 実ログイン・Employee 管理画面・ダッシュボード / 即席フォルダ）で確定した設計分岐の一覧。根拠と詳細は本文の各セクションに移したため、ここは一行の決定記録のみ。