コーディングエージェントを安全に並列実行するには、各エージェントに専用のGit worktreeとブランチを割り当て、人間が事前に承認した計画のキューからタスクを供給し、人間がdiffを確認する前にworktree内で自動テストと静的解析（lint）を実行し、計画ごとのコストを記録する必要があります。多くのチームは、3つの初期段階を経てこの構成にたどり着きます。すなわち、「チャット画面での単一エージェント」「手作業でブランチを分けたエージェント」「ワーカーを用いたタスクキュー方式」です。各パターンは1つの課題を解決する一方で、新たな課題を浮き彫りにします。本ガイドでは、これら4つのパターン、各段階で破綻するポイント、そしてオーケストレータが担保すべき6つの必須要件を解説します。
4つの運用パターン
Steve Yegge氏による「AI支援開発の8つのレベル（2025年）」は、全体像を把握する上で非常に有用なフレームワークです。基盤となるループ――各ステップについて思考し（Reason）、行動し（Act）、結果を観察し（Observe）、繰り返す――は、YaoらによるReAct論文（ReAct: Synergizing Reasoning and Acting in Language Models）で形式知化されたものです。以下で紹介する4つのパターンは、すべて「誰がそのループを監視・統制するのか」に対する異なるアプローチと言えます。本稿執筆時点で、多くの開発チームはレベル2から3（開発者がプロンプトを送り、結果を確認してコミットする）に位置しています。並列エージェント、永続化されたメモリ、そして厳格なレビューゲートを備えたオーケストレーションこそが「レベル8」に相当します。
パターン1：チャットウィンドウ内の単一エージェント
開発者がターミナルやIDEパネルを開き、タスクを指示し、エージェントが作業ディレクトリ内のファイルを書き換える様子を眺めるスタイルです。エージェントと開発者が同一のチェックアウト先を共有しているため、スループットは必然的に「開発者1人あたり1タスク」に制限されます。1つ目のタスクが終わる前に2つ目のタスクを開始すると、双方の変更が同じツリー上で混ざり合い、生成されたdiffは何の意味も成さなくなります。
パターン2：ブランチごとに手動起動する単一エージェント
次のステップは、タスクごとに独立したブランチと作業領域を割り当てることです。Git worktreeを活用すれば、これを極めて軽量に実現できます。同一のGitオブジェクトストアを共有しつつ、複数の独立した作業ディレクトリを展開できます。
# メインの作業ディレクトリから実行：
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "サイドバーに検索ボタンを追加してください。完了したらテストを実行してください。"
これにより、開発者はそれぞれ独立したディレクトリで2〜3体のエージェントを同時に動かせるようになります。しかし、ここで破綻するのが「タスクの管理・追跡」です。どのworktreeがどのタスクに対応しているのか誰も正確に把握できず、プロンプトの履歴はターミナルのスクロールバックの彼方に消えていきます。さらに、2体のエージェントが同じファイルを変更した場合、マージする段になって初めて激しい競合（コンフリクト）が発覚します。
パターン3：分離されたWorktreeとワーカーによるキュー処理
チーム内で動かすエージェントの数が一握りを超えると、タスクを手動で起動する作業自体が最大のボトルネックになります。その解決策が「キュー」の導入です。タスクをキューに投入し、バックグラウンドのワーカープロセスがそれらを取得してworktreeを作成し、エージェントを実行してブランチをプッシュし、プルリクエスト（PR）を自動作成します。AutoGenなどのマルチエージェント研究フレームワークも、このワーカー＆キュー方式を採用しています。
しかし、タスクの開始から人間を排除したことで、次の致命的な問題が発生します。エージェントが作業を開始する前にタスクの仕様を検証するプロセスが存在しないため、要件定義が不十分なタスクが大量のトークンを浪費し、誰も求めていない無用なPRを量産してしまいます。また、PR作成前にコードが自動検証されないため、今度は人間のコードレビュアーが完全なボトルネックと化します。さらに、キューが放置状態で動き続けるため、API利用コストが誰にも気付かれないまま跳ね上がります。
パターン4：レビューチェックポイントを備えた計画ライフサイクル
最後のパターンは、「2箇所の人間のチェックポイント」と「自動検証ステップ」を組み込んだものです。タスクはまず文章化された計画（Plan）へと変換されます。コードが1行も書かれる前に、人間がその計画を読みます。エージェントは完全に分離されたGit worktree内で作業を実行します。テスト、静的解析、diffの要約はすべてworktree内で完結して実行されます。これは継続的インテグレーション（CI）の原則を、開発者単位ではなくエージェント単位に適用したものです。人間が検証結果とdiffを確認し、承認されて初めてプルリクエストが作成されます。
Ivyではこのパターンを「ソフトウェアファクトリ（Software Factory）」と呼んでいます。すべてのコード変更が同一のステージと同一の2つの承認プロセスを通過する、再現性の高い標準ワークフローです。詳細はソフトウェアファクトリとはを参照してください。
各段階で破綻するポイント
| パターン | 解決する問題 | 次に生じる破綻・課題 |
|---|---|---|
| チャット画面での単一エージェント | なし（これがベースライン） | 開発者1人につき1タスクの限界、同一ディレクトリの衝突 |
| ブランチごとの手動起動 | フォルダ衝突のない並列タスク実行 | 文脈の喪失、記録されない指示、マージ時のコンフリクト多発 |
| ワーカーによるタスクキュー | 手動起動のボトルネック解消 | 未検証の仕様投入とPR乱造、コストの暴走と不可視化 |
| チェックポイント付き計画サイクル | 成果物の無駄と未検証コードの排除 | キュー、分離、検証、コスト、メモリを統括する専用ツールの必要性 |
オーケストレータが担保すべき6つの責務
オーケストレータとは、パターン4を安定的かつ自動で運用するための基盤ソフトウェアです。以下の6つの責務を担います。どれか1つでも欠落すると、その作業を手動で行うことになり、再びそこがシステム全体のボトルネックへと逆戻りします。
- キュー管理（Queue）： 計画は明確な順序とステータス（下書き・承認済み・実行中・検証中・レビュー中・マージ完了）で管理されます。進捗状況はターミナルを開くことなく一目で把握可能である必要があります。
- 作業環境の分離（Isolation）： 実行されるすべての計画に、専用のGit worktreeとブランチが割り当てられます。mainブランチがエージェントから直接書き換えられることは決してありません。並列AIエージェントのためのGit Worktree活用法では、worktreeが共有ディレクトリやコンテナよりも優れている理由を解説しています。
- 自動検証（Verification）： エージェントの実行後、人間がコードを目にする前に、worktree内で自動テスト、静的解析（lint）、型チェック、diff要約が実行されます。失敗した場合は、詳細なエラーログを添付してエージェントにタスクが差し戻されます。
- レビュー機構（Review）： 「計画」と「diff」の厳格な2箇所のチェックポイントを備え、それぞれ明確な承認・却下アクションを提供します。計画段階での却下であればコード生成トークンは一切消費されず、diff段階での却下でも損失は1回の実行分に抑えられます。
- コスト会計（Cost accounting）： トークン数と費用が計画およびジョブごとに記録され、マージされた変更にいくらかかったのか、途中で放棄された計画にいくら費やされたのかをチーム全体で正確に追跡できます。
- 永続メモリ（Memory）： エージェントがある計画で学んだ知見は、次の計画でも引き継がれる必要があります。そうでなければ、すべてのタスクがゼロからのスタートとなり、同じ過ちが何度も繰り返されます。
Ivy Tendrilによる実装
Ivy Tendrilは、任意のCLIコーディングエージェントを対象にパターン4を実行する、macOS、Windows、Linux対応のローカルファーストデスクトップアプリケーションです。tendril --web を指定することでヘッドレス環境でも動作します。
- キュー管理： Plans画面で、すべての計画とそのライフサイクル状態を可視化します。Drafts、Icebox、Recommendationsなどのタブで未承認タスクを整理できます。GitHub Issuesやjam.devのバグレポートからWebhook経由で自動生成できるほか、MCPサーバー、REST API、CLI経由でも作成可能です。
- 完全な分離： 実行が始まると、Tendrilはその計画専用のGit worktreeとブランチを自動作成します。多数の計画をそれぞれのworktreeで安全に並行稼働させることが可能です。マージ後、Tendrilはworktreeを自動削除します。詳細は並列AIエージェントのためのGit Worktree活用法を参照してください。
- 統合された検証： Reviewアプリでは、各計画のテスト、lint、diffがタブ形式で整理されて表示されます。Proプランでは、外部CIの検証結果を取り込むことも可能です。
- レビュー機能： 計画のチェックポイントでは、下書きに対して「展開（Expand）」「分割（Split）」「更新（Update）」を行ったり、インラインコメントを入れて計画を再生成させたりできます。diffのチェックポイントは自動検証完了後に提示されます。双方が承認されない限り、プルリクエストが開かれることはありません。
- コスト会計： トークン消費とコストが計画単位およびジョブ単位で追跡され、ダッシュボード上で主要KPIやコスト推移チャートを確認できます。
- プロンプトウェアによるメモリ管理： 各ステージは「プロンプトウェア」ユニットによって制御されます。これには、自己進化する指示書であるProgram.md、コードベースの知見を蓄積するMemory/ディレクトリ、権限を絞ったTools/、実行履歴を記録するLogs/が含まれます。標準でCreatePlan、ExpandPlan、ExecutePlan、UpdatePlan、SplitPlan、CreatePr、CreateIssueなどのユニットを備えています。詳細はプロンプトウェアの解説記事を参照してください。
Tendrilは特定のエージェントに依存しません。Claude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCodeをはじめとするあらゆるCLIエージェントに対応しており、計画ごとに使用するエージェントや基盤モデルを自由に切り替えられます。ソースコードは常に手元のローカルマシン内に留まり、外部通信は設定したLLM APIおよびGitHubに対してのみ行われます。
Ivy自身の開発チームでは、このワークフローを導入したことで、1日あたりのプルリクエスト作成数が約10件から100件超へと大幅に向上しました。
はじめ方
- Tendrilのインストール：macOSまたはLinuxでは
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh、Windowsではirm https://cdn.ivy.app/install-tendril.ps1 | iexを実行します。詳細はインストールガイドを参照してください。 - アプリで対象のリポジトリを開き、利用中のモデルプロバイダのAPIキーを設定します。
- 既存のチケットから計画を1件作成し、下書きを確認して実行し、Reviewアプリで生成されたdiffを確認します。
- 最初の計画がマージされたら、次は3つの計画を同時に作成し、完全に並列で実行される様子を体験してください。
TendrilはFunctional Source Licenseのもとで無償かつソースコード公開（Source-available）で提供されています。チーム共同作業機能、SSO、オンプレミス運用、外部CI検証のインポート機能は、Proプラン（1ユーザーあたり月額59ドル）およびEnterpriseプランにて提供されます。
よくある質問（FAQ）
エージェントを並列実行するためにDockerなどのコンテナは必須ですか？
いいえ、必須ではありません。Git worktreeを使えば、オブジェクトストアを共有しながら、エージェントごとに独立した作業ディレクトリとブランチを瞬時に用意できます。コンテナはランタイムレベルの分離を提供しますが、これはエージェントがOSのシステムパッケージをインストールしたりポートを占有したりする場合にのみ必要です。通常のコーディングタスクのほとんどはworktreeで十分です。
同時にいくつのエージェントを実行できますか？
主な制約となるのは、オーケストレータの性能ではなく、モデルプロバイダのAPIレートリミットおよび手元マシンのテスト並行実行リソースです。まずは3〜5件の計画を並列で動かすことから始め、検証プロセスがスムーズに完了する範囲で徐々に増やしていくことをお勧めします。
2つの計画が同一のファイルを変更した場合はどうなりますか？
後からマージされる計画のブランチでマージコンフリクトが発生します。根本的な解決策は「計画立案」の段階にあります。同じモジュールを変更する計画は、実行前に順序付けを行うか、タスクをあらかじめ分割しておくべきです。Tendrilに搭載されている「Split（計画分割）」機能は、まさにこのために用意されています。
Ivy Tendrilで開発を加速する
開発者レベルの並列エージェントオーケストレーションを体験しませんか？
- ソースコードを確認: GitHubのIvy Tendrilリポジトリ（オープンソース）
- 技術ドキュメント: tendril.ivy.appの統合ガイドを参照
- アーキテクチャ相談: renco@ivy.appまでお気軽にお問い合わせください（30分の技術相談）