ローカルAI音声スタジオOSS「Voicebox」の仕組みと特徴

「ElevenLabs や WisprFlow のようなクラウド音声 AI サービスを、そのままローカルで置き換えられないか」——このような要件に直面した経験のあるエンジニアは少なくないはずです。音声データを社外に出せない業務、API 料金を抑えたい個人プロジェクト、あるいは Claude Code や Cursor といったエージェントに「自前の声で通知させたい」という開発体験の要求など、動機はさまざまです。

しかし OSS の音声スタジオを探し始めると、すぐに壁にぶつかります。TTS 単機能のライブラリは豊富にあるものの、「音声出力（TTS）＋音声入力（口述・STT）＋エージェント連携（MCP）」を1つのアプリで完結させたい場合、選択肢は一気に狭まります。さらに日本語で「Voicebox」を検索すると、同名で無関係な日本語 TTS ソフトウェア「VOICEVOX」が上位に表示されるため、情報収集そのものが難しくなります。

本記事で取り上げる Voicebox（jamiepine/voicebox）は、この空白域を埋めることを狙う OSS です。ローカル実行を前提に、7 つの TTS エンジン、Whisper ベースの STT、そして MCP サーバを1つのデスクトップアプリに束ねています。開発は Spacedrive の作者としても知られる Jamie Pine 氏が主導しており、リポジトリメタデータ（archived=false / fork=false / MIT ライセンス）から見ても評価に着手できる状態です。

なお、日本語 TTS の VOICEVOX（ヒホ／ヒホサウンド系）と本記事の Voicebox は表記・発音が近いだけで、開発元・機能・成り立ちのいずれも別プロダクトです。区別のため、本文では英名 Voicebox をそのまま用います。

本記事では、Voicebox の位置づけ・主な機能・技術スタック・サポートプラットフォーム・MCP を介したエージェント連携・類似 OSS との違い・向き不向きを、README と公式ドキュメントの記述をもとに整理します。動作検証やインストール手順の実行は行わず、あくまで採用判断のための一次情報の整理として読んでください。

Voiceboxとは

Voicebox は、公式サイト voicebox.sh で「The open-source AI voice studio.」と説明されるローカル実行型のデスクトップアプリです。README の一文を引用すると、次のように位置づけられています。

"Voicebox is a local-first AI voice studio — a free and open-source alternative to ElevenLabs and WisprFlow in one app."

出典: README（jamiepine/voicebox）

音声 I/O ループの「出力側（TTS）」を ElevenLabs、「入力側（口述・STT）」を WisprFlow が代表するクラウドサービスに対し、Voicebox はその両方を1つのアプリで置き換え、間をローカル LLM でつなぐ設計思想を取っています。全てローカル実行であり、音声データやモデルがマシン外へ送信されない点が本 OSS の中核的な特徴です。

繰り返しになりますが、日本語 TTS の VOICEVOX とは無関係のプロダクトです。表記や音は近いものの、開発者・技術スタック・機能構成のいずれにおいても別物と理解して読み進めてください。

プロジェクトの位置づけと開発体制

Voicebox のメンテナは Jamie Pine 氏（jamiepine）です。同氏は、クロスプラットフォームのファイル管理 OSS「Spacedrive」の作者としても知られています。README を見る限り、他社 SaaS の代替を意識した機能設計・UX が随所に反映されており、単一メンテナ主導ながら「production 志向のプロダクトとして仕上げにいく」姿勢がうかがえます。

初見のエンジニアにとって、OSS を評価するうえで気になるのは「今もメンテされているか」「アーカイブ済ではないか」「forkプロジェクトの派生ではないか」の 3 点でしょう。Voicebox は執筆時点で以下のとおりで、いずれも評価着手の妨げになる状態ではありません。

• archived: false（アーカイブされていない）
• fork: false（他リポジトリの fork ではないオリジナル）
• disabled: false（無効化されていない）
• pushed_at: 2026-07-02T23:12:35Z（本記事作成日直近に更新あり）

リポジトリ基本情報

GitHub リポジトリ jamiepine/voicebox の主要メタデータは以下のとおりです。

スター数 37,092・フォーク数 4,460 という水準は、リリース直後の実験的 OSS とは一線を画すレベルです。ライセンスは MIT のため、商用アプリへの組み込みや改変を含む再配布についても本体側は寛容な条件になります（ただし、後述する内部 TTS エンジンや Whisper など、各モデルのライセンスは個別確認が必要です）。

Voiceboxの主な機能

README は非常に多くの機能を列挙していますが、そのまま読むと「結局どの機能が中核なのか」が捉えにくくなります。本節では、意思決定に必要な観点で「音声出力（TTS）」「音声入力（口述・STT）」「エージェント連携（MCP）」「エフェクト・音声人格」の 4 軸に整理して紹介します。

7つのTTSエンジンと音声クローン

Voicebox は生成ごとに切り替えられる TTS エンジンを 7 つ内蔵しています。README の該当テーブル（Multi-Engine Voice Cloning）を要約すると、それぞれの得意領域は次のとおりです。

音声クローンは数秒の参照音声から zero-shot で行えるほか、Kokoro と Qwen CustomVoice には合計 50 種以上のキュレーション済みプリセットが用意されています。テキストの長さは最大 50,000 文字まで扱え、文境界で自動チャンク分割し、各チャンクを独立生成してクロスフェード連結する仕組みです。CJK 句読点や略語、[tags] を尊重するスマート分割も備えています。

「英語のみ十分でよい」のか、「日本語・多言語も担保したい」のかで、選ぶべきエンジンは変わります。多言語カバレッジを優先するなら Chatterbox Multilingual、CPU での軽量運用を優先するなら Kokoro や LuxTTS、というのが README の記述から素直に導ける選定軸です。

グローバル口述とWhisperベースの文字起こし

Voicebox は音声入力側の機能も同一アプリで扱います。README では以下の 2 系統が紹介されています。

• Global Dictation: OS 全体で使えるホットキーで録音し、macOS ではフォーカスされたテキストフィールドへ Accessibility 経由で自動ペーストする。クリップボードは atomic save/restore で保持されるため、既存の内容は失われない。押し続け（push-to-talk）と単押しトグルの両モードがある。
• Speech-to-Text: OpenAI Whisper を採用し、Base / Small / Medium / Large / Turbo をサポート。Apple Silicon では MLX、それ以外では PyTorch（CUDA / ROCm / DirectML / CPU）で動作する。Turbo は Whisper Large の約 8 倍速で、大きな品質劣化なしとされる。

さらに、ペースト前にローカル LLM で「ums」「stutter」「false start」を除去するリファインメント処理が任意で挿入できる点も、口述用途では強みになりそうです。全ての口述・録音・アップロードは Captures タブに自動保存され、再文字起こし・LLM 再リファイン・インライン編集・音声プロファイル化までを 1 か所で回せる設計です。

Windows / Linux については、README のロードマップに「auto-paste parity」が挙がっており、現時点では自動ペーストのフル対応は macOS が先行しています。Windows / Linux は「アプリ内のマイクボタンからの入力」は使えますが、任意のテキストフィールドへの自動ペーストを前提とした運用を計画している場合、この点は事前に把握しておく必要があります。

MCP サーバによるエージェント連携（Claude Code / Cursor / Cline）

Voicebox の差別化ポイントとして特に強調されているのが、内蔵の MCP（Model Context Protocol）サーバです。README では次のように紹介されています。

"Every agent gets a voice. One tool call and any MCP-aware agent can speak to you in a voice you've cloned — task completions, questions, notifications."

出典: README「Agent Voice Output」

MCP サーバは FastMCP をベースに /mcp にマウントされ、Streamable HTTP でクライアントと通信します。stdio 経由の接続も用意されているため、HTTP MCP を話せないクライアントでも同じ機能にアクセスできます。提供ツールは 4 種で、詳細は後述の MCP サーバ節で扱います。

「Claude Code に音声で通知させる」「Cursor での作業中に、テストが通ったら音声で知らせる」といったコーディングエージェントの音声化ユースケースを、voicebox.speak のツール呼び出し 1 つで実現できる点が、他の音声 OSS には見当たらない設計です。

エフェクト・音声人格・Stories エディタ

生成後の後処理として、Spotify の pedalboard ライブラリを用いた 8 種のオーディオエフェクトが用意されています。Pitch Shift / Reverb / Delay / Chorus（Flanger）/ Compressor / Gain / High-Pass Filter / Low-Pass Filter が対象で、Robotic / Radio / Echo Chamber / Deep Voice の 4 プリセットも内蔵されています。プロファイルごとにデフォルトのエフェクトチェーンを固定できるため、キャラクター音声の管理を宣言的に行える点は、キャラクター系コンテンツ用途では扱いやすい設計です。

Voice Personalities（音声人格）は、各音声プロファイルにフリーフォーマットのペルソナを付与できる機能です。「Compose」ボタンでキャラクター発話をシャッフル生成し、「Speak in character」でユーザー入力をペルソナ LLM 経由で書き換えてから TTS に流し込みます。Voicebox は Qwen3 の 0.6B / 1.7B / 4B をローカル LLM として同梱しており、この LLM は TTS ランタイムと GPU メモリを共有します。

Stories エディタは複数音声を並べる会話・ポッドキャスト・ナラティブ制作向けのタイムラインエディタです。ドラッグ＆ドロップでのトラック編成、インラインでのオーディオトリム／分割、同期プレイヘッド、トラッククリップごとのバージョンピン留めなどを備えます。「音声制作寄り」の用途にも一定の作り込みがある点は覚えておくとよいでしょう。

技術スタックとアーキテクチャ

Voicebox は「Electron ではない」ことを README で明示的にアピールしています。デスクトップ側は Tauri（Rust）で書かれ、バックエンドは Python の FastAPI が担当する 2 プロセス構成です。

REST API は FastAPI 側で http://127.0.0.1:17493 に公開されます。ローカルの固定ポートを占有する設計のため、他のツールとポートが衝突していないかは、導入前に確認しておくとよいでしょう。

プロセス構成とプロジェクト構造

README では、プロジェクトのディレクトリ構造として以下が示されています。

voicebox/
├── app/       # 共通 React フロントエンド
├── tauri/     # Tauri + Rust デスクトップアプリ
├── web/       # Web デプロイ
├── backend/   # Python FastAPI サーバ
├── landing/   # マーケティングサイト
└── scripts/   # ビルド・リリーススクリプト

出典: README（jamiepine/voicebox）

Tauri がデスクトップ側の UI・グローバルホットキー・ペースト注入を担当し、Python バックエンドがモデル推論と REST API を提供します。フロントは app/ に集約され、web/ と tauri/ はそれぞれ Web と Tauri の薄いホストになっている、と読み解けます。

推論バックエンド（MLX / PyTorch / DirectML / ROCm / CPU）

Voicebox は推論バックエンドを動的に切り替える設計です。README の GPU Support テーブルを整理すると、対応関係は以下のとおりです。

「Apple Silicon で MLX、他は PyTorch」というシンプルな整理は、モデルキャッシュや GPU メモリの共有を成立させるうえでも都合が良い設計です。TTS・STT・ローカル LLM が同一の推論ランタイムに乗ることで、「モデルをまとめてロードして GPU メモリを分け合う」という運用が可能になります。

サポートプラットフォームと GPU 対応

初見エンジニアの意思決定で決定的な離脱ポイントになりやすいのが「手元の環境で本当に動くか」です。ここでは README の Download テーブルおよび GPU Support テーブルをもとに、対応状況を整理します。

対応 OS とダウンロード提供状況

macOS（Apple Silicon / Intel）と Windows についてはビルド済みバイナリが用意されており、Docker でも docker compose up で起動できるとされています。一方で Linux はビルド済みバイナリが提供されておらず、ソースビルドが必要な状態です。Linux 環境でのバイナリ配布が必須の要件を持つ場合、この点は Voicebox の採用可否に直接影響します。

GPU バックエンド別の想定パフォーマンス

README では Apple Silicon（MLX / Metal）でのニューラルエンジン経由の推論が「4〜5 倍速」と紹介されており、Whisper Turbo は Whisper Large と比べて「約 8 倍速で品質劣化は最小限」とされています。実際の秒あたり生成量はモデル・入力長・エフェクト有無で変わるため、README の数値は「相対的な優位性の指標」として読むのが安全です。

CPU 推論は「動くが遅い」というのが README の総括で、少なくとも実運用では GPU の準備を前提とするほうが体験は安定します。GPU なし環境で「軽量な Kokoro / LuxTTS でどこまで実用に耐えるか」は、要件次第で個別検証が必要な領域です（本記事では動作検証は行いません）。

MCP サーバで実現する Claude Code 連携

Voicebox の最大の差別化ポイントは、繰り返しになりますが MCP サーバの内蔵にあります。ここでは、公式ドキュメント docs.voicebox.sh および README の記述に基づいて、MCP サーバの構成とセットアップ例を紹介します。

MCP サーバの構成と提供ツール

MCP サーバは FastMCP をベースに、Streamable HTTP で http://127.0.0.1:17493/mcp にマウントされています。HTTP MCP を話せないクライアント向けに、アプリ同梱の voicebox-mcp バイナリを stdio 経由で呼び出す方式も併用可能です。提供ツールは以下の 4 種類です。

• voicebox.speak — 指定した音声プロファイルでテキストを喋る
• voicebox.transcribe — 音声ファイルを Whisper で文字起こしする
• voicebox.list_captures — Captures（口述・録音・アップロード履歴）を列挙する
• voicebox.list_profiles — 登録された音声プロファイルを列挙する

クライアントごとに音声プロファイルを固定できる点も差別化要素で、README では「Claude Code は Morgan、Cursor は Scarlett」といったバインドの例が紹介されています。話している間は OS レベルのオーバーレイ（"pill"）に音声名が表示されるため、複数のエージェントが同居していても「今どのエージェントが喋っているか」を視認できます。

Claude Code へのセットアップ例

README では、Claude Code へのインストールを次のワンライナーで案内しています。動作検証は本記事の対象外のため、README の記述をそのまま引用します。

claude mcp add voicebox \
  --transport http \
  --url http://127.0.0.1:17493/mcp \
  --header "X-Voicebox-Client-Id: claude-code"

出典: README「MCP server」

Cursor / Windsurf / VS Code MCP など、任意の HTTP MCP クライアント向けには、標準的な mcpServers 設定で URL 登録する方式が紹介されています。

{
  "mcpServers": {
    "voicebox": {
      "url": "http://127.0.0.1:17493/mcp",
      "headers": { "X-Voicebox-Client-Id": "cursor" }
    }
  }
}

出典: README「MCP server」

HTTP MCP を話せないクライアント向けには、macOS の場合、アプリ内バンドルの voicebox-mcp バイナリを stdio で呼び出す設定も用意されています。

{
  "mcpServers": {
    "voicebox": {
      "command": "/Applications/Voicebox.app/Contents/MacOS/voicebox-mcp",
      "env": { "VOICEBOX_CLIENT_ID": "claude-desktop" }
    }
  }
}

出典: README「MCP server」

MCP サーバのツール仕様・音声解決の優先順位・セキュリティ上の注意点などは、公式ドキュメント docs.voicebox.sh に一次情報がまとまっています。実運用に向けては公式ドキュメントの精読が前提となる領域です。

類似 OSS との違い

初見のエンジニアが評価着手の前に必ず問うのが「他の OSS ではダメなのか」という点です。ここでは、機能スコープと立ち位置が近い 2 つの OSS と Voicebox を対比し、どのようなケースで Voicebox 以外を選ぶべきかも併せて示します。

OmniVoice-Studio との比較

OmniVoice-Studio（debpalash/OmniVoice-Studio） は、Voicebox と同様に「ローカルの ElevenLabs 代替」を掲げるデスクトップアプリで、音声クローン・動画ダビング・リアルタイム口述・vocal isolation・話者分離を含む機能構成です。README ベースで比較すると、次のような差分があります。

• 言語カバレッジ: OmniVoice-Studio は TTS で 646 言語、STT で 99 言語（WhisperX 経由）を謳います。一方 Voicebox は 23 言語（7 エンジンの合計カバレッジ）で、代わりに各エンジンごとの品質差別化と切替を提供します。「多言語カバレッジ最優先」なら OmniVoice-Studio、「多言語もしっかりカバーしつつ、エンジンごとの品質差を選び分けたい」なら Voicebox、という整理が可能です。
• エージェント連携: OmniVoice-Studio は MCP サーバを内蔵しません。Voicebox は MCP を第一級インターフェースとして提供し、Claude Code / Cursor などのコーディングエージェントに音声出力を持たせる用途では明確に差別化されています。
• ネイティブランタイム: Voicebox は Tauri（Rust）で構築されている点を README で明示しています。「Electron ではない」ことを重視する層に向けたシグナリングが明確です。
• メンテナ体制: Voicebox は Spacedrive の作者が主導し、リポジトリメタでも pushed_at が本記事作成日直近になっています。単一メンテナ体制ではあるものの、更新頻度と開発の方向性は README・公式サイトから読み取りやすい状態です。

Coqui TTS（XTTS-v2）との比較

Coqui TTS（coqui-ai/TTS） は、音声クローン・多言語 TTS の「エンジン／ライブラリ」として広く採用されてきたプロジェクトです。特に XTTS-v2 は 17 言語対応の代表的なオープンモデルとして知られます。差分の要点は以下のとおりです。

• 範囲: Coqui TTS は「ライブラリ／モデル群」であり、GUI や OS 統合機能を持ちません。Voicebox は「エンジンを束ねたエンドユーザ向けアプリ」で、口述・キャプチャ管理・MCP サーバ・ペースト注入までを含みます。ライブラリとして自前のアプリに組み込みたい用途なら Coqui TTS、UI ごと一気に手に入れたい用途なら Voicebox、と考えるとわかりやすいです。
• ライセンス: Coqui XTTS-v2 は CPML（Coqui Public Model License、非商用寄り）で、加えて Coqui Inc. 自体が 2024 年に閉鎖されているため商用ライセンスの新規取得も難しい状態です。Voicebox 本体は MIT で商用フレンドリーですが、内部で使用する各 TTS エンジンのライセンスは個別に確認する必要があります。
• 入力側の統合: Coqui TTS は STT を持ちません。Voicebox は Whisper（Base / Small / Medium / Large / Turbo）を統合し、口述・LLM リファインメントまで一体化しています。
• エージェント連携: Coqui TTS には MCP サーバも標準 REST API 実装もありません。Voicebox はどちらも標準で備えます。

なお、参考として rhasspy/piper も類似の名前で言及されることがあります。Piper はエッジデバイスや Home Assistant への統合を主目的とした軽量 TTS ライブラリで、GUI・エージェント連携・音声クローンは持ちません。用途が明確に異なるため、Voicebox の代替候補として並列比較する対象にはなりにくい位置づけです。

どのケースで Voicebox 以外を選ぶべきか

比較の結論として、以下のようなケースでは Voicebox 以外を検討したほうが合理的です。

• 500 言語以上のカバレッジが必須な場合は、OmniVoice-Studio の方向性が近いです。
• 自前アプリに TTS ライブラリとして組み込みたい場合は、Voicebox のようなデスクトップアプリではなく、Coqui TTS（XTTS-v2）や別のライブラリ系 OSS の方が適合しやすいです。
• Linux でのバイナリ配布が必須の場合は、ビルド済みバイナリを提供している OSS を優先候補にしたほうが早いです。
• 軽量 CPU 環境でのエッジ実行が主目的の場合は、Piper のような軽量 TTS が向いています。

逆に、「音声 I/O を1つのアプリで完結させたい」「MCP エージェントに音声を持たせたい」「Apple Silicon / Windows / macOS Intel で GUI ごと導入したい」という要件が主軸なら、Voicebox は現時点で最有力候補の1つになります。

導入手順と利用の全体像

前述のとおり、本記事では動作検証は行いません。ここでは、README と公式ドキュメントに書かれている「導入と利用の全体像」を整理します。実際の導入時は、必ず公式ドキュメント docs.voicebox.sh と、必要に応じて README の Troubleshooting セクションを参照してください。

入手方法と対応プラットフォーム

• macOS（Apple Silicon）と macOS（Intel）は、それぞれ専用の DMG が voicebox.sh からダウンロード可能です。
• Windows は MSI が提供されています。
• Docker では docker compose up で起動できます。
• Linux はビルド済みバイナリの提供がなく、voicebox.sh/linux-install のソースビルド手順に従う必要があります。

初期導入時のコマンドラインでの手動セットアップは、Docker 構成を除いてほとんど必要ありません。バイナリを入手し、通常の GUI アプリと同様に起動する形が基本の流れになります。

初回起動時のセットアップフロー（macOS を例に）

README では、macOS の場合、初回起動時に Accessibility と Input Monitoring の権限フローがアプリ内ゲートとして提示されることが明記されています。これはグローバル口述機能（任意のテキストフィールドへの自動ペースト）を有効化するために必要な OS 側の権限です。deep-link で「System Settings」の該当画面に飛べるため、権限付与自体は難しくない導線が用意されています。

モデルのダウンロード先を変更したい場合は、環境変数 VOICEBOX_MODELS_DIR を利用して任意のディレクトリに切り替えることができます。モデルフォルダの移行はアプリ内で進捗が表示され、ダウンロードのキャンセル・クリアも UI で行えます。GPU バックエンド（Windows / Linux NVIDIA の CUDA バイナリ）は、アプリ内でオートダウンロードされる設計です。

Claude Code など MCP エージェントに Voicebox を接続する場合は、先ほど示したワンライナーで CLI 経由の登録が可能です。Cursor / Windsurf / VS Code MCP など HTTP MCP クライアントの場合は、標準の mcpServers 設定に URL を登録するだけで接続できます。

どんなプロジェクトに向いているか

ここまでの整理を踏まえて、Voicebox が特に価値を発揮するケースと、逆に向かないケースを対比で示します。裏テーマである「初見エンジニアの意思決定支援」に直結する節になります。

特に価値を発揮するユースケース

• コーディングエージェントの音声通知: Claude Code / Cursor / Cline などに voicebox.speak で通知を発話させ、開発体験を上げる用途では、MCP を第一級で備える Voicebox の設計優位が最も効いてきます。
• プライバシー要件の高い音声処理: 医療・法務・社外持ち出し禁止のコンテンツなど、音声データを社外に出せない用途では、ローカル実行が前提となる Voicebox が自然な選択肢になります。
• マルチエンジン切替が必要な音声制作: 高品質多言語クローン（Qwen3-TTS）、超軽量 CPU 実行（Kokoro / LuxTTS）、パラ言語タグ表現（Chatterbox Turbo）を、案件やシーンごとに切り替えたいケースに向きます。
• MCP 経由で任意のクライアントに音声 I/O を追加したい: 自作の CLI ツール、シェルスクリプト、独自のエージェントハーネスにも、REST API または stdio MCP から音声を組み込めます。

逆に向かないケース

• クラウド SaaS 品質を最重要視する商用制作: ElevenLabs 等の SaaS 品質と真正面から張り合う位置づけではありません。プロ音声制作のマスタリング用途では、まずは SaaS を軸に据える判断が現実的でしょう。
• Linux のバイナリ配布が必須のプロダクト: 現時点で Linux はソースビルドが前提のため、社内配布や顧客配布での Linux 対応が必須要件だと運用コストが上がります。
• モバイル対応が必須のユースケース: モバイルコンパニオンはロードマップに挙がっていますが、現時点でモバイルアプリの提供はありません。iOS / Android での動作を主軸に据えるなら、他候補を検討する必要があります。
• 500 言語超のカバレッジが必須: Voicebox は 23 言語（7 エンジン合計）です。極端に広い言語カバレッジが要件であれば、OmniVoice-Studio 等の別 OSS を優先することになります。

まとめ

本記事では、ローカル実行できるオープンソースの AI 音声スタジオ「Voicebox」（jamiepine/voicebox）について、README と公式ドキュメントに基づき、次の要点を整理しました。

• Voicebox は ElevenLabs（出力側）と WisprFlow（入力側）をローカルで代替することを狙う、Tauri ベースのデスクトップアプリです。日本語 TTS の VOICEVOX とは別プロダクトです。
• 7 つの TTS エンジン、Whisper ベースの STT、ローカル Qwen3 LLM、そして FastMCP による MCP サーバを 1 つのアプリに束ねている点が特徴です。
• 対応プラットフォームは macOS（Apple Silicon / Intel）と Windows がバイナリ配布、Docker が公式サポート。Linux は現時点でソースビルドが必要です。
• MCP サーバ経由で Claude Code / Cursor / Cline などのコーディングエージェントに音声出力を持たせる用途は、他 OSS には見られない差別化ポイントです。
• ライセンスは MIT。archived=false / fork=false / pushed_at=2026-07-02T23:12:35Z（本記事作成日直近）で、リポジトリメタ上は評価着手できる状態です。

初見のエンジニアが次に取るべきアクションは、GitHub リポジトリ と 公式ドキュメント を精読し、自環境（macOS / Windows / Linux、GPU 有無、MCP 連携先クライアント）で動作要件を満たすかを確認することです。公式サイトは voicebox.sh にあり、DMG・MSI・Docker の配布状況および Linux 向けビルド手順はこちらから確認できます。