遅いRailsアプリを改善する診断項目と優先順位
「トップページの表示に5秒かかる」「特定の画面だけ異様に重く、ユーザーからの離脱率が高い」「サーバーを増強してもなぜか改善しない」——Railsで作られたプロダクトが本番で遅く、売上やCVに影響が出ているという相談を私たちはよく受けます。
厄介なのは、遅さの原因を推測だけで直そうとして空振りするケースが多いことです。「なんとなくサーバーのスペックが足りない気がする」とインスタンスを増強しても速くならず、費用だけが積み上がる。あるいは「このコードが怪しい」と当たりをつけて手を入れたら、実は別の場所がボトルネックだった。この記事では、Railsアプリの遅さを推測でなく計測から特定し、優先順位をつけて改善する進め方を整理します。
まず「計測」から始める、推測で直さない
パフォーマンス改善で最初にやるべきことは、コードを読むことではなく計測です。感覚で「ここが遅そう」と当たりをつけて手を入れると、体感速度が変わらないまま工数だけを消費するということが頻繁に起きます。
- APM(New Relic、Datadog、Skylightなど)を導入する: どのアクション・どのクエリが何ミリ秒かかっているかを可視化する。導入していないRailsアプリは、実はかなり多い
rails-mini-profilerやbulletgem で開発環境から当たりをつける: 本番導入前でも、N+1クエリの検出はこれらのgemで早期に見つけられる- 本番のスロークエリログを見る: PostgreSQLなら
log_min_duration_statementを設定し、一定時間以上かかったクエリを記録する - どのページが、どのユーザー層で遅いかを特定する: 全ページが一律に遅いのか、特定の画面(一覧・検索・集計)だけが遅いのかで、原因も対処法も変わる
計測をせずに改善に着手すると、体感では速くなった気がしても実測では変わっていない、というすれ違いが発注者と開発チームの間でよく起きます。「何がどれだけ遅いか」を数字で合意してから着手するのが、無駄な工数を避ける最短ルートです。
遅さの典型的な原因
計測で当たりをつけたら、Railsアプリで頻出する原因のどれに当てはまるかを確認します。
- N+1クエリ: 一覧画面で関連レコードを1件ずつ個別に取得しており、100件表示するのに101回SQLが発行されている。Railsで最も頻出する遅さの原因で、
includesやpreloadで解消できることが多い - インデックス不足: WHERE句やJOIN、ORDER BYに使われるカラムにインデックスが無く、テーブルが育つほど遅くなる。開発環境ではデータが少なく気づかれにくい
- 重いクエリ・集計処理: 複雑なJOINやサブクエリ、画面表示のたびにSUM/COUNTを実行する集計処理が、リクエストのたびにフルスキャンされている
- キャッシュが無い: 変更頻度の低いデータ(カテゴリ一覧、設定値、集計結果など)を毎回DBから取得している。Rails標準のフラグメントキャッシュや、Redisを使ったキャッシュ層が入っていないことが多い
- アセットの肥大化: 画像が最適化されていない、JS/CSSのバンドルサイズが大きい、不要なライブラリが読み込まれている、といったフロントエンド側の要因
- 外部API呼び出しの直列実行: 決済・地図・配送業者のAPIなど、外部サービスへの呼び出しを同期的に何度も行い、レスポンスを待つ時間がそのまま画面表示の遅延になっている
これらは特殊な問題ではなく、リリース当初はデータ量もアクセス数も少なく問題化しなかったものが、事業が伸びるにつれて表面化するパターンがほとんどです。特にN+1クエリは改善効果が高く着手しやすいため、詳しい直し方はN+1クエリを解消する進め方で扱っています。
優先順位のつけ方
計測で複数の原因が同時に見つかったとき、全部を一度に直そうとすると予算も時間も膨らみます。私たちは次の軸で優先順位をつけます。
- ユーザー影響が大きい画面から着手する: 訪問数が多いトップページや、CVに直結する申込・購入フローの遅さは、社内向け管理画面より優先度が高い
- 改善効果が大きく、対応コストが小さいものから着手する: N+1クエリの解消はコード変更のみで数日〜1週間程度で終わることが多く、効果も体感しやすい。一方でDB設計自体の見直しは数週間〜数ヶ月かかる大きな改修になる
- インフラ増強は最後の手段にする: サーバーのスペックを上げても、N+1クエリや無駄な全件取得といったコード側の非効率はそのまま残る。増強は「コード側の改善を終えたうえで、それでも足りない場合」に検討する
この順序を逆にして「まずサーバー増強、それでもダメならコードを見る」と進めると、クラウド費用だけが積み上がって根本原因が温存されがちです。管理画面など社内向け利用の遅さについては、業務インパクトから優先順位をつける進め方を遅い管理画面を業務効率から改善する進め方で解説しています。
外部に依頼するときの進め方
Railsアプリのパフォーマンス改善を外部に依頼する場合、いきなり実装から入らず、次の順番で進めるのが安全です。
- 現状の計測: APMやスロークエリログを使って、どの画面・どのクエリが遅いかを実測する
- 原因の切り分け: N+1・インデックス不足・キャッシュ不足・アセット・外部API呼び出しのどれに該当するかを特定する
- 優先順位の合意: ユーザー影響と対応コストを突き合わせ、着手順を発注者と合意する
- 段階的な改善とリリース: 一度に全体を直そうとせず、優先度の高いものから小さくリリースして効果を計測しながら進める
このとき重要なのは、改善前後で同じ指標を同じ条件で比較することです。「体感で速くなった」ではなく、Time to First Byte やページの表示完了時間、APMが記録するレスポンスタイムの中央値・95パーセンタイルといった数字で、改善効果を発注者と共有できる状態にします。この進め方は、既存プロダクト改善で外部チームが最初に見る観点で解説している全体診断の一部としても位置づけられ、パフォーマンス以外の技術的負債と合わせて優先順位を整理できます。
まとめ
- Railsアプリの遅さは推測で直すと空振りしやすく、APMやスロークエリログによる計測から始めるのが最短ルート
- 原因はN+1クエリ・インデックス不足・重い集計・キャッシュ不足・アセット肥大化・外部API直列実行といった典型パターンに集約されることが多い
- 優先順位はユーザー影響の大きさと対応コストの小ささから決め、インフラ増強はコード側の改善を終えたうえで最後の手段として検討する
torcheees ではRuby on Railsを中心に、既存プロダクトのパフォーマンス診断・改善を数多く手がけています。「なんとなく遅い気がする」という段階でも、まずは1〜4週間の「既存プロダクト診断」で遅さの原因を実測し、改善の優先順位と概算費用をご提示します。継続的な改善支援はモダナイゼーションのサービスとして承っています。お問い合わせフォームからお気軽にご相談ください。