はじめに

こんにちは、株式会社divxでエンジニアをしている黒です。
今回は、Ruby on Rails（以下Rails） のバージョンを7.0から7.2にマイナーバージョンアップした経験について記事を書かせていただきます。
Railsのバージョンアップを考えている方や実際に進めようとしている方にとって、この記事が実践的な参考資料となり、少しでもお役に立てれば嬉しいです。ぜひご一読ください。

バージョンアップを行った背景

今回はRailsを7.0から7.2にバージョンアップさせました。バージョンアップの背景として、現在のRails 7.0.4が2025年4月1日にサポート終了となり、サポートが終了すると新しいセキュリティ更新やバグ修正が受けられなくなる可能性があるため、より安全な開発環境を保つことを目的にバージョンアップを行いました。
Rails 7.2を選定した理由として、クライアントとのバージョン選定時点の最新安定バージョンがRails 7.2であり、継続的な更新や修正が受けられるサポート期間が2026年8月9日まで続くこと、マイナーバージョンアップであることをプロジェクトの現状と照らし合わせて、Rails 7.2が今は最適だと判断したためでした。
また、バージョンを選定するにあたって、そのバージョンが本当に自分たちのアプリにマッチしているかどうかをしっかり調べることも大切です。単に新しいバージョンにするだけでなく、アプリの今後にどんな影響があるかを考慮する必要があり、今回はテスト環境での動作確認や新機能の調査をし、すべてが問題ないことを確認した上でバージョンアップを行いました。

バージョンアップとは

バージョンアップを行うメリットについて

バージョンアップは、Railsだけでなく多くのプログラミング言語やライブラリにとって、避けて通れない重要な作業の一つです。
一度にまとめてバージョンアップすれば良いと考えている方は要注意です。まとめてバージョンアップを行うと多くのエラーが発生し、そのエラーを解消することだけでも膨大な時間がかかってしまう懸念があります。
さらに、サポートが切れたバージョンのまま放置すると、新機能が利用できなかったり、セキュリティリスクが増大する恐れがあります。予期しない問題が発生することを防ぐためにも定期的にバージョンアップを行うことをお勧めします。

信用できる情報選びについて、実際に参考にした記事

どんなに優秀なエンジニアでも情報なしで作業を進めることは難しくリスクを伴うため、多くのエンジニアは作業を進める際に様々な記事やサイトを参考にすると思います。しかし、どのサイトの情報が正確で信頼できるか判断するのは正直言って難しいと感じるかもしれません。特にバージョンアップにおいて、正しい情報を得ることはとても重要になります。
そこで、必ず確認するべきは一次情報であるRailsの公式サイトです。
Railsの公式サイトには、最新の情報や公式のガイドラインが詳しく掲載されています。公式サイトであることから、掲載情報の信頼性は高く他の情報源よりも優先して参考にする価値があります。

Railsバージョンアップ手順

では、私が実際にバージョンアップを行った手順を記載していきます。今回はRailsを7.0から7.2にバージョンアップするために、以下のステップを踏みました。それぞれの段階で重要なポイントを説明します。
まず、Railsのバージョンアップを行う前に、Rubyのバージョンを最新のものにバージョンアップさせることが重要であり、今回はRubyを3.1から3.2にバージョンアップさせました。より新しいRubyのバージョンを使用することは、公式でも推奨されており、新機能やセキュリティ向上のメリットがあります。
また、Railsのバージョンを上げる際には、できる限り1つずつ段階的にバージョンを上げ、それぞれの段階でテストを行うことを推奨します。7.0から7.1にアップデートし、その後7.2に進むことで、移行時の互換性問題を適切に対処することができます。

手順

この手順では、Docker上でRubyとRailsの環境をアップデートする方法を説明します。以下の内容は、Dockerを利用した開発環境を前提としていますが、Dockerを利用していない場合は適宜調整してください。また、「※注意」の記載がある箇所はエラーが出やすい箇所となるので、確認しながら行ってください。

1.Docker設定の更新

• Dockerfile内で使用されるRubyのバージョンを更新しました。新しいバージョンのRubyをDocker環境で使用するための設定です

• Gemfile: Rubyのバージョンを変更しました。これは、Bundlerが正しいバージョンのRubyを使用するために必要な設定です。

# Dockerfile
FROM ruby:3.2

# Gemfile
ruby '3.2.0'

2.Dockerの再ビルド

• Dockerコンテナをが起動している際は停止してから行うことを推奨します。
• docker-compose build --no-cache を用いて再ビルドしました。このステップでは、新しい設定が反映されない場合や依存関係の問題（例えば、Gemのバージョン不一致など）でエラーが発生しやすいため、細心の注意を払って確認しました。エラーが発生した場合は、エラーメッセージを確認し、必要に応じてGemfileの依存関係を調整することをお勧めします。※注意

docker-compose build --no-cache

3.GemfileのRailsバージョン更新

• Gemfile Railsのバージョンを希望する新しいバージョンに設定しました。Railsをアップデートするための準備ステップです。

4.Railsのバージョンアップ

• docker-compose up -d でAPIコンテナを起動し、コンテナ内で bundle update rails を実行することで、Railsのバージョンとその依存関係を更新しました。このとき、bundle update を使うとすべてのGemが更新され、意図しない変更が起こる可能性があるため、注意が必要です。※注意

bundle update rails

5.動作確認

• RubyとRailsのバージョンをそれぞれ ruby -v と rails -v で確認しました。 rails s -u puma コマンドを用いてサーバーが正常に起動するかをテストしました。この過程で問題が起こることも多いので、迅速に対処できるよう準備しました。特に、依存関係の不整合や設定ミスが一般的な問題ですので、エラーメッセージを注意深く確認し、必要に応じて設定を見直すことが重要です。※注意

Rubyのバージョン確認　ruby -v 
Railsのバージョン確認　rails -v 

6.アップデートタスクの実行

• rails app:update を実行しました。rails app:updateコマンドを実行することで最新バージョン向けの設定ファイルが生成され、既存ファイルについては対話形式で変更することができます。Y/n/a/q/d/hのいずれかのキーを入力して選択肢を決定します。具体的には、マイグレーションファイルや初期設定ファイルなどが対象となりますので、それぞれの変更内容を慎重に確認しながら進めることが重要です。（下記はキーの意味になります。)

 rails app:update 

Y - Yes。上書き実行
n - No。上書きしない
a - All。このファイル以降の全ファイルを上書き
q - Quit。処理中断
d - Diff。新旧ファイルのdiffを表示
h - Help。入力する各キーの意味を表示

7.デフォルト設定の更新

• config/application.rb の config.load_defaults を新しいバージョンに変更しました。この更新により、Railsの新機能や設定がデフォルトで使えるようになり、再度動作確認を行いました。

8.再度動作確認を行う

• 動作に問題ないか確認します。

動作確認（テスト）の重要性

今回のバージョンアップで私は、チームのメンバーと協力し何度も動作確認を行いました。テストコードによる自動テストはとても重要ですが、それだけで安心することはできず、最終的な品質保証には人間による確認が不可欠です。バージョンアップ作業においても、次のようなテストは徹底的に行うべきだと思います。

• 単体テスト

  • システムを構成する最小単位（関数、メソッド、クラス、モジュールなど）に対して、個々の動作が設計通りかどうかを検証するテストです。

• 結合テスト

  • 単体テストをパスした各コンポーネントやモジュールを組み合わせ、そのインタフェースやデータ連携が正しく動作するかを検証するテストです。

• 総合テスト

  • システム全体を実際の運用環境やユーザシナリオに近い形で検証し、要件仕様通りに動作するかどうかを確認するテストです。

• モンキーテスト

  • あらかじめ定義されたテストシナリオや仕様にとらわれず、ランダムまたは予測不能な入力や操作をシステムに対して行い、予期しない動作やエラーが発生しないかを検証するテストです。

今回のバージョンアップでは、チームで入念に確認作業を進めました。たとえば、AからBへの移行は問題がないと確認しましたが、AからCへの移行も含めシステム全体への影響を考慮し、様々な角度から動作を検証しました。
バージョンアップ後は、ローカル環境で徹底的に動作確認を行いました。ローカル環境で問題がなくても、ステージング環境でエラーが発生することがあるため、ステージング環境でも細心の注意を払って確認しました。
また、クライアントからも、細かな動作確認を行った点についてポジティブなフィードバックをいただきました。やはり、今回のような確認プロセスが、高品質な成果物を提供するために重要だと私は思います。

詰まった箇所

Railsのバージョンアップの際はRubyのバージョンアップも一緒に行う

Railsのバージョンを上げる際にはRubyのバージョンも一緒に上げる必要があります。
新しいバージョンのRailsでは、特定の機能や動作が、最新のRubyのバージョンに依存していることがあることが理由の一つとして挙げられます。Railsが想定する最適な動作を引き出すためには、Ruby自体の新しいバージョンが必要になる場合があります。

to_sメソッドが推奨されなくなったことについて

修正箇所

今回のバージョンアップを行いその影響で、メールテンプレートの中で通貨などの数値フォーマットにおいて使用されている部分にエラーが発生しメールを送信できなくなってしましました。

修正案

Rails 7では、数値オブジェクトに対してto_sメソッドを用いてシンボルを指定しフォーマットを行う方法が非推奨となり、to_formatted_sメソッドを使用することが推奨されるようになりました。
しかし、Rails 7では、to_sメソッドの使用は引き続き可能ですが、特定のフォーマットを行う場合にはto_formatted_sメソッドの使用が推奨されます。

例)

修正前
金額：<%= @purchased_data.total_price.to_s(:delimited)%>円

修正後
金額：<%= @purchased_data.total_price.to_formatted_s(:delimited) %>円

enumの使い方に関するメソッドが推奨されなくなったことについて

修正箇所

整数値を直接enumに割り当てて意味を付与する従来の手法が非推奨となったため、コードの互換性に問題が生じました。例えば、0を「男性」、1を「女性」とするような表現を使用していましたが、この手法が非推奨となったことで、コードが正常に動作しない場合やエラーが発生するケースが出てきました。

修正案

• PurchasedRoom モデルで seat_type と adult_or_child を定義する際に、データベースにそれぞれのカラムを追加し、enum が期待通りに動作することを確認しました。

• 新しい記法を使用し、位置引数を用いて enum の定義を行います。公式情報でも推奨される書き方となっており、より明確に定義できます。

例)

class PurchasedRoom < ApplicationRecord
  # seat_typeとしてのenumの定義
  enum seat_type: {
    standard: 0,
    premium: 1,
    deluxe: 2
  }, _prefix: true

  # adult_or_childとしてのenumの定義
  enum adult_or_child: {
    adult: 0,
    child: 1
  }, _prefix: true

  # バリデーションの例（任意）
  validates :seat_type, presence: true
  validates :adult_or_child, presence: true

  # その他のメソッドやロジック
end

まとめ

今回のRailsのバージョンアップでは、バージョン7.0から7.2への移行を無事に完了させ、サポート切れによるリスクを回避させることができました。
今回のバージョンアップ作業を通して、正確な情報源を選んで活用することがとても重要だと改めて気付かされました。特に一次情報である「Rails公式サイト」を活用することで、信頼できる情報に基づいた準備ができ、大きな助けとなりました。
また、手動での動作確認の重要性も再認識しました。自動テストだけでは確認できない細かな動作を人間の目でチェックすることにより、アプリの質をしっかりと維持することができました。
さらに嬉しいことに、クライアントからのこのバージョンアッププロセスに対する評価は高く、ポジティブなフィードバックを頂くことができました。
今回のバージョンアップの経験が、Railsのバージョンアップを検討している方々にとって参考になれば幸いです。

お気軽にご相談ください