【ITニュース解説】Qwen3-TTS Silently Dropped My Instruction, and My A/B Never Noticed

AIによる音声合成（Text-to-Speech, TTS）モデル「Qwen3-TTS」の評価中に、システム開発における重要な教訓が得られた。それは、ソフトウェアがユーザーの指示を「黙って無視する」ことがあるという問題である。この問題は、一見するとシステムが正常に動作しているように見えるため、発見が非常に困難であり、誤った判断を招く危険性をはらんでいる。

このプロジェクトの目的の一つは、Qwen3-TTSモデルを使用して、特定の速さ（例えば1分間に230語、つまり230 WPM）で音声を生成できるかを検証することだった。具体的には、モデルに与えるテキスト形式の「指示（instruction）」パラメーターを使って、音声の速さを制御できるかどうかをA/Bテストで評価した。A/Bテストとは、二つの異なる条件（この場合は「指示あり」と「指示なし」）でシステムを実行し、その結果を比較する手法である。Qwen3-TTSには0.6B（6億）と1.7B（17億）という二つのモデルサイズがあり、それぞれで「230 WPM程度で話すように」や「競売人のように速く話すように」といった指示を試した。

初期のA/Bテスト結果では、指示を与えても音声の速さは目標の230 WPMには遠く、指示なしの場合と比較しても大きな変化は見られなかった。例えば、0.6Bモデルでは指示ありで139.1 WPMと131.8 WPM、指示なしで129.9 WPMとなり、1.7Bモデルでは指示ありで140.6 WPMと126.3 WPM、指示なしで128.3 WPMであった。最大の変化でも9.6%程度の増加に留まり、指示によって音声の速さを調整することは難しいという結論に至った。また、モデル選択においては、0.6Bモデルが約3.22ギガバイト（GiB）のメモリを使用し、設定された4 GiBのメモリ要件に適合したのに対し、1.7Bモデルは約5.6 GiBを使用し要件を超過したため、0.6Bモデルがデフォルトとして採用された。

しかし、この結論は後日、驚くべき事実によって覆されることになった。別の実験中に、Qwen3-TTSのライブラリ（qwen_tts 0.1.1パッケージ）のコード内部で、0.6Bモデルに関する特定の一行が発見された。そのコードは「もしモデルサイズが"0b6"（0.6Bモデルを示すタグ）であれば、instructパラメーターをNone（何もなし）に設定する」というものだった。このコードが示すのは、0.6Bモデルの場合、開発者がどんな指示を与えても、それが実際にモデルに渡される前に強制的に「何もなし」の状態に上書きされていたということである。

この問題の最も恐ろしい点は、「サイレントドロップ」と呼ばれているように、この上書き処理がエラーメッセージも、警告も、ログ出力も一切行わなかったことである。つまり、システムは表面上、全く問題なく動作しているように見えた。開発者は指示を与えたつもりでテストを実行していたが、実際には0.6Bモデルは常に指示なしの状態で音声を生成していたことになる。生成された音声は完璧で、文字起こしにも誤りはなく、測定されたWPMも不自然ではなかったため、誰もこの問題に気づかなかった。結果として、0.6Bモデルで行われた「指示あり」のテストは、全て「指示なし」のテストとして処理され、そのデータに基づいて「指示は効果がない」という誤った結論が導き出されてしまったのである。

この経験から、システム開発における重要な教訓が明確になった。それは、利用するライブラリやフレームワークが提供する機能が、本当に意図通りに動作しているかを常に検証する必要があるということである。特に、オプションのパラメーターや設定値（コントロールノブと表現されている）については、それが実際にシステムに影響を与えているかを徹底的に確認しなければならない。

具体的な確認ポイントは以下のようになる。まず、A/Bテストのような比較を行う前に、設定値の有効性を確認することが不可欠である。例えば、速さを制御する「ノブ」であれば、最も速い設定と最も遅い設定の二つの極端な値で実行し、期待される出力（WPMなど）が明確に変化するかを測定する。もし、極端な設定値でも出力がほとんど変わらないのであれば、そのノブは機能していない可能性が高い。次に、オプションの引数（指示パラメーターなど）が、コードのどこかで黙って破棄されていないかを、モデルの入力に到達するまでその経路を追跡して確認する。ライブラリの内部実装によって、開発者が意識しないところで引数が無視されることがあるためである。

さらに、システム性能を測定するための「測定器」自体が正しく機能しているかをキャリブレーション（校正）する必要がある。これは、既知の結果を持つコントロールデータ（例えば、明確に速さが異なる音声クリップなど）と比較し、測定器が期待通りに反応するかを検証する作業である。最後に、これらのチェックはプロトタイプや開発環境でテストしたモデルだけでなく、実際に顧客に提供する予定のモデルサイズ、話者、動作モードなど、最終的な構成全てで繰り返すことが重要である。異なるモデルサイズや話者では、同じ設定値でも動作が異なる可能性があるためだ。例えば、声のトーン（感情）を制御する機能についても検証が行われたが、指示パラメーターよりも、特定のトーンを持つ参照音声クリップを利用する方が効果的であることが判明した。また、特定のスピーカーで機能したトーン制御の設定が、別のスピーカーでは効果が薄いことも確認された。

この事例は、システムエンジニアが開発を行う上で、提供されるライブラリやフレームワークの動作を盲目的に信頼せず、常にその内部動作を疑い、検証する姿勢が極めて重要であることを示唆している。見えないところで機能が無視されるという問題は、開発時間の無駄だけでなく、誤った意思決定やシステムの欠陥に直結する可能性があるため、これらの検証プロセスを開発ワークフローに組み込むことが、信頼性の高いシステムを構築する上で不可欠である。