音楽と場所は、切り離せない。これは感覚論じゃなくて、エンジニアリングの話だ。
uta.liveを作るとき、バックエンドはRust + Axumで書いた。リアルタイム音声ストリーミングと歌詞syncを同時に扱うには、レイテンシとスループットの両方を制御できる言語が必要だったから。WebRTCのシグナリングサーバーを自前で立て、ICEネゴシエーションのタイムアウトをチューニングし、歌詞データのdiffをバイナリストリームで流す。そういう細部を詰めながら、ふと気づいたことがある。
同じ実装、同じレイテンシ、同じ曲——でも、防音室とビーチでは、まったく別の歌になる。マイクに入る声の質が違う。聴衆の反応が違う。体が感じる空気圧が違う。コードベースはまったく同じなのに、出力が別物になる。
プロダクトの本質は「文脈」を設計することだ
自分が今書いているコードは全部Rustで、デプロイ先はFly.io(TokyoのnrtリージョンにSQLite + libSQL + WALモード)だ。chatweb.ai、JiuFlow、パシャ、そしてuta.liveのバックエンド——全部同じスタック。統一されたスタックには、意味がある。Dockerビルドにcargo-chefを入れると、依存クレートに変更がなければキャッシュがヒットして、5〜10分かかっていたビルドが1〜2分で終わる。Claude Codeをマルチエージェントで並列稼働させると、開発速度は体感で3〜5倍になる。インフラのノイズを消せば、「何を作るか」だけに集中できる。
そうやってプロダクト設計に集中するほど、気づくことがある。優れたサービスは「機能の束」ではなく「文脈の設計」だ、と。カラオケボックスの本質は歌えることじゃなくて、「みんなで馬鹿になれる許可が与えられた時間」を提供することだ。uta.liveが面白かったのも、ストリーミングの実装じゃなく、「どこでも歌えるはずなのに、場所がすべてを決める」という矛盾を観察できたからだった。
SOLUNAは、その観察の延長線上にある。「音楽が鳴る場所を、プロダクトとして作ったらどうなるか」——これがSOLUNAを始めた、ほぼすべての動機だ。