> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kodus.io/llms.txt
> Use this file to discover all available pages before exploring further.

# バグ比率

> バグ修正の PR の割合を測定します（変更失敗率とも呼ばれます）

## バグ比率とは

バグ比率は、全 PR 数に対するバグ修正や修正に関するプルリクエストの割合を測定します。このメトリクスは、開発工数のどれだけが新機能の構築ではなく問題の修正に費やされているかを理解するのに役立ちます。また、「変更失敗率」として読むこともできます — 変更が失敗につながる割合のことです。

## 計算方法

PR の名前と説明を分析するAI言語モデル（LLM）を使用して、どの PR がバグ修正かを自動的に識別します。次に、総 PR アクティビティに対するバグ関連の作業の割合を計算します。

**トラッキング対象:**

* AI 分析によってバグ修正と識別された PR
* 期間中の PR の総数
* バグ関連の作業の割合

**計算方法:**

```
バグ比率 = (バグ修正 PR) ÷ (総 PR 数) × 100
```

たとえば、15 件の PR のうち3件がバグ修正と識別された場合、バグ比率は20%です。

**バグ修正の識別方法:**
PR タイトルを分析して自動的に分類するために高度な言語モデルを使用します。AI は以下のようなパターンを探します:

* "Fix bug in..." または "Bug fix for..."
* "Resolve issue with..." または "Fix problem in..."
* "Patch for..." または "Hotfix:..."

## 重要な理由

バグ比率は、チームの開発フォーカスとコード品質の重要な指標です。この比率を理解することで:

* **開発フォーカス**: 修正と構築にどれだけの時間を費やしているかを把握
* **コード品質**: バグに費やしすぎている時間を特定
* **プロセス改善**: 開発プロセスの最適化が必要かどうかを理解
* **リソース計画**: バグ修正にどれだけの工数を割り当てるかを計画

## 改善方法

* 包括的なテスト戦略（ユニット、統合、E2E）を実装する
* 本番前に自動化ツール（リンター、静的解析ツール）を使用する
* すべての変更について徹底的なコードレビューを確保する
* 大きな機能をより小さなテスト可能な部分に分割する
* より安全なデプロイのためにフィーチャーフラグを使用する
* 再発を防ぐためにポストインシデントレビューを実施する

## PR 命名のベストプラクティス

AI がバグ修正を正確に識別できるように、以下の命名規則を検討してください:

### 良いバグ修正 PR 名

* "Fix: User login fails with invalid credentials"
* "Bug fix: Memory leak in data processing module"
* "Resolve issue: API returns 500 error for large requests"
* "Patch: Fix null pointer exception in user service"

### 曖昧な名前は避ける

* "Fix stuff" または "Bug fix"
* "Update code" または "Improve performance"
* "Fix things" または "Resolve issues"

### 機能 vs バグ修正

* **バグ修正**: "Fix: Payment validation fails for expired cards"
* **機能**: "Add: New payment method support"
* **改善**: "Enhance: Payment validation error messages"