個々は正しくても合わせると壊れる：コントラクトと統合

各Agentに独立したワークスペースを与え、明確な責任境界を設定した。Agent Aは決済モジュールの全テストに合格し、Agent Bは請求モジュールの全テストに合格した。両方のブランチをtrunkにマージし、統合テストを実行すると、失敗する。

Agent Aの決済インターフェースは金額フィールドをtotal_amountで返し、Agent Bの請求モジュールはpayment_amountというフィールドを期待している。各Agentの実装は機能的には正しいが、インターフェースの理解に食い違いがある。単一Agentのシナリオではこの種の問題はめったに発生しない。同じAgentが同じコンテキスト内で自然に命名の一貫性を維持するからだ。Multi-Agentシナリオでは、各Agentが自分のコンテキスト内で作業しており、明示的な契約上の制約がない限り、あらゆる細部で前提がずれる可能性がある。

第2章で導入したAPI Contractは、ここで新たな役割を担う。単一Agentシナリオでは、Contractはあなた（人間）とAgentの間のコミュニケーションツールであり、AgentがインターフェースのRequirementsを理解することを保証する。Multi-Agentシナリオでは、ContractがAgent間の唯一の調整チャネルとなる。Agent同士は会話しない。リアルタイム同期もない。Contractが合意の唯一の基盤だ。これによりContractに対する要求水準は大幅に上がる：フィールド名、データフォーマット、エラーコード、状態遷移、あらゆる細部がContractに明示的に定義されていなければならない。単一Agentであれば、Contractはある程度曖昧でも、人間とAgentが会話の中で明確化できる。複数Agentでは、Contractのあらゆる曖昧さが潜在的な統合失敗ポイントとなる。

第3章で議論した統合テストは、ここで「推奨」から「必須」へと変わる。単一Agentシナリオでは、Trophyテストが出力品質を検証する最良のツールだ。Multi-Agentシナリオでは、統合テストがAgent間の不整合を発見する唯一のツールとなる。モジュールレベルのテストはモジュール自身の正しさを検証できるが、モジュール間の前提が揃っているかは検証できない。

継続的インテグレーションの頻度も上げる必要がある。従来のチームは1日1回統合するかもしれない。Multi-Agent並列開発では、Agentがタスクのチャンクを完了するたびに統合テストをトリガーすべきだ。統合の問題を早く発見するほど、修正コストは低くなる。2つのAgentがそれぞれ1日作業してから統合すると、発見される問題は1日分の作業を破棄する必要があるかもしれない。1時間ごとに統合すれば、最悪でも1時間分のロールバックで済む。