cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202

結論（先に）

1. 固定でかかる時間は差分の大きさ D にほぼ比例しない。テストの所要 T だけで決まる。 予算から使えた時間を引いた値（B − A）は、
   x̂ + (4.7 + 0.43·x̂) + v̂ + 2F で、中央値の絶対誤差 1.1 分で再現できる（63 回。v̂ と F はその回の上限の表の値を使ったので、実質は提案と改修計画の P の当てはまり）。
   x̂ = 着手前のテストの所要、v̂ = 最終ゲートの確かめ（CI に任せるなら CI の壁時計 c、手元なら全体テスト w）、F = 修正 1 回の見込み（配分の fix）。

2. 提案件数は D とほとんど相関しない（Spearman ρ = 0.21、p = 0.10。変更ファイル数とは ρ = 0.30、p = 0.02）。
   D が 300 行未満で 14 件前後、それ以上ではどの大きさでも 19〜23 件で頭打ちになる。
   採用件数を決めているのは使えた時間 A である（計画で採った件数と A の ρ = 0.84）。予算で頭打ちになったのは 64 回のうち 49 回。

3. 項目 1 件の実際の所要は約 3 分（計画の後の壁時計 ÷ 検証した項目は 8 回の中央値 159 秒。63 回の使えた時間 ÷ 計画で採った件数は 2.3 分、÷ 最終の採用件数は 3.7 分）。
   一方で、着手前のテストを範囲で走らせる回（スプリント s2086 #2092 以降の scope）は、計画が使う 1 件の見積りが 9.6〜12.9 分に膨らんでいる。
   検証の見積りに着手前の範囲テストの全体の実測（約 500 秒）を 1 件ずつ載せているためで（commands/plan.py の measured_verify）、
   実測の検証は 1 件 5〜50 秒である。式で予算を広げても、この見積りを直さないと scope の回では見送りがほとんど解消しない。

4. 推奨の式（候補 1）:

   想定最大時間 B = 固定分(T) + N(D) × u
     固定分(T) = x̂ + P + v̂ + 2F          P = 4.7 + 0.43·x̂（提案と改修計画。分）
     N(D)    = clamp(4·log10(D), 6, 16)   D = 範囲に入るプロダクションコードの変更行数（追加 + 削除）
     u       = 3 分（項目 1 件の実測）
     下限 = 固定分 + 3u、上限 = 固定分 + 16u（かつ 120 分）
   

   今の ai-plugins（x̂ 8.5 分・c 15.4 分・2F 3.5 分・D 1,000 行）では 固定分 35.8 分 + 12 件 × 3 分 = 約 72 分。
   cross-refactoring: 最終ゲートの CI の待ち（予算 30 分のうち 13.4 分）を想定最大時間の勘定から外し、別の上限で待つ #2203（最終ゲートの CI の待ちを予算から外す）が入れば約 57 分になる。

5. 過去 63 回に当てると、予算の理由の見送り 712 件のうち 候補 1 で 456 件（64%）、候補 2（N を提案件数にする）で 570 件（80%） が入る計算になる。
   ただし スプリント s2086 #2092 以降の scope の回では、見積りが膨らんでいるため 136 件のうち 32 件しか入らない（3. の見積りを直す前提で初めて効く）。

1. データと前処理

差分の大きさ D の取り方。 PR の今の差分はリファクタリングのコミットを含むため使わない。コメントの「着手前のテストの結果 … HEAD 」
（64 件）を着手前の HEAD とし、マージコミットの第 1 親（未マージの #2363 は origin/develop）との merge-base からの差分を取った。
HEAD の無い 44 件は、PR の commits で最初のリファクタリングのコミット（Test: … — / Refactor: <手法> — / 現状固定）の直前を HEAD とした。

時間の内訳の逆算。 コメントの「時間の上限」の表から、実装（timeline.py・budget.py）の式を逆にたどった。

• 開始 = H − B（H = 想定最大時間の終わり）
• バッファ R = (H − 直しの試行の打ち切り) + F。fix_end = 開始 + B − 危険フラグ − 最終ゲート − final_fix と fix = final_fix（同じ配分の値）による
• 最終ゲートの確かめ v（危険フラグ + 最終ゲートの全体テスト） = (H − fix_end) − F
• 計画の時点の経過 E = B − A − R（available_minutes = B − E − R）、提案と改修計画 P = E − x

2. 固定でかかる時間の内訳

2.1 全体（63 回、分）

配分の履歴（8 回）の実測でも、提案は 197〜362 秒、改修計画は 62〜94 秒、指標の測定は 1〜47 秒で、P は 4.5〜7.5 分に収まる。
P が x と弱く相関するのは、着手前のテストが長い回ほど提案の CLI が並行して遅くなるか、提案の枠（0.20·B）の取り方の違いによると見られる（確かめていない）。

2.2 期ごと（中央値、分）

• 固定分は 22.5 → 35 分へ伸びてきた。伸びたのは x（テストの増加）と v（CI の壁時計 c が 296 → 922 秒）で、P はほぼ同じ
• B = 30 分のままでは、固定分が 26 分を越えた スプリント m744 #1745 以降に使えた時間が 0.3〜8 分になる（スプリント m744 #1745・スプリント m653 #1780・スプリント m1290 #1799・スプリント m1743 #1825 は 1 分未満）

2.3 予算の外でかかっている時間（データの注意）

• 着手前のテストの打ち切りと打ち直し。 配分の履歴の init_test では、上限 max(0.10·B, 3·s) が B = 30 のとき 180 秒になり、
  スプリント m2087 #2152・スプリント m1426 #2247・スプリント l20261031-2 #2250・スプリント m26-1 #2268・スプリント l20261031-3 #2283・スプリント l20261031-5 #2312・スプリント m26-2 #2318 で打ち切り（180 秒、続いて 450〜540 秒）→ 打ち直しが起きている。
  スプリント m1426 #2247 は 180 + 540 + 653 秒。この時間は記録上の開始より前で、B にも A にも現れない
• 最終ゲートの確かめは見込みより長い。 履歴の reserve.final_whole_test は見込み 616〜922 秒に対し実測 687〜930 秒（7 回のうち 5 回が見込みを超過。スプリント m2087 #2152・スプリント m2169 #2178 は 616 秒の見込みに 930 秒）。v̂ は c の直近の実測の最大を使うのが安全

3. 提案件数・採用件数と差分の大きさ

3.1 相関（時間の記録がある 64 回、Spearman）

• 「頭打ちあり」= 見送りの理由に budget がある回（49 回、見送り計 712 件）
• ラウンド制の 44 回（Add: 運用モード operation を新設する（#423） #448〜mcp-serena: 言語サーバの設定・検査・誘導の hook を足し、Claude Code と Codex で定義・参照・診断を使えるようにする（#818） #972）でも提案件数 × D は ρ = +0.18（p = 0.26）で、同じ傾向
• 提案件数は「提案件数 = 項目の数 + 見送りの行 − 重複（duplicate）− 実装の締め切りで止まった項目（not_done、項目と二重に載る）」

3.2 D の区間ごと

提案は 3 者（claude / codex / kiro）が出し、重複を除くと 1 回 14〜23 件に収まる（コード上の上限 90 件には届かない）。
D が効くのは 300 行未満とそれ以上の境くらいで、それより大きくても提案は増えない。 採用件数は D ではなく A で決まっている。

3.3 頭打ちにならなかった 15 回

#1391・#1410・#1445・#1452・#1469・#1467・#1506・#1520・#1521・#1573・#1581・#1701・#1732・#2133（B = 60〜90）と #951。
計画で採った件数の中央値 18、最終の採用 11、提案 18。提案のほぼ全件が入るのに要った使えた時間は 30〜49 分（#951 を除く）だった。

4. 項目 1 件あたりの所要

4.1 実測（配分の履歴 8 回、秒）

手法別（件数, 1 件の秒）: extract_method 34 件 53 秒、replace_with_lookup_table 3 件 118 秒、introduce_named_constant 3 件 119 秒、
consolidate_duplication 2 件 338 秒、introduce_parameter_object 1 件 237 秒、その他 1〜2 件で 27〜81 秒。

4.2 コメントからの換算（63 回）

u = 3 分を 1 件の所要とする（計画で採った 1 件あたり 2.3〜2.7 分に、修正と待ちの余裕を少し足した値）。

4.3 計画が使う見積り（見送った行の「見積り X 分」）

commands/plan.py は item["estimate"]["verify"] = max(配分の verify, measured_verify) とし、budget.measured_verify_minutes は
着手前の範囲テスト全体の実測（mode が scope のとき）を返す。範囲テストが 500 秒なら 1 件ごとに 8.3 分の検証が載る。
実測の検証は 1 件 5〜50 秒（4.1）なので、この回たちでは見積りが実測の 3〜5 倍になり、予算の見送りを増やしている
（例: #2363 は A = 16.3 分で採用 3・時間の見送り 16、見積りは 9.4〜15.2 分）。

5. 式の候補

記号（分）: x̂ = 着手前のテストの所要の見込み（今の s。範囲テストの履歴、無ければ w）、v̂ = 最終ゲートの確かめの見込み
（CI に任せる戦略は c、手元は w。直近の実測が大きければそれ）、F = 配分の fix、D = 範囲に入るプロダクションコードの変更行数。

候補 1（推奨）: 着手前に D と T だけで決める

固定分(T) = x̂ + P + v̂ + 2F,   P = 4.7 + 0.43·x̂
N(D)     = clamp(4·log10(D), 6, 16)      # D=100 → 8、300 → 9.9、1,000 → 12、3,000 → 13.9、10,000 以上 → 16
B        = 固定分(T) + N(D) × u,  u = 3
下限      = 固定分(T) + 3u（3 件は必ず入る）
上限      = min(固定分(T) + 16u, 120)

• 固定分は B に依らない（今の提案の枠 0.20·B・改修計画の枠 0.10·B・余裕 0.05·B は、B が固定分から決まるので循環しない形に置き換える必要がある）
• N(D) は「提案のうち採れる見込みの件数」。提案件数（14〜23 件）の約 6 割で、最終の採用率 0.62 とも合う
• 利用者が「実装に使える時間」を渡す cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202 の提案とは、N(D) × u をその値で置き換えれば同じ形になる

候補 2: 提案の後に N を実際の提案件数で決め直す

B（着手時）  = 候補 1 と同じ
B（計画時）  = 固定分(T) + clamp(重複を除いた提案件数, 3, 20) × u   # 改修計画の時点で上書き

D と提案件数の相関が弱い（ρ = 0.2〜0.3）ため、計画の時点で分かる提案件数を使うほうが当たる。そのかわり B は計画の時点まで確定しない
（リファクタリング計画に「着手時の見込み」と「計画時の確定値」の 2 つを載せることになる）。

6. 過去の各回への試算

方法: その回の実際の固定分（E + R）はそのまま、式の B から使えた時間 A' = B' − (E + R) を出し、A' − A の余りへ、
その回の時間で見送った項目をコメントの順（順位の順）に budget.select と同じく「入るものは入れ、入らないものは飛ばす」で詰めた。
見積りはコメントの「見積り X 分」（計画の単位）をそのまま使う。

期ごと（入る件数 / その期の予算の見送り、B の中央値）:

• スプリント m744 #1745〜スプリント s2065 #2070 は候補 1 でほぼ解消する（スプリント m744 #1745・スプリント m653 #1780・スプリント m1290 #1799・スプリント m1793 #1801・スプリント m1743 #1825 は見送り 12〜23 件がすべて入る）
• スプリント s2086 #2092 以降は予算を広げても入らない。 x が長い 8 回は、式の B（54〜79 分）が実際の B（52〜90 分）とあまり変わらず、増えた数分に 1 件 10 分前後の見積りが入らない（入る 32 件のうち 31 件は x が短い スプリント m2169 #2178・スプリント m2170 #2192・スプリント m2171 #2209）。4.3 の見積りを
  「項目の範囲テストの実測（配分の verify）」へ直すことが式と同じくらい効く
• 候補 1 が実際より B を小さくする 19 回は、B = 60〜90 で頭打ちにならなかった回（ミッション m1337 #1391〜スプリント m1385 #1732・スプリント m1914 #2133）。使えた時間の換算（2.3 分/件）で
  1〜3 件ずつ（スプリント m1560 #1573 は約 10 件、スプリント m1914 #2133 は約 5 件）採れなくなる見込み。候補 2 ではこの損失は 3 回・各 1〜5 件に減る

6.1 各回の値

列: x・P・v・2F は分。D は範囲のコード行（ファイル数）。式の列は「B（分）/ 入る予算の見送りの件数」。

7. データの欠け・外れ値・仮定

• 件数の差。 cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202 は 103 回と書くが、取得できた計画のコメントは 108 件（2026-09-06〜11-01）。うち時間の記録があるのは 64 件で、
  cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202 の表の 54 回（10.17.8〜）とも数え方が違う。cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202 の回数は版で区切っており、本分析は PR 番号で区切った
• cross-refactoring を想定最大時間に収める 1 回の計画実行へ改める（#933 実装） #951 は内訳なし。 時間の上限の表が旧形式（final_fix の行が無い）で R を逆算できない
• 逆算の仮定。 R = (H − fix_end) + F は「検証の修正の枠 = 最終ゲートの修正の枠 = 配分の fix」（budget.reserve）に依る。
  floor で上げた回（検査のプランの構造改善が既定の予算で下限に届かず、33 行の差分でも refactor が落ちて abort へ進む #2047 の仕組み）は、コメントの B が上げた後の値なので、上げる前の B は分からない
• D の外れ値。 ミッション m1142b #1255（35,786 行）・ミッション m1323 #1342（16,090 行）・ミッション m1142c #1300（11,430 行）・cross-refactoring を想定最大時間に収める 1 回の計画実行へ改める（#933 実装） #951（7,458 行）は生成物・移動を含む大きな PR。
  相関は Spearman（順位）で見たので影響は小さい。N(D) は 16 件で頭打ちにしてある
• D の着手前の HEAD の推定。 時間の記録が無い 44 件は commits の題から推定した（リファクタリングの題の形が違う回は過大になりうる）。主な分析（64 件）はコメントの HEAD を使った
• 差分の範囲。 「対象範囲」の項目をパスの前方一致で判定した。テストの判定は名前の規則によるため、tests/ の外の検査用スクリプトはプロダクションコードに数えている
• 1 件の所要の標本が少ない。 配分の履歴の実行の行は 8 回（スプリント m2087 #2152〜スプリント lroot-2 #2363、実装担当はすべて claude）。kinds の秒は CLI の申告に近い値で、
  手順の壁時計（implement の 920〜1,865 秒）より小さい。u = 3 分は壁時計側（4.1 の最下行と 4.2）から取った
• 試算の仮定。 「入る件数」は、増えた時間で計画が採れたはずの件数であり、採った項目が最後まで採用される保証ではない（最終の採用率は 0.62）。
  実装担当の並列・修正の回数・最終ゲートの失敗は考えていない。採り直し（readopt）で実際に後から採られた分も差し引いていない
• ai-plugins だけのデータ。 他のリポジトリ（cross-refactoring: 既定の予算を固定の分数でなく、テストの所要とコード量から決める #2202 の novel など）の x・c は大きく違う。式は T を入力に持つので形はそのまま使えるが、
  P = 4.7 + 0.43·x̂ の係数は ai-plugins の当てはめ
• 予算の外の時間。 着手前のテストの打ち切りと打ち直し（2.3）は記録上の開始より前で、本分析の固定分に入っていない