---
title: "Ryeとは？開発終了後も使えるか2026年10月に検証、Windowsでの導入・削除とuv移行の注意点"
url: "https://www.issoh.co.jp/tech/details/3771/"
published: 2024-10-08
updated: 2026-10-28
categories: ["Python"]
publisher: "株式会社一創"
---

# Ryeとは？開発終了後も使えるか2026年10月に検証、Windowsでの導入・削除とuv移行の注意点

Rye（ライ）は、Pythonのインストールから仮想環境、依存関係の管理までを1つのコマンドで扱うツールです。英単語のryeは「ライ麦」を指しますが、この記事で扱うのはPythonのツールのほうです。Ryeは2025年2月26日の0.44.0を最後に更新が止まり、2025年8月には公式READMEに開発終了の告知が入りました。後継は同じ開発陣のuvです。

では、2026年のいまRyeは動くのか。2026年10月28日にmacOS（x86\_64）へRye 0.44.0を導入し、プロジェクトの作成からuvへの移行、アンインストールまでを試しました。その結果と公式ドキュメントをもとに、Windowsでの導入手順、uvへ移すときに詰まる箇所、消し方を順に説明します。

## まとめ

Ryeは今も導入でき、`rye sync`・`rye lint`・`rye test`も動きます。ただし中身は2025年2月で固まっています。自動で取得されるPythonは**3.13.2が上限で、3.14は「unknown version」で取得できません**。内部で使うuvも0.6.3のままです（uv本体は2026年10月27日に0.13.6が出ています）。公式は「セキュリティ更新も含めて今後の更新予定はない」としており、新しく採用する理由はありません。

既存のRyeプロジェクトをuvへ移す際は、次の3箇所を確認してください。該当する設定や依存関係がある場合に、解決失敗や機能の取りこぼしが起こります。

- `rye init`が書く`requires-python = ">= 3.8"`のままだと、`uv sync`が依存解決に失敗することがある
- `[tool.rye]`の`dev-dependencies`は、uvが警告を出さずに無視する（pytestなどが入らない）
- `[tool.rye.scripts]`のタスクは`uv run`で呼べない（uvにタスクランナーはまだ無い）

Windowsでは`rye-x86_64-windows.exe`を実行し、`%USERPROFILE%\.rye\shims`をPathの先頭に置けば使えます。削除は`rye self uninstall --yes`の後に、残った`.rye`フォルダとPathの行を手で消します。

## Ryeの現状：開発終了と2026年10月の動作確認

### 開発終了の告知と最終版0.44.0

Ryeの[GitHubリポジトリ](https://github.com/astral-sh/rye)はアーカイブ（読み取り専用）され、最終リリースは0.44.0（2025年2月26日）です。READMEの冒頭には「Ryeは今後も入手可能なままだが、セキュリティ更新を含め、これ以上の更新は予定していない（no further updates are planned, including security updates）」とあります。この告知は2025年8月18日のコミット「Retire Rye and add a uv migration guide」で追加されたもので、同時にuvへの移行ガイドも公開されました。

Ryeは、Flaskの作者Armin Ronacher氏が2023年に公開したツールで、のちにAstralへ移管されました。AstralはRust製のパッケージインストーラ・リゾルバとしてuvを公開し、Ryeを引き継ぎながらuvを後継のプロジェクト管理ツールへ拡張しました。Ryeも後期には依存解決にuvを使っていました。[インストールガイド](https://rye.astral.sh/guide/installation/)は「2025年2月の時点でRyeは開発されていない。新しく使う人はuvを入れてほしい」と案内しています。なおAstralは2026年3月にOpenAIによる買収を発表しています。uvやRuffの開発がその後どうなったかは[OpenAIのAstral買収とは？uv・Ruff・tyはどうなったか【2026年10月時点】](/tech/details/11465/)で確認しています。

### 2026年10月に導入して確かめた動作

macOS（x86\_64）で、GitHubリリースの`rye-x86_64-macos.gz`をsha256で照合してから、`RYE_HOME`を作業用フォルダに向けて導入しました。結果は次のとおりです。

| 確認した操作                | 結果（2026-10-28）          |
| --------------------- | ----------------------- |
| `rye self install`    | 成功。CPython 3.12.9を自動取得  |
| 内部で使うuv               | 0.6.3を取得                |
| `rye pin 3.13`        | 3.13.2に固定               |
| `rye add`・`rye sync`  | 成功（requests 2.34.2を解決）  |
| `rye lint`・`rye test` | 成功（Ruff・pytestが動作）      |
| `rye fetch 3.14`      | 失敗：unknown version 3.14 |

動作だけを見れば、Ryeは今も使えます。配布元の`rye.astral.sh/get`もGitHubのリリースも、2026年10月28日時点で取得できました。依存ライブラリは、Pythonの対応範囲や依存指定を満たす版が解決されます。既存のロックがある場合は、更新を指定しない限り必要な変更だけが行われ、常に最新版になるわけではありません。

### Rye 0.44.0によるCPython自動取得の上限

問題はPython本体です。Ryeは取得できるPythonの一覧（`python_downloads.inc`）をビルド時にバイナリへ埋め込んでいます。0.44.0の一覧はCPython 3.13.2までで、3.13系はその後も修正版が出ていますが、Ryeでは選べません。3.14はそもそも一覧にないため、`rye fetch 3.14`は次のように止まります。

```
$ rye fetch 3.14
error: error while fetching Python installation

Caused by:
    unknown version 3.14
```

[python.orgの配布ページ](https://www.python.org/downloads/)では、2026年10月25日に3.15.2・3.14.10・3.13.18が公開されています。Rye 0.44.0の自動取得機能だけでは、3.13の新しい修正版や3.14以降へ更新できません。手元のPythonを`rye toolchain register`で登録すれば使えなくはありませんが、その時点で「Pythonの取得まで任せられる」というRyeの利点は無くなります。Pythonの版を切り替える仕組み自体を比べたいなら、[pyenvでPythonのバージョンを切り替える手順｜shimの仕組みとビルド失敗の対処](/tech/details/17513/)も参考になります。

## WindowsにRyeをインストールする手順

### exeの選び方とSmartScreenの警告

WindowsではcurlのワンライナーではなくGitHubリリースのexeを実行します。64ビットなら`rye-x86_64-windows.exe`、32ビットなら`rye-x86-windows.exe`です。起動するとRyeは`%USERPROFILE%\.rye`へ自分を導入し、Pythonの版やPathへの登録を対話形式で尋ねます。

次の例はコマンドプロンプト（`cmd.exe`）で実行します。

```
:: ダウンロードしたフォルダで実行
rye-x86_64-windows.exe
:: 新しいターミナルを開いて確認
rye --version
```

Ryeのexeには署名がありません。SmartScreenで「WindowsによってPCが保護されました」と出たら、公式の案内どおり「詳細情報」から「実行」を選びます。ウイルス対策ソフトが「Bearfoos」というトロイの木馬として検出する例もあり、公式は誤検知と説明しています（[GitHub issue #468](https://github.com/astral-sh/rye/issues/468)）。社内PCで検出が出た場合は、情報システム部門に確認し、移行先のuvを含めて社内で利用を認められた導入方法を選んでください。

ARM版Windows（Snapdragon搭載のCopilot+ PCなど）には注意が要ります。0.44.0のリリースにARM64用のexeは無く、Ryeが取得するWindows向けPythonもx86とx86\_64だけです。エミュレーションで動かすことになり、ARM64ネイティブのwheelは使えません。uvは`aarch64-pc-windows-msvc`向けのビルドを配布しているので、ARM版Windowsで新しく環境を作るならuvを選んでください。

### shimsフォルダのPath登録と優先順位

インストーラは通常Pathを自動登録しますが、`rye`が「見つかりません」となる場合は手動で追加します。登録するのは`%USERPROFILE%\.rye\shims`で、Ryeの本体と、Ryeが管理するPythonへのshim（`python`・`python3`）が入っています。

1. Windowsキー＋Rで`sysdm.cpl`を実行する
2. 「詳細設定」タブの「環境変数」を開く
3. ユーザー環境変数の`Path`を開き、「新規」で`%USERPROFILE%\.rye\shims`を追加する
4. 「上へ」で一覧の先頭へ移動し、「OK」で閉じる
5. 新しいターミナルを開き直す（必要ならサインインし直す）

先頭へ動かすのは、Windowsには`python`と打つとMicrosoft Storeを開くアプリ実行エイリアスがあり、既存のPythonもPathに並んでいるからです。shimsが後ろにあると別のPythonが先に拾われます。ただし、ユーザーPathの先頭に置いても、システムPathに登録されたPythonよりは後に検索されます。新しいコマンドプロンプトで`where python`を実行して優先順位を確認してください。shimsが先に見つかる環境では、既存のPythonを前提にしたソフトの挙動が変わる場合があります。

### Windowsの開発者モード有効化と内部Pythonの指定

Rye公式は、インストール前に開発者モードを有効にするよう強く勧めています。Windows 11 24H2までは「設定」→「システム」→「開発者向け」、25H2以降は「システム」→「詳細設定」の「開発者向け」にあり（[Microsoftの開発者モードの説明](https://learn.microsoft.com/en-us/windows/advanced-settings/developer-mode)）、見つからなければ設定の検索で「開発者モード」と入力します。一般ユーザーでもシンボリックリンクを作れるようになり、Ryeの動作が安定するためです。手元のPythonをRye自身の実行用に使わせたいときは、`cmd.exe`から環境変数`RYE_TOOLCHAIN`を設定してインストーラを起動します。

```
set RYE_TOOLCHAIN=%USERPROFILE%\AppData\Local\Programs\Python\Python312\python.exe
rye-x86_64-windows.exe
```

Windowsのツールを増やさずにLinuxと同じ手順で済ませたいなら、WSLのUbuntuで`curl -sSf https://rye.astral.sh/get | bash`を使う方法もあります。WSL側の準備は[WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/)にまとめています。

## 既存のRyeプロジェクトを保守する最小コマンド

引き継いだRyeプロジェクトを動かすだけなら、覚えるコマンドは多くありません。Ryeは`pyproject.toml`ベースのプロジェクトが前提で、`setup.py`だけのプロジェクトには対応していません。

```
rye sync              # .venv と requirements*.lock を作る・更新する
rye add "requests>=2.32"
rye add --dev pytest  # [tool.rye] の dev-dependencies に入る
rye run hello         # [tool.rye.scripts] のタスクを実行
rye lint              # Ruff で検査（rye check も同じ）
rye fmt               # Ruff で整形
rye test              # pytest
rye build             # dist/ に sdist と wheel を作る
```

`rye sync`が作る仮想環境`.venv`にはpipが入っていません（実測でも`.venv/bin`にpipはありませんでした）。依存は必ず`rye add`から足します。ロックファイルは`requirements.lock`と`requirements-dev.lock`の2本で、pipでそのまま読める書式です。先頭のコメントに`universal: false`とあるとおり、既定では手元のPythonと環境に合わせた解決結果だけを記録しています。この点が、次のuv移行で効いてきます。

## Ryeからuvへ移行する手順

uvの基本操作は[uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説](/tech/details/4384/)で扱っているので、ここではRyeから移すときの差分に絞ります。`rye init`で作ったプロジェクトに`rye add requests`と`rye add --dev pytest`を行い、`.venv`を消してuv 0.11.31で`uv sync`を実行して確かめました。

### requires-pythonと依存パッケージの対応範囲の不一致

最初の`uv sync`は失敗しました。`rye init`は`pyproject.toml`に`requires-python = ">= 3.8"`と書き、`rye add requests`はその時点の最新版を下限にした`requests>=2.34.2`を書き込みます。uvは宣言された範囲のすべてのPythonで成り立つように解決するため、Python 3.10以上を要求するrequests 2.34.2を「3.8と3.9では入らない」と判断します。

```
× No solution found when resolving dependencies for split (markers:
│ python_full_version >= '3.8' and python_full_version < '3.10'):
╰─▶ Because the requested Python version (>=3.8) does not satisfy
    Python>=3.10 and requests==2.34.2 depends on Python>=3.10, ...
```

Ryeで問題が出なかったのは、手元の3.13.2だけを対象に解決していたからです。運用しているPythonの版に合わせて`requires-python = ">= 3.10"`のように上げると、`uv sync`は通りました。移行前に、`pyproject.toml`の`requires-python`と依存パッケージの対応範囲を確認してください。古いPythonへの対応を維持する必要がある場合は、下限を上げるのではなく、依存パッケージの版指定を見直します。

### Ryeの開発依存設定からdependency-groupsへの移行

`requires-python`を直した後の`uv sync`は成功しましたが、pytestが入っていませんでした。`[tool.rye]`の`dev-dependencies`はuvにとって知らない名前空間なので、警告も出さずに読み飛ばされます。成功表示だけを見て移行完了とすると、CIで初めて`ModuleNotFoundError: No module named 'pytest'`に気づくことになります。標準の`[dependency-groups]`へ移すと入りました。

```
# 移行前（Rye）
[tool.rye]
managed = true
dev-dependencies = ["pytest>=9.2.0"]

# 移行後（uv）
[dependency-groups]
dev = ["pytest>=9.2.0"]
```

そのほかの設定も、多くは`[tool.rye]`を`[tool.uv]`へ書き換えるだけですが、[公式の移行ガイド](https://rye.astral.sh/guide/uv/)が挙げる次の項目は名前か意味が変わります。

| Ryeの設定                       | uvでの書き方                       | 注意点               |
| ---------------------------- | ----------------------------- | ----------------- |
| `tool.rye.dev-dependencies`  | `dependency-groups.dev`       | 移さないと無視される        |
| `tool.rye.lock-with-sources` | `tool.uv.no-sources`          | 真偽が反転（false→true） |
| `tool.rye.virtual`           | `tool.uv.package`             | 真偽が反転（true→false） |
| `tool.rye.universal`         | `tool.uv.pip.universal`       | pip配下へ移動          |
| `tool.rye.generate-hashes`   | `tool.uv.pip.generate-hashes` | pip配下へ移動          |
| `[[tool.rye.sources]]`       | `[[tool.uv.index]]`           | 単数形。indexesは不可    |

`tool.uv.pip`配下の設定は、`uv pip`専用です。表の`universal`と`generate-hashes`を書き換えても、`uv sync`や`uv lock`の動作は変わりません。

最後の行は移行ガイドの記述そのままでは動きません。ガイドは対応先を`[[tool.uv.indexes]]`と書いていますが、uvの設定名は単数形の`[[tool.uv.index]]`です。複数形で書くとuvは「Failed to parse `pyproject.toml` during settings discovery」と`unknown field indexes`の警告を出しますが、処理は止めずに`uv sync`まで成功させます。書いたインデックスは使われないので、成功表示だけで判断せず警告を確認してください。既定のインデックスは`name = "default"`の代わりに`default = true`、find-linksは`format = "flat"`で指定します。Ryeでできたインデックスurl内の環境変数の展開はuvに無いため（[uv#5734](https://github.com/astral-sh/uv/issues/5734)）、認証情報は環境変数やkeyring、URLごと差し替えるなら`UV_INDEX`を使います。

### \[tool.rye.scripts\]の非互換とタスクの移行先

`rye run hello`で動いていたタスクは、`uv run hello`では実行ファイルが見つからずに失敗します。uvにはタスクランナーが無く、機能要望の[uv#5903](https://github.com/astral-sh/uv/issues/5903)は2026年10月28日時点でもオープンのままです。`[project.scripts]`に書くエントリポイントは標準仕様なのでuvでも動きますが、こちらは別物です。

移す先は、タスクが数本ならREADMEに`uv run pytest`などのコマンドを書き出す、定型の手順が多いならMakefileやシェルスクリプト、CIで回すものはワークフロー定義、と分けるのが現実的です。移行の手間を見積もる際は、タスク数に加え、連鎖実行、環境変数、OS依存のコマンド、CIからの呼び出しを確認してください。

### Ryeとuvのコマンド・ロックファイル対応

以下の対応表でRuffを実行するには、先に`uv add --dev ruff`で開発依存へ追加してください。Ryeが内部で使うRuffは、uvへの移行だけではプロジェクトへ導入されません。

Poetryやpipenvからの移行に使われるmigrate-to-uv（0.12.0）は、Ryeに対応していません。Ryeのプロジェクトで実行すると`Could not determine which package manager is used from the ones that are supported.`と出て止まり、対応先として表示されるのはpip・pip-tools・pipenv・poetryの4つです。移行は上の書き換えを手で行います。

| Rye                    | uv                                       |
| ---------------------- | ---------------------------------------- |
| `rye init --script`    | `uv init --package`                      |
| `rye sync`             | `uv sync`                                |
| `rye add`・`rye remove` | `uv add`・`uv remove`                     |
| `rye lint`・`rye fmt`   | `uv run ruff check`・`uv run ruff format` |
| `rye test`             | `uv run pytest`                          |
| `rye build`            | `uv build`                               |
| `requirements.lock`    | `uv.lock`                                |

`uv init --script`は`rye init --script`とは別の機能で、依存を先頭のコメントに書く単一ファイルのスクリプトを作ります。ロックファイルはuv独自の`uv.lock`に変わるので、移行後に`uv export --no-hashes --no-dev --no-emit-project`で書き出し、元の`requirements.lock`と版を突き合わせておくと安心です。今回の検証ではパッケージ5つの版がすべて一致しました。Dockerイメージで`requirements.lock`をpipに読ませていた場合も、公式ガイドはその形を残さず、ビルドで`uv sync`、実行で`uv run`を使うよう勧めています。

## Ryeをアンインストールする手順と残るファイル

Rye本体は専用のサブコマンドで消します。`rye remove`は依存パッケージを外すコマンドなので、取り違えないでください。

```
rye self uninstall --yes
```

実行すると「Don’t forget to remove the sourcing of …/env from your shell config.」と表示されて終わります。検証では、`.rye`フォルダに**空の`env`と、設定が保存された`config.toml`の2ファイル**が残りました。公式ドキュメントは空の`env`が残るとだけ書いていますが、設定ファイルも残ります。完全に消すには次の後片付けをします。

- Windows：`%USERPROFILE%\.rye`を削除し、ユーザー環境変数Pathから`%USERPROFILE%\.rye\shims`の行を消す
- macOS・Linux：`~/.rye`を削除し、`.profile`や`.zprofile`などにある`source "$HOME/.rye/env"`の行を消す
- fish・nushell：`fish_user_paths`や`env.nu`に足した`~/.rye/shims`を外す

Pathの行を残すと、存在しないフォルダが検索対象に残り、`python`の解決先がわかりにくくなります。

削除の順番にも注意が要ります。Ryeが作った`.venv`の`python`は、`.rye/py/cpython@3.13.2`のようなRye管理下のPythonを指しています。検証でも、`rye self uninstall`の後に`.venv/bin/python`を実行すると「no such file or directory」になりました。[公式のインストールガイド](https://rye.astral.sh/guide/installation/)も、アンインストール後はRyeで作った仮想環境が機能しなくなると書いています。同じ端末のRyeプロジェクトをすべてuvへ移し、既存の`.venv`を削除してから`uv sync --managed-python`でuv管理のPythonを使って作り直し、テストが通ることを確かめてから、最後にRye本体を消してください。検証でも、Ryeの`.venv`を残したまま`uv sync`すると、`.venv/bin/python`はRye管理下のPythonを指したままでした。

## 新規に採用しない理由と、既存プロジェクトの移行の優先度

2026年に新しいプロジェクトへRyeを入れる理由はありません。「枯れたツールだから安定している」という考え方は、セキュリティ更新もしないと宣言されたツールには当てはまりません。前の章で見たとおり、Python 3.14以降を自動取得できない、内部のuvが0.6.3のまま、という形で古さはすでに表に出ています。新しく選ぶならuvが第一候補で、condaのパッケージも扱いたい場合は[Pixiとは？Python・conda対応のパッケージ管理ツールの使い方とuv・condaとの違い](/tech/details/9892/)、Poetryと比べたい場合は[Poetryとは？Python依存管理の仕組みと2.5系の使い方・uvとの選び方](/tech/details/12303/)が判断材料になります。

既存のプロジェクトは、次のどれかに当たるなら移行を前倒しします。

- Python 3.14以降、または3.13の新しい修正版へ上げる予定がある
- CIやDockerのビルドで、毎回Ryeのインストーラをネットワークから取得している
- ARM版Windowsの開発者がいる、または新しいメンバーが継続的に加わる

逆に、機能追加が止まっているプロジェクトでも、Pythonと依存関係の脆弱性対応、配布物の再取得可否、稼働期限を確認して移行時期を決めます。版を固定していることだけでは、移行を先送りする根拠になりません。避けたいのは、全プロジェクトを一度に移して、`dev-dependencies`の消失や`[tool.rye.scripts]`の取りこぼしにまとめて気づく形です。`[tool.rye.scripts]`を多く使っているものから1本ずつ移し、CIが通るのを確かめてから次へ進めてください。社内の業務システムでPython環境の刷新から任せたい場合は、[フルスクラッチのシステム開発](/service/system/fullscratch/)として相談も受けています。エディタ側でuvを使う設定は[PyCharmの最新バージョンは2026.2｜2025.3〜2026.2の新機能・uv設定・無料版の範囲](/tech/details/10226/)で確認できます。

## よくある質問

### Ryeの読み方と意味は？

「ライ」と読みます。英語ではライ麦のことで、公式ロゴにも麦の穂が描かれています。作者のArmin Ronacher氏は、Ryeの役割をuvへ引き継ぐ方針を2024年8月のブログ記事「Harvest Season」（収穫期）で説明しており、名前と掛けたタイトルになっています。

### Ryeは2026年でもまだ使えますか？

使えます。2026年10月28日の検証でも、導入から`rye sync`・`rye lint`・`rye test`まで動きました。ただし取得できるPythonは3.13.2まで、内部のuvは0.6.3のままで、セキュリティ修正も出ません。動くことと使い続けてよいことは分けて考えてください。

### RyeでPython 3.14は使えますか？

自動取得はできません。`rye fetch 3.14`は「unknown version 3.14」で失敗します。別途入れたPythonを`rye toolchain register`で登録する方法はありますが、Pythonの管理まで含めて新しい版を使うならuvへ移る方が手間がかかりません。

### Windowsでryeコマンドが「見つかりません」と出るのはなぜ？

まずPathの登録と、インストールが完了しているかを確認してください。`%USERPROFILE%\.rye\shims`がユーザー環境変数Pathにあるかを確認し、無ければ追加して先頭へ移動してください。追加前に開いていたターミナルには反映されないため、開き直す必要があります。

### RyeとuvはどちらもAstral製ですが、併用できますか？

同じプロジェクトを両方で操作するのは避けてください。Ryeは`requirements.lock`、uvは`uv.lock`を正として別々に解決するため、2つのロックファイルの版がずれていきます。`[tool.rye]`の設定もuvは読みません。移行したプロジェクトのロックファイルと設定はuvの形にそろえてください。Rye本体の削除は、同じ端末でRyeを使うほかのプロジェクトも移行してから行います。

## 関連記事

- [uvとは？Pythonの環境構築・パッケージ管理・バージョン管理の使い方を徹底解説](/tech/details/4384/)
- [OpenAIのAstral買収とは？uv・Ruff・tyはどうなったか【2026年10月時点】](/tech/details/11465/)
- [Poetryとは？Python依存管理の仕組みと2.5系の使い方・uvとの選び方](/tech/details/12303/)
- [pyenvでPythonのバージョンを切り替える手順｜shimの仕組みとビルド失敗の対処](/tech/details/17513/)
- [Pixiとは？Python・conda対応のパッケージ管理ツールの使い方とuv・condaとの違い](/tech/details/9892/)

---

出典: [Ryeとは？開発終了後も使えるか2026年10月に検証、Windowsでの導入・削除とuv移行の注意点](<https://www.issoh.co.jp/tech/details/3771/>)（株式会社一創）
