Railsのバージョンアップ、上げるか作り直すか｜1段ずつしか上げられない仕組みと、段数・gem・テストで決まる費用

「開発会社から『Railsが古すぎて、このままでは手を入れられない』と言われた…」
「バージョンアップを頼んだら、見積もりの行がやけに多かった…」

Railsのバージョンアップをどう扱うかで、困っていませんか？
サービスは毎日動いている。止めるわけにはいかない。でも、作った人はもう社内におらず、どこまで古いのかも正確には分からない。
上げるのか、この機会に作り直すのか。どちらで見積もりを頼めばいいかが決まらないまま、時間だけが過ぎていきます。

本記事では、開発会社の立場から、Railsのサポートが終わると何が起きるかと、上げるか作り直すかを決める4つの目安を解説します。頼むときの進め方と、見積もりで費用が変わる所も書きます。発注する側が判断するための記事です。

Railsバージョンアップの悩み：こんなことありませんか？

「古い」と言われたが、どれくらい困るのかが分からない

保守を頼んでいる会社や、採用の候補者から「このRailsは古い」と言われます。今は問題なく動いているので、何がどう困るのかを社内で説明できず、後回しになりがちです。

「上げるだけ」のはずなのに、見積もりの行が多い

Railsの版を上げる作業を頼んだら、Rubyの更新、gem（部品）の入れ替え、JavaScriptのまとめ方の変更、動作の確認まで入った見積もりが届きます。なぜそこまで要るのかが分からないと、金額だけを見て止まってしまいます。

作った人がいない。上げるにも作り直すにも、誰に聞けばいいのか

最初に作ったエンジニアや開発会社がすでに離れていて、どのgemを何のために入れたのかが分かる人がいません。テストがどこまであるのかも分からず、上げる・作り直すのどちらの見積もりを頼むにも、前提が出せません。

3つとも、サポート終了で何が起きるかと、上げるか作り直すかの線を知れば整理できます。順に見ていきます。

Railsのサポート終了とは？放っておくと何が起きるか

サポート終了とは、その版のRailsに弱点が見つかっても修正が出なくなることです。終了した日にサービスが止まるわけではありません。ただ、放っておいた分だけ、上げるときの段数と費用が増えていきます。

Railsは版ごとに、修正が止まる期限が決まっている

Railsはおおむね1年に1回、新しい版（7.2・8.0・8.1 のような「系」）が出ます。それぞれの系に、不具合の修正とセキュリティの修正が出る期間が、別々に決まっています。Railsの保守方針（Rails Guides）では、不具合の修正は公開から1年、セキュリティの修正は2年、重大なセキュリティの修正は3年です。主な系の状況は次のとおりです（2026年11月時点。月は公開月から数えた目安）。

6系や5系で止まっているサービスは、動いていても、弱点が公開されたまま直らない状態が何年も続いています。

Rubyの期限も一緒に来る

Railsは、プログラミング言語のRubyの上で動きます。Rubyにも版ごとの期限があり、こちらは毎年3月に古いものが1つ終わります。Railsの8系はRuby 3.2以上が前提なので、Railsを上げるときにはRubyを上げる作業がほぼ必ず付いてきます。見積もりに「Rubyの更新」の行があるのはこのためです。

終了後に起きる3つのこと

• 修正が出ない：弱点が公開されても直されません。会員や取引先が使う画面を持つサービスなら、そこが攻撃の入口になります
• gemが付いてこない：決済・認証・メール送信などの部品（gem）が、古いRailsへの対応をやめていきます。新しい機能を足そうとしたときに、使いたい部品が入らなくなります
• 直せる人が減る：古いRailsとRubyの組み合わせを触った経験のあるエンジニアは、年々少なくなります。採用でも外注でも、候補が狭まります

どれもじわじわ効いてくるので、期限から逆算して自分たちで時期を決めることが要ります。保守を続ける理由とやめるとどうなるかはシステムの保守運用はなぜ必要？で書いています。

Railsの上げ方の特徴：1段ずつしか上げられない

Railsは、5.2から8.1へ一気には上げられません。公式のアップグレードガイドも、1つずつ順に上げることを勧めています。ここがPHPやJavaの更新と違う所で、費用の見え方に直結します。

何段上げるかで、作業の量が決まる

たとえば5.2で止まっているサービスを8.1まで上げるなら、6.0・6.1・7.0・7.1・7.2・8.0・8.1と7段を踏みます。1段ごとに、Railsが出す「この書き方はもうすぐ使えなくなります」という警告を直し、動作を確かめ、次の段へ進みます。段数が多いほど、同じ確認を繰り返す回数が増えます。

段ごとに「標準の動き」が変わる

Railsは系ごとに、何も設定しないときの動き（デフォルト）が少しずつ変わります。上げるときは、新しい動きに1つずつ合わせていきます。画面には何も変化がないのに作業が要るのは、この合わせ込みのためです。見積もりに「設定の見直し」の行があるのも同じ理由です。

JavaScriptのまとめ方が、途中で入れ替わっている

Rails 5〜6の時期に標準だったWebpacker（画面のJavaScriptをまとめる仕組み）は、2022年に開発が終わりました。7系以降へ上げるときは、別の仕組みへ置き換えることになります。画面の見た目は同じでも、裏側のまとめ方を変える作業は小さくありません。6系以前のサービスでは、ここが見積もりの大きな行になります。

段数が多いからといって、すぐに作り直しが正解になるわけではありません。次の章の4つの目安で、上げる価値がある土台かを見ます。

上げるか作り直すか：4つの目安で決める

土台のgemに上げ先があり、テストが残っているなら上げます。土台のgemの開発が止まっていて、直すたびに別の所が壊れるなら、作り直しを含めて考えます。次の4つを順に確かめると、自社がどちら寄りかが見えてきます。

目安①：土台になっているgemに、上げ先があるか

Railsのサービスは、認証・管理画面・ファイルの保存・決済などを、gemという部品を組み合わせて作ります。gemにも版と対応するRailsの範囲があり、開発が止まったものは新しいRailsで動きません。土台になっているgem（管理画面の枠組みや認証の仕組みなど）の開発が止まっていて、置き換え先もないなら、上げる作業は作り直しに近づきます。

開発会社に、使っているgemの一覧と、それぞれが新しいRailsに対応しているか、最後に更新されたのはいつかを先に出してもらいます。

目安②：自動のテストが、どれくらい残っているか

Railsはテストを書く文化が強く、作った当時のものが残っているサービスも多くあります。テストが動く状態で残っていれば、1段上げるたびに回すだけで確認の大半が済み、段数が多くても費用は抑えられます。テストがない、または長く動かしておらず半分以上が通らない状態なら、確認を人がなぞることになり、段数がそのまま費用に乗ります。

目安③：直すたびに、別の所が壊れていないか

小さな修正を頼むたびに、関係ないはずの画面が動かなくなります。修正の見積もりも毎回高くなります。こういう状態のサービスは、版だけ上げても壊れやすさは残ります。中身が複雑になっている正体は技術的負債とはで書いています。

目安④：あと何年、そのサービスで事業を回すか

2年以内に別の仕組みへ入れ替える予定なら、最小の対応で延命します。5年以上使い続けるなら、更新のたびに同じ苦労を繰り返すことになるので、整理しながら上げるか、作り直すかを選びます。

「整理しながら上げる」の中身は、上げる前に複雑になった所をほぐす作業です。画面が変わらない作業にお金を払う理由はリファクタリングとはで書いています。作り直すと決めたときに、どこまでを新しくするかの選び方はモダナイゼーションとはで解説しています。

進め方：Railsのバージョンアップを頼む5ステップ

発注する側がやるのは、棚卸しの材料を出すこと、上げ先を決めること、新旧の動きを確かめる人を選ぶことです。作業そのものは開発会社に任せます。

ステップ①：今の版と部品を棚卸しする

Railsの版、Rubyの版、使っているgem、JavaScriptのまとめ方、データベースの版、サーバーやクラウドの構成を一覧にします。分からなければ、開発会社に調べてもらう作業から頼みます。あわせて、ソースコードの置き場所、デプロイ（本番に反映する手順）、クラウドの管理アカウントが自社の名義で手元にあるかを確かめます。手元にないと、上げる作業を今の開発会社以外に頼めません。作った人が離れたあとの確かめ方はシステム引き継ぎの進め方で書いています。

ステップ②：上げ先の系を決める

上げ先は、セキュリティの修正が1年半以上残っている系にします。2026年11月なら8.1です。最新の系が出た直後は、gemの対応が追いついていないことがあるので、途中の段で一度止めて様子を見る進め方も候補にします。

ステップ③：試験環境で1段上げ、直す所を洗い出す

開発会社が、本番とは別の環境で1段だけ上げ、テストの通り方と警告の量から、全体の作業量を見積もります。ここで「段ごとの確認で済むか」「土台のgemの置き換えまで要るか」が分かります。見積もりは、この調査と、そのあとの本対応の2段階に分けて頼むと、金額の根拠が見えます。

ステップ④：段ごとに新旧の動きを比べる

テストが残っていれば、段ごとにそれを回します。足りない所は、会員登録・決済・請求のような主要な業務の操作を一覧にし、新旧で同じ結果が出るかを人が確かめます。確かめる操作の一覧は、業務を知る人が作ります。

ステップ⑤：段ごとに本番へ入れ、戻す手順を決める

何段も一度に本番へ入れず、1段ずつ進めて様子を見ます。切り替えの日は、月末の締めやキャンペーンの繁忙期を避けます。「切り替え後に特定の操作でエラーが続いたら前の版に戻す」のように、戻す条件と手順を先に決めてから本番に入れます。

ステップ③で「土台のgemに上げ先がない」と分かったら、そこで作り直しの検討に切り替えます。調査の結果は、作り直しの見積もりの材料になります。

注意点：費用が変わる所と、見積もりで確かめること

費用を決めるのは、段数、止まったgemの数、確かめる量の3つです。見積もりが高いと感じたら、この3つがどう入っているかを見ます。

Rails以外も一緒に上がる

Railsを上げると、Rubyとgemも新しいRailsに対応した版へそろえることになります。6系以前ならJavaScriptのまとめ方の置き換えも入ります。見積もりに「Rails以外の何を上げるか」が書かれていなければ、聞いてから比べます。

テストの状態で、確認の費用が大きく変わる

テストが残っていれば、段ごとに回すだけで多くの確認が済みます。残っていなければ、人が業務の操作を段ごとになぞることになり、ここが費用の大半を占めます。確認の範囲を「主要な業務だけ」「全部」のどちらで見積もっているかを確かめます。テストを先に書き足してから上げる提案が出ることもあります。段数が多いなら、その先行投資のほうが総額は小さくなります。

先延ばしは、段数と費用を増やす

Railsは1年に1回新しい系が出るので、1年放っておくと段数が1つ増えます。期限が来てから慌てて頼むと、Rubyの終了やクラウドの更新と重なり、作業の範囲が一度に広がります。期限の1年前には調査（ステップ③）まで終えておくと、対応を分けて進められます。

作り直しに切り替えても、仕様の確認は省けない

AIを使う開発で古いプログラムの読み解きが速くなり、作り直しは以前より進めやすくなりました。ただ、仕様や要件を漏れなく拾うこと、テストとレビューを人が見ることは省けません。作り直しの見積もりでは、「何が速くなり、何が残るか」を内訳で説明してもらいます。

1. 上げ先の系とその期限：セキュリティの修正が1年半以上残る系か
2. 段数と、段ごとの進め方：何段を踏み、段ごとに本番へ入れるか
3. 一緒に上げる部品の一覧：Ruby・gem・JavaScript・データベース
4. 確認の方法と範囲：テストで回すか人の操作か、主要な業務か全部か
5. 調査と本対応の分け方：調査の結果で本対応の金額が変わる前提か
6. 終わったあとの更新の約束：次の系の対応が保守に含まれるか

効果は？上げたあとに何が変わるか

修正を受け取れる状態に戻り、部品と人を選べるようになります。上げたこと自体は画面に出ないので、効果は次の3つで見ます。

修正が届き、新しいgemが使える

修正が出る系に戻るので、公開された弱点にその都度対応できます。決済や外部サービスとの接続のような最近の部品は、新しいRailsを前提に作られています。機能を足すときの選択肢が戻ります。

直せる人が増える

新しいRailsとRubyの組み合わせなら、触れるエンジニアの数が違います。特定の1人や1社にしか頼めない状態が続いているなら、上げる作業は、そこから抜ける機会にもなります。

次の更新が1段で済む

一度新しい系にそろえれば、次からは毎年1段ずつ上げる小さな作業になります。効果は、1段にかかった日数、障害の件数、小さな修正の見積もりの金額を、上げる前と比べて見ます。