Show HN：リアルなAI音声で電子書籍をオーディオブックに変換

ある開発者が、オープンソースのKokoroモデルを活用した電子書籍からオーディオブックへの変換サービス「ebookaloud」を立ち上げました。開発者は以前から長編ナレーションにAI音声を試したいと考えていましたが、既存のサービスはすべてサブスクリプションが必要で、自分の限られた利用頻度には見合わないと感じていました。そんな中、Kokoroモデルに出会い、その音声品質の高さに感銘を受けました。従来のロボット的なTTS音声とは異なり、長時間聴いても疲れにくいだけでなく、非常に自然な発音が特徴です。Kokoroモデルは8200万パラメータとコンパクトで高速実行向けに設計されていますが、開発者の12コアラップトップでのCPU推論では十分な速度が得られませんでした。そこで、クラウドGPUサービスを利用すれば高速にオーディオブックを生成でき、そのパイプラインを製品化できると考えました。

この製品のコードの99%は、DeepSeek v4によってOpenCode上でマルチエージェントコーディングワークフローを用いて作成されました。開発者は1ヶ月で約7億5000万トークンを使用し、12ドルの費用で結果に非常に満足しています。すべての変更は、計画→実装→テスト→レビュー→修正→コミットのサイクルを経て、ProとFlashエージェントを組み合わせて行われました。通常は1〜2の同時ワーカーに制限していましたが、抽出および合成パイプラインのさまざまな部分の品質管理用に、個別の評価エージェントを用意し、8〜10のインスタンスを同時に実行することもありました。開発者は、AIワークフロー自動化において、YeggeのStage 6に近づいているかもしれないと述べています。

その後、Claude Codeを導入し、Opus 4.8とDeepSeekを並行して使用しました。品質に違いはあるものの、開発者は経験豊富なエンジニアとして実践的なアプローチをとっており、コードを直接書く代わりに、生成された重要な部分を精読し、DeepSeek Proと各ステップについて広範な議論を行いました。OpusはDeepSeekの選択に対してあまり批判的な意見はなく、開発者は最先端モデルが自身のワークフローに大きな違いをもたらすとは考えていません。大規模なコードベースでは違いがより顕著になる可能性はありますが、Opusで実装した少数の変更でも、他のモデルと同様の問題（指示なしのランダムな変更、単純な解決策の複雑化、行き詰まったときの予期しない破壊的な行動など）に遭遇しました。一方、Opusは複雑な計画やオーケストレーションを処理する能力に優れており、これは状況によっては有用ですが、常に必要とは限りません。

製品自体は、市場にはもっと洗練されたソリューションが多数存在しますが、開発者はElevenLabsと競合するつもりはなく、m4b形式のシームレスなオーディオブック体験を提供することに特化しています。従量課金制で、出力品質は「十分良い」レベルを目標としています。これは開発者が初めて商品化を試みた製品であり、AIコード生成のおかげで洗練された製品を手の届く範囲にすることができました。AIがなければ、手動での研究開発に6〜8ヶ月を要し、完了する前に燃え尽きていたでしょう。サイトのトップページには無料サンプルが用意されており、音声や形式を試すことができます。出力品質に関して、開発者はいくつかの意見決定を行っています：ほとんどの音声で業界標準に合わせて毎分140ワードを目標としましたが、一部の音声ではこの速度で韻律が損なわれるため、速度調整は再生デバイスに任せることにしました。ユーザーに多くのオプションを提示する代わりに、プレイバックデバイスに委ねるという判断です。将来的には、Kokoroの他言語対応やPDFからの抽出・合成機能を追加したいと考えています。