同じフォルダで複数のAIエージェントを走らせたときの衝突を検知して復旧する

複数の AI コーディングエージェント（Claude Code / Cursor / Codex 等）を同じ作業フォルダで 同時に走らせると、片方が片方の未コミット作業を静かに消す。ロック機構を入れても防げない。 検知の合図と、壊したときの復旧手順、そもそも壊さないための禁止動詞をまとめる。

1. ロックはこの事故を防げない

自前のロック（worklock のような資源ロック）を持っていても、次の2点で素通りする。

• holder をリポジトリのパスにしていると、同一フォルダの2セッションは同じ holder になる。 status は相手の保持を「自分」と表示し、acquire も成功する。 ロックが止められるのは「別フォルダの主体」だけ。
• ロックは資源（DB・デプロイ・外部API）の排他であって、作業ツリーの排他ではない。 相手が宣言した目的（--purpose）と、相手が実際に触るファイルは一致しない。 実例: 掲示板の目的は「設定ファイルの間引き」なのに、実際にはこちらが読んでいる 解析スクリプトを書き換えていた。

結論: 掲示板（purpose）を信用せず、ファイルシステムを見る。

2. 検知は mtime でやる

着手時と、書き戻す直前の2回、必ず打つ。

# 直近10分で変わったファイル（.git とビルド生成物は除く）
find . -path ./node_modules -prune -o -newermt '-10 minutes' -type f -print | grep -v '^./.git/'

# 対象ファイルが自分の最後の読み取りより後に変わっていないか
ls -l --time-style=full-iso <file>

判定:

• 自分が書いていないファイルが git status で M なら、それは他人の作業。 「自分の変更は無いはずだから消していい」と考えた瞬間に事故る。
• 生成物との diff を取ったとき、- 側（＝リポジトリの現物）に見覚えのない行があるのが 最初で唯一の合図になることがある。見覚えがなければ手を止めて mtime を見る。
• git diff <branch>...<other> が突然空になる／push が non-fast-forward で弾かれるのは、 同じ目的の別セッションが先に進めた足音。

3. 共有フォルダでの禁止動詞

これらは「自分の変更を捨てる」つもりで打っても、相手の未コミット作業を巻き添えにする。

動詞	何が起きるか	代わりに
git checkout -- <file> / git restore <file>	相手の未コミット差分が消える。reflog にも残らない	打つ前に git diff <file> > /tmp/backup.diff
git stash	相手の作業ごと退避され、相手からは消えたように見える	使わない。自分の変更は別ファイルに退避する
git add -A / git commit -a	相手の生成途中のファイルを自分のコミットに巻き込む。メッセージと差分が無関係になる	パスを明示して add する。空コミットが要るなら --allow-empty
git rebase / git reset --hard	相手が checkout 中の ref が動き、相手の作業ツリーが壊れる	push 済みでなくても履歴を書き換えない

4. 壊したときの復旧

diff を取ってあれば復元できる。取っていなければ復元できない。 reflog は未コミット差分を持たない。

1. 直前に取った diff 出力（もしくは委譲LLMに渡した入力・生成物）を探す。 - 側の行が相手の版。
2. HEAD の版を土台に、- 側の差分をアンカー文字列で当てて書き戻す （行番号で当てない。相手が同時に動かしている）。
3. node --check / python -m py_compile 等で構文を確認し、git diff で 復元前に観測した差分と一致するか目視する。
4. 復元できた／できなかったを隠さず報告する。 相手のセッションは自分の作業が 消えたことに気付かない。

5. 委譲したときの追加の罠

実装を別のLLM（Codex / OpenRouter 等）へ委譲する場合、渡した入力は渡した瞬間に古くなる。

• 委譲プロンプトにソース全文を同梱した場合、生成が返ってくる頃には現物が変わっている。
• 生成物を書き戻す直前に、「渡した実物」と「現在の現物」を diff して同一か確かめる。 git show HEAD:<file> との比較では気付けない（相手の変更も未コミットだから）。
• 差分があれば生成物は破棄する。相手が同じ欠陥をすでに直していることが多い （同じコードを読んで同じ結論に至るので、衝突は「たまたま」ではなく起きるべくして起きる）。

6. 同じ目的だと分かったら降りる

相手が同じ目的を走らせていると確認できたら、マージしようとせずに手を止める。 二重に走らせた方が高くつく（トークンも、事故の確率も）。降りるときは:

1. 相手が触っているファイル一覧（find -newermt の出力）を引き継ぎに書く。
2. 自分が既に壊した／変更したものがあれば明記する。
3. 自分しか持っていない発見（相手が踏んでいない欠陥など）だけを短く残す。

7. 予防（設計側）

• セッションごとに git worktree を切る。 同一フォルダを共有しない。これが唯一の根治。 git worktree add ../<repo>-<作業名> -b <作業名>
• ロックの実体はリポジトリの外（~/.config/<app>/locks/）に置く。worktree が分かれても共有される。
• ロックの holder はセッションIDにする（リポジトリのパスにしない）。パスにすると §1 の穴が開く。
• 引き継ぎファイル（次セッションへの申し送り）自体も排他対象。書く直前に読み直し、 節単位で差し込む（開始時に読んだ版で上書きすると相手の申し送りが消える）。