アドベントカレンダー最終日なので、今日は技術詳細じゃなくて お気持ち表明 です。
この数週間、Rustで「SIP UAS + RTP + 録音 +　ASR/LLM/TTS」の音声ボット基盤を作ってきて、思ったことをそのまま書きます。

まず、なにを作っているのか（超短く）

SIPフォン（Zoiperみたいなやつ）から電話をかけると、

…というところまでをMVPとして作りました。

“会話はこれからが本番だけど、まず土台ができた、という状態です。

このプロジェクトで一番やりたかったこと

やりたかったのは「電話でしゃべるボット」そのものもあるけど、実はそれ以上に、

この2つを ちゃんと繋げられる設計 にしたかった。

雑にやると、プロトコルの泥とAIの泥が混ざって、たぶん二度と触れないコードになるので、
最初に「責務の境界」をちゃんと引くことを一番大事にしました。

みたいな話を先に固定しておいたのは、結果的にかなり効きました。

正直、実装中は「この責務どこに置くべき？」が毎日出てくるけど、迷ったときに戻れる場所があると強い。
そしてコードを書かせる時も「この境界を守れ」が伝えやすい。

“神様がある”だけで、コード生成もレビューもブレにくくなりました。

SIP/RTPって「仕様を知る」だけじゃ足りなくて、

みたいな、現実の地雷が多い。

だからこそ、MVPで “録音” を入れたのは正解だったと思っています。
録音が残ると、「音が来てるかどうか」が一瞬で分かる。
これは開発速度に直結しました。

途中で何度も「LLMを繋ぎたい」「ずんだもんに喋らせたい」って気持ちが先行しそうになったけど、
一旦 “通話基盤” に集中して、

を先に固めたのは良かったです。

AIは後から差し替えられるけど、SIP/RTPが不安定だと全部崩れる。
土台を作ってから上を乗せるのが結局いちばん早い。

SIP音声ボットって、派手なLLMの話に比べると地味で泥臭いんだけど、

みたいなソフトウェア設計の話が、めちゃくちゃ効く分野だと思っています。

結局、SIP/RTPもAIも「失敗する前提」なので、設計がないと壊れた時に戻れない。

この先のTODOは山ほどあります。
でも、MVPの基盤ができたので、これらは“積み上げ”として進められるはず。

アドベントカレンダーで書くことで、

という意味で、自分にとってかなり良い整理になりました。

もし同じことをやる人がいたら、

をおすすめします。

来年は、ずんだもんにちゃんと電話対応させます。