コーディングエージェントを大規模に運用するチームは、例外なく同じ構成要素を必要とするようになります。タスクの作業キュー、エージェントごとのgit worktree、長時間実行されるプロセスの監視、検証ランナー、Diffをレビューするインターフェース、コスト集計、そしてエージェントが同じ間違いを繰り返さないための記憶（Memory）です。多くのチームは、Claude CodeやCodex CLIをラップしたシェルスクリプトから始めて、これらを自作しようと試みます。Ivy Tendrilは、これらの構成要素をあらかじめ実装し、手元のマシンで任意のCLIエージェントを動かせる無料かつソース利用可能（source-available）なデスクトップアプリケーションとして提供しています。オーケストレーション自体が自社の製品である場合や、標準のライフサイクルに収まらない特殊なワークフローを持つ場合は自作が適しています。今週中にすべての仕組みを稼働させ、継続的な保守を外部に任せたいならTendrilを選ぶべきです。
それぞれのアプローチの目的
内製オーケストレーションの多くは、利便性のためのスクリプトから始まります。ブランチを作成し、プロンプトを与えてエージェントを起動し、終了時にPull Requestを作成するような処理です。しかし、複数のエージェントを同時に走らせたくなり、それぞれの進捗をリアルタイムで追跡したくなり、最終的にコストを把握したくなった段階でツールは肥大化します。数か月後には、それ自体が独自のバックログを抱える社内開発プロジェクトになってしまいます。AutoGenをはじめとするマルチエージェントフレームワークに関する研究論文にも全く同じコンポーネントが登場しますが、これはこれらの要素が特定の実装都合ではなく、課題の本質に根ざしている明確な証拠です。
Ivy Tendrilは、自作の手間をかけずにその仕組みの恩恵を受けたいチームのためのツールです。「アイデア・チケット作成 → Plan作成 → Draft（下書き） → 人間によるPlanレビュー → Expand、Split、またはUpdate → 隔離されたworktreeでの実行 → テスト・Lint・Diffによる検証 → 人間によるDiffレビュー → Pull Request作成 → マージ」という確立されたライフサイクルを実行します。チェックポイントは「Plan」と「Diff」の2箇所に厳密に絞られており、人間の承認なしにコードがマージされることはありません。macOS、Windows、Linux向けのデスクトップアプリとして動作するほか、tendril --webによりヘッドレスでも稼働し、任意のCLIエージェントをご自身のAPIキーで利用できます。
比較表
| 項目 | Ivy Tendril | 自作（DIY）オーケストレーション |
|---|---|---|
| 作業キュー | Plans、Drafts、Icebox、Recommendationsビュー | 自前で設計・開発が必要 |
| worktreeによる隔離 | 自動（Planごとに独立したworktreeとブランチを作成） | 作成、命名規則、クリーンアップのスクリプトが必要 |
| プロセス監視 | Jobsビュー（ストリーミング出力と実行ログを保持） | タイムアウト、リトライ、クラッシュの例外処理が必要 |
| 検証 | Planごとのテスト、Lint、Diff自動実行（ProではCIインポート） | 各エージェントの出力にテストランナーを独自配線 |
| レビュー | Reviewビュー（Diffと検証結果をタブで比較） | 素のPull Requestのみ、または自作UIが必要 |
| コスト集計 | PlanおよびJob単位で追跡、DashboardでKPI表示 | 各エージェント独自の出力形式からトークン数をパース |
| 記憶（Memory） | ライフサイクル段階ごとのPromptware Memory/（エージェントが自己更新） | ストレージ設計、検索、プロンプト注入を自作 |
| エージェント対応 | 任意のCLIエージェント、Plan単位で切替可能 | 自社で統合スクリプトを書き、最新状態を維持 |
| カスタマイズ性 | Promptwareプログラム、ツール、Memory、REST API、ソースコード公開 | 無制限 |
| 保守・メンテナンス | Ivy社が定期アップデートを提供 | 自社チームが恒久的に保守を担当 |
| 費用 | 無料（Proプランは1ユーザー月額59ドル） | エンジニアの人件費・開発時間 |
自作オーケストレーションに求められる要素
実際に開発を始める前に、4つのオーケストレーションパターンがどのように発展してきたかを確認しておく価値があります。ほとんどの内製ツールは、この発展パターンを順番に追体験することになるからです。
作業キュー（Queue）： 課題チケット、バグ報告、チャットなどからタスクが届きます。それらを保持し、優先順位を付け、エージェントへ配分する仕組みが必要です。TendrilではPlans、Drafts、Iceboxの各ビューがこれを担い、webhooks、MCPサーバー、REST API、CLI経由でのタスク取り込みに対応しています。
worktreeの管理： 2つのエージェントが同一の作業ディレクトリでファイルを編集すると競合が発生します。各タスクは独立したブランチ上で個別のgit worktreeを必要とし、エージェント起動前に作成され、Pull Requestマージ後に削除されなければなりません。TendrilはこれをすべてのPlanに対して自動で行います。詳細は並列AIエージェントのためのgit worktreesをご覧ください。
エージェントプロセスの監視： CLIエージェントは数分から数時間にわたって動作し、途中で権限確認を求めたり、レート制限に達したり、予期せず終了したりします。適切なフラグでプロセスを起動し、標準出力を捕捉し、停止を検知し、ログを記録する監視機構が不可欠です。TendrilのJobsビューはリアルタイムで出力をストリーミングし、Jobごとの実行ログを正確に記録します。
検証ランナー： エージェントが「完了した」と自己申告しても、成功の証拠にはなりません。人間が目を通す前に、該当のworktree上でテスト、Lint、Diff解析を実行する必要があります。TendrilはPlanごとにこれらを走らせ、結果をReviewビューに集約します。詳細はAI生成コードのための検証ゲートをご覧ください。
レビュー用UI： Pull Requestの画面はDiffを表示できますが、どの検証ステップがパスしたのか、エージェントにいくらコストがかかったのかはわかりません。1日に10件のDiffなら素のPull Requestでも処理できますが、50件になると破綻します。TendrilのReviewビューは、コードの変更点と検証結果を同一画面に統合します。
コスト集計： 各エージェントは独自のフォーマットでトークン使用量を出力します（出力されない場合もあります）。タスクの正確な原価を知るには、実行ごとにトークンを記録し、価格を算定して集計しなければなりません。TendrilはPlanおよびJob単位でトークンとコストを記録し、Dashboardで可視化します。
記憶（Memory）： 記憶がなければ、すべての実行はゼロからのスタートになります。記憶を持たせるには、永続ストレージ、実行後の学びを書き戻す仕組み、そして次回の実行前に必要な知識を注入する仕組みが必要です。Tendrilでは、各ライフサイクルの段階がProgram.md、Memory/ディレクトリ、専用のTools/、Logs/を備えたpromptwareユニットになっています。エージェント自身が知見を蓄積し、自身のプログラムを更新します。詳細はpromptware：自らの指示を改善するエージェントをご覧ください。
保守にかかる真のコスト
初期開発にかかるコストは、全体から見ればごくわずかです。最大のコストは、上記の構成要素のすべてが「頻繁に変更される外部要素」に依存している点にあります。CLIエージェントは頻繁にバージョンアップされ、そのたびにオプションフラグ、出力フォーマット、権限モデルが変更されます。モデル提供元は新しいモデルを追加し、既存モデルを廃止します。リポジトリの規模拡大に伴い新たな検証ステップも必要になります。個々の修正は小さく見えても、積み重なることで少なくともエンジニア1名分の業務を恒久的に圧迫します。
さらに、「自作では手が回らない機能」の機会損失もあります。Planのインライン注釈、Planの分割（plan splitting）、音声入力、スマートフォンからのジョブ監視、レコメンデーション画面などはそれぞれ高度な設計と開発工数を要するため、内製ツールに実装されることは稀です。
人間のチェックポイントとその配置
自作の自動化ループは通常、すでに仕組みとして存在するPull Requestの1箇所しかチェックポイントを持ちません。Tendrilは2つのチェックポイントを設けています。Planのチェックポイントにより、エージェントがコードを書き始める前にスコープの誤りを正し、下書きにインラインコメントを付けてPlanを再生成させ、大きすぎるPlanを事前に分割することができます。内製ツールにPlanのチェックポイントを組み込むには、Planのデータ構造、ドラフト作成機能、エディタ、承認済みPlanをエージェントに渡す仕組みをすべてゼロから開発しなければなりません。
並列処理、エージェント選定、コスト管理
並列実行は、自作ツールが最も保守工数を取られる領域です。不要になったworktreeの掃除、並列テスト実行時のポート衝突、あるエージェントのクラッシュによる他タスクの巻き添え停止などが頻発します。Tendrilは各Planを専用のworktreeとブランチに完全隔離し、最終レビューまでmainブランチをクリーンに保ちます。
1つのエージェントを接続するのは簡単な作業ですが、5つのエージェントを常に最新仕様に追従させるのは終わりのない重労働です。Tendrilなら、ワークフローに手を加えることなくPlanごとにエージェントやモデルを変更でき、Anthropic、OpenAI、Google、OpenRouterなどのキーを直接利用できます。Planごとのコスト比較により、同一タスクにおけるモデルごとの費用対効果も一目瞭然です。
独自構築が適しているケース
- オーケストレーション自体が自社のコア製品であり、ループ内のすべての意思決定を完全に掌握する必要がある。
- 開発フローのゴールがPull Requestではなく、Gitを使用せず、コードベース以外のデータや資産を扱っている。
- 人間のチェックポイントが一切不要な完全自律ループ（リスクの極めて低いリポジトリで未レビューのままマージされる運用など）を構築したい。
- オーケストレーションのループ構造そのものを研究対象としている研究機関である。
Ivy Tendrilが適しているケース
- 並列エージェント、worktreeによる隔離、自動検証、レビューUI、コスト追跡を今週中に導入したい。
- PlanフォーマットやレビューUIを自作することなく、2段階の人間のチェックポイントを導入したい。
- ストレージの設計に頭を悩ませることなく、実行ごとに知識が蓄積されるMemory機構を手に入れたい。
- エージェント連携の継続的なメンテナンスをIvy側に任せたい。アプリ自体は無料です。ProおよびEnterpriseの詳細は料金プランをご確認ください。
あわせてコーディングエージェントのためのエージェントオーケストレーションパターンもご覧ください。
よくある質問
ゼロから作らずにIvy Tendrilを拡張できますか？
はい。ライフサイクルの各段階はpromptwareユニットとして構成されており、Program.md、Memory/、Tools/を直接確認・編集できます。REST API、MCPサーバー、CLIを通じて、既存の独自社内ツールからTendrilを制御することも可能です。ソースコードはFSL-1.1-ALv2ライセンスのもとで公開されています。
Ivy Tendrilを使うと特定のエージェントやモデルに縛られますか？
いいえ。TendrilはClaude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCode、その他あらゆるCLIエージェントをサポートしています。ご自身のAPIキーを使用し、Planごとに自由に切り替えて運用できます。
すでに自作ツールがありますが、併用できますか？
はい。一部のタスクをWebフックやREST API経由でTendrilに流し、Pull Requestの処理ペースやPlanごとのコストを現在の自作ツールの数値と比較検証することをおすすめします。
Ivy Tendrilで開発を加速する
開発者レベルの並列エージェントオーケストレーションを体験しませんか？
- ソースコードを確認: GitHubのIvy Tendrilリポジトリ（オープンソース）
- 技術ドキュメント: tendril.ivy.appの統合ガイドを参照
- アーキテクチャ相談: renco@ivy.appまでお気軽にお問い合わせください（30分の技術相談）