conductor どうしの排他が無い: Issue・プラン・ファイル・版数などの対象ごとにロックを置き、並列の conductor が同じ物を同時に書き換えないようにする #2316

何が起きたか

2026-10-31〜11-01（JST）、開発ループ l20261031 の周回 5 を、2 つの Claude Code のセッションが同時に conductor として回した。

B が A に気づいたのは、検査が止まった理由から作業場所を使っているプロセスを辿ったときである。それまでどちらも相手がいることを知る手段が無かった。B は操作をやめて見張りだけに切り替えた。

原因: conductor どうしの排他が無い

conductor が触る状態（開発ループの記録・スプリントの状態・キューの done・プランの状態ディレクトリ）は、どれも 1 つの conductor が持つ前提で作られているが、それを守る仕組みが無い。

開発ループに限らない。--loop を使わないスプリントでも、引継ぎ文書を読んだ 2 つのセッションが同じ queue --resume を打てば同じことが起きる。

何をするか

書き換える対象ごとに、書き換える間だけ取るロックを置く。 開発ループ全体を 1 本のロックにすると、conductor が同時に 1 つしか動けず、並列に強くする方針（2026-10-31）と逆向きになる。Issue の単位だけでは、別々の Issue でもぶつかる共有のもの（版数・同じファイル・同じブランチへのマージ・ループの選定）を防げない。実際に、並行のスプリント m26-1 と版 10.27.1 がぶつかり、手で 10.27.2 に書き換えた。

• リース: ロックの中で宣言（セッションの識別子・pid とホスト・始めた時刻・最後に動いた時刻）を置く。担当は節目で最後に動いた時刻を更新し、終わったら解放する。担当のプロセスが生きていない（同じホスト）、または寿命を過ぎたら、別のセッションが引き取って続け、引き取りを記録に残す。中継の再起動で次のセッションが続くのは、前のセッションのリースを引き取る正規の流れになる
• 短いロック: ファイルのロック（lib/locks.py）を操作の間だけ取る。取れなければ待つか断る
• 断るときの出力: 担当のセッションと最後に動いた時刻を出し、引き取る手順を示す
• 取る順序を固定する（例: Issue → プラン → ファイル → 作業場所 → 短いロック）。複数のロックを取るときに互いに待ち合って止まるのを防ぐ
• 部品: 既存の lib/run_owner.py（持ち主・最後に動いた時刻・終わった時刻・引き取り）と lib/locks.py を広げて使い、同じ役割の部品を作らない。見直しのフェーズの担当（開発ワークフローに「見直し」と「大整理」を足す: 棚卸しを毎スプリントの差分の棚卸し・数回に 1 回の見直し・十数回に 1 回の大整理（根本原因の発見と組み直し、後回しの再評価）に分ける #2315 の考察 6）も「ループの選定・棚卸し・見直し」の行のロックで扱う
• ループの記録の扱い: ループ全体のリースは置かない。2 つの conductor が同じループの別々の Issue を進めるのは許し、ぶつかる所だけを上の行で止める

ロックの置き場: ネットワークで共有できるロックにする

ファイルのロックでは足りない。 ファイルのロックが効くのは同じマシン（同じファイルシステム）の中だけである。Neural Development Factory では、conductor は実行ジョブのコンテナ（factory/runner/、ECS のタスク）の中で動き、スプリントを並列に回す。別々のコンテナの conductor は互いのファイルのロックも pid も見えない。手元でも、別のコンテナや別のマシンのセッションが同じリポジトリを進めれば同じである。

要件

候補

推奨

NDF の側にロックの契約（取る・更新・解放・状態・フェンシングトークン）を 1 つ置き、つなぎ先を .ndf/ の設定で選べるようにする。

• 書き込みの側はフェンシングトークンを確かめる。ロックのサービスが持つ状態（版数の採番・ループの選定）はサービスの中で番号を照らす。git への push は期待するコミットを条件にして（--force-with-lease と同じ考え）、古い担当の上書きを断る
• 既存の部品（lib/run_owner.py・lib/locks.py）は、手元の 1 台のつなぎ先として契約の後ろへ移す。同じ役割の部品を 2 つ持たない
• Factory の側のロックの API と DynamoDB の表は Factory の課題として分け、contracts/ に契約を置く

受け入れ条件

1. 2 つ目のセッションが、別のセッションが着手中の Issue に着手しようとすると断られ、担当と最後に動いた時刻が示される。着手中でない Issue には着手できる
2. 同じ done へ 2 つ目のプロセスが queue --resume（または同じプランを含む queue）を打つと断られ、同じプランのステップが二重に流れない
3. 別々の Issue のプランが同じファイルを触るとき、別のプロセスの queue が流すプランでも重なりが見え、同時には書き換えない
4. 版数の採番・リリース・スプリントブランチや develop へのマージ・ループの選定と棚卸しは、2 つのセッションから同時に打っても 1 つずつ進む。版数が重ならない
5. 別々のマシン・コンテナの conductor が同時に同じリースを取ろうとしても、片方だけが取れる。Factory のランナー 2 つで示す
6. 期限が切れた古い担当が動き出して書き込もうとすると、フェンシングトークンが古いため断られる
7. ネットワークのロックのつなぎ先が無い環境（手元の 1 台）でも、同じ契約でファイルのロックへ落ちて動く
8. 2 つのプロセスが同時に同じリースを取ろうとしても、片方だけが取れることをテストで示す
9. 担当のプロセスが終わっている、または寿命を過ぎていれば、別のセッションが引き取って続けられ、引き取りが記録に残る
10. 中継の再起動（ndf-next → 次のセッション）では、前のセッションの宣言を引き取って続く
11. 複数のロックを取る経路が決めた順序で取り、待ち合って止まらない
12. loop status と supervise.py の状態の表示が、担当のセッションと最後に動いた時刻を出す

未決

関連

• 見直しのフェーズの担当を 1 つにする: 開発ワークフローに「見直し」と「大整理」を足す: 棚卸しを毎スプリントの差分の棚卸し・数回に 1 回の見直し・十数回に 1 回の大整理（根本原因の発見と組み直し、後回しの再評価）に分ける #2315
• 作業場所が「使用中」のまま残る: リファクタリングの工程で着手前のテストが時間切れになると、作業場所が「使用中」のまま残り、テストのプロセスも残る #2285
• 開発ループの確定仕様: docs/specifications/ndf-workflow-development-loop.md
• 走っているプランの登録簿: plugins/ndf/scripts/supervise_lib/running.py