TL;DR
- Claude Code・Codex・Cursor CLI など複数のターミナル型AIエージェントを並列実行する運用は、これまで
git worktreeを手作業で切るか、parallel-code（GitHub 798スター、MITライセンス）のような軽量OSSでワークツリー生成を自動化するのが定番だった。 - 2026年に入り、この領域で Orca（
stablyai/orca）というOSSツールがGitHub 11.7kスター まで伸び、parallel-codeの約14.6倍の規模になっている。MITライセンス・macOS/Windows/Linux対応で、Claude Code・Codex・Cursor・OpenCode・Pi・GitHub Copilot・Devin など30以上のエージェントに対応する。 - Orca の本質は「ワークツリー自動化」そのものではなく、CLI経由でエージェント自身がOrcaを操作できる 設計にある。
orca worktree createでタスクを起票し、orca terminal sendでエージェントに指示を送り、orca snapshot/click/fillでブラウザまで操作できる。つまり「人間が並列実行を監督するツール」から「エージェントが並列実行を自己組織化するツール」へと設計思想がシフトしている。 - 本稿では公式ドキュメント・GitHubリポジトリの情報をもとに、インストール手順・基本フロー・CLIコマンド体系・既存ツールとの違いを整理する。
背景: 並列AIエージェント運用の定番だった git worktree
Claude Code や Codex のようなターミナル常駐型のAIコーディングエージェントを1つのリポジトリで複数同時に走らせると、同じ作業ディレクトリを取り合ってファイルの競合やブランチの混線が起きる。この問題を解決する標準的な方法が、Gitの標準機能である git worktree だ。1つの .git オブジェクトストアを共有したまま、ブランチごとに独立した作業ディレクトリを展開できる。
この手作業を自動化する軽量OSSとして知られてきたのが johannesjo/parallel-code（MITライセンス）で、タスク作成時に「ブランチ作成 → ワークツリー展開 → 依存ディレクトリのsymlink → エージェント起動」までを自動処理する。2026年7月時点でGitHub上のスター数は798件である。
Orca: スター数14.6倍で台頭したOSS
これに対し stablyai/orca は、同じ「並列ワークツリー」の思想を土台にしながら、対応範囲と自動化の粒度を大きく広げたOSSだ。GitHub上の情報は以下のとおり。
| 項目 | 内容 |
|---|---|
| スター数 | 11.7k |
| ライセンス | MIT |
| フォーク数 | 773 |
| 対応OS | macOS / Windows / Linux（デスクトップアプリ） |
| 対応エージェント | Claude Code, Codex, Cursor, OpenCode, Pi, GitHub Copilot, Devin など30以上 |
| モバイル | iOS（App Store / TestFlight）、Android（APK） |
| 最新バージョン | v1.4.121（2026年7月4日リリース） |
公式サイトでは「Agent Development Environment（ADE）」を名乗っており、1つのプロンプトを複数のワークツリーへ分岐させ、異なるエージェントに同じタスクを解かせて結果を比較・マージするという使い方が中核コンセプトとして紹介されている。
インストール方法
公式ドキュメントによると、インストール経路は複数用意されている。
# macOS（Homebrew）
brew install --cask stablyai/orca/orca
Windows・Linuxではそれぞれ orca-windows-setup.exe / orca-linux.AppImage が公式サイト（onorca.dev）から配布されている。
基本フロー: 最初の3エージェントセッション
公式ドキュメント「Your first 3-agent session」では、次の手順が案内されている。
- サイドバーの「Add Repo」でローカルのリポジトリを追加する（Orcaが分岐元のbase refを自動設定する）
- リポジトリ名の隣の「+」でタスク名（例:
fix-login-race）を入力し、起点ブランチを選ぶとOrcaが実際のgit worktreeを生成してブランチをチェックアウトする - agent comboboxからClaude Code・Codex・Cursor CLIなど対応エージェントを選択する（正しい作業ディレクトリで起動し認証情報が引き継がれる）
- 手順2〜3をさらに2回繰り返し、3つの独立したワークツリーで同一プロンプトを異なるエージェントに実行させる
- タブを分割ペインにドラッグして3エージェントの出力を同時監視する
- 各ワークツリーのdiffビューを開き、「Annotate AI Diff」でインラインコメントを付けて狙ったエージェントに差し戻し、採用する案を「Commit and push directly from Orca」で統合する
この一連の流れが、Orcaが謳う「複数のAIに同じタスクを競わせて最良の結果を選ぶ」というワークフローの実体である。
Orca CLI: エージェントがエージェントを操作する自動化層
Orcaが parallel-code などの既存ツールと最も異なる点は、GUI操作の大半をCLIコマンドとして公開していることだ。公式CLIリファレンスには次のようなコマンド体系が定義されている。
# ワークツリー操作
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca worktree ps --json
orca worktree rm --worktree id:<id> --force --json
# ターミナル操作（agent自身への指示送信も可能）
orca terminal send --text "continue" --enter --json
orca terminal wait --for tui-idle --timeout-ms 30000 --json
# ブラウザ操作（フロントエンド確認の自動化）
orca snapshot --json
orca click --element @e3 --json
orca fill --element @e1 --value "user@example.com" --json
いずれのコマンドも --json オプションで構造化出力を返せるため、Orca自身をエージェントのツールとして呼び出す ことができる設計になっている。つまり、人間がGUIでワークツリーを作ってエージェントを配置するのではなく、上位のオーケストレーター役エージェントが orca worktree create でタスクを増殖させ、orca terminal wait で完了を待ち、orca snapshot でブラウザの見た目まで確認する、という自己組織的な運用が可能になる。
既存ツールとの違い
| 観点 |
git worktree（素の手動運用） |
parallel-code（798スター） |
Orca（11.7kスター） |
|---|---|---|---|
| ワークツリー自動生成 | 手動 | 自動 | 自動 |
| 対応エージェント数 | 制限なし（手動起動） | 数種（Claude Code・Codex CLI等） | 30以上 |
| CLIによる外部からの操作 | 不可 | 限定的 | worktree/terminal/file/browser/emulatorの全操作をCLI公開 |
| モバイルからの監督 | 不可 | 不可 | iOS/Androidアプリ対応 |
| ブラウザ・エミュレータ操作 | 不可 | 不可 | 対応（フロントエンド確認まで自動化） |
著者視点の発見ポイント
各ツールの公開情報を横断して整理すると見えてくるのは、この領域の競争軸が「ワークツリーを誰が自動生成するか」から「並列実行された結果を誰がどう検証・統合するか」へ移っている点だ。parallel-code はワークツリー生成の自動化止まりだが、Orcaはブラウザ操作・エミュレータ操作・GitHub/Linear連携までを1つのCLI体系に収め、しかもその全操作を --json で機械可読にしている。これは「人間がGUIで監督する」設計から「上位エージェントがCLI経由で下位エージェント群を運用する」設計への移行を示しており、並列AIエージェント運用のOSS選定基準は今後「対応エージェント数」よりも「CLI/API経由でどこまで外部から制御できるか」に寄っていく可能性が高い。
まとめ
- 並列AIエージェント運用OSSの主流は、ワークツリー自動生成の軽量ツール（
parallel-code798スター）から、CLI全操作を公開した高機能ツール（Orca 11.7kスター）へシフトしている - Orcaの差別化ポイントは対応エージェント数の多さだけでなく、
worktree/terminal/browser/emulatorの全操作をJSON出力付きCLIで公開している点にある - 導入する場合は「Your first 3-agent session」の手順（リポジトリ追加 → ワークツリー作成 → エージェント選択 → diffレビュー → 統合）から始めるのが公式の推奨導線