Ruby

rbenvとは?Rubyバージョン管理の仕組みとRVMとの違い・1.3系の導入手順

rbenvとは?Rubyバージョン管理の仕組みとRVMとの違い・1.3系の導入手順

rbenvは、1台のマシンに複数のRubyを共存させ、プロジェクトごとに使う版を固定するためのツールです。仕組みの中心にあるのはshims(シム)と呼ばれる中継スクリプトで、rubyやgemの呼び出しをrbenvが一度受け取り、そのディレクトリで使うべき版へ渡し直します。この記事では、shimsの経路とバージョン決定の優先順位、rbenv 1.3.0で挙動が変わったrbenv init、RVMやmiseとの選び分け、2026年9月時点で入れるべきRubyの版までを、実際に打つコマンドとともに整理します。

まとめ

rbenvは「shimsディレクトリをPATHの先頭に置く」という一点だけで成立するツールです。最新版は2025年1月8日公開の1.3.2で、Rubyのビルドを担うrbenv installは本体ではなくruby-buildプラグインが提供します。バージョンはRBENV_VERSION環境変数、.ruby-versionファイル、~/.rbenv/versionの順に探索され、先に見つかったものが勝ちます。

RVMとの比較で迷う必要は、2026年時点ではほとんどありません。RVMの最終リリースは2021年1月15日の1.29.12で5年以上更新が止まっており、rbenv側の公式wikiも利用を勧めない旨を明記しています。Rubyだけを扱うならrbenv、Node.jsやPythonも同じ仕組みで揃えたいならmiseという分け方が実務的です。Python側で同じshim方式を使うツールはpyenvでPythonのバージョンを切り替える手順にまとめました。以下、仕組みから順に見ていきます。

rbenvの仕組み|shimsがrubyコマンドを横取りする経路

shimsとPATHの関係

rbenvを導入すると~/.rbenv/shimsというディレクトリが作られ、そこにruby、gem、bundle、rakeといった実行ファイルと同じ名前の小さなスクリプトが並びます。これがshimsです。rbenvのREADMEは、このshimsディレクトリをPATHの先頭に追加することを「rbenvが正しく動くための実質唯一の要件」と表現しています。

$ rbenv which ruby
/Users/you/.rbenv/versions/3.4.10/bin/ruby

$ which ruby
/Users/you/.rbenv/shims/ruby

which rubyが返すのはshims側のパス、rbenv which rubyが返すのが実際に起動される本体です。この2つがずれていることを理解しておくと、後述のトラブル対処が一気に楽になります。shimsが呼ばれるとrbenvはカレントディレクトリから上へ.ruby-versionを探し、決まった版の実体へ処理を渡します。

この設計には代償もあります。rbenv自身のwikiは、すべてのRuby呼び出しを一度受けるため約50ミリ秒のオーバーヘッドが加わると認めています。通常の開発では体感しませんが、短いスクリプトを大量に起動するような使い方では効いてきます。

バージョン決定の優先順位

「設定したはずの版にならない」という相談の大半は、優先順位を把握していないことが原因です。rbenvは次の順で探し、最初に見つかった指定を採用します。

優先 指定方法 設定先 有効範囲
1 rbenv shell RBENV_VERSION環境変数 その端末セッション
2 rbenv local .ruby-version そのディレクトリ以下
3 rbenv global ~/.rbenv/version マシン全体

.ruby-versionの探索はカレントディレクトリから親方向へさかのぼるため、プロジェクト直下に置いておけばサブディレクトリでも同じ版が効きます。このファイルはBundlerやCIも読むので、チーム内でRubyの版を揃える手段としてはrbenvの設定ファイルより.ruby-versionのほうが汎用性があります。

rbenvとRVMの違いと2026年の選択肢

RVMの現況とrbenvが避けた設計

RVM(Ruby Version Manager)は、rbenvが登場する前からある元祖のバージョン管理ツールです。両者の決定的な差は介入の深さで、RVMはcdコマンドを自前の関数で置き換えてディレクトリ移動を監視し、シェル環境そのものを書き換えて動きます。rbenvはPATHにshimsを差し込む以外のことをしません。

2026年9月時点で判断材料になるのは、思想よりも更新状況です。RVMの最終リリースは2021年1月15日の1.29.12で、5年半以上タグが打たれていません。リポジトリ自体はアーカイブされておらずコミットは続いていますが、リリースとして配布された版は止まったままです。rbenv側の公式wikiは、RVMについて「Rubyの版を入れやすい場面がある以外に利点が見当たらず、利用を勧められない」と書いています。競合ツールの言い分である点は割り引くとしても、新規に環境を組むなら選ぶ理由は残っていません。

miseとrbenvの使い分け|扱う言語数による判断

今の実務でrbenvの対抗馬になるのはRVMではなく、mise(旧rtx)です。miseはRubyに限らずNode.jsやPython、Goなども1つの設定ファイルで管理でき、リリースも活発です(2026年9月2日にv2026.9.1が公開)。rbenvの公式wikiが挙げている「rtx」は、その後miseへ改称されたこのツールを指します。

選び分けの基準は単純です。扱う言語がRubyだけならrbenv、複数言語のランタイムを同じ作法で固定したいならmise。Node.js側で同種の悩みがある場合の考え方はVolta(ヴォルタ)とは?Node.jsバージョン管理ツールの使い方と現状【mise移行推奨・2026年】、JVM系についてはJVM開発者がSDKMAN!を導入すべき理由とバージョン管理の課題解消で扱っています。

rbenvを選ばないほうがよい場面

rbenvが向かないケースははっきりしています。まず、gem install --user-installで~/.gemや~/.local/share/gemに入れたgemの実行ファイルを、rbenvは見つけられません。これはrbenv自身がwikiで認めている制約で、回避するにはそのディレクトリを手動でPATHへ足す必要があります。

もう1つは、アプリをコンテナで動かす構成です。ベースイメージ側でRubyの版が固定されるなら、ホストにバージョン管理ツールを入れる意味は薄くなります。rbenvのwiki自身も、コンテナ化した構成ではバージョン管理ツールもRubyのコンパイルも通常は不要だと述べています。ローカルでrbenv、本番はコンテナという二重管理にするより、開発環境ごとイメージへ寄せるほうが版ずれの事故は減ります。

rbenvとBundlerの守備範囲の違い

「rbenvとBundlerのどちらを使うのか」という疑問は検索クエリにも現れますが、これは選択の問題ではなく担当範囲の違いです。rbenvが決めるのはRuby本体の版、Bundlerが決めるのはそのRubyの上に載るgemの版で、両方を同時に使うのが標準的な構成です。

$ cat .ruby-version
3.4.10

$ head -3 Gemfile
source "https://rubygems.org"
ruby "3.4.10"
gem "rails", "~> 8.0"

Gemfileのruby行は「このアプリが要求するRubyの版」の宣言で、実際にその版を用意するのはrbenvの仕事です。両者が食い違うとBundlerは実行時にエラーを出して止まります。.ruby-versionとGemfileの記述を揃えておくのが事故防止の基本で、Gemfileやgemの管理そのものはgemとBundlerの使い方|Bundler 4系で変わったコマンドとGemfileの書き方で詳しく扱っています。

インストールと初期設定|1.3.0で変わったrbenv init

macOSとLinuxへの導入

macOSではHomebrewが最短です。Homebrewのrbenv formulaはruby-buildを必須依存として持つため、rbenvだけを指定すればビルド用プラグインも同時に入ります。

# macOS・Linux(Homebrew)
$ brew install rbenv
$ rbenv -v
rbenv 1.3.2

Homebrewの公開統計では、rbenvの直近30日のインストール数は4,600件を超えています(2026年9月7日時点)。導入経路としては今もこれが主流と考えてよいでしょう。

Linuxでは配布パッケージに注意が必要です。rbenvのREADMEは、DebianおよびUbuntuの公式リポジトリにあるrbenvは古いと明示的に警告し、gitでの導入を推奨しています。ArchやFedora、openSUSEには公式パッケージがあります。

# git で導入(配布版が古い環境・最新を確実に入れたい場合)
$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv
$ ~/.rbenv/bin/rbenv init

# rbenv install が無いと言われたら ruby-build をプラグインとして追加
$ git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

ruby-buildは本体とは別のリリース周期で、新しいRubyが出るたびに更新されます。直近の版は2026年9月2日公開のv20260902です。新しいRubyがインストール候補に出てこないときは、ほぼruby-buildの更新漏れが原因です。

rbenv initの2つのモード

ここが古い解説記事といちばん食い違う箇所です。rbenv 1.3.0(2024年7月5日公開)で、rbenv initは「手順を画面に表示するだけ」から「シェルの初期化ファイルを実際に書き換える」動作に変わりました。以前のrbenvは指示を出力するだけで何も変更しなかったため、表示された内容を自分で~/.bash_profileや~/.zshrcへ貼る必要がありました。この誤解が最も多いつまずきだったと、rbenv側もリリースノートで説明しています。

現在のrbenv initには2つのモードがあります。

# 人間向け:シェルを自動判定して初期化ファイルを書き換える
$ rbenv init
writing ~/.zprofile: now configured for rbenv.

# シェルを引数で明示することもできる
$ rbenv init bash
writing ~/.bash_profile: now configured for rbenv.

# 機械向け:eval する用のスクリプトを出力するだけ
$ rbenv init -

書き込み先はシェルと既存のdotfileの状態で決まるため、「どのファイルに入るか」を思い込みで探さないでください。rbenv 1.3.2のソース(libexec/rbenv-init)では次のように分岐します。

シェル 条件 書き込み先
zsh .zshrcにrbenvの記述が既にある ~/.zshrc
zsh 上記以外 ~/.zprofile
bash .bashrcがあり.bash_profileが無い ~/.bashrc
bash 上記以外(何も無い新規環境を含む) ~/.bash_profile

dotfileを何も作っていない新規環境でbashを指定すると、~/.bashrcではなく~/.bash_profileに書かれます。追記されるのは次の2行です。引数を省略した場合は親プロセスを調べて現在のシェルを判定し、すでに設定済みのシェルに対して再実行しても何も書き換えずに終了します。

# Added by `rbenv init` on Mon Sep  7 00:02:00 JST 2026
eval "$(rbenv init - --no-rehash zsh)"

末尾のシェル名と--no-rehashが自動で埋まる点に注目してください。1.3.0では、シェル起動のたびにshimsを再生成する処理が既定で無効になりました。起動が遅くなる原因を初期状態から取り除く変更で、gemをインストールした直後の再生成は別の仕組みで自動的に走るため、通常はこれで困りません。手でeval行を書く場合も、この形をそのまま使えば挙動が揃います。

設定を書き込んだら、端末を開き直してから確認します。

$ echo $PATH | tr ':' '\n' | head -2
/Users/you/.rbenv/shims
/usr/local/bin

PATHが通らないときの確認

shimsのパスが先頭に来ていなければ設定が効いていません。zshは~/.zshrc、bashはログインシェルかどうかで~/.bash_profileと~/.bashrcのどちらが読まれるかが変わるため、書いたファイルと実際に読まれるファイルが違っているケースが典型です。rbenv initに任せればこの判断はrbenv側が行います。環境全体の健全性はrbenv-doctorスクリプトで一括点検できます。

Rubyのインストールと2026年に選ぶ版

rbenv installの実行手順

rbenv installはrbenv本体のコマンドではなく、ruby-buildプラグインが追加するものです。Homebrew経由なら依存として入っているため、そのまま使えます。

# 安定版の一覧を出す(ruby-build 20260902 での出力)
$ rbenv install -l
3.3.12
3.4.10
4.0.6
jruby-10.1.1.0
mruby-4.0.0
picoruby-3.4.2
truffleruby-34.0.1
truffleruby+graalvm-34.0.1

# 過去のパッチ版まで含めた全候補
$ rbenv install -L

# 指定した版をビルドして入れる
$ rbenv install 4.0.6
$ rbenv global 4.0.6
$ ruby -v
ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-darwin23]

-lで出るのは各系列の最新パッチだけで、この一覧にMRIは3系列しか並びません。サポートが終わった3.2以前は候補から外れているため、迷ったらrbenv install -lに出てくる版から選ぶのが手堅い判断になります。

rbenv installはソースからのコンパイルなので、実行前にビルドに必要なライブラリが揃っているかを確認してください。ここで失敗する場合の原因はrbenvではなくOS側の依存関係にあり、ruby-buildのDiscussionsにビルド失敗のカテゴリが用意されています。

保守状況から決めるバージョン

入れる版を「最新だから」で決めると、数か月後にセキュリティ修正が降ってこない枝を掴むことがあります。2026年9月時点のRuby公式の保守状況は次のとおりです。

系列 最新パッチ 状態 備考
4.0 4.0.6 通常メンテナンス 2025-12-25リリース
3.4 3.4.10 通常メンテナンス 2024-12-25リリース
3.3 3.3.12 セキュリティメンテナンス 2026-04-01から / EOL 2027-03-31予定
3.2 3.2.11 EOL 2026-04-01にサポート終了
3.1 3.1.7 EOL 2025-03-26にサポート終了

新規プロジェクトなら4.0系か3.4系、つまり通常メンテナンス中の2系列から選ぶのが妥当です。3.3系はバグ修正が止まりセキュリティ修正のみの段階に入っているため、新しく採用する対象ではなく移行計画を立てる対象になります。3.2以前を使い続けている環境は、修正が一切提供されない状態です。Ruby 4系で何が変わったかはRuby 4.0.1がリリースされました – 新機能満載のRuby 4系に初の安定版パッチが登場しましたにまとめています。

バージョンの切り替えと確認|global・local・shell

切り替えは3つのコマンドで完結します。それぞれ書き込む先が違うだけで、優先順位は先ほどの表のとおりです。

# マシン全体の既定(~/.rbenv/version に書く)
$ rbenv global 3.4.10

# このディレクトリ以下(.ruby-version に書く)
$ cd ~/projects/myapp
$ rbenv local 3.3.12

# この端末セッションだけ(RBENV_VERSION に入る)
$ rbenv shell 4.0.6

確認側はversionとversionsを使い分けます。単数形は「今どれが有効か」と「どの設定で決まったか」を返し、複数形は「入っている版の一覧」を返してアスタリスクで現在の版を示します。

$ rbenv version
3.3.12 (set by /Users/you/projects/myapp/.ruby-version)

$ rbenv versions
  system
  3.3.12
* 3.4.10 (set by /Users/you/.rbenv/version)

rbenv versionの括弧内が、どのファイルや環境変数で決まったかを示します。意図しない版になっているときは、まずこの括弧を読めば原因のファイルが分かります。rbenv shellを使うにはシェル統合が有効である必要があり、無効な環境ではexport RBENV_VERSION=4.0.6を直接書いても同じ効果になります。特定の版だけを解除したい場合はrbenv local --unsetやrbenv shell --unsetです。

なおsystemという特殊な版名は、PATH上にあるOS標準のRubyを指します。macOS標準の/usr/bin/rubyは2.6系(Darwin 25系で確認した版はruby 2.6.10p210)のまま据え置かれており、これは2022年4月12日にサポートが終了した系列です。実務ではsystemを既定にせず、rbenvで入れた版をglobalに設定しておくのが安全です。Rails開発でのエディタ側の設定はruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Containerを参照してください。

更新とrehash・つまずきやすいエラー

rbenv本体とruby-buildの更新

rbenvには自己更新コマンドがありません。導入方法に応じた更新をします。

# Homebrew で入れた場合
$ brew upgrade rbenv ruby-build

# git で入れた場合
$ git -C ~/.rbenv pull
$ git -C "$(rbenv root)"/plugins/ruby-build pull

更新の主目的はrbenv本体よりruby-buildです。本体は1.3.2が2025年1月8日から据え置かれている一方、ruby-buildは新しいRubyが出るたびに更新されます。rbenv install -lに目当ての版が出てこないときは、本体ではなくruby-buildを更新してください。

shimsが見つからないときの確認

gemをインストールしたのに実行ファイルが見つからない、という症状はshimsの生成漏れです。gemインストール後の再生成は自動で走りますが、手動での取り直しも1コマンドです。

$ rbenv rehash
$ ls "$(rbenv root)"/shims
bundle    bundler   erb       gem       irb       minitest  racc      rake

$ rbenv which rspec
/Users/you/.rbenv/versions/3.4.10/bin/rspec

切り分けの順序を決めておくと早く終わります。まずwhich rubyでshimsが返るかを見て、返らなければPATH設定(rbenv init)の問題です。shimsは返るのに版が想定と違うならrbenv versionの括弧で設定元を特定します。コマンド自体が見つからないならrbenv rehash、それでも解決しないならgemがそのRuby版に入っていません。rbenv whenceを使うと、指定した実行ファイルを持つ版を横断的に探せます。

よくある質問

rbenvとは何ですか?

Unix系OSでRubyの複数バージョンを共存させ、プロジェクトごとに使う版を切り替えるためのバージョン管理ツールです。shimsという中継スクリプトをPATHの先頭に置き、rubyやgemの呼び出しを受けてから該当する版へ渡す仕組みで動きます。最新版は2025年1月8日公開の1.3.2です。

rbenvのshimsとは何ですか?

~/.rbenv/shimsに置かれる、Ruby関連の実行ファイルと同名の小さなスクリプト群です。実体ではなく入口で、呼ばれるとrbenvが.ruby-versionなどの設定を読んで使う版を決め、そのバージョンの本体へ処理を渡します。which rubyがshims配下を返し、rbenv which rubyが実体を返すのはこのためです。

rbenvとRVMはどちらを使うべきですか?

新規に環境を作るならrbenvです。RVMの最終リリースは2021年1月15日の1.29.12で5年以上更新が止まっており、rbenvの公式wikiも利用を勧められないと明記しています。Ruby以外の言語も同じ仕組みで管理したい場合は、RVMではなくmiseを比較対象にしてください。

rbenv installコマンドが見つからないのはなぜですか?

rbenv installはrbenv本体ではなくruby-buildプラグインが提供するコマンドだからです。Homebrewではruby-buildがrbenvの必須依存なのでbrew install rbenvだけで入りますが、gitで手動導入した場合は"$(rbenv root)"/plugins/ruby-buildにruby-buildをクローンする必要があります。

rbenv rehashは手動で実行する必要がありますか?

通常は不要です。gemのインストール後にshimsの再生成は自動で走ります。ただしrbenv 1.3.0以降、rbenv initが書き込む設定にはシェル起動時の再生成を止める--no-rehashが既定で付くため、シェルを開き直しただけでは再生成されません。新しく入れたコマンドが見つからないときだけrbenv rehashを実行してください。

関連記事

お気に入りに入れた記事の一覧

資料請求

RELATED POSTS 関連記事

目次