レスポンスタイム（応答時間）とは
レスポンスタイムとは、利用者がボタンを押す、ページを開く、APIを呼び出すといった操作をしてから、システムが結果を返すまでにかかる時間のことです。
平たく言えば「待たされる時間」です。同じ機能でも、結果が一瞬で返ってくるか、数秒待たされるかで、使い心地や業務効率は大きく変わります。英語の response time をそのままカタカナにした言葉で、日本語では「応答時間」と呼ばれます。性能要件を決めるときの代表的な指標の一つで、処理量を表す「スループット」と並べて語られることが多い言葉です。
何を測るのか：区間と指標の考え方
「レスポンスタイム」と一口に言っても、どこからどこまでを測るかで数値の意味が変わります。打ち合わせで話がかみ合わない原因の多くは、この区間の認識違いです。
| 測る区間 | 内容 | 主に見る人 |
|---|---|---|
| サーバー処理時間 | リクエストを受けてから応答を返し始めるまで | バックエンド開発者 |
| API応答時間 | 呼び出し側から見た、送信から受信完了まで | 連携先・アプリ開発者 |
| 画面表示時間 | ブラウザが描画を終え、操作できるようになるまで | 利用者・事業担当者 |
| 業務完了時間 | 一連の操作で目的の作業が終わるまで | 現場の責任者 |
利用者が体感するのは画面表示時間や業務完了時間ですが、原因を突き止めるにはサーバー処理時間やデータベースの処理時間まで分解して見る必要があります。
もう一つ大事なのが「平均値だけで判断しない」ことです。平均が速くても、一部のリクエストだけ極端に遅いと、利用者には「ときどき固まるシステム」と受け取られます。そのため実務では次のような見方を組み合わせます。
- 中央値：典型的な利用者が感じる速さ
- 上位の遅い側の値（パーセンタイル）：遅い側から数えて何番目かの値。「100回に1回の遅さ」を把握できる
- 最大値：異常なケースの把握。ただし外れ値に振り回されやすい
- 時間帯別の推移：朝の始業時や締め日など、混雑時だけ遅くなっていないか
実務での使い方・具体例
要件定義での使い方
システムを発注するときは、「速いこと」ではなく、どの画面・どの処理で、どの程度の同時利用時に、どれくらいの応答時間を目標にするかを言葉にします。たとえば「一覧画面は通常時に体感でもたつかないこと、月末の集計処理は数分以内で終わればよい」のように、処理の性格ごとに分けて決めると、過剰な性能対策で費用が膨らむのを防げます。すべての画面に同じ厳しい基準を課すと、効果の薄い箇所にまで工数がかかります。
架空の例：受注管理画面が遅くなった
ある卸売の会社（架空）で、受注一覧画面が年々遅くなり、締め日には表示に長く待たされるようになりました。調べると、画面表示のたびに過去数年分の受注を全件読み込み、画面側で絞り込んでいたことが原因でした。検索条件をデータベース側で処理するように変え、よく使う条件に索引（インデックス）を付け、一覧は期間で区切って表示するように改修したところ、締め日でも待たずに使えるようになりました。サーバーを増強する前に、処理の中身を見直すのが基本の順番です。
改善の順番
- 遅い画面・APIを計測で特定する（体感ではなく数値で）
- 処理時間の内訳を分解する（データベース、外部API、画面描画など）
- 一番時間を食っている箇所から手を入れる
- キャッシュや非同期処理など、構造的な対策を検討する
- それでも足りなければサーバー性能や台数を見直す
よくある誤解と注意点
- 「サーバーを強くすれば速くなる」とは限らない：非効率なクエリや外部APIの待ち時間が原因なら、性能を上げても効果は小さくなります。
- 開発環境で速くても本番で遅いことがある：データ量や同時アクセス数が違うためです。本番に近いデータ量で負荷テストを行うのが確実です。
- 外部サービスの遅さも自社の応答時間になる：決済や地図、AIのAPIなど、連携先の応答待ちが全体を引きずることがあります。タイムアウトや代替表示を設計しておきます。
- 目標値を決めずに「遅い」と言っても改善は進まない：何秒なら許容できるか、どの画面が優先かを先に合意しておきましょう。
関連用語
- 負荷テスト：多数の同時アクセスを再現し、応答時間がどこまで保てるかを確かめる試験
- CDN（コンテンツデリバリーネットワーク）：画像などを利用者の近くから配信し、表示を速くする仕組み
- 監視（システムモニタリング）：応答時間の悪化を継続的に見張り、異常に気づくための仕組み
- オートスケーリング：負荷に応じてサーバー台数を自動で増減させる仕組み
- レイテンシ：AIや通信の文脈で使われる、応答までの遅延時間
実践的な設計はサービス監視とアラートの設計も参考にしてください。
Otsumuに相談できること
「画面が重い」という声は出ていても、どこが遅いのか分からないまま放置されているシステムは少なくありません。Otsumuでは、計測による原因の切り分けから、クエリや画面構成の改修、運用中の監視設計までを一体で支援します。既存システムの改善は保守・運用、作り直しを含む検討はシステム開発のページをご覧ください。
まずは現状の困りごとを伺い、自社で手を打てる範囲と外部に任せた方がよい範囲を整理します。30分の無料相談からお気軽にどうぞ。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01