遅いAPIレスポンスを改善する調査と実装手順

「画面がぐるぐる回っている時間が長い」「ユーザーから遅いというクレームが増えた」「競合アプリと比べて明らかにもっさりしている」——SPAやモバイルアプリの運用担当者から、こうした相談をよく受けます。話を聞いていくと、フロントエンドのコードよりも先に、バックエンドAPIのレスポンスが単純に遅いケースが圧倒的に多いです。

厄介なのは、「なんとなく遅い」という体感はあっても、どこが遅いのか、なぜ遅いのかが社内で言語化されていないことです。原因を特定しないまま「フロントを最適化しよう」「キャッシュを入れよう」と対症療法を試して、効果が出ずに時間だけが過ぎていく、という失敗パターンをよく見ます。この記事では、APIが遅いと感じたときに私たちが実際に行う調査手順と、典型的な原因、そしてその改善方法を、発注者にも分かる言葉で整理します。

まず「どこが遅いか」を計測する

改善の第一歩は、感覚ではなく数字で遅い箇所を特定することです。ここを飛ばして推測でコードを直し始めると、体感が変わらないまま工数だけ消費する事態になります。

• エンドポイント単位のレスポンスタイムを計測する。全ページが均等に遅いことは稀で、たいてい特定の一覧画面・検索・ダッシュボードなど、数個のエンドポイントが突出して遅いというケースがほとんどです。
• APM(Application Performance Monitoring)を導入する。New RelicやDatadog、Railsであればrack-mini-profilerのような軽量なツールでも、リクエストごとの処理時間の内訳(DB・外部API・アプリケーションコード)が可視化できます。
• 本番相当のデータ量で計測する。開発環境のデータが数十件しかないと遅さが再現しません。本番のレコード数に近いダミーデータ、あるいは匿名化した本番データのコピーで計測するのが重要です。
• ユーザー体感(TTFB・フロントの描画完了まで)とサーバー内部の処理時間を分けて見る。ネットワークやフロント側のレンダリングが遅いのか、サーバーの処理そのものが遅いのかで対処法がまったく変わります。

この段階で「遅いエンドポイントの上位5〜10個」と「それぞれの処理時間の内訳」が手元に揃えば、次の原因調査に進めます。既存プロダクトの改善に着手する際に最初に見るべき観点は、既存プロダクトの改善、外部チームが最初に見る観点でも整理しているので、着手前に合わせて確認してください。

典型的な原因のパターン

計測結果を見ていくと、遅さの原因はある程度パターン化されています。

N+1クエリ

一覧画面で関連データを表示する際、1件ごとに追加のクエリが発行されてしまう問題です。表示件数が20件なら20回、100件なら100回の余計なクエリが走るため、データが増えるほど致命的に遅くなります。APMのSQLログに同じ形のクエリが大量に並んでいたら、まずこれを疑います。N+1クエリの具体的な見つけ方と直し方はN+1クエリを見つけて潰すで詳しく解説しています。

重い集計処理をリクエスト都度実行している

ダッシュボードの合計金額やランキングなど、集計クエリをリクエストのたびにフルスキャンで計算しているケースです。データ量が少ないうちは気づかず、レコードが数万件を超えたあたりから急激に遅くなります。

外部API・外部サービスへの同期待ち

決済代行、住所検索、AIのAPIなど、外部サービスへのリクエストをレスポンスの中で同期的に待っている場合、その外部APIの遅延がそのまま自社APIの遅延になります。外部APIが不安定な時間帯にだけ遅くなる、という症状はこれが原因のことが多いです。

レスポンスペイロードの肥大化

必要のないフィールドまで全部返している、画像のURLではなくBase64データを埋め込んでいる、ページングをせず全件返しているなど、レスポンスのデータ量そのものが大きすぎるケースです。サーバー処理は速くても、転送量が大きければ体感速度は悪化します。

インデックス不足

検索やフィルタ条件に使われているカラムにインデックスが張られておらず、テーブルスキャンが発生しているケースです。データ量が小さいうちは問題にならず、成長してから顕在化するため、リリース初期には見逃されがちです。

改善の実装アプローチ

原因が特定できたら、それぞれに対応する打ち手を選びます。

• クエリの最適化: N+1はincludesやJOINでの事前読み込みに直す。集計処理は事前計算してキャッシュする、または集計用のカラム・サマリーテーブルを用意する。
• インデックス設計の見直し: 検索・ソート・フィルタで使われるカラムに複合インデックスを追加する。追加後は実際の実行計画(EXPLAIN)で効いているか確認する。
• キャッシュの導入: Redisなどで、頻繁にアクセスされるが更新頻度の低いデータをキャッシュする。キャッシュの無効化タイミングを設計しないと今度はデータの不整合を生むため、ここは慎重に設計します。
• 非同期化: 即座にレスポンスを返す必要がない処理(メール送信、外部連携、重い集計)はジョブキューに逃がし、リクエスト自体のレスポンスタイムを短縮する。
• ページング・部分取得の徹底: 一覧APIは必ずページングし、詳細画面で使わないフィールドはレスポンスから外す。GraphQLでなくとも、フィールド指定のクエリパラメータを用意するだけでも効果があります。
• レスポンス圧縮: gzip/Brotli圧縮を有効にするだけでも、テキスト中心のJSONレスポンスは大きく転送量が減ります。サーバー・CDN設定で有効化されているか確認するのは意外と見落とされがちです。

これらは一つだけ実施しても効果が薄いことが多く、計測で特定した原因に対して優先順位をつけて組み合わせるのが基本です。特にN+1解消とインデックス追加は投資対効果が高く、着手しやすい部類です。

外注時に確認すべきこと

パフォーマンス改善を外部に依頼する場合、着手前に次の点を発注者側でも押さえておくと、成果がぶれにくくなります。

• 「速くする」を定量的なゴールに落とし込んでもらう。「一覧APIのレスポンスタイムを平均2秒から500ms以内にする」のように数値で合意する。
• 改善前と改善後で同じ条件(データ量・負荷)で計測してもらう。感覚での「速くなった気がする」ではなく、計測ログでのビフォーアフターを求める。
• キャッシュや非同期化はデータ整合性のリスクを伴うため、設計方針を事前に説明してもらう。特に金額や在庫など、整合性がシビアな箇所は慎重な設計が必要です。
• 本番投入は段階的に。インデックス追加やクエリ変更は本番データ量で想定外の挙動を起こすことがあるため、負荷の低い時間帯や一部トラフィックへの適用から始めてもらうと安全です。

私たちが改善支援に入る際も、最初の1〜2週間は計測と原因特定にあて、Before/Afterの数値を明示したうえで改善提案をまとめます。原因が曖昧なまま実装だけ進めることはしません。

まとめ

• APIが遅いと感じたら、まず計測でどのエンドポイントが・どの処理が遅いのかを数値で特定することが出発点です。感覚での対症療法は工数の無駄になりがちです。
• 遅さの原因はN+1クエリ・重い集計・外部API待ち・ペイロード肥大・インデックス不足に大別され、それぞれ対処法が異なります。原因に応じてクエリ最適化・キャッシュ・非同期化・ページングを組み合わせます。
• 外注する場合は、改善のゴールを数値で合意し、Before/Afterの計測結果で成果を確認できる進め方にすることが重要です。

torcheeesでは、既存プロダクトのパフォーマンス診断から、原因特定を踏まえた改善支援まで対応しています。まずは現状のAPIレスポンスがどこで詰まっているか、無料相談で状況をお聞かせください。お問い合わせはこちら。改善支援の詳細はプロダクト改善・モダナイゼーション支援をご覧ください。