Rails 8ガイド: 機能、要件、アップグレードパス (2026)

Rails 8 ガイド：機能、要件、アップグレードパス (2026)

Rails 8.0は2024年11月7日にリリースされ、Ruby 3.2.0以降が必要です。主な機能は、組み込み認証ジェネレーター、Solid Queue/Cache/Cable（データベースベース、Redis不要）、Kamal 2 + Thrusterによるデプロイ、Propshaft、本番環境対応のSQLiteです。Rails 8.1（2025年10月）が現在のリリースシリーズです。Rails 8.0は2026年11月までセキュリティ修正のみを受け付けます。

このガイドでは、使用するコマンドとデフォルト設定とともに、Rails 8の各機能について説明します。また、現在のサポート期間、Rails 7.1または7.2からのアップグレードチェックリスト、Rails 8.1での変更点の概要も確認できます。

このガイドのすべてのバージョンに関する記述は、Rails 8.1.3.1とRuby 3.4.10での新規 rails new アプリケーションで検証されています。

要件とサポート状況

Rails 8.0と8.1はどちらもRuby 3.2.0以降が必要です。rails gemはそのgemspecを通じてこれを強制するため、Ruby 3.1以前では gem install rails は失敗します。実際には、最小バージョンよりも新しいRubyを使用したいでしょう。現在のRuby 3.4シリーズは、YJITの改善と最も長いRubyセキュリティパッチの提供期間をもたらします。

以下は、2026年8月時点のRailsメンテナンスポリシーに基づいた、各最近のRailsバージョンの状況です。

この表からわかることは2つあります。第一に、Rails 8.0は最終段階にあります。セキュリティ修正のみを受け付けており、それらは2026年11月7日に終了します。第二に、7.1と7.2の両方はすでにサポートリストから完全に外れています。どちらかを本番環境で使用している場合は、アップグレードチェックリストを「いつか」ではなく「今すぐ」行うべきものとして扱ってください。

最小RubyバージョンはRailsアップグレードガイドから取得され、8.1の機能セットはRails 8.1リリースノートに記載されています。

組み込み認証がシンプルに

Railsは何年もの間、認証のビルディングブロックを提供してきました。Rails 5では has_secure_password、そしてRails 7.1では normalizes、generates_token_for、authenticate_by です。

Rails 8は、それらのピースをジェネレーターにまとめました。1つのコマンドで、データベースベースのセッションとパスワードリセットを含む、完全なセッションベースの認証システムをスキャフォールディングできます。

ジェネレーターはモデル、コントローラー、メーラー、ビューを作成します。

生成されたコードはアプリケーション内に存在するため、そのすべての行を読み取り、変更できます。セッションロジックを隠すエンジンはないため、このジェネレーターは、以前は習慣でDeviseを使用していたチームにとって強力なデフォルトとなります。残りは、アプリケーションに合わせたサインアップフローを追加することだけです。

Solidアダプターによる軽量なRailsデプロイ

Rails 8は、典型的な本番アプリケーションが必要とするサービス数を削減します。ジョブキュー、キャッシング、Pub/Subメッセージングは、従来はRedisをリレーショナルデータベースの隣で実行する必要がありました。Rails 8は、新しいアプリにデフォルトでインストールされる3つのデータベースベースのアダプターでこれを置き換えます。Solid Queue、Solid Cache、Solid Cableです。

1. Solid Queue は新しいデフォルトのActive Jobバックエンドです。PostgreSQL、MySQL、またはSQLiteでの効率的なジョブディスパッチのために FOR UPDATE SKIP LOCKED メカニズムを使用し、同時実行制御、リトライ、繰り返しジョブを備えています。HEYでは1日あたり2000万件のジョブを実行しています。
2. Solid Cache は、RAMの代わりにディスクストレージで Rails.cache をバックアップします。最新のNVMeドライブは、ほとんどのワークロードで十分に高速であり、ディスク容量は安価です。デプロイをまたいで永続化されるはるかに大きなキャッシュ、および暗号化されたストレージと保持ポリシーが得られます。
3. Solid Cable は、本番環境でのデフォルトのAction Cableアダプターです。ほとんどの状況でRedisと同等のパフォーマンスで、高速なデータベースポーリングを介してアプリケーションと接続されたクライアント間でメッセージを中継します。

新しいRails 8アプリは、これら3つすべてを自動的に設定します。生成された Gemfile にはgemが含まれ、production.rb は config.cache_store = :solid_cache_store と config.active_job.queue_adapter = :solid_queue を設定し、cable.yml は solid_cable を指します。既存のアプリは、例えば bin/rails solid_queue:install のように、インストーラーを使用して各アダプターを個別に採用できます。

RedisをSolid Queueに切り替えると、ジョブキューがデータベースに移動します。これは注意が必要です。AppSignalはSolid Queueをインスツルメントするため、キューのレイテンシと失敗したジョブがRailsのパフォーマンスデータと並んで表示されます。

Kamal 2とThrusterによる簡単なデプロイ

Rails 8は、デフォルトのデプロイツールとしてKamal 2を搭載しています。Kamalは、PaaSを介さずに、アプリケーションをDockerコンテナとしてクラウドVM、ベアメタルサーバー、またはVPSにデプロイします。単一のコマンド（kamal setup）で、標準的なLinuxボックス上に本番環境対応のRails環境をプロビジョニングできます。

Kamal 2は、すべての新しいアプリの Gemfile に含まれるRails用に構築されたHTTPプロキシであるThrusterとペアになります。Thrusterは、ゼロダウンタイムデプロイ、HTTP/2サポート、Let's Encryptによる自動SSL証明書、Pumaの前面でのアセットキャッシングと圧縮を追加します。複数のアプリケーションが追加設定なしで単一のサーバーを共有できます。

Rails 8.1以降、Kamalは基本的なデプロイのためにリモートレジストリ（Docker Hubなど）を必要としなくなりました。Kamal 2.8はデフォルトでローカルレジストリを使用するため、最初のデプロイにはサーバーとSSHアクセス以外は何も必要ありません。

別の方法でデプロイする場合は、rails new に --skip-kamal を渡して、既存のワークフローを維持してください。kamal および thruster gemは require: false とマークされているため、どちらの場合でもアプリケーションの起動時間に影響を与えません。

SQLiteが本番環境に対応

Rails 8は、SQLiteを開発時の利便性からサポートされる本番データベースへと昇格させました。これは、SQLiteアダプターとRubyドライバーに対する広範な作業によって支えられています。

Solidアダプターは主要な利用者です。シングルサーバーアプリでは、SQLiteは現在、プライマリデータベースと並んでActive Job、Rails.cache、Action Cableをサポートできます。これにより、小規模および中規模のアプリケーションは、依存関係のない真のスタック（1つのサーバー、1つのデータベースエンジン、Redisなし）を持つことができます。

アダプター自体もRails 8で本番環境に焦点を当てた改善を収集しました。

• create_virtual_table を介した全文検索と仮想テーブル。
• より高速なデータシーディングのためのバルクフィクスチャ挿入。
• より良い同時実行性のために、トランザクションはデフォルトで IMMEDIATE モードになります。
• SQLite3::BusyException は ActiveRecord::StatementTimeout に変換されるため、ビジーデータベースエラーはPostgreSQLおよびMySQLの同等物と同様に動作します。

PostgreSQLとMySQLは、マルチサーバーセットアップまたは重い書き込み同時実行性には引き続き適切な選択です。しかし、「本番環境でのSQLite」は、このリリースでジョークではなくなりました。

Propshaftによるアセットパイプラインの新時代

Rails 8は、10年以上にわたるSprocketsに代わり、Propshaftをデフォルトのアセットパイプラインとして採用しました。

Sprocketsは、最新のJavaScriptビルドツールやHTTP/2が登場する前に設計され、それらに対応するために多くの責任を蓄積しました。トランスパイル、バンドル、ミニファイです。Propshaftはこれらすべてをドロップします。Propshaftは2つのことを行います。アセットパスを解決し、キャッシュバスターのためにファイル名にダイジェストをスタンプします。

この狭いスコープは、今日のRailsアプリケーションの構築方法に適合しています。インポートマップはビルド不要のJavaScriptパスをカバーし、より重いフロントエンドを持つアプリケーションはesbuild、Bun、またはViteを使用します。どちらの場合でも、アセットパイプラインはビルドツールである必要はなくなり、Propshaftもそうしようとしません。

新しいscriptフォルダとActive Recordの改善

Rails 8は、データ移行やクリーンアップタスクなどの単発および汎用スクリプトのために script フォルダを追加しました。対応するジェネレーターがそれらをスキャフォールディングします。

スクリプトは次のように実行します。

これにより、ユーティリティスクリプトが整理され、単発コードが永続的に残りがちな lib/tasks から分離されます。

Active Recordの多数の改善

Active RecordもRails 8で一連の小さなアップグレードを収集しました。

• PostgreSQLの float4 と float8 は、現在区別される型になりました。
• drop_table は複数のテーブルを一度に受け入れ、create_schema/drop_schema はマイグレーションで元に戻すことができます。
• 高度なPostgreSQLテーブルオプション（継承やパーティショニングを含む）が create_table でサポートされるようになりました。
• 新しいデータベースのマイグレーションでは、スキーマをロードしてから保留中のマイグレーションを実行するため、CIとオンボーディングが高速化されます。
• 開発環境ではクエリログタグがデフォルトで有効になるため、SQLステートメントをアプリケーションコードの正確な行にトレースできます。
• MySQL 5.6.4以降が必要になり、日付時刻列に精度が追加されました。

Rails 7.1または7.2からのアップグレード

Rails 7.1と7.2の両方がセキュリティサポートの終了に達しました。一般的な落とし穴を避けるためのアップグレードパスは次のとおりです。

1. まずサポートされているRubyに移行してください。 Rails 8はRuby 3.2.0以降を必要とします。Ruby 3.4がより良いターゲットです。現在のRailsバージョンでRubyをアップグレードし、それを個別にリリースしてください。
2. 現在のシリーズの最新パッチリリースに更新してください（執筆時点では7.1.6または7.2.3.x）。他のものを変更する前に、テストスイートがグリーンであることを確認してください。
3. 一度に1つのマイナーバージョンずつ移動してください：7.1から7.2、次に7.2から8.0、次に8.0から8.1。各ステップで bin/rails app:update を実行し、変更されたすべてのファイルをレビューしてください。
4. 新しいフレームワークのデフォルトを意図的に採用してください。 アプリケーションがクリーンに起動するまで config.load_defaults を古いバージョンに設定したままにし、その後 config/initializers/new_framework_defaults_8_0.rb をフラグごとに1つずつ処理してください。
5. Solidアダプターをオプトインとして扱ってください。 既存のアプリケーションは、アップグレード時にRedisベースのキャッシュ、キュー、およびケーブル設定を維持します。可能であれば、インストーラーを使用して solid_cache、solid_queue、または solid_cable を個別に移行してください。
6. 開始する前に、監視およびデプロイgemがRails 8をサポートしているか確認してください。 AppSignalのRubyインテグレーションリストには、Solid Queueを含むどのライブラリが自動的にインスツルメントされているかが示されています。

Railsアップグレードガイドは、各ホップの設定変更について詳細に文書化しています。

Rails 7.1から既に持っているもの

7.1（またはそれ以前）からアップグレードする場合、そのリリースで追加された機能は既に持っており、Rails 8でそれらは変更されません。Rails 7.1は、非同期クエリAPI（async_sum、async_pluck など）、.with を介した共通テーブル式、instance_methods: false を持つ enum、および has_secure_password の password_challenge アクセサーをもたらしました。また、Rails 8が構築するデプロイの基盤も導入しました。デフォルトのDockerfile、/up ヘルスチェックエンドポイント、Rails.env.local?、および利用可能なプロセッサに合わせたPumaワーカー数です。テンプレートは、受け入れ可能な部分引数を宣言するための locals: マジックコメントを獲得しました。これらすべては変更なく引き継がれるため、7.1から8へのジャンプは、既存のAPIを再学習するのではなく、新しいデフォルトを採用することです。

Rails 8.1での変更点

Rails 8.1（2025年10月リリース）は、現在のリリースシリーズです。Rails 8.0スタックをそのまま維持し、開発者向けの改善を重ねています。Rails 8.1リリースノートには7つの主要機能がリストされています。

• Active Jobの継続（Continuations）。長時間実行されるジョブは、個別のステップを宣言し、再起動後に最後に完了したステップから再開できます。これは、デプロイ中にジョブコンテナがシャットダウンするために30秒しか与えられないKamalにとって重要です。
• 構造化イベントレポート。Rails.event.notify は、登録したサブスクライバーにタグとコンテキストを持つ構造化イベントを発行します。これは、人間向けのRailsロガーを解析するよりもログパイプラインに適しています。
• ローカルCI。config/ci.rb のCI宣言DSL（bin/ci で実行）は、小規模および中規模のアプリケーションのファーストクラスのテストランナーとして高速な開発マシンを変換します。
• Markdownレンダリング。コントローラーは render markdown: でMarkdownリクエストに直接応答できます。これは、MarkdownがAIツールが消費するデフォルトの形式になりつつあることへの配慮です。
• コマンドライン認証情報取得。rails credentials:fetch は暗号化された認証情報ストアから値を取得するため、Kamalのシークレットは外部シークレットマネージャーなしでRailsから直接取得できます。
• 非推奨の関連付け。関連付けに deprecated: true をマークすると、Active Recordは削除前に、直接的または間接的なすべての使用状況を報告します。
• レジストリ不要のKamalデプロイ。Kamal 2.8はデフォルトでローカルレジストリを使用するため、基本的なデプロイでDocker Hubの前提条件が不要になります。

継続を有効にしたジョブは次のようになります。

インポート中にコンテナが再起動しても、ジョブはバッチ全体を再処理するのではなく、保存されたカーソルから再開します。

これらのいずれもRails 8.0アプリケーションコードを変更しないため、8.0から8.1へのアップグレードは小規模です。8.0のセキュリティサポートは2026年11月に終了することを考えると、アップグレード時に8.0で止まる理由はほとんどありません。

まとめ

Rails 8はデプロイに焦点を当てたリリースです。認証が標準装備され、Redisがスタックから除外され、rails new から所有する本番サーバーまでエンドツーエンドのパスが提供されます。Rails 8.1は、再開可能なジョブ、構造化イベント、ローカルCIでそれを締めくくります。

新しいアプリケーションを開始する場合、Ruby 3.4上のRails 8.1がデフォルトの選択肢です。7.1または7.2でアプリケーションを保守している場合、サポート期間は既に終了しており、上記のチェックリストがパッチ適用済みのバージョンへの最短ルートです。

変更点の完全なリストについては、Rails 8.0リリースノートとRails 8.1リリースノートをお読みください。参加したい場合は、Rails GitHubリポジトリに未解決の課題と貢献ガイドラインがリストされています。

お読みいただきありがとうございます！

P.S. Ruby Magicの投稿をいち早く読みたい場合は、Ruby Magicニュースレターを購読して、投稿を見逃さないようにしてください！