【要約】Discord音声BotをWAV振幅解析で自動検証する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
音声Botの開発者は、再生された音声を外部から取得する手段がない問題に直面している。
従来のテキストBotは、REST APIを用いて応答内容を検証できた。
しかし、音声Botはボイスch内の音声を直接受け取る手段を持たない。
そのため、人間がボイスchに入り、耳で音を確認する作業を強いられていた。
この「人間による確認」が、自動検証における最大のボトルネックとなっていた。
従来のテキストBotは、REST APIを用いて応答内容を検証できた。
しかし、音声Botはボイスch内の音声を直接受け取る手段を持たない。
そのため、人間がボイスchに入り、耳で音を確認する作業を強いられていた。
この「人間による確認」が、自動検証における最大のボトルネックとなっていた。
// Approach
Botの動作を「合成」「接続」「再生」の3層に分解し、個別に検証する手法を採用した。
- ・合成層：VOICEVOXのAPI動作確認と、WAVのRMS計算による無音判定を行う。
- ・接続層：systemdのjournalctlログから、ボイスchへの接続完了を確認する。
- ・再生層：FFmpegの終了コードを確認し、デコードの成否を判定する。
- ・最終工程：生成したWAVをテキストchに投稿し、人間が音質のみを確認する。
// Result
検証工程を分離したことで、開発サイクルを劇的に改善できる。
- ・「音声が鳴ったか」という物理的な検証を完全に自動化できた。
- ・人間は「声が正しいか」という主観的な判断のみにリソースを集中できる。
- ・CI/CDへの組み込みが容易になり、自動検証ステップの構築が可能となった。
Senior Engineer Insight
> 音声検証における「観測不能」という問題を、物理量（振幅）とシステム状態（ログ）への分解で解決した点は極めて実戦的だ。全ての検証を自動化しようとして破綻するのではなく、人間が担うべき「主観的評価」を明確に切り分けた設計思想は、スケーラブルなテスト設計の模範と言える。ただし、ログ解析に依存するため、ライブラリのアップデートによるログ形式変更には注意が必要だ。