LASSIC Media らしくメディア

2026.10.20 らしくコラム

Rails 7.2のEOLとバージョンアップ|外注の確認ポイント

監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

会議室の机でノートPCの横の移行計画の紙を、外部の技術者と担当者が指でたどっている

この記事の結論

  • Rails 7.2のセキュリティ修正は2026年8月9日までで、9月24日公開の7.2.4が最後の版です。
  • 8.0系の期限も2026年11月7日と近いため、移行先は2027年10月10日まで続く8.1系が現実的です。
  • 自動テストと依存ライブラリを先に確かめ、Rubyを先に上げてから1段ずつ版を上げます。

※ 本記事は2026年10月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。

Rails 7.2のサポートが終わったと聞いたが、自社のシステムに何が起きるのか分からない。版を上げたいが、社内にRailsに詳しい人がいない——。Ruby on Rails(Webアプリを作るための仕組み)で業務システムを動かしている会社では、こうした悩みが起こりがちです。Rails 7.2のEOL(End of Life)とは、7.2系の版に公式のセキュリティ修正が出なくなることを指します。

EOLを迎えても、システムがすぐに止まるわけではありません。ただし、新しく見つかった弱点への修正は、サポート中の版にしか出なくなります。本記事では、Railsで作ったシステムを担当する情報システム部門の方に向けて、7.2のEOLの期限、移行先の版の違い、バージョンアップの進め方、そして外注するときに確認したい点を整理します。

Rails 7.2のEOLとは

Railsの開発チームは、版ごとのサポート期間をメンテナンスポリシーとして公式サイトで公開しています。サポートは新機能・不具合の修正・セキュリティの修正の3つに分かれ、期間はそれぞれの系列の最初のリリースから数えます。*1

  • 不具合の修正は、系列の最初のリリースから1年間です
  • セキュリティの修正は、最初のリリースから2年間です。これを過ぎた版がEOLになります
  • Rails 7.2は2024年8月10日に公開されました*5
  • 7.2系のセキュリティ修正は、2026年8月9日までと公式に案内されていました*2
  • 2026年9月24日公開の7.2.4が7.2系の最後のリリースで、以後の修正は8.0系と8.1系にだけ出ます*3

サポートが終わった版の不具合やセキュリティの問題は、利用者が自分で対処することになると公式は説明しています。自分で版を保守できないなら、サポート中の版へ上げるよう勧めています。*1 2026年7月には、ファイルの保存を扱うActive Storageという機能の脆弱性(セキュリティ上の弱点)に対する修正が、7.2・8.0・8.1の各系列に出ました。*6 7.2.4の後は、こうした修正が7.2系に出ることはありません。

移行先となる版の違い

7.2から上げる先は、いまサポートが続いている8.0系か8.1系です。2つの版は必要なRubyの版が同じですが、セキュリティ修正の期限が1年近く違います。

並べた2枚の比較表の片方にペンで印を付けようとしている手元

Rails 7.2・8.0・8.1の違い(公式のメンテナンスポリシーとアップグレードガイドから作成)
版 必要なRubyの版 セキュリティ修正の期限
Rails 7.2 3.1以上 2026年8月9日(終了)
Rails 8.0 3.2以上 2026年11月7日
Rails 8.1 3.2以上 2027年10月10日

8.0系の期限は2026年11月7日、8.1系は2027年10月10日です。*1 これから計画するなら、8.1系を目標にするのが現実的です。8.0は通過点として扱い、そこで止めない計画にしておくと、短い間隔で2度目のバージョンアップに追われずに済みます。8.0系の不具合修正の期間が延びたように、*2 期限は変わることがあるため、公式のページで最新の値を確かめておきます。

バージョンアップの進め方

公式のアップグレードガイドは、版を一気に上げず、マイナーバージョン(7.2から8.0のような版の段)を1つずつ上げることを勧めています。*4 1段ずつ上げれば、次の版で使えなくなる機能を知らせる「非推奨の警告」を手がかりに、直す場所を絞り込めます。

  • ステップ1:自動テストを整え、すべて通る状態にする
  • ステップ2:Rubyを先に上げる(Rails 8.0と8.1はRuby 3.2以上が必要です)
  • ステップ3:7.2の最新の修正版に上げてから、8.0、8.1の順に1段ずつ上げる
  • ステップ4:新しい版の初期設定を、数回の公開に分けて少しずつ有効にする

Railsのバージョンアップを4つの段階で左から順に並べた流れ図。STEP1 テストを整える、STEP2 Rubyを先に上げる、STEP3 1段ずつ版を上げる、STEP4 初期設定を切り替える。

RubyとRailsを別々に上げるのも、ガイドの勧めです。*4 同時に上げると、不具合が出たときにどちらの変更が原因かを切り分けにくくなるため、別の作業として計画します。Ruby 3.1をお使いの場合のRubyの版上げはRuby 3.1サポート終了と移行で扱っています。また、Railsの版を上げただけでは、アプリは以前の版の初期設定のまま動きます。

テストと依存ライブラリの確認

バージョンアップがうまく進むかどうかは、作業の前に動作を確かめる手段がどれだけあるかで大きく変わります。ガイドは、自動テストが足りなければ変更された部分を手で確かめる必要があり、Railsの版上げではアプリのすべての機能がその対象になると述べています。*4 着手の前に、次の4点を確かめておきます。

  • 自動テスト:主要な画面と処理がテストで確かめられているか。足りなければ版上げの前に書き足す
  • 依存ライブラリ:使っているライブラリが8.0・8.1に対応した版を出しているか。更新が止まったものは置き換えを検討する
  • 非推奨の警告:テストの実行時やログに出る警告を一覧にし、件数が減っていくかを追う
  • 検証の環境:本番と同じ版のRubyとデータベースで動作を確かめられる環境があるか

なかでも依存ライブラリは見落とされやすい点です。Railsのアプリは、gem(Ruby用の部品となるライブラリ)を数多く組み合わせて動くのが一般的で、1つでも新しい版に対応していないと、バージョンアップはそこで止まります。

外注するときに確認しておきたい点

社内にRailsのバージョンアップを経験した人がいない場合、調査から移行までを外注するのも一つの方法です。見積もりを頼む前に、次の点を確かめておくと話が早く進みます。

夕方の西日が入る長机で、確認表に印を付けながら打ち合わせをしている2人

  • どこまで頼むか:テストの整備、Rubyの版上げ、Railsの版上げ、本番への反映のうち、どれを任せるか
  • 事前の調査:依存ライブラリと非推奨の警告を洗い出す調査を、移行の前に別の段階として設けるか
  • 段階の切り方:7.2から8.0、8.0から8.1のどこで本番に反映し、各段階で何を確かめて次に進むか
  • テストの扱い:自動テストを誰が書き足し、版上げの後も自社に残すか
  • 公開後の保守:8.1の期限を見据えて、次の版上げを誰がいつ計画するか

Railsは半年ごとに新機能を含む版を出すことを目指しており、*1 バージョンアップは一度で終わる作業ではありません。保守の契約に版上げの計画まで含めておくと、次のEOLの直前に慌てずに済みます。

まとめ:Rails 7.2で確かめたい3つの点

Rails 7.2のバージョンアップを進めるうえで、確かめておきたい点は3つに整理できます。第一に、7.2系にはもう修正が出ないことを踏まえ、移行先を8.1系に置くこと。第二に、自動テストと依存ライブラリの対応状況を、作業の前に確かめること。第三に、Rubyを先に上げ、Railsは1段ずつ上げる計画を立てることです。この3点を踏まえておけば、「8.0に上げたところで、すぐにまた期限が来てしまった」という事態を避けやすくなります。調査や移行の進め方に迷いがあれば、外注して外部の手を借りるのも一つの選択肢です。

LASSICに相談するメリット

LASSICは2006年の創業以来、システムの運用・保守に特化したプライム(一次請け)のシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。日本ニアショア開発推進機構の認定ベンダーとして、全国のリモート人材による開発・運用の体制を整えています。

Railsのバージョンアップでは、BundlerでGemfile.lockに固定された依存ライブラリの版を一覧にし、Rails 8.0・8.1に対応した版の有無を1つずつ確かめます。テストはMinitestやRSpecの実行結果と、テストの実行時やログに出る非推奨の警告を記録し、版ごとに警告が減ったことを確かめてから次の段へ進みます。設計の判断点は、RubyとRailsを上げる順序、本番へ反映する区切り、新しい初期設定を切り替える順番の3つです。検証では本番と同じ版のRubyとデータベースを用意し、Active Storageなど本番で使っている機能の動作を確かめます。運用では、Brakemanによる静的解析と公式のセキュリティ告知の確認を手順にし、次の版上げの時期を保守計画に組み込みます。

よくある質問

EOLを迎えたRails 7.2のアプリはすぐに動かなくなりますか

すぐに動かなくなるわけではありません。ただし、新しく見つかった不具合やセキュリティの問題への修正は出ないため、利用者が自分で対処することになります。外部に公開しているシステムほど、早めに移行の計画を立てておくと、修正が出ない期間を短くできます。

8.0に上げたところで止めてもよいですか

8.0系のセキュリティ修正は2026年11月7日までと案内されています。止めると短い間隔で次のバージョンアップが必要になるため、8.0は通過点として8.1まで上げる計画にするのが現実的です。

外注の見積もりは何をもとに決まりますか

作業の量は、自動テストがどこまで整っているか、依存ライブラリをいくつ使っていて新しい版に対応しているかで大きく変わります。最初に小さな調査を頼み、その結果をもとに移行の見積もりを出してもらうと、比べやすくなります。

Railsのバージョンアップのご相談

Rails 7.2からのバージョンアップについて、テストと依存ライブラリの調査から段階的な移行、公開後の保守まで、元請(プライムベンダー)としてご提案します。

2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。

無料相談はこちら

出典

  1. *1 参考:Ruby on Rails「Maintenance policy」(https://rubyonrails.org/maintenance)。出典:新機能・不具合修正・セキュリティ修正の期間、サポート延長の決まり、サポート中の版の期限、サポート終了後の扱いを参照(2026年10月20日確認)(2026年10月確認)
  2. *2 参考:Ruby on Rails「New Rails Releases and End of Support Announcement」(2025年10月29日)(https://rubyonrails.org/2025/10/29/new-rails-releases-and-end-of-support-announcement)。出典:Rails 7.2.xのセキュリティ修正の期限(2026年8月9日)と、Rails 8.0のサポート延長を参照(2026年10月確認)
  3. *3 参考:Ruby on Rails「Rails Version 7.2.4 has been released!」(2026年9月24日)(https://rubyonrails.org/2026/9/24/Rails-Version-7-2-4-has-been-released)。出典:7.2.4が7.2系の最後のリリースであること、以後の修正は8.0系と8.1系に限ることを参照(2026年10月確認)
  4. *4 参考:Rails Guides「Upgrading Ruby on Rails」(https://guides.rubyonrails.org/upgrading_ruby_on_rails.html)。出典:テストの重要性、各版に必要なRubyの版、RubyとRailsを分けて上げる勧め、マイナーバージョンを1つずつ上げる手順、初期設定の切り替えを参照(2026年10月20日確認)(2026年10月確認)
  5. *5 参考:Ruby on Rails「Rails 7.2: Better production defaults, Dev containers, new guides design, and more!」(2024年8月10日)(https://rubyonrails.org/2024/8/10/Rails-7-2-0-has-been-released)。出典:Rails 7.2の公開日を参照(2026年10月確認)
  6. *6 参考:Ruby on Rails「Rails Versions 7.2.3.2, 8.0.5.1, and 8.1.3.1 have been released!」(2026年7月29日)(https://rubyonrails.org/2026/7/29/Rails-Versions-7-2-3-2-8-0-5-1-and-8-1-3-1-have-been-released)。出典:Active Storageの脆弱性に対する修正が7.2・8.0・8.1の各系列に出たことを参照(2026年10月確認)




View