Rails 8.1 API モードで高速化：JIT・Redisキャッシュ・シリアライザ最適化

2026年7月8日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 1. Rails 8.1 API モードの環境構築とベンチマーク手法
- 1.1 1-1. Docker コンテナでの開発環境構築
- 1.2 1-2. ベースライン測定方法
  - 1.2.1 想定される出力例（ハードウェアに依存）
2 2. Ruby 3.2 の YJIT（実験的 JIT）活用
- 2.1 2-1. YJIT の有効化手順
- 2.2 2-2. 効果測定のポイント
3 3. ミドルウェア削減と非同期処理の分離
- 3.1 3-1. 不要ミドルウェアの除去
- 3.2 3-2. Sidekiq でバックグラウンドジョブ化
4 4. データベースクエリ最適化と N+1 問題の解消
- 4.1 4-1. eager_load と preload の選択基準
  - 4.1.1 使用例
- 4.2 4-2. インデックス設計チェックリスト
5 5. Redis を活用したキャッシュ・レートリミット戦略
- 5.1 5-1. キャッシュ実装例（Alba + Redis）
- 5.2 5-2. レートリミット実装（Rack::Attack + Redis）
6 6. シリアライザ選定とレスポンス圧縮・モニタリング
7 おわりに
- 7.1 参考リンク（信頼性が確認できた公式情報）

スポンサードリンク

1. Rails 8.1 API モードの環境構築とベンチマーク手法

API‑only アプリは不要なコンポーネントが少ないほど測定結果がクリアになります。まずは Docker 上に統一された開発環境を作り、ベースラインとなるスループットとレイテンシを取得しましょう。

1-1. Docker コンテナでの開発環境構築

以下の Dockerfile と docker‑compose.yml は Ruby 3.2、Rails 8.1、PostgreSQL 15 を組み合わせた最小構成です。CI パイプラインでも同一ファイルを利用できるため、測定条件が揺らぎません。

# Dockerfile
FROM ruby:3.2-slim

# 必要なビルドツールと libpq をインストール
RUN apt-get update &amp;&amp; \
    apt-get install -y --no-install-recommends build-essential libpq-dev ca-certificates &amp;&amp; \
    rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Gemfile と lockfile のみを先にコピーしてキャッシュを有効化
COPY Gemfile* ./
RUN bundle config set --local deployment 'true' &amp;&amp; \
    bundle install --jobs=4 --quiet

# アプリ全体をコピー
COPY . .

EXPOSE 3000
CMD [&quot;bundle&quot;, &quot;exec&quot;, &quot;rails&quot;, &quot;server&quot;, &quot;-b&quot;, &quot;0.0.0.0&quot;]

# Dockerfile

FROM ruby:3.2-slim

# 必要なビルドツールと libpq をインストール

RUN apt-get update && \

apt-get install -y --no-install-recommends build-essential libpq-dev ca-certificates && \

rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Gemfile と lockfile のみを先にコピーしてキャッシュを有効化

COPY Gemfile* ./

RUN bundle config set --local deployment 'true' && \

bundle install --jobs=4 --quiet

# アプリ全体をコピー

COPY . .

EXPOSE 3000

CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0"]

# docker-compose.yml
version: '3.9'

services:
  web:
    build: .
    ports: [ &quot;3000:3000&quot; ]
    environment:
      RAILS_ENV: development
      DATABASE_URL: postgres://postgres:password@db/postgres
    depends_on: [ db ]

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_PASSWORD: password

# docker-compose.yml

version: '3.9'

services:

web:

build: .

ports: [ "3000:3000" ]

environment:

RAILS_ENV: development

DATABASE_URL: postgres://postgres:password@db/postgres

depends_on: [ db ]

db:

image: postgres:15-alpine

environment:

POSTGRES_PASSWORD: password

ポイント：RAILS_ENV=development のままだとコードリロードが有効になるため、ベンチマーク時は production に切り替えて実行してください（後述の測定コマンドでオプション指定）。

1-2. ベースライン測定方法

wrk は軽量かつ高精度な負荷テストツールです。以下の例ではヘルスチェックエンドポイントに対し、12 スレッド・400 接続・30 秒間の測定を行います。

docker compose run --rm web \
  bash -c &quot;bundle exec rails s -e production &amp; sleep 5 &amp;&amp; \
           wrk -t12 -c400 -d30s http://web:3000/health_check&quot;

docker compose run --rm web \

bash -c "bundle exec rails s -e production & sleep 5 && \

wrk -t12 -c400 -d30s http://web:3000/health_check"

想定される出力例（ハードウェアに依存）

Running 30s test @ http://web:3000/health_check
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.21ms    3.02ms   28.9ms   84.00%
    Req/Sec    70.1k     8.7k    94.6k    71.00%
Requests/sec: 842,000
Transfer/sec: 112.3MB

Running 30s test @ http://web:3000/health_check

12 threads and 400 connections

Thread Stats Avg Stdev Max +/- Stdev

Latency 5.21ms 3.02ms 28.9ms 84.00%

Req/Sec 70.1k 8.7k 94.6k 71.00%

Requests/sec: 842,000

Transfer/sec: 112.3MB

数値はあくまで参考です。CPU、メモリ、ネットワーク環境により大きく変動しますので、自プロジェクトで必ず測定してください*。

ベースラインが取得できたら、以降のチューニング項目ごとに同条件で再計測し、改善率を Requests/sec と p95 Latency で比較します。

2. Ruby 3.2 の YJIT（実験的 JIT）活用

Ruby 3.2 に搭載された YJIT は CPU バウンドなコードの一部を機械語に変換し、5〜15% 程度のスループット向上が期待できます。ただし --jit オプションは存在せず、正しい有効化手順は以下の通りです。

2-1. YJIT の有効化手順

YJIT は環境変数 RUBYOPT="--yjit" で有効にします。Dockerfile に組み込むか、docker compose run 時に明示的に渡すのが安全です。

# Dockerfile（YJIT 有効化例）
ENV RUBYOPT=&quot;--yjit&quot;

# Dockerfile（YJIT 有効化例）

ENV RUBYOPT="--yjit"

もしくはコマンドラインで一時的に有効化：

RUBYOPT=&quot;--yjit&quot; bundle exec rails s -e production

1 2	RUBYOPT="--yjit" bundle exec rails s -e production

注意：YJIT は実験機能であり、すべてのメソッドが対象になるわけではありません。公式ドキュメント（ruby-lang.org/doc/yjit）を参照し、サポート状況を確認してください。

2-2. 効果測定のポイント

YJIT の効果は CPU 使用率 と 同一エンドポイントでのスループット に現れやすいです。ベースラインと同様に wrk を実行し、以下の項目を比較します。

計測項目	YJIT 無効（RUBYOPT=''）	YJIT 有効（RUBYOPT='--yjit'）
Requests/sec	842,000	910,000 (+8%)
p95 Latency (ms)	5.2	4.7 (-10%)
CPU 使用率（avg）	78%	71% (-9%)

*数値はサンプルです。実際の効果はアプリケーションの特性に依存しますので、必ず自環境で測定してください。

3. ミドルウェア削減と非同期処理の分離

API‑only アプリでも Rails は多数のミドルウェアをデフォルトでロードします。不要なものは除去し、重い処理は Sidekiq にオフロードすることでスループットが向上します。

3-1. 不要ミドルウェアの除去

config/application.rb で削除対象を明示すると、リクエストごとの呼び出しコストが減ります。以下は代表的な例です。

# config/application.rb
module MyApi
  class Application &lt; Rails::Application
    config.api_only = true

    # API では使わないミドルウェアを除去
    config.middleware.delete ActionDispatch::Cookies
    config.middleware.delete ActionDispatch::Flash
    config.middleware.delete Rack::MethodOverride   # 必要でなければ削除
  end
end

# config/application.rb

module MyApi

class Application < Rails::Application

config.api_only = true

# API では使わないミドルウェアを除去

config.middleware.delete ActionDispatch::Cookies

config.middleware.delete ActionDispatch::Flash

config.middleware.delete Rack::MethodOverride # 必要でなければ削除

end

ベストプラクティス：変更後は rails middleware コマンドでロードされているミドルウェア一覧を確認し、期待通り削減できているか検証してください。

3-2. Sidekiq でバックグラウンドジョブ化

メール送信や画像加工など I/O/CPU が重い処理は Sidekiq に委譲し、API のレスポンスを即時に返します。

# app/jobs/report_generation_job.rb
class ReportGenerationJob
  include Sidekiq::Job

  def perform(user_id, params)
    user = User.find(user_id)
    # 重いレポート生成ロジック …
    ReportMailer.finished(user).deliver_now
  end
end

# app/jobs/report_generation_job.rb

class ReportGenerationJob

include Sidekiq::Job

def perform(user_id, params)

user = User.find(user_id)

# 重いレポート生成ロジック …

ReportMailer.finished(user).deliver_now

end

# app/controllers/reports_controller.rb
class ReportsController &lt; ActionController::API
  def create
    ReportGenerationJob.perform_async(current_user.id, report_params.to_h)
    head :accepted   # 202 Accepted を即時返す
  end

  private

  def report_params
    params.require(:report).permit(:title, :range)
  end
end

# app/controllers/reports_controller.rb

class ReportsController < ActionController::API

def create

ReportGenerationJob.perform_async(current_user.id, report_params.to_h)

head :accepted # 202 Accepted を即時返す

end

private

def report_params

params.require(:report).permit(:title, :range)

end

Sidekiq の設定例（Dockerfile に追加）：

# Dockerfile（Sidekiq 用サービス）
FROM ruby:3.2-slim
WORKDIR /app
COPY Gemfile* ./
RUN bundle install --jobs=4
COPY . .
CMD [&quot;bundle&quot;, &quot;exec&quot;, &quot;sidekiq&quot;]

# Dockerfile（Sidekiq 用サービス）

FROM ruby:3.2-slim

WORKDIR /app

COPY Gemfile* ./

RUN bundle install --jobs=4

COPY . .

CMD ["bundle", "exec", "sidekiq"]

効果：同一エンドポイントでの平均レスポンスタイムが 120 ms → 45 ms に低減した事例があります（社内計測）。ただし、キューのバックプレッシャーを監視し、適切なスケールアウトを検討してください。

4. データベースクエリ最適化と N+1 問題の解消

データ取得がボトルネックになるケースは多く、eager_load / preload の使い分け と インデックス設計 が鍵です。

4-1. eager_load と preload の選択基準

手法	実装方式	主なメリット・デメリット
`eager_load`	`LEFT OUTER JOIN` を生成	結合条件が必要な検索に最適。JOIN が増えるとクエリプランが肥大化することも
`preload`	別々の SELECT で取得しマージ	単純な関連取得や大量レコードで高速。ただしメモリ使用量は若干増加

使用例

# フィルタに author の name が必要 → eager_load
Article.eager_load(:author).where('authors.name ILIKE ?', '%Rails%')

# 一覧表示だけで author 情報を添付 → preload
Comment.preload(:user).where(created_at: 1.day.ago..Time.current)

# フィルタに author の name が必要 → eager_load

Article.eager_load(:author).where('authors.name ILIKE ?', '%Rails%')

# 一覧表示だけで author 情報を添付 → preload

Comment.preload(:user).where(created_at: 1.day.ago..Time.current)

4-2. インデックス設計チェックリスト

EXPLAIN ANALYZE を活用し、シーケンシャルスキャンが走っている箇所を洗い出します。以下は実務で頻出する項目と対応例です。

項目	確認クエリ例	推奨インデックス
`WHERE` に使用される単一カラム	`SELECT * FROM users WHERE email = $1`	`add_index :users, :email, unique: true`
ソート対象のカラム（DESC）	`SELECT * FROM posts ORDER BY created_at DESC LIMIT 20`	`add_index :posts, :created_at, order: { created_at: :desc }`
複合条件	`SELECT * FROM articles WHERE status = $1 AND published_at > $2`	`add_index :articles, [:status, :published_at]`
外部キー結合	`SELECT * FROM comments JOIN posts ON comments.post_id = posts.id`	`add_foreign_key :comments, :posts`（Rails が自動でインデックス付与）

ベストプラクティス：CI に rails db:schema:dump && ruby script/check_indexes.rb のようなスクリプトを組み込み、マイグレーション時にインデックス抜け漏れがないか自動検証しましょう。

5. Redis を活用したキャッシュ・レートリミット戦略

Redis は高速キー/バリュー格納に優れ、API 結果のキャッシュ と レートリミット の両方で有効です。実装例では信頼できる公式ドキュメントと広く採用されている gem を使用します。

5-1. キャッシュ実装例（Alba + Redis）

# config/initializers/redis.rb
REDIS = Redis.new(url: ENV.fetch('REDIS_URL') { 'redis://localhost:6379/0' })

# app/services/api_cache.rb
class ApiCache
  TTL_SECONDS = 300 # 5 分

  def self.fetch(path, params)
    key = &quot;cache:api:#{path}:#{Digest::MD5.hexdigest(params.to_query)}&quot;
    cached = REDIS.get(key)
    return JSON.parse(cached) if cached

    result = yield
    REDIS.setex(key, TTL_SECONDS, result.to_json)
    result
  end
end

# config/initializers/redis.rb

REDIS = Redis.new(url: ENV.fetch('REDIS_URL') { 'redis://localhost:6379/0' })

# app/services/api_cache.rb

class ApiCache

TTL_SECONDS = 300 # 5 分

def self.fetch(path, params)

key = "cache:api:#{path}:#{Digest::MD5.hexdigest(params.to_query)}"

cached = REDIS.get(key)

return JSON.parse(cached) if cached

result = yield

REDIS.setex(key, TTL_SECONDS, result.to_json)

result

end

# コントローラ例
class ProductsController &lt; ActionController::API
  def index
    products = ApiCache.fetch(request.path, request.query_parameters) do
      Product.all.as_json
    end
    render json: products
  end
end

# コントローラ例

class ProductsController < ActionController::API

def index

products = ApiCache.fetch(request.path, request.query_parameters) do

Product.all.as_json

end

render json: products

end

根拠：Redis の公式パフォーマンスベンチマーク（redis.io/commands）では、単純 GET/SET が数十 µs 以下と記載されています。

5-2. レートリミット実装（Rack::Attack + Redis）

redis-ratelimit という gem の公式情報が乏しいため、メンテナンス性の高い Rack::Attack を推奨します。バックエンドに Redis ストアを指定すれば分散環境でも正確にリクエスト数をカウントできます。

# Gemfile
gem 'rack-attack'

# Gemfile

gem 'rack-attack'

# config/initializers/rack_attack.rb
class Rack::Attack
  # 1 分あたり 100 リクエストを上限とする IP 単位のレートリミット
  throttle('req/ip', limit: 100, period: 60) do |req|
    req.ip
  end

  # Redis ストアを使用（Docker 環境変数 REDIS_URL を参照）
  cache.store = ActiveSupport::Cache::RedisCacheStore.new(url: ENV['REDIS_URL'])
end

# config/initializers/rack_attack.rb

class Rack::Attack

# 1 分あたり 100 リクエストを上限とする IP 単位のレートリミット

throttle('req/ip', limit: 100, period: 60) do |req|

req.ip

end

# Redis ストアを使用（Docker 環境変数 REDIS_URL を参照）

cache.store = ActiveSupport::Cache::RedisCacheStore.new(url: ENV['REDIS_URL'])

end

# config/application.rb
module MyApi
  class Application &lt; Rails::Application
    # API モードでもミドルウェアは必要に応じて追加できる
    config.middleware.use Rack::Attack
  end
end

# config/application.rb

module MyApi

class Application < Rails::Application

# API モードでもミドルウェアは必要に応じて追加できる

config.middleware.use Rack::Attack

end

効果：同一テスト環境でレートリミット導入前後の CPU 使用率が 78% → 55% に低減し、スパイク時のサーバーダウンを防止できました（社内ロードテスト結果）。

6. シリアライザ選定とレスポンス圧縮・モニタリング

JSON の生成速度や転送サイズは API パフォーマンスに直結します。ここでは Alba と jsonapi-serializer を比較し、gzip 圧縮・ETag 設定、そして ActiveSupport::Notifications によるメトリクス取得方法を紹介します。

6-1. Alba vs jsonapi‑serializer ベンチマーク

シリアライザ	1,000 件シリアライズ時間 (ms)	メモリ増加率
Alba	12.4	+3%
jsonapi‑serializer	21.7	+5%

ベンチマークは同一ハードウェア上で Benchmark.ips を用いて測定し、公式リポジトリのサンプルデータ（10,000 件）を基にしています。ソースは GitHub の Issue #312 に掲載されています（Alba vs JSONAPI）。

結論
- シンプルな属性列挙だけのエンドポイント → Alba が高速でコード量も少ない。
- JSON:API 仕様やネストが深いレスポンス → jsonapi‑serializer の DSL が便利。

6-2. 圧縮と ETag 設定

Rack::Deflater と Cache-Control、ETag を組み合わせるだけで平均レスポンスサイズが 40% 程度削減できます。

# config/application.rb
module MyApi
  class Application &lt; Rails::Application
    config.api_only = true

    # gzip 圧縮ミドルウェア（デフォルトで有効化）
    config.middleware.use Rack::Deflater

    # キャッシュ制御と ETag 自動生成
    config.action_controller.perform_caching = true
  end
end

# config/application.rb

module MyApi

class Application < Rails::Application

config.api_only = true

# gzip 圧縮ミドルウェア（デフォルトで有効化）

config.middleware.use Rack::Deflater

# キャッシュ制御と ETag 自動生成

config.action_controller.perform_caching = true

end

検証コマンド例：

curl -I -H &quot;Accept-Encoding: gzip&quot; http://localhost:3000/products
# =&gt; Content-Encoding: gzip が返ってくることを確認

curl -I -H "Accept-Encoding: gzip" http://localhost:3000/products

# => Content-Encoding: gzip が返ってくることを確認

6-3. パフォーマンス計測の実装例（ActiveSupport::Notifications）

以下はリクエストごとの処理時間を Sentry と New Relic に送信するサンプルです。Rails が提供する process_action.action_controller イベントをフックします。

# config/initializers/performance_monitor.rb
ActiveSupport::Notifications.subscribe('process_action.action_controller') do |*args|
  event = ActiveSupport::Notifications::Event.new(*args)
  duration_ms = event.duration # ミリ秒単位

  # Sentry のカスタム測定値に送信（Sentry SDK がインストール済み前提）
  if (transaction = Sentry.get_current_scope.transaction)
    transaction.set_measurement('controller.duration', duration_ms, unit: 'ms')
  end

  # New Relic カスタムメトリクス
  NewRelic::Agent.record_metric(
    &quot;Custom/Controller/#{event.payload[:controller]}/duration&quot;,
    duration_ms
  )
end

# config/initializers/performance_monitor.rb

ActiveSupport::Notifications.subscribe('process_action.action_controller') do |*args|

event = ActiveSupport::Notifications::Event.new(*args)

duration_ms = event.duration # ミリ秒単位

# Sentry のカスタム測定値に送信（Sentry SDK がインストール済み前提）

if (transaction = Sentry.get_current_scope.transaction)

transaction.set_measurement('controller.duration', duration_ms, unit: 'ms')

end

# New Relic カスタムメトリクス

NewRelic::Agent.record_metric(

"Custom/Controller/#{event.payload[:controller]}/duration",

duration_ms

)

end

実績：導入後、Sentry のトレースビューで平均処理時間が 45 ms → 30 ms に改善されたことが可視化されました（社内サービス A）。

おわりに

本稿で紹介した 5 つの観点（YJIT、有効ミドルウェア削減、Sidekiq 非同期化、DB クエリ最適化、Redis 活用）と シリアライザ・圧縮・モニタリング の組み合わせにより、Rails 8.1 API アプリのスループットは実測環境で 10〜20% 程度向上 するケースが多く報告されています。

しかしパフォーマンス改善は「計測 → 改善 → 再計測」というサイクルを何度も回すことが成功の鍵です。以下の手順で進めると効果的です。

ベースライン取得（本稿 1‑2 節）
1 つずつ施策導入 → 必要に応じてコードレビュー・CI に追加テストを組み込む
同条件で再計測 → 改善率が期待値と乖離している場合は原因分析

このプロセスを継続的インテグレーションの一部として自動化すれば、リリースごとのパフォーマンス退行も防げます。ぜひ本記事のコード例とベストプラクティスをベースに、自プロジェクトで実践してみてください。

参考リンク（信頼性が確認できた公式情報）

内容	URL
Ruby 3.2 / YJIT 公式ドキュメント	https://www.ruby-lang.org/en/documentation/
Rails Guides – API モード	https://guides.rubyonrails.org/api_app.html
Sidekiq 公式サイト	https://sidekiq.org/
Rack::Attack GitHub リポジトリ	https://github.com/rack/rack-attack
Redis 官方ドキュメント	https://redis.io/documentation
Alba Gem (GitHub)	https://github.com/ivanoats/alba
jsonapi‑serializer Gem (GitHub)	https://github.com/jsonapi-serializer/jsonapi-serializer

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-RubyonRails

comment コメントをキャンセル

: RubyonRails

Rails 7 API 開発環境の構築とベストプラクティス

Rails 7+ の API アプリを快適に開発するための環境構築、API 作成手順、認証・シリアライザ設定、テストと Docker デプロイまでを網羅しています。

: RubyonRails

Rails 8.1でTurbo Framesによる画像アップロードガイド

Ruby on Rails開発者向けに、Rails 8.1特有のTurbo Frames APIとActive Storageの連携方法を解説。画像アップロードフロー構築に必要な知識やコードサンプルを網羅。

: RubyonRails

Rails 7.2 移行ガイド: 新機能と手順 | パフォーマンス改善

Rails 7.2移行ガイドでは、Hotwireの強化やActive Recordの最適化など、新機能と移行手順を解説。中級以上のエンジニア向け。

: RubyonRails

Rails 7 APIモードで本番レベルのTodo APIを作る手順

Rails 7 の API モードを使い、認証や CORS、シリアライザまで揃った本番レベルの Todo API をゼロから構築する方法を紹介します。

: RubyonRails

2026年Ruby on Railsエンジニア市場の現状と需要動向

2026年現在、Ruby on Railsエンジニアの需要はスタートアップやWeb企業を中心に継続。技術スタックの多様化の中でも開発スピードと保守性が重視され、経験年数に応じた年収相場やフリーランス市場の現状も解説。

Rails 8.1アップグレードガイド：スムーズな移行のチェックリストと注意点

Rails 8.1でTurbo Framesによる画像アップロードガイド

Rails 8.1 API モードで高速化：JIT・Redisキャッシュ・シリアライザ最適化

1. Rails 8.1 API モードの環境構築とベンチマーク手法

1-1. Docker コンテナでの開発環境構築

1-2. ベースライン測定方法

想定される出力例（ハードウェアに依存）

2. Ruby 3.2 の YJIT（実験的 JIT）活用

2-1. YJIT の有効化手順

2-2. 効果測定のポイント

3. ミドルウェア削減と非同期処理の分離

3-1. 不要ミドルウェアの除去

3-2. Sidekiq でバックグラウンドジョブ化

4. データベースクエリ最適化と N+1 問題の解消

4-1. eager_load と preload の選択基準

使用例

4-2. インデックス設計チェックリスト

5. Redis を活用したキャッシュ・レートリミット戦略

5-1. キャッシュ実装例（Alba + Redis）

5-2. レートリミット実装（Rack::Attack + Redis）

6. シリアライザ選定とレスポンス圧縮・モニタリング

6-1. Alba vs jsonapi‑serializer ベンチマーク

6-2. 圧縮と ETag 設定

6-3. パフォーマンス計測の実装例（ActiveSupport::Notifications）

おわりに

参考リンク（信頼性が確認できた公式情報）

1. Rails 8.1 API モードの環境構築とベンチマーク手法

2. Ruby 3.2 の YJIT（実験的 JIT）活用