3 min read

Misora 開発ノート Part.1

Claude Code を利用して静的サイトとして WebRTC SFU Sora さえあれば利用できるミーティングツールを開発している。

詳細は以下の記事に書いてある。また開発 6 日目までのメモも書いてある。

社内専用オンラインミーティングツールを Claude Code で作ってる
自社製品の WebRTC SFU を利用した社内専用のプライベートオンラインミーティングツールを Claude Code で作ってる。プロダクト名は Misora (み空色) 。 全くコードは書いていないし、見てない。CLAUDE.md をしっかり書いて、指示は複雑なタスクになりそうな場合は、かなり詳細に指示してる。 モチベーション もともと自社専用のオンラインミーティングツールが欲しかったが、開発ツールを利用で困っていたわけではなかった。 またコストかけて作るメリットがあまり見えなかった。ただ Claude Code であれば、かなりコストを抑えて作れると判断してチャレンジしてみた。実際 1 日で最低限の機能を搭載したミーティングツールが出来た。 前提 * VS Code の Claude Code 拡張を利用 * Claude Opus 4 (/model opus) を利用 * WebRTC SFU Sora を利用 * Sora Cloud や Sora

せっかくなのでメモを定期的に書いていこうと思う。

E2E テストの導入

Claude Code で書いてると恐ろしくデグレするので、そろそろ E2E テストを書くぞということで、 Playwright を利用して E2E テストを書いてみることにした。

Vite で開発サーバを起動して、そこに Playwright でアクセスしてテストするという戦略。静的サイトなのでセットアップも何もいらないのが良い。

もちろん WebRTC SFU Sora は自社の Sora Labo というサービスを利用している。これは .env.test に設定して VITE_* で始まってビルドするともう既に埋め込まれているので Playwright 側で何かする必要はない。

E2E テスト書いてみてわかったが想像以上に転ける。びっくりするくらい転ける。つまりそれくらい「破壊的な変更を積極的にやっている」ということがわかった。

また、E2E テスト自体はしっかり書くこともあれば手抜きで、何それ意味あるの?というのもあるのでレビューは大事。

コンポーネントテストの導入

Claude Code で大きくなってきた Page に対して、コンポーネント化をすることで、コンポーネントのテストがしたくなってきた。Vitest でもテストできるようなのだが、いかんせんしっくりこない。調べたら Playwright がコンポーネントテストの仕組みを提供しているということがわかり、早速導入。

とりあえず、簡単なオーディオインジケーターのテストを作ってみたが、コンポーネントのテストの知識が全くないので、どう配置するべきなのか?すらわからない。ファイル名の付け方もわからない。

Claude Code に相談してみたところ、コンポーネントなんだし同じ場所に置いた方がわかりやすいので、Spam.tsx のテストファイルは Spam.ct.tsx で、同じ場所に置くのはどうか?と提案されたので採用。 tests/ 以下にあると見づらくて嫌だなと思っていたのでちょうど良い。

テスト動かしてみたところ、Tailwind CSS がうまく読み込めていないことがわかった。調べたら解決策が提示されていた。ctViteConfig で vite.config.ts を読み込んで、@import "tailwindcss" source("."); とすれば解決するとのこと。

[Bug]: Component testing doesn’t work with tailwind v4. Tailwind utilities doesn’t applied · Issue #36060 · microsoft/playwright
Version 1.52.0 Steps to reproduce Example steps (replace with your own): Clone my repo at https://github.com/vovsemenv/playwright-ct-tailwind-problem npm install npm run test-ct You should see the…

せっかくなので Tailwind CSS をちゃんと読み込めるかどうかのコンポーネントテストを作ってみた。TailwindCss.tsx / TailwindCss.ct.tsx で、無事動作確認。ちなみに Playwright でスクリーンショットを撮ったりして、ちゃんと反映されているかも確認した。Claude Code は画像もちゃんと確認してくれる。

次のステップ

いろいろ機能を実装はしているのだが、それらについては次回へ。まずは徹底的にテストをして、デグレを抑える。

Claude Code を利用して開発はとにかくデグレ対策が全てと言っていいほど。結局人は「あの機能に影響ありそうだな ... 」みたいなのを意識できる場合があるが、LLM さんは知らない機能は「本当に知らない」ので、影響など全く考えずコードを変えて言ってしまう。

ただ、React でコンポーネントを綺麗に分割したり、コンポーネントテストを書いたりは、今までコストが高かったのが一気に下がったというのはあるので、オススメしたい。

とくにコンポーネントテストでは PBT (fast-check) を利用して変な値でも挙動がおかしくならないかを確認できそうでやってみようと思っている。

Claude Code + Playwright Component Test + スクリーンショット

E2E テストをしていたときに挙動がおかしくなった際、「スクリーンショットを撮って確認します」みたいなことを言ってきてたが、まぁ嘘だろうと判断していたのだが、どうやら本当っぽい。

今日も Taildwind の読み込みがうまく行かないタイミングでスクリーンショットを撮って確認していた。ほんとか?とおもって画像の中身を差し替えたりして確認したらちゃんと差し替えた画像について説明していた。これは結構な革命ではないだろうか?