2026 年 5 月、Publickey が VS Code、複数AIエージェントでの開発を容易にする新機能「Agent window」プレビュー公開 を報じました。1 つのエディタウィンドウ内で複数の AI エージェントセッションを同時に走らせ、それぞれが独立したワークスペース・コンテキスト・実行履歴を持つ新しい開発パラダイムです。
弊社の受託開発の現場では、すでに 「リファクタ用エージェント」「テスト追加用エージェント」「ドキュメント生成用エージェント」を 別ウィンドウで並列実行する運用が増えていました。Agent window はこの **「マルチエージェント並列開発」を、標準 UI として正式にサポートするものです。これは VS Code 1.118 と Copilot CLI リモート制御 — 受託の “Copilot 持ち込み” ガイドライン の延長線にある、「受託で複数エージェントをガバナンスする」**新たな課題を生み出します。
なぜ「複数エージェントの並列実行」が標準になるか
| ボトルネック | 単一エージェント | 複数エージェント並列 |
|---|---|---|
| タスク依存待ち | 直列で 30 分待ち | 並列で 5 分 |
| コンテキスト汚染 | 1 セッションに大量タスク | 関心事ごとに分離 |
| レビュー粒度 | 巨大 diff | タスク単位の小 diff |
| 失敗時の影響 | 全タスクやり直し | 失敗エージェントのみ |
| モデル選択 | 1 モデル固定 | タスク別に最適モデル |
特に 「コンテキスト汚染」は、長時間セッションで品質劣化を起こす主因でした。Agent window によって タスクごとに独立コンテキストで分離することで、品質と速度の両立が初めて現実的になります。
受託で複数エージェントを並列稼働させる 4 つの設計原則
原則 1: ワークスペース境界を明示する
Agent window は 同一リポジトリの別ブランチ / 別ワークツリーで並列実行できますが、「同じファイルを同時に書き換える」事故が起きやすくなります。受託では タスク × ファイル所有マトリクスを事前に定義し、競合を物理的に防止します。これは Claude Code クライアント規約抽出受託 で扱った 「エージェント運用規約」を マルチエージェント対応に拡張したものです。
原則 2: 各エージェントに「役割と禁止事項」を持たせる
| エージェント | 役割 | 禁止事項 |
|---|---|---|
| Refactor Agent | リファクタリング | 外部 API 呼び出しの変更 |
| Test Agent | テスト追加・修正 | プロダクションコード改変 |
| Docs Agent | コメント・README 更新 | コードロジック変更 |
| Review Agent | PR レビュー支援 | 直接コミット |
役割の重複や禁止事項の漏れは 「全員が同じことをやる」事故の元です。CLAUDE.md / AGENTS.md に 役割定義を明文化し、エージェント起動時に自動読み込みさせます。これは AI Coding 規約抽出受託 の応用です。
原則 3: 並列実行数の上限と承認ゲート
5 つ以上のエージェント並列実行は モデル API のレート制限 / クォータ消費を一気に進めます。受託契約では 「同時稼働上限 N」と 「夜間バッチでの並列上限」を 数値で合意します。これは Claude Code 自動モード承認ゲート受託 と同じ思想です。
原則 4: 各エージェントの実行ログを「セッション単位」で永続化
Agent window のセッションごとに 「どのプロンプトで何を変えたか」の実行ログを 永続ストレージに保管します。これは 後から「なぜこの変更が入ったか」を追跡するための 監査基盤です。
受託で構築する 4 つのフェーズ
フェーズ 1: マルチエージェント基盤の評価（2 週間）
Agent window プレビューの実機検証と、既存の受託案件で並列化できるタスクの棚卸しを行います。並列で速くなるタスクと 直列のままが安全なタスクを 明確に区分します。
フェーズ 2: 役割設計とガードレール実装（3 週間）
4 〜 6 種類のエージェント役割を AGENTS.md / CLAUDE.md に定義し、役割を超えた変更を拒否するガードを CI で実装します。
フェーズ 3: シャドー並列運用（4 週間）
既存案件で 2 〜 3 種類のエージェントを並列稼働させ、実行ログ・レビュー時間・本番事故の有無を計測します。
フェーズ 4: 本番化と契約再交渉（3 週間）
受託契約に「複数エージェント並列稼働」の条項を追加し、監査ログの保管期間 / 同時稼働上限 / 課金按分を顧客と合意します。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| エディタ | VS Code Agent window | Cursor Composer 2 |
| モデル | Claude Sonnet 4.6 / GPT-5.4 mini | Codex / Gemini |
| 役割定義 | AGENTS.md + CLAUDE.md | リポジトリ Wiki |
| 並列制御 | Git worktree + ブランチ分離 | Devcontainers |
| ログ集約 | OpenTelemetry + S3 | Langfuse |
| CI ガード | GitHub Actions + danger.js | reviewdog |
| 承認 UI | Slack Block Kit | Linear / Jira |
Cursor Composer 2 や Zed 1.0 — AI エディタ受託チームオンボーディング のように、マルチエージェント対応の競合エディタも増えています。受託では 「エディタ非依存」のガードレールを設計するのが鍵です。
どの案件で刺さるか
| 向く案件 | 効果 |
|---|---|
| 大規模リファクタを伴う移行 | 並列化で 3〜5 倍速 |
| レガシーコードのテスト追加 | テスト追加を別エージェントで一気に |
| 月次ドキュメント更新 | Docs Agent で自動化 |
| 複数 PR を同時進行する受託 | レビュー Bottleneck 解消 |
| 多人数チーム × AI 受託 | 役割分担で衝突回避 |
受託契約に書く 5 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 同時稼働エージェント数上限 | N 並列までと明示 | 上限超過時の責任 |
| 役割定義の責任分界 | 受託側 / 顧客側で定義 | 役割超過時の補償 |
| API 課金按分 | エージェント別 / プロジェクト別 | 月次レポート |
| ログ保管期間 | 90 日 / 1 年 / 3 年 | 監査要件との整合 |
| 暴走時の即停止 | キルスイッチ実装 | 連絡経路 |
価格モデル — マルチエージェント受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| PoC 評価 | 60 万円〜 | 2 週間 | 並列化可否の評価 + ROI 試算 |
| Lite | 400 万円〜 | 8 週間 | 1 案件分の並列基盤 + シャドー検証 |
| Standard | 1,200 万円〜 | 3 ヶ月 | 上記 + 全社展開 + 監査基盤 |
| Care（運用代行） | 月 60 万円〜 | 12 ヶ月〜 | 並列稼働運用 + 月次レビュー |
ハマりやすい 4 つの落とし穴
落とし穴 1: 「全部並列」で逆に遅くなる
タスク間に依存があるのに並列化すると、マージ衝突解消で結局直列より遅くなるケースが頻発します。依存グラフを事前に可視化してから並列化対象を選びます。
落とし穴 2: モデル API クォータ枯渇
5 並列 × 長時間プロンプトで 1 日のクォータを午前中に消費する事故が起きます。1 エージェントあたりの月間予算を 物理的に制限します。これは GitHub Copilot 従量課金トークンガバナンス と同じ問題です。
落とし穴 3: コードレビュー破綻
並列で大量の小 PR が出ると、人間レビューが追いつかない事態になります。Review Agent + 自動マージ閾値を組み合わせ、人間レビューは「重要変更のみ」に絞ります。
落とし穴 4: ログが分散して監査不能
Agent window のセッションログがローカルだけだと、プロジェクト終了後に証跡が消えます。OpenTelemetry でリアルタイム集約を 初日から組み込みます。
まとめ — 「1 人 1 エージェント」から「1 人 N エージェント」へ
VS Code Agent window のプレビュー公開は、受託開発を「1 人 1 エージェント」から 「1 人 N エージェントの司令塔」へ転換させる起点です。並列化の速度メリットは大きい反面、役割設計・並列上限・ログ集約を 最初に設計しないと事故が連鎖します。
弊社では PoC 評価 / Lite / Standard / Care の 4 段階で マルチエージェント並列開発受託パッケージを提供しています。「複数エージェントで開発速度を上げたい」「並列化のガードレールを設計してほしい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
