2つのAgentを同時に動かす：コンフリクトと隔離

同じプロジェクトで2つのAgentを起動した。一方は決済モジュール、もう一方は請求モジュールを担当する。両方のAgentが作業を開始しコードを修正する。数分後に気づく：Agent Aが決済ロジックに合わせて共有ユーティリティ関数を修正し、同時にAgent Bが請求ロジックに合わせて同じ関数を修正していた。2つの修正が互いを上書きしている。あるいはもっと厄介なケース：Agent Aがデータベーススキーマを変更したのに、Agent Bはまだ旧スキーマに基づいてクエリを書いている。各Agentの出力は個別にはテストを通過するが、同じコードベースの異なるスナップショットに基づいている。

これは分散並列開発における最も基本的な問題だ：共有状態の並行修正。人間のチームはブランチ戦略とコードオーナーシップでこれを管理する。Multi-Agentシナリオでも同じメカニズムが必要だが、より明示的でなければならない。

各Agentには独立したワークスペースが必要だ。最も基本的な形は独立したgitブランチだ：各Agentが自分のブランチで作業し、完了したらマージで統合する。より厳格な隔離はディレクトリやモジュールレベルで行う：Agent Aはpayments/配下のファイルのみ修正可能、Agent Bはbilling/配下のファイルのみ修正可能。

第4章で導入したSkillカードは、ここで新たな役割を担う。単一Agentの個人メモから、Multi-Agentチームの職務記述書へと変わるのだ。Skillカードのtrust_boundariesフィールドが、各Agentが触れてよいものと触れてはならないものを明示的に定義する。「データベーススキーマを変更しない」「外部APIコントラクトを変更しない」は、提案から厳格な境界へと変わる。複数のAgentが並列で作業する場合、責任境界の明確さがコンフリクトの発生確率を直接的に決定する。

隔離の粒度はプロジェクトのアーキテクチャによって決まるべきだ。マイクロサービスアーキテクチャはAgent単位の隔離に自然に適している：各Agentが1つのサービスを担当する。モノリシックアーキテクチャではモジュール分割をより慎重に行う必要がある。原則は：Agentの作業スコープをできるだけ直交的にすること。交差が小さいほど、コンフリクトは少なくなる。