【完全版】Rails 8 アップグレードガイド｜Rails 7からの移行手順・新機能

Ruby on Rails 8.0 が2024年11月にリリースされてから1年以上が経過し、Rails 8.1（2025年10月）、Rails 8.2（2026年4月）と進化を続けています。Rails 7.0/7.1 は2025年10月に**EOL（サポート終了）**となり、Rails 7.2は2026年8月にEOL予定。

**「Rails 8 にアップグレードしないと、もうセキュリティ更新も受けられない」**段階に入っています。

しかし、Rails 8 は単なるマイナー更新ではなく、

• Solid Trifecta（Solid Queue / Cache / Cable） によるRedis脱却
• Propshaft によるアセットパイプライン刷新
• Kamal 2 での本番デプロイ標準化
• Built-in Authentication Generator
• Ruby 3.2+（8.0） / Ruby 3.3+（8.1） 要件

など、アーキテクチャレベルの変更を伴います。準備なしのbundle updateは危険です。

• 自社のRails 7アプリをそのまま動かして大丈夫か
• Sidekiq を使っているが Solid Queue に移行すべきか
• WebpackerからPropshaft に変えると何が変わる？
• bin/rails app:update を実行したら大量の差分が出た
• ステージング環境でテストが大量に失敗する

本記事では、Rails 7.x から Rails 8.x への完全なアップグレード手順を、2026年6月時点の最新情報で網羅します。事前準備から段階的移行、Solid Trifecta対応、Kamal 2デプロイ、FAQまで完全網羅。この1本でRails 8 移行のプロジェクトを安全に完遂できます。

結論：今すぐ知りたい人のための3分サマリー

時間がない方向けに、要点を先に示します。

Rails 8 系の現状（2026年6月時点）

移行に必要なRuby

• Rails 8.0 → Ruby 3.2.0 以上
• Rails 8.1 → Ruby 3.3.0 以上
• Rails 8.2 → Ruby 3.3.0 以上（推奨は最新）

5ステップで移行

# 1. Ruby を 3.3+ に更新
rbenv install 3.3.6
# 2. Rails 7.2 への中間移行（推奨）
bundle update rails
# 3. Rails 8.0 → 8.1 → 8.2 と段階的に上げる
# 4. bin/rails app:update で設定差分を取り込み
bin/rails app:update
# 5. テスト・Gem監査・本番反映

それでは詳細を解説します。

Rails 8 主要新機能の全体像

1. Solid Trifecta（最大の変革）

Rails 8 が打ち出した「Redis 不要のフルスタック」哲学を具現化する3つのライブラリ:

3つともデータベース（PostgreSQL/MySQL/SQLite）を使うため、Redis等の外部サービスが不要になり、デプロイがシンプルになります。

# config/environments/production.rb
config.cache_store = :solid_cache_store
config.active_job.queue_adapter = :solid_queue

# config/cable.yml
production:
  adapter: solid_cable

2. Propshaft（アセットパイプライン）

Sprockets の代替として、新規Rails 8アプリのデフォルトに。

3. Kamal 2（デプロイ）

Docker コンテナベースの本番デプロイをコマンド1つで:

kamal deploy

Heroku等のPaaSへの依存度を下げ、自前VPSやクラウドVMへの直接デプロイを容易化。

4. Thruster（HTTPプロキシ）

Pumaの前段に置く軽量HTTP/2プロキシ:

gem "thruster", require: false

X-Sendfileアクセラレーション、アセットキャッシュ、圧縮を提供し、Nginxなしでも本番運用可能に。

5. Built-in Authentication Generator

Devise などのGem不要で、認証機能の足場を生成:

bin/rails generate authentication

User モデル、Session 管理、パスワードリセット等が一気に生成されます。

6. SQLite Production Ready

WAL モード、改善された並行性、Litestream バックアップ統合により、小〜中規模アプリで SQLite を本番運用可能に。

Rails 8.1 / 8.2 の追加機能

Rails 8.1（2025年10月）

Rails 8.2（2026年4月）

アップグレード戦略：一気にではなく段階的に

Rails の公式推奨は**「メジャー/マイナーバージョンを1つずつ上げる」**です。

おすすめパス

現在のバージョンによって最適パスが異なります:

Rails 6.0 → 6.1 → 7.0 → 7.1 → 7.2 → 8.0 → 8.1 → 8.2
Rails 7.0 → 7.1 → 7.2 → 8.0 → 8.1 → 8.2
Rails 7.1 → 7.2 → 8.0 → 8.1 → 8.2
Rails 7.2 → 8.0 → 8.1 → 8.2

いきなり 7.1 → 8.2 にジャンプするのは:

• bin/rails app:update の差分が膨大
• Deprecation 警告を全部一度に消化することになる
• Gemの互換性問題が複合的に発生
• ロールバック判断が難しくなる

時間に余裕があれば1段階ずつ進めるのが安全です。

スキップ案：7.2 LTS的活用

時間がない場合、Rails 7.2 で一旦停止し、8.0 を経由せず直接 8.1 に上げる戦略も。ただし 7.2 のサポートも 2026年8月に切れるため、長く居座れません。

事前準備チェックリスト

bundle update rails を実行する前に必ず確認:

1. Ruby のバージョン

ruby -v
# ruby 3.3.6 (推奨)

• Rails 8.0 → Ruby 3.2 以上
• Rails 8.1 → Ruby 3.3 以上
• Rails 8.2 → Ruby 3.3 以上（実質3.3.5+推奨）

Ruby を先に上げる:

# rbenv 環境
rbenv install 3.3.6
rbenv local 3.3.6

# asdf
asdf install ruby 3.3.6
asdf local ruby 3.3.6

Ruby 更新時の注意点は[Rubyバージョン管理の記事]も参照。

2. テストカバレッジ

最低限の自動テストがないと、移行時の動作確認が困難。事前に:

# カバレッジ確認
bundle exec rspec --coverage
# または
bundle exec rails test

70-80% 以上のカバレッジを目標に。

3. Gem の互換性チェック

依存Gem の Rails 8 対応状況を確認:

# 古いgemリスト
bundle outdated

# 主要 gem のRails 8対応確認
# 公式 GitHub / RubyGems で確認

特に確認すべきもの:

• devise （8.0 対応版あり）
• sidekiq （継続利用 or Solid Queue 移行）
• redis-rails （非推奨化）
• paperclip / carrierwave / shrine → Active Storage 推奨
• kaminari / will_paginate
• 古いgem（最終リリースが2年以上前）は要警戒

4. Deprecation 警告の解消

現バージョンで動かしていて出る warning は、次バージョンで Hard Error になる可能性大:

# テスト実行時に warning を確認
RUBYOPT="-W:deprecated" bundle exec rspec

すべて消してから次バージョンへ。

5. CI/CD のRubyバージョンも更新

GitHub Actions / GitLab CI / CircleCI で使う Ruby バージョンも事前に更新:

# .github/workflows/ci.yml
strategy:
  matrix:
    ruby: ['3.3.6']

6. 本番環境のRubyも準備

# Docker利用なら Dockerfile 更新
FROM ruby:3.3.6-alpine

本番デプロイ前にステージングで Ruby 3.3 動作確認。

7. バックアップ

# DB バックアップ
pg_dump mydb > backup.sql
# または mysqldump

# Git ブランチ作成
git checkout -b upgrade-rails-8

段階1：Gemfile の更新

Rails 7.x → 8.0 の場合

# Gemfile

# 変更前
gem "rails", "~> 7.1.0"

# 変更後
gem "rails", "~> 8.0.0"

bundle update rails

Rails 7.2 を経由する場合:

gem "rails", "~> 7.2.0"

bundle update rails

bundle update 時のエラーへの対処

典型的なエラー1: gem 依存解決失敗

Bundler could not find compatible versions for gem "X":
  In Gemfile:
    rails (~> 8.0.0)
    some_gem

→ 該当 gem の最新版が Rails 8 対応か確認。未対応なら:

• 互換性のあるバージョンを探す
• 代替 gem を検討
• 該当 gem を一時無効化

典型的なエラー2: 古い lock ファイル

# Gemfile.lock を一度削除
rm Gemfile.lock
bundle install

⚠️ プロジェクトによってはこれで膨大な依存変更が起きるため、慎重に。

段階2：bin/rails app:update

Gem を更新したら、Rails 自身の設定ファイル差分を取り込み:

bin/rails app:update

このコマンドは各種設定ファイルの 新旧バージョンの差分について、ファイルごとにどう扱うか質問してきます:

   conflict  config/application.rb
Overwrite /path/to/config/application.rb? (enter "h" for help) [Ynaqdh]

選択肢:

• Y: 上書き（注意: カスタマイズが消える）
• n: 上書きしない（現状維持）
• d: 差分を見る（推奨）
• h: ヘルプ

推奨ワークフロー

# 1. 一旦すべて新版で上書き
bin/rails app:update
# 全部に対して Y

# 2. git diff で差分確認
git diff

# 3. 重要なカスタマイズが消えていれば手動マージ

主要な差分が出るファイル

• config/application.rb
• config/environments/*.rb
• config/initializers/new_framework_defaults_*.rb ← 重要
• bin/setup
• Dockerfile（Rails 7.1+ なら）
• .dockerignore
• Procfile.dev

new_framework_defaults_*.rb の意味

このファイルはバージョンごとの新デフォルト挙動を段階的に有効化するためのもの:

# config/initializers/new_framework_defaults_8_0.rb
# Rails.application.config.action_controller.escape_json_responses = true
# ↑ コメントアウトされた状態で生成される

すべて有効化すると新挙動になり、コメントアウトのまま残せば旧挙動を維持できます。1つずつ有効化してテストするのが安全です。

最終的に全部有効化したら、config/application.rb で:

config.load_defaults 8.0  # または 8.1, 8.2

を設定し、個別ファイルは削除可能。

段階3：Solid Trifecta の導入（必要に応じて）

Solid Queue の導入

Sidekiq から Solid Queue への移行

現状確認:

# Gemfile
gem "sidekiq"

# config/application.rb
config.active_job.queue_adapter = :sidekiq

Solid Queue へ:

# Gemfile
# gem "sidekiq"  # 削除またはコメントアウト
gem "solid_queue"
gem "mission_control-jobs"  # 管理UI

bundle install
bin/rails solid_queue:install
bin/rails db:migrate

# config/environments/production.rb
config.active_job.queue_adapter = :solid_queue

# config/queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 3
      processes: 1
      polling_interval: 0.1

Sidekiq との共存パターン

一気に切り替えるのが不安なら、段階的:

# 重要なジョブだけまずは継続
class CriticalJob < ApplicationJob
  self.queue_adapter = :sidekiq   # 個別指定
end

class NormalJob < ApplicationJob
  # デフォルトの solid_queue を使う
end

Solid Queue の起動

開発環境:

bin/rails solid_queue:start
# または
bundle exec rake solid_queue:start

本番（systemd など）:

# /etc/systemd/system/solid_queue.service
[Service]
ExecStart=/path/to/bin/rails solid_queue:start

詳細は[Linux crontab・systemd の記事]も参照。

Solid Cache の導入

# Gemfile
gem "solid_cache"

bundle install
bin/rails solid_cache:install
bin/rails db:migrate

# config/environments/production.rb
# 変更前
config.cache_store = :redis_cache_store, { url: ENV["REDIS_URL"] }

# 変更後
config.cache_store = :solid_cache_store

Solid Cable の導入

# Gemfile
gem "solid_cable"

bundle install
bin/rails solid_cable:install
bin/rails db:migrate

# config/cable.yml
production:
  adapter: solid_cable
  connects_to:
    database:
      writing: cable
  polling_interval: 0.1.seconds
  message_retention: 1.day

Solid Trifecta の DB 設計

新規アプリでは、Rails 8 がマルチデータベース設定を自動生成し、Solid 用に別DB（または同一DB内別接続）を割り当てます:

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache:
    <<: *default
    database: myapp_production_cache
    migrations_paths: db/cache_migrate
  queue:
    <<: *default
    database: myapp_production_queue
    migrations_paths: db/queue_migrate
  cable:
    <<: *default
    database: myapp_production_cable
    migrations_paths: db/cable_migrate

既存アプリでは、最初は主DBで動かし、規模が大きくなったら分離するのが現実的。

移行しない選択肢

Sidekiq/Redis を使い続けるのは今後もアリです。Solid Trifecta は「シンプル化したい人向け」のオプションで、強制ではありません。

段階4：Propshaft への移行（任意）

Sprockets を使っている場合

# Gemfile
# gem "sprockets-rails"  # 削除
gem "propshaft"

bundle install

主な違いと注意:

• トランスパイルなし: ES6→ES5変換等は別途必要（cssbundling-rails, jsbundling-rails 利用）
• Sass/SCSS → dartsass-rails 推奨
• 画像のhelpers: image_path 等の挙動が微妙に変わる
• 生成パス: public/assets/ 配下のハッシュファイル名が異なる

Webpacker からの移行

Webpacker（Rails 7 で非推奨化済み）は基本的に段階的に廃止へ:

# Webpacker 系を削除
# gem "webpacker"

# 代替（用途に応じて）
gem "cssbundling-rails"
gem "jsbundling-rails"
# または importmap で簡素化
gem "importmap-rails"

Importmap の活用

JavaScript ビルドツール不要で運用したいなら:

bin/rails javascript:install:importmap

これでNode.js依存ゼロでフロントエンド開発可能。

段階5：Authentication Generator（任意）

新規プロジェクト・小規模プロジェクトで Devise の代わりに:

bin/rails generate authentication

これだけで:

• User モデル（email, password_digest）
• SessionsController
• PasswordsController
• マイグレーションファイル
• 必要なルーティング

が自動生成されます。

bin/rails db:migrate

Devise との比較

シンプルな認証なら Built-in、複雑な要件なら Devise という使い分け。

段階6：Kamal 2 によるデプロイ（任意）

Heroku などPaaS依存を脱却したい場合の選択肢。

初期セットアップ

# Rails 8 では自動セットアップ済み
# 既存アプリへの追加
bin/rails kamal:install

config/deploy.yml を編集:

service: myapp
image: yourname/myapp

servers:
  web:
    - 192.168.1.100

registry:
  username: yourname
  password:
    - KAMAL_REGISTRY_PASSWORD

env:
  secret:
    - RAILS_MASTER_KEY
    - DATABASE_URL

asset_path: /rails/public/assets

デプロイ

# 初回セットアップ（サーバー側に Docker 等をインストール）
kamal setup

# 通常デプロイ
kamal deploy

# ロールバック
kamal rollback

Kamal 2 のメリット

• VPS/EC2 等の生サーバーに直接デプロイ可能
• Zero-downtime デプロイ
• 複数サーバー対応
• Docker Compose的な扱いやすさ

学習コスト

kamal deploy までは比較的シンプルですが、本番運用では SSL/Lets Encrypt、データベースバックアップ、監視等の周辺ツール導入が必要。

詳細は[ssh host key verification failedの記事]もデプロイ時に有用です。

Rails 8.1 への移行追加ポイント

Rails 8.0 から 8.1 へは比較的軽量な移行ですが、いくつか注意点:

Ruby 3.3+ 必須

ruby -v
# 3.3.0 以上が必要

Association Deprecations

class User < ApplicationRecord
  has_many :old_posts, deprecated: true
end

ログに警告が出る:

DEPRECATION WARNING: User#old_posts is deprecated...

将来の Hard Error 化に備えて段階的廃止を計画。

Structured Event Logging

# 構造化ログ
Rails.event.notify(
  "user.signup",
  user_id: user.id,
  source: "web"
)

ログ集約ツール（Datadog、New Relic、ELK等）との連携が大幅に改善。

Local CI（bin/ci）

bin/ci

これだけで:

• テスト実行（rspec/minitest）
• リンター（rubocop）
• セキュリティ監査（brakeman）
• 依存関係チェック（bundler-audit）

をローカルで一気に実行できます。

Rails 8.2 への移行ポイント

8.1 → 8.2 は比較的シンプル:

# Gemfile
gem "rails", "~> 8.2.0"

bundle update rails
bin/rails app:update

主な変更:

• パフォーマンスチューニング（基本的に互換）
• Hotwire統合の改善
• 一部Deprecationの完全削除（8.0時代に警告されたもの）

8.0時代の new_framework_defaults_8_0.rb を全有効化済みなら、ほぼスムーズに移行できます。

よくあるエラーと対処

NoMethodError: undefined method ‘X’ (Rails内部)

bundle update 後に Rails の内部APIが変わった可能性。各 gem を一つずつ最新版に更新:

bundle update --conservative gem_name

ActiveRecord::PendingMigrationError

Solid Queue/Cache/Cable のマイグレーションが未実行:

bin/rails db:migrate

複数DBの場合:

bin/rails db:migrate:queue
bin/rails db:migrate:cache
bin/rails db:migrate:cable

Mysql2::Error: Access denied

DB認証関連。MySQL 1045 access denied の記事 を参照。

Sidekiq から Solid Queue 移行時にジョブが動かない

# config/application.rb で adapter を確実に変更
config.active_job.queue_adapter = :solid_queue

ジョブクラス側も再確認:

class MyJob < ApplicationJob
  # queue_as :default
  # self.queue_adapter = :sidekiq  # ← 残っていないか
end

Webpacker 関連エラー

Webpacker can't find application.js in /public/packs/manifest.json

Webpacker を完全に削除したのに古い参照が残っている:

# 残骸を削除
rm -rf public/packs
rm -rf config/webpacker.yml
rm -rf bin/webpack*

ViewやLayoutからjavascript_pack_tag等の呼び出しも削除。

Active Storage 関連エラー

Active Storage のマイグレーションが必要な場合:

bin/rails active_storage:install
bin/rails db:migrate

Tailwind CSS が反映されない

Rails 8 でTailwind を使う場合:

bin/rails tailwindcss:install
# または
gem "tailwindcss-rails"

bin/dev で開発サーバー起動時に自動コンパイル。

Docker環境での問題

Dockerfile の更新も必要:

# Rails 7 時代
FROM ruby:3.2

# Rails 8 / 8.1
FROM ruby:3.3-slim

WORKDIR /rails

RUN apt-get update && apt-get install -y \
    build-essential \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*

COPY Gemfile Gemfile.lock ./
RUN bundle install

COPY . .

CMD ["./bin/rails", "server", "-b", "0.0.0.0"]

Docker容量問題はDocker no space left on device の記事も参照。

アップグレード後の検証

1. テスト全実行

bin/rails test
# または
bundle exec rspec

2. デプロイ前の動作確認

# 開発環境で実際に触る
bin/dev

3. ステージング環境での負荷テスト

本番相当のデータ・トラフィックでステージング検証。

4. ログのDeprecation警告チェック

tail -f log/development.log | grep -i deprecation

5. パフォーマンス計測

# rack-mini-profiler 等で比較
gem "rack-mini-profiler"

6. メモリ・CPU 使用率比較

# 本番計測ツール（Datadog/New Relic等）で旧版と比較

トラブルシューティング・チェックリスト

アップグレード作業中の対処手順:

1. エラーメッセージから原因を特定
2. Gemfile.lock を削除してbundle install 試行
3. bin/rails app:update の差分を確認
4. new_framework_defaults_*.rb を1つずつ有効化
5. 依存gem を個別に更新
6. テスト失敗箇所を順番に修正
7. Solid Trifecta 関連は段階導入
8. デプロイ前に必ずステージング検証
9. 本番デプロイは段階的（ブルーグリーンorカナリア）
10. 問題発生時のロールバック手順を準備

よくある質問（FAQ）

Q1. いつアップグレードすべきですか？

できるだけ早く。Rails 7.0 / 7.1 は既にEOL、7.2 も 2026年8月にサポート終了予定です。セキュリティ更新が受けられなくなる前に Rails 8 系に移行を計画してください。

Q2. Rails 7.0 から直接 Rails 8.2 にできますか？

技術的には可能ですが強く非推奨。最低でも 7.2 を経由し、8.0 → 8.1 → 8.2 と段階的に上げてください。一気にジャンプすると、変更が複合してデバッグが極めて困難になります。

Q3. Sidekiq を使い続けてもいいですか？

問題なし。Solid Queue は Sidekiq の代替候補のひとつで、強制移行ではありません。大量ジョブ処理のパフォーマンスが必要なら Sidekiq 継続が現実的。Redis のコスト・運用負荷を減らしたい場合は Solid Queue を検討。

Q4. Solid Trifecta 導入で本当に Redis を消せますか？

Yes、ただし規模によります。中小規模アプリなら問題なし。大規模・高頻度アクセスのアプリでは、Solid系はDB負荷の検証が必要。徐々に切り替えてベンチマークを取ることを推奨。

Q5. Devise から Built-in Authentication に移行すべき？

既存アプリは Devise 継続が無難。新規プロジェクトなら Built-in を検討。Devise はRails 8 でも継続サポートされており、機能の差を理解した上で選択してください。

Q6. Webpacker から Propshaft への移行は必須ですか？

Rails 8 では Webpacker 利用は事実上不可能（Gem も非対応）。cssbundling-rails + jsbundling-rails、または importmap-rails への移行が必要です。

Q7. Heroku で動いていますが Kamal に移行すべき？

Heroku で問題なければ継続でOK。Kamal は自前インフラ運用したい人向け。コストとメリットを比較してください。

Q8. テストが大量に失敗します

考えられる原因:

• Deprecation が Hard Error 化した（new_framework_defaults_* で1つずつ確認）
• gem の API 変更（依存gemのCHANGELOG確認）
• ActionView/ActionController の挙動変化（特に CSRF/JSON周り）
• ActiveRecord クエリ生成の変化

エラー1つずつ潰し、可能ならCIで自動チェック。

Q9. アップグレード作業はどれくらいかかりますか？

規模・状態によって大幅に変わります:

• 小規模（5モデル以下、Gem 10本程度）: 0.5〜1人日
• 中規模（20モデル前後、Gem 30本程度）: 3〜5人日
• 大規模（50モデル以上、Gem 50本以上）: 1〜3人週
• 超大規模・モノリス: 数ヶ月のプロジェクト化

事前準備（テストカバレッジ向上、Deprecation警告解消）に最も時間がかかります。

Q10. 本番アップグレードでダウンタイムを最小化するには？

• マイグレーションは事前に（zero-downtime migration手法）
• Blue-Green デプロイ: 新旧2系統を並行稼働
• DB スキーマ変更は事前に分割
• Solid Trifecta は段階的有効化（一気に切り替えない）
• キャッシュ移行は徐々に

Q11. Rails 8.0 と 8.1 ではどちらに移行すべき？

8.1 が推奨。8.0 は2026年5月から security-only サポートに移行しました。8.1 は2026年10月までバグ修正サポート、その後 8.2 LTSへ。

Q12. 移行に失敗した時のロールバック方法は？

Git の場合:

git checkout main
bundle install
bin/rails db:rollback STEP=10  # マイグレーション戻し

⚠️ Solid Queue/Cache/Cable の DBテーブルや、Rails 8で追加された機能が本番DBに残っている可能性に注意。マイグレーション履歴を確認しながら戻してください。

参考リンク・関連資料

Rails 公式

• Ruby on Rails 公式 – 最新リリース情報
• Rails Guides – Upgrade Guide – 公式アップグレードガイド
• Edge Guides – 開発中の最新仕様

Rails 8 主要機能

• Solid Queue（GitHub） – 公式リポジトリ
• Solid Cache（GitHub）
• Solid Cable（GitHub）
• Propshaft（GitHub） – アセットパイプライン
• Kamal 2（公式） – デプロイツール
• Thruster（GitHub） – HTTPプロキシ

Ruby

• Ruby 公式 – Ruby本体
• Ruby 3.3 リリースノート

コミュニティ・記事

• Rails Releases – 最新リリース履歴
• The Rails Maintenance Policy – サポートポリシー

関連記事（本サイト）

• MySQL 1045 access denied エラー対処 – DB認証エラー（Mysql2::Errorと連動）
• MySQL 1146 Table doesn’t exist エラー対処 – DB エラー
• MySQL Got error 28 from storage engine エラー対処 – DB容量問題
• Docker no space left on device エラー対処 – Docker容量問題
• SSH Host key verification failed エラー対処 – デプロイ時のSSHエラー
• crontab 書き方 例 – Solid Queue 代替の定期実行・systemd timer
• address already in use エラー対処 – Rails server起動時のポート問題

まとめ

Rails 8 / 8.1 / 8.2 へのアップグレードは、単なるバージョン更新ではなく、アーキテクチャ刷新の機会でもあります。要点を再整理します。

• 緊急性: Rails 7.0/7.1 は EOL、7.2 も 2026年8月にサポート終了
• 必須要件: Ruby 3.2+ (Rails 8.0)、Ruby 3.3+ (Rails 8.1/8.2)
• 段階的移行: 7.2 → 8.0 → 8.1 → 8.2 と1つずつ
• Solid Trifecta は任意: Redis脱却したい人向け。Sidekiq継続もOK
• Propshaft 移行は実質必須: Webpacker は完全廃止
• Kamal 2 はオプション: 既存PaaSを継続する選択肢もアリ
• 事前準備が重要: テストカバレッジ・Gem監査・Ruby更新・Deprecation解消
• 本番反映は慎重に: ステージング検証・ロールバック手順準備

これらの知識は、Rails アプリの長期運用・保守・モダナイゼーションに不可欠です。本記事をブックマークしておけば、Rails 8 移行プロジェクトを安全に進められます。

本記事は2026年6月時点の情報をもとに、Ruby on Rails 8.0.5 / 8.1.3 / 8.2.x、Ruby 3.3.6+ での動作確認・公式ドキュメントに基づき作成しています。Rails のバージョン・マイナーアップデートによって挙動が変わる場合があるため、最新の情報はRails公式ガイドもあわせてご確認ください。