AIコーディングの効果測定｜速度だけで決めない5指標
目次
はじめに
月末の開発会議で、CursorやGitHub Copilotの利用画面を開く。アクティブ率は高い。生成されたコードも多い。ところが「開発は何日短くなったのか」と聞かれると、答えが止まる。
これは珍しい場面ではない。利用回数は簡単に取れるが、事業に届いた成果は別の場所にあるからだ。コードを速く書けても、レビューの往復が増えたらチームは速くならない。リリース後の修正が増えれば、浮いた時間は消える。
AIコーディングの生産性は、キーボードを打つ速さでは測れない。仕様を受け取り、実装し、確認し、 本番へ届ける一連の流れで測る。見るべき指標は5つある。
AIコーディングの生産性を利用量で測らない
利用率、チャット回数、生成行数、提案の受入率。これらはツールが使われたかを知る先行指標として役立つ。ただし、成果そのものではない。
GitHubは、2,000人を超える開発者への調査と匿名の利用データを組み合わせ、提案の受入率と体感上の生産性に強い関連があったと報告している。一方、同社の別の実験では、95人の開発者が同じJavaScript課題に取り組み、Copilotを使った群の完了時間が平均で55%短かった。数字は魅力的だが、統制された一つの課題で得た結果である。自社の保守開発や複雑な業務システムへ、そのまま当てはめることはできない。
企業導入を調べたGitHubとAccentureの研究も、利用状況、DevOpsの計測値、アンケートを組み合わせている。「何回使ったか」と「仕事がどう 変わったか」は分けて見る。利用率は浸透度、完了時間や障害率は成果を示すからだ。
効果測定の前に比較条件をそろえる
計測を始める前に、AIありとAIなしで同じ仕事を比べられるようにする。ここが曖昧だと、精密なダッシュボードを作っても意味がない。
単位は「開発者1人」より「完了条件を持つ作業」にする。たとえば、同じサービスに対する小規模な機能追加、既知の不具合修正、テスト追加である。新規事業の立ち上げと文言修正を一緒に平均してはいけない。
SIerでは、契約と検収の条件も分ける。準委任の保守作業と、請負で顧客検収を伴う開発では、完了の位置が違うからだ。要件ID、変更要求の有無、顧客レビュー日、検収日を作業へひも付ける。社内でマージできても、顧客の受け入れで戻れば完了ではない。
作業票には最低でも次の属性を残す。
- 作業種別と対象サービス
- 見積もり規模、または変更ファイル数の帯
- 担当者の対象領域での経験
- AIを使った工程
- 要件ID、受け入れ条件、テスト結果
- 着手、初回レビュー、マージ、本番反映の時刻
- 契約形態、顧客レビュー、検収の時刻
導入前の基準値も必要だ。同じチーム、同じ種類の作業を一定期間記録する。期間と必要件数は、作業のばらつきで変わる。短い試行では効果を断定せず、データの取り方を確かめる。
AIの利用有無を自己申告だけにすると記録漏れが起きる。PRテンプレートに「使った工程」を一つ追加し、ツール側の集計と照合する。GitHub Copilotには、組織やチーム単位のアクティブ利用者、提案、受入などを集計するCopilot Metrics APIがある。ただし、取れるのは主に利用状況だ。GitHubのPRやCI/CDのデータと接続して初めて、成果との関係が見える。
AIコーディングを測る5つの指標
1. 作業のリードタイム
着手から本番反映までの時間を測る。実装完了までではない。AIでコード作成が半日短くなっても、レビュー待ちが1日増えれば、利用者へ届く速度は落ちている。顧客検収がある案件は、本番反映の代わりに検収完了まで測る。
中央値を使うと、長期停止した1件に平均が引っ張られにくい。作業種別ごとにAIあり・なしを分ける。比較する式はシンプルだ。
`短縮率 = (導入前の中央値 - 導入後の中央値) ÷ 導入前の中央値`
着手時刻が曖昧なチームでは、プルリクエストを開いてから本番反映まででもよい。完璧な データを待つより、同じ定義を守る方が価値がある。
2. レビューの往復回数と待ち時間
AI生成コードで詰まりやすいのはレビューだ。初回レビューまでの時間、修正依頼の回数、最初の指摘から承認までの時間を分けて測る。
レビューコメント数だけでは判断できない。丁寧なレビュー文化ほどコメントは増えるからだ。「要件IDとの不一致」「テスト不足」「設計方針の逸脱」「顧客変更の未反映」に分類すると、AIに渡す文脈の不足が見える。
同じ指摘が何度も出るなら、プロンプトを工夫する前に正本を確認したい。Codex CLIを業務開発で使う境界設計で触れたように、AIが読む仕様、変更してよい範囲、人間へ戻す判断を作業前に固定する。
3. 受け入れ条件の合格率
速度と対にする品質指標だ。PRの初回提出時に、受け入れテストを何件満たしたかを測る。
`初回合格率 = 初回提出で通った受け入れ条件数 ÷ 全受け入れ条件数`
ここでテスト件数を後から増減すると比較が壊れる。実装前に正常系、境界値、権限、例外、既存機能への影響を決め、要 件IDと対応させる。AIありの作業だけ簡単な条件にすれば、当然よく見えてしまう。顧客検収で追加された条件は、当初条件と変更要求に分けて数える。要件IDや受け入れ条件をAIが読める仕様として整理する場合は、Kakusillのプロダクトページも参考になる。
コード品質は単一の点数にしなくてよい。GitHubの研究は36人が統制された課題に取り組み、読みやすさ、再利用性、簡潔さ、保守性などの軸を使った。実運用の障害率を証明した研究ではない。自社では静的解析、テスト、レビュー指摘、本番障害を別々に追う。
4. 変更失敗率と再作業率
本番反映後のロールバック、緊急修正、障害対応を数える。AIが速く大量の変更を作るほど、この安全側の指標が欠かせない。
DORAはソフトウェアデリバリー性能を、スループットと不安定性に分けている。現在の指標には、変更のリードタイムやデプロイ頻度に加え、変更失敗率とデプロイ再作業率がある。速さと失敗を同時に見る設計だ。
DORAのソフトウェアデリバリー指標を参考に、自社では「本番反映後7日以内に、同じ原因で緊急作業が発生したか」と定義すると集計しやすい。AIが関与したPRだけ失敗率が高いなら、生成モデルの良し悪しと決めつけない。作業の切り方、テスト範囲、レビュー負荷も調べる。
5. リリースされた成果と総コスト
最後に、利用者へ届いた成果を数える。マージ数ではなく、受け入れ条件を満たして本番へ出た機能や修正の件数だ。請負案件では顧客検収済みの要件ID、準委任では合意した作業票を数える。
コストにはライセンス代だけでなく、レビュー、手戻り、環境整備、教育の時間を含める。たとえば月10万円のツール費で40時間を削減しても、追加レビューが25時間、障害対応が10時間増えたなら、純削減は5時間である。
`純削減時間 = 削減できた作業時間 - 追加レビュー - 再作業 - 運用時間`
チーム内でCursorなどのプラン価格が話題になるのは自然だ。だが、安いか高いかは月額だけでは決まらない。純削減時間とリリース成果を並べると、継続、縮小、対象工程の変更を判断できる 。
2週間で計測方法を試す
大規模な分析基盤は要らない。最初の2週間は、効果判定ではなく計測定義と収集フローの試行に使う。対象を一つのリポジトリに絞り、時刻、要件ID、AIの利用工程を漏れなく取れるか確かめる。
初日に、作業種別、完了条件、AIを使う工程を決める。週末にレビュー指摘と再作業を分類する。2週目の終わりには、欠損や分類の迷いを直す。ここで「何%速くなった」とは結論づけない。
ここで個人ランキングは作らない。経験、担当領域、作業難度の差が大きく、利用者が難しい仕事を避ける誘因にもなる。サービスや作業種別の単位で、流れの詰まりを探す。
DORAの生成AIレポートも、AIへの依存度や利用頻度だけでなく、信頼、フロー、レビュー時間、技術的負債、デリバリー性能などを挙げている。AIコーディングの生産性を一つの数字へ潰さない方がよい。
数字が良くても確認すべき落とし穴
短期の数字は、簡単な作業へ 偏るとよく見える。経験者だけがAIを使った場合も同じだ。導入前後で担当者と作業の種類が変わっていないかを確認する。
もう一つは、局所最適である。実装時間が減る一方、プロダクトオーナーの仕様確認やレビュアーの負荷が増えることがある。工程別の時間を残していれば、負担の移動に気づける。
正直なところ、単純な導入前後比較だけで因果関係を証明するのは難しい。正式評価では作業種別と難度で層を分け、可能なら同時期の比較群を置く。中央値だけでなく分布と件数も示す。同じ定義で繰り返せば、どの作業でAIが効き、どこで人間の確認が増えるかが見えてくる。
AIコーディングの生産性を上げる起点は、ツールの追加ではない。要件IDと完了条件を揃え、仕様変更から検収まで測れる状態を作ることだ。Atsumellでは、AIが読む要件と受け入れ条件の整理から、開発フローへの組み込み、評価設計まで支援している。利用率は高いのに成果を説明できないなら、まず一つの案件で計測方法を試してみてほしい。
