LASSIC Media らしくメディア

2026.11.06 らしくコラム

Redmineバージョンアップ4段階|RubyとRailsも更新

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

サーバーラックの上のノートPCで版上げを進める担当者と、画面を示す先輩

この記事の結論

  • Redmineは新しい方から3つのマイナー版だけが公式のサポートを受けられ、5.1系以前は対象外です。
  • Redmine 6.x系が使うRails 7.2は公式のサポート一覧から外れており、7.0系へ上げる理由になります。
  • 作業は要件確認・バックアップ・入れ替え・データベース更新の順で、プラグインの確認が要になります。

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

社内のRedmineをいつから更新していないのか、担当者の誰も答えられない。上げたいけれど、RubyやRailsまで入れ替えると聞いて手が止まっている——。Redmineを長く使っている情報システム部門では、こうした迷いが起こりがちです。Redmineのバージョンアップとは、Redmineを新しい版に入れ替え、あわせて土台のプログラム言語Rubyと開発の枠組みRuby on Rails(以下Rails)を、新しい版が求める組み合わせにそろえる作業です。

版を上げると、脆弱性の修正を受け取れる状態に戻り、新しい機能も使えるようになります。ただし万能ではなく、プラグインやテーマが新しい版に合わなければ、上げた後に使えなくなる機能も出てきます。本記事では、Redmineを運用する情報システムの担当者に向けて、版ごとのサポート状況、RubyとRailsも一緒に上げる理由、作業の進め方、そして外部に頼むときに確認したい点を整理します。

Redmineのバージョンアップとは

Redmineはオープンソースの課題管理ツールで、Railsという開発の枠組みの上に作られたWebアプリケーションです。そのため版を上げるときは、Redmine本体だけでなく、その下で動いている層まで含めて見る必要があります。

  • Redmine本体:課題(チケット)やWikiなどの機能そのもの。マイナー版はおよそ3か月ごと、メジャー版は年1回を目安に出す方針です
  • Rails:Redmineが使っている開発の枠組み。Redmineの版ごとに使うRailsの版が決まっています*2
  • Ruby:Redmineを動かすプログラム言語。Redmineの版ごとに対応するRubyの版が決まっています
  • データベースとプラグイン:PostgreSQLやMySQLなどのデータベース、あとから追加したプラグインやテーマも、新しい版との相性を確かめます

公式のサポート方針では、修正を受けられるのは新しい方から3つのマイナー版までです。最新の版はすべての修正、1つ前は不具合とセキュリティの修正、2つ前は重要なセキュリティの修正だけを受け取ります。*1 新しい版が出るたびに、手元の版の段階は1つずつ下がります。

版ごとのサポート状況

2026年10月時点のRedmine公式サイトでは、7.0系が最新の安定版です。*1 主な版のサポートの段階と、使うRails・対応するRubyをまとめると次のとおりです。*2

Redmineの版ごとのサポートとRuby・Railsの組み合わせ
Redmineの版 公式のサポート 使うRails 対応するRuby
7.0系 新機能・不具合・セキュリティの修正 8.1 3.2・3.3・3.4・4.0
6.1系 不具合とセキュリティの修正 7.2 3.2・3.3・3.4
6.0系 重要なセキュリティの修正のみ 7.2 3.1・3.2・3.3
5.1系以前 サポート対象外 ― ―

5.1系以前を使っている場合は、すでに公式のサポートの外にあります。6.0系も、次の版が出れば段階が下がってサポート対象外になる位置です。上げる先の版が求めるRubyとRailsに合わせて、土台ごと入れ替える計画を立てます。

なぜRubyとRailsも上げるのか

Redmineの版だけを見ていると見落としやすいのが、土台のRubyとRailsの期限です。どちらも公式が保守の期間を決めており、期限を過ぎた版には開発チームからの修正版が出ません。

壁の工程表の横棒を手で示して説明する担当と、あごに手を当てて見る上司

  • Ruby:3.2系は2026年4月1日にEOL(修正の終了)を迎えました。3.3系はセキュリティの修正だけの期間に入り、EOLは2027年3月31日の見込みです*4
  • Ruby:3.4系と4.0系は通常の保守の期間で、EOLの日付はまだ決まっていません*4
  • Rails:新しい機能を入れた版が出てから、不具合の修正は1年、セキュリティの修正は2年が原則です。公式サイトのサポート一覧に載っているのは8.1系と8.0系です*5
  • Rails:Redmine 6.0・6.1が使う7.2系は2024年8月に出た版で、この一覧に入っていません*6

Redmine 6.x系のままでは、Redmineとしてはサポート中でも、土台のRailsには修正版が出ない状態です。Rails 8.1を使う7.0系へ上げ、あわせてRubyも、7.0系が対応する版のうちEOLまで余裕のある3.4系か4.0系にそろえると、3つの層の期限をまとめて先へ延ばせます。4.0系を選ぶなら、Redmine公式は4.0.4以降を勧めています。*2 Rails 7.2の期限そのものはRails 7.2のEOLとバージョンアップでも扱っています。

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

Redmine公式の手順書は、バージョンアップを大きく4つの段階に分けています。*3 入れ替えの作業そのものより、事前の確認と、元に戻せる準備に時間を割きます。

  • ステップ1:要件を確かめる。上げる先の版が求めるRuby・Rails・データベースの版を確認します
  • ステップ2:バックアップを取る。データベースと、添付ファイルの置き場所の両方を保存します
  • ステップ3:新しい版を入れる。新しいフォルダに展開し、接続の設定・添付ファイル・追加したプラグインを移します
  • ステップ4:データベースを更新して確かめる。プラグインの分も含めて更新し、新しい機能の権限の設定を見直します

Redmineのバージョンアップを4つの段階で左から順に並べた流れ図。STEP1 要件を確かめる、STEP2 バックアップを取る、STEP3 新しい版を入れる、STEP4 データベースを更新する。

迷いやすいのはステップ3のプラグインとテーマです。公式の手順は、最初から同梱されていなかったプラグインだけを移すよう求め、テーマも新しい版に合った版が出ていないか確かめるよう勧めています。*3 移す前にプラグインごとの対応状況を調べ、使い続けるか、外すかを決めておきます。本番の前に、本番データの複製で一度通しておきます。

外部に頼むときに確認しておきたい点

Redmineのバージョンアップは、RubyやRailsの入れ替えまで含めると、サーバーの構成を分かっている人の手が要ります。外部に作業を頼むときは、見積もりの前に次の点を確かめておきます。

ノートPCを前に手を差し出して説明する外部の技術者と、ノートに書く発注側の担当

  • 範囲:Redmine本体だけか、Ruby・Rails・データベース・OSの更新まで含むか
  • プラグインとテーマ:いま入っているものの一覧を作り、新しい版で使えるかを誰が確かめるか
  • 検証:本番データの複製で事前に通すか。通した後に、利用部門が画面を確かめる時間を取るか
  • 切り戻し:うまくいかなかったときに、バックアップから元に戻す手順と判断の基準を決めておくか
  • その後の更新:次の版や、RubyとRailsの期限が近づいたときに、誰が気づいて計画するか

特に最後の点は、一度きりの作業で終わらせないために大切です。Redmine公式のセキュリティ情報のページには、修正された脆弱性と、どの版で直ったかが一覧で載っています。*7 定期的に確かめる担当を決めておくと、更新の漏れを防げます。Redmineの構築から頼む場合の考え方はRedmineで課題管理基盤を外注構築にまとめています。

まとめ:Redmineのバージョンアップで確かめておきたい3つの点

Redmineのバージョンアップを進めるうえで、確かめておきたい点は3つに整理できます。第一に、いま使っている版がRedmine公式のサポートのどの段階にあるかを確かめること。第二に、土台のRubyとRailsの期限もあわせて見て、3つをそろえて上げること。第三に、プラグインの対応状況と、バックアップから元に戻す手順を、作業の前に決めておくことです。この3点を踏まえておけば、「本体は上げたのに土台の期限は切れたままだった」という事態を避けやすくなります。上げる先の版の選び方や作業の分担に迷いがあれば、外部の手を借りるのも一つの選択肢です。

LASSICに相談するメリット

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

Redmineのバージョンアップでは、まず稼働中のRedmine・Ruby・Rails・データベースの版と、入っているプラグインとテーマを一覧にし、上げる先の版の公式の要件と照らし合わせます。Rubyはrbenvなどの版管理の仕組みで切り替えられるようにし、Bundler(必要な部品の版をそろえる仕組み)で依存関係を固めます。検証は、本番のデータベースと添付ファイルを複製した検証環境で、PumaやPassengerなどアプリケーションサーバーの再起動まで含めて通します。切り戻しは、バックアップから戻す手順と判断の基準を文書にして事前に合意します。運用では、Redmine公式のセキュリティ情報とRuby・Railsの保守期限を定期的に確かめ、次の更新の時期を提案します。

よくある質問

6.0系から7.0系へ一度に上げられますか

上げる先の版の要件を満たせば、手順の流れは同じです。*3 ただし6.0系をRuby 3.1で動かしている場合は、7.0系が対応するRubyへの入れ替えが先に要ります。*2 プラグインも新しい版に合うものへ替えるため、検証環境で一度通してから本番に進めます。

作業中はRedmineを止める必要がありますか

データベースの更新とアプリケーションサーバーの再起動を伴うため、作業の間は利用を止めておくのが無難です。利用部門には停止の時間を前もって知らせ、チケットの更新が作業中に入らないようにしておくと、バックアップとの食い違いを防げます。

どのくらいの頻度で見直せばよいですか

決まった答えはありませんが、半年に1回など時期を決めて見直すのが目安です。Redmineはマイナー版をおよそ3か月ごと、メジャー版を年1回出す方針で、RubyとRailsの期限も年単位で決まっています。3つの期限を並べて、次に上げる時期を決めておくと計画が立てやすくなります。

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

Redmine本体とRuby・Railsの更新、プラグインの対応確認から切り戻しの準備まで、元請(プライムベンダー)としてご提案します。

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

無料相談はこちら

出典

  1. *1 参考:Redmine.org「Download」(Versions status and releases policy)(https://www.redmine.org/projects/redmine/wiki/Download)。出典:版ごとのサポート状況(7.0系・6.1系・6.0系・5.1系以前)、リリースの頻度、サポート方針の記述を参照(2026年11月確認)
  2. *2 参考:Redmine.org「RedmineInstall」(https://www.redmine.org/projects/redmine/wiki/RedmineInstall)。出典:Redmineの版ごとに対応するRubyの版と使うRailsの版の表、Ruby 4.0.4以降の推奨の記述を参照(2026年11月確認)
  3. *3 参考:Redmine.org「RedmineUpgrade」(https://www.redmine.org/projects/redmine/wiki/RedmineUpgrade)。出典:要件の確認・バックアップ・入れ替え・データベースの更新の手順、プラグインとテーマの扱いの記述を参照(2026年11月確認)
  4. *4 参考:Ruby公式サイト「Ruby ブランチごとのメンテナンス状況」(https://www.ruby-lang.org/ja/downloads/branches/)。出典:Ruby 3.2・3.3・3.4・4.0のステータスとEOLの日付、EOLの定義を参照(2026年11月確認)
  5. *5 参考:Ruby on Rails「Maintenance policy」(https://rubyonrails.org/maintenance)。出典:不具合の修正1年・セキュリティの修正2年の方針、サポート中の版の一覧を参照(2026年11月確認)
  6. *6 参考:Rails Guides「Maintenance Policy for Ruby on Rails」(https://guides.rubyonrails.org/maintenance_policy.html)。出典:リリースノートの一覧(Version 7.2 – August 2024)を参照(2026年11月確認)
  7. *7 参考:Redmine.org「Redmine Security Advisories」(https://www.redmine.org/projects/redmine/wiki/Security_Advisories)。出典:修正された脆弱性と修正版の一覧を参照(2026年11月確認)




View