Cursor の KPI 設計：リードタイム・欠陥率・レビュー時間を定量で追う

2025年10月23日

Cursor

AI ペアプログラミングツール「Cursor」の導入効果を可視化するには、定量的な測定が欠かせません。本記事では、開発チームが実践できる KPI 設計の具体策を解説します。リードタイム、欠陥率、レビュー時間の 3 つの指標を中心に、測定方法から改善アクションまでを体系的に整理しました。

背景

Cursor による開発プロセスの変化

Cursor は AI によるコード補完・生成機能を備えたエディタとして、多くの開発チームに採用されています。従来の IDE と比較して、以下のような変化が生まれました。

コード記述の大幅な高速化
AI による設計提案やリファクタリング支援
自然言語でのコード生成によるプロトタイピングの迅速化

しかし、これらの変化が実際にどれだけの効果をもたらしているのか、定量的に把握できていないチームも少なくありません。

KPI 測定の必要性

以下の図は、Cursor 導入による開発プロセスの変化と KPI の関係を示しています。

mermaidflowchart TB
  cursor["Cursor 導入"]
  change1["コード記述の<br/>高速化"]
  change2["AI による<br/>設計支援"]
  change3["プロトタイピング<br/>迅速化"]

  kpi1["リードタイム<br/>短縮"]
  kpi2["欠陥率<br/>変動"]
  kpi3["レビュー時間<br/>変化"]

  cursor --> change1
  cursor --> change2
  cursor --> change3

  change1 --> kpi1
  change2 --> kpi2
  change3 --> kpi1
  change1 --> kpi3
  change2 --> kpi2

この図から分かるように、Cursor の各機能は複数の KPI に影響を与えます。そのため、効果を正確に把握するには体系的な測定設計が必要です。

図で理解できる要点

Cursor の 3 つの主要機能が開発プロセスに与える影響
各機能が複数の KPI に関連していること
効果測定には包括的なアプローチが必要であること

測定のメリット

定量的な KPI 測定によって、以下のメリットが得られます。

導入効果の客観的な評価
改善すべき領域の特定
ステークホルダーへの説明責任の向上
チーム内での共通認識の形成

これらのメリットを最大化するためには、適切な指標選定と測定方法の確立が重要です。

課題

従来の測定手法の限界

多くの開発チームでは、以下のような課題を抱えています。

主観的な評価に依存

「速くなった気がする」「品質が上がった気がする」といった感覚的な評価では、正確な効果測定ができません。また、メンバー間で認識のズレが生じやすくなります。

データ収集の困難さ

必要なデータが複数のツールに分散しており、手動での集計に多大な工数がかかるケースが多く見られます。

指標の不統一

チームごとに異なる指標を使用していると、組織全体での比較や分析が困難になるでしょう。

Cursor 特有の測定課題

Cursor の効果測定には、従来の開発ツールとは異なる課題が存在します。

以下の図は、Cursor 導入時に直面する主な測定課題を整理したものです。

mermaidflowchart LR
  challenges["測定課題"]

  c1["AI 生成コードと<br/>手動コードの<br/>区別困難"]
  c2["品質評価の<br/>基準不明確"]
  c3["学習期間の<br/>影響考慮"]
  c4["従来ツールとの<br/>公平な比較"]

  challenges --> c1
  challenges --> c2
  challenges --> c3
  challenges --> c4

  c1 --> impact1["リードタイム<br/>測定の歪み"]
  c2 --> impact2["欠陥率評価の<br/>不正確さ"]
  c3 --> impact3["短期評価の<br/>誤り"]
  c4 --> impact4["ROI 算出の<br/>困難さ"]

図で理解できる要点

Cursor 特有の 4 つの測定課題
各課題が KPI 測定精度に与える影響
包括的な対策が必要であること

AI 生成コードの識別

どの部分が AI によって生成され、どの部分が人間が手動で記述したのかを区別することが難しいという問題があります。

品質基準の曖昧さ

AI が生成したコードの品質をどのように評価するか、明確な基準が定まっていないケースが多いです。

学習期間の考慮

Cursor の効果を最大化するには、チームメンバーが使い方に習熟する期間が必要となります。この学習期間をどう考慮するかが課題です。

解決策

KPI 設計の 3 つの柱

Cursor の効果を正確に測定するため、以下の 3 つの KPI を中心に設計します。

#	KPI	測定対象	期待される効果
1	リードタイム	着手から完了までの時間	開発速度の向上
2	欠陥率	リリース後の不具合発生率	コード品質の維持・向上
3	レビュー時間	コードレビューにかかる時間	レビュー効率の改善

これらの KPI は相互に関連しており、バランスよく測定することで Cursor の真の効果を把握できます。

リードタイムの測定設計

リードタイムは、開発の速度と効率を示す重要な指標です。

測定ポイント

以下のタイミングでデータを取得します。

着手時刻: チケット・Issue のステータスが「In Progress」に変更された時刻
完了時刻: プルリクエストがマージされた時刻

測定方法の実装

Git と GitHub API を活用した自動測定の例を示します。

測定スクリプトの準備

まず、必要なパッケージをインストールします。

bashyarn add @octokit/rest date-fns

GitHub API クライアントの初期化

API クライアントを設定し、リポジトリ情報を取得できるようにします。

typescriptimport { Octokit } from '@octokit/rest';

// GitHub API クライアントの初期化
const octokit = new Octokit({
  auth: process.env.GITHUB_TOKEN, // 環境変数からトークンを取得
});

// リポジトリ情報
const owner = 'your-organization';
const repo = 'your-repository';

プルリクエスト情報の取得

指定期間内のプルリクエストデータを取得します。

typescriptimport { differenceInHours } from 'date-fns';

// プルリクエスト一覧を取得する関数
async function getPullRequests(since: string) {
  const { data } = await octokit.pulls.list({
    owner,
    repo,
    state: 'closed', // マージ済みのPRのみ対象
    sort: 'updated',
    direction: 'desc',
    per_page: 100,
  });

  // 指定日以降のPRに絞り込み
  return data.filter(
    (pr) =>
      pr.merged_at &&
      new Date(pr.merged_at) > new Date(since)
  );
}

リードタイムの計算

各プルリクエストのリードタイムを算出します。

typescriptinterface LeadTimeData {
  prNumber: number;
  title: string;
  leadTimeHours: number;
  createdAt: string;
  mergedAt: string;
}

// リードタイムを計算する関数
function calculateLeadTime(
  pullRequests: any[]
): LeadTimeData[] {
  return pullRequests.map((pr) => {
    const createdAt = new Date(pr.created_at);
    const mergedAt = new Date(pr.merged_at!);

    // 着手から完了までの時間（時間単位）
    const leadTimeHours = differenceInHours(
      mergedAt,
      createdAt
    );

    return {
      prNumber: pr.number,
      title: pr.title,
      leadTimeHours,
      createdAt: pr.created_at,
      mergedAt: pr.merged_at!,
    };
  });
}

統計値の算出

平均値、中央値、標準偏差を計算します。

typescriptinterface LeadTimeStats {
  average: number;
  median: number;
  stdDev: number;
  min: number;
  max: number;
}

// 統計値を計算する関数
function calculateStats(
  leadTimes: LeadTimeData[]
): LeadTimeStats {
  const values = leadTimes
    .map((lt) => lt.leadTimeHours)
    .sort((a, b) => a - b);

  // 平均値
  const average =
    values.reduce((sum, val) => sum + val, 0) /
    values.length;

  // 中央値
  const median =
    values.length % 2 === 0
      ? (values[values.length / 2 - 1] +
          values[values.length / 2]) /
        2
      : values[Math.floor(values.length / 2)];

  // 標準偏差
  const variance =
    values.reduce(
      (sum, val) => sum + Math.pow(val - average, 2),
      0
    ) / values.length;
  const stdDev = Math.sqrt(variance);

  return {
    average,
    median,
    stdDev,
    min: values[0],
    max: values[values.length - 1],
  };
}

これらの統計値により、リードタイムの傾向を多角的に分析できます。中央値は外れ値の影響を受けにくいため、平均値と併せて確認することが重要です。

欠陥率の測定設計

欠陥率は、Cursor による開発がコード品質に与える影響を示す指標です。

測定ポイント

以下の情報を追跡します。

リリース単位: 各リリースでデプロイされた機能数
欠陥数: リリース後に報告されたバグ・不具合の件数
欠陥の重要度: Critical、High、Medium、Low の 4 段階で分類

測定方法の実装

Issue トラッキングシステム（GitHub Issues、Jira など）のデータを活用します。

Issue データの取得

GitHub Issues から欠陥情報を収集します。

typescript// 欠陥として分類されたIssueを取得する関数
async function getDefects(since: string) {
  const { data } = await octokit.issues.listForRepo({
    owner,
    repo,
    state: 'all',
    labels: 'bug', // bugラベルが付いたIssueを対象
    since, // 指定日以降のIssueのみ
    per_page: 100,
  });

  return data;
}

欠陥の分類と集計

重要度別に欠陥を集計します。

typescripttype Severity = 'critical' | 'high' | 'medium' | 'low';

interface DefectData {
  issueNumber: number;
  title: string;
  severity: Severity;
  createdAt: string;
  closedAt: string | null;
}

// 欠陥を重要度別に分類する関数
function classifyDefects(issues: any[]): DefectData[] {
  return issues.map((issue) => {
    // ラベルから重要度を判定
    let severity: Severity = 'low';

    if (
      issue.labels.some((l: any) => l.name === 'critical')
    ) {
      severity = 'critical';
    } else if (
      issue.labels.some((l: any) => l.name === 'high')
    ) {
      severity = 'high';
    } else if (
      issue.labels.some((l: any) => l.name === 'medium')
    ) {
      severity = 'medium';
    }

    return {
      issueNumber: issue.number,
      title: issue.title,
      severity,
      createdAt: issue.created_at,
      closedAt: issue.closed_at,
    };
  });
}

欠陥率の算出

リリースごとの欠陥率を計算します。

typescriptinterface DefectRate {
  releaseVersion: string;
  totalFeatures: number; // リリースされた機能数
  totalDefects: number; // 検出された欠陥数
  defectRate: number; // 欠陥率（%）
  bySeverity: Record<Severity, number>; // 重要度別の件数
}

// 欠陥率を計算する関数
function calculateDefectRate(
  releaseVersion: string,
  featuresCount: number,
  defects: DefectData[]
): DefectRate {
  // 重要度別の集計
  const bySeverity = defects.reduce((acc, defect) => {
    acc[defect.severity] = (acc[defect.severity] || 0) + 1;
    return acc;
  }, {} as Record<Severity, number>);

  // 欠陥率の計算（機能数に対する欠陥の割合）
  const defectRate = (defects.length / featuresCount) * 100;

  return {
    releaseVersion,
    totalFeatures: featuresCount,
    totalDefects: defects.length,
    defectRate: Math.round(defectRate * 100) / 100, // 小数点第2位まで
    bySeverity,
  };
}

この測定により、Cursor 導入前後での品質変化を定量的に把握できます。重要度別の内訳を見ることで、致命的な欠陥が増えていないかも確認可能です。

レビュー時間の測定設計

レビュー時間は、コードレビューの効率性を示す指標です。Cursor による高品質なコード生成により、レビュー時間の短縮が期待できます。

測定ポイント

以下のタイミングを記録します。

レビュー開始: プルリクエストが作成された時刻
最初のレビューコメント: レビュアーが最初にコメントした時刻
承認時刻: プルリクエストが承認（Approve）された時刻

測定方法の実装

GitHub のプルリクエストレビュー API を活用します。

レビュー情報の取得

各プルリクエストのレビュー履歴を取得します。

typescript// PRのレビュー情報を取得する関数
async function getReviewData(prNumber: number) {
  const { data: reviews } = await octokit.pulls.listReviews(
    {
      owner,
      repo,
      pull_number: prNumber,
    }
  );

  const { data: comments } =
    await octokit.pulls.listReviewComments({
      owner,
      repo,
      pull_number: prNumber,
    });

  return { reviews, comments };
}

レビュー時間の計算

開始から承認までの時間を算出します。

typescriptimport { differenceInMinutes } from 'date-fns';

interface ReviewTimeData {
  prNumber: number;
  timeToFirstReview: number; // 最初のレビューまでの時間（分）
  timeToApproval: number; // 承認までの時間（分）
  reviewerCount: number; // レビュアーの人数
  commentCount: number; // コメント数
}

// レビュー時間を計算する関数
async function calculateReviewTime(
  prNumber: number,
  createdAt: string
): Promise<ReviewTimeData> {
  const { reviews, comments } = await getReviewData(
    prNumber
  );

  // 最初のレビューコメントまたは承認の時刻
  const firstReviewTime =
    reviews.length > 0
      ? new Date(reviews[0].submitted_at!)
      : comments.length > 0
      ? new Date(comments[0].created_at)
      : null;

  // 承認された時刻
  const approvalTime = reviews.find(
    (r) => r.state === 'APPROVED'
  )?.submitted_at;

  const prCreatedAt = new Date(createdAt);

  return {
    prNumber,
    timeToFirstReview: firstReviewTime
      ? differenceInMinutes(firstReviewTime, prCreatedAt)
      : 0,
    timeToApproval: approvalTime
      ? differenceInMinutes(
          new Date(approvalTime),
          prCreatedAt
        )
      : 0,
    reviewerCount: new Set(
      reviews.map((r) => r.user?.login)
    ).size,
    commentCount: comments.length,
  };
}

レビュー効率の分析

複数のプルリクエストからレビュー効率を分析します。

typescriptinterface ReviewEfficiency {
  averageTimeToFirstReview: number; // 平均レビュー開始時間
  averageTimeToApproval: number; // 平均承認時間
  averageCommentCount: number; // 平均コメント数
  fastReviewRate: number; // 1時間以内のレビュー率（%）
}

// レビュー効率を分析する関数
function analyzeReviewEfficiency(
  reviewTimes: ReviewTimeData[]
): ReviewEfficiency {
  const totalPRs = reviewTimes.length;

  // 平均値の計算
  const avgFirstReview =
    reviewTimes.reduce(
      (sum, rt) => sum + rt.timeToFirstReview,
      0
    ) / totalPRs;

  const avgApproval =
    reviewTimes.reduce(
      (sum, rt) => sum + rt.timeToApproval,
      0
    ) / totalPRs;

  const avgComments =
    reviewTimes.reduce(
      (sum, rt) => sum + rt.commentCount,
      0
    ) / totalPRs;

  // 高速レビュー率（60分以内に承認されたPRの割合）
  const fastReviews = reviewTimes.filter(
    (rt) => rt.timeToApproval > 0 && rt.timeToApproval <= 60
  ).length;

  return {
    averageTimeToFirstReview: Math.round(avgFirstReview),
    averageTimeToApproval: Math.round(avgApproval),
    averageCommentCount: Math.round(avgComments * 10) / 10,
    fastReviewRate:
      Math.round((fastReviews / totalPRs) * 100 * 10) / 10,
  };
}

これらの指標により、Cursor がレビュープロセスに与える影響を可視化できます。コメント数の減少は、生成されたコードの品質が高いことを示す可能性があります。

統合ダッシュボードの構築

3 つの KPI を一元的に可視化するダッシュボードを構築します。

以下の図は、データ収集から可視化までのフローを示しています。

mermaidflowchart LR
  gh["GitHub API"]
  jira["Jira API"]

  collector["データ収集<br/>スクリプト"]

  db[("時系列<br/>データベース")]

  dashboard["可視化<br/>ダッシュボード"]

  gh --> collector
  jira --> collector

  collector --> db
  db --> dashboard

  dashboard --> metric1["リードタイム<br/>トレンド"]
  dashboard --> metric2["欠陥率<br/>推移"]
  dashboard --> metric3["レビュー時間<br/>分布"]

図で理解できる要点

複数のデータソースから情報を統合
時系列データベースでの一元管理
3 つの主要 KPI の同時可視化

データ収集の統合

各 KPI の測定結果を統合するメイン関数を作成します。

typescriptinterface KPIReport {
  period: string; // 測定期間
  leadTime: LeadTimeStats;
  defectRate: DefectRate[];
  reviewEfficiency: ReviewEfficiency;
  generatedAt: string;
}

// 全KPIを収集・統合する関数
async function generateKPIReport(
  since: string
): Promise<KPIReport> {
  // プルリクエストデータの取得
  const pullRequests = await getPullRequests(since);

  // リードタイムの計算
  const leadTimeData = calculateLeadTime(pullRequests);
  const leadTimeStats = calculateStats(leadTimeData);

  // 欠陥データの取得と分析
  const defects = await getDefects(since);
  const defectData = classifyDefects(defects);
  // 実際にはリリースごとに集計（ここでは簡略化）
  const defectRates = [
    calculateDefectRate('v1.2.0', 25, defectData),
  ];

  // レビュー時間の計算
  const reviewPromises = pullRequests.map((pr) =>
    calculateReviewTime(pr.number, pr.created_at)
  );
  const reviewTimes = await Promise.all(reviewPromises);
  const reviewEfficiency =
    analyzeReviewEfficiency(reviewTimes);

  return {
    period: `${since} ~ ${new Date().toISOString()}`,
    leadTime: leadTimeStats,
    defectRate: defectRates,
    reviewEfficiency,
    generatedAt: new Date().toISOString(),
  };
}

レポートの出力

収集したデータを JSON 形式で保存します。

typescriptimport { writeFile } from 'fs/promises';
import { format } from 'date-fns';

// レポートをファイルに保存する関数
async function saveReport(
  report: KPIReport
): Promise<void> {
  const fileName = `kpi-report-${format(
    new Date(),
    'yyyy-MM-dd'
  )}.json`;

  await writeFile(
    `./reports/${fileName}`,
    JSON.stringify(report, null, 2),
    'utf-8'
  );

  console.log(`レポートを保存しました: ${fileName}`);
}

実行スクリプトの作成

定期的に KPI を収集するスクリプトを用意します。

typescript// メイン実行関数
async function main() {
  try {
    // 過去30日間のデータを対象
    const since = new Date();
    since.setDate(since.getDate() - 30);

    console.log('KPIレポートの生成を開始します...');

    const report = await generateKPIReport(
      since.toISOString()
    );
    await saveReport(report);

    console.log('KPIレポートの生成が完了しました');
    console.log(
      `リードタイム平均: ${report.leadTime.average.toFixed(
        1
      )}時間`
    );
    console.log(
      `レビュー承認時間平均: ${report.reviewEfficiency.averageTimeToApproval}分`
    );
  } catch (error) {
    console.error('エラーが発生しました:', error);
    process.exit(1);
  }
}

// スクリプトの実行
main();

これで、定期的に KPI データを収集し、ファイルとして保存できるようになります。

具体例

実際の運用シナリオ

あるスタートアップ企業が Cursor を導入し、3 ヶ月間 KPI を測定した事例を紹介します。

チーム構成とツール構成

#	項目	詳細
1	チーム規模	エンジニア 8 名
2	プロジェクト	Web アプリケーション開発
3	技術スタック	TypeScript、Next.js、React
4	バージョン管理	GitHub
5	プロジェクト管理	GitHub Projects

測定期間と比較方法

以下のタイムラインで測定を実施しました。

mermaidflowchart LR
  before["導入前<br/>（1ヶ月）"]
  learning["学習期間<br/>（2週間）"]
  after["導入後<br/>（3ヶ月）"]

  before -->|ベースライン測定| learning
  learning -->|習熟| after
  after -->|効果測定| comparison["比較分析"]

  style before fill:#e1f5ff
  style after fill:#fff4e1
  style comparison fill:#e8f5e9

図で理解できる要点

導入前のベースライン測定の重要性
学習期間を考慮した測定設計
十分な期間（3 ヶ月）での効果検証

導入前（ベースライン）: 1 ヶ月間、従来の VS Code での開発データを収集 学習期間: 2 週間、Cursor の使い方をチーム全体で習得 導入後: 3 ヶ月間、Cursor を使った開発データを収集

リードタイムの改善結果

測定結果を以下の表にまとめます。

#	指標	導入前	導入後（1 ヶ月目）	導入後（3 ヶ月目）	改善率
1	平均リードタイム	48.5 時間	42.3 時間	35.2 時間	27.4% 短縮
2	中央値	36.0 時間	32.5 時間	28.0 時間	22.2% 短縮
3	標準偏差	18.2 時間	16.8 時間	14.5 時間	ばらつき減少

特に注目すべきは、3 ヶ月目の大幅な改善です。これは、チームメンバーが Cursor の使い方に習熟し、効果的な活用方法を共有できたためと考えられます。

改善要因の分析

リードタイム短縮の主な要因として、以下が挙げられました。

定型的なコードの自動生成による記述時間の削減
AI による設計提案を活用した実装方針の迅速な決定
リファクタリング作業の効率化

欠陥率の推移

品質面での変化を確認します。

#	リリース	機能数	欠陥数	欠陥率	Critical	High	Medium	Low
1	v1.0（導入前）	32	8	25.0%	1	2	3	2
2	v1.1（1 ヶ月目）	28	7	25.0%	0	3	2	2
3	v1.2（2 ヶ月目）	35	6	17.1%	0	1	3	2
4	v1.3（3 ヶ月目）	40	5	12.5%	0	1	2	2

欠陥率は導入後に徐々に低下し、最終的に 50% の改善を達成しました。特筆すべきは、Critical レベルの欠陥がゼロになった点です。

品質向上の要因

以下のような AI 支援が品質向上に寄与しました。

エッジケースの考慮漏れを AI が指摘
型安全性を重視したコード生成
ベストプラクティスに沿った実装の提案

レビュー時間の変化

コードレビューの効率性を確認します。

#	指標	導入前	導入後（3 ヶ月目）	改善率
1	平均承認時間	185 分	142 分	23.2% 短縮
2	最初のレビューまでの時間	52 分	38 分	26.9% 短縮
3	平均コメント数	8.3 件	5.7 件	31.3% 減少
4	1 時間以内承認率	18%	32%	77.8% 向上

レビュー時間の短縮は、生成されたコードの品質が高く、指摘事項が減少したためです。また、AI が一貫性のあるコーディングスタイルを維持したことで、スタイルに関するコメントが減少しました。

レビュープロセスの変化

Cursor 導入後、以下のようなレビュープロセスの変化が見られました。

スタイルやフォーマットに関する指摘の減少
ロジックやアーキテクチャに関する本質的な議論の増加
レビュアーの負担軽減による迅速なフィードバック

継続的な改善サイクル

KPI 測定を単なるモニタリングで終わらせず、改善アクションにつなげることが重要です。

以下の図は、PDCA サイクルを用いた継続的改善のプロセスを示しています。

mermaidflowchart TB
  plan["Plan<br/>目標設定と<br/>測定計画"]
  do_measure["Do<br/>KPI測定の<br/>実施"]
  check["Check<br/>データ分析と<br/>課題抽出"]
  act["Act<br/>改善施策の<br/>実行"]

  plan --> do_measure
  do_measure --> check
  check --> act
  act --> plan

  check --> issue1["リードタイム<br/>増加の検出"]
  check --> issue2["特定機能の<br/>欠陥率上昇"]

  issue1 --> action1["ボトルネック<br/>の特定"]
  issue2 --> action2["AI プロンプト<br/>の見直し"]

  action1 --> act
  action2 --> act

図で理解できる要点

PDCA サイクルによる継続的な改善
データ分析から具体的な課題の抽出
課題に応じた的確な改善アクション

週次レビュー会議の実施

毎週、以下の内容をチームで確認します。

確認項目

前週の KPI トレンド
異常値やスパイクの有無
改善が必要な領域の特定

改善アクションの例

測定データから以下のようなアクションを実施しました。

#	発見した課題	実施したアクション	結果
1	特定の機能でリードタイムが長い	Cursor のカスタムプロンプトを作成	30% 短縮
2	API 統合部分の欠陥率が高い	AI に渡すコンテキストを充実化	欠陥率 40% 減
3	レビューコメントが特定パターンに集中	チーム内でプロンプト事例を共有	コメント 25% 減

月次レポートの作成

毎月末に、経営層・ステークホルダー向けのレポートを作成します。

レポートに含める内容

以下の情報を 1 ページにまとめます。

3 つの KPI のサマリー（前月比、導入前比）
主要な改善成果のハイライト
次月の重点施策

サンプルレポート構成

typescriptinterface MonthlyReport {
  month: string;
  summary: {
    leadTime: {
      current: number;
      previousMonth: number;
      baseline: number;
      improvement: string;
    };
    defectRate: {
      current: number;
      previousMonth: number;
      baseline: number;
      improvement: string;
    };
    reviewTime: {
      current: number;
      previousMonth: number;
      baseline: number;
      improvement: string;
    };
  };
  highlights: string[];
  nextMonthFocus: string[];
}

// 月次レポートを生成する関数
function generateMonthlyReport(
  currentData: KPIReport,
  previousData: KPIReport,
  baselineData: KPIReport
): MonthlyReport {
  return {
    month: format(new Date(), 'yyyy年M月'),
    summary: {
      leadTime: {
        current: currentData.leadTime.average,
        previousMonth: previousData.leadTime.average,
        baseline: baselineData.leadTime.average,
        improvement: calculateImprovement(
          baselineData.leadTime.average,
          currentData.leadTime.average
        ),
      },
      // 他のKPIも同様に集計
      defectRate: {
        current: currentData.defectRate[0].defectRate,
        previousMonth:
          previousData.defectRate[0].defectRate,
        baseline: baselineData.defectRate[0].defectRate,
        improvement: calculateImprovement(
          baselineData.defectRate[0].defectRate,
          currentData.defectRate[0].defectRate
        ),
      },
      reviewTime: {
        current:
          currentData.reviewEfficiency
            .averageTimeToApproval,
        previousMonth:
          previousData.reviewEfficiency
            .averageTimeToApproval,
        baseline:
          baselineData.reviewEfficiency
            .averageTimeToApproval,
        improvement: calculateImprovement(
          baselineData.reviewEfficiency
            .averageTimeToApproval,
          currentData.reviewEfficiency.averageTimeToApproval
        ),
      },
    },
    highlights: [
      'リードタイムが前月比15%改善',
      'Critical欠陥ゼロを3ヶ月連続達成',
    ],
    nextMonthFocus: [
      'テスト自動化率の向上',
      'Cursorプロンプトのベストプラクティス策定',
    ],
  };
}

// 改善率を計算する関数
function calculateImprovement(
  baseline: number,
  current: number
): string {
  const rate = ((baseline - current) / baseline) * 100;
  return rate > 0
    ? `${Math.round(rate * 10) / 10}% 改善`
    : `${Math.round(Math.abs(rate) * 10) / 10}% 悪化`;
}