レスポンスタイム監視とは？サイト表示速度の低下を早期発見する方法

サイトが「落ちていない」だけでは不十分

死活監視でサイトの稼働を確認していても、「表示に10秒かかる」状態を見逃していませんか？サイトが動いていても、表示速度が遅ければユーザーは離脱し、SEO評価も下がります。

GoogleはCore Web Vitalsをランキング要因に含めており、表示速度はSEOに直接影響します。レスポンスタイム監視は、サイトの健全性を測るもう一つの重要な指標です。

レスポンスタイムが遅いと何が起こるか

ユーザー離脱率の増加

Googleの調査によると、ページの読み込み時間が1秒から3秒に増えると、直帰率は32%増加します。5秒になると90%増加です。

SEO順位の低下

Core Web Vitalsの指標のうち、**TTFB（Time to First Byte）**はサーバーのレスポンスタイムに直結します。TTFBが遅いサイトは、検索順位で不利になる可能性があります。

コンバージョン率の低下

ECサイトでは、表示速度が1秒遅くなるごとにコンバージョン率が約7%低下するとされています。問い合わせフォームやお申し込みページも同様です。

レスポンスタイム監視の仕組み

レスポンスタイム監視では、定期的にサイトへHTTPリクエストを送信し、応答までの時間を記録します。

# curlでレスポンスタイムを手動測定する例
curl -o /dev/null -s -w "\
  DNS解決:      %{time_namelookup}秒\n\
  TCP接続:      %{time_connect}秒\n\
  TLS接続:      %{time_appconnect}秒\n\
  リクエスト送信: %{time_starttransfer}秒\n\
  合計:         %{time_total}秒\n" \
  https://example.com

上記のように、レスポンスタイムは複数のフェーズに分解できます。どのフェーズが遅いかを特定することで、原因の切り分けが可能です。

Miterlでレスポンスタイムを監視する

Miterlでは、HTTP監視と同時にレスポンスタイムも自動で記録します。各チェックの応答時間はダッシュボードのグラフで推移を確認でき、ステータスページやAPIのレスポンスにも含まれます。

# HTTP監視モニターを作成（レスポンスタイムは自動で記録される）
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントサイト",
    "type": "http",
    "url": "https://client-site.example.com",
    "interval_seconds": 60,
    "alert_contact_ids": [1]
  }'

alert_contact_ids には、ダッシュボードの「アラート連絡先」で作成済みのSlack等の通知先IDを指定します（ID は GET /alert-contacts で取得）。ダウン検知時にはここで紐付けた連絡先へ通知が飛びます。

ダッシュボードでトレンドを把握する

レスポンスタイムの推移グラフを確認することで、以下のパターンを発見できます。

• 徐々に遅くなっている: データベースの肥大化やリソース不足の兆候
• 特定の時間帯だけ遅い: アクセス集中やバッチ処理の影響
• 突然遅くなった: デプロイや設定変更の影響

制作会社がレスポンスタイム監視を活用する方法

1. 保守レポートに含める

月次レポートに「平均レスポンスタイム」と「最大レスポンスタイム」を記載することで、サイトのパフォーマンスを可視化できます。数値で示すことで保守契約の価値をクライアントに実感してもらえます。

2. パフォーマンス改善の提案につなげる

レスポンスタイムの悪化を検知したら、キャッシュの導入やサーバースペックの見直しを提案できます。クライアントへの提案に根拠となるデータがあることで、説得力が増します。

3. SLA（サービスレベル合意）に組み込む

「応答時間3秒以内を99%以上維持」のようなSLAを保守契約に含めることで、サービスの品質基準を明確にできます。

アラート閾値の設計ガイド

「何秒を超えたらアラートを出すか」の閾値設計は、アラート疲れを防ぐ上で非常に重要です。最初から厳しすぎる閾値を設定すると、わずかな負荷変動でも大量のアラートが発生し、チームが通知に慣れてしまいます。

推奨される閾値設計の流れは次のとおりです。

1. ベースラインを測定する: 最初の1〜2週間は閾値アラートをオフにして通常時のレスポンスタイムを記録する
2. 平均値の2〜3倍を初期閾値にする: 平均が800msなら閾値は2,000〜2,500ms程度
3. 徐々に絞り込む: ベースラインが安定したら閾値を見直す。最終的には「異常の前兆を捉えられる値」を目指す

閾値はサーバースペックやCDN有無によっても変わるため、あくまで出発点として使ってください。

SLAへの組み込みと稼働率レポートとの連携

レスポンスタイムは稼働率（uptime）と並んで、クライアントへの月次報告に組み込む指標として活用できます。「今月の平均レスポンスタイムは800ms、最大は2.1秒でした」と数値で示すことで、保守作業の可視化につながります。

SLA設定や月次レポートの具体的な作り方は「稼働率レポートの作り方」で詳しく解説しています。

まとめ

レスポンスタイム監視は、死活監視と並んでサイトの品質を守る重要な監視項目です。「落ちていないから大丈夫」ではなく、「快適に使えるか」まで監視することで、クライアントのビジネス成果を最大化できます。

導入の第一歩としては、まずトップページやログインページなどユーザー体験に直結する主要ページから監視対象に加え、1〜2週間のベースラインを取得することをおすすめします。ベースラインが見えれば、「普段は平均800ms、閾値は3000ms」のように根拠のある閾値設計が可能になり、アラート疲れを避けつつ異常検知の精度を高められます。閾値を一度決めたら終わりではなく、サイトの改修やトラフィック変動に合わせて定期的に見直すことも忘れないでください。

Miterlの監視設定についてはドキュメントで詳しく解説しています。実際の動作を試したい方は無料プランに登録してお試しください。他の監視ツールとの違いは死活監視ツールの比較記事で確認できます。死活監視の基本から知りたい方は「非エンジニアでもわかるサーバー監視入門」もあわせてご覧ください。