並列コーディングエージェントはタダではない：Git Worktree はファイルを隔離するが、状態は隔離しない¶
クイックアンサー： 今週の Hacker News のスレッド「Git worktree はコーディングエージェントの隔離境界ではない」は、ほとんどの並列エージェント構成が見落としている点を指摘しました。worktree が隔離するのは ファイル であって 状態 ではありません。複数のエージェントが同じ計画、アクティベーションストア、トークンストリーム、証拠ログに対して実行されると、マルチスレッドコードと同じ競合状態——失われた更新、二重消費、静かな競合——が発生します。ファイルの隔離は必要ですが十分ではありません。トランザクション的な状態と明示的な協調も必要です。
並列エージェントの流行と現実¶
並列コーディングエージェントは今やどこにでもあります。Claude Code、Codex、OpenCode を並べて実行する tmux TUI、並列エージェント用のローカルマージキュー、エージェントごとに 1 つの worktree を立ち上げるチーム。アイデアは単純です——エージェントは安いのだから、もっと多く走らせよう。
現実を突きつけたのが、今週の「worktree は隔離境界ではない」というスレッドです。この指摘は核心を突いています。2 つの worktree の 2 つのエージェントはお互いの ソースファイル を壊すことはできませんが、お互いの 状態 を壊すことは十分にできます。
worktree の隔離が実際に提供するもの¶
Git worktree は各エージェントに独自の作業ディレクトリとブランチを与えます。守られるのは：
- ソースファイル —— エージェント A の編集がエージェント B のファイルを上書きすることはありません。
- ブランチ —— 各エージェントは自分のブランチをマージし、競合はマージ時に表面化します。
守られないのは：
- アクティベーションストア —— どのワークフローがアクティブか、計画がどのトークンにいるか。
- トークンの前進 —— 2 つのエージェントが両方「現在のトークン = 3」を読み、両方 4 に進めます。1 つのステップが 2 回実行され、別のステップは一度も実行されません。
- 証拠と検証 —— エージェント A の検証ログが、同じチェックを実行したエージェント B に上書きされることがあります。
- 共有キャッシュとロック —— 同じロックファイル、同じレジストリ、同じ
.aios状態ディレクトリ。
エージェントがこれらを共有しているなら、worktree は隔離された 気分 を与えるだけで、その下の状態機械はバグだらけのマルチスレッドコードとまったく同じように競合します。失われた更新、二重消費、静かな競合です。
状態レベルの隔離とはどのようなものか¶
「うまく動く並列エージェント」と「お互いを壊し合う並列エージェント」を分けるのは 3 つの要素です。
1. トランザクション的な状態書き込み¶
状態の更新は原子的でクラッシュセーフでなければなりません。書き込み途中でエージェントがクラッシュした場合、次の実行はロールフォワードするかフェイルクローズします——中途半端に書き込まれた投影を信用することはありません。AIOS v5.4.0 はアクティベーション書き込みをトランザクション化しました（write-ahead トランザクション、再起動時の自動ロールフォワード、stale-activation-projection 障害による読み取り側の整合性検証）。
2. 共有トークンへの真のロック¶
並列エージェントは同じ Command トークンを二重消費してはいけません。ストアのファイルロックが前進を直列化します。並行呼び出しは静かに競合する代わりに AIOS_REX_STORE_BUSY を受け取ります。これは SELECT ... FOR UPDATE と同じ規律です——並列化できない唯一のものを直列化します。つまり、次のステップを所有するのは誰か。
3. 暗黙の信頼ではなく明示的な協調¶
並列性には協調レイヤーが必要です。明確な所有権を持つ独立した作業パッケージ、監視（誰が詰まっている？）、安全な回復（ワーカーが死んだらどうなる？）。AIOS の Agent Team ルートは、受入基準付きの独立パッケージに作業を分割し、ライブステータス用の HUD を提供します。Solo Harness は、ジャーナルと停止/再開を備えた 1 つの長期目的のための worktree 隔離を提供します——2 つは異なる仕事のための異なるツールです。
経験則¶
作業が独立した状態を持つ独立したパッケージに分割できるときに並列エージェントを使いましょう。結合された変更は順次に保ちます——ワークフローポリシーはすでにこれを実行しています（planned ルート、結合された変更は 1 つのクライアントに留まる）。2 つのエージェントが同じアクティベーション、トークン、または証拠に触れなければならないなら、それは並列タスク 2 つではなく、競合状態を抱えたタスク 1 つです。
安全な開始手順¶
aios init --all
aios doctor --native --verbose
独立した作業パッケージと HUD 監視については Agent Team ガイド、worktree 隔離による再開可能な長時間作業については Solo Harness ガイド、結合された変更を順次に保つ必要がある場合については Workflow Policy をお読みください。
FAQ¶
では worktree を使うのをやめるべきですか？¶
いいえ。worktree は優れたファイルレベルの隔離メカニズムです。ポイントは 十分ではない ということです。トランザクション的な状態と明示的な協調をその上に追加しないと、並列性はファイル競合では決して起きない形で牙をむきます。
エージェントが状態を共有しているかどうかはどうすればわかりますか？¶
worktree の外に何を書いているかを確認してください。共有の .aios ディレクトリ、ロックファイル、レジストリ、あるいは「今どのステップにいるか」を記録するものすべてです。2 つのエージェントが同じファイルを読み書きできるなら、状態を共有しています。
マージキューだけでは十分な協調にならないのですか？¶
マージキューが協調するのは コード —— ブランチがマージされるタイミングです。状態 —— 計画トークンを前進させるのは誰か、検証を所有するのは誰か——は協調しません。両方必要です。
詳細はどこで確認できますか？¶
Changelog には v5.4.0 の状態堅牢化リリースがまとめられており、リリース記事 Workflow Iteration v2.1 はクローズされた並行性の障害モードを解説しています。
並列性は力の増幅器です——スループットにとっても、破壊にとっても。ファイルはぜひ隔離してください。状態も隔離しないと、エージェントたちが最悪の形で代わりにやってくれます。