Ruby on Rails 8 新機能完全ガイド：Solid Trifecta・認証・移行手順を徹底解説【2026年版】

Ruby on Rails 8は、Rails 7以来最も重要なリリースであり、Redisのデータベースバック代替、ネイティブ認証機能、そして合理化されたデプロイパイプラインを導入しています。2024年11月にリリースされ、2025年10月のRails 8.1フォローアップにより成熟したRails 8は、これまで専用インフラを必要としていた外部依存関係を排除します。本記事では、Rails 8の主要な新機能と、Rails 7からの移行手順を包括的に解説します。

Solid Trifecta：データベースバックのインフラストラクチャ

Rails 8以前は、ほとんどの本番アプリケーションがバックグラウンドジョブ、キャッシュ、WebSocketのpub/subにRedisを依存していました。Solid Trifectaは、PostgreSQL、MySQL、SQLiteで動作するデータベースバックのアダプターで、これら3つすべてを置き換えます。

このアーキテクチャの転換により、運用の複雑さが大幅に軽減されます。Redisインスタンスの監視、スケーリング、メンテナンスが不要になります。トレードオフはスループットです。高負荷シナリオではRedisの方が依然として高速ですが、大多数のアプリケーションにとって、データベースバックのアダプターは十分以上のパフォーマンスを発揮します。

Solid Queue：バックグラウンドジョブ処理

Solid Queueは、Sidekiq、Resque、Delayed Jobをデータベースバックのactive Jobバックエンドで置き換えます。PostgreSQL 9.5以上、MySQL 8.0以上ではFOR UPDATE SKIP LOCKEDを活用し、SQLiteでは適切にフォールバックします。

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

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

Pumaプラグインにより、開発環境ではWebサーバーと同時にSolid Queueが起動するため、別プロセスの管理が不要になります。

# config/puma.rb
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"] || Rails.env.development?

Solid Queueは、定期実行ジョブ、同時実行制御、キューごとの一時停止・再開といったミッションクリティカルな機能をサポートしています。毎分10,000件未満のジョブを処理するアプリケーションであれば、問題なく負荷を処理できます。

Solid CacheとSolid Cable

Solid Cacheは、HTMLフラグメントキャッシュをMemcachedやRedisの代わりにデータベースに保存します。ディスクストレージ（SSD/NVMe）のコストはRAMのごく一部であるため、より大きなキャッシュプールとより長い保持期間を実現できます。Basecampでは、本番環境で60日間保持の10 TB Solid Cacheを運用しています。

# config/environments/production.rb
config.cache_store = :solid_cache_store

Solid Cableは、Action CableのRedis pub/subアダプターを置き換えます。WebSocketメッセージはデータベーステーブルに書き込まれ、デフォルトで100msごとにポーリングされます。ほとんどのユースケースでほぼリアルタイムの動作を実現し、メッセージは24時間後に自動的に削除されます。

# config/cable.yml
production:
  adapter: solid_cable
  polling_interval: 0.1
  keep_messages_around_for: 1.day

組み込み認証ジェネレーター

Rails 8には、セッションベースのログイン、ログアウト、パスワードリセットのスキャフォールディングを生成するネイティブ認証ジェネレーターが搭載されています。基本的な認証機能に外部gemは不要です。

# Generate the authentication scaffolding
bin/rails generate authentication

このコマンドにより、Userモデル、Sessionモデル、SessionsController、PasswordsController、およびAuthenticationコンサーンが作成されます。生成されるコードはbcryptを使用したhas_secure_passwordを採用し、レート制限（IPあたり3分間に10回のログイン試行）が含まれています。

# app/controllers/concerns/authentication.rb
module Authentication
  extend ActiveSupport::Concern

  included do
    before_action :require_authentication
    helper_method :authenticated?
  end

  private

  def require_authentication
    resume_session || request_authentication
  end

  def resume_session
    Current.session = find_session_by_cookie
  end

  def find_session_by_cookie
    Session.find_by(id: cookies.signed[:session_id]) if cookies.signed[:session_id]
  end

  def request_authentication
    session[:return_to_after_authenticating] = request.url
    redirect_to new_session_path
  end

  def authenticated?
    Current.session.present?
  end
end

パスワードリセットは、データベースに保存されたトークンではなく、has_secure_passwordが生成する署名付きの有効期限付きトークンを使用します。ジェネレーターには、サインアップ、メール認証、ソーシャルログインは含まれていません。これは意図的な設計判断です。生成されるコードはDeviseの代替ではなく、拡張するための基盤として機能します。

params.expectによる安全なパラメーター処理

Rails 8では、params.require.permitパターンのより安全な代替としてparams.expectが導入されています。この新しいメソッドは、キーが存在しない場合にnilを黙って返すのではなく、例外を発生させます。

# Before (Rails 7)
def user_params
  params.require(:user).permit(:name, :email, :role)
end

# After (Rails 8)
def user_params
  params.expect(user: [:name, :email, :role])
end

expectメソッドは、:userキーが存在し、許可された属性のみを含むことを強制します。キーが存在しない場合はActionController::ParameterMissingが即座に発生し、下流でのサイレントなバグを防止します。

Propshaft：新しいデフォルトアセットパイプライン

Propshaftは、デフォルトのアセットパイプラインとしてSprocketsを置き換えます。Sprocketsがコンパイル、ミニファイ、フィンガープリントを単一のモノリシックなシステムで処理していたのに対し、Propshaftは静的アセットの配信とフィンガープリントに特化しています。

JavaScriptのバンドルについては、Propshaftはesbuild、Vite、Bunなどのモダンなツールに委譲します。CSS処理はTailwind CLIまたはdart-sassを経由します。その結果、現在のフロントエンドツーリングに整合した、より高速で予測可能なアセットパイプラインが実現されます。

# Gemfile (Rails 8 default)
gem "propshaft"

# No configuration needed for basic usage
# Assets in app/assets are served and fingerprinted automatically

既存のアプリケーションでSprocketsを使用している場合は、引き続き使用できます。移行パスとしては、Sprockets固有のディレクティブ（//= require）を削除し、import mapsまたはJavaScriptバンドラーに移行します。

Kamal 2とThruster：ゼロダウンタイムデプロイ

Rails 8には、Kamal 2がプリコンフィギュアされています。Kamal 2は、新しいLinuxサーバーを単一のコマンドで本番サーバーにプロビジョニングするデプロイツールです。Kamal 2は、Traefikを専用のリバースプロキシであるKamal Proxyで置き換えています。

# Deploy to a fresh server
kamal setup

# Subsequent deployments
kamal deploy

ThrusterはKamal ProxyとPumaの間に位置し、ファイルダウンロードのためのX-Sendfileアクセラレーション、自動アセット圧縮（gzip/brotli）、HTTP/2サポートを提供します。Rails 8が生成するDockerfileには、デフォルトでThrusterが含まれています。

# Excerpt from Rails 8 generated Dockerfile
RUN gem install thruster
CMD ["thrust", "./bin/rails", "server"]

このスタック（Kamal 2 + Kamal Proxy + Thruster + Puma）は、NginxやHAProxyなどの外部サービスなしで、SSL終端、ゼロダウンタイムデプロイ、ローリングリスタートを処理します。

本番環境向けSQLiteの強化

Rails 8では、本番環境でのSQLiteサポートが改善されています。コネクションプーリング、WALモード、改善された並行処理により、小規模から中規模のアプリケーションでSQLiteが実用的になっています。Solid Trifectaと組み合わせることで、単一サーバーのRails 8アプリケーションは外部データベースサーバーなしで完全にSQLite上で実行できます。

# config/database.yml (SQLite production setup)
production:
  primary:
    adapter: sqlite3
    database: storage/production.sqlite3
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  cache:
    adapter: sqlite3
    database: storage/production_cache.sqlite3
  queue:
    adapter: sqlite3
    database: storage/production_queue.sqlite3
  cable:
    adapter: sqlite3
    database: storage/production_cable.sqlite3

この構成により、アプリケーションスタック全体が4つのSQLiteファイルから実行されます。Kamalはストレージディレクトリを永続ボリュームとしてマウントし、コンテナの再起動時にもデータが保持されることを保証します。

Rails 7からRails 8へのアップグレード手順

Rails 7.2からRails 8.0への移行パスは、アプリケーションが既に非推奨の警告に対応している場合は比較的簡単です。Rails 7.0または7.1を使用しているアプリケーションの場合は、段階的にアップグレードする必要があります。7.0から7.1、次に7.2、そして8.0の順序で進めます。

ステップ1：依存関係の更新

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

bundle update rails

ステップ2：アップデートタスクの実行

bin/rails app:update

このコマンドは、設定ファイルをRails 8のデフォルトに更新します。git diffを使用して各変更を慎重にレビューしてください。主な変更点として、新しいRegexp.timeoutのデフォルト値（1秒）、更新されたdb:migrateの動作（新規データベースでのスキーマロード）、Propshaftの設定があります。

ステップ3：スキーマの並び替え処理

Rails 8はschema.rbのカラムを実際のデータベースカラム順に並び替えます。この表面的な差分を実際のマイグレーション変更から分離するため、すぐにスキーマダンプを実行します。

bin/rails db:schema:dump
git add db/schema.rb
git commit -m "Reorder schema columns for Rails 8"

ステップ4：新機能の段階的な導入

Solid Trifecta、Propshaft、認証ジェネレーターは、既存のアプリケーションではオプトイン方式です。コアのアップグレードが安定した後、個別に導入します。

1. ジョブアダプターをSolid Queueに置き換える
2. キャッシュストアをSolid Cacheに切り替える
3. Action CableをSolid Cableに移行する（該当する場合）
4. アセットパイプラインのPropshaft移行を評価する

ステップ5：パラメーター処理の更新

コントローラー全体でparams.require.permitの呼び出しをparams.expectに置き換えます。この変更は任意ですが、より強力なパラメーターバリデーションのために推奨されます。

Rails 8.1：継続可能ジョブと組み込みCI

2025年10月にリリースされたRails 8.1は、Rails 8の基盤の上に2つの注目機能を追加しています。継続可能ジョブ（ActiveJob::Continuable）は、長時間実行されるジョブを再開可能なステップに分割します。インポート処理の途中でサーバーが再起動された場合、ジョブは最初からやり直すのではなく、停止した場所から正確に再開します。

# app/jobs/import_records_job.rb
class ImportRecordsJob < ApplicationJob
  include ActiveJob::Continuable

  def perform(cursor:)
    records = Record.where("id > ?", cursor.value || 0).limit(1000)

    records.each do |record|
      process(record)
      cursor.advance(record.id)
    end
  end
end

Rails 8.1では、組み込みCI設定とネイティブMarkdownレンダリングも導入されており、外部依存関係がさらに削減されています。

まとめ

• Solid Trifecta（Queue、Cache、Cable）により、ジョブ、キャッシュ、WebSocketにおけるRedisのハード依存が排除される
• 組み込み認証ジェネレーターは、サードパーティgemなしでセッションベース認証の基盤を提供する
• params.expectは、params.require.permitをより厳格で安全なパラメーター処理で置き換える
• PropshaftがデフォルトのアセットパイプラインとしてSprocketsを置き換え、バンドルはモダンなツールに委譲される
• Kamal 2とThrusterにより、NginxやCapistranoなしでゼロダウンタイムデプロイが実現される
• Rails 7.2からのアップグレードは段階的に実施可能：依存関係の更新、app:updateの実行、新機能の順次導入
• Rails 8.1は継続可能ジョブと組み込みCIを追加し、外部ツールの必要性をさらに低減する