成果を残存で測る（Measuring Outcomes by What Survives）

「受け入れたか」は成果の証拠として弱い。受容は受け取った瞬間の判断であり、そこで測るのをやめると、後から消した変更が成功として数えられ続ける。コミットの時点で残っているかを数えると、その取り違えが閉じる。

問題

エージェントの出力が良かったかを、我々は受け入れたかどうかで数えている。差分を採ったら成功、捨てたら失敗である。数えやすく、操作の直後に確定するため、指標としては便利である。

ところが受容は受け取った瞬間の判断にすぎない。その瞬間に手元にある材料は、差分そのものと、それを読んだ数十秒の理解だけである。動かしていないし、隣の呼び出し元も見ていない。受け入れた変更が、10分後にどうなっているかは、受容の記録に何も残らない。 書き直したのか、消したのか、そのまま通ったのか — 区別が付かない。

すると2種類の間違いが同時に起きる。採ってすぐ書き直した変更が、成功として数え続けられる。 逆に、読んだときは不安で採らなかったが、実は正しかった提案は、失敗として記録されたまま二度と見直されない。どちらも指標の側が受け取りの瞬間で止まっているために生じる。

さらに悪いのは、受容が受け取り手の側から操作できる量であることである。短く、狭く、既存の書き方をなぞった差分は読むのが速く、採られやすい。踏み込んだ変更は読むのに時間がかかり、採られにくい。受容率を上げるのに、良い変更を出す必要はない。 出す側にも、渡し方を調整する我々の側にも、この抜け道は開いている。

コンテキスト

適用する条件:

• 同じ種類の仕事を繰り返している — 1回の出来ではなく傾向を見たいとき。残存は数えるのに時間の経過を要するため、繰り返しがないと母数が溜まらない
• 渡し方やモデルの選択を変えて比べたい — 変更前と変更後で何が良くなったかを言いたいとき
• 成果がコミットという形で残る — 数える対象が版管理に載っていること

適用しないケース:

• 1回きりの仕事。 残存は数えるまでに時間がかかる。今この差分を採るかどうかの判断には間に合わない
• 成果がコミットに載らないとき。調べ物の結論、レビューの指摘、設計の判断は、残存を数える対象を持たない
• 試行そのものが目的のとき。捨てる前提で書かせた探索的な実装は、消えることが失敗ではない

隣接パターンとの境界:

• 成果物の差分レビューと段階的採用 — 差分をどう受け取るかが同パターン、受け取った後に何を数えるかが本パターン。時間軸で隣り合っており、同パターンが刻んで採った差分にも本パターンの問いは残る
• 検証対象の明示 — 事前に「何を基準に直ったと言うか」を契約として渡すのが同パターン。本パターンは事後に何を数えるかであり、契約の有無とは独立に成立する
• 改訂を測って採る — 測った結果を使って命令の改訂を採否するのが同パターン。本パターンは何を測るかの側であり、同パターンの入力になる

解決

なぜ効くのか。受容と残存は、判定する主体が違う。

受容を決めるのは、差分を読んでいる最中の我々である。材料は差分と、それを読んだ理解だけである。この判断は、出す側から近い — 読みやすく書けば通りやすくなる。指標としての受容は、この近さのぶんだけ操作の余地を持つ。

残存を決めるのは、その後に働いた我々である。動かしてみて落ちた、隣の呼び出し元と噛み合わなかった、レビューで指摘された、あるいは単に読み返して要らないと分かった。どれも受容の時点では手元に無かった材料である。残存は、後から入ってきた材料による判定であり、出す側から遠い。 遠いから、なぞって通すことができない。

つまり本パターンがしているのは、指標を、操作しにくい側へ動かすことである。受容を捨てるのではない。受容は依然として速く、その場で使える。ただしそれだけを見ていると、受容率が上がったのに何も良くなっていないという状態を、指標の側から検出できない。残存を並べて置くと、2つが逆を向いたときに気づける。

⚠ 本カタログの判断であることを明記する。 「受容より残存を優先せよ」という優劣づけは、確認した一次資料のどこにも書かれていない — 素材は両方を品質の指標として並置しているだけである（具体例節）。優劣づけは本カタログが引いた判断であり、公式 ではない。 一次資料から引けるのは、指標の定義と実測、そして「durable な結果に到達したか」を評価の目標に据える枠組みまでである。

数え方は1つに絞る。コミットの時点で残っているかだけを数える。 版管理はどこにでもあり、後から数え直せる。「受け入れた瞬間から何分後」という時間の窓で数える方法もあるが、それには編集操作そのものを記録している必要があり、道具の側の計測に依存する（具体例節に実例がある）。依存しない側だけで、本パターンは成立する。

トレードオフ

利点

• 指標を、なぞって通せない側へ動かせる。 読みやすく書けば通る受容と違い、残存は後から入ってきた材料で決まる。渡し方を変えて比べるとき、この差が効く
• 受容と残存が逆を向いたときに気づける。 片方だけを見ていると、この状態が「良くなった」に見える。並べて置くことが検出そのものである

代償

• 遅い。 残存は時間が経つまで確定しない。今この差分を採るかどうかの判断には間に合わず、傾向を見るための指標にしかならない
• 残ったことは、正しいことではない。 誰も読み返さなかった変更も残る。残存は「後から消されなかった」ことしか言っておらず、品質の証明ではない。残存率を目標にすれば、今度はそれが操作の対象になる

GitHub Copilot での具体例

VS Code — 3層の指標で報告された実測

出典: MAI-Code-1-Flash: early results from real developer workflows（取得日: 2026-07-30）公式。面は VS Code である — 集計の対象は VS Code Copilot Chat で各モデルを自分で選んだ利用者であり、github.com・Copilot CLI・cloud agent の記述は無い。

この数値が語る範囲

baseline はこの記事のベンダー自身の新モデルである。 つまり自社モデルを 0% に置いた自社比較であり、絶対値は公開されていない。数値はすべて baseline 比の相対値であり、median（中央値）であって平均ではない。実測期間は 2026-06-02 から 2026-07-24 である。

同記事は品質を3つの指標で測っている 公式:

指標	定義
受容率（accept rate）	利用者が受け入れた、AI 生成の提案の割合
残存率（code survival rate）	AI が生成したコードのうち、能動編集 10 分後に残っている割合
コミット時残存率（commit survival rate）	AI が生成したコードのうち、git のコミット時点で残っている割合

⚠ 10 分の時計は「受け入れてから」ではない。 原文の定義は能動編集（active editing）10 分後であり、経過時間ではなく編集操作の量で区切っている。この層は編集操作の記録を要するため、版管理だけでは再現できない。 本パターンの本体をコミット時点に置いているのはこのためである。

同記事の測定の枠組みそのものも 公式 として引ける — 見ているのは生成コードの品質と、利用者がどれだけ効率よく durable な結果に到達したかである。「durable（もちのよい）結果」を目標に据える言い方は、記事自身のものである。

受容と残存が逆を向いた行が、同じ表に在る — Kimi K2.7 Code は受容率が baseline より 6% 低い一方、残存率は 4% 高く、コミット時残存率は 6% 高い。

⚠ 記事はこの行を無評価で置いてはいない。 受容率が下がっているにもかかわらず、この行を含む2モデルを品質の面で優位と判定している（消費が多いことを代償として併記したうえで）公式。つまり記事自身が、この行の総合判定において受容率より残存率を重く見た読みを採っている。⚠ ただしそれは1つの行についての総合判定であって、「指標として残存が受容に優る」という一般の順位づけではない。 記事はその一般化を書いておらず、逆を向いた理由（因果）にも触れていない。一般化は本カタログの判断である。

⚠ 同記事には母集団の異なる第2の表がある（利用者が自分で選んだ集計ではなく、モデルを自動で割り当てた条件での比較）。指標も比較基準も違うため、2つの表の数値を混ぜて引いてはならない — 同じモデルの消費が、片方では baseline より少なく、もう片方では多く見える箇所がある。本ページが引いたのは第1の表だけである。

対向側 — 残存を数える記述は見つからなかった

Anthropic 側の一次資料7件の生 HTML を全文取得して検索したが、成果物の残存を数える指標は 0 件だった（取得日はいずれも 2026-07-30）。当たった資料は Claude Code analytics API のリファレンス、agentic coding の展開についての記事、Claude Code の実利用の研究、code review の記事、ソフトウェア開発への影響の経済指標、エージェントの自律性の測定、Claude Code のベストプラクティスである。検索語は acceptance rate / accept / retain / retention / survive / revert / commit / still、および stem として surviv である。

⚠ 0 件なのは残存の側だけである。受容の側は在る — analytics API はツール別に受け入れ／却下のカウントと受容率の算式を持つ 公式。またコミット数・PR 数・テストの通過を成果の硬い証拠として使う記述も在る 公式。無いのは、受容した差分がその後どうなったかを追う定義である。retain のヒットはデータの保持期間や計画の保持であって、成果物の残存ではない。

「無い」のは記述であって、機能ではない。 確認したのはこの7件の範囲であり、他の資料や製品面に存在する可能性は残る。

実践に落とすと

道具が3層を測ってくれるのは VS Code 面の集計の話であり、手元で同じことをするには版管理を使う。コミットの時点で残っているかだけなら、道具を問わず数えられる — エージェントが出した差分の量と、実際にコミットに載った差分の量を、ブランチ単位で並べる。受け入れた直後の量ではなく、コミットの時点の量を数えるところが本パターンである。

別名

呼称	出典
Commit survival rate / Code survival rate	一次 — VS Code 面のブログが指標に与えている名（出典は具体例節）。⚠ 指標の名であって、本パターン（実践）の名ではない
Accept rate	一次 — 同じ資料が対になる指標に与えている名。本パターンが置き換えを説くのはこの指標に対してである（出典は具体例節）
成果を残存で測る / Measuring Outcomes by What Survives	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

指標の名を実践の名として使わない。commit survival rate は測った量の名であり、「受け取りの瞬間で測るのをやめて、時間が経った後を数える」という測り方の選択には名前が付いていない。量の名を選択の名に流用すると、その量を計算してくれる道具が無い環境では、選択そのものが見落とされる。

関連

• 成果物の差分レビューと段階的採用 — 時間軸で隣り合う。同パターンが扱うのは差分を採る操作、本パターンが扱うのは採った後に残った量である。刻んで採っても本パターンの問いは残る
• 検証対象の明示 — 事前の契約が同パターン、事後の計数が本パターン。契約を渡していても、残ったかどうかは別に数える必要がある
• 改訂を測って採る — 本パターンは何を測るか、同パターンは測った結果で何を採否するかである。本パターンの出力が同パターンの入力になる
• 由来を分けて記録する — 本ページ自身がこの型で書かれている。 3指標の定義と数値は 公式、「受容より残存を優先せよ」は本カタログの判断であり、同じラベルの下に置いていない
• 委譲の損益分岐 — 同じ資料の同じ表が、消費の側でも使われている。効率の指標が「1ターンあたりの生成量」と「コミット到達までのターン数」に分かれる点は同パターンで扱う
• まず次に読むなら 成果物の差分レビューと段階的採用 — 何を数えるかを決めたら、次は受け取り方そのものを見る番である