コード生成の評価でよく出てくるのは「一発で通った率」です。ベンチマークの数字としては扱いやすいのですが、実際の開発ではあまり使えません。通ったあとに人が直したのであれば、通ったこと自体にはあまり意味がないためです。
見たいのは、書かせたコードがそのまま残ったかどうかです。
修正生存率という測り方
修正生存率（MSR）は、AIの編集を経てもコードが通り続ける割合を見ます。一回で通らなければ、エラーを返して書き直させます。それを数回まで許したうえで、最終的に通ったかどうかを数えます。
人が手を入れる前の状態で測るのが要点で、「三回やり取りして通るなら実用」という現場の感覚に近い数字になります。
毎日回す
Aid-Onでは自社の言語Almideについて、31個のタスクを易しい順に三段階へ分けたタスクバンクを用意し、毎日走らせています（almide-dojo）。
毎日である必要があるのは、測る対象が両方とも動くからです。モデル側は勝手に更新されます。言語側もこちらが変えます。手応えでは、どちらが効いたのか分かりません。
計測の仕組み自体もAlmideで書いてあります。測る道具を測る対象の言語で書いておくと、言語が壊れたときに真っ先に気づけます。
何が判断できるようになるか
数字が毎日出ていると、変更の良し悪しをその日のうちに切り分けられます。
エラーメッセージの文面を変えた。AGENTS.mdに一項目足した。構文をひとつ削った。どれも「良くなった気がする」で終わりがちな変更ですが、割合が動けば残し、動かなければ戻せます。効かなかった手引きを消せるのは、数字があるからです。
枠組みの中での置きどころ
NIST AI RMFで最も詰まるのはMEASUREだと別の記事に書きました。精度は測れても、AIに任せた結果が良かったのかを測る物差しが手元にないためです。
修正生存率は、その空白を埋める一例になります。コード生成に限った話ではありません。「AIの出力が、人の手直しをどれだけ必要としたか」は、たいていの用途で測れます。要約でも分類でも、直された割合は記録から拾えます。
自社で測るなら
必要なのは三つだけです。同じ条件で繰り返せるタスクの一覧、通ったかどうかを自動で判定する手段、そして毎日走らせる仕組み。最初は10件程度で構いません。
測る仕組みは、運用が始まってから足すのが難しいものです。何を残すかを決めるのは、導入の前になります。
