マルチAgent並列：隔離と統合

🚧 本章は開発中です。以下はコア論点の概要であり、完全版は今後のバージョンで公開されます。

前章では単一のAgentが自律的にタスクを完了できるようにしました。自然な次のステップは、同時に複数を走らせることです。フロントエンドに1つ、バックエンドに1つ、テストに1つ。理論上、個人の生産性は5〜10倍から数十倍へと跳躍できます。

実際の運用では、2種類の問題が順に浮上します。第1は物理的な衝突です。2つのAgentが同じファイルを変更し、後からコミットした方が先のコミットを上書きします。あるAgentがデータベースのschemaを変更し、別のAgentはまだ古いフィールド名を使っています。この種の衝突は明白で、エラーメッセージが問題を直接指し示します。第2はより潜在的です。各Agentがそれぞれ自分のテストに通過しているのに、マージすると システムが崩壊します。フロントエンドが期待する API のレスポンスフォーマットとバックエンドの実際のレスポンスが異なり、双方の前提は矛盾しているにもかかわらず、各自のテストは各自の前提だけを検証しています。

この2種類の問題に対応する2層の解決策があります。隔離メカニズム（独立した作業ディレクトリ、gitブランチ、モジュール境界）が物理的衝突を防ぎます。契約と統合テストが論理的衝突を防ぎ、API契約がインターフェース動作の仕様を定義し、統合テストがマージ前に複数モジュールの協調を検証します。この2層の下にはインフラの支えが必要です。階層型 feedback loop（ミリ秒レベルのlintから分レベルの統合テストまで）、再現可能な環境、機械可読なシグナルフォーマット。これが Agent 開発シナリオにおける platform engineering の核心的関心事です。

マルチAgent並列は管理の問題も生みます。同時にいくつ管理できるか。3つのAgentならまだ自力で調整できますが、それ以上になると誰が何をしているか、問題を誰が持ち込んだかが把握できなくなります。管理のスパンはあなたの精力ではなく、検証の自動化の成熟度によって決まります。CIが自動的に問題の発生源を特定し実行可能なフィードバックを生成できるとき、管理できるAgent数は増加します。マージ後にどのAgentがリグレッションを持ち込んだかを手動で調査する必要があるとき、3つが限界です。

本章は隔離から統合、そしてプラットフォーム基盤へと、マルチAgent並列開発の完全な方策を構築します。

Harness Engineering Playbook · AgentsZone Community