VS Code のブログに「MAI-Code-1-Flash: early results from real developer workflows」という記事が出ました(2026-07-29 公開、2026-07-30 取得)。新しいコーディングモデルのローンチ記事なのですが、目を引いたのはモデルの性能ではなく、性能の測り方のほうでした。

AI が書いたコードの評価に、受け入れたかどうかではなく、後から見てまだ残っているかを使っています。言いたいことを先に図にすると、こうです。

提案 受け入れる その後さわる コミット 受容率 ここで測定が終わる。材料は差分と、読んだ数十秒だけ 残存率 残存率は、動かして落ちた・読み返して消した … 受容の時点には無かった材料で決まる 測る区間が違うから、2つは逆を向くことがある 元記事の実測: 受容率 −6% のモデルが、残存率 +4% / コミット時残存率 +6%（baseline 比）

受容率は「読んで通したか」、残存率は「後から消さなかったか」。判定する材料も、判定する時点も違います。

この指標を手元のリポジトリで実際に数えてみたので、その結果まで書きます。先に要点だけ:

  • コミット時残存率は git だけで数えられる。過去に遡れるので、今日から計測を始める必要もない
  • 手元で数えたら全体 93.2%。ただしこの数字自体はリポジトリの性格で天井に張り付くので、あまり語らない
  • 分解すると使える。新しい行ほど残っているので期間を揃える必要があり、残存率が落ちた1日を機械的に指せた

何が変わったか

記事は品質を3つの指標で測っています(以下すべて上記 URL、2026-07-30 取得)。

原文の呼称 本記事での呼び方 何を数えるか いつ確定するか
Accept rate 受容率 利用者が受け入れた、AI 生成の提案の割合 受け入れた瞬間
Code survival rate コード残存率 AI が生成したコードのうち、残っている割合 能動編集 10 分後
Commit survival rate コミット時残存率 AI が生成したコードのうち、残っている割合 git のコミット時点

3つは数えるものがほぼ同じで、違うのは「いつ数えるか」だけです。同じ時間軸に並べると、こうなります。

提案 受け入れる 能動編集10分後 コミット 受容率 Accept rate 受け入れた瞬間に確定する コード残存率 Code survival rate 受け入れの後、編集10分ぶん コミット時残存率 Commit survival rate git のコミット時点まで(手元で数え直せるのはこれだけ) 測る区間が長いほど、受け入れの時点には無かった材料が判定に入る

効率のほうも2つに分けています。1ターンあたりの生成トークン数と、コミットに到達するまでのターン数です。どちらも中央値です。

見慣れないのは下の2つでしょう。受容率は「採ったか捨てたか」で、操作した瞬間に確定します。残存率は違って、採った後の時間経過を見ています。

数字の読み方には注意が要ります。この表の baseline は記事を書いたベンダー自身の新モデルで、それを 0% に置いた相対値です。絶対値は公開されていません。記事が「自社比較である」と断っているわけではありませんが、表の baseline 行がそのモデルで、本文でも自社のモデルとして紹介されています。

そのうえで、私が面白いと思ったのは1行でした。Kimi K2.7 Code は受容率が baseline より 6% 低いのに、残存率は 4% 高く、コミット時残存率は 6% 高い。受容と残存が逆を向いています。

ここで、元記事の書き方に触れておきます。元記事はこの行を無評価では置いていません。受容率が下がっているのに、Kimi を含む2モデルを「品質の面では優位、ただし1ターンあたり 67〜94% 多く消費し、コミットまでのターン数も多い」と評価しています。つまり元記事自身が、この行の総合判定では受容率より残存率を重く見ている。ただし「指標として残存が受容に優る」と一般化して書いてはいませんし、なぜ逆を向いたのかにも触れていません。

ここから先は私の見立てです。受容は読んでいる最中の判断です。手元にあるのは差分と、それを読んだ数十秒の理解だけで、動かしてもいないし呼び出し元も見ていない。だから短く、狭く、既存の書き方をなぞった差分ほど通りやすい。受容率を上げるのに、良い変更を出す必要はないわけです。

残存はその逆で、後から入ってきた材料で決まります。動かしたら落ちた、隣と噛み合わなかった、読み返したら要らなかった。どれも受容の時点では手元になかったものです。つまり残存は、出す側から遠いところで判定される。遠いから、なぞって通せない。

3つのうち、手元で数えられるのはどれか

3つの指標のうち、手元で再現できるのはコミット時残存率だけです。真ん中の「能動編集10分後」はエディタが編集操作を記録していないと数えられません。元記事の定義は 10 minutes of active editing なので、時計は経過時間ではなく編集量で回っていると読めます(受け入れてから10分、ではない)。ここは私の読解です。

一方でコミット時残存率は、git さえあれば数えられます。しかも git は過去に遡れるので、今日からデータを取り始める必要もない。実際に数えました。結果は次の節です。

試した結果

対象は、私が AI エージェントと書いているとあるドキュメントリポジトリです。コミットに Co-Authored-By: トレーラーが入っているので、エージェント関与のコミットを機械的に拾えます。集計は 2026-07-30 時点の HEAD に対して行っており、以下の数字はすべてその日のものです。

数えたのは、そのコミットが .md に追加した行のうち、いま HEAD に残っている行の割合です。記事の commit survival rate はコミット時点の話ですが、git で遡って数えられるのは「計測した日まで生き延びたか」なので、そこは指標の定義を変えています。

もう一段ずれがあります。git blame が数えるのは「いまその行が誰に帰属しているか」なので、後から空白を直したり行を移動したりしただけでも帰属は移り、元のコミットから見ると「消えた」と数えられます。内容が生き残っていても、触られれば残存には数えられないわけです。以下の数字はその前提で読んでください。

エージェント関与のコミットを拾い、追加行数を集計します。

git log --format='C %H %ad' --date=short --numstat --no-merges \
 | awk '/^C /{sha=$2;date=$3} /\.md$/ && $1!="-" {add[sha]+=$1; d[sha]=date} \
        END{for(s in add) print s, d[s], add[s]}' \
 | sort > added.txt

git log --format='%H %(trailers:key=Co-Authored-By,valueonly)' \
 | grep -i claude | cut -d' ' -f1 | sort > ai.txt

いま HEAD に残っている行を、由来のコミット別に数えます。git blame の --line-porcelain は1行ごとにコミット SHA を先頭に出すので、それを数えるだけです。

git ls-files '*.md' | xargs -I{} git blame --line-porcelain HEAD -- {} 2>/dev/null \
 | awk '/^[0-9a-f]{40} /{print $1}' | sort | uniq -c \
 | awk '{print $2, $1}' | sort > alive.txt

3つを突き合わせて、日付ごとに集計します。

join added.txt ai.txt | join -a1 - alive.txt \
 | awk '{a=($4==""?0:$4); print $2, $3, a}' | sort \
 | awk '{add[$1]+=$2; alive[$1]+=$3} \
        END{for(d in add) printf "%s  追加 %6d  残存 %6d  %5.1f%%\n", \
                                 d, add[d], alive[d], alive[d]/add[d]*100}' \
 | sort

出力です。

2026-07-16  追加   5849  残存   5076   86.8%
2026-07-17  追加   1886  残存   1718   91.1%
2026-07-19  追加    236  残存    216   91.5%
2026-07-20  追加   3903  残存   3834   98.2%
2026-07-21  追加   1176  残存   1137   96.7%
2026-07-22  追加    863  残存    791   91.7%
2026-07-24  追加    239  残存    153   64.0%
2026-07-25  追加   1103  残存   1047   94.9%
2026-07-26  追加   2851  残存   2620   91.9%
2026-07-27  追加   2370  残存   2357   99.5%
2026-07-29  追加   1638  残存   1618   98.8%
2026-07-30  追加    720  残存    717   99.6%

全体では 22,834 行の追加に対して 21,284 行が残存、93.2% でした。日付ごとに並べると、こうなります。

100% 80% 60% 86.8 07-16 91.1 07-17 91.5 07-19 98.2 07-20 96.7 07-21 91.7 07-22 64.0 07-24 94.9 07-25 91.9 07-26 99.5 07-27 98.8 07-29 99.6 07-30 07-24 だけ落ちている 古い ← 　書かれた日　 → 新しい（新しい行ほど、まだ消される時間を与えられていない）

全体の数字は、あまり意味がない

93.2% という数字そのものは、正直たいして語っていません。これは書き足す一方のドキュメントリポジトリで、コードのように書き直しが起きにくい。エージェントがほぼ全部を書いているので分母も母集団も偏っています。リポジトリの性格しだいで天井に張り付く指標だ、というのがまず分かったことでした。

面白いのは分解したほうです。

新しい行ほど残っている

日付順に並べると傾きが見えます。計測日の当日(07-30)が 99.6%、前日(07-29)が 98.8%、2週間前の初日(07-16)が 86.8%。

当たり前といえば当たり前で、新しい行はまだ消される時間を与えられていないだけです。ただこれは、指標として使うときに効いてくる性質だと思います。残存率は、測った時点から遡る期間を揃えないと比較できません。「今週の残存率が先週より高い」は、たいてい今週のほうが若いというだけの話になります。記事が 2026-06-02 から 07-24 という期間を明記している理由も、たぶんここでしょう。

これは受容率にはない面倒さです。受容率はその場で確定するので、いつ数えても同じ。残存率は遅い。今この差分を採るかどうかの判断には、原理的に間に合わない指標です。

1日だけ、明らかに外れている

07-24 の 64.0% が浮いています。他はすべて 86% 以上なので、ここだけ 20 ポイント以上低い。

同じ3つのファイルを日付で絞ればコミット単位まで割れるので、掘ってみました。落ち込みはほぼ1本のコミットが作っていて、217 行追加したうち残っているのは 141 行(65%)。その日に書いた設計文書が、後から大幅に書き直されていたわけです(対象がプライベートなリポジトリなので、コミットの中身は伏せます)。

ここで言いたいのは「その日の作業が失敗だった」ではありません。設計文書は改訂されるものですし、実際この文書は後続の議論で作り直されました。指標が言ったのは「この日を見ろ」までで、見に行って理由が分かったのは人間のほうです。それでも、200 コミット以上ある中から見るべき1日を機械的に指したことには意味があると思いました。受容率を数えていても、この日は浮かんできません。

この指標の限界

やってみて、残ったことは正しいことではないとはっきり思いました。誰も読み返していない行も残ります。残存率が言っているのは「後から消されなかった」ことだけで、品質の証明にはなっていない。

それに、残存率を目標にすれば今度はそれが操作の対象になります。消しにくいものを書けば数字は上がる。受容率で起きていたことが、一段ずらして再現するだけです。

なので私の結論は「受容率をやめて残存率にする」ではありません。2つを並べて置いて、逆を向いたときに気づくのが使い方だろうと思います。冒頭の Kimi の行が面白かったのも、逆を向いていたからでした。片方だけ見ていたら、あれはただの「受容率が低いモデル」です。

なお元記事は、指標としての優劣づけは書いていません。3つを並置しているだけで、受容率を捨てるとも、残存率のほうが良い指標だとも書いていない。個々のモデルの総合判定では残存を重く見ているものの、それを一般則として述べてはいない。一般化したのは私です。

まとめ

  • VS Code のブログが、AI 生成コードの品質を受容率・残存率(能動編集10分後)・コミット時残存率の3層で報告していた
  • そのうちコミット時残存率は git だけで数えられる。過去に遡れるので、今日から始める必要もない
  • 手元のドキュメントリポジトリで数えたら全体 93.2%。ただしこの数字自体はリポジトリの性格で天井に張り付く
  • 分解すると使える。新しい行ほど残っているので期間を揃えないと比較できず、残存率が落ちた1日を機械的に指せた
  • ただし残ったことは正しいことではない。受容率と並べて置いて、逆を向いたときに気づくための道具だと思う