ARM64版voicevoxを作る場合にやること調査結果

report_claude.md

Arm64 Windows版VOICEVOXビルド調査

調査の対象

Arm64版WindowsでVOICEVOXを動かすために、どのリポジトリで何を変更すればよいかを調査した。

対象は voicevox（エディター）、voicevox_engine、voicevox_core、onnxruntime-builder、voicevox_additional_libraries の5リポジトリである。 調査の過程で、voicevox_core が依存する open_jtalk-rs と、voicevox_engine が依存する kanalizer、pyopenjtalk、pyworld、soxr も対象に含めた。 これらはVOICEVOXのビルドが実際に通るかどうかを左右する依存先であり、5リポジトリ側の変更だけでは完結しないためである。

各リポジトリのGitHub Actionsワークフロー、ビルドスクリプト、依存クレートやパッケージの実装を読み、次の3点を確認した。

• 各リポジトリが互いにどう連携しているか
• Arm64 Windows向けのビルドが既に存在するか
• 存在しない場合、追加することが技術的に見込めるか

結論

5リポジトリすべてのワークフローファイルを検索したが、Arm64 Windows向けのビルドはどこにも存在しない。 windows-arm64 に相当するmatrixエントリは一件も見つからなかった。

GitHub Actionsは windows-11-arm という名前でArm64 Windowsのホスト型ランナーを提供しており、プレビュー表記が外れた一般提供の状態にある。 このランナーにはVisual Studio 2022のArm64向けMSVCツールチェイン、Rust、Python、Node.js、NSISがあらかじめ入っており、Arm64バイナリをネイティブにビルドできる。 この基盤がある上で5リポジトリそれぞれの追加コストを調べたところ、onnxruntime-builder と voicevox（エディター）はごく小さな変更で対応できる見込みが高い。 voicevox_core も、生成物のダウンロード機構がOSとCPUアーキテクチャの組み合わせに対して汎用的に作られているため、大きな障害は見当たらなかった。

一方 voicevox_engine は、PyInstallerを自前ビルドする際のスクリプトがx64決め打ちになっている点、そして pyworld、soxr、kanalizer がArm64 Windows向けの配布物を持たない点で、実際にビルドを試さないと判断できない部分が残る。 voicevox_additional_libraries は、DirectMLについては対応の見込みが高い一方、CUDAはそもそもNVIDIAがWindows ARM64向けのCUDA Toolkitを提供していないため対象から外れる。

リポジトリ間の関係

onnxruntime-builder は、Microsoftの microsoft/onnxruntime を独自パッチを当ててビルドし、OSとCPUアーキテクチャとデバイスの組み合わせごとに動的ライブラリをGitHub Releasesへ公開する。

voicevox_core はRust製のコアライブラリであり、open_jtalk-rs をCargo依存として組み込む。 C APIは実行時に onnxruntime-builder が公開したライブラリを動的読み込みする方式を取っており、ビルド時点ではONNX Runtimeの実体を必要としない。 voicevox_core はC API、Pythonホイール、Java向けライブラリ、そして環境に応じて必要なファイル一式を取得する専用のダウンローダー実行体を公開する。

voicevox_engine はPython製で、このダウンローダーを使って voicevox_core のC API、ONNX Runtime、追加ライブラリ、音声モデルを取得する。 pyopenjtalk（VOICEVOXによるフォーク）、pyworld、soxr、kanalizer をPython依存として組み込み、PyInstallerで単一の実行ファイルにまとめる。

voicevox（エディター）はElectron製アプリケーションであり、voicevox_engine のビルド成果物をサブプロセスとして同梱し、electron-builderでインストーラーを作る。

voicevox_additional_libraries は、CUDAやDirectMLなどGPU利用時にのみ必要になる再配布用ライブラリを用意するリポジトリであり、voicevox_core のダウンローダーから間接的に参照される。

VOICEVOXの内部では、動作対象を os-arch-device の組で表す Runtime Target という呼び方が使われている。 arch の値としてはすでに x64、x86、arm64 が定義されており、arm64 自体は目新しい値ではない。 今回の調査対象は、この組のうち os が windows で arch が arm64 となる組み合わせをどう成立させるかという話に相当する。

onnxruntime-builder

onnxruntime-builder の build.yml は、matrixの各行にOSとビルドオプションを列挙する構成になっている。 Windows向けの既存の行は win-x64、win-x64-dml、win-x64-webgpu、win-x64-cuda、win-x86 であり、いずれも windows-2022 を使う。

Microsoft公式のONNX Runtime NuGetパッケージを確認したところ、voicevox_core が指定するのと同じv1.23.2で win-arm64 のランタイムがすでに配布されている。 PyPIのonnxruntimeパッケージも、Python 3.11以降について win_arm64 のwheelを配布している。 ONNX Runtime自体がArm64 Windowsを既知の対象として扱っていることの裏付けになる。

追加できそうなデバイスとできなさそうなデバイスがある。 DirectMLは、後述のとおりArm64向けのバイナリがNuGetパッケージに含まれているため、win-arm64-dml を足せる見込みがある。 CUDAは、NVIDIAがWindows ARM64向けのCUDA Toolkitを提供していないため、win-arm64-cuda に相当する行は成立しない。 WebGPUについては、Windows arm64向けのDawnバックエンドが実際にビルドできるかどうかまでは確認できておらず、要検証として扱う。

voicevox_core

build.yml のmatrixにWindows向けの行を足すこと自体に大きな障害はない。 Rustの aarch64-pc-windows-msvc はTier 2としてホストツール込みで提供されており、voicevox_core が固定するRust 1.96.0でも問題なく使える。

成果物を配布するダウンローダー実行体は、OSとCPUアーキテクチャを Os と CpuArch という列挙型で表しており、アーキテクチャ名は x86、x64、arm64 の3値である。 アーティファクト名の組み立ては format!("{C_API_LIB_NAME}-{os}-{cpu_arch}-{tag}.zip") のようにOSとアーキテクチャを機械的に組み合わせるだけであり、Android向けの一箇所を除けばOSごとの特別扱いがない。 そのため Os::Windows と CpuArch::Arm64 の組み合わせは、コードを変更しなくても windows-arm64 という自然な名前になる。 build.yml 内でPythonホイール用のインタプリタのアーキテクチャを決める処理も、すでに ARM64,aarch64-* という汎用的な条件分岐になっており、Windows向けのArm64ランナーを想定していなくても自然に対応できる形になっている。

一方で、確実に手を入れる必要がある箇所が2つある。

• deny.toml の graph.targets は build.yml のターゲット一覧と一致している必要があり、check-release-target-tuples.yml が一致を検査している。 aarch64-pc-windows-msvc を両方に追加する必要がある。
• voicevox_core はPython 3.10でPythonホイールをビルドしているが、actions/setup-pythonが提供するWindows Arm64向けのPythonビルドはPython 3.11以降のみである。 ただし voicevox_core_python_api は abi3-py310 を使っているため、ビルド時のPythonを3.11以降に上げても、生成されるホイールはPython 3.10以降で動作する。 実害のない変更で済む。

voicevox_core はC APIのビルド時にONNX Runtimeの実体を必要としない設計であるため、onnxruntime-builder 側の対応を待たずに voicevox_core 単体のビルドを先に進めることもできる。

voicevox_core は生成物を配布するための独立したダウンローダー実行体も持っており、build-downloader.yml でRustのターゲットごとにビルドしている。 現状はWindows向けに x86_64-pc-windows-msvc しかなく、こちらにも aarch64-pc-windows-msvc を足す必要がある。 また download_test.yml はこの一覧とは独立したテスト用matrixを持っており、そちらにもArm64 Windows向けの行と、ダウンローダー名を決める分岐への追加が必要になる。

open_jtalk-rs

voicevox_core はOpenJTalkのRustバインディングとして open_jtalk-rs に依存しており、こちらにも変更が要る。

open_jtalk-sys はビルド時にbindgenで生成したCバインディングを使うが、生成にはビルド対象ごとのCコンパイラ環境が要るため、事前生成した bindings.rs を src/generated/<os>/<arch>/ 以下にコミットしておき、通常のビルドではそれを使う仕組みになっている。 このディレクトリを確認したところ、windows/x86 と windows/x86_64 はあるが windows/aarch64 は存在しない。

生成の仕組み自体は自動化されている。 gen_bind.yml はターゲットごとに cargo build --features generate-bindings を実行し、生成された bindings.rs を自動でプルリクエストにする auto_gen_bind_pr アクションを呼び出す。 このmatrixに windows-11-arm と aarch64-pc-windows-msvc の組を1行足せば、既存の仕組みに乗るかたちで windows/aarch64/bindings.rs を生成できる見込みが高い。

voicevox_engine

build-engine.yml のビルド機構は voicevox_core のダウンローダーに乗る形で作られており、matrixに os: windows-11-arm、architecture: arm64 の行を足すこと自体は他リポジトリと同様に難しくない。

手を入れる必要がある箇所がいくつかある。

• tools/modify_pyinstaller.bash は、ウイルス判定回避などを目的にPyInstallerのブートローダーを自前ビルドし直すスクリプトだが、--msvc_targets="x64" とアーキテクチャを決め打ちしている。 PyInstaller本体はArm64向けのブートローダービルドに対応しており、実際に固定版の6.20.0でも win_arm64 のwheelがPyPIに配布されている。 --msvc_targets にArm64を含めるよう変更する必要がある。
• pyproject.toml は requires-python == 3.11.9 と固定しているが、Python 3.11はWindows Arm64向けのビルドがすでに存在するため、Pythonのバージョン自体は変更しなくてよい。

依存パッケージのうち、PyPIでArm64 Windows向けのwheelを配布していないものが3つある。

• pyworld==0.3.5 には win_arm64 のwheelがない。 ソース配布物を確認したところ、x86固有のSIMD命令に依存するコードは見当たらなかった。 ソースからのビルド自体は通る可能性が高いが、実際に試していないため要検証とする。
• soxr==1.1.0 にも win_arm64 のwheelがない。 こちらはソースの詳細までは確認しておらず、通るかどうかは要検証とする。
• kanalizer==0.1.1 にも win_arm64 のwheelがない。 これはVOICEVOX自身が持つRust製ライブラリであり、kanalizer リポジトリの build_and_deploy_infer.yml で公開している。 すでに windows-2019 のビルドに i686-pc-windows-msvc を追加ターゲットとして加えている実績があり、同様に aarch64-pc-windows-msvc を追加ターゲットとして加えれば対応できる見込みが高い。

pyopenjtalk はVOICEVOXによるフォークをgit依存として取得し、エンジンのビルド時にソースからコンパイルしている。 open_jtalk-rs と同様にC++コードをArm64 MSVCでビルドすることになるが、こちらは手元にリポジトリがなく実装を確認できていない。 open_jtalk-rs 側で問題が出ていない以上大きな障害は考えにくいが、この点も要検証として扱う。

voicevox（エディター）

build.yml のWindows向けの行は現状 windows-2022 の1系統のみであり、これはmatrixに行を足すだけで済む。

Electron側の設定は build/electronBuilderConfig.ts にあり、LinuxとmacOSの target は次のように実行環境のアーキテクチャに応じて arm64 と x64 を切り替えている。

const isArm64 = process.arch === "arm64";
// ...
linux: {
  target: [{ target: "AppImage", arch: [isArm64 ? "arm64" : "x64"] }],
},

一方Windowsの win.target だけは次のように x64 を決め打ちしている。

win: {
  target: [{ target: "nsis-web", arch: ["x64"] }],
},

LinuxやmacOSと同じ isArm64 ? "arm64" : "x64" の形に揃えるだけで、windows-11-arm ランナー上では自動的にArm64向けのビルドになる見込みが高い。

Electron自体は42.1.0という固定バージョンを使っており、Arm64 Windows向けのビルドをすでに公式に配布している。 electron-builderもArm64 Windows向けのnsis-webターゲットに対応している。 package.json の依存関係を確認したところ、プラットフォームごとのプリビルドバイナリを要求するようなネイティブNodeモジュールは見当たらなかった。 Electron本体とビルド設定さえ対応すれば、追加の障害は少ないと見てよい。

voicevox_additional_libraries

download_and_deploy.yml はCUDA・cuDNNとDirectMLをそれぞれ別ジョブで取得し、voicevox_core のダウンローダーが参照できる形で配布している。

DirectMLについては、実際に使っているMicrosoft.AI.DirectMLのNuGetパッケージの中身を展開して確認したところ、バージョン1.15.4の時点ですでに bin/arm64-win/DirectML.dll が含まれている。 現在Windows向けの行は platform: x64-win のみであり、platform: arm64-win の行を足すだけで取得自体は成立する見込みが高い。 ただしArm64版Windows機の実機でDirectMLが実際に動作するかどうかは、対象デバイスのGPUドライバに依存するため未確認である。

CUDAについては、NVIDIAがWindows ARM64向けのCUDA Toolkitを提供していない。 Windows ARM64を採用するデバイスの多くがNVIDIA製の単体GPUを搭載していないこととも整合しており、この経路は対象から外してよい。

残る不確定要素

実装を読むだけでは判断できず、実際にビルドを試す必要がある項目を挙げる。

• pyworld、soxr、pyopenjtalk がソースからArm64 MSVC向けにビルドできるかどうか
• onnxruntime-builder でWebGPUバックエンドがArm64 Windows向けにビルドできるかどうか
• DirectMLが実際のArm64版Windows機で動作するかどうか

今後の進め方

onnxruntime-builder と voicevox_core は、依存先の問題が少なく、既存のCIパターンをなぞるだけで着手しやすい。 voicevox（エディター）も変更箇所が明確で、着手しやすい部類に入る。 voicevox_engine は pyworld、soxr、kanalizer のビルド可否が読めば読むほど焦点になるため、まずこの3つを実際にArm64 Windows向けにビルドしてみて、通るかどうかを確認するところから始めるとよい。

report_codex.md

Windows Arm64 版 VOICEVOX のビルド調査

調査日は 2026 年 7 月 25 日である。 本書では、Windows Arm64 上でネイティブ実行する VOICEVOX エディター、エンジン、コア、ONNX Runtime を対象とする。 ビルド時だけ使う x64 ツールと、製品に同梱される x64 実行ファイルは区別して評価する。

調査対象

主要リポジトリの既定ブランチと公開リリースを調査した。 製品経路を成立させるため、open_jtalk-rs と公式サイトの voicevox_blog も調査対象に加えた。

リポジトリ	調査したリビジョン	役割
VOICEVOX/voicevox	44da02060f84b763ef946ae72ea04de265ff38f1	Electron 製エディターと配布物を作る
VOICEVOX/voicevox_engine	c7106719c01641ced42869ef35b17bbd9ffe6f74	Web API と PyInstaller 製エンジンを作る
VOICEVOX/voicevox_core	d00cffac38a1420eba74e4a313e3a10cb9e16fc8	Rust 製推論 API とダウンローダーを作る
VOICEVOX/onnxruntime-builder	e6acb6a3a402d4ecef3d853b0f9cec3e35762834	VOICEVOX 用 ONNX Runtime を作る
VOICEVOX/voicevox_additional_libraries	2df46bb55a84bbbd01bba42bd07c82f8b743e4e0	DirectML と CUDA の再配布物を作る
VOICEVOX/open_jtalk-rs	コアが固定する 7c87b4227bb005b439a3ad473b48ce8975829576	コアが使う Open JTalk の Rust バインディングを作る
VOICEVOX/voicevox_blog	1bb1c782e2d1c01a02376d0fef5295b7ed1e408b	公式ダウンロード画面と初回起動用エンジン情報を配信する

voicevox_onnxruntime の製品用ソースは非公開である。 公開リポジトリから確認できるビルド処理と公開 ONNX Runtime を調査し、非公開差分は未確認事項として残した。

結論

調査した公開リリースには Windows Arm64 成果物が存在しない。 安定版だけでなく、現在のプレビュー版と開発版でも該当成果物を確認できなかった。

対象	既存の Windows Arm64 成果物	実現性	主な条件
ONNX Runtime CPU	なし	高い	Arm64 ジョブと製品用非公開差分の検証が必要
ONNX Runtime DirectML	なし	高い	Arm64 ジョブと実機 GPU 検証が必要
追加ライブラリ DirectML	なし	高い	NuGet 内の arm64-win を梱包すればよい
VOICEVOX コア	なし	高い	open_jtalk-rs の生成済みバインディング追加が必要
VOICEVOX エンジン CPU	なし	中から高	Python ネイティブ依存のソースビルド検証が必要
VOICEVOX エンジン DirectML	なし	中から高	CPU 版の条件に DirectML 実機検証が加わる
VOICEVOX エディター	なし	高い	7-Zip、typos、NSIS 周辺の Arm64 対応が必要
Windows Arm64 CUDA	なし	成立しない	NVIDIA が Windows Arm64 用 CUDA 一式を配布していない

最初の到達点は CPU 版が適している。 CPU 版でコアからエディターまでの製品経路を通した後に、同じコアとエディターへ DirectML 版エンジンを追加できる。 CUDA 版は対象から外す必要がある。

製品の主要実行ファイルを Arm64 にすることは可能である。 ただし、electron-builder が作る NSIS セットアップ実行ファイルは x86 系の NSIS ランタイムを使う可能性が高い。 Windows on Arm のエミュレーションでインストールできる見込みはあるが、セットアップ実行ファイルまで完全な Arm64 にする要件とは分ける必要がある。 ZIP 配布物なら、NSIS の制約を受けずに Arm64 製品を先に検証できる。

リポジトリ間の連携

製品経路とは、利用者がエディターを入手して音声を生成するまでに使う成果物の流れを指す。 製品経路は次の順序でつながっている。

1. onnxruntime-builder が voicevox_onnxruntime.dll を公開する。
2. voicevox_additional_libraries が DirectML 版で必要な DirectML.dll を公開する。
3. open_jtalk-rs がコアに組み込まれる Open JTalk バインディングを提供する。
4. voicevox_core が voicevox_core.dll とダウンローダーを公開する。
5. コアのダウンローダーが、コア、ONNX Runtime、DirectML、音声モデル、辞書を集める。
6. voicevox_engine が集めた成果物を PyInstaller の実行ファイルへ同梱し、7z と VVPP を公開する。
7. voicevox が Electron アプリへエンジンを埋め込むか、初回起動時に VVPP を取得するエディターを公開する。
8. voicevox_blog が公式ダウンロードリンクと latestDefaultEngineInfos.json を配信する。

ONNX Runtime の選択はファイル名だけに依存していない。 onnxruntime-builder はリリース本文へ OS、CPU アーキテクチャ、デバイス、成果物名を表す仕様表を埋め込む。 コアのダウンローダーはその表を解析し、Windows、AArch64、CPU または DirectML に合う成果物を選ぶ。

追加ライブラリの選択は規則的なファイル名に依存する。 ダウンローダーは DirectML 版で DirectML-windows-arm64.zip を探す。 したがって、追加ライブラリ側の artifact_name を windows-arm64 にすれば既存のダウンローダー実装と一致する。

エンジンの公開成果物は 7z と VVPP の二種類である。 エディターの埋め込みビルドは 7z の分割ファイル一覧を読み、対象ディレクトリを vv-engine へ配置する。 初回起動方式のエディターは latestDefaultEngineInfos.json から VVPP を選び、インストールする。

voicevox_resource と voicevox_vvm はこの流れにも含まれる。 前者は README、規約、画像などを供給し、後者は推論用音声モデルを供給する。 いずれもアーキテクチャに依存しないため、Windows Arm64 のためのコード変更は不要である。 ただし、各リリースが参照するバージョンは既存の更新手順どおり同期する必要がある。

既存成果物の確認

エディターの 0.25.2 と 0.26.0-preview.0 には Windows x64、Linux Arm64、macOS Arm64 の成果物がある。 Windows Arm64 の ZIP、インストーラー、事前梱包物はない。

エンジンの 0.25.2 と 0.26.0-preview.0 には Windows CPU、DirectML、NVIDIA の成果物がある。 これらの Windows 成果物は windows-2022 の x64 ジョブで作られており、Windows Arm64 成果物ではない。

コアの 0.16.4 と現在の開発リリースには windows-x64 と windows-x86 がある。 windows-arm64 の C API、Python wheel、Java ライブラリ、ダウンローダーはない。

ONNX Runtime Builder の voicevox_onnxruntime-1.17.3 と voicevox_onnxruntime-1.23.2 には Windows x64 と Windows x86 の成果物がある。 Windows Arm64 の CPU 版と DirectML 版はない。

追加ライブラリの 0.2.1 と 0.3.0 には Windows x64 の DirectML と CUDA がある。 Windows Arm64 の DirectML はない。

過去にはコアのプルリクエスト 91 で Windows Arm64 環境のビルド問題が修正されている。 この修正は当時の Open JTalk 周辺を改善したものであり、現在のリリース成果物や現在の依存関係まで Windows Arm64 対応にするものではない。

GitHub Actions の Windows Arm64 環境

GitHub-hosted runner には windows-11-arm ラベルがある。 2026 年 7 月時点ではパブリックプレビューであり、公開リポジトリから利用できる。

現在のランナーイメージには Visual Studio 2022、Arm64 用 MSVC、Windows SDK、CMake、Ninja、Rust、Node.js、7-Zip が入っている。 主要リポジトリは公開されているため、セルフホストランナーを最初から用意する必要はない。

Windows Arm64 ランナーには Python 3.10 が用意されていない。 actions/python-versions にも Windows Arm64 版 Python 3.10 の成果物はない。 一方、Python 3.11.9 には python-3.11.9-win32-arm64.zip があり、actions/setup-python の architecture: arm64 で利用できる。

この差はコアと ONNX Runtime Builder に影響する。 両リポジトリは現在 Python 3.10 を指定しているため、Windows Arm64 ジョブだけでも Python 3.11.9 へ変更する必要がある。

ONNX Runtime Builder

現在の機構

.github/workflows/build.yml の行列が OS、CPU、実行プロバイダーごとの共有ライブラリを作る。 公開 onnxruntime と製品用 voicevox_onnxruntime は同じワークフローを使う。 製品用ビルドでは公開 ONNX Runtime を取得した後、非公開タグへ切り替えて prepare.bash を実行する。

エンジンとコアが現在使うバージョンは 1.17.3 である。 一方、ONNX Runtime Builder の現在の既定値は 1.23.2 である。 Windows Arm64 対応だけを切り分けるなら、最初は 1.17.3 を維持した方が変更範囲を限定できる。

Windows Arm64 が成立する根拠

Microsoft の ONNX Runtime 1.17.3 と 1.23.2 は公式に onnxruntime-win-arm64 を公開している。 ONNX Runtime 1.17.3 のビルドスクリプトは、Arm64 Python から実行された場合に platform.machine() を検出し、Visual Studio の ARM64 ターゲットを選ぶ。

ONNX Runtime 1.17.3 の公式 Azure Pipelines には DirectML の Windows Arm64 ビルドがある。 そのビルドは --arm64 --use_dml を使い、win-dml-arm64 成果物を作る。 DirectML のリンク先も arm64-win を選べるように実装されている。

必要な変更

windows-11-arm を使う CPU 行と DirectML 行を追加する。 成果物名は voicevox_onnxruntime-win-arm64 と voicevox_onnxruntime-win-arm64-dml が既存規則に合う。 仕様表には spec_os: Windows と spec_arch: AArch64 を設定する。

Python は 3.11.9 と architecture: arm64 を明示する。 ネイティブ Arm64 ランナーでは --arm64 を付けず、ビルドスクリプトにホストを検出させる方法が使える。 この方法なら ONNX Runtime がビルドをクロスコンパイル扱いせず、Arm64 上でテストを実行できる。

現在のワークフローは --update と --build を明示しているため、テストを自動では実行しない。 Arm64 行へ --test を追加するか、生成した DLL を使う個別の推論テストを追加する必要がある。

Windows ジョブで tree を入れるためだけに使う MSYS2 は Arm64 行から外せる。 ランナー標準の PowerShell か tree.com でビルドディレクトリを表示すれば、ONNX Runtime のビルド条件に影響しない。

1.17.3 を再ビルドするときは、現在の既定ブランチをそのまま使えない。 現在のパッチ群には 1.23.2 専用パッチがあり、1.17.3 へ無条件適用すると失敗する。 voicevox_onnxruntime-1.17.3 タグが指す Builder の dad0da0e4167eb26e0405b1ed6289f31bdfb5cac から作業を始めるか、パッチ適用を ONNX Runtime のバージョン別に分ける必要がある。

製品用 voicevox_onnxruntime の非公開差分は確認できていない。 公開 ONNX Runtime が Windows Arm64 を作れることは確認できたが、非公開差分のコンパイル可否は製品用 CI を実行して確かめる必要がある。

DirectML と CUDA

ONNX Runtime 1.17.3 が使う DirectML は 1.13.1 である。 Microsoft.AI.DirectML の 1.13.1 には bin/arm64-win/DirectML.dll と DirectML.lib が入っている。 現在の ONNX Runtime 1.23.2 系が使う DirectML 1.15.4 にも同じ Arm64 成果物がある。

Windows Arm64 CUDA 行は追加できない。 現在の CUDA と cuDNN の URL は windows-x86_64 を指し、Windows Arm64 用ツールキットと再配布 DLL がないためである。

VOICEVOX 追加ライブラリ

現在の機構

.github/workflows/download_and_deploy.yml が CUDA と DirectML を別ジョブで収集する。 DirectML ジョブは NuGet パッケージから指定プラットフォームの DirectML.dll を取り出し、ライセンスと一緒に ZIP へ入れる。

CPU 版は追加ライブラリを使わない。 したがって、このリポジトリの変更は DirectML 版を作る段階で必要になる。

必要な変更

DirectML の行列へ platform: arm64-win と artifact_name: windows-arm64 を追加する。 出力名は DirectML-windows-arm64.zip となり、コアのダウンローダーが現在生成する名前と一致する。

ONNX Runtime 1.17.3 を維持する場合は、DirectML 1.13.1 を使う 0.2.1 系から新しいリリースを作る。 たとえば 0.2.2 を公開し、エンジン側の追加ライブラリ版を更新する。

ONNX Runtime を 1.23.2 へ更新する場合は、DirectML 1.15.4 を使う 0.3.0 系へ Arm64 行を加える。 ONNX Runtime と DirectML の系列を混ぜず、同じ ONNX Runtime 版が要求する DirectML を選ぶ必要がある。

Open JTalk の Rust バインディング

open_jtalk-rs は Windows Arm64 コアを阻む必須の上流依存である。 コアの C API も Open JTalk をコンパイルするため、Python API と Java APIを無効にしてもこの問題は残る。

open_jtalk-sys は OS と CPU ごとの生成済みバインディングを include! で読み込む。 Linux Arm64、macOS Arm64、Android Arm64 はあるが、Windows Arm64 の分岐とファイルがない。 この状態で aarch64-pc-windows-msvc を追加すると、Open JTalk の CMake ビルドより後の Rust コンパイルで必要なシンボルが定義されない。

次の変更が必要になる。

• .github/workflows/gen_bind.yml に windows-11-arm と aarch64-pc-windows-msvc を追加する。
• .github/workflows/test.yml に同じターゲットのビルドとテストを追加する。
• crates/open_jtalk-sys/src/generated/bindings.rs に Windows と aarch64 の分岐を追加する。
• generate-bindings 機能で src/generated/windows/aarch64/bindings.rs を生成して保存する。
• コアが参照する open_jtalk-rs のリビジョンを更新する。

Open JTalk 本体の C と C++ コードには Windows Arm64 を明示的に拒む分岐を確認できなかった。 生成済みバインディングを追加した後は、MSVC と CMake の実ビルドで最終確認できる。

VOICEVOX コア

現在の機構

コアは Rust のワークスペースであり、C API、Python API、Java API、ダウンローダーを一つのリリースワークフローから作る。 エンジンが必要とするのは C API の voicevox_core.dll とダウンローダーである。

Windows の C API リリースは load-onnxruntime 機能を使う。 この方式ではコアをビルドするときに ONNX Runtime をリンクせず、実行時に指定された DLL を読み込む。 したがって、Windows Arm64 のコア DLL 自体は ONNX Runtime 成果物の完成前にもコンパイルできる。

ダウンローダーの実装には CpuArch::Arm64 がすでにある。 実行環境が aarch64 なら Arm64 を既定値とし、コアには windows-arm64、ONNX Runtime 仕様表には AArch64、追加ライブラリには windows-arm64 を使う。

必要な変更

.github/workflows/build.yml の行列へ次の C API 行を追加する。

os: windows-11-arm
target: aarch64-pc-windows-msvc
artifact_name: windows-arm64
c_release_format: plain-cdylib

製品経路だけを先に作るなら python_whl: false と java: false にできる。 完全な API 対応まで同時に行うなら、両方を有効にできる見込みがある。

Python API は abi3-py310 を使うため、Python 3.11.9 から Python 3.10 互換の ABI3 wheel を作れる。 現在の actions/setup-python は 3.10 を指定しているため、Arm64 行では 3.11.9 と architecture: arm64 に変更する。

Java 側の DLL 選択コードは aarch64 を arm64 へ変換できる。 完全な Java 対応には、Java 成果物の収集処理へ copy_dll windows-arm64 windows-arm64 を追加し、リソースの説明にも windows-arm64 を加える。

deny.toml の graph.targets へ aarch64-pc-windows-msvc を追加する。 この一覧はビルド行列と一致することを CI が検査しているため、片方だけを変更すると失敗する。

Cargo の依存解決には複数版の windows_aarch64_msvc がすでに含まれている。 deny.toml はビルドスクリプトを許可リストで制限しているため、Arm64 ターゲットで必要になる各版のバイパスとハッシュを cargo deny の結果に基づいて追加する必要がある。

crates/voicevox_core_build_features/onnxruntime-libs.toml には aarch64-pc-windows-msvc がない。 通常の Windows C API リリースは実行時ロードを使うため、この不足は最初の製品経路を阻まない。 コアのビルド時ダウンロード機能と対応テストまで揃える場合は、ONNX Runtime Arm64 成果物名と DLL、インポートライブラリの SHA-256 を追加する。

.github/workflows/build-downloader.yml には次の行を追加する。

name: download-windows-arm64.exe
target: aarch64-pc-windows-msvc
os: windows-11-arm

.github/workflows/download_test.yml には Windows Arm64 のテスト行と Windows,ARM64 のダウンローダー名対応を追加する。 CPU と DirectML の両方で、取得したコア、ONNX Runtime、追加ライブラリが Arm64 であることを検査する。

Windows Arm64 C API の成果物名は voicevox_core-windows-arm64-バージョン.zip になる。 この名前はダウンローダーが現在組み立てる名前と一致する。

VOICEVOX エンジン

現在の機構

エンジンは Python、FastAPI、Open JTalk、コア C API を組み合わせ、PyInstaller で run.exe を作る。 ビルドワークフローはコアのダウンローダーを取得し、コア、ONNX Runtime、追加ライブラリ、VVM を集める。

現在の既定値はコアとダウンローダー 0.16.2、VOICEVOX ONNX Runtime 1.17.3、追加ライブラリ 0.2.0 である。 Windows Arm64 コアを公開した後は、コアとダウンローダーの版を新しいリリースへ更新する必要がある。

必要な変更

.github/workflows/build-engine.yml へ CPU 行と DirectML 行を追加する。 どちらも windows-11-arm と architecture: arm64 を使う。 ターゲット名は windows-arm64-cpu と windows-arm64-directml にすると、初回起動用 Runtime Target と一致する。

ダウンローダー選択へ Windows,ARM64 と download-windows-arm64.exe の対応を加える。 その後の --cpu-arch arm64 は現在の行列値をそのまま利用できる。

MSVC の初期化を既定値の x64 のままにできない。 現在使う ilammy/msvc-dev-cmd はネイティブ Arm64 ホストを選ぶ入力を持たないため、Arm64 行では arch: amd64_arm64 を指定し、x64 ホストツールから Arm64 を生成する構成が現実的である。 ビルド時の x64 コンパイラは Windows on Arm のエミュレーションで動くが、生成する拡張モジュールは Arm64 になる。

Python はプロジェクトが固定する 3.11.9 を Arm64 で用意する。 actions/setup-python で 3.11.9 と architecture: arm64 を先に設定すれば、uv sync が同じ処理系を使える。

tools/modify_pyinstaller.bash はブートローダーを --msvc_targets="x64" で固定している。 PyInstaller の Windows Arm64 用指定である --target-arch=64bit-arm へ変えるか、Arm64 Python と Arm64 ビルド環境から既定ターゲットで作る必要がある。 PyInstaller 6.20.0 自体には win_arm64 wheel があり、Windows Arm64 のネイティブ実行ファイル作成を公式に支援している。

Python ネイティブ依存

現在の uv.lock には、NumPy、CFFI、psutil、PyInstaller、SoundFile などの win_arm64 wheel がある。 一方、次の実行時依存には Windows Arm64 wheel がない。

依存	現在の版	ビルド方式	評価
kanalizer	0.1.1	Rust と maturin	ランナーに Rust があり、ソースは Windows Arm64 用クレートを含む
pyworld	0.3.5	Cython と C++	x86 固定処理は見つからず、MSVC Arm64 で試せる
soxr	1.1.0	CMake と C++	AArch64 の NEON 検出と SIMD なしの経路がある
pyopenjtalk	固定コミット	Cython、CMake、C と C++	Windows MSVC 対応があり、CPU 固定処理は見つからない

これらは Arm64 ランナー上の uv sync でソースビルドされる見込みである。 ただし、実際の Windows Arm64 ビルドは公開 wheel より検証例が少ないため、エンジンの最初の CI 実行で失敗しやすい箇所になる。

再現性とビルド時間を改善するなら、各上流リポジトリで Windows Arm64 wheel を公開する。 最初の試作ではソースビルドを許可し、成功した版を固定してから wheel 公開へ移る順序が使える。

成果物とテスト

7z と VVPP のルートディレクトリをターゲット名と一致させる。 CPU 版なら voicevox_engine-windows-arm64-cpu-バージョン.7z と同名系列の VVPP を作る。 DirectML 版も windows-arm64-directml の系列で作る。

.github/workflows/test-engine-package.yml に同じ二つの Arm64 行を追加する。 既存の tools/check_release_build.py はエンジンを起動し、クエリ作成、音声合成、WAV 読み込み、マニフェスト取得まで実行するため、製品経路の確認に利用できる。

CPU 版の成功条件には、run.exe、voicevox_core.dll、voicevox_onnxruntime.dll、Python 拡張 DLL がすべて PE の Arm64 マシン種別 AA64 であることも加える。 DirectML 版では DirectML.dll と ONNX Runtime の DirectML プロバイダーも確認する。

VOICEVOX エディター

現在の機構

エディターは Electron 42.1.0 と electron-builder 26.15.2 を使う。 Electron 42.1.0 は electron-v42.1.0-win32-arm64.zip を公式に公開している。 electron-builder は electron-builder --win --arm64 を公式のビルド方法として案内している。

pnpm-lock.yaml に含まれる主要なネイティブ Node パッケージには Windows Arm64 成果物がある。 esbuild、Rollup、Rolldown、Sass Embedded、Lightning CSS、Parcel Watcher などが該当する。

アプリ側の初回起動処理は Runtime Target の arm64 をすでに理解する。 process.arch が arm64 なら windows-arm64-デバイス だけを候補に残すため、エンジン情報が追加されれば選択できる。

ビルド行列と electron-builder

.github/workflows/build.yml へ Windows Arm64 のエンジンなし、CPU、DirectML の行を追加する。 実行環境は windows-11-arm を使い、事前梱包ディレクトリは dist_electron/win-arm64-unpacked にする。

build/electronBuilderConfig.ts の Windows ターゲットは arch: ["x64"] で固定されている。 Windows でも process.arch に従って arm64 を選ぶか、ビルド行列からアーキテクチャを明示する必要がある。

build/splitNsisArchive.ts は入力を パッケージ名-版-x64.nsis.7z に固定している。 アーキテクチャを引数から組み立てるか、出力ディレクトリ内の .nsis.7z を一件だけ検出し、零件または複数件なら例外にする必要がある。

エンジン取得アクションは対象名を部分一致で選び、同名のルートディレクトリを展開する。 Arm64 行では windows-arm64-cpu と windows-arm64-directml を明示し、x64 成果物を誤って選ばないようにする。

エディターの公開名にも Arm64 を含める。 ZIP は voicevox-windows-cpu-arm64-バージョン.zip と voicevox-windows-directml-arm64-バージョン.zip のように区別できる。 インストーラーも VOICEVOX-CPU-arm64.Web.Setup のように x64 版と重複しない名前が必要になる。

typos

tools/downloadTypos.ts は Windows で x64 しか定義していない。 typos 1.43.4 の公式成果物にも Windows Arm64 はないため、Arm64 ランナー上の pnpm install は現在のままでは失敗する。

typos は製品に同梱されず、静的検査だけに使う。 リリースビルドの postinstall から検査用ツール取得を分離する方法が最も小さい。 Arm64 上でも typos を実行する必要があるなら、ランナーにある Rust から aarch64-pc-windows-msvc 用をビルドし、既存の配置先へ置く。

7-Zip

現在の Windows 処理は 7z2601-extra.7z から x64 の 7za.exe を取り出す。 この実行ファイルは VVPP の展開にも使われるため、製品へ同梱される。 x64 版を残せばエミュレーションで動く見込みはあるが、完全な Arm64 製品にはならない。

7-Zip 26.01 は公式に 7z2601-arm64.exe を公開している。 そのパッケージには Arm64 の 7z.exe と 7z.dll が入っている。

完全な Arm64 配布物にするには、次の箇所を 7z.exe と 7z.dll の二ファイル構成へ合わせる。

• tools/download7z.ts
• build/electronBuilderConfig.ts
• tools/generateLicenses.ts
• build/installer.nsh
• build/funcs.nsh

src/backend/electron/vvppFile.ts は環境変数で実行ファイル名を受けるため、名前が正しく渡れば 7z.exe も起動できる。 インストーラー内の一時展開処理は 7za.exe と 7zr.exe の名前が混在しているため、Arm64 対応時に実際に呼ぶファイル名を一つに統一して検証する必要がある。

Playwright と NSIS

現在の postinstall はリリースビルドでも Playwright の Chromium を取得する。 Playwright 1.60.0 は Windows の Arm64 と x64 を同じ win64 として扱うため、Windows Arm64 上では x64 Chromium を取得する。 この Chromium は Electron 製品へ同梱されないため、リリースビルドからブラウザー取得を分離すれば製品のアーキテクチャには影響しない。

NSIS Web インストーラーは、Arm64 Electron のペイロードを配布できる見込みである。 一方、NSIS 本体、プラグイン、セットアップ内で使う 7-Zip のアーキテクチャは別に確認する必要がある。 最初の成果物では ZIP と事前梱包物を必須とし、NSIS Web は Windows Arm64 実機でインストール、更新、アンインストールを通してから公開する方が安全である。

公式サイトと初回起動用エンジン情報

voicevox_blog は製品経路に必要である。 エンジンを分離したエディターは https://voicevox.hiroshiba.jp/latestDefaultEngineInfos.json を参照するため、エディターだけを公開しても Windows Arm64 エンジンを取得できない。

src/tools/generateLatestDefaultEngineInfos.ts の Runtime Target は固定配列である。 現在は windows-x64-cpu と windows-x64-directml だけがあり、Windows Arm64 がない。

次の二つを追加する。

• windows-arm64-cpu
• windows-arm64-directml

同じファイルの VVPP 一覧名対応へ、エンジンが公開する Arm64 の .vvpp.txt 名を追加する。 各 OS とアーキテクチャのグループには既定候補が一つだけ必要なため、Arm64 でも CPU または DirectML のどちらを既定にするか決める。

公式ダウンロード画面の DownloadModal.tsx も Windows を x64 前提で扱う。 Windows にアーキテクチャ選択を追加し、Arm64 の CPU と DirectML のインストーラーと ZIP へリンクする必要がある。 ブラウザーの User-Agent は Windows の CPU アーキテクチャを確実に表さないため、利用者が明示的に選べる画面が必要である。

latestDefaultEngineInfos.json は該当するエンジンの安定版 VVPP が公開された後に生成する。 先に JSON だけを公開すると、生成処理が該当リリースを見つけられず失敗する。

推奨する実装順序

1. バージョン系列を固定する

最初の CPU 版では ONNX Runtime 1.17.3 を維持する。 この選択なら、現在のコアとエンジンが使う C API 系列を変えずにアーキテクチャだけを追加できる。

DirectML 版では Microsoft.AI.DirectML 1.13.1 を使う追加ライブラリの新しい 0.2.x リリースを作る。 ONNX Runtime 1.23.2 への更新は、Windows Arm64 対応が通った後の別変更に分ける。

2. Open JTalk を先に直す

open_jtalk-rs に Windows Arm64 バインディングと CI を追加する。 Arm64 の open_jtalk-sys がビルドとテストを通ったコミットへ、コアの依存を更新する。

3. ONNX Runtime と DirectML を作る

onnxruntime-builder で CPU の voicevox_onnxruntime-win-arm64 を作る。 製品用非公開差分を適用した DLL が Arm64 でロードでき、推論できることを確認する。

CPU 版と並行して、追加ライブラリで DirectML-windows-arm64.zip を作れる。 その後、ONNX Runtime の DirectML Arm64 版を作る。

4. コアとダウンローダーを作る

コアの C API と download-windows-arm64.exe を公開する。 ダウンローダーから Arm64 のコアと ONNX Runtime を取得し、CPU 推論を実行する。 DirectML 成果物が揃った後は --devices directml でも同じ試験を行う。

5. エンジンを作る

エンジンが参照するコア、ダウンローダー、追加ライブラリの版を更新する。 CPU 版を PyInstaller で作り、既存のリリースビルド試験で音声合成まで通す。 その後、DirectML 版を追加する。

6. エディターを作る

最初にエンジンなしの ZIP と CPU エンジン入り ZIP を作る。 起動、初回エンジンダウンロード、音声合成、VVPP 操作を Windows Arm64 実機で確認する。 DirectML 版と NSIS Web インストーラーはこの後に加える。

7. 公式配信を更新する

エンジンの VVPP を公開してから latestDefaultEngineInfos.json に Windows Arm64 を追加する。 エディター成果物を公開してから公式ダウンロード画面へ Windows Arm64 の選択肢を追加する。

変更対象ファイル

リポジトリ	主な変更対象
open_jtalk-rs	.github/workflows/gen_bind.yml、.github/workflows/test.yml、生成済みバインディング
onnxruntime-builder	.github/workflows/build.yml、1.17.3 用パッチ適用条件
voicevox_additional_libraries	.github/workflows/download_and_deploy.yml
voicevox_core	.github/workflows/build.yml、build-downloader.yml、download_test.yml、deny.toml、Open JTalk 依存、必要に応じて onnxruntime-libs.toml
voicevox_engine	.github/workflows/build-engine.yml、test-engine-package.yml、tools/modify_pyinstaller.bash、Python 準備処理
voicevox	.github/workflows/build.yml、build/electronBuilderConfig.ts、build/splitNsisArchive.ts、エンジン取得アクション、7-Zip と typos の取得処理、NSIS スクリプト
voicevox_blog	generateLatestDefaultEngineInfos.ts、DownloadModal.tsx、生成される latestDefaultEngineInfos.json

検証項目

各段階で、成果物が存在するだけでなく、実際に Arm64 で動くことを確認する。

• PE ヘッダーを調べ、製品同梱 DLL と EXE のマシン種別が AA64 であることを確認する。
• コアのダウンローダーが Windows Arm64 の CPU 成果物だけを選ぶことを確認する。
• DirectML 指定時に Arm64 の ONNX Runtime と DirectML.dll を選ぶことを確認する。
• コア C API から VVM を読み、短い音声を生成する。
• エンジンの /audio_query と /synthesis を実行し、生成 WAV を読み込む。
• エディターの初回起動で Windows Arm64 用 VVPP だけが候補になることを確認する。
• エディターから音声合成、音声保存、VVPP の追加と削除を行う。
• ZIP 版と NSIS Web 版で同じ Arm64 実行ファイルが配置されることを確認する。
• コード署名後も PE のマシン種別と DLL ロードが変わらないことを確認する。
• GitHub-hosted runner だけでなく、Snapdragon 搭載 Windows 端末で CPU と DirectML を試す。

未確認事項

製品用 voicevox_onnxruntime の非公開差分と prepare.bash が Windows Arm64 でコンパイルできるかは確認できていない。 ここは公開情報から確定できず、製品用 CI の実行結果が必要である。

kanalizer、pyworld、soxr、pyopenjtalk はソース上で致命的な x64 固定処理を確認できなかった。 しかし、現在の版を Windows Arm64 と Python 3.11.9 の組み合わせでビルドした実績は確認できていない。

GitHub の windows-11-arm はパブリックプレビューである。 ビルド時間、キャッシュ容量、提供ソフトウェアは正式提供までに変わる可能性がある。

DirectML の Arm64 DLL と ONNX Runtime の Arm64 ビルド経路は存在する。 実際の Snapdragon GPU ドライバーで期待する速度と安定性が得られるかは、GitHub の仮想マシンだけでは判断できない。

コード署名サービスと NSIS プラグインの Windows Arm64 実機動作は確認できていない。 CPU 版 ZIP の成立を待たずに解決する必要はないが、公式インストーラー公開前には検証が必要である。

参照資料

• VOICEVOX 全体構成
• エディターのビルドワークフロー
• エンジンのビルドワークフロー
• コアのビルドワークフロー
• コアのダウンローダー実装
• ONNX Runtime Builder のワークフロー
• 追加ライブラリのワークフロー
• Open JTalk の生成済みバインディング選択
• 初回起動用エンジン情報の生成処理
• GitHub-hosted runner の選択
• Windows 11 Arm64 ランナーイメージ
• electron-builder のアーキテクチャ指定
• PyInstaller の Windows Arm64 対応
• ONNX Runtime 1.17.3 リリース
• VOICEVOX ONNX Runtime 1.17.3 リリース
• VOICEVOX エディター 0.25.2 リリース
• VOICEVOX エンジン 0.25.2 リリース
• VOICEVOX コア 0.16.4 リリース
• 追加ライブラリ 0.2.1 リリース
• 7-Zip 26.01 リリース
• typos 1.43.4 リリース
• コアの Windows Arm64 改善プルリクエスト