# パイプラインのパフォーマンス

> ビルド時間、成功率と失敗率、MTTR、最近のワークフロー実行、そして自己修復された実行がどこに現れるか。

Source: https://latchkey.dev/ja/documentation/pipeline-performance

## Summary

- ワークフローの健全性、所要時間、失敗、復旧メトリクス(MTTR、リビルド成功率)を1か所に。
- 実行テーブル(ソート可能、1ページ13件、最新順)は各実行をGitHubへリンクします。修復された実行には、Heal Details ドロワーを開く緑の **Healed** バッジが付きます。
- 傾向は緩やかな悪化を捉え、Top Failed Builds は今燃えている火を見つけます。

Pipeline Performance ページは、ワークフローがどれだけ健全で、どれだけ速いかを追跡します。

使い方は2通りあります。**モニター**としては、概要と傾向をさっと見て "CIは良くなっているか悪くなっているか?" に答えます。**調査ツール**としては、1つのリポジトリまたはワークフローまで絞り込み、実行テーブルと復旧メトリクスを使って "正確に何が起きたのか、そしてどう対処したのか?" に答えます。以下のセクションはおおむねその順序で並んでいます。

## Performance Overview

- **Workflow Health**: 全体の成功率をゲージとして表示。
- 選択したウィンドウの **Average Build Duration**、**Successful Builds**、**Failed Builds**。
- **Top Failed Builds**: 失敗ビルドが最も多い3つのリポジトリと3つのワークフロー。各項目はGitHub上のリポジトリまたはワークフローファイルへ直接リンクするので、ホットスポットから修正へ飛べます。
- **Repositories Monitored** と **Workflows Monitored** の件数。数値が何を対象にしているかを正確に確認できます。

ゲージを読むための指針: たった1日の悪い日はほとんど意味を持ちません。壊れたマージ1つで、その日の成功率が単独で沈むことがあります。注意に値するのは、ウィンドウ全体にわたる持続的な低下や、リポジトリ間の差です: あるリポジトリの健全性が他より大きく下回っている場合、通常 **Top Failed Builds** が原因のワークフローを名指しし、その直接リンクからGitHub上のワークフローファイルへ直行できます。

## Build Trends

- **Successful Builds Over Time by Repository**: 成功ビルドの日次傾向。リポジトリごとに1本の線。
- **Average Build Duration by Repository** と **Workflow Duration**: リポジトリとワークフローを平均所要時間で順位付けする棒グラフ。それぞれ **Top 5 / Bottom 5** のドロップダウン付き。チャートのラベルはGitHub上のリポジトリまたはワークフローファイルへリンクします。
- **Build Duration Trend Across Workflows** で、遅くなりつつあるパイプラインを見つけます。

所要時間の傾向には、区別する価値のある2つの形があります。**段階的変化**(所要時間が特定の日に跳ね上がりそのまま留まる)は、ほぼ常に具体的な編集にたどり着きます: 新しいステップ、依存関係の変更、別のランナー。**緩やかな悪化**はより静かな問題です: 増え続けるテストスイートや積み重なるステップで、週ごとには誰も気づきません。傾向チャートは、この悪化を可視化するために存在します。Latchkeyの毎晩の信頼性ディテクターも同じ実行履歴を監視しています: 持続的な実行時間のリグレッションは、[AI Insight](/documentation/optimization-insights) に信頼性の検出結果として表面化し、エビデンスはワンクリック先にあります。

## Recent Workflow Runs

Workflow Runs テーブルは、すべてのリポジトリにわたる個々の実行の単一フィードです: ステータスアイコン、タイムスタンプ、リポジトリ、ワークフロー、**ブランチ**、所要時間。各列はソート可能で、既定の順序は最新順、実行は1ページ13件でページ分割されます。行をクリックするとGitHubで実行が開きます。

Latchkeyの自己修復が実行を修復すると、テーブルの Heal 列に緑の **Healed** バッジが表示されます。クリックすると Runners ページで **Heal Details** ドロワーが開きます: 何が失敗したか、診断、そして取られた正確なアクションを平易な言葉で。AIが診断した失敗については、エージェントの反復も含まれます。これがこのページを読むうえで重要なのは、修復された実行はクリーンな合格ではなく救出としてカウントされるからです: 同じワークフローが修復を必要とし続けるなら、根底にある不安定さはまだ解消されずに残っています。修復の仕組みは [自己修復](/documentation/self-healing) を、Recent Heals フィードの全体は [Runners ページ](/documentation/runners-dashboard) を参照してください。

## Recovery & Comparative Analysis

- **Build Fail Rate** と **Rebuild Success Rate**: ビルドがどれくらいの頻度で失敗するか、そして再実行がどれくらいの頻度でグリーンになるか。
- **Mean Time to Recovery (MTTR)** と **MTTR Over Time**: 失敗ビルドから次の成功ビルドまでの平均時間と、その日次傾向。
- **Build Status by Repository**: リポジトリごとの成功・失敗・キャンセルされたビルドを積み上げ棒グラフで。Top 5 / Bottom 5 のドロップダウン付き。

### 各復旧メトリクスが伝えること

**MTTR** は、失敗ビルドから次の成功ビルドまでの平均時間です。これはチームの復旧ループ全体を測ります: 赤いビルドに気づき、診断し、修正を届けることです。普遍的な "良い" 数値はありません。1日に何度もデプロイするチームは分単位のMTTRが必要ですが、週次リリースのチームは数時間を許容できます。普遍的に悪いのは、上昇する **MTTR Over Time** の傾向です: 失敗の診断が難しくなっているか、チームの対応が遅くなっていることを意味し、そのどちらも積み重なります。

**Rebuild Success Rate** は不安定さの検出器です。単にビルドをもう一度実行しただけで消える失敗の割合を教えてくれ、両極端は非常に異なる問題を指し示します:

**Build Fail Rate** は、リビルド成功率と並べて初めて意味を持ちます。本物のリグレッションで構成される10%の失敗率と、再実行して忘れるだけの不安定な失敗で構成される10%の失敗率は、まったく別の問題です。このページが両方の数値を示すのは、まさにあなたがそれらを区別できるようにするためです。

## メトリクス用語集

| メトリクス | 何を測るか | どう読むか |
| --- | --- | --- |
| Workflow Health | 選択したウィンドウの全体の成功率。ゲージとして表示 | 1日だけの落ち込みではなく、持続的な動きに注目 |
| Average Build Duration | 選択したスコープにわたる平均実行時間 | 絶対値よりも傾向が重要 |
| Build Fail Rate | ビルドがどれくらいの頻度で失敗するか | リビルド成功率と一緒に解釈する |
| Rebuild Success Rate | 失敗ビルドの再実行がどれくらいの頻度でグリーンになるか | 高い = 一時的/不安定な失敗、低い = 本物のリグレッション |
| MTTR | 失敗ビルドから次の成功ビルドまでの平均時間 | 検知-診断-修正のループを端から端まで測る |
| MTTR Over Time | ウィンドウ全体にわたる傾向としてのMTTR | 方向が最も重要。上昇する線は積み重なる |

**推奨する週次レビュー(好みに合わせて調整)**
- [ ] Workflow Health ゲージを先週と比較する
- [ ] Top Failed Builds で常習犯のワークフローを探す
- [ ] Build Duration Trend Across Workflows で最も急速に伸びているパイプラインを確認する
- [ ] MTTR Over Time の方向を読む
- [ ] 修復された実行のレポートを1つ開き、根底の不安定さが本当の修正に値するか問う

### ワークフロー実行に付く Healed バッジとは?

緑色の Healed バッジは、その実行中に自己修復が何かを修正したことを示します。選択すると Heal Details パネルが開き、何が失敗し、何が適用され、その後ステップが成功したかを確認できます。修復は暗黙の処理ではなく監査可能です。

### CI が遅くなっていることに気づくにはどの指標を見ますか?

現在の実行時間ではなく Build Trends です。多くのパイプラインは数週間かけて緩やかに劣化するため、トレンドがそれを捉えます。単発の遅い実行はノイズです。逆に今日対応すべき問題には Top Failed Builds を使ってください。

### ここでの MTTR と再ビルド成功率の意味は?

MTTR は同じワークフローで失敗した実行から次に成功するまでの平均時間で、失敗そのものではなく回復を測ります。再ビルド成功率は再実行が成功した割合で、低い場合は再実行しても解決しておらず、不安定な失敗ではなく本物の失敗であることを示します。

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt