1. 作りたかったもの
とある定例で参加者のリアクションがなくて寂しい！という声があったので、AIでいい感じにレスポンスして参加者が発言したくなる君を作ろうとした。
Google Meet の字幕をリアルタイムに読んで、発言の区切りごとに AI が短い相づち・リアクションコメントをチャットへ投稿するものだ。
ポイントはリアルタイム性。会議の話題が次に移る前に反応できないと、コメンターとしての価値がゼロになる。
2. v1: 全部 Claude にやらせた
最初は、楽に問題解決できないかとClaude セッションの中でMCPを読んで/loop させながら音声文字データの取得と返信内容の送信をやらせた。
約60秒周期に起き、1サイクルで以下を全部 Claude がやる:
- 字幕取得
- 差分確認
- 反応すべきか判断
- コメント生成
- チャット投稿
I/O はすべて chrome-devtools MCP（ブラウザ DOM 操作）に集約。
Claude が制御ループを握り、取得も投稿も MCP 越しにやっていた。
アーキテクチャは以下
結果としては動いたが、遅くて使えない。
30分の会議で投稿できたのは 7件。リアルタイムな発言に絡むには遅すぎて、これでは期待するようなリアクションができていない。没。
3. なぜ遅いと感じたか
ボトルネックは、毎サイクル字幕の取得も投稿も Claude が MCP 経由の tool call でやっていたことだと思っている。MCP を使うということは、DOM を読む・書くという本来機械的な操作のたびに「Claude がそれを判断して tool call する」という形になる。全部 Claude（LLM）が介在している。判断からコメント生成まで含めて、コードで済む部分までまるごと Claude に多段でやらせていたのが、遅さの正体だと思う。
以前先輩が似たものを作っていて、構成を聞いたら WebSocket を使っていた。字幕取得や投稿を Claude の判断を介さずに進められる形にできるはずだと思い、ソースをもらってこの構成を改善の方針の軸にした。
4. v2 claudeの役割を最小限にする
上記の方針をclaudeに出しつつ、バイブコーディングをしながら改善をした。
- socketの通信を確立して、同期的なログの出力を確認
- claudeの呼び出しを確認できたが、全てskipになる
- wsで差分だけ送りダブりのない字幕通りのプロンプトを渡せるようにする
- 回答が出る
と段階的に改善した。
技術的な問題を解決できた構成は結果的に以下のような形になっていた。
アーキテクチャ
v1とv2の比較
| 仕事 | v1（全部 Claude） | v2（役割分担） |
|---|---|---|
| 字幕取得 | Claude が MCP で DOM 往復 | Chrome 拡張が WebSocket で push |
| 反応すべきか判断 | Claude | デーモンの区切り検出（到着間隔ベース）+ cooldown |
| コメント生成 | Claude | Claude（ここだけ残す） |
| 投稿 | Claude が MCP で DOM 操作 | Chrome 拡張のchat-inject が直接注入 |
ポイントそうなところ
- chrome拡張×node daemonで常にローカル側で最新の発話情報を保持できる構成
- claudeの処理が1箇所だけになった
- 音声文字データを渡し、返信コメントを返させるだけ
5. 結果 — スループット約3倍
| v1（Claude-as-runtime） | v2（Claude-as-function） | |
|---|---|---|
| 投稿件数 | 7件 / 30分 | 14件 / 20分 |
| 1分あたり | 約 0.23 件 | 約 0.70 件 |
| スループット | 基準 | 約3倍 |
だいたい発話した内容に対して、人間くらいの速さでレスポンスがくるようになった。
6. そして没になった
AIはmeetの話者に自然にコメントを返してくれるようになったが、実際の会議で動かしてみた結果を先輩に自慢していたら、「これ、本当にいる？」と言われてハッとなった。
そもそも会議中にリアクションが少ないことにAIがリアクションをすれば解消できるものなのか。発表者の「寂しい」と感じるその課題感からちゃんと抑えられていない。
発言しづらい空気なのか。
参加者が内容を理解できていないのか。
単に議題への関心が低いのか。
課題が曖昧なまま作り始めたので、技術的には改善できても、本当に解決したかったものを捉えられていなかった。
使えないと思ったものを出すのは嫌なので、このツールは没にした。
7. 学び
- MCPに限らずやたらLLMに処理を任せて判断実行させるのではなく、機械的にできる操作を切り分けて役割を最小限にすることが大事。
- 速くした後でも、課題そのものを抑えられてなければ意味がない。合わせて解きたい課題をちゃんと捉えていきたい。
8.感想
今回イチから丁寧に作るのではなく、バイブコーディングで一度動くものを作りつつ、リバースエンジニアリングして設計図を綺麗にするやり方で技術を学んだ。
結構テンポ良く作り、学べるのでいいやり方かもと思った。
いろんな問題見つけて気軽に形にしていきたい。