p95とは、収集した全リクエストの応答時間を昇順に並べたとき、全体の95％が含まれる境界値となる応答時間です。平均値が100ミリ秒と良好に見えるシステムでも、p95を計測すると2秒を超えている事例は日常的に発生します。ダッシュボードの平均レスポンス時間が安定しているにもかかわらず、ユーザーから「画面の読み込みが異常に重い」という苦情が届いて頭を抱えた経験はありませんか。

レスポンス遅延の監視において、算術平均値だけに頼る運用には構造的な欠陥が存在します。極端に遅い少数のアクセスが大量の高速アクセスに希釈され、異常が数字の背後に隠れてしまうためです。

この記事では、WebエンジニアやSRE、インフラ担当者が押さえるべきp95の基礎概念、平均値やp99との役割分担、障害を防ぐアラート設計とチューニング手順を整理して提示します。

p95とは何の指標？平均値が現場を惑わす理由

p95とは何の指標？平均値が現場を惑わす理由

p95は、システムが処理したリクエストのうち「95％のリクエストがこの時間内に処理を完了した」という境界ラインを示す統計指標です。全体の5％に該当するリクエストは、このp95の数値よりも長い時間を要したことを意味します。

【レスポンス時間の分布イメージ（昇順並び替え）】
┌───────────────────────────────────────┬────────┐
│ 全体の95%（一般的なアクセス）          │上位5%  │
│ 50ms ─── 80ms ─── 120ms ─── 250ms ... │ 2,500ms│
└───────────────────────────────────────┴────────┘
                                        ▲
                                   ここが p95

WebシステムやAPIサーバーのパフォーマンスを評価する際、古くから使われてきたのが「平均レスポンス時間」です。全リクエストの応答時間を合算し、リクエスト総数で割る計算方法は直感的で分かりやすい特徴を持ちます。しかし、レスポンス時間のデータ分布は左右対称の正規分布にはなりません。大半のリクエストが数十ミリ秒で返る一方で、一部の処理だけが数秒から数十秒かかる「ロングテール（裾野の広い非対称な分布）」を描きます。

平均値には「極端に大きな外れ値に引っ張られる」と同時に「圧倒的多数の小さな値によって外れ値が不可視化される」という二面性があります。10,000件のリクエストのうち、9,500件が10ミリ秒で処理され、残りの500件が5,000ミリ秒（5秒）かかったケースを計算してみます。

  • 合計応答時間: (9,500件 × 10ms) + (500件 × 5,000ms) = 95,000ms + 2,500,000ms = 2,595,000ms
  • 算術平均値: 2,595,000ms ÷ 10,000件 ＝ 約259.5ミリ秒

平均値の「約260ミリ秒」という結果だけを見ると、多くのエンジニアは「少し遅い程度で許容範囲内」と判断してしまいがちです。現実には500人ものユーザーが画面の前で5秒間待たされています。全体の5％のユーザーが深刻な不利益を被っている事実が、平均値というフィルターを通すことで綺麗に隠蔽されます。

p95を算出した場合、10,000件のデータを速い順に並べた9,500番目の値を取得するため、結果は「10ミリ秒（または悪化の兆候を示す境界値）」を正確に捉え、同時に「残りの500件はもっと遅い」という構造を浮き彫りにします。平均値は全体量の把握には役立ちますが、利用者の体験実態を把握するモニタリング指標としては適していません。

パーセンタイルの仕組みと代表値（p50・p90・p99）の役割分担

パーセンタイルの仕組みと代表値（p50・p90・p99）の役割分担

パーセンタイル（百分位数）は、計測値を小さい順にソートし、最小値を0％、最大値を100％として位置づける集計手法です。監視の現場では、p95単体ではなく複数のパーセンタイル値を並行して観測します。

代表的なパーセンタイル指標の特徴と監視における用途をまとめました。

指標名別名・定義主な監視目的・読み取れる状態異常時の典型的な原因
p50中央値（Median）全体の半分（50%）が完了する時間。標準的な一般ユーザーの体感速度を表すアプリケーション全体のコード効率低下、CPU逼迫
p9090パーセンタイル上位10%の遅延を捉える。日常的な負荷のブレを評価する中長期指標一時的な通信輻輳、キャッシュミスヒットの増加
p9595パーセンタイル上位5%の遅延を捉える。多くのWebサービスでSLO・アラートの主軸となるDBスロークエリ、外部API遅延、GCの発生
p9999パーセンタイル上位1%の極端な遅延を捉える。高信頼性が求められる金融・決済・インフラ向けコネクションプールの枯渇、ロック競合、ディスクI/O詰まり
p99.93ナインパーセンタイル1,000回に1回起きる致命的なスパイクを検知する最高水準の指標OSレベルのコンテキストスイッチ、メモリ再配置の遅延

各指標には固有の役割があり、どれか1つを監視するだけではシステムの全体像は見えません。

p50（中央値）は、一般的なユーザーが体験している日常的な速度です。平均値のように少数の巨大な外れ値に引きずられないため、「普段の動きが健全かどうか」を測る土台になります。

p95は、日常的なブレと異常値の境界線に位置する実務的なスイートスポットです。ノイズのような一時的な外れ値を適度に除外しながら、アーキテクチャ上の欠陥やリソース不足によって生じる実害のある遅延を的確に捕捉します。WebシステムにおけるSLO（サービスレベル目標）の基準値としてp95が採用される理由は、運用の過剰なアラート疲れを防ぎつつ、顧客体験の悪化を確実に防げるバランスの良さにあります。

p99は、決済処理やマイクロサービス間の内部APIなど、失敗や遅延が許されない環境で真価を発揮します。100回に1回という頻度は、1人のユーザーが複数ページを回遊したり多数のAPIを並列で呼び出したりする場合、数分以内に必ず遭遇する確率です。

これらの数値を横並びで比較すると、ボトルネックの性質が瞬時に判明します。例えば「p50は30ミリ秒と極めて高速なのに、p95が800ミリ秒、p99が4,000ミリ秒まで跳ね上がっている」という状態であれば、システム全体が遅いのではなく、特定の条件下で発生するデータベースの行ロックや外部APIのタイムアウト待ちが起きていると推測できます。

なぜ平均値監視では重大な障害を見落とすのか？

なぜ平均値だけを監視している現場で障害対応が後手に回るのか。原因は、システムのアーキテクチャが複雑化し、非同期処理やキャッシュ機構が一般化したことにあります。

現代のWebシステムでは、RedisなどのインメモリキャッシュやCDNが前段に配置されています。リクエストの8割から9割はキャッシュから数ミリ秒で即座に応答を返します。このキャッシュヒットによって全体の応答時間が大幅に引き下げられる構造が日常化しています。

【現代の多層アーキテクチャにおけるレイテンシ格差】
[ クライアント ]
       │
       ▼
[ CDN / キャッシュ ] ──(80%ヒット: 5ms) ───────┐
       │                                        │（全体の平均を猛烈に下げる）
       ▼ (20%ミス)                              ▼
[ Web/Appサーバー ] ───(DB重処理: 3,000ms) ─── [ 平均値: 604ms ]
                                                ▲
                                                実際は2割のユーザーが
                                                3秒待たされている

残りの1割から2割のリクエストがキャッシュをミスし、背後のデータベースへアクセスして重い集計クエリを実行したとします。データベースの接続プールが枯渇して数秒間の待機が発生しても、前段の高速なキャッシュ応答が大量に存在するため、合算した算術平均値はほとんど変動しません。

監視ダッシュボード上の平均応答時間グラフは綺麗なフラットを示し、アラートは沈黙を保ちます。しかし、新規登録や決済、商品検索といった「データベース書き込みや複雑な検索を伴う重要なトランザクション」を行っているユーザーだけが局所的に被害を受けます。これらはビジネス上、最も離脱させてはならない顧客層です。

開発現場では「サーバーのリソース監視（CPU・メモリ）も正常で、平均レスポンスも平常値なのに、コンバージョン率が急落している」という不可解な現象に直面します。この現象の正体が、平均値の陰に隠れた上位パーセンタイルの急激な悪化です。

インフラ全体の運用設計や社内統制を検討する際には、PdMが押さえるAIリスク7分類と社内ガバナンスの作り方 (2026年版)でも触れられているような、可視化指標の抜け漏れによるビジネスリスクを未然に防ぐ視点が欠かせません。

今週のAIニュースを週1回メールで受け取る無料

毎週月曜の朝に、今週のAIの主なニュース・新しく載ったツール・よく読まれた記事をまとめて届けます。登録特典は「AIツール選定チェックリスト 2026」。

確認メールのボタンを押すと登録が完了します。配信はいつでも解除できます。

p95を監視基準に選ぶメリットと実務上の恩恵とは？

p95をシステム監視の一次指標に据えることには、運用効率とユーザー体験の両面で明確な利点があります。

最も大きな恩恵は「アラートの信頼性向上（狼少年アラートの撲滅）」です。外れ値を極限まで拾うp99や最大値（Max）を監視のトリガーに設定すると、一時的なクライアント側のネットワーク瞬断や、検索エンジンのクローラーによる突発的なアクセス集中でもアラートが発報されます。オンコール担当のエンジニアは深夜に何度も叩き起こされ、確認しても自然復旧しているという事態が頻発します。

結果としてアラートが形骸化し、本当に対応が必要な障害を見過ごす原因になります。p95は上位5％の外れ値を計算から切り離すため、突発的かつ単発のスパイクを適度にフィルタリングします。p95が継続して閾値を超えている状況は、システムの設計やリソースキャパシティに明確な異常が生じている確実なシグナルです。

【監視指標ごとのアラートノイズと検知精度の違い】
最大値(Max) : ───────▲────────▲────── (単発ノイズで誤検知多発)
p99         : ────▲──────▲──▲──────── (高精度だがアラート過敏)
p95         : ───────────■■■───────── (実害のある構造的遅延を的確に捕捉)
平均値(Avg) : ──────────────────────── (異常を完全に検知漏れ)

2つ目の利点は「ビジネスKPIとの相関性の高さ」です。ECサイトやSaaSアプリケーションにおいて、離脱率の急増と直結するのは上位数％の遅延です。Googleの調査をはじめとするWebパフォーマンス研究では、表示速度が1秒から3秒に悪化するだけで直帰率が32％上昇することが知られています。

p95をコントロールすることは、最も不満を抱えやすいストレス予備軍のユーザーを救済することを意味します。ヘビーユーザーほど複雑な操作を行い、データ量も多いため、上位5％の遅延枠に巻き込まれる頻度が高くなります。優良顧客のロイヤルティを維持するためにも、p95の維持は実務上きわめて有効に働きます。

なぜp95は悪化するのか？主な技術的要因

p95が突出して悪化する場合、システム全体が一律に重くなっているケースは稀です。特定のレイヤーで発生するリソースの待ち行列や偏りが原因の大半を占めます。

代表的な原因と影響範囲を下表に整理しました。

原因カテゴリ具体的な発生事象p95に現れる影響の特徴対策のアプローチ
データベース複合インデックス不足によるフルテーブルスキャン、N+1クエリデータ量の多い特定ユーザーの操作時のみ遅延が跳ね上がるスロークエリログの分析、インデックス再設計
コネクション管理DB接続プールやHTTPクライアントのプール枯渇負荷ピーク時にキュー待機時間が発生し、急激に崖のような悪化を示すプール数の適正化、タイムアウト値の短縮
排他制御・ロックトランザクション分離レベルの不一致、行ロック・テーブルロックの競合特定レコードの更新が集中した際に後続処理が待たされるトランザクション範囲の極小化、楽観的ロックへの移行
ガベージコレクションメモリ枯渇に伴うJava/Go/Node.js等のフルGC（Stop the World）数分から数十分おきに周期的なスパイクが全Podに分散して発生するヒープサイズのチューニング、不要なオブジェクト生成の抑制
外部通信外部決済ゲートウェイやSaaS APIのレスポンス遅延自社インフラのCPUは空いているのにp95だけが引きずられて悪化する非同期キューイング、サーキットブレーカーの導入

これらの要因を分析する際、原因がどこにあるかを切り分けるために活用されるのが分散トレーシングです。マイクロサービス環境では、1つのユーザーリクエストが数十の内部サービスを経由します。

連鎖する通信の中で、どの処理がp95の悪化を招いているかを特定するには、AI搭載IDEの選び方2026年版生産性と安全性で比較でも取り上げられるような最新の開発環境を使い、コードレベルでのプロファイリングやAPM連携をスムーズに行える体制を整えておくことが役立ちます。

p95の数値を改善する基本アプローチ

悪化したp95を健全な数値へ引き下げるには、闇雲にサーバーのスペックを上げるスケールアップではなく、ボトルネックの特性に応じたピンポイントの対策を実行します。

第一に取り組むべきは「データベースクエリの最適化」です。p95の悪化を招くクエリは、アクセス頻度は低くても1回あたりの走査行数が膨大な処理です。

-- 改善前: インデックスが効かず、全件走査（フルスキャン）でp95を押し上げる
SELECT * FROM orders 
WHERE user_id = 12345 AND status = 'pending' 
ORDER BY created_at DESC;

-- 対策: 複合インデックスを追加して走査行数を最小化する
CREATE INDEX idx_orders_user_status_created 
ON orders (user_id, status, created_at DESC);

適切な複合インデックスを追加するだけで、これまで3秒かかっていた95％目の処理が15ミリ秒まで短縮され、p95の数値が一気に正常化する事例は少なくありません。

第二のアプローチは「タイムアウトとサーキットブレーカーの厳密な設定」です。外部API連携やマイクロサービス間の通信において、相手先の応答を待ち続けることはp95を破壊する主因になります。タイムアウトを無指定のまま放置すると、デフォルトで60秒から120秒待機してしまい、リクエストを処理するワーカースレッドを長時間占有します。

【サーキットブレーカーによる遅延遮断】
[ 通常時 ]
クライアント ──▶ [ API Gateway ] ──▶ [ 外部決済API ] (50ms)

[ 相手先遅延時（対策なし）]
クライアント ──▶ [ API Gateway ] ──▶ [ 外部決済API ] (30,000ms待機で全滅)

[ サーキットブレーカー適用後 ]
クライアント ──▶ [ API Gateway ] ──X (即座にフォールバック応答: 10ms)
                                     ※障害サービスへの通信を遮断

タイムアウトを1秒や2秒といった明確な閾値で打ち切り、必要に応じてデフォルト値や縮退データを返すフォールバック処理を組み込みます。これによって、下流のサービスが遅延しても自社システムのp95が連鎖的に崩壊する事態を防ぎます。

第三のアプローチは「重い処理のバックグラウンド非同期化」です。ユーザーへのレスポンスを返す段階で、メール送信やログ解析、大規模なデータ集計を同期的に実行してはいけません。SQSやRabbitMQ、Redis Streamsなどのメッセージキューにタスクを投入し、ユーザーには即座に202 Acceptedを返却します。ユーザーの手元に届くレスポンス時間は数ミリ秒で完結し、p95の劇的な改善に直結します。

API・Webサービスにおけるp95の適正値は何ミリ秒か？

「p95は何ミリ秒以下を目指せばよいのか」という疑問は、システムの性質やアーキテクチャによって基準が異なります。業界標準および実務上の推奨値を基準として把握しておきます。

システム種別に応じたp95の目標値ラインを下表にまとめました。

システム種別p95目標値（理想）p95許容限界（要改善）設計上の留意点
一般的なWebサイト（HTML描画）800ms以下2,000ms超TTFB（最初の1バイト受信時間）を抑え、CDNキャッシュを最大限活用する
内部マイクロサービス間RPC20ms〜50ms以下100ms超1つの画面表示で十数回呼ばれるため、単体の遅延が全体へ掛け算で波及する
公開BtoB API（REST / GraphQL）200ms〜300ms以下1,000ms超クライアント側のタイムアウト設定（1秒〜3秒）に余裕を持たせる設計が必須
リアルタイム検索API100ms以下500ms超ユーザーのキーストロークごとに発火するため、極めて高い即応性が求められる
非同期バッチ処理・重集計5,000ms〜10,000ms30,000ms超同期レスポンスを諦め、進捗確認用ポーリングエンドポイントを設ける

ユーザー向けWeb画面の場合、Googleが提唱するCore Web Vitalsの「LCP（最大視認コンテンツの表示時間）2.5秒以内」を達成するために、バックエンドサーバーのp95レスポンス時間は遅くとも800ミリ秒以下に抑える必要があります。

マイクロサービス環境では基準が一段と厳しくなります。トップページを1回表示するために内部で20回のサービス間通信が発生する設計を考えてみます。1回あたりの内部APIのp95が100ミリ秒だった場合、最悪のケースでは直列に並んだ遅延が累積し、ユーザー全体の応答時間は2秒を超えてしまいます。内部APIにおけるp95は20ミリ秒から50ミリ秒以内を死守することが鉄則です。

p95監視をアラート設計とSLA・SLOへ落とし込む手順

p95を日常の運用に定着させるには、感覚的な監視を排し、SRE（Site Reliability Engineering）のプラクティスに基づいたSLI（サービスレベル指標）とSLO（サービスレベル目標）の枠組みへ落とし込みます。

【SLI・SLO・SLAの階層関係】
┌────────────────────────────────────────────────────────┐
│ SLA（サービス水準合意）: 破るとペナルティ（例: p95 < 2,000ms）│
│ ┌────────────────────────────────────────────────────┐ │
│ │ SLO（サービスレベル目標）: 内部目標（例: p95 < 500ms） │ │
│ │ ┌────────────────────────────────────────────────┐ │ │
│ │ │ SLI（サービスレベル指標）: 計測値（実際のp95レイテンシ）│ │ │
│ │ └────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘

具体的な導入ステップは次の通りです。

  1. クリティカルパスの特定: すべてのエンドポイントを一律に監視するのではなく、ログイン、カート追加、決済など、ビジネス上の最重要トランザクションを特定します。
  2. SLIの定義: 対象エンドポイントにおける「成功したリクエストの応答時間（p95）」をSLIとして定義します。ステータスコード5xxのエラーは別枠のエラーレート指標で計測します。
  3. SLOの合意: 「過去30日間において、決済APIのp95が500ミリ秒以内である割合を99.5％以上維持する」といった現実的かつ達成可能な目標を設定します。
  4. マルチウィンドウ・マルチバーンレートアラートの構築: 短期（5分間）の急激な悪化と、長期（1時間〜6時間）の緩やかな悪化の双方を検知するアラートを構成します。

ここで避けるべきは「1回でもp95が閾値を超えたら即座にPagerDutyを鳴らす」という単発閾値アラートです。ネットワークの一時的な揺らぎによって誤アラートが乱発されます。

「過去5分間の移動平均においてp95が基準値を超過し、かつ直近15分間のエラーバジェット消費率が許容ペースを上回っている場合のみ緊急通知を行う」というバーンレート監視を採用します。これにより、夜間の不要な叩き起こしを排除し、本当の異常事態にのみエンジニアが集中できる環境を構築できます。

監視データの分析手法やダッシュボードの構築ノウハウについては、データ分析のカテゴリやノーコードを活用した可視化手法を組み合わせることで、非エンジニアのステークホルダーとも共通言語で遅延状況を共有しやすくなります。

ログ集計とモニタリングツールでp95を計測する方法

パーセンタイルを算出する処理は、算術平均値に比べて計算コストが大幅に高くなります。100万件のリクエストログを毎回メモリ上に展開してソートを実行すると、監視サーバー自体のリソースを激しく浪費するためです。

現代のモニタリング基盤では、数学的なアルゴリズムを用いて「近似パーセンタイル」を高速に算出する手法が標準となっています。

【ヒストグラムによるパーセンタイル近似の仕組み】
レスポンス時間（ms）
[0 - 50ms]    : ■■■■■■■■■■■■■■■■■■■■ (5,000件)
[50 - 100ms]  : ■■■■■■■■■■ (2,500件)
[100 - 250ms] : ■■■■■■ (1,500件)
[250 - 500ms] : ■■ (500件) ─── 合計9,500件地点（95%）が
[500 - 1000ms]: ■ (200件)      このバケット（境界）にあると推定
[1000ms以上]  : ■ (300件)

代表的な監視ツールであるPrometheusでは、メトリクスタイプとして「Histogram」を使用し、histogram_quantile 関数を用いてp95を計算します。

# Prometheusでのp95レイテンシ計算クエリ例（直近5分間のHTTPリクエスト）
histogram_quantile(
  0.95, 
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Prometheusにデータを渡すアプリケーション側では、あらかじめ le（Less than or Equal to）ラベルで区切られた複数のバケット（例: 0.05秒、0.1秒、0.25秒、0.5秒、1秒、2.5秒、5秒）を定義しておきます。サーバーは各バケットに該当するカウント数のみをインクリメントして保持するため、リクエスト総数が数億件に達しても一定の極めて軽い計算量でp95を導出できます。

DatadogやAWS CloudWatchを使用する場合も同様です。Datadogではメトリクス送信時にDDSketchと呼ばれる高精度なスケッチアルゴリズムが自動適用され、p95:trace.web.request.duration{*} のようなシンプルなクエリで誤差1％未満のp95を即座に描画できます。

アクセスログを直接集計するElasticsearchやBigQueryなどの環境では、percentile_approx や APPROX_QUANTILES といった近似関数を使用するのが定石です。完全な精度を求めて生データを全件ソートするのではなく、近似集計を活用してダッシュボードの描画速度と監視の即時性を両立させることが運用上の鍵となります。

AI PICKS編集部の判定

p95を指標の中心に据えたモニタリング体制の構築は、Webシステムを運用するあらゆるチームにとって一択の選択肢です。

かつて主流だった平均値監視は、現代のキャッシュとマイクロサービスが入り組んだ多層システムにおいては、重大な障害を不可視化する危険な罠に成り下がっています。一方で、p99や最大値（Max）だけを追いかける運用は、ノイズのような外れ値に振り回されて現場を疲弊させます。その点、上位5％の構造的遅延を的確に炙り出すp95のバランス感覚は圧倒的です。

新規のプロダクトを立ち上げる際、最初から複雑なメトリクスを何十種類も並べる必要はありません。まずは主要なAPIエンドポイントに対して「p50（中央値）」と「p95」の2本をダッシュボードに並べるだけで十分です。平常時のベースラインを把握し、p95がp50の3倍から5倍以上に乖離し始めた段階でアラートを通知する設定を組むだけで、大半の重大インシデントはユーザーからのクレームが入る前に対処できます。

高価な専用APMを契約しなくても、PrometheusやCloudWatchの標準機能で十分にp95の算出は可能です。平均値のダッシュボードを眺めて安全だと錯覚する運用を今日で打ち切り、p95を基準にした実態に即したパフォーマンス監視へ移行することを強く推奨します。

よくある質問（FAQ）

Q. p95とp99はどちらを基準に監視すべきですか？

システムの性質によって使い分けます。一般的なWebサイトやコンテンツ配信、社内業務システムであれば、ノイズを抑えて実用的な障害を捉えるp95を主軸にするのが最適です。一方、決済処理、金融取引、ヘルスケア、SaaSの基幹APIのように「数千回に1回の遅延も許されないクリティカルな処理」ではp99を一次監視に採用します。実務では両方を並べて表示し、p95を日常のアラート、p99をキャパシティプランニングの参考値として併用する構成が広く採用されています。

Q. パーセンタイル値は単純に合算や平均をして集計できますか？

できません。統計学上、パーセンタイル値同士を足し算したり、複数サーバーのp95を単純平均（算術平均）したりすることは数学的に誤りです。例えば、サーバーAのp95が100ミリ秒、サーバーBのp95が300ミリ秒だったとしても、クラスター全体のp95は200ミリ秒にはなりません。サーバーごとのリクエスト処理数が異なれば比重が変わり、遅延の分布も異なるためです。複数ノードを束ねて集計する場合は、個々のノードでp95を計算するのではなく、大元のヒストグラムや生のリクエスト分布データを合算した上で、全体に対してパーセンタイル関数を適用する必要があります。

Q. p95のアラートが頻発して困る場合の対処法は？

まず監視のインターバルと評価期間を見直します。10秒や30秒といった極端に短いウィンドウでp95を評価すると、少数のリクエスト集中によって数値が乱高下します。評価期間を「直近5分間の移動平均」や「10分間継続して閾値を超えた場合」へと広げることで、一時的なスパイクを吸収できます。また、リクエスト総数が極端に少ない時間帯（深夜など）はパーセンタイル計算の母数が足りず、数件の遅延でp95が急騰します。「1分あたりのリクエスト数が100件以上ある場合のみ評価する」といった母数条件をアラートのトリガーに追加することが効果的です。

Q. データベースの集計でp95を速く計算するコツは何ですか？

全レコードをソートする ORDER BY クエリを避け、データベースエンジンが提供する近似パーセンタイル関数を利用します。PostgreSQLであれば拡張機能の tdigest、MySQL 8.0以降であればウィンドウ関数を活用しつつ対象データを時間軸でパーティショニングします。分析基盤のBigQueryでは APPROX_QUANTILES(latency, 100)[OFFSET(95)] を用いることで、生データを全件スキャンしてソートするのに比べて劇的に計算リソースとクエリ実行時間を削減できます。

Q. p90ではなくp95が業界標準として多く使われる理由は何ですか？

「上位10％（p90）」では許容範囲が広すぎて、実際にユーザーへ不快感を与えている危険な遅延を拾いこぼすリスクがあるためです。逆に「上位1％（p99）」まで絞ると、クライアント側の回線不調など自社で制御不能なノイズが混入しやすくなります。実務上「自社のインフラやアプリケーションコードの不備によって発生しており、かつ放置すると重大障害に発展する遅延」が最も綺麗に凝縮されて現れるラインが上位5％（p95）であるという経験則が、多くのSREエンジニアの間で共有されているためです。

あわせて見たいツール・カテゴリ

システムのモニタリング基盤を整え、レスポンス遅延の原因を迅速に特定・排除するために役立つツールや関連記事をピックアップしました。

パフォーマンス改善や障害に強いアーキテクチャの構築をさらに進めるなら、プロンプトの工夫で実装速度を引き上げるChatGPTのカスタム指示のおすすめ例10選｜コピペ用の最強1セット (2026年版)をあわせて読むと、開発効率の向上に直結します。