NDF Factory: 開発ループ・並行する実行の調整・ジョブの中の区切りと利用上限・手元のランナーの同時実行数・ループの見え方を定義する #2347

親: #2168。前提: #2186（スプリントの実行とランナー）・#2189（手元のランナー）・#2172（一覧と詳細）・#2173（承認と通知）。

具体例

2026-11-01、このリポジトリでは開発ループを 3 本並列で回すと決めた（Factory の l20261031・根本解決の lroot・開発フローの見直しの lflow。どれも同じリポジトリの develop へ入る）。そのとき決めたことは次の 4 つである。

• ループごとに選定の対象のマイルストーンを分ける
• 同時に流すプランは 1 本のループにつき 2 本までにする（全体テスト 6 本の同時実行が実測の上限）
• 版の衝突を避けるため、版数を流す時点に決める スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 が入るまで始めない
• 触る場所の重なり（plugins/ndf/ を 2 本が触る）は取り込みの時点で解く

Factory で同じことをしようとすると、どれも置き場が無い。この課題は、それらをすべて Factory の仕様として定義する。

依頼（原文）

Neural Development Factory ではこのあたりの並行開発のオーケストレーションはどのような構想になっていますか？（または未定義ですか？）

（書き手: 利用者（起票者がこの課題の「由来」に引用）、日付: 2026-11-01）

決まっていないこと、は全て定義する必要があります

（書き手: 利用者（同上）、日付: 2026-11-01）

恐らく、factory の場合 relay.py に相当するオーケストレーターが低コストで常に動いているのではないでしょうか

（書き手: 利用者（同上）、日付: 2026-11-01）

上の 3 つ以外の題・本文（「具体例」「何が決まっていなかったか」の表、「定義」1〜7、元の受け入れ条件 1〜13）は起票者（課題を書いた AI、2026-11-01）の文で、利用者の指示の原文としては扱わない。「定義」の値は NDF の開発ループ（plugins/ndf/skills/development-workflow/references/loop.md）と 2026-11-01 の 3 本並列の運用に合わせて起票者が決めた（判断の記録は ask.jsonl）。起票者が足した条件は次の「起票者の推定」に並べ、承認ゲート 1 で利用者が見直す。

起票者の推定

承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

• 同じリポジトリで方針の違う開発ループを複数並べる運用（2026-11-01 の 3 本並列）を、Factory の利用者が Web から同じ形で行えるようにする
• 並行する実行どうしの取り合い（課題・版・触るファイル）と、手元の機械の資源の上限を、機械で守る
• 8 時間のジョブの中で conductor の context window が埋まっても、手元の relay.py と同じく区切りで起動し直して続けられるようにする
• 利用者の 3 つの原文に答える: 並行開発のオーケストレーションの構想を、決まっていない点を残さず仕様として定義する

前提

• 前提 1: この課題は設計の課題で、成果は Factory の確定仕様（docs/specifications/ndf-factory-*.md）へ入る設計文書と、その設計を実装する子の課題である。受け入れ条件は実装の後に観測する振る舞いとして書き、設計の承認（承認ゲート 1）で範囲を確かめる
• 前提 2: 実行の制御（factory/api/src/runs/）とランナー（factory/runner/src/）の既存の形（docs/specifications/ndf-factory-runs-and-runner.md・ndf-factory-runs-state-and-data.md）は変えずに足す。実行の枠の数の行（I34・I35）と開始のトランザクションはそのまま使う
• 前提 3: Factory は NDF のループの記録（.ndf/loop/<名>/loop.json）を直接読まず、ランナーが進捗の事象へ翻訳したものだけを読む（腐敗防止層の向き）
• 前提 4: NDF の止まる条件のうち、周回の途中で止まる gate2_returned はループの状態の awaiting_approval へ写し、stopped にしない。答え（承認）で resume が続く。ほかの条件（user_stop・mvv_changed・same_failure・budget_laps・budget_usd・budget_hours・no_issue・outside_mvv・refused）は stopped へ写し、条件と値を止まった理由に残す。refused は元の定義 1 の列挙に無いが、loop.md が周回の途中で止まる条件として持つため足す
• 前提 5: 利用者が画面から止めたループは cancelled にし、ランナーへは NDF の loop stop に当たる知らせを渡す。周回の実行が動いていれば、今の取り消し（cancelSprintRun）と同じ形で止める → 止めたループは cancelled にし、周回の実行が動いていれば今の取り消し（cancelSprintRun）で止める。NDF の loop stop に当たる知らせは渡さず、ループの cancelled そのものを知らせとする（2026-11-02、設計の決定 15。取り消したループには次のジョブが起きず、止める印を書いても読む者がいないため）
• 前提 6: 「スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 を含む NDF の版」は、スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 を含んで出た最初の NDF の版数を下限とし、実行が使う NDF の版数（実行ジョブの指示が持つ版）と比べて決める。下限の版数は スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 のリリースの後に決まり、設計はその版数を設定の値として持つ（コードに埋め込まない）
• 前提 7: local の形態の「次の周回を起こしてよいか」の承認は、承認の依頼（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173）の新しい種類として画面と通知に並ぶ。今の 3 種類（ゲート 1・ゲート 2・判断）のどれかへ寄せるか新しい種類にするかは設計で決める（未決 1）
• 前提 8: 「低コストで常に動いているオーケストレーター」（利用者の 3 つ目の原文）は、常駐のプロセスとしては作らない。実行をまたぐ制御は今の呼ばれたときだけ動く実行の制御（事象と見回りで起きる）に置き、ジョブの中の区切りだけをランナー（ジョブの間だけ動く）に置く。常駐の費用は増えない
• 前提 9: 区間の上限の既定 20 とジョブの打ち切りの時間 8 時間は、今の手元の relay.py の運用の値に合わせた起票者の値で、設計の時点で実測（手元の relay の区間の数の分布）があれば置き換える
• 前提 10: 利用上限の検出は claude -p の結果（result の文と終了の形）から読む。managed・byok の形態では上限の切り替えをせず、API の失敗は今の失敗の扱いのまま

対象範囲

含む:

• 開発ループの集約（持つ値・状態・周回の起こし方・止まる条件の写し方・承認ゲート・実行の枠との関係・同じリポジトリの複数のループ）
• 同じリポジトリで並行する実行の調整（同じ課題の取り合い・版・触るファイルの重なり・本数の上限）
• 手元のランナーの同時実行数（max_jobs の申告と、資源の目安の警告）
• ループの見え方と承認（一覧・詳細・承認の依頼の並べ方・画面からの操作）
• local の形態の自動実行を確かめるまでの扱い
• ジョブの中の区切り（ndf-next を読んで区間を起動する）と区間の上限
• local の形態の利用上限での終わり方と回復の後の再開
• 上の追加が要る契約（進捗の事象・実行ジョブの指示・ランナーの登録と心拍）の定義と型

含まない:

• 課題の選定の規則（NDF の開発ループが持つ。Factory は持たない）
• スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164（版数を流す時点に決める）の実装。この課題は スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 を含む版かどうかで並行を絞るだけである
• relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346（relay.py が複数の claude セッションを統括する）の実装と、手元のアカウントの切り替え。サービスはアカウントを知らない
• Anthropic への確認そのもの（結果は NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 に記録する）
• 1 本のループの中で同時に流すプランの数（具体例の「1 本のループにつき 2 本まで」）。NDF の実行計画の並列の数が持ち、Factory はジョブの数だけを数える
• managed・byok の形態の利用上限の切り替え

ドメインイベント

引き金の無いイベント・失敗の経路の無いイベントは残っていない。E5 は失敗の経路を持たない（NDF の承認ゲートで止まること自体が経路である）。E7 の「事象が届かない」は前提 4 と受け入れ条件 2 で扱う。

用語

定義

1. 開発ループ（新しい集約）

開発ループは、1 つのリポジトリの登録に属し、スプリントの実行を順に起こし続ける集約である。 周回 1 回がスプリントの実行 1 本に当たる。課題の選定と周回の締めは、ランナーの中の NDF の開発ループ（/ndf:development-workflow --loop、sprint-state.py loop）がそのまま行い、Factory は選定の規則を持たない（腐敗防止層の向きを変えない）。

2. 同じリポジトリで並行する実行の調整

3. 手元のランナーの同時実行数

4. 見え方と承認

5. 手元のランナーの自動実行（#2189 の未確認の扱い）

確かめるまで、local の形態ではサービスがジョブを自動で起こさない。 開発ループの周回の起こし方（定義 1）は、local の形態では「次の周回を起こしてよいか」を利用者に問う承認の依頼に置き換える。Anthropic に確かめた結果は #2189 の本文に記録し、認められればこの置き換えを外す。managed・byok の形態は今のまま自動で起こす。

6. ジョブの中の区切り（relay.py の役割をランナーへ）

オーケストレーターの役割は 2 層に分ける。 実行をまたぐ制御（開始・停止の知らせ・見回り・周回の起こし方）は今の実行の制御（呼ばれたときだけ動くサーバーレス。常駐のプロセスを持たない）が持つ。1 つのジョブの中の区切りは、手元の relay.py と同じ役割をランナーが持つ。

7. 利用上限での切り替え（local の形態）

何が決まっていなかったか（確定仕様 docs/specifications/ndf-factory-*.md を 2026-11-01 に読んだ）

受け入れ条件

• 1. 利用者が画面から、リポジトリの登録ごとに開発ループを始め・止め・予算（周回の数・費用・時間）を変えられ、ループは周回ごとにスプリントの実行を START=loop・LOOP_NAME つきで起こし続ける。周回の課題の選定と締めはランナーの中の NDF の開発ループが行い、Factory のコードに選定の規則が無い
• 2. NDF の止まる条件（前提 4 の 10 個）はすべて進捗の事象 loop.stopped（条件と値）で届き、前提 4 の写し方どおりにループの状態（stopped か awaiting_approval）と止まった理由として画面に出る。loop.stopped が届かずにジョブが終わったループは、失敗を理由として stopped になる
• 3. 実行の枠が空くまで次の周回を起こさず、between_laps のループは枠を使わない（枠の数は動いている実行の数と等しいまま。I34 が崩れない）。枠が空いたら、待っていたループの次の周回が起きる
• 4. 選定の対象のマイルストーンが重なる 2 つのループを同じリポジトリで始めようとすると、後の方を理由（重なったマイルストーンと相手のループの名前）つきで断る。重ならない 2 つは始められる
• 5. 同じ課題が 2 つの動いている実行に入らないことを、開始の入力（課題の並びで動いている実行の課題を指すと断るか外す）とループの選定（EXCLUDE_ISSUES に動いている実行の課題が並ぶ）の両方で確かめるテストがある
• 6. スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164 を含まない NDF の版を使う実行は、同じリポジトリで 1 本に絞られる（2 本目の開始が理由つきで断られる）。下限の版数は設定の値で持つ
• 7. 取り込みで解けない衝突は attention（reason: base_conflict）として画面に並ぶ
• 8. リポジトリごとの同時の実行の数は、プランの表の値と、宣言した小さい方の値のうち小さい方で断られる
• 9. 手元のランナーは登録と心拍で max_jobs（既定 1）を申告し、サービスは動いているジョブがその数に達したランナーへ指示を渡さない
• 10. 手元のランナーは起動の時点の CPU の数とメモリから同時のジョブの数の目安を出し、申告が目安を超えると警告を出す（申告は受ける）
• 11. 画面にリポジトリごとのループの一覧（名前・選定の対象・状態・周回の数・費用・予算の残り・最後に動いた時刻・止まった理由）がある
• 12. 画面にループの詳細（周回ごとの実行の課題・結果・版・費用と、人の判断待ちの課題の並び）があり、人の判断待ちの課題に画面から答えると NDF の loop answer が働く
• 13. 承認の依頼にループの名前と周回の番号が載り、複数のループの承認の依頼が 1 つの一覧に並ぶ
• 14. local の形態では、次の周回を起こす前に利用者の承認を求め、承認されるまで次の実行を起こさない。Anthropic の確認の結果が NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 にあり認められていれば、設定でこの置き換えを外せる。managed・byok は承認を挟まずに起こす
• 15. ランナーは conductor の最後の result の ndf-next のブロックを読み、- 結果: が 判断が要る でないとき同じジョブの中で次の区間を起動する。判断が要る のときとブロックが無いときは起動しない。区間ごとに section.started（区間の番号・コマンド）が届く
• 16. 区間の数が上限（既定 20）を超えたジョブは job.finished（stopped、理由 section_limit）で終わる。打ち切りの時間（8 時間）は区間の合計に掛かる
• 17. ndf-next のブロックの読み方の規則は NDF の契約（入口・受け渡しのファイル・設定・環境変数の契約を 1 か所に宣言し、宣言の外を検査で落とす #2336 の宣言）にあり、ランナーの読み方と NDF の relay.py（relay_lib/mark.py）の読み方が同じ入力で同じ答えを返すことを確かめるテストがある。plugins/ は factory/ を参照しない（python3 scripts/check-service-boundary.py が通る）
• 18. local の形態で利用上限に当たったジョブは job.finished（stopped、理由 usage_limit、回復の時刻）で終わり、実行の制御が回復の時刻の後に resume のジョブを起こす
• 19. managed・byok の形態では usage_limit の扱いをせず、API の失敗は今の失敗の扱いのまま（既存のテストが通る）
• 20. 進捗の事象と実行ジョブの指示の追加（loop.stopped・section.started・LOOP_NAME・EXCLUDE_ISSUES・START=loop・max_jobs）は factory/contracts/ の定義と生成した型にあり、契約の検査が通る
• 21. 既存の開始の入口（課題の番号を 1〜20 件渡すスプリントの実行）の振る舞いは変わらない（既存の Factory のテストが通る）

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

関連

• relay.py が同じコンテナの複数の claude セッションを統括する（2 本目以降はホストが起動し tmux で端末を結び付ける） #2346（relay.py が同じコンテナの複数の claude セッションを統括する）: 手元のランナーと同じ「利用者の機械の上で複数の claude を起動・監視・停止する常駐のプロセス」。起動・一覧・停止の口を Factory の契約の形で揃える
• スプリントのプランが作った時点の版数を配布と本番のプランへ書き込み、並行する別のスプリントがその版を先に出すとプランを作り直すまで止まる #2164（版数を流す時点に決める）・異常系・ログ・回復とデータ・入出力の形を 1 つの実行の核へ集め、異常系の課題 103 件を型ごとにまとめて解く #2335（根本解決）

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-02 01:05
• 作業場所の用意 — 2026-11-02 03:20
• 設計 — 2026-11-02 01:15
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-11-02 03:20
• 実装 — 2026-11-02 04:21
• 構造改善 — 2026-11-02 06:03
• 実装レビュー — 2026-11-02 06:42
• 完了判定 — 2026-11-02 05:11
• Pull Request — 2026-11-02 05:29
• 確定仕様化 — 2026-11-02 12:27
• 後片付け — 2026-11-02 12:57
• 配布 — 2026-11-02 07:51
• 体裁レビュー
• リリース後テスト — 2026-11-02 12:46
• 振り返り — 2026-11-02 12:52
• 棚卸し — 2026-11-02 12:57

前提にする方針（2026-11-02 追記）

利用者の指示で、マイルストーン「25 Neural Development Factory」の説明にスプリント MVV を置いた（操作性と UX 重視・画面先行・オフライン利用・AI からも人と同じく使える・国や地域を越えて使える。#2168 の方針の表にも同じ行がある）。この課題の画面は #2382（UX の土台）の上に作り、#2383（オフラインで読める）と #2384（API と MCP から画面と同じ操作）の形に合わせる。

人の判断待ち（開発ループ lfactory2）

• 判定: follow（承認ゲート 1）
• 理由: Mission・Vision: Factory の利用者が、方針の違う開発ループを Web から同じリポジトリに並べ、始め・止め・予算の変更・一覧と詳細の確認を行えるようにする設計で、目指す姿に沿う。承認の依頼の種類を増やさず（決定 6）、承認をゲート 1・2 に寄せており、Value 2 にも反しない／Value 4・Value 5: 選定から外す課題は、conductor への文での依頼でなく環境変数 NDF_LOOP_EXCLUDE で機械的に渡す（決定 3）。並行を許す版の下限・区間の上限・local の自動の周回はコードに埋め込まず設定で受ける（決定 12、環境変数の表）／Value 3・Value 10: 区間の上限 20 は relay の記録 14 本の実測（最大 9）から、同時のジョブの数の目安は 2026-09-25 の実測から、待ちの 900 秒は NDF の既存の値から決めている。常駐のプロセスを置かず費用を増やさない（決定 1）／Value 6・Value 7: 取り合いは条件つきの書き込みとトランザクションで根本の場所で守る（決定 2・11・12）。ndf-next の読み方の正本は NDF の契約の一覧の 1 か所に置き、両方のテストが同じ例の組を読む（決定 8）。決めたことと採らなかった案の理由が記録されている／人に見てもらうべき点が 2 つある。1 つ目は、local で利用上限に当たった後、リセット時刻にサービスが自動でジョブを積むこと。これは要求の定義 5「サービスがジョブを自動で起こさない」の例外で、設計自身が承認ゲート 1 で利用者が見るとしている。2 つ目は、検査 requirements-check が「ファイルを読めない」で止まったままで、再実行と原因の確認が残っていること
• 根拠の項目: Mission, Vision, Value 2, Value 3, Value 4, Value 5, Value 6, Value 7, Value 10, C2, C3
• 設計 Pull Request: NDF Factory: 方針の違う開発ループを同じリポジトリで並べ、Web から始め・止め・見て、ジョブの中で区切りを越えて続ける（#2347） #2380
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.7/scripts/sprint-state.py loop answer lfactory2 2347 --approved|--rejected

振り返り: #2427 (comment)

閉じた理由

実装（PR #2393・スプリント PR #2397）がマージされ、ndf v10.27.14 で出ました。リリース後テストで不合格だった受け入れ条件 7・13（取り込みの衝突と、複数のループの承認の依頼の一覧が画面に出ない）は #2430 が受け持ちます。保留の 2 件は Factory を動かす環境が要る確認です。残りは #2430 で追うため、この課題は閉じます。