Parsimony：AI改修量と成功率の読み方

整数合計の例から、変更の広さを見る

整数リストの合計を、ループとPython標準の関数sumで書いてみます。ソースコードを公開しているParsimonyは、修正差分の構文要素を数え、テストの成否に加えて変更の広さを見る指標を提示します。

以下は公式READMEにある、ループからsumへの置換前後の作例です[1]。

# 変更前: ループ処理による逐次加算
def total(items):
    result = 0
    for item in items:
        result = result + item
    return result

# 変更後: 組み込み関数sumによる集計
def total(items):
    return sum(items)

置換前後の返り値が同等になる前提は、処理中に変わらない通常の組み込みリストに、厳密に組み込み型intの要素だけが入ることです[2]。このコードは公式READMEの作例で、ここでは置換条件を考えるための例として扱います。

仮にどちらも同じ要件のテストを通ったとしても、テスト合格だけでは変更の広さが分かりません。Parsimonyは前後の構文要素の増減を数え、修正規模を表します[3]。可読性や設計品質は別に確認する項目です[4]。

成功判定に、変更量の指標を加える

Hacker Newsのプロジェクト紹介枠「Show HN」で、Parsimonyは日本時間2026年10月14日4時50分に紹介されました[5]。トークンはAIが文章を処理する基本単位です。投稿者は、解決率やトークン消費、費用の比較だけでは過剰なコード追加を把握しにくいと説明しています。その追加が長期保守の問題になる、という投稿者の指摘です[6]。

共通課題で性能を比べる評価をベンチマークと呼びます。SWE-benchはGitHubの実際の課題を使い、修正すべきテストの合格と、既存テストの合格維持を確認します[7]。Parsimonyはその公表済みの成功判定を利用し、自身の処理ではプログラムやテストを再実行せずに変更量を測ります[8]。成功率と改修量は、役割の異なる指標です。

利用者は、同じ課題の成功例でも、計測対象内の純増減と変更総量を手掛かりに修正の広がりを比較できます。

構文単位を数え、純増減と変更総量を分ける

Parsimonyは、プログラムを動かさずに構造を調べる静的解析で変更量を算出します。構文木（AST）は、文や式などの関係を木構造で表したものです。

base_commit（修正前の版）からファイルを取得し、メモリ上で修正パッチを適用して、前後の構文木を解析して単位列の差分を求めます[9]。

計数の単位であるcoding unitは、文、式、呼び出し、比較、変数や関数の名前、リテラル（コードに直接書いた値）などです。Pythonではブロック終端ごとにEndBlockを1つ加え、入れ子構造の変化やブロック間の移動も反映します[10]。

coding unitsと行数（LOC）は別の尺度です。1行に詰めたコードも同じ規則で数えます。Parsimonyの計数では、コメント、書式、句読記号、名前の長さを単位に含めません。全ASTノード差分は構造診断値として扱い、coding unitsとは区別されます[11]。

差分の集計では、追加数から削除数を引いた値を純変更単位（net_units）、追加数と削除数の合計値を変更総量（churn）と定義します。公式READMEの作例では、ループからsumへの置換を削除13単位、追加3単位と計数しています。純変更は−10単位、変更総量は計算上16単位となります[12]。13と3は、削除・追加された差分の単位数です。

例えば100単位を削除して100単位を追加した場合、純変更は0ですが変更総量は200となります。差引がゼロでも変更総量が大きい状況を表す仮想例です。

修正パッチの例	削除（deleted）	追加（added）	純変更（net）	変更総量（churn）	算出の意味
公式作例（loopからsumへの置換）	13 単位	3 単位	−10 単位	16 単位	ループ構文の解消による純減
説明用：100削除・100追加	100 単位	100 単位	0 単位	200 単位	差引ゼロでも変更総量は大

単位列の差分は、前後を変換する追加・削除の最少手順から求めます。

Parsimonyは、編集数が500を超える大規模な書き換えで、未変更行を基準点にする行アンカー近似へ切り替えます。近似を使ったファイルの一覧をapproximate_filesに記録します。行アンカー近似は変更総量を過大に見積もる可能性があるため、単位の対応づけに近似が含まれうる点に留意が必要です[13]。

Web順位は、どの試行の平均かを確認する

以下は2026年10月14日に確認した固定版の計測方法に基づく説明です。公開Webの数値は更新されるため、比較時には参照時点も記録します。

Webの平均と計測カバレッジ

Webサイトの主順位は、測定できた解決済み試行における純変更の平均値が小さい順に並びます。横には失敗を含む全計測試行の純変更平均値も表示されます[14]。

Solvedは元のベンチマークが公表する解決率です。評価対象の全試行数に対して、解決済みの試行数が占める割合を示します[15]。

Web集計の実装は、計測値が得られ、方式がfull_fileで、計測範囲外だけを変更した試行に該当しないものを平均の対象にします。full_fileは、前後のファイル全体を取得して解析する方式です。

元のベンチマークで解決済みとされた試行数と、計測件数の差は、取得・適用の失敗や解析不能のほか、修正がテストファイルなど除外範囲だけだった場合にも生じます。原因は個別記録で確認します。

WebのMeasured欄は、元のベンチマークで解決済みの試行のうち、計測対象に入った試行数を件数比で示します[15]。解決率とは別に、成功した試行の計測カバレッジを確認する値です。ParsimonyのWeb集計では、解析できないファイルの単位数を未計測（null）として扱い、平均から除外します[16]。計測された値の0と、未計測は区別する必要があります。

CLIの中央値と旧スコア

文字コマンドで操作するCLI版の順位表（リーダーボード）は、中央値を基準に整列します[17]。中央値はデータを順に並べた中央の値を基に求める統計量です。Webの平均とCLIの中央値は別々に読みます。また、過去の80/20スコアは、課題ごとに値の尺度をそろえた純変更80％と変更総量20％を合成した旧指標であり、現行Webの平均値とは異なります[18]。

共通課題と設定の条件

モデル比較では、同じ解決率でも解決できた課題の内訳が異なる場合があります。CLIの共通課題オプション（--shared）は全構成が解決・解析できた共通の課題だけを用いますが、平易な課題に偏る可能性があると公式の計測方法に記載されています。

DeepSWEもコード修正のベンチマークです。

Parsimony側のDeepSWE Python計測資料は、各モデルで公開パッチが入手できる最良スコアの構成（思考設定）を選ぶと説明しています。

思考設定は、モデルの推論の深さなどを指定する設定です。比較時には、この設定とエージェントの版も確認します。

Python計測は.pyの実装ファイルが対象です。示すのは計測範囲内の実装変更で、テストや文書、生成ファイルは対象外です[19]。言語ごとに構文単位の定義や課題集合が異なるため、単位数は同じ言語・課題集合のボード内で読みます。

なお、公開パッチがなかったモデルについて作者がサブスクリプションで実行した3〜10課題の記録は、薄色の円で表示され順位対象外とされています[20]。

仕様とテストを確認してから、レビューの手掛かりに使う

coding unitsは構文上の量を示す指標です。正しさ、可読性、設計品質、保守性は別に確認します[21]。必要な入力検証や共通化を加えるため、大きな変更になる場合もあります。

また公開データの比較では、モデル単体の差だけでなく実行環境の影響を考慮する必要があります。SWE-benchの記録でも、モデル、エージェント（課題に応じてコードを修正するプログラム）、思考設定は別項目です[22]。ハーネス（エージェントを動かす実行基盤）の版、試行回数、課題集合、解析器やPythonの版も、比較時に確認する条件として挙げられます。

以上の制約を踏まえ、本稿では実務でのAI生成コードの確認手順として、2段階の運用案を提案します。

第一段階では、開発者が要件仕様、入力契約（受け付ける型や値の条件）、テスト結果を確認します。第二段階では、開発者がテストを通った修正のうち、純変更が突出して大きいものや、純変更が小さくても変更総量が大きいものを選びます。

近似計測の印が付いた結果も含め、変更した処理を人が重点確認するための材料にする、という提案です。開発者は、必要な検証を追加した変更と目的外の書き換えを、実際の差分で見分けます。

この運用案の目的は、重点確認する差分を選ぶことです。安全性向上や工数削減の効果は、本稿では検証していません。開発者はまず要件の充足を確認し、その上で変更量をレビューの手掛かりとして参照します。