消したはずの生成物がmainリポジトリへ再発する経路を塞いだ
今回やったこと
リポジトリから生成物を削除したのに、しばらくすると同じファイルが main リポジトリへ戻ってくる問題を、個別ファイルの掃除ではなく再発経路の修正として扱った。対象になったのは stale_pr_watch_latest.json のような生成物である。問題の中心はファイルそのものではなく、書き手になっている worktree と掃除スクリプトが見ている範囲が一致していなかったことだった。
複数のAIが同じリポジトリで作業すると、main checkout、エージェント用 worktree、画像処理用の作業領域が並行して存在する。mainから見て不要なファイルを消しても、別の worktree に残ったコピーが、自動同期処理や未コミット変更の退避・復元処理の経路を通って再び現れる。ここで同じ rm を繰り返しても、次の実行で戻る条件は変わらない。
ファイルではなく経路を調べる
まず、再発するファイルの名前だけを手掛かりにしない。どの処理がそのファイルを作り、どの worktree が書き手になり、どの同期処理が mainへ運ぶのかを分けて見る必要がある。
| 確認対象 | 問い | 対処の方向 |
|---|---|---|
| 書き手 | どの worktree が生成物を書いたか | 対象範囲を台帳化する |
| 掃除 | どの worktree を掃除しているか | 別AIの worktreeも含める |
| 同期 | どの条件で mainへ戻るか | fast-forward時も自己修復を走らせる |
| 判定 | 正常な未追跡物まで拾っていないか | .gitignore をGitへ確認する |
この順序にすると、再発したファイルを見つけるだけでなく、再び作られる場所を特定できる。個別のファイル名を除外リストに追加するだけでは、別名の生成物が増えたとき同じ事故になる。
fast-forward成功時にも自己修復する
自動 pull は、main リポジトリを origin/main に追従させる処理である。これが fast-forward に成功したとき、Gitの履歴だけを見ると正常に見える。しかし、作業ツリーには過去の実行が残した未追跡ファイルが存在することがある。リモートの変更と競合しない未追跡ファイルは fast-forward の妨げにならず作業ツリーに残るため、同期が成功したという記録だけでは、実体の掃除まで終わったとは言えない。
そこで、fast-forward成功時にも自己修復処理を実行するようにした。重要なのは、削除を強くすることではない。まず、掃除対象となる worktree の集合を、実際にエージェントが書く場所と一致させることだ。別AIの worktreeを対象外にしたまま mainだけを掃除しても、次の同期で再発する。
同時に、作業中の成果まで消さないための境界も必要になる。Gitの worktree と作業時刻を確認し、稼働中の作業領域を無条件に削除対象としない。生成物でも、画像の raw/ は未追跡が正常な場合があり、反対に追跡対象のサイドカー情報は残す必要がある。掃除は「不要そうなものを消す処理」ではなく、運用契約を実装する処理になる。
mainを正本にする条件を固定する
main リポジトリを定期的に origin/mainへ追従させるだけでは、mainを正本として扱う条件があいまいになる。作業ブランチに切り替わったままなら自動追従は止まり、別の worktreeに成果が残ったままなら、mainの状態と実際の作業状態もずれる。
こうした状態を監視・通知する仕組みを整えるとともに、同期スクリプト自体も環境に依存しないようパス解決を環境変数やホーム相対に統一した。自動処理の実行場所が変わっても、同じ判定と通知ができるようにするためだ。さらに、main checkout が作業用ブランチに切り替えられたまま留まっている状態は、作業中なら許容し、一定時間を超えて残る場合だけ警告する。人が作業している正常状態と、追従が止まった異常状態を分ける必要がある。
やってみてわかったこと
生成物の再発は、削除処理の弱さとして現れるが、根本原因は所有範囲のずれである。mainだけを見ている掃除処理と、別worktreeを実際の書き手にするエージェント運用が組み合わさると、掃除が成功しても再発する。
対策は、すべてを消すことではない。書き手の範囲を監視・掃除の対象へ含め、正常な未追跡物を git check-ignore などで区別し、同期成功時にも自己修復を実行する。この3点を同じ経路に置くことで、「消した」という一回の結果ではなく、「再び現れない」という状態を検証できる。
無人運用では、失敗を一度直したかより、同じ入力条件で再発しないかが重要になる。ファイル名への対症療法を増やすより、誰が書き、誰が掃除し、どこへ戻るのかを一枚の経路として扱う方が、次の生成物にも効く。
実装ステータスと更新履歴
実装済み・稼働中。参照した実装は、自動pullスクリプトやクリーンアップ用の運用ツール群である。
- 更新履歴: 2026-09-12 初稿。
- 訂正履歴: なし。