VOICEVOXの処理をCLI化──ニュース音声をバックエンドで処理

毎朝5時、デスクのMacが静かに動き出し、ニュースの収集とラジオ音声の書き出しを自動で行ってくれています。

起きて画面を開いたとき、すでにその日の音声ができあがっているのは便利なのですが、ここ最近、ずっと気になっている小さな違和感がありました。

作業スペースの片隅に、いつの間にかVOICEVOXの画面アプリが立ち上がったまま残っているのです。

実用上、何かが壊れているわけではありません。
けれど、ただ音声を書き出すだけのバッチ処理のために、毎回GUIウィンドウが開き、そのままメモリを抱え込み続ける様子を見ていると、「裏側のエンジンだけを呼べないものだろうか」と感じていました。

結論から言うと、Mac版のVOICEVOXアプリには画面を介さずに音声合成APIだけを提供する実行ファイルが標準で同梱されており、呼び出し元を切り替えるだけで完全なヘッドレス動作が可能でした。

さらに、同じ原稿を使って「画面アプリ経由」と「ヘッドレス経由」で音声を再生成して比較したところ、生成されたMP3ファイルのハッシュ値（SHA-256）はバイト単位で完全一致し、メモリ消費量（常駐メモリの合計）は平均で約847 MiB削減できることが分かりました。

今回は、なぜ画面アプリが立ち上がっていたのかという原因の特定から、ヘッドレス化の手順、そして実際に同じ原稿で音声を再生成して行った比較検証の記録を整理しておきたいと思います。

なぜ、毎朝VOICEVOXの画面が立ち上がっていたのか

私の環境では、毎朝5時にLaunchAgentがPythonスクリプトを呼び出し、RSSなどからピックアップしたニュースを読み上げ原稿に仕立て、ローカルのVOICEVOXに投げて音声ファイル（MP3）を生成しています。

この処理コードを改めて確認してみたところ、音声を生成する直前の接続判定に原因がありました。

スクリプト側では、まずVOICEVOXのAPIポート（通常は http://127.0.0.1:50021）にアクセスし、エンジンが待機しているかを確認します。もし応答がなければ、次のようなコマンドを実行する設計になっていました。

subprocess.run(["open", "-a", app_name], ...)

つまり、事前にエンジンが立ち上がっていない場合は、macOSの通常起動コマンドを使って「VOICEVOXのアプリ本体」を起動していたわけです。

これによってAPIの応答が得られるようにはなるのですが、当然ながら画面上のウィンドウやDockアイコン、付随するUIプロセスまで一式立ち上がってしまいます。

自動化のバッチ処理としては、音声合成用のAPIサーバーだけがバックグラウンドで動いてくれれば十分です。

そこで、VOICEVOX公式のリポジトリやドキュメントを調べてみたところ、macOS向けのアプリパッケージ内に、CUI（CLI）で直接叩けるエンジンバイナリが含まれていることが分かりました。

私のMac環境を確認すると、次のパスにエンジン実行ファイルが存在していました。

/Applications/VOICEVOX.app/Contents/Resources/vv-engine/run

実際にターミナルから --help を付けて叩いてみると、待受ホスト（--host）やポート（--port）を指定して起動できることが確認できました。
バージョンを確認するAPI（/version）を叩いたところ、0.25.2 という応答が返ってきます。

わざわざ別のDockerコンテナや外部パッケージを用意しなくても、手元のアプリパッケージの中身を直接呼ぶだけでヘッドレス化できる道筋が見えました。

画面を出さずにエンジンだけを起動・終了させる仕組みへ

仕組みが分かれば、スクリプト側の変更はとてもシンプルです。

APIが応答しなかった場合のフォールバック先を、従来の open -a VOICEVOX から、アプリ内のエンジン直接起動へと書き換えました。

/Applications/VOICEVOX.app/Contents/Resources/vv-engine/run \
  --host 127.0.0.1 \
  --port 50021

安全のために、待受ホストは外部からのアクセスを受け付けない 127.0.0.1（ローカルホスト）に限定しています。

また、運用の作法として次の点も考慮しました。

• 今回のスクリプト自身が起動したエンジンの場合のみ、音声生成が完了した後に責任を持ってプロセスを終了する

• もし作業中などで、すでに別のVOICEVOX（画面アプリや常駐エンジン）が動いていた場合はそのAPIを利用し、処理完了後も勝手に終了させない

これにより、「朝のバッチ処理のときだけ裏でエンジンが立ち上がり、音声を書き出したら綺麗に片付いて去っていく」という、本来あるべき自動処理の挙動が作れました。

いきなり本番環境を上書きするのではなく、まずは別の一時ポート（50121）を使って「動作確認です。」という短い文字列を合成し、問題なくWAVファイルが返ってくること、そして処理終了後にエンジンプロセスが綺麗に消えることを確認しました。

本当に同じ音声が作れているのか？ 3本のファイルを厳密に比較した

ヘッドレス化によって画面が立ち上がらなくなったとしても、もし音声のイントネーションが変わったり、音質が劣化してしまっては本末転倒です。

そこで、今朝（2026年9月26日）の朝に実際に作成されていた本番のニュース原稿を使って、検証を行うことにしました。

比較に用いた原稿の規模は次の通りです。

• 原稿文字数: 4,776文字

• 音声合成チャンク数: 33個

• 仕上がりの音声長: 約13分58秒（838秒）

比較対象として、以下の3つの条件で書き出したファイルを用意しました。

1. 今朝5時にGUIアプリ経由で自動生成されていた元ファイル

2. 変更後のヘッドレス方式で再生成したファイル

3. CPUとメモリを計測するために、改めてGUIアプリを立ち上げて再生成したファイル

これら3本の音声ファイルに対して、ハッシュ値（SHA-256）を算出して比較してみました。

fe6bd5288f9df2d0f27fb8ac7972c8ecf5bf40a86706c13b6ae70fad1dab13d1

結果として、3ファイルすべてのハッシュ値が完全に一致しました。

ビットレート（約64 kb/s）やサンプリングレート、ファイルサイズ（6,707,565バイト）はもちろんのこと、データとして1バイトの狂いもなく全く同一の音声が出力されていたことが確認できました。

UIを介さず直接エンジンを叩いても、音声合成の計算ロジック自体には何の影響もないことが数値として裏付けられた形です。

CPUとメモリの負荷はどう変わったか

続いて、14分近い音声合成を行っている最中のシステム負荷を比較しました。

処理を実行している間、1秒間隔でプロセスの状況を監視し、CPU使用率と常駐メモリ（RSS）を計測しています。

なお、GUIアプリ方式ではElectronベースのUIプロセスやヘルパープロセスが複数立ち上がるため、VOICEVOX関連の全プロセスの数値を合計して集計しています。

両方式の計測結果をまとめると、以下のようになりました。

この結果を見てみると、いくつかの興味深い事実が浮かび上がってきます。

まず、CPU使用率については平均・最大ともにほぼ差がありませんでした。どちらも440%前後の高い数値を示していますが、これは音声合成のディープラーニング推論処理が複数のCPUコアをフルに使って計算しているためです。計算自体の重さは、画面の有無にかかわらず同等だと言えます。

一方で、明確な違いが出たのがメモリ消費量でした。

GUIアプリ方式では、Electronによる画面描画や複数プロセスの管理オーバーヘッドが乗るため、平均して約2.1 GiBのメモリを消費していました。これがヘッドレス方式になると、エンジン単体（1プロセス）の約1.25 GiBに収まっています。

平均で約847 MiB、率にして40%以上のメモリが浮いた計算になります。

処理時間についてもヘッドレス方式の方が約9秒短くなっていますが、これは測定回数が各1回のため、OSのキャッシュやバックグラウンド処理のブレが含まれている可能性があります。
ただ、余計な描画処理を抱え込まない分、身軽に動けている印象はあります。

何より、朝の作業開始時に「使っていない巨大なGUIアプリが画面に残っていない」という精神的な快適さは、数字以上のメリットだと感じています。

自動化の足回りを整えるときに意識しておきたいこと

今回の検証を通じて、手元のMacで動く自動化処理について改めて考えさせられたことがあります。

日常の作業を楽にするために組んだ自動化スクリプトが、いつの間にかマシンのリソースを圧迫していたり、画面上に不要なウィンドウを残して集中を削いでしまうのは、少しもったいない状態です。

ツールがGUIを備えていると、私たちはどうしても「画面を開いて操作する」前提で設計してしまいがちですが、内部でAPIサーバーとして動いているツールの場合、実は裏側のエンジンだけを直接呼び出せる口が用意されていることが少なくありません。

ただし、今回の検証結果についても、いくつか留意しておくべき点があります。

今回の音声ハッシュの完全一致は、あくまで「同一のマシン環境、同一の原稿、同一バージョンのVOICEVOX（0.25.2）」という条件下で観測できた事実です。
VOICEVOXのバージョンが変わったり、モデルやパラメータ設定が異なる環境でも完全にバイト単位で一致するかどうかまでは保証できません。

また、今回は手動実行での検証を終えた段階であり、明日の朝5時にLaunchAgentのタイマーから本番バッチとして問題なく完走するかどうかは、明日のログを確認して初めて完了となります。

道具の仕組みを一段だけ深く覗いてみて、不要な画面やリソースを削ぎ落としていく。そうした地道な手入れを重ねることで、毎日の自動化環境が少しずつ静かで堅牢なものになっていくのだと思います。

次はこれをどうぞ
毎朝のルーティンを支える自作ツールが止まったとき、裏側の仕組みをどう観察し付き合っていくか。個人開発の自動化に共通する視点をまとめています。

現場の業務自動化やAIツールの活用相談について、詳しくは【自己紹介・お仕事のご相談】をご覧ください。

もし少しでも参考になりましたら、下の「スキ（♡）」を押していただけると、次の記事執筆や検証の大きな励みになります！