Rails Solid Cache の使い方｜セットアップから本番運用・Redis/Memcachedからの移行

Rails 8 で デフォルトのキャッシュストア となった solid_cache は、データベース駆動のキャッシュ実装です。Redis / Memcached の代わりにDBとSSDを使うことで、大容量キャッシュをシンプルなインフラで実現します。

# Rails 8 デフォルト設定
config.cache_store = :solid_cache_store

しかし、Redis / Memcached 時代の知識のままだと:

• どう設定すればいい？config/cache.yml の書き方は？
• 既存のキャッシュ用途（フラグメント・ロウレベル）はどう移行？
• DB容量がどんどん増えていく心配は？
• FIFO eviction って何？LRUと違う？
• 既存のRedisキャッシュからどう移行する？
• 本当に Redis より遅くないの？
• どこまで Solid Cache に任せて、どこを Redis 継続にすべき？

など、判断ポイントが多くあります。

本記事では、Solid Cache のすべての使い方を、セットアップから本番運用、Redis/Memcachedからの移行まで実用視点で網羅します。config/cache.yml設定、Rails.cache.fetchの使い方、フラグメントキャッシュ、シャーディング、サイズ管理、Redis比較、移行手順、パフォーマンスチューニング、FAQまで完全網羅。この1本で Solid Cache を実戦投入できるようになります。

結論：今すぐ使える3ステップ

時間がない方向けに、最短のセットアップ手順を示します。

ステップ1：インストール

# Rails 8 では既に含まれている。既存アプリへの追加なら:
bundle add solid_cache
bin/rails solid_cache:install
bin/rails db:migrate

ステップ2：キャッシュストア設定

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

ステップ3：使う

# 値の取得・設定（通常のRails.cacheと同じ）
Rails.cache.fetch("user/#{user.id}", expires_in: 1.hour) do
  user.expensive_calculation
end

これだけで Redis 不要のキャッシュが使えます。詳細は以下で解説します。

まず押さえる：Solid Cache とは

概要

Solid Cache は Basecamp が開発し、Rails 8 から標準採用されたデータベース駆動のキャッシュストアです。

設計思想：「ディスク（SSD）はもう十分速い」

従来のキャッシュはメモリベース（RAM）が常識でしたが、Solid Cache は**「現代のSSDなら、容量と速度のバランスでディスクの方が有利」**という考え方に基づきます。

• 10GB のRAMキャッシュ = 高コスト
• 10GB のSSDキャッシュ = 低コスト・大容量化が容易

Basecamp の事例: Solid Cache で 10TB のキャッシュデータを60日保持しているとのこと。Redis では非現実的なスケールです。

Redis / Memcached との性能比較

公式情報による HEY での実測:

• Redis vs Solid Cache: 単一キーread/writeで 25〜50% 遅い（0.8〜1ms vs 1.2ms）
• ただしリクエスト全体での影響は微小
• キャッシュミスのコストが高いアプリでは、長期保持できるSolid Cacheが実質有利

Solid Trifecta の中での位置づけ

Rails 8 の「Solid Trifecta」3兄弟:

Solid Cache はRails 8のアップグレード戦略の中核を成すコンポーネントです。

インストールとセットアップ

Rails 8 新規プロジェクト

rails new myapp
# Solid Cache は既に設定済み
bin/rails db:prepare

config/cache.yml、db/cache_schema.rb などが自動生成されます。

Rails 7.1+ への追加

# Gemfile に追加
bundle add solid_cache

# セットアップコマンド実行
bin/rails solid_cache:install

生成されるもの:

• config/cache.yml – Solid Cache 設定
• db/cache_schema.rb – キャッシュテーブルのスキーマ（Rails 7.2+）
• db/migrate/xxx_install_solid_cache.rb – マイグレーション
• config/environments/production.rb の cache_store 設定変更

bin/rails db:migrate
# または
bin/rails db:prepare

Rails 8 で確認

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

開発環境でも有効化したい場合:

# config/environments/development.rb
config.cache_store = :solid_cache_store
config.solid_cache.connects_to = { database: { writing: :cache } }

データベース設定：単一DB vs マルチDB

パターン1：単一DB（簡易構成）

メインアプリのDB内にキャッシュテーブルを作成:

# config/database.yml
production:
  <<: *default
  database: myapp_production

# config/cache.yml（databaseを指定しない）
default: &default
  store_options:
    max_age: <%= 60.days.to_i %>
    namespace: <%= Rails.env %>
    size_estimate_samples: 1000

production:
  <<: *default
  store_options:
    <<: *default_store_options
    max_size: <%= 256.gigabytes %>

シンプルですが、キャッシュ書き込みがメインアプリのトランザクションに影響する可能性。

パターン2：マルチDB（推奨）

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache:
    <<: *default
    database: myapp_production_cache
    migrations_paths: db/cache_migrate

# config/environments/production.rb
config.cache_store = :solid_cache_store
config.solid_cache.connects_to = { database: { writing: :cache } }

# config/cache.yml
production:
  database: cache
  store_options:
    max_age: <%= 60.days.to_i %>
    max_size: <%= 256.gigabytes %>

メインDBと完全分離されたDBでキャッシュが管理されます。

パターン3：複数シャード（大規模向け）

書き込み負荷を分散したい場合:

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache_shard1:
    <<: *default
    database: myapp_production_cache_1
  cache_shard2:
    <<: *default
    database: myapp_production_cache_2

# config/cache.yml
production:
  databases: [cache_shard1, cache_shard2]
  store_options:
    max_size: <%= 256.gigabytes %>

Solid Cache が自動でキーをハッシュ分散します。

Solid Trifecta 全部入り構成

production:
  primary:
    database: myapp_production
  cache:
    database: myapp_production_cache
    migrations_paths: db/cache_migrate
  queue:
    database: myapp_production_queue
    migrations_paths: db/queue_migrate
  cable:
    database: myapp_production_cable
    migrations_paths: db/cable_migrate

Rails 8 の新規アプリでは自動的にこの構成。

config/cache.yml の書き方

Solid Cache の挙動を制御する設定ファイルです。

基本構造

default: &default
  store_options: &default_store_options
    max_age: <%= 60.days.to_i %>
    namespace: <%= Rails.env %>
    size_estimate_samples: 1000

development:
  <<: *default
  database: cache
  store_options:
    <<: *default_store_options
    max_size: <%= 256.megabytes %>

production:
  <<: *default
  databases: [cache_primary, cache_shard_two]
  store_options:
    <<: *default_store_options
    max_size: <%= 256.gigabytes %>

主要パラメータ

max_age

キャッシュの最大保持期間。これを過ぎたエントリは削除対象に。

store_options:
  max_age: <%= 30.days.to_i %>

max_size（容量制限）

キャッシュの合計サイズ上限（バイト）:

store_options:
  max_size: <%= 256.gigabytes %>

これを超えると古いエントリから削除（FIFO）。

max_entries（件数制限）

件数で制限する場合（max_sizeと排他）:

store_options:
  max_entries: 1_000_000

max_size と max_entries どちらか一方を指定。両方指定すると max_size が優先。

namespace

キーの前置接頭辞。複数環境を同じDBで使う場合に便利:

store_options:
  namespace: <%= Rails.env %>   # "production", "staging" などで分離

# Rails.cache.write("key", "value")
# → DB上は "production:key" として保存

size_estimate_samples

キャッシュサイズ推定のサンプル数。多いほど正確、少ないほど高速:

store_options:
  size_estimate_samples: 1000

暗号化

store_options:
  encrypt: true

保存される値が自動で暗号化されます（Rails のActive Record Encryption 機能利用）。

キャッシュの基本的な使い方

Rails.cache の API は標準的なものがすべて使えます。

Rails.cache.write / read / delete

# 値の設定（永続）
Rails.cache.write("greeting", "Hello, World!")

# 値の取得
Rails.cache.read("greeting")
# => "Hello, World!"

# 削除
Rails.cache.delete("greeting")

# 存在確認
Rails.cache.exist?("greeting")

期限付きキャッシュ（expires_in）

Rails.cache.write("token", "abc123", expires_in: 1.hour)
Rails.cache.write("api_data", response, expires_in: 5.minutes)

# 絶対時刻指定
Rails.cache.write("daily_stats", stats, expires_at: Date.tomorrow.beginning_of_day)

fetch（読み取り or 計算）

最頻出パターン。キャッシュにあれば返す、なければブロック実行して結果をキャッシュ:

# 単純なケース
result = Rails.cache.fetch("user_count") do
  User.count
end

# 期限付き
result = Rails.cache.fetch("expensive_data", expires_in: 1.hour) do
  ExpensiveCalculation.compute
end

# 強制再計算
Rails.cache.fetch("data", force: true) do
  fresh_data
end

# キャッシュバージョン管理
Rails.cache.fetch("user_#{user.id}", version: user.updated_at.to_i) do
  user.expensive_calculation
end

複数キーの一括操作

# 一括取得
keys = ["user/1", "user/2", "user/3"]
results = Rails.cache.read_multi(*keys)
# => {"user/1" => obj1, "user/2" => obj2, "user/3" => nil}

# 一括書き込み
Rails.cache.write_multi(
  "user/1" => user1,
  "user/2" => user2
)

# 一括 fetch（未存在のみブロック実行）
results = Rails.cache.fetch_multi("user/1", "user/2") do |key|
  User.find(key.split("/").last)
end

全削除（要注意）

Rails.cache.clear   # 全キャッシュ削除！

⚠️ 本番環境では実行前にしっかり影響を確認。Solid Cache は DELETE クエリで全レコード削除するため、巨大なキャッシュでは時間がかかります。

ロウレベル（低レベル）キャッシュ

特定の重い計算結果や外部API応答などをキャッシュする典型パターン:

Model内でのキャッシュ

class Product < ApplicationRecord
  def expensive_total
    Rails.cache.fetch([self, "expensive_total"], expires_in: 1.hour) do
      compute_expensive_total
    end
  end
end

[self, "expensive_total"] の形式で、自動的に cache_key_with_version が呼ばれ、レコードのupdated_atを含むキーが生成されます。

Versioned Cache

# レコードが更新されたら自動的にキャッシュキーが変わる
Rails.cache.fetch(product) do
  expensive_data
end
# キー: "products/123-20260620100000123456"

永続キャッシュ vs ETag的活用

def cached_data
  Rails.cache.fetch("data/v2", expires_in: 1.week) do
    fetch_from_external_api
  end
end

# データ構造変更時はキーをバンプ
# "data/v2" → "data/v3" で旧キャッシュを無効化

フラグメントキャッシュ

ビューの一部をキャッシュする機能:

<%# views/products/show.html.erb %>
<% cache product do %>
  <h1><%= product.name %></h1>
  <p><%= product.description %></p>
  <%= render product.reviews %>
<% end %>

cache product のように指定すると、product の cache_key_with_version がキーになります。

ネストしたフラグメントキャッシュ

<% cache @article do %>
  <h1><%= @article.title %></h1>
  
  <% @article.comments.each do |comment| %>
    <% cache comment do %>
      <%= render comment %>
    <% end %>
  <% end %>
<% end %>

「Russian Doll Caching」と呼ばれるパターン。コメントが更新されたら、その親の記事キャッシュも自動で無効化されます。

コレクションキャッシュ

<%= render partial: "product", collection: @products, cached: true %>

各 product 用のフラグメントを個別にキャッシュ。

バージョン管理オプション

<% cache [@product, "v2"] do %>
  ...
<% end %>

テンプレート変更時にキーをバンプして旧キャッシュ無効化。

FIFO eviction 戦略

Solid Cache は **FIFO（First In, First Out）**を採用しています。

LRU との違い

なぜ FIFO で十分か

Solid Cache の設計思想:

1. キャッシュ容量を大きくできるため、頻繁にアクセスされるデータも自然と残る
2. FIFOは管理コストが低いため、書き込みパフォーマンスが安定
3. 大容量キャッシュ + 長期保持で、LRUの理論的優位性が薄れる

注意点

「最近アクセスしたから残る」が保証されないため、以下の用途では工夫が必要:

• 重要だが頻度の低いキャッシュ → 明示的に expires_in 長め、定期的に touch
• ホットデータの保持 → max_size を十分大きく取る

キャッシュサイズ管理の運用

DB に保存されるため、容量管理は重要です。

現在のキャッシュサイズ確認

-- キャッシュエントリの統計
SELECT 
    COUNT(*) AS entry_count,
    pg_size_pretty(SUM(LENGTH(value))) AS total_size,
    AVG(LENGTH(value)) AS avg_size,
    MIN(created_at) AS oldest,
    MAX(created_at) AS newest
FROM solid_cache_entries;

キャッシュ削除のスケジュール

max_size に達すると自動削除されますが、計画的な手動削除も有効:

# 古いエントリを削除
SolidCache::Entry.where("created_at < ?", 30.days.ago).delete_all

# namespace 単位の削除
SolidCache::Entry.where("key LIKE ?", "staging:%").delete_all

キャッシュサイズの監視

# config/initializers/solid_cache_monitoring.rb
ActiveSupport::Notifications.subscribe("cache_full.solid_cache") do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  Rails.logger.warn "Solid Cache full: #{event.payload}"
end

バックアップ戦略

キャッシュデータをバックアップに含めるかは要検討:

# キャッシュDB を除外してメインDBのみバックアップ
pg_dump myapp_production > backup.sql
# キャッシュDBは別に管理（または含めない）

⚠️ Solid Cache データはアプリ再起動で空になることを想定し、本番運用ではバックアップ不要というのがBasecampの推奨です。

キャッシュ暗号化

機密データをキャッシュする場合、暗号化を有効化:

設定

# config/cache.yml
production:
  store_options:
    encrypt: true

Active Record Encryption の設定

事前に Rails の Encryption キーが必要:

bin/rails db:encryption:init

生成されたキーを config/credentials.yml.enc に保存。

active_record_encryption:
  primary_key: xxx
  deterministic_key: yyy
  key_derivation_salt: zzz

暗号化の影響

• 書き込みコスト: 微増（CPU負荷）
• 読み込みコスト: 微増
• 検索不可: 暗号化された値で検索はできない（FIFO eviction には影響なし）

セキュリティ要件と性能のトレードオフで判断。

Redis / Memcached からの移行

既存のRedis/Memcachedキャッシュから Solid Cache への移行手順です。

ステップ1：並行運用準備

# Gemfile
gem "redis-rails"   # 残す
gem "solid_cache"   # 追加

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

ステップ2：段階的切り替え

Option A：環境別で先に切り替え

# config/environments/staging.rb
config.cache_store = :solid_cache_store
config.solid_cache.connects_to = { database: { writing: :cache } }

# config/environments/production.rb
# まだ Redis 継続
config.cache_store = :redis_cache_store, { url: ENV["REDIS_URL"] }

ステージングで十分検証してから本番へ。

Option B：本番でも段階的に

特定キャッシュだけ Solid Cache に向ける場合、明示的にストアを切り替え:

class MyService
  def cached_result
    solid_cache = ActiveSupport::Cache::SolidCacheStore.new
    solid_cache.fetch("key") { expensive_calc }
  end
end

ステップ3：完全切り替え

# config/environments/production.rb
config.cache_store = :solid_cache_store
config.solid_cache.connects_to = { database: { writing: :cache } }

ステップ4：Redis 削除

# Gemfile
# gem "redis-rails"   # 削除

Redis を完全に削除しても、Action Cable や Sidekiq でまだ使う場合は残す。

Redis 固有機能の移行

Memcached から移行する場合

Memcached は機能がシンプルなため、移行はより容易:

# 旧設定
config.cache_store = :mem_cache_store, "cache.example.com"

# 新設定
config.cache_store = :solid_cache_store

API はほぼ互換。

Redis を併用するパターン

「キャッシュは Solid Cache、Action Cable やセッションは Redis 継続」という運用も自然:

# キャッシュは Solid Cache
config.cache_store = :solid_cache_store

# セッションは Redis
config.session_store :redis_store,
  servers: ["redis://localhost:6379/0/session"]

# Sidekiq は Redis
# config/sidekiq.rb で設定

完全な Redis 脱却が必須でない場合、このハイブリッド構成が現実的です。

本番運用のベストプラクティス

1. マルチDB構成を採用

メインDBとキャッシュDBを分離し、お互いに影響を与えない構成に。

2. SSD（NVMe推奨）の利用

Solid Cache は SSDのI/O性能を前提とした設計。HDDでは本来のパフォーマンスが出ません。

3. max_size を適切に設定

サーバーのディスク容量、データ規模、必要な保持期間を見ながら決定。256GB〜数TBのスケールを想定。

4. namespace で環境分離

store_options:
  namespace: <%= Rails.env %>

production / staging / test を同じDBで運用する場合に必須。

5. 監視

# AppSignal、Datadog、New Relic 等で監視
ActiveSupport::Notifications.subscribe(/solid_cache/) do |*args|
  # メトリクス送信
end

6. キャッシュウォーミング

デプロイ後の初期空状態を回避するため、重要キャッシュを事前に温める:

# lib/tasks/cache.rake
namespace :cache do
  desc "Warm critical caches"
  task warm: :environment do
    Product.featured.find_each do |product|
      Rails.cache.fetch("products/#{product.id}") do
        product.to_cache_hash
      end
    end
  end
end

# デプロイ時に実行
bin/rails cache:warm

7. Thundering herd 対策

キャッシュが切れた瞬間に大量リクエストが同一キーを生成しようとする問題:

# race_condition_ttl で対策
Rails.cache.fetch("key", expires_in: 1.hour, race_condition_ttl: 10.seconds) do
  expensive_calc
end

race_condition_ttl で猶予を持たせる。

8. データベース接続プール調整

# config/database.yml
production:
  cache:
    pool: <%= ENV.fetch("CACHE_POOL_SIZE") { 20 } %>

Web ワーカーのスレッド数 × プロセス数より多めに。

9. インデックス確認

Solid Cache が作成する標準インデックスで通常は十分。カスタマイズしない方が無難。

10. 監視メトリクス

パフォーマンス・チューニング

キャッシュサイズ最適化

# 平均サイズが大きすぎないか
SolidCache::Entry.average("LENGTH(value)")

# サイズ別分布
SolidCache::Entry
  .group("CASE WHEN LENGTH(value) < 1000 THEN 'small' WHEN LENGTH(value) < 10000 THEN 'medium' ELSE 'large' END")
  .count

圧縮の活用

大きな値をキャッシュする場合、自動圧縮で容量削減:

# デフォルトで有効（>= 1KB は自動圧縮）
Rails.cache.fetch("large_data", compress: true) do
  large_object
end

# 閾値カスタマイズ
Rails.cache.fetch("data", compress: true, compress_threshold: 500) do
  data
end

ヒット率モニタリング

# config/initializers/cache_metrics.rb
ActiveSupport::Notifications.subscribe("cache_read.active_support") do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  if event.payload[:hit]
    # キャッシュヒット
  else
    # キャッシュミス
  end
end

トラブルシューティング

キャッシュが効かない

確認順序:

1. cache_store 設定

Rails.application.config.cache_store
# => :solid_cache_store になっているか

2. マイグレーション完了

bin/rails db:migrate:status

3. テーブル存在確認

SELECT COUNT(*) FROM solid_cache_entries;

4. キャッシュ無効化されていないか

Rails.cache.class
# => SolidCache::Store

開発環境では bin/rails dev:cache で有効化トグル:

bin/rails dev:cache
# Development mode is now being cached.

マイグレーション エラー

ActiveRecord::PendingMigrationError

bin/rails db:migrate
# または明示的にキャッシュDB
bin/rails db:migrate:cache

キャッシュサイズが想定外に大きい

# 状況確認
SolidCache::Entry.count
SolidCache::Entry.sum("LENGTH(value)")

# 大量の小さいキャッシュ → max_entries で件数制限検討
# 巨大な値が混入 → 何が大きいか調査
SolidCache::Entry.order(Arel.sql("LENGTH(value) DESC")).limit(20).pluck(:key, Arel.sql("LENGTH(value)"))

Read/Write が遅い

-- スロークエリで Solid Cache 操作を確認
EXPLAIN ANALYZE SELECT value FROM solid_cache_entries WHERE key = 'key' LIMIT 1;

通常の主キー検索なら極めて高速のはず。遅い場合は:

• DB接続の問題
• ディスクI/O問題（HDDを使っていないか）
• ロック競合（マルチDB分離を検討）

詳しくはMySQL Got error 28 from storage engineの記事等も参照（容量問題の場合）。

Docker環境でディスク不足

Docker環境ではDocker no space left on device の記事を参照。Solid Cache が DB容量を圧迫している可能性。

namespace 設定漏れで他環境のキャッシュが混在

# 確認
Rails.cache.options[:namespace]

# 設定漏れなら config/cache.yml を更新して再起動

よくある質問（FAQ）

Q1. Solid Cache は Rails 7 でも使えますか？

Rails 7.1 以上 で利用可能。Gemfile に gem "solid_cache" を追加すればOK。Rails 8 ではデフォルト。

Q2. 本当に Redis より速くないですか？

単一操作では 25〜50% 遅い（公式実測）ですが、リクエスト全体の応答時間からすると無視できる差です。大容量キャッシュ・長期保持ができる利点で、結果的にヒット率が上がるためトータルで有利な場合も多いです。

Q3. Sidekiq の Redis は残しても Solid Cache は使えますか？

完全に問題ありません。Solid Cache はキャッシュ専用で、Sidekiq の Redis とは別物。両者は共存可能です。

Q4. キャッシュ専用DBは必須ですか？

強く推奨ですが必須ではありません。小規模アプリならメインDBに同居でも動きます。中規模以上ではDB分離を推奨。

Q5. SQLite で本番運用できますか？

可能です。Rails 8 の SQLite は WAL モードで並行性が改善されているため、小〜中規模なら問題なし。ただし書き込み頻度が極めて高いケースでは PostgreSQL / MySQL を推奨。

Q6. Memcached の方が向いている場合は？

• 超高頻度書き込み（毎秒数万操作）
• マルチサーバーで完全分散
• 既存システムがMemcached前提で設計

これらの場合、Memcached 継続も選択肢。

Q7. eviction（自動削除）はいつ実行されますか？

max_size/max_entries 閾値を超えた時、書き込み操作の延長でバッチ削除されます。常駐プロセスは不要。

Q8. キャッシュキーに使える型は？

# 文字列
Rails.cache.write("string_key", value)

# 配列（自動的にハッシュ化）
Rails.cache.write([user, "profile"], value)

# ActiveRecord オブジェクト（cache_key_with_version 利用）
Rails.cache.write(product, value)

# ハッシュも可能（JSON化される）
Rails.cache.write({type: "user", id: 1}, value)

Q9. 開発環境でキャッシュを使うべき？

通常は無効ですが、テストしたい時:

bin/rails dev:cache   # トグル切り替え

または config/environments/development.rb で明示有効化。

Q10. プロセス間でキャッシュは共有されますか？

はい。DBに保存されるため、Webサーバー・ワーカー・ジョブプロセス間で共有されます。Memcachedのような独立サーバー型と同じ感覚で使えます。

Q11. キャッシュの暗号化は必須ですか？

機密データを含む場合のみ推奨。通常のキャッシュデータ（公開可能なクエリ結果等）には不要。暗号化は若干のCPUコストがかかります。

Q12. Redis を完全に削除したいです

Solid Trifecta（Cache + Queue + Cable）すべてを導入すれば、Redisが不要になります:

• キャッシュ → Solid Cache
• ジョブ → Solid Queue
• WebSocket → Solid Cable
• セッション → Cookie 化または ActiveRecord Session Store

ただし「Redis 完全脱却」が目的化しないよう、運用上のメリットで判断してください。

参考リンク・関連資料

公式ドキュメント

• Solid Cache 公式リポジトリ – GitHub
• Caching with Rails（公式Guide） – Active Support Cache全般
• Active Record Encryption（公式Guide） – 暗号化機能

関連プロジェクト

• Solid Queue – ジョブキュー
• Solid Cable – WebSocket
• Mission Control – ジョブ管理UI

関連記事（本サイト）

• Rails 8 アップグレードガイド – Rails 8 移行全般
• Solid Queue 使い方 – Solid Trifecta シリーズ
• crontab 書き方 例 – キャッシュウォーミングタスクの定期実行
• MySQL 1045 access denied – DB接続トラブル
• MySQL Got error 28 from storage engine – DB容量問題
• Docker no space left on device – Docker環境のトラブル
• linux find オプション一覧 – ログ・データ調査

まとめ

Solid Cache はRails 8 のキャッシュアーキテクチャを刷新する重要な機能です。要点を再整理します。

• 設計思想: SSD時代のDB駆動キャッシュ。容量・コスト・運用のバランスが優秀
• シンプル設定: bin/rails solid_cache:install で即使える
• マルチDB推奨: メインDBから分離して影響を排除
• 設定の中心: config/cache.yml で max_size / max_entries / max_age / namespace を制御
• FIFO eviction: LRUと違うが、大容量キャッシュで実用上問題なし
• 暗号化対応: encrypt: true で簡単に有効化
• シャーディング: 複数DB分散で大規模対応
• Redis比較: 単一操作は若干遅いが、容量・コスト・運用性で優位
• 移行: 段階的に切り替え可能（並行運用もOK）
• 適性: 中小〜大規模アプリで威力発揮、超高頻度ならMemcached併用も

これらの知識は、Rails 8 アプリのパフォーマンス設計・本番運用・Redis脱却プロジェクトなどあらゆる場面で活用できます。本記事をブックマークしておけば、Solid Cache を実戦投入できるようになります。

本記事は2026年6月時点の情報をもとに、Ruby on Rails 8.0.5 / 8.1.3 / 8.2.x、Solid Cache 最新版での動作確認・公式ドキュメントに基づき作成しています。Solid Cache は活発に開発されており、設定方法が更新される可能性があるため、最新の情報は公式リポジトリもあわせてご確認ください。