Kristopher Baker iOSを土台に · プロダクトシステム · AI支援ワークフロー
← Aoede

note · 2026.06.07 · 約3分

ロボットのような声は、自分のコードではなく依存ライブラリのせいだった

Aoedeのニューラル音声、Kokoroが、故障したドロイドのような音を出し始めました。どの文も、ガビガビとロボットのような出だしで開き、やがて普通の発話に落ち着き、次の文の頭でまたロボットに戻る。合成された音声は、再生エンジンに届く前からすでに壊れていました。

AIコーディングエージェントと一緒に、長い夜をかけてこれを追いかけ、思いつくかぎりの道をたどりました。生の音声を取り込んで波形として眺めました。同じバッファをオーディオグラフの複製でオフラインにレンダリングし、再生を切り分けました。ボイスファイルの形を確かめ、ボコーダーのソースを読み、シードのない乱数生成器のせいで合成が非決定的になっていることまで見つけました。どの仮説も自分たちのコードを指していました。バッファリング、オーディオグラフ、PCM変換、タイミング。全部試して、ことごとく空振りでした。

突破口は、「自分たちのコードの何が悪いのか?」と問うのをやめ、「この環境の何が違うのか?」と問い始めたときに開きました。モデルをGPUではなくCPUに強制したら、ロボットのようなアーティファクトが消えたのです。それが答えのすべてでした。ある特定の依存ライブラリのバージョン、mlx-swift 0.30.x のGPU/Metal経路にある数値的なリグレッションが、このApple M5というハードウェアで出ていたのです。0.29.1に戻すと直り、新しい0.31.4でも直りました。実際の変更は、見当違いの場所を何時間も探した末の、たった一行のバージョン更新でした。

ここが覚えておく価値のあるところです。この夜、自分は二つの異なるフロンティアモデル、Opus 4.8とGPT-5.5を回しましたが、どちらも単独では原因を見つけられませんでした。彼らは本当に役に立ちました。取り込み用のハーネスを書くのは速く、アイデアを試すのは根気強く、見慣れないボコーダーのコードを読むのも上手い。でも肝心の一手、つまりコードのデバッグをやめて環境の二分探索を始めるという判断は、どうデバッグするかについての人間との協働から来たもので、エージェントから出てきたものではありませんでした。最終的に原因を見つけて確認したのはエージェントですが、それは何を探すかをこちらが変えたからこそでした。

これは、自分がこうしたツールについて考えるようになった形と一致します。彼らは探索を実行するのは得意で、その探索が間違った方を向いていることに気づくのは苦手です。仮説の方向性そのものを捨てるべきかどうかを見極めるのは、いまも人間の仕事です。修正は一行。そこにたどり着くのは、協働でした。