4 min read

Misora 開発ノート Part.4

Claude Code を利用して静的サイトとして WebRTC SFU Sora さえあれば利用できるミーティングツールを開発している。プロダクト名は Misora (み空色) 。

今までのまとめはこちら

全くコードは書いていないし、テストコード以外は見てない。CLAUDE.md をしっかり書いて、指示は複雑なタスクになりそうな場合は、かなり詳細に指示してる。E2E テストとコンポーネントテストはかなりしっかりレビューしている。

せっかくなのでメモを定期的に書いている。

ライブ機能

自社イベントではいつも開発ツールを使っていたのだが、今回は色気をだしてライブ機能をミーティングツールに追加することにした。今回は自分しか配信しないので、まずは 1 画面前提で追加。今後は複数人にも対応したデザインにしていきたい。

あくまで自社用なのでチャット機能などは追加していない。チャット機能は Discord を利用している。

視聴者専用 URL の生成

ライブ配信 URL は設定でチェックを入れるだけで生成されるようにした。チェックを入れると視聴者専用 URL が生成される。

配信側は普通にミーティングと同じページで、視聴者がいる感じになる。今後は OBS 配信用 URL とかも生成できるようにしたい。

配信準備画面

まだ配信していない状態で視聴者用の URL を開くとこんな感じになる。Tailwind CSS v4 のみで実現している。数分でできた。

配信画面

マウスオーバーすると映像停止やミュート、退室ができる

退室ってなんか違う気がするので、なんか名前を考えておきたい。ちないに全画面表示ボタンはあるが動かない。設定もまだ未実装。

WebRTC 前提なので追っかけ配信は存在しないので、ポーズ機能が本当に一時的にミュートするだけ。

マウスオーバーするだけだとこんな感じ。ちなみに画質は 1080p を 1.2 Mbps で H.265 で配信しているのを Chrome で受信している画質。

コンポーネントテスト

かなりしっかり書いている。とにかくデグレを潰すためにはコンポーネントテストを徹底的に書くしかない。Playwright Component Test 本当に便利。

  152 passed (17.8s)

E2E テスト

全ページに対して行っているが 5 分程度かかってしまうので、改善の余地あり。ただ一定時間待つ系がかなり多いので、やっかい。

PBT テスト

今回は fast-check を vitest 経由で使う PBT を導入してみた。基本的にはバリデーション系で試している。

packege.json

当面 OSS にする予定はないので、どんなライブラリを使っているのかは毎回書いておく。

  "devDependencies": {
    "@biomejs/biome": "2.0.6",
    "@playwright/experimental-ct-react": "1.53.2",
    "@playwright/test": "1.53.2",
    "@tailwindcss/vite": "4.1.11",
    "@types/node": "24.0.10",
    "@types/react": "19.1.8",
    "@types/react-dom": "19.1.6",
    "@vitejs/plugin-react": "4.6.0",
    "@vitest/ui": "3.2.4",
    "dotenv": "17.0.1",
    "fast-check": "4.1.1",
    "playwright": "1.53.2",
    "tailwindcss": "4.1.11",
    "typescript": "5.8.3",
    "vite": "7.0.2",
    "vitest": "3.2.4"
  },
  "engines": {
    "node": ">=24",
    "pnpm": ">=10"
  },
  "dependencies": {
    "jose": "6.0.11",
    "react": "19.1.0",
    "react-dom": "19.1.0",
    "react-router-dom": "7.6.3",
    "sora-js-sdk": "2025.2.0-canary.1",
    "zustand": "5.0.6"
  },
  "pnpm": {
    "overrides": {
      "vite": "7.0.2"
    }
  }

dependencies をこれ以上増やしたくない、むしろ jose は JWT だけのライブラリに切り替えたいまであるが、これ系のライブラリは信頼性が大事なので jose を使い続けると思う。

サイズ

vite v7.0.2 building for production...
✓ 200 modules transformed.

dist/index.html                   1.13 kB │ gzip:   0.61 kB
dist/assets/index-DU_A-DUO.css   35.18 kB │ gzip:   7.07 kB
dist/assets/index-DKnQ0FYT.js   444.66 kB │ gzip: 129.84 kB
✓ built in 804ms

少しずつでかくなってきてしまっている。仕方ないのだが本当は 100 kB 切りたい。試しに preact 化してみたところ、60 kB くらいになったが コンポーネントテストや色々動かなくなったので採用はあきらめた。やはり React のエコシステムはスゴイ。

モックアップ

何度か書いているがまず新しいページを追加する時は HTML + Tailwind CSS (CDN版) を利用して 1 つの HTML でモックアップを作っている。好き放題依頼してデザインをリテイクしまくっている。

その後、HTML から React の 1 ページとして起こしてもらい、E2E テストを書く。その後、コンポーネント分割を行い、コンポーネントテストを書いて、E2E テストとコンポーネントテストが通るという流れで作業を進めている。

エンタープライズっぽくしてという依頼をしたらファイル名に enterprise が付いた。

ちゃんとマウスオーバーでメニューバーが出るところまでモックアップで実現してる

ここまでのコード量

1 行も自分では書いてない。テストコードを大量に増やしたりリファクタリングや、コンポーネントの整理を積極的にしたこともあってかなり増えた。またライブ機能のモックアップ作成も影響していそう。

今後

ライブ機能周りを整理したら、バグ取りに戻る。まだまだバグはあるし、デグレ対策でテストも追加して行きたい。

テストも定期的にレビューして見直していかないとかなり意味のないテストも存在するので気をつけたい。

DuckDB-Wasm を利用した可視化ツールはライブ機能でも便利そうだなと思ったのでそれも実現したいところ。

Sora は定期的に帯域推定の結果をクライアントに通知する機能があるのでそれをクライアント側で好きなタイミングで見られるようにするだけでも違いそう。

雑感

とにかく HTML -> React -> テストという流れが本当に快適でびっくりする。今までは自分で作るにはコスパが良くないが、人に依頼するには連携が難しかったので、一人で自分が考えた最強のミーティングツール(ライブ機能含む)が作れるのはとても楽しい。

他にも自社製品向けの React コンポーネント集を作り始めた。<SoraChannel> みたいな感じで使えるやつ。OSS で公開すればそのコンポーネントを読み込んで Sora を使った製品を気軽に作りやすくなると考えている。とても楽しい。