LASSIC Media らしくメディア
Ruby 3.1サポート終了、3.3系への移行を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Ruby 3.1は2025年3月26日公開の3.1.7を最後に、公式のセキュリティ修正提供が終了しました。
- Ruby 3.2も2026年3月27日公開の3.2.11を最後に同じ状態となり、Rails 8系の稼働にはRuby 3.2以上が要件です。
- YJITやBundler・gemの非互換を洗い出す移行検証には専門知識と工数が必要で、外部委託も選択肢の一つです。
目次
2025年3月、Ruby 3.1がEOL――3.2も2026年3月に終了
Ruby 3.1のサポート終了とは、Rubyコミュニティが2025年3月26日公開の3.1.7を最後に、3.1系への公式なセキュリティ修正の提供を終えた状態を指します*1。この3.1.7ではCVE-2025-27219をはじめとする複数の脆弱性が修正されており、EOL後は同種の修正を受けられません*1。
Ruby 3.2も2026年3月27日公開の3.2.11を最後に、同じくセキュリティ修正の提供を終えました*2。3.2.11ではzlibのバッファオーバーフロー(CVE-2026-27820)が修正されており、これが3.2系にとって最後の対応です*2。本稿執筆時点で、Ruby 3.1・3.2はいずれもサポート対象外の状態にあります。
Rubyのライフサイクルには、バグ修正とセキュリティ修正の両方を受けられる「通常メンテナンス」と、セキュリティ修正のみに絞って提供する「セキュリティメンテナンス」という2つの段階があります*4。通常メンテナンスがおおむね2年、その後のセキュリティメンテナンスが約1年続き、合計3年3か月ほどでEOLに至る設計です*4。Ruby 3.1・3.2はこの両段階をすでに終え、次の段階であるEOLに入っている状態です。
Rubyは2021年以降、毎年12月25日に新しいメジャーバージョンを公開する方針を続けています*4。各バージョンは通常メンテナンス期間を経てセキュリティメンテナンス期間に移り、その後EOLを迎える3段階のライフサイクルをたどります*4。主なバージョンの状況を整理すると、次の通りです*1*2*3*4*5。
| バージョン | 公開日 | 現在の状態 |
|---|---|---|
| 3.1 | 2021年12月25日 | EOL(2025年3月26日) |
| 3.2 | 2022年12月25日 | EOL(2026年3月27日) |
| 3.3 | 2023年12月25日 | セキュリティメンテナンス(2027年3月末に終了予定) |
| 3.4 | 2024年12月25日 | 通常メンテナンス中 |
| 4.0 | 2025年12月25日 | 通常メンテナンス中 |
セキュリティ修正停止とRails 8系利用不可――放置のリスク
Ruby 3.1・3.2がEOLとなった状態で稼働を続けると、新たに見つかった脆弱性への公式パッチは提供されません*1*2。個人情報や決済情報を扱うシステムでは、この状態自体が監査や取引先からの指摘対象になりかねません。
加えて、Ruby on Railsの最新版であるRails 8.0・8.1はRuby 3.2.0以上を要求します*6。Ruby 3.1のまま稼働するシステムは、Railsの新しいセキュリティ対応やフレームワーク機能を取り込めない状態が続きます。Ruby 3.2もEOLとなった以上、実務上は3.3系以降への移行が前提になっているといえるでしょう。
移行の着手が遅れるほど、稼働中バージョンと最新バージョンの間に積み重なる仕様変更は増えていきます。Bundler・gemの依存関係やYJITまわりの挙動差を含め、確認すべき項目は単純な新機能の把握にとどまりません。
YJIT高速化・Prismパーサ――Ruby 3.3系での変更点
YJITの高速化――インタプリタ比3倍のベンチマーク
Ruby 3.3では、JIT(実行時にコードを機械語へ変換して高速化する仕組み)コンパイラのYJITが大きく改善されました*7。公式ベンチマーク(Optcarrot)では、インタプリタ比で3倍を超える速度が計測されています*7。YJIT自体はRuby 3.1で実験的に導入された機能であり、3.3系で実運用水準の性能に達したと位置づけられます*7。
あわせて、コード生成後に使われなくなった領域を回収するコードGCが既定で無効化され、メモリ使用量を抑えつつコピーオンライトの効率を高める設計に変わりました*7。Railsの側でも、Ruby 3.3以上と組み合わせた場合にYJITを既定で有効化する対応が進められています。
Prismパーサとスレッドスケジューラ――構文解析・並行処理の刷新
構文解析についても、新しいデフォルトgem(Rubyの外部ライブラリ)であるPrismパーサが3.3系から採用されました*7。エラー耐性の高い構文解析器で、既存のパーサ生成の仕組みも刷新されています*7。従来のMJITに代わる純Ruby実装のJITであるRJITも導入されましたが、こちらは実験的な位置づけにとどまり、本番運用にはYJITが推奨されています*7。
スレッド管理の面では、複数のRubyスレッドを少数のネイティブスレッドで動かすM:Nスレッドスケジューラが加わりました*7。C拡張gemとの互換性を優先し、メインのRactor(並行実行の単位)では既定で無効化されています*7。YJITの改善やスレッド周りの変更は、C拡張gemとの組み合わせで挙動が変わる場合があるため、移行前に自社が利用するgemの対応状況を確認しておくことが欠かせません。
Ruby 3.4・4.0で加わった機能――移行先を選ぶ材料
Ruby 3.4は2024年12月25日に公開され、Prismが構文解析の標準パーサとして定着するなど、3.3系の変更をさらに進める内容になっています*4。2025年12月25日に公開されたRuby 4.0では、モンキーパッチや定数変更の影響範囲を分離する実験的機能Ruby Box、YJITの後継として開発が進む新しいJITコンパイラZJITが加わりました*5。
3.3系は2027年3月末までセキュリティメンテナンスが続く見込みで、当面の移行先として選べます*3。ただし次の移行までの猶予を長く確保したい場合は、通常メンテナンス中の3.4系や4.0系も候補に含めて検討する価値があるでしょう*4。
Bundler・gem・Railsの非互換確認――移行前に洗い出す項目
移行先を選ぶ際には、稼働中のRailsバージョンが要求するRubyバージョンを先に確認する必要があります*6。公式ガイドが示す対応関係を整理すると、次の通りです*6。
| Railsバージョン | 必要なRubyバージョン | 備考 |
|---|---|---|
| 7.0 / 7.1 | 2.7.0以上 | 3.1・3.2はいずれもEOL済み |
| 7.2 | 3.1.0以上 | 3.1自体はすでにEOL |
| 8.0 / 8.1 | 3.2.0以上 | 3.2も2026年3月にEOL |
Railsのバージョン要件を満たすだけでは、移行の準備が終わったことにはなりません。Bundler(Rubyのgem依存関係を管理する仕組み)が扱うgemの中には、特定のRubyバージョンを前提に依存関係を宣言しているものがあるからです。対応が古いままのgemが残っていると、bundle install実行時にバージョン不一致のエラーが発生することがあります。
移行前の点検としては、bundle outdatedで各gemの最新対応状況を洗い出す作業や、ruby -W:deprecatedで非推奨機能の利用箇所を検出する作業が有効です。既存のテストスイートを新しいRubyで再実行し、警告やエラーの内容を1件ずつ確認する工程も欠かせません。
CI/CDパイプラインのRubyバージョン指定や、Dockerfileのベースイメージも合わせて見直す対象になります。テスト環境と本番環境でRubyバージョンがずれていると、移行後に想定外の挙動差が生じる原因になりやすいものです。Gemfile.lockに記録された依存関係も、移行後のバージョンで一度再生成して整合性を取り直す必要があります。
内製移行の負荷と外部委託という選択肢
Ruby 3.1・3.2からの移行を内製で進めるには、gem単位の依存関係調査、YJITやBundlerの仕様変更の把握、検証環境での移行リハーサルという複数の工程を担うスキルが必要です。これらを兼務の1名で対応する体制では、通常業務と並行しての作業が滞りやすい傾向があります。
検証環境でエラーが解消できても、本番切替時の監視体制や切り戻し手順の準備には別途工数を要します。連携するgemの数が多いシステムほど、洗い出しから検証までの工程は長くなりやすいといえるでしょう。専任担当を置けない体制では、通常の開発案件と移行作業が競合し、どちらも中途半端になりかねません。
外部パートナーに委託する場合は、非互換の洗い出しから検証環境の構築、切替時の対応、切替後の監視までを一括して依頼できるかどうかが選定の分かれ目になります。内製は既存体制をそのまま活用できる一方、外部委託は専門知識を持つ体制に短期間で対応を任せやすいという違いがあります。
| 項目 | 内製で進める場合 | 外部委託する場合 |
|---|---|---|
| 実施体制 | 既存エンジニアが通常業務と兼務 | 移行実務の経験を持つ体制に依頼できる |
| 非互換調査 | gem・Rails・YJITの対応状況を自社で1件ずつ確認 | 洗い出しから検証まで一括で依頼できる |
| スケジュール | 通常業務と並行するため長期化しやすい | 専任体制のため短期間での対応を見込める |
まとめ：Ruby 3.1移行で押さえる3つの判断軸
本稿ではRuby 3.1のサポート終了(EOL)を起点に、移行先の選び方と技術的な変更点を整理しました。要点は次の3つです。第一に、Ruby 3.1は2025年3月26日にEOLとなり、2026年3月27日にはRuby 3.2も同じ状態を迎えました。第二に、Rails 8.0・8.1はRuby 3.2.0以上を要求するため、移行先には3.3系だけでなく3.4系・4.0系も含めて検討する必要があるでしょう。第三に、YJITやBundler・gemの非互換を洗い出し、検証から切替までを内製で担うには専門知識と工数が必要で、社内リソースとの兼ね合いで外部委託も判断材料になります。
よくある質問
Ruby 3.1を今のまま使い続けるとどうなりますか。
Ruby 3.1は2025年3月26日公開の3.1.7を最後に、公式のセキュリティ修正提供が終了しています*1。そのため新たに脆弱性が見つかっても修正パッチを受けられません。Ruby 3.2も2026年3月にEOLとなっており、稼働を続けるほど対応すべき非互換も積み重なりやすくなります。
移行先はRuby 3.3系と3.4系のどちらを選ぶべきですか。
Ruby 3.3は2026年3月からセキュリティメンテナンス期間に入り、2027年3月末に公式サポートが終わる予定です*3。Ruby 3.4は2024年12月に公開された通常メンテナンス中のバージョンで*4、次の移行までの猶予を長く確保したい場合は3.4系や4.0系も候補になります。
Ruby 3.3系への移行で特に確認すべき変更点は何ですか。
JITコンパイラYJITの性能向上と、デフォルトの構文解析器がPrismパーサに変わった点です*7。加えてRails 8.0・8.1はRuby 3.2.0以上を要求するため*6、利用中のRailsバージョンとgemの対応状況をあわせて確認する必要があります。
移行を外部委託する場合、何を確認すればよいですか。
検証環境の構築範囲、gem・Bundlerの非互換調査の進め方、切替時の立ち会い体制、障害発生時の切り戻し手順を委託先とすり合わせることが大切です。契約前に成果物と検証項目を明確にしておくと、後工程の手戻りを防ぎやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Ruby「Ruby 3.1.7 Released」（https://www.ruby-lang.org/en/news/2025/03/26/ruby-3-1-7-released/）（2025年）
- *2 出典：Ruby「Ruby 3.2.11 Released」（https://www.ruby-lang.org/en/news/2026/03/27/ruby-3-2-11-released/）（2026年）
- *3 出典：Ruby「Ruby 3.3.11 Released」（https://www.ruby-lang.org/en/news/2026/03/26/ruby-3-3-11-released/）（2026年）
- *4 出典：Ruby「Ruby Maintenance Branches」（https://www.ruby-lang.org/en/downloads/branches/）
- *5 出典：Ruby「Ruby 4.0.0 Released」（https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-released/）（2025年）
- *6 出典：Ruby on Rails Guides「Upgrading Ruby on Rails」（https://guides.rubyonrails.org/upgrading_ruby_on_rails.html）
- *7 出典：Ruby「Ruby 3.3.0 Released」（https://www.ruby-lang.org/en/news/2023/12/25/ruby-3-3-0-released/）（2023年）
