配信を止めないための、OS設計

午前4時の冷や汗

status field not found in roomInfo というエラーが画面を埋め尽くした。「またか」という絶望と、それでも投げ出せないという責任感。配信を待つリスナーと、背負っているクライアントの顔が浮かぶ。

バグの正体：API との「終わりなき追いかけっこ」

最初は TikTok API の仕様変更を疑い、次に FSM（有限状態マシン）のバグを疑った。しかし、真の原因は「単なるフィールドの欠損」に対する過剰な潔癖さ（ガードマンが厳しすぎたこと）だった。「バグを見つけた！」という興奮と、同時に「なぜ今までこんな単純な設計ミスに気づかなかったのか」という、開発者としての未熟さと成長への手応え。

「壊れないシステム」の哲学

• INVALID を「破損」ではなく「説明不能な揺らぎ」と再定義し、指数退避（Exponential Backoff）という新しいリズムを実装した。

• 感情: 壊れたら止まるシステムから、壊れても呼吸し続けるシステムへ。「完璧」を目指すのではなく「適応」を目指すという、人生にも通じる哲学への気づき。

最後の壁：二重接続という名の「エゴ」

管理画面と OBS が同じ部屋を奪い合っていた。Role System（役割分担）を導入し、OBS をただの「受動的な観測者」に格下げした。

すべてを自分で制御しようとする「技術的なエゴ」が、実はシステムを不安定にしていたという矛盾への皮肉。手放すことの重要性。

UIはGPUになれ

修正は、管理画面と OBS の関係を明確にすることでした。 OBS から「制御権（JOIN_ROOM）」を剥奪し、ただの「描画専用GPU」に格下げする。WebSocket の権限を切り離し、管理画面だけを正当な指揮官として定義する。 Role-based Client 分離。 これに気づいた瞬間、システムから余計なノイズが消え、呼吸が整いました。

6月は撃ち抜く月

振り返れば、バグに振り回されていた数日間は、Pace-Sync が単なる「趣味のツール」から「本番に耐えうる配信OS」へと脱皮する過程でした。 「壊れないシステム」を設計する過程で、私自身も「壊れない経営者」へ変わろうとしています。

技術的なトラブルはすべて過去のものになりました。 今、コードベースはかつてないほど盤石です。

さあ、準備は整った。 30社への突撃に向けた、静かな自信。 6月は走る月ではない。撃ち抜く月である。