minedia-www 変更点

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

設計方針案 — 5つの論点

「Operator として実ログインし、Room/録画をどう読んでいるか」を実査したうえで、5つの設計分岐の方針案をまとめた。これらは互いに整合し、「外部化 Slot ごとの薄いローカル参照モデル」へ一意に収束する想定。

アンカーモデル — 薄いローカル参照モデル InterviewRoomRef

5つの方針案は 外部化 Slot ごとの薄いローカル参照モデルに収束する。これが「統一IF のアダプタ先」「一覧用キャッシュ」「詳細 API 用 uuid 保持先」「Webhook 更新先」を兼ねる。新テーブル interview_room_refs（仮称・別名 LivekitRoom）を追加する。

索引：unique [slot_id] / unique [extemporary_slot_id] / unique [core_session_uuid]。OpenTok legacy 案件はこの行を持たず slot.room で従来どおり。新エンジン案件のみ1行持つ。エンジン選択は projects.webrtc_engine（opentok/livekit・default opentok）で持ち、Slot が継承する。

なぜ「薄い参照モデル」か

• Slot に列直付けだけでは、詳細 API キャッシュ・録画 uuid 配列・同期鮮度の置き場が散らかる。1:1 付帯テーブルに隔離するほうが移行の継ぎ目が明確。
• core の完全ローカルミラーは「事実は core が正、調査は uuid 参照」（DEC-02）と矛盾し整合性責務が重い。採らない。
• 薄い参照モデルは「事実は core が正」を保ちつつ一覧性能だけローカルで担保する最小の方法。

録画・事後処理の繋ぎ直し（DEC-02）

現状、録画後加工の各モデルが belongs_to :ot_archive（物理 FK）。外部化後は recording_uuid 参照へ。

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

統一インターフェース（DEC-01）と読み取り書き換え

Slot#interview_room がエンジンに応じてアダプタを返し、呼び出し側を非依存にする。

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

両アダプタが共通インターフェースに応答する：
#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 — 一覧・集計は interview_room_refs の cache 列で即返し、詳細はその場で core API を叩く（on demand）。API 障害時はデグレード値を返す。

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

  # 一覧・集計：API を叩かず cache 列で即返し
  def movie_duration_sec = @ref.cached_total_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:) = @client.post("/room-access-tokens", room: @ref.core_room_uuid, role:)
end

主な読み取り書き換え

同期 — Webhook 役割分担（DEC-05）

状態を2軸に分け、衝突しないよう権威を分界する。

連携インターフェース

実装フロー

主軸は 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 公開が着手条件（gating）＝core の稼働サービスは不要だが契約公開は必要（minedia-www は pure consumer）。
• Phase 3 のみ core 稼働がブロッカー。