ナレーション生成や多言語吹き替えをクラウドの音声 SaaS に任せていると、ある時点で 3 つの制約が同時に効いてきます。従量課金が想定を超えて膨らむこと、月あたりの生成量に上限があること、そして自社や顧客の音声データを外部サービスへ送信し続けることです。とくに 3 つ目は、社内規程や顧客との秘密保持契約に照らして後から問題になりやすい部分です。
そこでローカルで動くオープンソースへの切り替えを検討し始めると、今度は別の壁にぶつかります。GitHub 上には音声合成モデルのリポジトリが数多く並んでいますが、その多くは「モデル」または「ライブラリ」であり、文字起こしから翻訳、再音声化、書き出しまでを含む業務フローをそのまま置き換えられるものではありません。どれを選べば実務に載るのか、判断軸が定まらないまま比較記事を読み続けることになりがちです。
こうした状況で候補に挙がるのが、debpalash 氏が公開している VoiceStudio です。「オープンソースかつ完全ローカルで動作する ElevenLabs 代替」を掲げるデスクトップアプリケーションで、16 の TTS エンジンと 11 の ASR エンジンをひとつのアプリの内側に束ね、音声クローンからボイスデザイン、動画吹き替え、文字起こし、オーディオブック生成までを扱います。単体のモデルではなく、複数のエンジンを取りまとめるアプリケーション層に位置しているのが最大の特徴です。
本記事では、VoiceStudio の機能とアーキテクチャ、導入手段と動作要件、Chatterbox や GPT-SoVITS といった類似プロジェクトとの違い、そして採用可否を左右するライセンス構成を、公開ドキュメントに基づいて整理します。なお本記事は README・公式サイト・公式ドキュメント・公式リリースノートを出典とするドキュメントベースの調査であり、インストールや動作検証は行っていません。音質や安定性についての主観的な評価は扱わず、採用判断に必要な事実の整理に絞ります。
ローカル音声クローンOSS「VoiceStudio」とは
完全ローカルで動く「ElevenLabs 代替」という位置づけ
VoiceStudio は、debpalash/VoiceStudio で公開されているオープンソースのデスクトップアプリケーションです。リポジトリの説明文では「オープンソースかつ完全ローカルで動作する ElevenLabs 代替」と位置づけられており、音声クローン、ボイスデザイン、動画吹き替え、口述、文字起こし、オーディオブック生成を 646 言語で扱えると謳っています。
README では、ローカルワークフローについてアカウント登録・API キー・サブスクリプション・使用量メーターのいずれも不要であることが明記されています。音声データが端末の外に出ないこと自体が、プライバシー面での主要な訴求になっている構成です。冒頭で挙げた「従量課金」「利用上限」「外部送信」という 3 つの制約に、それぞれ正面から対応する設計思想だと読み取れます。
基本情報を整理すると、主要言語は Python、ライセンスはアプリケーション本体が AGPL-3.0 です。2026 年 9 月時点で約 19,900 スター・約 2,500 フォークを集めています。リポジトリはアーカイブされておらず、他リポジトリからのフォークでもない独立した公開プロジェクトとして稼働しています。
更新の活発さについては、最新リリースで確認できる v0.5.1（2026 年 8 月 28 日）が判断材料になります。このリリースでは、Apple Silicon 上の音声生成を子プロセスとして分離して致命的なメモリエラーでバックエンド全体が落ちない構成に変更したこと、HTTP・WebSocket・JSON-RPC・CLI・MCP の各トランスポートから統合できる「ローカル音声プラットフォーム」として整理し直したこと、吹き替えで発話言語と目標言語を分離し字幕行単位のタイミング調整に対応したことなどが挙げられています。加えて、ヘッドレスな NVIDIA / ROCm マシンを worker 専用の Docker サービスとして参加させられるようになった点も記載されています。単なる機能追加ではなく、運用面の作り込みが進んでいる段階と読めます。
同名リポジトリ・旧称との見分け方
VoiceStudio という名称は一般性が高く、GitHub 上には同名または近似名のプロジェクトが複数存在します。本記事が扱うのは debpalash/VoiceStudio です。テキストのスタイルプロンプトから音声を合成・編集する研究系ツールキットである latentforge/VoiceStudio や、リアルタイムストリーミング転写と CPU 推論を志向する ASR / TTS ツールボックスの mjlzz/voice-studio は別プロジェクトであり、機能も設計思想も異なります。
さらに紛らわしいのが旧称の存在です。このプロジェクトはもともと debpalash/OmniVoice-Studio という名前で公開されており、日本語圏の紹介記事や SNS の投稿では旧称の「OmniVoice Studio」で言及されているものが少なくありません。Docker イメージ名やデータの既定保存先ディレクトリにも omnivoice の文字列が残っているため、後述するインストール手順で旧称を目にしても同一プロジェクトだと判断して問題ありません。なお、既定の TTS エンジン名も「OmniVoice」であり、こちらはプロジェクト名とは別にエンジンの固有名として現在も使われています。
情報収集の初期段階では、この 3 種類の混同（同名の別リポジトリ・旧称・エンジン名）が調査コストを押し上げる要因になります。参照する情報が debpalash/VoiceStudio のものかどうかを最初に確定させておくと、以降の比較検討がぶれません。
VoiceStudioでできること（音声クローンから吹き替え・オーディオブックまで）
VoiceStudio が扱う機能は大きく 6 系統に整理できます。単機能のツールを何本も組み合わせて構築していたパイプラインを、どこまで 1 つのアプリで置き換えられるかを判断する材料になります。
機能 | 内容 | 効きやすい業務 |
|---|---|---|
Voice Cloning（音声クローン） | 3〜15 秒程度のクリーンな参照音声からのゼロショット合成 | 特定話者のナレーションを継続的に量産する用途 |
Voice Design（ボイスデザイン） | 年齢・アクセント・ピッチ・スタイル等のパラメータから声を設計。Voice Gallery で既成ボイスを絞り込み可能 | 実在話者の音声を使えない案件での声の用意 |
Video Dubbing（動画吹き替え） | 文字起こし → 翻訳 → 話者性とタイミングを保持したまま再音声化 → 動画書き出し | 教材動画・製品デモの多言語展開 |
Dictation（口述） | システム全体で使えるウィジェット。ローカル LLM による整形を任意で利用可能 | 議事メモや下書きの音声入力 |
Transcription（文字起こし） | 音声・動画のテキスト化。話者分離に対応 | 会議録・インタビュー素材の整理 |
Audiobook / Stories | 複数話者スクリプト、EPUB / PDF インポート、 | 長尺コンテンツの音声化 |
これらに加えて、キューイングと進捗表示を伴うバッチ処理、話者分離（diarization）、ボーカル分離、モデル管理、AudioSeal による AI 生成音声のウォーターマーク埋め込みが README の機能一覧に挙げられています。
音声クローンとボイスデザイン
音声クローンは、3〜15 秒程度のクリーンな参照音声を与えるだけで合成できるゼロショット方式です。事前にデータセットを用意してファインチューニングを回す必要がないため、着手のハードルは低い部類に入ります。
一方のボイスデザインは、参照音声を使わずに年齢・アクセント・ピッチ・スタイルといったパラメータから声そのものを組み立てる機能です。実在話者の声を使うと権利処理や本人同意の確認が必要になる案件では、こちらが現実的な選択肢になります。既成のボイスを絞り込める Voice Gallery も用意されており、ゼロから設計せずに近いものを探す進め方も想定されています。
動画吹き替えと文字起こし
動画吹き替えは、文字起こし・翻訳・再音声化・動画書き出しまでを一連の流れとして扱います。単に翻訳した台本を読み上げるのではなく、話者性とタイミングを保持したまま再音声化する設計になっている点が実務上の差になります。v0.5.1 では発話言語と目標言語を分離できるようになり、字幕行単位でのタイミング調整や行の挿入にも対応しました。
文字起こしは既定で WhisperX を用い、Pyannote / WhisperX による話者分離に対応します。複数話者が入り混じる会議音声やインタビュー素材を扱う場合、この話者分離の有無が後工程の手間を大きく左右します。吹き替えパイプラインの前段としても同じ仕組みが使われるため、文字起こしと吹き替えを別々のツールで運用していた場合はまとめられる余地があります。
オーディオブック生成とウォーターマーク
オーディオブック機能では、複数話者のスクリプトを扱えるほか、EPUB / PDF のインポートと .m4b 形式での書き出しに対応します。テキスト素材を用意してから配布可能な形式に落とすまでを 1 つのアプリで完結できる構成です。
もう 1 つ、実務で見落としやすいのが AudioSeal によるウォーターマーク埋め込みです。生成音声であることを機械的に判別できる情報を埋め込む機能で、公式ドキュメントでも専用の項目が設けられています。AI 生成コンテンツの表示に関する社内ポリシーや取引先の要請がある場合、この機能の有無は選定条件に直結します。
16のTTSと11のASRを束ねるマルチエンジン設計
VoiceStudio を評価するうえで最も重要なのは、これが単一の音声合成モデルではなく、複数エンジンを束ねるアプリケーションである点です。README によれば TTS は 16 エンジン、ASR は 11 エンジンに対応します。TTS 側には既定の OmniVoice のほか CosyVoice 3、GPT-SoVITS、VoxCPM2、KittenTTS、MLX-Audio、Sherpa-ONNX などが、ASR 側には既定の WhisperX のほか Faster-Whisper、MLX Whisper、PyTorch Whisper、Parakeet、Moonshine、FunASR などが含まれます。
デスクトップシェルとバックエンドの構成
アーキテクチャは、Tauri によるデスクトップシェル（Rust）が React / Vite で実装された UI を包み、その背後で FastAPI のバックエンドが動く構成です。バックエンドはエンジンレジストリと SQLite による永続化を持ち、リモートワーカーの併用にも対応します。データの既定保存先は omnivoice_data/ です。
この構成が意味するのは、UI と処理系が疎結合になっているということです。前述のとおり v0.5.1 ではヘッドレスな GPU マシンを worker 専用の Docker サービスとして参加させられるようになっており、手元の作業マシンで UI を操作しながら重い推論は別マシンに逃がす、といった配置が視野に入ります。個人の作業ツールとしてだけでなく、チームで共有する処理基盤としての使い方も想定された設計です。
「646言語」をどう読むか
リポジトリの説明文と公式サイトはいずれも「646 言語」を掲げています。ただし README は、言語カバレッジがエンジンごとに異なる旨を明記しています。つまり 646 という数字は、束ねている全エンジンの対応言語を合算したカタログの規模であり、任意のエンジンで 646 言語すべてが使えるという意味ではありません。
採用検討の実務では、この読み替えが必要です。確認すべきは「646 言語に対応しているか」ではなく、「自社が本当に必要とする言語を、どのエンジンが、どの品質水準でカバーしているか」です。マルチエンジン構成は選択肢の広さと引き換えに、エンジンごとの特性を把握する手間を利用者側に残します。対象言語が限られているなら、まず必要言語をカバーするエンジンを絞り込んでから評価に入るのが現実的な進め方になります。
OpenAI 互換ローカル API と MCP からの統合
VoiceStudio は http://localhost:3900 でローカル API を公開し、/v1 配下で OpenAI 互換のインターフェースを提供します。README には次のクライアント例が掲載されています。
from openai import OpenAI
client = OpenAI(base_url="http://localhost:3900/v1", api_key="local")
with client.audio.speech.with_streaming_response.create(
model="tts-1",
voice="<profile-id>",
input="Made on my own hardware.",
response_format="wav",
) as response:
response.stream_to_file("speech.wav")
（出典: debpalash/VoiceStudio の README）
OpenAI SDK の base_url を差し替えるだけで呼び出せる形になっているため、既にクラウドの音声 API を組み込んでいる既存コードからの移行コストは比較的読みやすい部類です。README では音声合成の POST /v1/audio/speech、文字起こしの POST /v1/audio/transcriptions、ストリーミング転写の WS /v1/audio/transcriptions/stream といったエンドポイントが挙げられています。
さらに http://localhost:3900/mcp で Model Context Protocol のサーバーも提供され、generate_speech / clone_voice / transcribe などのツールを Claude Desktop や対応エージェントから呼び出せます。認証については、VoiceStudio 公式ドキュメントにローカル API はループバック接続では認証なしで動作する（リモートアクセスを構成した場合を除く）と記載されています。ループバック以外からのアクセスを許可する構成にする場合は、認証とネットワーク境界の設計を自分で担保する前提だと理解しておく必要があります。
なお公式ドキュメントには Cloud API のプレビューも併載されていますが、こちらは実行可能な API ではなくコントラクトのプレビューである旨が明示されています。この点は後ほど改めて触れます。
導入手段と動作要件
配布形態別のインストール手段
対応プラットフォームは、macOS 13.3 以降（Apple Silicon）、Windows 10 / 11 の x64、glibc 2.39 以降の Linux x86_64、および Docker です。リリースページではプラットフォーム別のインストーラ（DMG / MSI / AppImage）が配布されており、v0.5.1 では全デスクトップ OS 向けのワンコマンドインストールも追加されています。
サーバー上で動かす、あるいは環境を汚さずに切り分けたい場合は Docker が選択肢になります。README に記載されている起動コマンドは次のとおりです。
docker run -d -p 127.0.0.1:3900:3900 -v omnivoice-data:/app/omnivoice_data --name voicestudio palashdeb/omnivoice-studio:stable
（出典: debpalash/VoiceStudio の README）
ポートが 127.0.0.1:3900 にバインドされ、データが名前付きボリュームに永続化される形になっています。イメージ名とボリューム名に旧称の omnivoice が残っている点は、前述のとおり同一プロジェクトです。
ソースからビルドする場合は、Node 20 以降または Bun と、Python 3.11 以降が前提になります。README の手順は次のとおりです。
git clone https://github.com/debpalash/VoiceStudio.git
cd VoiceStudio
bun install
bun run desktop
（出典: debpalash/VoiceStudio の README）
配布物・Docker・ソースビルドの 3 経路が用意されているため、まず個人のマシンで挙動を確かめてから共有環境に展開する、といった段階的な進め方が取りやすい構成です。
ハードウェア要件の目安
README に掲載されている動作要件は次のとおりです。
項目 | 最小 | 推奨 |
|---|---|---|
RAM | 8 GB | 16 GB 以上 |
ディスク | 空き 10 GB | 20 GB 以上（SSD） |
GPU | 任意 | NVIDIA CUDA または Apple Silicon |
VRAM | 4 GB（GPU 使用時） | 8 GB 以上 |
Python | 3.11 以降 | 3.11 または 3.12 |
GPU が「任意」とされている点は判断が分かれるところです。GPU なしでも動作する設計ではあるものの、推奨欄に NVIDIA CUDA または Apple Silicon が明記されていることから、実用的なスループットを求めるなら GPU の確保を前提に見積もるのが妥当です。v0.5.1 では CUDA 向けに FlashInfer を用いた約 2.2 倍の高速化が任意機能として追加されたほか、Linux ARM64（Asahi / Apple Silicon）での OmniVoice GGUF エンジン対応も加わっています。
ディスク容量については、最小 10 GB という数字を額面どおり受け取らないほうが安全です。マルチエンジン構成である以上、評価対象のエンジンを増やすほどダウンロードされるモデルの総量は膨らみます。複数エンジンを比較検討する前提なら、推奨値の 20 GB を下限として見ておくほうが実態に近いはずです。
ChatterboxやGPT-SoVITSとの違い
ローカルで動く音声クローン OSS を比較する際、機能を横並びにした表だけでは選定できません。そもそも比較対象が同じレイヤーに属していないことが多いためです。ここでは代表的な 2 つのプロジェクトとの差分を、レイヤー・ライセンス・チューニング前提・守備範囲の 4 つの軸で整理します。
観点 | VoiceStudio | ||
|---|---|---|---|
レイヤー | 複数エンジンを束ねるアプリケーション | TTS モデル／ライブラリ | 音声クローンモデル + WebUI |
ライセンス | 本体 AGPL-3.0、既定モデル重みは CC-BY-NC | MIT | MIT |
チューニング前提 | ゼロショット中心（エンジン選択で調整） | ゼロショット | ゼロショット + few-shot ファインチューニング |
守備範囲 | 合成・吹き替え・文字起こし・オーディオブックまで | 音声合成 | 音声合成 |
「エンジン」と「オーケストレーター」というレイヤーの違い
Chatterbox は Resemble AI が MIT ライセンスで公開している TTS モデルです。Multilingual V3 は約 500M パラメータ・23 言語対応（日本語を含む）で、5 秒程度の音声からのゼロショットクローンが可能とされています。ただし Chatterbox が提供するのはモデルとライブラリであり、動画吹き替えのパイプラインやオーディオブックの書き出しといったアプリケーション層の機能は含まれません。自前でパイプラインを組む前提のコンポーネントです。
GPT-SoVITS はさらに構図が異なります。数秒の音声からのゼロショット合成に加えて、1 分程度の音声によるファインチューニングで精度を高める few-shot 運用に対応した音声クローン OSS で、WebUI も同梱されています。日本語コミュニティの情報量が多いこともあり、国内では有力な選択肢として定着しています。ここで重要なのは、VoiceStudio が GPT-SoVITS を 16 の TTS エンジンのひとつとして取り込んでいるという事実です。両者は競合というより、オーケストレーターと、その配下に置かれうる単一エンジンという関係にあります。
つまり「VoiceStudio か GPT-SoVITS か」という問いの立て方自体が、実態とはややずれています。より実態に近い問いは「単一エンジンを自前のパイプラインで深く追い込むか、複数エンジンと周辺機能をまとめて面倒を見てもらうか」です。
用途別の使い分け
音質の追い込みが成果を左右する用途、たとえば特定話者の声を長尺コンテンツで一貫して再現したい場合は、ファインチューニングを前提とする GPT-SoVITS を単体で運用し、パラメータとデータセットに時間を投じるほうが到達点は高くなりやすい方向です。既存アプリケーションに音声合成機能を組み込むだけであれば、MIT ライセンスで扱いやすい Chatterbox のようなライブラリが構成として素直です。
一方で、文字起こし・翻訳・吹き替え・オーディオブック書き出しといった複数の工程を横断し、それらを 1 つの UI とローカル API から回したい場合は、VoiceStudio のようなアプリケーション層に価値が生まれます。ツールを個別に選定・接続・保守するコストを、アプリケーション側にまとめて預ける判断だと言い換えられます。
ただし、この使い分けの議論はライセンスの前提が揃っていて初めて成立します。Chatterbox と GPT-SoVITS がいずれも MIT であるのに対し、VoiceStudio は本体が AGPL-3.0 で、さらにモデル重みが別ライセンスという構造を持ちます。ここが採用判断における最大の分岐点です。
商用利用の前に確認すべきAGPL-3.0とモデル重みの二層ライセンス
「OSS でローカル動作するのだから、商用でも自由に使える」という理解は、VoiceStudio については成立しません。ライセンスがアプリケーション本体とモデル重みの二層に分かれており、それぞれ別の条件が課されているためです。以下は README のライセンス記載に基づく整理であり、法的な助言ではありません。実際の採用可否は、必ずライセンス原文と各モデルの配布条件を確認したうえで、必要に応じて法務の判断を仰いでください。
アプリ本体（AGPL-3.0）で発生する義務
README は、VoiceStudio が AGPL-3.0 でライセンスされており、実行・改変・社内利用が可能であると述べています。そのうえで、改変版をネットワークサービスとして提供する場合には、対応するソースコードを同一ライセンスで提供する必要があると明記されています。
これは GPL 系のなかでも強いコピーレフトに分類される条件です。バイナリを配布しなければ開示義務は生じない GPL と異なり、AGPL はネットワーク越しにサービスとして提供する形態にも開示義務を及ぼします。社内の閉じた環境で利用する分には問題になりにくい一方、VoiceStudio を改変して自社サービスの一機能として顧客に提供する構成を取る場合は、その改変分のソース開示が視野に入ります。
なお README では、AGPL の義務を負わずに VoiceStudio 自身のコードを組み込むための商用ライセンスが別途存在することにも触れられています。ただし同時に、その商用ライセンスはサードパーティ製モデルを再ライセンスするものではないとも述べられています。問い合わせ窓口は README に記載されているため、必要な場合は公式リポジトリで直接確認してください。
モデル重みは別ライセンス（CC-BY-NC の既定エンジン）
より見落とされやすいのが、こちらの層です。README は、ダウンロードされるモデルの重みが上流の別ライセンスに従うこと、そして既定エンジンである OmniVoice の重みが CC-BY-NC の条件を持つことを明記しています。同梱される音声トークナイザーもまた別のコミュニティライセンス下にあるとされています。
さらに README は、アプリケーションのライセンス自体は生成音声の販売を制限しないが、ダウンロードしたモデルとトークナイザーの条件が制限しうる、という趣旨を明示しています。CC-BY-NC は非商用利用を条件とするライセンスであるため、既定構成のまま生成した音声を商用コンテンツに使う運用は、そのままでは成立しない可能性があります。
この「本体は OSS だが重みは非商用」という構造は VoiceStudio に固有のものではありません。たとえば研究由来の TTS である SWivid/F5-TTS も、事前学習済みチェックポイントが CC-BY-NC-4.0 で配布されています。ローカル TTS を商用案件で使う場合は、アプリケーションのライセンス表記だけを見て判断せず、読み込むモデル側の配布条件を 1 つずつ確認する手順を組み込んでおくのが安全です。VoiceStudio はマルチエンジン構成であるため、エンジンを切り替えれば重みのライセンス条件も変わります。裏を返せば、商用利用可能な条件のエンジンを選ぶという回避策が構造上は取りうるということでもあります。
Cloud / Pro とローカル版の関係
VoiceStudio 公式サイトでは、商用権とホスティングを含む VoiceStudio Pro（問い合わせベース）と、ホスト型を必要とするチーム向けの VoiceStudio Cloud（early access）に言及されています。ローカル版で商用利用の制約に抵触する場合、これらが選択肢になります。
ただし、Cloud については設計段階の情報である点に注意が必要です。公式ドキュメントの Cloud API はプレビューのコントラクト（バージョン 1.0.0）として掲載されており、実行可能な API ではないことが明記されています。ローカル API とのリクエスト／レスポンス互換も保証されていません。ローカル API に対して実装したクライアントコードが、そのまま Cloud に載せ替えられるとは考えないほうがよいということです。ローカル版の採用を「将来的に Cloud へ移行する前提」で正当化するのは、現時点では根拠が弱い判断になります。
VoiceStudioの採用を判断するチェックリスト
ここまでの内容を、採用判断の形に整理します。まず、VoiceStudio が向きやすいケースです。
- 顧客音声や社内音声を外部サービスへ送信できず、処理をローカルに閉じる必要がある
- 生成量が読みにくく、従量課金や月次上限のない構成にしたい
- 文字起こし・翻訳・吹き替え・オーディオブック書き出しまでを 1 つのツールで扱いたい
- OpenAI 互換のローカル API や MCP 経由で、社内ツールやエージェントから音声機能を呼び出したい
- 複数の TTS / ASR エンジンを比較検討したいが、個別に環境構築する手間は避けたい
- GPU 搭載マシン（NVIDIA CUDA または Apple Silicon）を用意できる
一方、慎重に検討すべきケースは次のとおりです。
- 生成音声を商用コンテンツとして販売・提供する予定があり、既定エンジンの重みが持つ CC-BY-NC 条件を回避する見通しが立っていない
- VoiceStudio を改変して自社サービスに組み込み、ネットワーク越しに提供する構成を想定しており、AGPL-3.0 のソース開示義務を受け入れられない
- GPU の予算・調達が確保できず、CPU のみで実用的なスループットが必要
- 対象言語が限定的で、その言語における品質要件が厳しい（646 言語という総数ではなく、必要言語をカバーするエンジン単体の実力を個別に確認する必要がある）
- 単一話者の音質を極限まで追い込む必要があり、ファインチューニング前提の運用を想定している
- 将来的な Cloud 移行を前提に設計したい（Cloud API は未リリースで、ローカル API との互換保証がない）
判断の順序としては、機能要件の充足よりも先にライセンス条件を確認するのが効率的です。商用配布や外部提供の予定がある場合、そこで採用可否の大枠が決まり、残りの検討が不要になることもあります。ライセンスの前提をクリアしたうえで、必要言語をカバーするエンジンの特定、動作要件の見積もり、既存パイプラインとの接続方式の検討へ進むのが、無駄の少ない進め方になります。
関連情報
音声 AI を組み込んだ社内ツールの内製化や、ローカル完結型の生成 AI 基盤の技術検証・PoC の受託開発をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。
