performance-report-analysis

パフォーマンスレポートアナライザー

パフォーマンステストの結果を解釈し、ボトルネックを特定して、重大度別に所見を分類し、技術担当者向けとビジネス関係者向けの2つの構造化レポートを作成します。このスキルはテスト終了後から始まります。

対象範囲の境界： このスキルの対象は、テスト実行後の結果の分析と共有です。実施するテストの計画、VU 数の見積もり、SLA の設定には、代わりに performance-testing-strategy を使用してください。

出力形式

ステップ1～3の完了後、次の2つの成果物を提出します。

1. 技術レポート — エンジニアと QA 向け：生データに基づく所見、根本原因分析、重大度の分類、具体的な改善手順。
2. ビジネスレポート — 関係者向け：ビジネスへの影響、リスク評価、推奨する意思決定。生のパーセンタイル値は記載しません。

---

ステップ1 — 結果を収集する

すぐに分析を始めないでください。まず、以下の質問を論理的なグループに分けて尋ねます。回答を待ってから先に進んでください。目的は、新しいテストを計画するのではなく、すでにテストを実施した人の視点から結果を理解することです。

グループA — 必ず尋ねる（すべての分析セッション）

ユーザーがすでに生データを貼り付けていても、まず次の質問をします。

1. ツールとテストの種類： このレポートはどのツールで生成されましたか？（k6、Gatling、Locust、JMeter、Artillery、その他）また、どの種類のテストでしたか？（負荷、ストレス、スパイク、耐久、スモーク）
2. テストは完了しましたか？ 設定した時間いっぱい実行され、目標のユーザー数／RPS に到達しましたか？ そうでない場合、結果は不完全または信頼できない可能性があります。
3. 誰がレポートを読みますか？ エンジニアと QA のみですか？ マネージャーやチームリーダーも読みますか？ ビジネス関係者や幹部向けですか？ これによって、技術レポート、ビジネスレポート、または両方を作成するかを決めます。

グループB — 貼り付けられた出力にない場合のみ尋ねる

ユーザーが共有したデータにすでに含まれている情報は尋ねず、不足している情報のみ確認します。

• パーセンタイル： p95 と p99 はありますか？ それとも平均値のみですか？
• SLA の目標： 合格／不合格のしきい値は何でしたか？（例：p95 < 800ms、エラー率 < 1%）何も定義されていない場合は、ユーザーにとって許容できない応答時間を尋ねます。
• エラーの詳細： エラーには具体的なメッセージがありましたか？（タイムアウト、接続拒否、5xx、アサーション失敗）エラーの種類によって診断が変わります。

グループC — 出力に不審な点がある場合に尋ねる

分析で追加情報が必要な所見が見つかった場合のみ、次の質問をします。

• インフラストラクチャのデータ： テスト中に何らかの監視が有効になっていましたか？（CPU、メモリ、DB メトリクス、APM）これがないと、ボトルネックの仮説を検証できません。
• ベースライン： 同じテストを以前に実行した際の結果はありますか？回帰の検出に必要です。
• インフラストラクチャのイベント： テスト中に何か異常なことが起きましたか？（デプロイ、再起動、アラート、外部インシデント）

ルール： 平均値のみでパーセンタイルも SLA の目標もない場合は、ステップ2に進まないでください。 ユーザーが SLA を提示できない場合は、業界標準値として p95 < 1000ms、エラー率 < 1% を使用し、この前提をレポート内で明示してください。

ユーザーが k6、Gatling、Locust、JMeter、Artillery の生データを貼り付けており、そのツールのレポートにある特定のフィールド、グラフ、セクションの読み取りや解釈に支援が必要な場合に限り、references/TOOL-REPORT-FORMATS.md を読み込みます。

CPU スパイク、メモリの増加、遅いクエリ、コネクションプールの枯渇、サードパーティ依存サービスの遅延など、メトリクスが劣化した「理由」の診断をユーザーが求めている場合に限り、references/BOTTLENECK-PATTERNS.md を読み込みます。

最終的な技術レポートまたはビジネスレポートの草案を作成する準備ができた場合に限り、references/REPORT-TEMPLATES.md を読み込みます。

---

ステップ2 — 所見を分析する

2.0 トリアージの順序 — 必ずここから始めてください

結果が届いたら、次の順序で評価してください。いずれかの手順でブロッカーが見つかった場合は、そこで中止して報告してください。

1. まずエラー率を確認 — ベースライン負荷でエラーが発生する場合は、容量の問題ではなくバグです。バグが修正されるまで、容量の数値は無効です。
2. テストは目標負荷に到達しましたか？ — VU 数または RPS が設定されたピークに達していない場合、結果は部分的なものです。この制約を明確に述べてください。
3. グローバル p95 と SLA — 定常状態で、最も重要な SLA は満たされていますか、それとも違反していますか？
4. 時間経過に伴うレイテンシの傾向 — テスト全体を通してパフォーマンスは安定していましたか、それとも実行途中で低下しましたか？（メモリリーク、ウォームアップ、リソース枯渇）
5. エンドポイントごとの内訳 — 問題の原因となっている具体的なエンドポイントはどれですか？エンドポイントごとのデータがある場合、グローバル指標だけを報告してはいけません。

2.1 SLA 準拠状況の確認

指標ごとに、実測値と目標値を比較します。

指標	目標	実測値	ステータス
p95 応答時間	< X ms	Y ms	PASS / FAIL
p99 応答時間	< X ms	Y ms	PASS / FAIL
エラー率	< X%	Y%	PASS / FAIL
スループット	≥ X RPS	Y RPS	PASS / FAIL

パーセンタイルを平均してはいけません。 p95 は全リクエストの 95 パーセンタイルです。p95 が 1.2s ということは、ユーザーの 5% が 1.2s 以上を経験したことを意味します。これは平均値ではなく、精度を示す数値です。

2.2 レイテンシ分布の分析

健全な状態と劣化した状態の特徴：

パターン	示唆する内容
p50 ≈ p95（ばらつきが小さい）	一貫性があり、予測可能なパフォーマンス
p95 >> p50（ばらつきが大きく、ロングテールがある）	外れ値 — GC の一時停止、ロック競合、キャッシュミス、DB の急増
負荷に伴って p50 が上昇	飽和状態 — システムがリクエストをキューに入れている
p99 >> p95	まれに深刻な停止が発生 — リトライ、タイムアウト、外部依存先を調査
ユーザー数の増加に伴い p95 が直線的に上昇	想定どおり — バグではありません。SLA の範囲内に収まることを確認してください
しきい値を超えると p95 が指数関数的に上昇	限界点 — 曲線の変曲点を特定してください

2.3 エラー率の分析

診断する前に、エラーを分類してください。

• タイムアウトエラー — 完了しなかったリクエスト：飽和状態または下流の処理の遅さを示します
• 4xx エラー — 負荷時のクライアントエラー：多くの場合、テストデータの問題です（期限切れトークン、データ不足）
• 5xx エラー — サーバー側の障害：過負荷、未処理の例外、OOM クラッシュ
• 接続エラー — 接続拒否またはリセット：インフラストラクチャの上限（接続プール、ファイアウォール、最大スレッド数）

負荷に伴って増加するエラー率（ベースラインでは発生しない）は、バグではなく容量のシグナルです。低負荷でも発生するエラー率はバグです。容量の数値を解釈する前に修正してください。

2.4 リグレッションの検出

ベースラインがある場合は、必ず差分を計算してください。

指標	ベースライン	現在	差分	フラグ？
p95	A ms	B ms	+X%	20% を超えるリグレッションでフラグ
エラー率	A%	B%	+X pp	増加があればフラグ
スループット	A RPS	B RPS	-X%	10% を超える低下でフラグ

リグレッションのしきい値（デフォルト。SLA に応じて調整してください）：

• p95 または p99 のリグレッションが 20% を超える → 劣化としてフラグ
• エラー率が 0.1 pp を超えて増加（ほぼゼロから） → 直ちにフラグ
• 同じ負荷でスループットが 10% を超えて低下 → 容量のリグレッションとしてフラグ

2.5 エンドポイントごとの分析

全体のメトリクスでは、どのエンドポイントが問題を引き起こしているのか分かりません。エンドポイントごとのデータが利用できる場合は、次の手順に従ってください。

1. p95 の降順でエンドポイントを並べ替えます。上位 3 件を調査対象とします。
2. 問題が発生しているエンドポイントに共通のパターンがないか確認します（同じ DB テーブル、同じ外部依存先、同じサービスなど）。
3. 問題を切り分けます。遅いエンドポイントが 1 つだけで全体の p95 を押し上げているのか、それとも広範囲で問題が発生しているのかを確認します。
4. SLA が全体ではなくエンドポイントごとに定義されている場合は、全体だけでなく、エンドポイントごとの SLA 遵守状況を報告します。

状況	報告する内容
10 個のエンドポイントのうち 1 つが SLA 違反の原因	そのエンドポイントを具体的に指摘します。この情報がなければ、全体の SLA 違反は誤解を招きます
すべてのエンドポイントが同時に劣化	共有リソースのボトルネックです。DB、ネットワーク、またはインフラを調査します
POST エンドポイントのみ失敗	書き込み経路を調査します。DB ロック、バリデーション、下流への書き込みなどを確認します
認証済みエンドポイントのみ失敗	認証ミドルウェア、トークン検証、セッションストアを調査します

2.6 チャートとグラフの解釈

ユーザーが視覚的なレポート（Gatling HTML、k6 ダッシュボード、Locust チャート）を共有または参照している場合は、次の点を確認します。

チャートの種類	確認する内容	注意すべき兆候
時間ごとの応答時間	定常状態では横ばいになるはずです	上昇傾向はリークまたは飽和を示します。スパイクは GC またはリトライの集中を示します
時間ごとのアクティブユーザー数／VU 数	設定されたランププロファイルと一致するはずです	目標未満での頭打ちは、テストランナーのボトルネック、または厳しすぎるレートリミッターを示します
1 秒あたりのリクエスト数	VU 数に連動するはずです	VU 数が増加しても RPS が頭打ちになる場合、システムが飽和しています
時間ごとのエラー率	ほぼゼロになるはずです	一時的なスパイク後に回復する場合は一過性です。増加し続ける場合は、容量上限が近づいています
応答時間の分布	右に裾が長い分布になるはずです（少数の遅い外れ値）	二峰性の分布は、ユーザー層が 2 つに分かれているか、キャッシュヒットとミスに分かれていることを示します

2.7 スパイクテストとウォームアップの分析

スパイクテスト — 確認すべき 3 点：

1. システムは設定されたスパイクのピークに到達しましたか？（VU／RPS チャートを確認）
2. ピーク時（負荷が最大のとき）のエラー率と p95 はどれくらいでしたか？
3. 負荷が下がった後、回復にどれくらいかかりましたか？（回復時間 ＝ ベースラインの p95 ± 10% に戻るまでの時間）

ウォームアップ／コールドスタート — SLA 評価から除外する場合：

• 最初の 2～5 分間はレイテンシが高く、その後安定する場合は、ウォームアップ期間を SLA 測定から除外します
• SLA は定常状態（ランプアップフェーズの完了後）のみ評価します
• レポートにウォームアップ時間を記載します。これはオートスケーリングとレディネスプローブの設定で重要です

---

ステップ 3 — 重大度の分類

どちらかのレポートを作成する前に、各所見の重大度を割り当てます。

重大度	定義	例
重大	SLA 違反。本番環境でユーザーがシステムを利用できない、または性能が低下している	p95 > SLA × 2、エラー率 > 5%
高	SLA 違反。デプロイした場合、ユーザーに大きな影響が及ぶ	p95 > SLA、エラー率 1～5%
中	SLA は満たしていますが、傾向に懸念があります。将来的に SLA 違反となるリスクがあります	p95 が SLA の 90% で、負荷とともに上昇している
低	SLA の範囲内。軽微な最適化の余地があります	p95 が SLA の 60% で、傾向の変化はない
参考情報	注目すべき所見ですが、対応は不要です	GC 中にレイテンシが急上昇したが、すぐに回復した

レポート内のすべての所見に重大度ラベルを付ける必要があります。

---

ステップ 4 — 技術レポート

技術レポートは、次の構成にします。具体的に記述し、実際の数値、ツール出力の抜粋、担当者を明記した具体的な次のステップを含めます。

## Performance Test Technical Report
**Date:** [date]
**Test type:** [Smoke / Load / Stress / Spike / Endurance]
**Tool:** [k6 / Gatling / Locust / JMeter / other]
**Environment:** [staging / perf / prod-clone]
**Load profile:** [X users, Y RPS, Z minutes duration]

---

### Executive Summary (3 sentences max)
[What was tested. Whether SLAs were met. Top finding in plain language.]

---

### SLA Compliance

| Metric | Target | Actual | Result |
|---|---|---|---|
| p95 response time | ... | ... | PASS/FAIL |
| p99 response time | ... | ... | PASS/FAIL |
| Error rate | ... | ... | PASS/FAIL |
| Throughput | ... | ... | PASS/FAIL |

---

### Findings

#### [CRITICAL/HIGH/MEDIUM/LOW] Finding 1 — [Short title]
**Observed:** [What the data shows, with exact numbers]
**Root cause hypothesis:** [Why this likely happened — infrastructure, code, config]
**Evidence:** [Specific metric, timestamp, or tool output that supports this]
**Recommended action:** [Concrete next step — code change, config tuning, infra scaling]
**Owner:** [Team or role responsible]
**Retest required:** Yes / No

#### [severity] Finding 2 — ...
[repeat for each finding]

---

### Regression vs. Baseline

| Metric | Baseline | Current | Delta | Status |
|---|---|---|---|---|
| p95 | — | — | — | — |
| Error rate | — | — | — | — |

[Note: omit section if no baseline exists]

---

### Infrastructure Observations
[CPU, memory, DB, network observations during the test. Flag any resource that peaked
above safe thresholds (CPU > 70%, memory upward drift, connection pool saturation).]

---

### Recommendations Summary

| Priority | Action | Owner | Target date |
|---|---|---|---|
| P1 | ... | ... | ... |
| P2 | ... | ... | ... |

---

### Test Conditions
[Document: environment, dataset size, any known limitations that affect validity of results]

---

ステップ 5 — ビジネスレポート

ビジネスレポートでは、技術的な所見を意思決定とリスクに置き換えます。生のパーセンタイル値、ツール名、技術用語は絶対に含めないでください。 すべてのメトリクスを、ユーザーまたはビジネスへの影響に置き換えてください。

翻訳表 — メトリクスをビジネス向けの表現に

技術メトリクス	ビジネス向けの表現
p95 = 1.8s（SLA: < 1s）	20人に1人のユーザーが、許容範囲のほぼ2倍の時間待たされます
ピーク時のエラー率 = 3%	混雑時には、100件のトランザクションのうち3件が失敗します
800人のユーザーでシステムが停止	現在の容量は、想定ピークの1,300人の60%です
前回のリリースと比べてp95が+40%悪化	最近のリリースにより、最も遅いユーザー体験が大幅に悪化しました
耐久性テスト：4時間でメモリが2GB増加	デプロイすると、停止を避けるために数時間ごとにサービスを再起動する必要があります

## Performance Test — Business Summary
**Date:** [date]
**System:** [product or service name]
**Test conducted by:** [team]

---

### What Was Tested
[One paragraph. What system, what scenario, what load level — in plain language.
No tool names. Example: "We simulated 500 users purchasing products simultaneously,
representing the expected traffic during the upcoming sale."]

---

### Key Question: Is It Ready?

**Overall verdict:** [Ready to deploy / Not ready — risks identified / Ready with conditions]

[One paragraph summary of what this means for the business.]

---

### Risk Summary

| Risk | Impact | Likelihood | Recommended action |
|---|---|---|---|
| [plain-language risk] | High/Med/Low | High/Med/Low | [decision recommendation] |

---

### What Happens If We Deploy Now
[Honest assessment of the user-facing impact if the system goes live as-is.
Focus on conversion, user experience, or revenue impact where applicable.]

---

### What Needs to Happen Before Go-Live
[Bullet list of must-fix items in plain language. Each bullet should say what needs
to happen and why it matters to users or the business — not how to fix it technically.]

---

### What We Can Defer
[Low/informational findings that do not block launch but should be addressed post-launch.]

---

### Decision Required
[If there is a go/no-go decision pending, state it explicitly with a recommendation
and the tradeoff of each option.]

---

結果の解釈でよくある間違い

1. パーセンタイルではなく平均応答時間を使う

平均値は外れ値を隠してしまいます。p99が8sであれば、平均200msという値に意味はありません。ユーザーが感じるパフォーマンスについては、常にp95とp99を中心に報告してください。

2. エラー率の増加パターンを無視する

ユーザー数100人で0%だったエラー率が、200人で5%に跳ね上がる場合、これは容量に関する兆候です。すべての負荷レベルでエラー率が5%なら、バグです。必要な修正はそれぞれ異なります。

3. 「平均で」SLAを満たしているため、成功と判断する

SLAは平均ではなく、パーセンタイルごとに評価する必要があります。「p95は問題ない」と「平均は問題ない」は同じ意味ではありません。

4. 異なる環境の結果を比較する

ステージング環境の結果と、本番相当の規模の環境の結果は比較できません。環境の違いを必ず記録し、その結果が何を証明し、何を証明しないのかを明示してください。

5. 技術的な数値を使ってビジネス向けレポートを作成する

ビジネス関係者に「p95 = 1,240msは、SLAの800msを超えています」と伝えても、何の行動にもつながりません。「20人に1人のユーザーが、目標より55%長い遅延を経験しています」と伝えてください。

6. ベースラインがないのに初回実行を合格とする

ベースラインがなければ、「SLAを満たしています」としか言えません。パフォーマンスが悪化していないとは言えません。初回実行の結果は必ず取得して保存し、今後の比較に使うベースラインにしてください。

7. 回復を確認せずに、ストレステストの限界点を宣言する

限界点を見つけるのは、ストレステストの半分にすぎません。負荷を取り除いた後にシステムが回復することを確認してください。クラッシュしてそのまま停止するシステムは、段階的に性能が低下するシステムよりはるかに危険です。

8. ウォームアップ期間を定常状態として分析する

テスト開始から最初の2～5分間にp95が高くなるのは、多くの場合、JITコンパイル、遅延接続初期化、またはDNS名前解決が原因であり、アプリケーションのパフォーマンスを示すものではありません。SLAへの準拠を評価するときは、必ずランプアップ／ウォームアップ期間を除外してください。

9. エンドポイントごとのデータがあるのに、全体のメトリクスしか報告しない

全体のp95が900msでも、10個すべてのエンドポイントが遅い（インフラの問題）場合と、1つのエンドポイントが9,000msを返している（特定のバグ）場合があります。結論を出したり、提案を行ったりする前に、必ずエンドポイントごとに内訳を確認してください。