Ruby はかつて公式の Windows バイナリを配布していました。https://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ には 1.6 から 1.9-preview 時代の mswin32 の zip が今も残っており、1.9 の頃に途絶えています。理由のひとつは、素の zip が配布物として成立していなかったことです。https://bugs.ruby-lang.org/issues/999 には ruby-1.9.1-preview1 の mswin32 zip に OpenSSL と zlib の DLL が入っておらず gem update が全く動かなかったという報告があります。
以来、Windows への Ruby のインストールはサードパーティの配布物に依存してきました。ruby/ruby の CI が MSVC で実際にビルドしテストしている mswin プラットフォームには、エンドユーザー向けの配布物が存在しません。現状が Windows ユーザーにどう受け止められているかは https://bugs.ruby-lang.org/issues/19325 が示すとおりです。
技術的な土台は変わりました。この数か月、mswin に残っていた動かないテストは私自身がすべて修正しました。nmake check、test-bundler、test-bundled-gems は現在グリーンで、全テストスイートを実行する nmake exam も完走します。ビルドは pin された vcpkg manifest (vcpkg.json) で C 依存を管理しており、CI は VS 2022、VS 2026、windows-11-arm をカバーしています。MSVC の ABI (vcruntime140) は 2015 年から安定しています。欠けているのはビルド品質ではなく配布です。
タイミングも重要です。AI を使ってコードを書く時代に Windows 上で動く Ruby を必要とするのは、コーディングアシスタントに環境構築を任せる普通のユーザーであり、コンシューマ向けの AI ツールは WSL を介さず Windows ネイティブで動作します。無人で作業するアシスタントに必要なのは、昇格なし・GUI ダイアログなしでインストールでき、機械可読なバージョンインデックスを持ち、導入結果が決定的になる relocatable なランタイムです。無人プロビジョニングは CI では既に標準であり (setup-ruby はまさにこの用途のために存在します)、AI アシスタントは同じ要求をエンドユーザーのマシンに持ち込みました。Python は後述する PEP 773 で同じ結論に達しています。Windows の Ruby には、これに対する公式の答えが今日存在しません。
mswin プラットフォームに基づく公式 Windows 配布を、3つのコンポーネントで提供することを提案します。上記のテストスイート修正も含め、以下はすべて私自身が実装し検証した成果です。机上の設計ではありません。
1. ruby/ruby: binary-package ターゲット。 nmake 専用の新ターゲットで、インストール済みツリーに vcpkg のランタイム DLL、VC ランタイム、再頒布物のライセンス文書をまとめ、rbconfig.rb からビルドマシン固有のパスを除去したうえで、再配置可能な zip にパッケージします。LOAD_RELATIVE によりツリーはどこに置いても動作します。pull request は近日中に提出します。
これは実装・検証済みです。パッケージは PATH を System32 のみに制限したスモークテストを通過し (openssl、fiddle、psych、zlib、RubyGems がすべて動作)、C 拡張は VS Build Tools でビルドできます。rubygems.org のダウンロード上位 500 gem をソースビルド強制で調査したところ、native extension を持つ 44 gem 中 21 がビルドとロードに成功しました。失敗した 23 はすべて gem 側または環境側の要因 (gcc 専用コード、POSIX 専用ソース、外部ライブラリの不在) で、パッケージや ruby 本体に起因するものはなく、結果は 3.3.11 / 3.4.10 / 4.0.5 で同一でした。
2. ruby/actions: ビルドと公開。 zip のビルドと sha256 チェックサム付きの公開を自動化します。master の daily ビルドと、メンテナンス中の系列のリリースビルドです。リリース済み系列 (3.3、3.4、4.0) はリリース tarball からビルドし、同じパッケージングスクリプトを外部から適用するため、stable ブランチへの変更は不要です。この仕組みにより、OpenSSL のような同梱依存にセキュリティ更新が必要になった際、Ruby 本体のリリースなしで再パッケージリビジョン (-1、-2) を出せます。この部分も既に動いています。master に加えて 3.3.11、3.4.10、4.0.5 の zip をこの方式で作成・検証済みで、上記の gem 調査はこれらのパッケージ上で実施したものです。
3. rbmanager: Windows 向けバージョンマネージャ。 Python の install manager (PEP 773、https://peps.python.org/pep-0773/) と同型です。単一のネイティブ実行ファイル (rb コマンド) が URL またはローカルパスの zip をインストールし、%LOCALAPPDATA% 配下に展開して NTFS junction でバージョンを切り替えます。必要なのはユーザーレベルの PATH エントリ1つだけで、昇格は不要です。C# で作成したプロトタイプが既に完成しており、実機で検証済みです。
> rb install ruby-4.1.0-x64-mswin64_140.zip
Extracting ruby-4.1.0-x64-mswin64_140 ...
Installed ruby-4.1.0-x64-mswin64_140
> ruby -v
ruby 4.1.0dev (2026-06-29T22:22:44Z master 2ce6b8e54a) +PRISM [x64-mswin64_140]
> rb list
ruby-3.3.11-x64-mswin64_140
ruby-3.4.10-x64-mswin64_140
ruby-4.0.5-x64-mswin64_140
* ruby-4.1.0-x64-mswin64_140
> rb use 4.0
Now using ruby-4.0.5-x64-mswin64_140
> ruby -v
ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x64-mswin64_140]
この例では現在ローカルの zip からインストールしていますが、後述の公式バージョンインデックスが公開されれば、rb install 4.1 のようにバージョン指定だけで解決・ダウンロード・チェックサム検証まで行えるようになります。
この提案は既存の gcc ベースの配布物を補完するものであり、競合するものではありません。一部の能力は Ruby 側ではなくサードパーティベンダーが決めています。ベンダーの SDK が MSVC のツールチェーンと ABI を前提としているためで、公式の MSVC ビルドランタイムがあって初めて手が届きます。
機械学習のランタイム資産を直接流用できるようになります。ONNX Runtime、libtorch、OpenCV の Windows 向けビルド済みパッケージは C++ ABI を持つ MSVC バイナリであり、CUDA の nvcc は Windows ではホストコンパイラとして cl.exe しか受け付けません。GPU / ML ランタイムをバインドする Ruby 拡張が正しくリンクできるのは MSVC ビルドの Ruby です。PDB シンボルは Ruby を Windows 標準の診断スタックに接続します。WinDbg や Visual Studio で Ruby とベンダー DLL の混在スタックをデバッグでき、エンドユーザーの WER minidump が解析可能になり、公式シンボルパッケージの公開が初めて可能になります。さらに拡張の作者は、ruby/ruby 自身が vcpkg.json で使っているのと同じ vcpkg エコシステムから C 依存を取得できます。
第一に、これらを公式配布物とすることです。www.ruby-lang.org のダウンロードページで案内し、zip、チェックサム、静的なバージョンインデックス (pymanager の index-windows.json 相当) を ruby-lang.org のインフラでホストします。プレビュー期間中の初期ホスティングは GitHub Releases で構いません。
第二に、公開バイナリへの署名を個人の証明書ではなくプロジェクト名義で行うことです (例えば SignPath Foundation は OSS 向けコード署名証明書を発行しています)。
第三に、rbmanager を ruby organization 配下のリポジトリとしてホストすることです。
zip の具体的なレイアウトと命名規則は実装の詳細です。nobu さんと相談して決め、結果を doc/distribution/windows.md に文書化するので、このチケットで決める事項ではありません。
この提案は既存のサードパーティ配布物を置き換えたり非推奨にしたりするものではありません。コアチーム自身がビルドしテストしているプラットフォームに公式チャネルを追加するものです。
私は公式 snap 配布とセキュリティリリースを含むリリースパイプライン全体を既に運用しており、これらの成果物は同じ自動化と同じ運用者に乗ります。この提案によって現状のメンテナンスレベルが変わることはありません。
pure Ruby の gem はツールチェーンなしで動きます。C 拡張のビルドには VS Build Tools が必要ですが、Microsoft は 2022 年からオープンソース依存のビルドについて有償の Visual Studio ライセンスなしで利用できるようライセンスを変更しています。ridk 相当のブートストラップ (win32/install-buildtools.cmd が種) は follow-up の作業です。エコシステム全体での x64-mswin64 precompiled gem は長期の作業であり、前提条件ではありません。上記の調査では、x64-mingw-ucrt の precompiled バイナリで既に Windows をサポートしながら MSVC でのソースビルドだけが壊れている gem が 12 個特定されており、具体的で小さな upstream 修正リストになっています。このリストには nokogiri と ffi が含まれるため、これらに依存するアプリケーション (例えば Rails) はこの配布物ではまだ動きません。修正は手の届く規模で、msgpack については1行修正をローカルで検証済みであり、順次 upstream に送ります。
TLS のトラストアンカーは zip に同梱しません。rbmanager がインストール時に Windows 証明書ストアから証明書を用意します。恒久解として、OpenSSL 3.2+ の org.openssl.winstore:// ストアに対する OpenSSL::X509::Store#add_store サポートを ruby/openssl に別途提案します。
まず x64 からです。arm64 (arm64-mswin64) は CI でビルド済みであり、テストスイートがグリーンになり次第続けます。
展開は特定の日付に縛らず、準備ができたものから順次進めます。リリース済み系列 (3.3、3.4、4.0) の zip は既存リリースを対象に順次公開します。4.1 は master の nightly zip を継続的に公開し、preview がリリースされ次第その zip を出します。rbmanager と配布の仕組み全体の GA のみを 12 月の Ruby 4.1 リリースに合わせます。