最終更新: 2026-07-02

Apdex スコア

Apdex（アプリケーション性能指標）は、応答時間の測定値の集まりを 0〜1 の満足度スコア一つに変換するためのオープン標準です。グラフを使わずにアプリケーションの性能を専門家以外に伝えられるよう設計されており、一つの数値でユーザーが満足できる速さだったリクエストの割合を表します。Apdex は多くの監視プラットフォームで広く採用されており、応答時間のサービスレベル目標を表現する一般的な方法です。

計算式

各リクエストは目標しきい値 $T$ と比較され、次の 3 つのいずれかに分類されます。

• 満足 — 応答時間が $T$ 以下。
• 許容 — 応答時間が $T$ を超え $4T$ 以下。
• 不満 — 応答時間が $4T$ より遅い、または失敗・タイムアウト。

スコアは、満足サンプル数に許容サンプル数の半分を加え、総サンプル数で割った値です。

総数は 3 つのカウントの合計です。

許容リクエストが半分として数えられるのは、それらのユーザーが遅延に気づいたものの妨げられなかったためです。不満リクエストは寄与しません。結果は必ず 0（すべて不満）から 1（すべて満足）の間に収まります。しきい値 $T$ は各リクエストがどの区分に入るかを決めますが、カウントが確定した後は計算そのものには現れません。

計算例

しきい値 $T = 500$ ミリ秒に対して測定した 1,000 リクエストの監視ウィンドウが、次のように分かれたとします。

• 満足 850 リクエスト（≤ 500 ミリ秒）
• 許容 120 リクエスト（500 ミリ秒〜2,000 ミリ秒）
• 不満 30 リクエスト（> 2,000 ミリ秒または失敗）

まず総数を確認します。

次に計算式を適用します。

0.910 というスコアは「良好」のバンドに入り、このウィンドウのトラフィックの大部分で応答時間がユーザーの期待を満たしたことを示します。

評価バンド

Apdex Alliance は、単なる数値を一目で伝えられるよう定性的なラベルを公表しています。広く使われる対応は次のとおりです。

これらのバンドは厳密な仕様ではなく報告上の慣例です。厳しいレイテンシ目標を持つチームは 0.94 未満を要注意とみなすこともあれば、バッチ寄りの社内システムはより緩やかな基準を設けることもあります。

しきい値の選び方

最も影響が大きい判断は $T$ の値です。高く設定しすぎると、鈍いアプリケーションでも見栄えの良いスコアになり、低く設定しすぎると健全なサービスでも悪く見えます。仕様では、滑らかな体験の境界としてユーザーが感じる応答時間、または既存のサービスレベル目標に $T$ を合わせることを推奨しており、対話的なページでは数百ミリ秒の範囲になることが多いです。不満の境界は $4T$ に固定されているため、$T$ を選べば区分の仕組み全体が自動的に決まります。

制約

Apdex は完全なレイテンシ分布を一つの数値に圧縮するため、必然的に詳細を捨てます。まったく異なる二つの分布が同じスコアになることもあり、固定の $4T$ 許容境界が特定アプリケーションのユーザーが実際に感じる遅延と一致しないこともあります。またスコアはスループット、不満区分を超えたエラーの意味、どのリクエストが遅かったかについては何も語りません。高レベルの満足度指標として扱い、回帰を診断する際にはパーセンタイルレイテンシやエラー率と組み合わせてください。

可用性目標に関する関連する見方は 稼働率SLAの計算 を参照してください。