GitHub Copilotが2026年6月から従量課金に移ると発表され、気になったのは予算と作業への影響でした。どれくらい影響が出るのか、生産性がどれくらい落ちるのか、予算はいくら必要なのか。それを考える材料にしたくて、従量課金前の4月・5月の作業量とAIの利用量を記録し始めました。
6月以降に記録したのは、AI Creditsと変更行数です。モデルと集計方法をそろえて、日ごとに見比べていました。それでも、AIの投資対効果（ROI）は分かりませんでした。コードが増えたことと、仕事が前へ進んだことは、どうも同じではない。
考えたいのは、自分が携わっている開発業務での指標です。働く時間もAIに使える予算も、月ごとに大きく増やせるわけではありません。その条件で、どれだけ仕事を完了し、本番へ届けられたか。チームには、マージ済みPR数・本番へのデプロイ数・完了したストーリーポイント（ベロシティ）を組み合わせて記録する案を持ち込む。
AIクレジットと変更行数を並べても、成果にはならない
6月以降の日ごとの記録では、自分のコミットに含まれる追加行・削除行と、GitHubの管理画面から取得したAI利用量CSVをExcelで突き合わせていました。AIが書いた行だけを識別できるわけではありません。調査をした日も、コメントだけを直した日も、行数と利用量の並びだけでは作業内容や品質が見えません。
行数が増えたから価値が増えたとは言えません。既存システムの移行で十万行ほど変更が出る一方、細かな不具合を探して直す作業は少ない行数で終わることがありました。
不具合修正だと、トークンを使ったわりに、最後の変更はちょっとだけ、ということもあります。原因を探す調査にも時間やトークンを使っているからかなと思っています。新しくコードを作る作業と「使ったトークンに対して何行変わったか」だけで比べるのは、ちょっと無理がある。
私自身もAIで新機能のプロトタイプを先に作り、レビューや検証を待つものを増やしてしまいました。機能をたくさん作れても、一つずつ確認して検証する作業は残ります。そこが追いつかなければ、検証待ちがボトルネックになる。コードを書く速さだけを見ても、使える状態で利用者へ届けられたかは分かりません。
AIクレジットは利用量の記録、変更行数は書いたコードの量を振り返る参考値です。この2つを並べるだけでは、使える機能がどれだけ増えたかも、利用者が楽になったかも分かりませんでした。
他社でもPR数を見ていた。でも、それだけで終わらない
自分ではPR数が候補になると思っていたものの、他社が何を見ているのかも気になりました。大手企業とスタートアップの公開資料を読んでみると、実際にPR数を使う例がありました。
| 企業・事例 | 実際に見ている指標 | 自分が参考にしたいところ |
|---|---|---|
| SmartHRのある開発チーム（2026年7月） | 1スプリント・1人あたりのマージ済みPR数の中央値。AI活用前後の各7スプリントで3.75件から6.33件へ増えたと報告 | ストーリーポイントの見積もり方がAI前提に変わり、ベロシティで比較しにくくなったためPR数を採用していた |
| GitLabのCreate部門 | 月間マージ済みMR数を人数で割った値、レビュー数など。MRはGitLabでのPRに相当する変更の単位 | 件数だけで評価せず、複雑な開発、障害対応、育成なども合わせて見る。不自然な分割で件数を増やすことも避ける |
| AtlassianによるRovo Devの効果検証（2026年5月） | 顧客リポジトリの月間マージ済みPR数と、社内アンケートによる削減時間 | PR数を見る分析でも、導入前後だけでなく、似た条件の未導入リポジトリとも比べていた |
| MicrosoftのEngThrive（2026年5月公開） | 計画から顧客に届くまでの時間、価値の創出に使える時間の割合、障害1件あたりの完了PR数、開発者満足度など | 実装だけでなく、届けるまでの時間、品質、働きやすさまで見ている |
| PostHogの計画と製品レビュー（2025年6月公開） | 提供する機能・改善の進捗と、製品利用量、月次継続収益、継続率、顧客の推奨意向 | 作った後に、利用や事業へどう効いたかを月次で確かめている。これはAI単独の効果測定ではなく、製品の成果を見る運用 |
これらは各社が公表した運用や分析です。SmartHRは一つのチームの前後比較、Atlassianは無作為に導入を割り当てた実験ではありません。他社の数字を、自分たちにも出る効果や件数の目標として持ち込むつもりはありません。
PR数を候補にする考えは、自分だけの思いつきではなかった。一方で、どの資料を読んでも、件数が増えたらそれで終わり、とはなっていませんでした。
SmartHRのチームでは、機能の提供は早くなったのに、ベロシティはほとんど伸びていないようでした。AIを使う前提で、以前より小さいポイントで見積もるようになっていた。こなす量が増えても、付けるポイントを下げたら、合計には表れにくい。自分たちは、ポイントの付け方と完了の基準をすでにそろえています。ベロシティは、同じ基準で付けたポイントで比べる。
本番へのデプロイ頻度は、DORAのソフトウェア提供に関する指標にも含まれています。こちらも、変更が本番へ届くまでの時間や、変更後の失敗・復旧・手戻りと合わせて見ています。自分が気にしていた「作れたけれど、まだ届けられていない」を考えるには、この組み合わせが参考になります。
時間とAI予算が決まっているので、進めた量を見たい
私の稼働は、月に約150時間で、増減してもおおむね±10時間です。AIに使える予算にも月ごとの上限があり、使えるクレジットの枠も決まっています。時間も予算もどんどん増やして、作業量を増やせない。
それなら、ほぼ同じ時間と予算の枠で、どれだけ仕事を進められたかを比べられるのではないか。チームに持ち込むのは、次の3つを組み合わせる案です。
- ベロシティ：同じチーム・同じ見積もり基準と完了条件で、一定期間に完了したストーリーポイントを見る。件数だけでは捉えにくい作業の大きさを、相対的な量の目安にする。
- マージ済みPR数：作りかけのPR数より、変更を取り込むところまで進められた数を見る。ただし、小さな修正と大きな変更を同じ1件として数える限界は残る。
- 本番へのデプロイ数：変更が本番へ届く頻度を見る。一度にまとめて届ける場合もあるので、1回を1機能とは数えない。障害対応の再デプロイは、機能を届ける変更と可能であれば分けて計測したい。
PR数だけでは変更の大きさが分からないので、ベロシティも見る。マージしても本番へ届くまでの間があるので、デプロイ数も見る。この3つを組み合わせて、ほぼ同じ時間と予算で、完了した仕事が増えたか、本番へ届ける頻度が上がったかを比べる。
検証待ちやリリース後の不具合、手戻りが増えていないかも一緒に確認する。PRのリードタイムは、レビューや検証で止まっている理由を探す時の補助にする。
ただ、3つの数字が増えても、投資に見合った価値だったかは、使われた後の変化まで見ないと分かりません。
時間をかけた機能より、表の一列が役に立つこともある
そもそも、機能や処理、システムを作る目的は、作業や業務を楽にしたり、ストレスを減らしたり、できなかった表現をできるようにしたりすることだと思っています。知りたいのは、どれだけ早く、安く、高い価値を届けられたか。
でも、その価値が測りにくい。
たとえば、ものすごく時間をかけた機能が、案外使われないこともあり得ます。逆に、表に一列追加しただけで状況が見やすくなり、次のアクションを取りやすくなることもある。こういう差を考えると、工数やストーリーポイントを、そのまま価値の点数にはできません。
機能ごとに、作る前は「何を楽にするか」、提供後は「使われたか、何が変わったか」を短く残す。
作業時間やミスを減らす改善なら、その変化を確認する。表の一列なら、状況を把握して次の行動を決めやすくなったかを確認する。利用回数だけでは拾えない効果もあるので、使う人に何が起きたかまで追う。
チームには、3つの指標を組み合わせる案を持ち込む
利用量と変更行数を並べてみて、Copilotの効果を測るつもりが、コードの量を眺めて終わってしまいました。仕事では、実装を進めてもレビューや検証が追いつかず、利用者へ届けられない状態も経験しています。
チームには、PR数・デプロイ数・ベロシティを組み合わせて記録する案を持ち込む。ほぼ同じ時間とAI予算で、完了した仕事が増えたか、本番へ届ける頻度が上がったかを比べる。ポイントの付け方と完了の基準は、すでにそろえている。検証待ちや不具合、手戻りが増えていないかも一緒に確認する。
利用者への効果は、作った量と分けて残す。作る前に「何を楽にするか」、提供後に「使われたか、何が変わったか」を短く記録する。時間をかけた機能も、表に追加した一列も、使う人に起きた変化まで追う。
確認した公式情報
- GitHub Copilot is moving to usage-based billing – GitHub公式発表（2026年4月27日の発表と、6月1日からAI Creditsへ移行する説明を確認、2026年10月3日）
- SmartHR Tech Blog：AIドリブン開発のチームでの実践（1スプリント・1人あたりのマージ済みPR数の中央値、前後各7スプリント、3.75件・6.33件と、見積もり基準の変化、2026年10月3日確認）
- GitLab Handbook：Create部門の生産性指標と運用（マージ済みMR数・レビュー数、仕事内容を踏まえた判断、不自然な分割の回避、2026年10月3日確認）
- Atlassian：Rovo Devの効果検証（顧客のPR数と社内アンケートの区別、類似する未導入リポジトリとの比較、無作為実験ではないこと、2026年10月3日確認）
- Microsoft：EngThrive論文（社内の指標と運用、計画から顧客へ届くまでの時間・価値創出に使える時間・品質・満足度、2026年10月3日確認）
- PostHog：計画と月次の製品レビュー（提供する機能・改善と、利用・収益・継続率・顧客の推奨意向を見る運用、2026年10月3日確認）
- DORA：ソフトウェア提供に関する指標（デプロイ頻度、変更のリードタイム、失敗したデプロイからの復旧時間、変更失敗率、デプロイの手戻り率、2026年10月3日確認）
記録方法と問題意識は、2026年4月以降に行った自分の集計と、業務でレビュー・検証を待つ機能を増やした経験に基づいています。月約150時間（おおむね±10時間）とAI予算の上限は、自分の働き方の条件です。ポイントの付け方と完了の基準は、すでにチームでそろえています。PR数・デプロイ数・ベロシティを組み合わせる記録はチームへ持ち込む案、機能ごとの価値の記録も未実施の案です。表の一列の話は、実装量と価値が一致しないことを考えるための例として書いています。
コメント