Ruby on Rails（Rails）7.2は2024年8月9日にリリースされた版で、開発コンテナ設定の生成やPumaスレッド数の既定変更など、アプリの「作り始め」と「本番の既定値」に踏み込んだ変更が中心でした。そして2026年8月9日をもって、この7.2系はセキュリティ修正の提供期限に到達しました。いま7.2で動いているアプリに必要なのは新機能の紹介ではなく、7.2が何を変えたのかの把握と、8.0または8.1へどう移すかの判断です。公式ガイド・公式告知・RubyGemsの実データだけを根拠に整理します。
まとめ
- Rails 7.2系のセキュリティ修正提供は2026年8月9日まで。Rails公式が2025年10月29日の告知で明示しています。
- 7.2系の現時点の最新版は7.2.3.2（2026年7月29日、CVE-2026-66066対応）。バグ修正の提供はそれ以前に終了済みです。
- 7.2の主な変更は、devcontainer設定の生成、allow_browserによるブラウザ制限、Pumaスレッド既定値の5→3、トランザクション内でのジョブ登録の遅延、Ruby 3.1以上の要求。
- 移行先はRails 8.1系（バグ修正2026年10月10日まで／セキュリティ修正2027年10月10日まで）。8.0系はセキュリティ修正が2026年11月7日で切れます。
- 8.0・8.1はRuby 3.2.0以上を要求するため、Ruby 3.1で止まっている環境はRubyの更新が先に必要です。
Rails 7.2のサポート期限と2026年8月時点の位置づけ
Railsのメンテナンスポリシーは、マイナー系列ごとに「初回リリースから1年はバグ修正、2年はセキュリティ修正」と定めています。7.2.0の公開は2024年8月9日なので、バグ修正は2025年8月9日、セキュリティ修正は2026年8月9日が期限です。この日付はポリシーからの逆算ではなく、Rails公式ブログが2025年10月29日の「New Rails Releases and End of Support Announcement」で、サポート中の系列として明記しています。ただし次のマイナー版が1年以内に出なかった場合は支援期間が延長されるため、実際の期限は公式告知の日付が優先します。
| 系列 | 初回リリース | バグ修正期限 | セキュリティ修正期限 | 公開済みの最新版 |
|---|---|---|---|---|
| Rails 7.2.x | 2024-08-09 | 終了済み | 2026-08-09 | 7.2.3.2（2026-07-29） |
| Rails 8.0.x | 2024-11-07 | 2026-05-07（6か月延長済み） | 2026-11-07 | 8.0.5.1（2026-07-29） |
| Rails 8.1.x | 2025-10-22 | 2026-10-10 | 2027-10-10 | 8.1.3.1（2026-07-29） |
7.2系が最後に受け取った修正は、2026年7月29日の7.2.3.2です。これはActive Storageのバリアント処理における任意ファイル読み取りとリモートコード実行（CVE-2026-66066）への対応で、8.0.5.1・8.1.3.1と同時に公開されました。同じ告知の中でRails側は、これより古い系列はサポート外であり少なくとも7.2系まで上げることを推奨する、と述べています（原文: “Older versions of Rails are unsupported, and users are recommended to upgrade to at least the 7.2 series.”）。裏を返せば、7.2は推奨ラインの下限であって安全圏ではありません。
ここは判断を曖昧にしない方がよい部分です。7.2で止め続ける合理的な理由はありません。期限を過ぎた系列で脆弱性が見つかった場合、公式のgemは出ず、x-y-stableブランチをGitで直接参照して自前で追従するか、修正を自社でバックポートするしかなくなります。7.0系・7.1系が2025年10月にそうなったのと同じ経路をたどります。移行の経路は1マイナー版ずつ踏むとしても、到達点は8.0ではなく、セキュリティ修正が2027年10月10日まで残る8.1に置いてください。
Rails 7.2で追加・変更された主要機能
新規アプリ生成時の既定変更
7.2はrails newが吐き出すものを大きく増やしました。開発コンテナ（devcontainer）設定の生成がその筆頭で、.devcontainer配下にDockerfile・docker-compose.yml・devcontainer.jsonを作ります。既定でRedisコンテナ、データベース（SQLite／PostgreSQL／MySQL／MariaDB）、システムテスト用のヘッドレスChrome、ローカルディスクを使うActive Storageが含まれます。
# 新規アプリを開発コンテナ付きで生成
rails new myapp --devcontainer
# 既存アプリに後から追加する
rails devcontainerあわせて、PWA用のmanifestとService Workerの雛形がapp/views/pwaに生成され、ルーティングにも明示的にマウントされます。静的解析まわりでは、rubocop-rails-omakaseのルール一式を入れたRuboCop設定、GitHub Actionsのワークフローファイル、セキュリティ静的解析のBrakemanが新規アプリに標準で入るようになりました。CIとセキュリティスキャンが初回コミットの時点で動く状態が既定になった、という変更です。エディタ側の環境構築とあわせて整えるなら、ruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Containerで拡張機能とDev Containerの接続手順を確認してください。
実行時の既定値の変更
本番挙動に直接効く変更が3つあります。1つ目はPumaのスレッド数で、既定が5から3に下がりました。Rails側の説明は明快で、SQLが速くサードパーティ呼び出しをジョブに逃がしている「よく最適化されたRailsアプリ」では、スレッドを増やすほどGVL（Global VM Lock）の解放待ちが増え、レイテンシを悪化させるためです。既存アプリのconfig/puma.rbは自動では書き換わらないので、7.2の既定に合わせるなら明示的に下げます。
# config/puma.rb（7.1世代のテンプレートを手直しする場合）
threads_count = ENV.fetch("RAILS_MAX_THREADS") { 3 }
threads threads_count, threads_count
# 7.2の新規生成テンプレートはこの形
threads_count = ENV.fetch("RAILS_MAX_THREADS", 3)
threads threads_count, threads_count2つ目はYJITで、Ruby 3.3以上で動かしている場合に既定で有効になります。3つ目は既定のDockerfileにjemallocが組み込まれた点で、メモリ確保の断片化を抑える目的です。いずれも「7.2に上げた瞬間に本番の性能特性が変わりうる」変更なので、移行時はスループットとメモリ使用量を同時に見てください。
トランザクションとジョブの挙動変更
Active Jobの事故として定番だった「トランザクション内でジョブを登録し、コミット前に別プロセスが拾ってしまう」問題に、フレームワーク側の対処が入りました。config.load_defaults 7.2を有効にしたアプリでは、トランザクション内での登録がコミット後まで自動的に遅延され、ロールバックされた場合はジョブごと破棄されます。
Topic.transaction do
topic = Topic.create
# load_defaults 7.2 が有効なら、この登録はコミット後まで遅延される
NewTopicNotificationJob.perform_later(topic)
end
# ジョブ単位で遅延させない場合（Rails 8.1以降）
class NewTopicNotificationJob < ApplicationJob
self.enqueue_after_transaction_commit = false
endここは既存アプリで踏み外しやすい箇所です。ActiveJob::Base.enqueue_after_transaction_commitのクラス属性そのものの初期値は7.2でも:never（＝即時登録）で、load_defaults 7.2がこれを:defaultに切り替えることで遅延が働きます。7.1から上げただけでload_defaultsを据え置いたアプリは、7.2で動かしていても従来どおり即時登録のままです。
設定値の書き方はその後2回変わっています。:never・:always・:defaultのシンボル指定はRails 8.0で非推奨警告の対象になり、8.1で削除されてtrue／falseだけになりました。8.1で:neverと書いても警告や例外は出ず、シンボルが真として評価されるため「遅延させない」つもりが「遅延する」に反転します。移行の際は必ずfalseへ置き換えてください。
同時に、ActiveRecord::Base.transactionがトランザクションオブジェクトを引数に渡すようになり、レコードの外側からコミット／ロールバック時のコールバックを登録できるようになりました。after_commitをモデルに書かずに済むため、通知や外部連携をトランザクション境界に紐づけたいときに使えます。
Article.transaction do |transaction|
article.update(published: true)
transaction.after_commit do
PublishNotificationMailer.with(article: article).deliver_later
end
end遅延を無効化できるのはアダプタ側も同じで、enqueue_after_transaction_commit?がfalseを返すアダプタでは遅延しません。ただしこの判定の既定値はtrueで、falseを返しうるのはActive Recordと同じデータベースを使いトランザクションを認識できるアダプタの方です。SidekiqのようにRails外のバックエンドを使っている場合はむしろ遅延が効く側になります。ジョブ基盤そのものの選び直しを含めて検討するなら、Rails Active Jobとは？非同期ジョブ処理の実装とSolid Queue・リトライ設定が判断材料になります。
allow_browserによるブラウザ下限バージョンの宣言
コントローラ単位で、アクセスを許可するブラウザの下限バージョンを宣言できるallow_browserが追加されました。条件を満たさないブラウザにはpublic/406-unsupported-browser.htmlがHTTPステータス406で返ります。User-Agentを送らないクライアントや未知のブラウザは許可される仕様なので、これはボット遮断の仕組みではありません。
class ApplicationController < ActionController::Base
# webp・web push・import maps・CSSネスト・:has をネイティブ対応する版のみ許可
allow_browser versions: :modern
end
class MessagesController < ApplicationController
# showアクションだけ、さらに厳しい下限を課す
allow_browser versions: { opera: 104, chrome: 119 }, only: :show
endRuby 3.1が最低要件になったポリシー変更
7.2はRubyの最低要件を3.1.0に引き上げました。単なる要件変更ではなく、Rails側のポリシー変更を伴っています。従来はメジャー版でしか古いRubyを切りませんでしたが、7.2以降は「リリース時点でEOLを迎えているRubyはマイナー版で切る」方針に変わりました。RubyGems上のrequired_ruby_versionでも、7.2系は3.1.0以上、8.0系と8.1系は3.2.0以上と明示されています。Rubyのバージョン更新をRailsの更新と別々に計画していると、この点で手戻りが出ます。
Rails 7.1から7.2へ上げる手順
7.1からの移行そのものは定型です。ただし2026年8月時点では、7.2をゴールにするのではなく8.1までの通過点として踏む前提で進めてください。Railsは飛び級のアップグレードを推奨しておらず、7.1→7.2→8.0→8.1と1マイナーずつ上げ、各段でテストを通すのが公式の手順です。
# 1. Rubyが3.1以上か確認する（7.2の最低要件）
ruby -v
# 2. Gemfileのバージョン指定を上げる
# gem "rails", "~> 7.2.3"
bundle update rails
# 3. 設定ファイルの差分を対話的に取り込む
bin/rails app:update
# 4. 新しい既定値を有効化する
# config/application.rb の load_defaults を 7.2 に更新
# 5. テストを通す
bin/rails testbin/rails app:updateは設定ファイルの差分を提示するだけで、config/puma.rbのような既存ファイルを黙って書き換えはしません。前述のスレッド数やYJITのように「新規アプリだけが受け取る既定」があるため、既存アプリではconfig/initializers/new_framework_defaults_7_2.rbと各設定ファイルを個別に見比べる作業が必要です。テスト網羅率が低い状態で始めると差分の影響を検知できないので、移行前にテストを厚くしておくことが公式ガイドでも最初に挙げられています。モデルが肥大化していて移行時の影響範囲が読めない場合は、RailsのFat Model対策｜1500行model.rbを分割する4手法と判断基準の分割手法を先に当てておくと差分の切り分けが楽になります。
Rails 8.0・8.1へ移行する場合の判断材料
8.0の目玉は依存サービスの削減です。Solid Cache・Solid Queue・Solid Cableという3つのデータベース基盤アダプタが入り、キャッシュ・ジョブ・WebSocketのためにRedisを別途立てる必要がなくなりました。Solid QueueはMySQL 8以降・MariaDB 10.6以降・PostgreSQL 9.5以降でFOR UPDATE SKIP LOCKEDを使いロック待ちを避ける設計で、それ以前の版やSQLiteでも動作します。デプロイ面ではKamal 2とThrusterが既定構成に組み込まれ、Pumaの前段にNginxを置かずにコンテナのまま公開できる形になりました。この構成の実際の組み立てはKamal 2とThrusterを使用した最新デプロイメントの進化で扱っています。
8.1は運用寄りの機能が中心です。長時間ジョブをステップに分割し、再起動後に最後の完了ステップから再開できるActive Job Continuations、Rails.event.notifyで構造化イベントを出力するEvent Reporter、テストスイートをローカルマシンで並列実行するLocal CIが追加されました。Kamalでのデプロイ時にジョブ実行コンテナへ与えられる猶予（設定キーdrain_timeoutの既定値）が30秒しかないことを踏まえた設計で、7.2世代のジョブ運用をそのまま持ち込むより素直に噛み合います。
移行順の判断は単純です。8.0はセキュリティ修正が2026年11月7日で切れ、バグ修正は2026年5月7日で既に終わっています。つまり8.0を終着点に選ぶと、移行完了の数か月後に同じ作業をもう一度行うことになります。8.0は通過点として扱い、8.1を到達点に置いてください。前提として必要なのはRuby 3.2.0以上です。Ruby 3.1で7.2を動かしている環境では、Rubyの更新が移行計画の最初のタスクになります。7.2のActive Record周りの変更点をもう一段細かく確認したい場合は、ActiveRecord 7.2とは何か？Rails 7.2で進化したORMの概要と注目ポイントを解説を参照してください。
よくある質問
Rails 7.2はいつまで使えますか？
セキュリティ修正の提供は2026年8月9日までです。Rails公式が2025年10月29日の告知で「Rails 7.2.x – Supported until August 9, 2026」と明記しています。バグ修正の提供はそれ以前に終了しており、期限後は脆弱性が見つかっても公式のgemは公開されません。
Rails 7.2を動かすのに必要なRubyのバージョンは何ですか？
Ruby 3.1.0以上です。RubyGems上の7.2.3.2でもrequired_ruby_versionは3.1.0以上になっています。移行先となるRails 8.0系・8.1系は3.2.0以上を要求するため、8系まで上げる計画ならRuby 3.2以上を前提に環境を組んでください。
既存のRails 7.2アプリに開発コンテナ設定を後から追加できますか？
できます。rails devcontainerコマンドが7.2で追加され、既存アプリに.devcontainer一式を生成します。新規作成時にrails new myapp --devcontainerを付け忘れた場合も、このコマンドで同じ構成を作れます。
Pumaのスレッド数が3に下がると処理能力は落ちませんか？
Rails側の変更理由は逆で、スレッドを増やしすぎるとGVLの解放待ちが増えてレスポンスタイムが悪化するためです。SQLが速く、外部API呼び出しをジョブに逃がしている構成では3が妥当という判断が示されています。ただし既存アプリのconfig/puma.rbは自動では変わらないため、実際に変更する際はレイテンシとスループットを計測してから決めてください。
Rails 7.2から8.1へ一気に上げても問題ありませんか？
公式が推奨するのは1マイナー版ずつ上げる手順です。7.2から8.0へ上げてテストを通し、その後8.1へ進めます。8.0はバグ修正が2026年5月7日、セキュリティ修正が2026年11月7日で切れるため、8.0で作業を止めず8.1まで到達させる計画にしてください。
