3 層の初回の測定で supervisor が割る候補（実作業の中央値 296k・最大充填 787k）、worker の 24 件中 8 件が実作業 < 固定費

[takemi-ohama]

何を見つけたか

v10.15.0 のまとまり（8 課題、conductor のセッション 1 つ）を配布した版の skill-stats.py --agents --session <conductor> で測った初回の結果である。--window-limit は既定（200,000）。

層	持ち場	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	印
conductor	-	claude-opus-5	1	35689	376279	0	411968	割る候補
supervisor	その他	claude-opus-5	18	40354	295946	1	787115	割る候補
supervisor	その他	claude-sonnet-5	1	45294	252629	0	297923	割る候補
worker	修正	claude-sonnet-5	1	43830	26672	1	70502
worker	その他	claude-opus-5	21	40245	58871	6	132892
worker	その他	claude-sonnet-5	2	44909	35240	1	104798

持ち場	supervisor	supervisor の実作業	worker の件数	supervisor と worker の固定費の合計	印
その他	1	447407	12	526211	worker を使いすぎ

3 つの事実が読める。

1. supervisor の実作業の中央値（295,946）が --window-limit を超える。 最大充填の上位 3 件（787,115 / 641,503 / 487,555）は応答数 468 / 272 / 209、所要 1300 / 1251 / 318 分で、設計 PR のクロスレビューを 20 ラウンド・38 ラウンド回した supervisor と重なる。収束ループの 1 ラウンドごとの差分と指摘が supervisor 自身の context window に積まれている
2. worker の 24 件中 8 件が実作業 < 固定費（opus 21 件中 6 件、sonnet 3 件中 2 件）。固定費 40k を払って 26k〜37k の作業をしている worker がある
3. 1 つの supervisor が worker を 12 本起動し、固定費の合計（526,211）が自身の実作業（447,407）を上回る

どこで見つけたか

v10.15.0 の振り返り（issue #550 のコメント）の「context window の大きさ」の表。測定は plugins/ndf/skills/skill-stats/scripts/skill-stats.py --agents --session 95dd816c-…（タグ ndf--v10.15.0）。

なぜこの変更の範囲外なのか

#550 の受け入れ条件は「測定が retrospective の出力に集計として現れる」ことと「粒度の基準が比で書かれている」ことまでで、測った結果に基づく切れ目の見直しは「前提: 境界の 4 点は上限ではなく初期値である。測った結果、実作業が固定費を下回る工程があれば隣と束ねる。逆に 1 つの窓が劣化の目安に届くなら割る」と次の判断へ送っている。持ち場がすべて その他 に落ちる件は #768 が扱う。

直さないと何が起きるか

agent-layers.md の切れ目（持ち場 5 つ）のまま次のまとまりを通すと、設計の supervisor が同じ形で 700k を超え、context-window.md の劣化の目安（遅くとも 20 万で切る）を守れない。worker の側は固定費が実作業を上回る起動が 3 分の 1 残る。

直し方の候補

• agent-layers.md の supervisor の切れ目に「収束ループ（cross-review / cross-refactoring）の各ラウンドは worker へ出し、supervisor には結果の要約だけを戻す」を足す。/goal の worker をサブエージェントから CLI へ変え、ランタイム × モデルを輪番で回し、統計が溜まったら作業に適した組を自動で選ぶ #760（worker の CLI 化）と同じ向き
• worker の起動の基準に「見込みの実作業が固定費（測った値）を下回る作業は隣の作業と束ねる」を足す。値は測定が持つ（/goal の工程をサブエージェントへ出し、2 つの承認以外を無人で通す（工程ごとの窓の大きさも測る） #550 の前提）
• 持ち場の名前が付いた次の測定（conductor が supervisor の description に工程名を使い、持ち場がすべて「その他」に落ちる #768 の後）で、持ち場ごとの worker を使いすぎ を読み直す

由来

issue #550（v10.15.0 の振り返り）