何を見つけたか
上限を超えて見送った提案は後回しにならず、そのまま捨てられる。 ラウンドを重ねても、1 回の実行で処理できる量は増えない。
具体例は rf751（PR #751）の 2 回目のテスト整備ラウンドである。統合後の 10 件のうち 5 件が「1 ラウンドの採用上限 5 件を超えた」で見送られた。見送った中には plugins/ndf/scripts/lib/models.py の model_flag / observed_model / parse_model_args の 3 つが入っている。この 3 件は次のラウンドで再提案されても「過去のラウンドで見送った項目のため対象外」として落ちる。
仕組みは次のとおりである。
- 上限を超えた分は
deferred_items へ入る（plugins/ndf/skills/cross-refactoring/scripts/refactor_lib/proposals.py:187 、refactor_lib/commands/apply.py:178 ）
- 次のラウンドは
deferred_items の全件を対象外として採否へ渡す（apply.py:227 → proposals.py:176 ）
- 提案担当へも「対象外」として渡る（
scripts/launch-cli.sh の collect_excluded_items ）
見送りには理由の違う 2 種類が混ざっている。 「重要度がしきい値未満」「適用で失敗した」は見送ってよい。「枠が足りなかった」は内容を判断した結果ではないのに、同じように扱われている。
テスト整備では、どれを切り捨てるかがほぼ名前の順で決まる。 テスト項目の並べ方は「合意したランタイムの数 → target → case 」（proposals.py:290 ）である。実測で上限を超えた 19 件はすべて 1 者だけの提案だったので、どれが残るかは target の辞書順で決まった。
実測（2026-09-18）
状態ファイルが残っている 3 実行（rf677 / rf751 / rf752）を集計した。
| 実行 |
ラウンド |
種類 |
統合後 |
採用 |
上限超過で見送り |
| rf677 |
R1 |
テスト |
11 |
5 |
6 |
|
R2 |
テスト |
4 |
4 |
0 |
|
R3 |
構造 |
5 |
5 |
0 |
|
R4 |
構造 |
6 |
5 |
1 |
|
R5 |
構造 |
7 |
5 |
1 |
| rf751 |
R1 |
テスト |
11 |
5 |
6 |
|
R2 |
テスト |
10 |
5 |
5 |
|
R3 |
構造 |
4 |
4 |
0 |
|
R4 |
構造 |
6 |
5 |
1 |
|
R5 |
構造 |
5 |
5 |
0 |
| rf752 |
R1 |
テスト |
7 |
3 |
2 |
| 種類 |
統合後 |
上限超過で見送り |
見送りの割合 |
上限に達したラウンド |
| テスト整備 |
43 |
19 |
44% |
5 回中 4 回 |
| 構造改善 |
33 |
3 |
9% |
6 回中 5 回 |
所要時間は実行の要約（~/.local/state/ndf/metrics/devbasex--ai-plugins/ ）から集計した。完了した 6 実行（rf683 / rf717 / rf746 / rf747 / rf749 / rf752）が対象である。
| 実行 |
終わり方 |
ラウンド数（テスト＋構造） |
所要 |
最終ゲート（cross-review） |
| rf683 |
上限で終了 |
2＋3 |
140 分 |
42 分 |
| rf747 |
上限で終了 |
2＋4 |
133 分 |
69 分 |
| rf717 |
上限で終了 |
2＋3 |
69 分 |
15 分 |
| rf746 |
上限で終了 |
1＋2 |
45 分 |
56 分 |
| rf749 |
上限で終了 |
1＋1 |
21 分 |
5 分 |
| rf752 |
収束 |
1＋1 |
15 分 |
— |
- 1 ラウンドの所要は中央値 16 分前後（テスト整備 15 分、構造改善 17 分）で、所要はほぼラウンドの数で決まる
- 6 実行のうち 5 実行が、提案が尽きる前に提案ラウンドの上限で終わっている。1 ラウンドの件数の上限と回数の上限が合わさって、「新しい提案が出なくなるまで回す」目的に届いていない
- 1 ラウンドの内訳は、提案が 33%（3 者を同時に動かし最も遅い者を待つ）、適用が 54%（1 者ずつ順番に動く）、テストと進行の処理が 13%
- 最終ゲートの cross-review が 5〜69 分を別に足しているが、この所要を見積もる記述はどこにも無い
方針（利用者の指示）
ラウンドを減らし、1 ラウンドで処理する件数を増やす。
- 枠が足りずに見送った提案は、捨てずに次のラウンドへ持ち越す。 見送りの記録を「理由があって見送ったもの」と「枠が足りなかったもの」に分け、対象外として渡すのは前者だけにする。持ち越した分は、次のラウンドの新しい提案より先に採否へ入れる
- 1 ラウンドの採用上限を上げ、テスト整備と構造改善で別の値にする。 案として構造改善 10 件、テスト整備 10 件を挙げる。実測で統合後の最大はテスト整備 11 件、構造改善 7 件で、上限 10 件ならほぼすべてを 1 ラウンドで扱える
- ラウンドの上限を下げる。 案として
--max-test-rounds を 2 から 1、--max-outer-rounds を 3 から 2 にする。持ち越しがあるので、回数を減らしても提案は失われない
- 最終ゲートの所要を目安として
SKILL.md に書く。 本体とは別に 5〜69 分かかることを、実行前に読めるようにする
具体的な値は設計で決める。そのときは下の「上げると困ること」との釣り合いを見る。
指針: 全ラウンドを 60 分以内に収める（利用者の指示）
1 回の cross-refactoring は、全ラウンドを合わせて最大 60 分以内に収める。 範囲はテスト整備ラウンドの開始から、最後の提案ラウンドの適用と検証が終わるまでである。最終ゲート（cross-review、または --workflow-step の全体テスト）はこの 60 分に含めず、SKILL.md に別の目安として書く（方針 4）。
いまはこの指針を満たしていない。完了した 6 実行のうち 60 分以内に収まったのは 3 実行だけである。
| 実行 |
ラウンド数 |
全ラウンドの所要 |
60 分以内か |
| rf752 |
2 |
15 分 |
収まる |
| rf749 |
2 |
21 分 |
収まる |
| rf746 |
3 |
45 分 |
収まる |
| rf717 |
5 |
69 分 |
超える |
| rf747 |
6 |
133 分 |
超える |
| rf683 |
5 |
140 分 |
超える |
1 ラウンドの所要は中央値 16 分前後、90 パーセンタイル 25〜27 分、最大 35 分だった。ラウンドの数を減らすだけでは足りない。 3 ラウンドでも、90 パーセンタイルの長さが続けば 75〜80 分になる。そこで次の 2 つで 60 分を守る。
- ラウンドの数の既定を、60 分に収まる数から決める。 方針 3 の案（テスト整備 1 回＋提案 2 回の 3 ラウンド）なら、1 ラウンドあたり 20 分が目安になる
- 経過時間で次のラウンドを始めるか決める。 残り時間が 1 ラウンドの見込み（例: 20 分）より短ければ、次のラウンドを始めずに最終ゲートへ進む。終わり方は
max_outer_rounds と区別して報告に残す（例: time_budget ）。持ち越した提案は改修計画に残り、次の実行で拾える
1 ラウンドの件数を増やすと適用が伸びるため、#755 で適用を並べて動かし、1 ラウンドを 20 分に収める。60 分の値を引数で変えられるようにするか（例: --time-budget-min ）は設計で決める。
上げると困ること
直さないと何が起きるか
- テスト整備で 4 割強の提案が、内容ではなく名前の順で捨てられる。現状固定テストが足りないまま構造改善へ進む
- 提案が残っていても、回数の上限で打ち切られる。1 回の実行は 1〜2 時間（最終ゲートを含めると最大 3 時間強）かかるのに、改善が終わらない
関連
何を見つけたか
上限を超えて見送った提案は後回しにならず、そのまま捨てられる。 ラウンドを重ねても、1 回の実行で処理できる量は増えない。
具体例は rf751（PR #751）の 2 回目のテスト整備ラウンドである。統合後の 10 件のうち 5 件が「1 ラウンドの採用上限 5 件を超えた」で見送られた。見送った中には
plugins/ndf/scripts/lib/models.pyのmodel_flag/observed_model/parse_model_argsの 3 つが入っている。この 3 件は次のラウンドで再提案されても「過去のラウンドで見送った項目のため対象外」として落ちる。仕組みは次のとおりである。
deferred_itemsへ入る（plugins/ndf/skills/cross-refactoring/scripts/refactor_lib/proposals.py:187、refactor_lib/commands/apply.py:178）deferred_itemsの全件を対象外として採否へ渡す（apply.py:227→proposals.py:176）scripts/launch-cli.shのcollect_excluded_items）見送りには理由の違う 2 種類が混ざっている。 「重要度がしきい値未満」「適用で失敗した」は見送ってよい。「枠が足りなかった」は内容を判断した結果ではないのに、同じように扱われている。
テスト整備では、どれを切り捨てるかがほぼ名前の順で決まる。 テスト項目の並べ方は「合意したランタイムの数 →
target→case」（proposals.py:290）である。実測で上限を超えた 19 件はすべて 1 者だけの提案だったので、どれが残るかはtargetの辞書順で決まった。実測（2026-09-18）
状態ファイルが残っている 3 実行（rf677 / rf751 / rf752）を集計した。
所要時間は実行の要約（
~/.local/state/ndf/metrics/devbasex--ai-plugins/）から集計した。完了した 6 実行（rf683 / rf717 / rf746 / rf747 / rf749 / rf752）が対象である。方針（利用者の指示）
ラウンドを減らし、1 ラウンドで処理する件数を増やす。
--max-test-roundsを 2 から 1、--max-outer-roundsを 3 から 2 にする。持ち越しがあるので、回数を減らしても提案は失われないSKILL.mdに書く。 本体とは別に 5〜69 分かかることを、実行前に読めるようにする具体的な値は設計で決める。そのときは下の「上げると困ること」との釣り合いを見る。
指針: 全ラウンドを 60 分以内に収める（利用者の指示）
1 回の cross-refactoring は、全ラウンドを合わせて最大 60 分以内に収める。 範囲はテスト整備ラウンドの開始から、最後の提案ラウンドの適用と検証が終わるまでである。最終ゲート（cross-review、または
--workflow-stepの全体テスト）はこの 60 分に含めず、SKILL.mdに別の目安として書く（方針 4）。いまはこの指針を満たしていない。完了した 6 実行のうち 60 分以内に収まったのは 3 実行だけである。
1 ラウンドの所要は中央値 16 分前後、90 パーセンタイル 25〜27 分、最大 35 分だった。ラウンドの数を減らすだけでは足りない。 3 ラウンドでも、90 パーセンタイルの長さが続けば 75〜80 分になる。そこで次の 2 つで 60 分を守る。
max_outer_roundsと区別して報告に残す（例:time_budget）。持ち越した提案は改修計画に残り、次の実行で拾える1 ラウンドの件数を増やすと適用が伸びるため、#755 で適用を並べて動かし、1 ラウンドを 20 分に収める。60 分の値を引数で変えられるようにするか（例:
--time-budget-min）は設計で決める。上げると困ること
SKILL.mdの設計方針「取り消しの単位」）。rf677 の R4 では群 1 つを取り消して 4 件が一緒に消えた。取り消された件数は rf677 で 24 件中 4 件、rf751 で 24 件中 7 件である直さないと何が起きるか
関連
CLAUDE.mdが--max-outer-roundsの既定を 4 と書いている。この課題で既定を変えるなら、あわせて直す