AI と書いたドキュメントを git の履歴で追ったら、追加した行の 93.2% が計測日まで残っていました。ほとんど残っている、と眺めていたのですが、日付ごとに分けると 64.0% まで下がる日がありました。
その日のコミットへ戻ると、後の議論で大きく書き直した設計文書が見つかりました。今回、数えて役に立ったのはここです。全体の数字から文章の良し悪しを判断するのは難しくても、200 コミット以上の中から読み返す日を絞れました。
きっかけは VS Code の「MAI-Code-1-Flash: early results from real developer workflows」(2026-07-29 公開、2026-07-30 取得)。AI が書いたコードの評価に、採用後にどれだけ残ったかも使っています。手元では同じ記録を取れないので、コミット後から計測日までに残った行を数えました。
採用されやすい提案が、後まで残るとは限らない
VS Code の記事で使っている品質指標は 3 つです。定義は上記ページで 2026-07-30 に確認したものです。
| 原文の呼び方 | 何を見るか | 測る時点 |
|---|---|---|
| Accept rate (受容率) | AI の提案が受け入れられた割合 | 受け入れたとき |
| Code survival rate (コード残存率) | AI が生成したコードのうち残った割合 | 能動編集 10 分後 |
| Commit survival rate (コミット時残存率) | AI が生成したコードのうち残った割合 | git へコミットしたとき |
「能動編集 10 分」は原文の 10 minutes of active editing です。単に採用から 10 分待つのではなく、編集操作をした時間として読んでいます。
効率については、1 ターンあたりの生成トークン数と、コミットまでのターン数を、どちらも中央値で示しています。比較表は自社の新モデルを 0% に置いた相対値で、絶対値は公開されていません。
気になったのは Kimi K2.7 Code の行でした。受容率は基準より 6% 低いのに、コード残存率は 4% 高く、コミット時残存率は 6% 高い。採用されやすさと、採用後に残りやすいかどうかで、逆の結果になっています。
元記事は Kimi を含む 2 モデルを、品質では優位だが、1 ターンあたり 67〜94% 多くのトークンを使い、コミットまでのターン数も多いと評価しています。残存率を重く見た評価に読めますが、指標として受容率より優れていると一般化しているわけではありません。
差分を読んでよさそうだと思っても、動かしたらほかのコードと合わないことはあります。文章でも、いったん採用した説明を、後の議論で書き直すことがあります。自分の履歴にも、そういう変更がどれくらいあるのか見たくなりました。
git で計測日までの残存率を数える
元記事と同じ指標を測るには、AI の提案や編集操作の記録が必要です。手元の git 履歴で分かるのは、コミットした行がその後も残っているかどうかです。今回はこれを数えました。
対象は、私が AI エージェントと書いているドキュメントリポジトリです。Co-Authored-By: に Claude が入ったコミットを拾い、そのコミットが .md に追加した行数と、2026-07-30 時点の HEAD に残った行数を比べました。
残ったかどうかは git blame の帰属で判断します。空白の修正や行の移動で別のコミットに帰属すると、内容が同じでも元のコミットの行としては数えられません。また、共同作業のコミット全体を対象にしているので、AI が書いた行だけを厳密に分けた集計でもありません。
まず追加行数と、エージェントが関与したコミットを拾います。
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 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% でした。
書いたばかりの行が残るのは、当然でもある
計測日当日の 07-30 は 99.6%、前日の 07-29 は 98.8%。一方、2 週間前の 07-16 は 86.8% です。新しい行は、まだ修正や削除の機会が少ないので高く出やすそうです。
比較に使うなら、追加してから測るまでの期間を揃える必要があります。今週と先週を同じ日に測っても、今週のほうが書かれてからの日が浅いだけかもしれません。元記事でも計測期間は 2026-06-02 から 07-24 と明記されています。
今回のリポジトリは書き足しが多く、コードほど頻繁に書き直していません。しかも大半がエージェントとの共同作業です。93.2% という数字を、そのままAIの成績にするには無理がありました。
64%だった7月24日のコミットを開く
ほかの日がすべて 86% 以上なのに、07-24 は 64.0%。20 ポイント以上の差があったので、コミットまで戻って調べました。
主な原因は、217 行を追加し、そのうち 141 行 (65%) が残っているコミットでした。その日に書いた設計文書が、後続の議論で大きく書き直されていました。private リポジトリなので内容は載せませんが、下がった理由は分かりました。
設計を改訂するのは普通のことです。この日を失敗と判定したいわけではありません。数字が下がった理由は、コミットを開いて初めて分かりました。
残っていれば正しい、というわけでもない
誰も読み返していない文章も残ります。逆に、良い文章でも後の方針変更で消えることがあります。残存率だけを上げようとしても、品質が上がるとは限りません。
次もこの集計を使うなら、低い日から差分を読んでみます。最初の依頼が曖昧だったのか、書いている途中で考えが変わったのか。残った割合だけでは分からない、その先の事情を知りたいです。
2026-09-25 追記: 同じ 7 月のコミットを 2 か月後に数え直すと、残存率は 57.4% でした。消えた行の多くは、その後の書き直しで要らなくなった行です。