この記事は筆者オンリーのAdvent Calendar 202514日目の記事です。

Rustで、SIPのUASとして通話を受けて、相手の音声をASR→LLM→TTS（VOICEVOX）で返す「ずんだもん音声ボット」を作っています。

この記事は「このプロジェクト、どういう方向性でRustコードを書いていくか？」という 方針（ガイド） を、ざっくりまとめたメモです。
（SIPの細かいRFCや、Zoiperの設定、RTPの地獄などは別記事に回します）

目標：いったん “通話が成立して会話できる” を最短で作る

最初にやりたいことはこれだけです。

「全部完璧」より、まず 通話ができて会話が回る ことを優先します。

大方針：イベント駆動 + レイヤ分離で“迷子”を防ぐ

SIP/RTP（プロトコル）と、会話ロジックと、AI連携が混ざると、一気に破綻します。
なので最初から、役割を分けて“混ぜない”ことを徹底します。

ざっくり分けるとこう：

重要なのは「依存方向」です。

逆向きに呼び出さない。逆向きはイベントで通知する、というルールにします。

モジュール間のやり取りは、基本 enumイベント + 非同期チャネルでつなぐ想定です。

例（イメージ）：

こうすると「どこで判断してるか」が分かりやすくなって、後から改修しやすいです。

Tokioで実装するときの基本方針は：

共有Mutexで全体を守るのではなく、セッションタスク内に状態を閉じ込める方向で考えます。

ASR/LLM/TTSは、将来的にローカル/クラウドを切り替える可能性が高いので、最初から差し替え前提にします。

この方針にすると、例えば

みたいな変更がしやすくなります。

音声ボットは「無言」が一番つらいです。

こういうのは普通に起こるので、最初から

みたいな雑なポリシーを app 側に持たせる想定です。

自分はこの順で作ると迷子になりにくいと思っています。

この記事は「SIP音声ボットをRustで作る時に、どういう方向でコードを書くか」というメモでした。

次は、どれを書くかで悩んでいます：

自分の理解が進んだら、順番に記事にしていきます。