「Rails 8からはRedisがいらないらしい」——そんな話を聞いて、長年Sidekiq＋Redisで運用してきた身としては、正直ちょっと身構えていませんか？背景ジョブもキャッシュも当たり前のようにRedisに任せてきたのに、それをデータベースだけで動かすと言われても、「本当に大丈夫なの？」と疑いたくなりますよね。
その主役が、Rails 8で標準搭載された Solidトリオ（Solid Queue / Solid Cache / Solid Cable） です。新規のRails 8アプリを rails new すると、これらが最初から組み込まれた状態でプロジェクトが作られます。ねらいはシンプルで、背景ジョブ・キャッシュ・WebSocketを、追加のミドルウェア（Redis）なしにデータベースだけで完結させることです。
この記事では、まず「結局どう使い分ければいいのか」の結論を先に示したうえで、Solidトリオそれぞれの役割、Solid Queue / Solid Cacheの具体的な導入手順、そして既存のSidekiqアプリを無理に剥がすべきか・残すべきかという一番気になる判断基準まで、正直に線引きしていきます。Solid系gemを本番で動かすときの database.yml の書き方は Rails8に入るsolid_queueなどのgemを使った時のdatabase.ymlの書き方 にまとめているので、設定で詰まったらそちらも合わせてどうぞ。
まず結論：新規はSolid、既存は急いで剥がさなくていい
細かい仕組みに入る前に、いちばん知りたいところだけ先に言ってしまいます。判断はこの2軸で十分です。
- 新規のRails 8アプリ：そのままSolidトリオでOK。Redisを立てる理由がない限り、デフォルトに乗っておくのがいちばん楽です。
- 既存のSidekiq＋Redisアプリ：動いているなら急いで剥がす必要はありません。Solid Queueは「Redisという運用対象をひとつ減らせる」のが魅力ですが、Sidekiqの豊富な機能・管理画面・エコシステムを手放すことでもあります。移行はメリットとコストを天秤にかけて、段階的に判断すればよい話です。
「Rails 8＝Redis禁止」ではありません。あくまでRedisなしでも本番が回る選択肢が標準になった、というのが正確な理解です。ここを踏まえたうえで、中身を見ていきましょう。
Solidトリオとは？3つのgemの役割
Solidトリオは、これまでRedisに頼っていた3つの機能を、それぞれデータベースをバックエンドにして置き換えるgem群です。名前は似ていますが担当領域はきれいに分かれています。
| gem | 置き換える対象 | 担当する機能 |
|---|---|---|
| Solid Queue | Sidekiq / Resque（＋Redis） | Active Jobのバックエンド（背景ジョブ） |
| Solid Cache | Redis / Memcached | Rails.cache（キャッシュストア） |
| Solid Cable | Redis（Action Cable用） | Action Cableのpub/subバックエンド |
共通しているのは、すべて保存先がデータベース（PostgreSQL / MySQL / SQLite）だという点です。つまりこの3つを使えば、アプリ本体が使うDBのほかに用意するミドルウェアがゼロになります。従来のRedisありきの構成と比べると、インフラがどれだけシンプルになるかは一目瞭然です。
それぞれのgemの本番向けの database.yml の書き分け（本体用・queue用・cache用・cable用でデータベースを分ける方法）は、solid_gemsを使った時のdatabase.ymlの書き方 で実際にハマった話と一緒に解説しています。この記事は「そもそも何のために・どう使うか」に絞って進めます。
なぜデータベースで足りるのか？（速度の心配への回答）
ここで多くの人が引っかかるのが、「ジョブのポーリングやキャッシュをDBでやったら、遅いし負荷が高いのでは？」という疑問だと思います。かつてのRailsでDBをキュー代わりにすると、ワーカー同士がロックを奪い合って詰まる、というのはよくある話でした。
Solid Queueがこの問題を回避しているカラクリが、モダンなRDBが備える FOR UPDATE SKIP LOCKED です。これは「すでに他のワーカーがロックしている行はスキップして、空いている次のジョブを取る」という取り出し方で、複数のワーカーがロック競合なく並列にジョブを拾えるようになっています。PostgreSQL・MySQLの新しめのバージョンで使え、SQLiteも対応しています。
Solid Cacheのほうは、「メモリ（Redis）ではなくSSD上のDBに置く」ことを前提に設計されています。SSDはRAMより安く大容量なので、より多くのキャッシュを長く持てるのがねらいです。速度面はRedisにわずかに譲るものの、実運用のヒット率ではむしろ有利に働く場面もある、という発想です。
要するに、「DBだから遅い・危ない」という古い前提を、モダンなSQL機能とSSD前提の設計で乗り越えている、というわけです。ここが腑に落ちると、脱Redisの現実味がぐっと増します。
Solid Queueの使い方（背景ジョブ）
ではいちばん出番の多いSolid Queueから、導入の流れを見ていきましょう。新規のRails 8アプリなら最初から入っていますが、既存アプリに後入れするケースを想定して手順を追います。
STEP1：インストール
gemを追加して、インストーラを実行します。専用のテーブルを作るマイグレーションと設定ファイルが生成されます。
$ bundle add solid_queue
$ bin/rails solid_queue:install
$ bin/rails db:migrate次に、Active Jobのバックエンドとしてsolid_queueを使うよう指定します。config/environments/production.rb（本番）に以下を書きます。
config.active_job.queue_adapter = :solid_queueSTEP2：ワーカーを動かす
ジョブを処理するワーカープロセスの動かし方は2通りあります。ここが「運用がラクになる」ポイントなので、しっかり押さえておきましょう。
ひとつは、専用プロセスとして起動する方法です。Sidekiqを別プロセスで立てていたのと同じイメージです。
$ bin/jobs startもうひとつが、小〜中規模アプリで特にうれしい Pumaのプラグインとしてインプロセスで動かす方法です。Webサーバー（Puma）と同じプロセスの中でジョブワーカーも回るので、動かすプロセスが1つで済みます。config/puma.rb に次の1行を足すだけです。
# config/puma.rb
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]あとは SOLID_QUEUE_IN_PUMA=1 を設定して起動すれば、Pumaがジョブワーカーも面倒を見てくれます。「小さく始めたい個人開発やスモールなサービスでは、Redisもワーカー専用プロセスも要らない」——これがSolid Queue最大の魅力です。負荷が上がってきたら、専用プロセス（bin/jobs start）へ切り出せばよいので、スモールスタートとスケールの両立ができます。
Solid Cacheの使い方（キャッシュ）
キャッシュを担うSolid Cacheも流れは同じです。インストールしてマイグレーションを流します。
$ bundle add solid_cache
$ bin/rails solid_cache:install
$ bin/rails db:migrateキャッシュストアとしてsolid_cacheを使うよう、config/environments/production.rb に設定します。
config.cache_store = :solid_cache_storeこれだけで、Rails.cache.fetch のようなおなじみのキャッシュAPIがそのままDBバックエンドで動きます。使い方のコードを書き換える必要はありません。
ひとつだけ知っておきたいのが、Solid Cacheの失効はLRUではなくFIFO（古く書かれたものから消えていく）だという点です。Redis/Memcachedの「使われていないものから消す（LRU）」に慣れていると挙動が違うので、キャッシュサイズの上限（保持世代）を意識して設計しましょう。「よく使われるから残るはず」という前提は置かないほうが安全です。
導入でつまずきやすい3つのポイント
「入れたのに動かない」で時間を溶かさないよう、実際にハマりがちな箇所を先回りしておきます。
- ジョブが実行されない：たいていはワーカーを起動していないのが原因です。
bin/jobs startを立てるか、Puma起動時にSOLID_QUEUE_IN_PUMA=1が入っているかを確認しましょう。config.active_job.queue_adapter = :solid_queueの設定漏れも定番です。 - 本番で「テーブルが無い」と言われる：Solid Queue / Solid Cacheはアプリ本体とは別のデータベース（スキーマ）を使う構成が基本です。
database.ymlのqueue/cache接続とmigrations_pathsの設定漏れがないか確認します。ここは database.ymlの書き方の記事 でつまずきどころを詳しく書いています。 - キャッシュが思ったより早く消える：前述のとおりSolid CacheはFIFOです。サイズ上限（保持世代）に達すると古いものから消えるので、「消えて困る値」はキャッシュではなくDBやセッションに置く、上限を見直す、で対処します。
Sidekiq / Redis と Solid Queue はどう違う？
ここまで読んで「じゃあ既存のSidekiqも今すぐ乗り換えるべき？」と思ったかもしれません。ですが冒頭の結論どおり、そこは正直に線引きすべきポイントです。両者の違いを表で整理します。
| 観点 | Solid Queue | Sidekiq（＋Redis） |
|---|---|---|
| バックエンド | データベース（追加ミドルウェア不要） | Redisが必須 |
| 運用対象 | DBだけ（構成がシンプル） | Redisの監視・バックアップも必要 |
| 管理画面 | mission_control-jobs（別gem） | 標準の管理UIが充実 |
| 処理スループット | 中〜大規模でも実用十分 | 大量・高頻度ジョブに実績豊富 |
| エコシステム | まだ発展途上 | プラグイン・情報が非常に豊富 |
| 始めやすさ | Pumaインプロセスで即スタート | Redis＋ワーカー構築が必要 |
ざっくり言えば、Solid Queueは「構成のシンプルさ」で勝ち、Sidekiqは「機能の厚みと実績」で勝つという関係です。どちらが上というより、アプリの規模と運用体制で答えが変わります。
結局どっちを選ぶ？ケース別の推奨
判断に迷ったときのために、ケース別の推奨をまとめておきます。
- 新規のRails 8アプリ：迷わずSolidトリオ。Redisを立てない構成でスモールに始められます。個人開発やVPS1台運用と相性抜群です。
- 既存のSidekiqアプリで、運用がうまく回っている：無理に移行しない。Redis1台の運用コストと、移行の手間・機能差を天秤にかけて、ペインが小さいなら現状維持でOKです。
- 既存アプリだが、Redisの運用（監視・コスト・バックアップ）が地味に重い：Solid Queueへの移行を検討する価値あり。まずはCache/Cableだけ寄せる、といった段階的な移行が現実的です。
- 超大量・高頻度のジョブをさばいている：Sidekiq（Pro/Enterprise含む）の実績とエコシステムが効くので、当面は据え置きが無難です。
大事なのは「Rails 8に上げたら全部Solidに置き換えなきゃ」と気負わないことです。Solidトリオは使える選択肢が増えただけで、Redisを消すこと自体が目的ではありません。自分のアプリにとっての運用のラクさで選べば大丈夫です。
まとめ：Redisを「必須」から「選択」に変える
最後に要点を振り返ります。
- Solidトリオ（Queue / Cache / Cable）は、背景ジョブ・キャッシュ・WebSocketをデータベースだけで動かすRails 8標準の仕組み
- Solid Queueは
FOR UPDATE SKIP LOCKEDでロック競合を回避し、Pumaインプロセスならプロセス1つで背景ジョブまで回せる - Solid CacheはSSD前提のDBキャッシュ。失効がFIFOな点だけ注意
- 既存のSidekiqアプリは急いで剥がさない。運用の重さと機能差を見て、段階的に判断すればよい
Rails 8のSolidトリオは、これまで「本番なら当然入れるもの」だったRedisを、「必要なら入れる選択肢」へと立ち位置を変えました。特に個人開発や小規模サービスでは、この構成のシンプルさが効いてきます。本番の database.yml でqueue/cache/cableのデータベースをどう書き分けるかは solid_gemsを使った時のdatabase.ymlの書き方 に実例があるので、実際に設定する段になったら覗いてみてください。
あわせて、Redisを外したシンプルな構成はデプロイとも好相性です。Rails 8標準のKamal 2でAWSに載せる手順は [kamal 2]AWSへのデプロイ方法 に、Railsの前段にNginxが要るのか問題は Railsの前段にNginxは必要なのか にまとめています。環境構築からやり直したい方は macOSにRuby on Railsをインストールする方法 からどうぞ。
スポンサーリンク
