Contents
アップグレード前のチェックリスト
本セクションでは、Rails 8.1 に移行する前に実施すべき 事前確認項目 をまとめます。これらを完了させておくことで、アップグレード時の障害リスクを大幅に低減できます。
| No | 項目 | 確認内容 |
|---|---|---|
| 1 | テストスイートの網羅性 | rails test / rspec がすべてのパスで成功するか。カバレッジが 80 % 以上推奨。 |
| 2 | 依存 gem の対応状況 | bundle outdated で主要な gem（Devise、Sidekiq 等）が Rails 8.1 に非互換でないか公式ドキュメントを確認。 |
| 3 | Ruby バージョン | Rails 8.1 は Ruby 3.3 以上が推奨です。ruby -v でバージョンを確認し、必要に応じてアップデート。 |
| 4 | CI/CD パイプラインの設定 | RAILS_MASTER_KEY の管理や rails credentials:fetch が使用できるか事前に検証。 |
| 5 | バックアップ戦略 | 本番データベース・アセットのスナップショット取得手順をドキュメント化。 |
Rails 8.1 の主要変更点
Active Job Continuations（試験的機能）
Active Job Continuations は、長時間実行するバックグラウンドジョブを ステップ単位で中断・再開 できる拡張です。現在は Rails の
mainブランチ上で RFC が進行中（Rails RFC #2023）であり、正式リリースは未定です。
機能概要
- ジョブ実行中に例外やサーバ停止が発生した場合、現在のステップと状態を永続化。
- 次回ジョブがキューに再投入される際、自動的に保存されたステップから処理を再開。
実装イメージ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
class ImportCsvJob < ApplicationJob include ActiveJob::Continuable # 現在は試験的モジュール def perform(file_path, step = :read) case step when :read rows = CSV.read(file_path) continue_with(:process, rows) # 次ステップへ遷移 when :process rows.each { |row| process_row(row) } end end end |
利用上の注意点
ActiveJob::Continuableは Rails Edge（開発ブランチ）でのみ利用可能です。production 環境へ導入する場合は、互換性テストとバックアップ戦略を徹底してください。- 永続化先はデフォルトで Redis ですが、後述の Solid Queue が有効になると別のストレージに切り替えられます。
credentials:fetch コマンド（実装予定）
Rails 8.1 の credentials 機能拡張として、
rails credentials:fetch PATHというコマンドが提案されています。現時点では公式リリースに含まれていませんが、Rails Edge Guides に記載があります。
コマンドの目的
- 環境ごとの暗号化ファイル（例：
config/credentials/production.yml.enc）のみを復号し、標準出力やパイプで利用できる。 - CI/CD パイプラインにおいて、不要な認証情報が漏洩するリスクを低減。
典型的な使用例（GitHub Actions）
|
1 2 3 4 5 6 7 8 9 10 |
steps: - uses: actions/checkout@v3 - name: Set master key run: echo "${{ secrets.MASTER_KEY }}" > config/master.key - name: Fetch production DB credentials run: | rails credentials:fetch production/database.yml.enc > tmp/db.yml |
注意点
- コマンド実行には
RAILS_MASTER_KEYが必須です。キーが設定されていない場合は復号エラーとなります。 - 本機能は Rails Edge でのプレビュー版であり、将来の正式リリースに向けたフィードバックを受け付けています。
Solid Trifecta：Queue・Cache・Cable の代替実装
Rails 8 系列では、外部依存（主に Redis）を減らすために Solid Queue, Solid Cache, Solid Cable が標準 gem として提供されています。これらは 2025 年に Rails Core Team が公式に採択した実装であり、現在の安定版 Rails 8.0.x にも組み込まれています。
各コンポーネントの概要
| コンポーネント | 主な役割 | デフォルトストア |
|---|---|---|
| Solid Queue | バックグラウンドジョブ実行エンジン | :memory_store（開発・テスト） |
| Solid Cache | キー/バリューキャッシュ層 | :memory_store または :file_store |
| Solid Cable | ActionCable の WebSocket アダプタ | :async（シングルスレッド） |
導入手順
- Gem を追加
bash
bundle add solid_queue solid_cache solid_cable - インストーラ実行
bash
rails generate solid:install - 設定ファイル
config/solid.rbの例
ruby
SolidQueue.configure do |c|
c.max_threads = 8 # 同時ジョブ数上限
c.shutdown_grace_period = 45 # 秒単位での終了猶予（Kamal と併用可）
end
SolidCache.configure do |c|
c.store = :memory_store
end
SolidCable.configure do |c|
c.adapter = :async
end
Sidekiq からの移行ポイント
queue_asの設定はそのままで、内部的に Solid Queue が使用されます。- ActionCable のサーバ起動コマンドは変更不要です。
参考：Solid 系列の公式ドキュメントは solid_queue README、solid_cache README に掲載されています。
Propshaft の改善点
Rails 8.1 では、アセットパイプラインのデフォルト実装である Propshaft がいくつかの重要な改良を受けました。これにより、ビルド速度とキャッシュヒット率が向上し、開発者がエラー原因を特定しやすくなります。
主な改善内容
| 改善項目 | 具体的効果 |
|---|---|
| ハッシュ化ファイル名による長期キャッシュ | ブラウザ側での再取得回数が大幅に減少。application-3f4a2c.css のようにハッシュ付きで出力。 |
| 詳細エラーロギング | コンパイル失敗時に対象アセットのフルパスとスタックトレースを標準出力へ表示。 |
--trace オプション拡充 |
rails assets:precompile --trace で依存ツリーが可視化され、ビルド順序の問題を迅速に検出可能。 |
設定例（config/initializers/propshaft.rb）
|
1 2 3 4 5 6 7 8 |
Rails.application.config.assets = ActiveSupport::OrderedOptions.new # キャッシュディレクトリを共有ストレージへ変更（複数サーバ間で再利用） Rails.application.config.assets.cache_path = "tmp/propshaft-cache" # コンパイルエラー時に例外を送出し、CI が失敗するように設定 Rails.application.config.assets.raise_runtime_errors = true |
移行手順（Sprockets → Propshaft）
gem "propshaft"をGemfileに追加し、bundle install。rails propshaft:installで初期設定ファイルを生成。- 従来の
app/assetsディレクトリ構造はそのまま使用可能です。 - 本番環境で
RAILS_ENV=production rails assets:precompileを実行し、ハッシュ付きファイルが正しく出力されることを確認。
公式ガイド：Rails Edge の Propshaft guide に詳細があります。
段階的なアップグレード手順
1. 開発ブランチでの事前検証
git checkout -b upgrade-to-8-1を作成し、ローカル環境で Rails 8.1 の HEAD（rails main）をインストール。bundle update rails後にテストスイートを実行し、失敗がないか確認。
2. 非推奨 API の置換
| 削除／非推奨 | 推奨置換 |
|---|---|
ActiveSupport::TimeZone#now |
Time.zone.now |
ActionController::Parameters#permit!（デフォルト変更） |
明示的に許可リストを指定 |
Rails::Server#default_options |
config.server_options に移行 |
sass-rails 系列 |
Propshaft + cssbundling‑rails 推奨 |
3. 本番ステージングでのリハーサル
- ステージング環境に 同一構成 のデータベースとアセットを用意し、実際に
RAILS_ENV=staging rails db:migrate && rails assets:precompileを走らせる。 - デプロイツール（例：Kamal）での Graceful shutdown 設定が適切か検証。
4. 本番環境へのデプロイ
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# 1. メンテナンスモード開始（任意） rails maintenance:on # 2. コードプッシュとデプロイスクリプト実行 git push origin upgrade-to-8-1 kaml deploy production # 3. DB マイグレーションとアセットプリコンパイル bundle exec rails db:migrate RAILS_ENV=production bundle exec rails assets:precompile RAILS_ENV=production # 4. メンテナンスモード解除 rails maintenance:off |
ポイント：デプロイ前に必ず
kaml config validateで設定ミスを検出し、shutdown_grace_periodが期待通りか確認してください。
デプロイ時の留意点（Kamal）
Kamal のシャットダウン猶予時間
公式 README（kamal/kamal）によると、デフォルトで 30 秒 の shutdown_grace_period が設定されています。これはコンテナが停止シグナルを受け取った後に、プロセスが終了するまでの猶予です。
| 項目 | デフォルト値 | 変更方法 |
|---|---|---|
shutdown_grace_period |
30 秒 | kaml.yml の services.<name>.shutdown_grace_period: 45 |
運用ベストプラクティス
- 長時間ジョブは Continuations 対応
-
試験的機能ですが、Kamal の停止猶予内に完了できない処理は必ず状態永続化を行う設計が推奨されます。
-
Grace Period のチューニング
- 本番環境でのスケールアウト・イン時には、
shutdown_grace_periodを 45〜60 秒に延長し、ジョブの中断リスクを低減します。 -
設定変更後はステージングで シミュレーションデプロイ を実施し、期待通りに停止できるか検証してください。
-
モニタリングとアラート
- デプロイ中のジョブ失敗やコンテナ強制終了が頻発する場合は、
Kamalのログ（docker logs <container>）とActiveJobのエラー通知を統合し、Slack 等へ自動報告できるようにします。
まとめ
- Rails 8.1 は生産性向上と運用安定化を目的とした多くの改善が盛り込まれていますが、一部機能は 試験的 または 開発ブランチ の状態です。公式リリース前に必ず最新ドキュメントで確認してください。
- アップグレード手順 は「事前検証 → 非推奨 API 置換 → ステージングリハーサル → 本番デプロイ」の四段階で実施すれば、障害リスクを最小限に抑えられます。
- Kamal のデフォルトシャットダウン猶予は 30 秒です。長時間ジョブや Redis 依存の削減（Solid Trifecta）を活用することで、デプロイ時の停止リスクをさらに低減できます。
本ガイドが、Rails 8.1 への安全な移行と運用最適化に役立つことを願っています。 🚀