複数のAIコーディングエージェントを同時に走らせる——この「並列エージェント」という言葉は、2026年のAI開発現場で急速に一般化した。だが実際に技術記事を読み比べると、同じ「並列エージェント」でも指しているものがまるで違う。ある記事は「LangGraphで複数ノードを並行実行する制御構造」を指し、別の記事は「Claude CodeとCodexをターミナルで並べて走らせること」を指す。さらに別の文脈では「OpenHandsやDevinのような自律エージェントを複数インスタンス立てること」を意味する。
この混乱を解くのにちょうどいい題材が、stablyai/orca（★約16,000、TypeScript・MIT）だ。Orcaは自らを「a fleet of parallel agents（並列エージェントの艦隊）を扱うADE（Agent Development Environment）」と位置づける。1つのプロンプトを5つのエージェントに扇形展開し、各々を独立したgit worktreeで走らせ、勝った結果をマージする——この設計は「並列エージェント」という抽象概念を、触れる形にまで具体化している。
本記事はOrcaを軸に、「並列エージェント」を ①ADE（実行環境）② フレームワーク ③自律エージェント の3つの層に切り分ける。そのうえで、フレームワーク層の代表であるLangGraph・CrewAI、自律エージェント層の代表であるOpenHands・Devinと、Orcaが担う層がどう違い、どう組み合わさるのかを一次ソースから整理する。
AIエージェントフレームワーク全体の選定軸は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 で詳しく扱っています。本記事は「フレームワークの手前にある実行環境（ADE）」という切り口で、その比較を補完します。
- ・「並列エージェント」はADE・フレームワーク・自律エージェントの3層で意味が変わる。混同すると比較が噛み合わない。
- ・OrcaはADE層。Claude Code・Codex・OpenHandsなど既製のCLIエージェントを、git worktreeで隔離して並列実行する実行環境。
- ・LangGraph・CrewAIはフレームワーク層。エージェントの振る舞いをコードで組み立てる。Orcaの代替ではなく組合せ対象。
- ・OpenHands・Devinは自律エージェント層。Orcaはこれらを「1ペインで走らせる側」で、競合ではなく指揮所。
- ・並列エージェント運用の落とし穴（ディスク肥大・レート制限競合・レビュー負荷）と、3層の使い分け判断軸を提示。
1. 並列エージェントとは何か：1つのプロンプトを艦隊に扇形展開する
まず「並列エージェント」という言葉が指す最も直感的なイメージから始める。Orcaの公式リポジトリは、その中核体験をこう表現している。「Fan one prompt across five agents, each in its own isolated git worktree — compare the results and merge the winner.（1つのプロンプトを5つのエージェントに扇形展開し、各々を隔離されたgit worktreeで走らせ、結果を比較して勝者をマージする）」。
これが並列エージェントの一番わかりやすい形だ。従来のAIコーディングは「1人の開発者 ↔ 1つのアシスタント」の対話だった。GitHub Copilotはエディタに1つ常駐し、Cursorはチャットを1ウィンドウに出す。CLIネイティブなClaude CodeやCodexも、1ターミナル1セッションでの会話を軸にしている。
並列エージェントはこの前提を裏返す。「1人の開発者 ↔ N体のエージェント」だ。使い方は大きく2系統ある。
系統A：同じタスクを複数エージェントに競わせる（fan-out / N-best）。「このバグを直して」という同じプロンプトを、Claude Code・Codex・Grokの3体に同時に投げ、3つの異なる解を得て、いちばん筋のいいものを採用する。LLMは同じ問いに毎回違う答えを返すため、複数解の比較は品質を底上げする。
系統B：異なるタスクを複数エージェントに分担させる（fleet / 分業）。Claude Codeに認証機能、Codexに課金機能、Grokにリファクタリングを同時並行で任せる。人間は各エージェントの進捗を監督し、上がってきた差分をレビューして統合する。
系統Aも系統Bも、共通して直面する問題が「どうやってN体の作業を混ざらないように隔離するか」だ。3体が同じディレクトリ・同じブランチで動けば、ファイルの上書き合戦になる。git stash で退避し合えば、その管理だけで1日が終わる。並列エージェントを実務で成立させる鍵は、この隔離の設計にある。そしてOrcaはその答えとして「git worktree」を選んだ。次章で仕組みを見る。
2. Orcaの並列エージェント・アーキテクチャ：git worktreeで隔離する仕組み
Orcaの設計思想を一言でいえば「worktree-native」だ。READMEの機能リスト先頭に「Every feature gets its own worktree. No stashing, no branch juggling.（機能ごとに専用のworktreeを与える。スタッシュも、ブランチのお手玉もいらない）」と明記されている。
git worktreeに馴染みのない読者向けに整理すると、git worktree add は1つのリポジトリから複数の作業ディレクトリを切り出す機能だ。各worktreeは独立したブランチをチェックアウトでき、.git 本体を共有しつつファイルツリーだけを分ける。git stash で作業を退避する必要がなく、ディレクトリを移動するだけで別の作業状態に切り替わる。
Orcaはこのworktreeを各エージェントに1対1で割り当てる。Claude Codeで機能Aを実装中に、Codexに機能Bを依頼すれば、それぞれが別ディレクトリ・別ブランチで動き、互いのファイル変更が干渉しない。最終的にPRを統合する段階で初めてgitのmergeが走る。
並列エージェントのデータフロー
(1 リポジトリ)"] WT1["Worktree A
feature/auth"] WT2["Worktree B
feature/billing"] WT3["Worktree C
fix/login-bug"] A1["Claude Code
並列エージェント1"] A2["Codex
並列エージェント2"] A3["OpenHands
並列エージェント3"] UI["Orca ADE
統一UI・diffレビュー"] Repo --> WT1 Repo --> WT2 Repo --> WT3 WT1 --> A1 WT2 --> A2 WT3 --> A3 A1 --> UI A2 --> UI A3 --> UI UI -->|"レビュー後にマージ"| Repo
この構造の効能は3つに整理できる。
第一に、エージェント間の状態汚染がゼロになる。Claude CodeがファイルXを編集中にCodexが同じファイルXを触っても、別worktreeに分離されているため衝突が起きない。並列エージェントの最大の敵である「作業の混線」を、gitの標準機能で根本から絶つ。
第二に、git stash の運用負荷が消える。「いま動かしているClaude Codeを止めてCodexで別案を試したい」という場面で、退避→ブランチ切替→作業→復帰、という手数が要らない。新しいworktreeを切ってそこにエージェントを置くだけだ。
第三に、レビューが1か所に集約される。Orcaは各worktreeのdiffを内蔵ビューアに集約し、AI生成コードをそのままレビュー・注釈・コミットできる。GitHub / Linear のPR・Issue・チェックも各worktreeに紐づくため、レビュー画面とエディタを往復しなくていい。
ここで重要なのは、Orcaはエージェントの「中身」には一切関与しないという点だ。Claude Codeがどんなプロンプトで、どんな推論をして、どんなツールを呼ぶか——それはClaude Code側の責務であり、Orcaは「そのプロセスを起動し、worktreeを与え、出力を集約する」実行環境（ADE）に徹する。この責務分担こそが、次章で見る「3層モデル」の出発点になる。Orcaを単独のツールとしてより深く知りたい場合は、IDEとしての全機能を解剖した Orca｜Claude Code・Codex並行実行のAIエージェントIDE、Worktree戦略を解剖 を参照してほしい。本記事はそこから一歩引いて、Orcaを「並列エージェントの地図」の中に位置づける。
3. 「並列エージェント」は3層に分かれる：ADE・フレームワーク・自律エージェント
ここが本記事の核心だ。「並列エージェント」という言葉が噛み合わない最大の原因は、まったく異なる3つの層を同じ言葉で呼んでいることにある。この3層を分けると、OrcaとLangGraph・CrewAI・OpenHands・Devinの関係が一気に見通せる。
3つの層の役割
| 層 | 役割 | 「並列」の意味 | 代表例 |
|---|---|---|---|
| ①実行環境（ADE） | 既製エージェントを起動・隔離・監督する指揮所 | 複数のCLIエージェントプロセスをworktreeで並走 | Orca、agent-viewer |
| ②フレームワーク | エージェントの振る舞いをコードで組み立てる骨組み | 1アプリ内で複数のノード/エージェントを並行制御 | LangGraph、CrewAI、AutoGen |
| ③自律エージェント | 実際にコードを書く・タスクを遂行する本体 | 同一エージェントの複数インスタンスを同時起動 | OpenHands、Devin、Claude Code |
この3層は上下関係にある。自律エージェント（③）はフレームワーク（②）で作られることもあれば、単体の製品として提供されることもある。そしてそれらの実行・監督を担うのが実行環境（①）だ。
具体例で結ぶとこうなる。「LangGraph（②）で組んだリサーチエージェントをCLI化し、それをOrca（①）の1つのworktreeで走らせる。隣のworktreeではOpenHands（③）にバグ修正を任せ、さらに隣ではClaude Code（③）に別機能を実装させる」——これらは競合ではなく、垂直に積み重なる。
なぜこの区別が実務で効くのか
層を混同すると、選定でこういう不毛な比較が起きる。「OrcaとLangGraph、どっちを使うべき？」——これは「VS CodeとReact、どっちを使うべき？」と問うのに近い。前者は実行・編集の環境、後者は中身を作る道具で、そもそも並べる対象ではない。
正しい問いはこうだ。
・中身を自分で作りたいのか、既製品を動かしたいのか → 作るならフレームワーク層（LangGraph/CrewAI）、動かすなら実行環境層（Orca）
・1つのアプリに閉じた並列制御か、複数プロセスの並列運用か → 前者はフレームワーク、後者はADE
・エージェントの推論ロジックを触りたいのか、艦隊の監督だけしたいのか → 触るならフレームワーク、監督だけならADE
この地図を持ったうえで、次の2章でフレームワーク層（LangGraph・CrewAI）と自律エージェント層（OpenHands・Devin）を、Orcaと具体的に比較していく。
4. LangGraph・CrewAIとの比較：並列エージェントを「作る」層との違い
LangGraphとCrewAIは、フレームワーク層（②）の代表格だ。どちらも「エージェントの振る舞いをコードで組み立てる」ための道具であり、Orcaのように「既製エージェントを動かす」ものではない。まず2つのフレームワーク自体を整理する。
LangGraph は、LangChainチームが開発する、エージェントを「有向グラフのノード」としてモデル化するフレームワークだ。各ノードが状態（state）を共有し、条件分岐・ループ・人間の承認ステップ・永続実行（durable execution）を細かく制御できる。2026年時点で「本番運用のステートフルなエージェントの最も堅実な既定解」と評されることが多く、チェックポイントやタイムトラベル・デバッグを備える。並列は「グラフ内の複数ノードを同時に評価する」形で表現される。
CrewAI は、エージェントを「役割（role）・目標（goal）・背景（backstory）を持つ人間チームのメンバー」に見立てるフレームワークだ。タスクを各エージェントに割り当て、「クルー（crew）」として sequential / hierarchical / consensual といったプロセス型で実行する。人間のチーム編成の感覚に近く、プロトタイピングの学習コストが低いのが強み。並列は「複数のエージェントメンバーが同時にタスクを進める」形で表現される。
Orca・LangGraph・CrewAI 比較表
| 観点 | Orca | LangGraph | CrewAI |
|---|---|---|---|
| 層 | ①実行環境（ADE） | ②フレームワーク | ②フレームワーク |
| 主な役割 | 既製CLIエージェントの並列実行・監督 | ステートフルなエージェントをグラフで構築 | 役割ベースのエージェントチームを構築 |
| 「並列」の対象 | CLIプロセス×git worktree | グラフのノード | クルー内のメンバー |
| 記述方法 | ノーコード（GUI／Orca CLI） | Python / JS（低レベル制御） | Python（高レベル・宣言的） |
| エージェント本体 | 作らない（既製を使う） | 自分で実装する | 役割定義で組み立てる |
| 隔離の単位 | ファイルシステム（worktree） | プロセス内の状態 | プロセス内のタスク |
| 得意領域 | コーディング艦隊の監督 | 長時間・分岐の多い本番ワークフロー | 業務ワークフローの高速試作 |
| ライセンス | MIT | MIT | MIT |
この表から読み取れる本質は、OrcaとLangGraph/CrewAIは「並列」の対象が物理的に違うという点だ。フレームワークの並列は「1つのPythonプロセスの中で複数のエージェントロジックを同時に走らせる」ソフトウェア的な並行性。Orcaの並列は「OSレベルで複数のCLIプロセスを、別々のファイルツリーで走らせる」物理的な並行性だ。
だから両者は競合しない。むしろ相補的だ。LangGraphで作った高度なエージェントをCLIエントリポイント付きでパッケージすれば、それはOrcaにとって「1つの動かせるCLIエージェント」になる。Orcaの公式スタンス「Works with any CLI agent — if it runs in a terminal, it runs in Orca.（ターミナルで動くなら、Orcaで動く）」は、フレームワーク製の自作エージェントにもそのまま当てはまる。
・フレームワーク層を選ぶべき場面：エージェントの内部ロジック（ツール選択、状態遷移、ガードレール）を自分で設計・制御したいとき。
・ADE層（Orca）を選ぶべき場面：Claude Code・Codexのような完成度の高い既製エージェントを、複数同時に監督したいとき。ロジックを書く必要はない。
5. OpenHands・Devinとの比較：自律エージェントとADEの役割分担
OpenHandsとDevinは、自律エージェント層（③）の代表だ。ここが最も誤解されやすい。「Orca vs Devin」という比較を見かけるが、これも層の取り違えで、実際にはOrcaはDevinやOpenHandsを動かす側にいる。
OpenHands（旧OpenDevin、All-Hands-AI）は、OSSの自律ソフトウェアエンジニアだ。コードの読み書き、コマンド実行、ブラウザ操作までをエージェントが自律的に行い、SWE-Bench系のベンチマークで高いスコアを出している。MCP経由でGitHub/GitLabに接続し、マージ前レビューでバグや脆弱性を検出する使い方もできる。OSSなのでローカルにもセルフホストにも置ける。詳細は OpenHands完全ガイド：SWE-Bench 77.6%のOSS AIコーディングエージェント徹底解説 で扱っている。
Devin（Cognition Labs）は、クローズドソースの商用自律ソフトウェアエンジニアだ。「AIソフトウェアエンジニア」として2024年に大きな注目を集めたパイオニアで、計画立案からPR作成までを自律で回す。商用SaaSとして提供され、内部アーキテクチャは非公開である。
Orcaとの関係を図で押さえておく。
Orca・OpenHands・Devin 比較表
| 観点 | Orca | OpenHands | Devin |
|---|---|---|---|
| 層 | ①実行環境（ADE） | ③自律エージェント | ③自律エージェント |
| 本質 | 艦隊の指揮所 | 自律SWEエージェント本体 | 自律SWEエージェント本体 |
| ソース | OSS（MIT） | OSS（MIT系） | クローズド（商用SaaS） |
| コードを書くのは | 起動した各エージェント | OpenHands自身 | Devin自身 |
| 並列運用の形 | worktreeで複数エージェント並走 | 複数インスタンス起動 | 商用プラン内で複数タスク |
| Orcaとの関係 | — | Orcaの1ペインで走らせ可能 | CLI提供があれば同様に可能 |
| セルフホスト | ローカルアプリ | 可能 | 不可（クラウド） |
構図はこうだ。OpenHandsやDevinは「コードを書く手」であり、Orcaは「複数の手を同時に動かして監督する頭」である。だからこの2者も競合ではない。OrcaはOpenHandsを1つのworktreeで走らせ、隣のworktreeでClaude Codeを走らせ、両者の差分を1画面でレビューする——という運用が成立する。
ただし現実的な注意点もある。DevinのようなクローズドSaaSは「ターミナルで動くCLIとして起動できるか」が組み込みの条件になる。CLIやAPIが提供されていればOrcaの管理下に置けるが、Web UIに閉じている機能はADEからは扱えない。OSSのOpenHandsはローカルでCLI起動できるため、Orcaとの相性は良い。
・自律エージェント層を選ぶべき場面：「タスクを丸ごと任せて、PRまで自律で作らせたい」とき。手を選ぶ。
・ADE層（Orca）を重ねるべき場面：その自律エージェントを複数体・別タスクで同時に動かし、人間が1か所で監督したいとき。指揮所を足す。
6. 並列エージェントを実際に動かす：Orcaのセットアップと運用フロー
3層の地図を持ったところで、ADE層の実物であるOrcaを実際に動かす流れを見る。Orcaはログイン不要で、ローカルにインストール済みのCLIエージェント（claude・codex・gemini など）を自動検出する。
インストール
READMEはインストール経路を複数示している。macOSはHomebrew Caskが最短だ。
# macOS: Homebrew Cask 経由（初回のみtapが自動追加される）
brew install --cask stablyai/orca/orca
# バージョン確認
orca --version
# Arch Linux: AUR（ビルド済みバイナリで高速インストール）
yay -S stably-orca-bin
Homebrew / AUR を使わない環境では、公式サイト onOrca.dev または GitHub Releases から直接インストーラーを取得する。Orcaは「we ship daily（毎日出荷する）」を公言しており、常に最新版を取る releases/latest を使うのが確実だ。
# Linux: 常に最新のAppImageを取得して起動
wget https://github.com/stablyai/orca/releases/latest/download/orca-linux.AppImage
chmod +x orca-linux.AppImage
./orca-linux.AppImage
並列エージェントを起動する流れ
起動後の基本フローは4ステップに集約できる。
- リポジトリを開く：gitリポジトリをドラッグ&ドロップすると、Orcaがworktreeルートを準備する。
- worktreeを切ってエージェントを割り当てる：タスクごとに新しいworktreeを作り、Claude CodeやCodexを紐づける。
- プロンプトを投げる：単一エージェントに指示するか、同じプロンプトを複数エージェントに扇形展開（fan-out）する。
- 差分をレビューしてマージする：各worktreeの差分を内蔵ビューアで確認し、注釈を付け、勝った結果をコミット・マージする。
Orcaはこのフローをコマンド化する Orca CLI も備える。エージェント自身がOrcaを操作し、ワークフローをスクリプト化できる。
# Orca CLI: エージェント/自動化からOrcaを操作する例
orca worktree create feature/search # 新しいworktreeを作成
orca snapshot # 現在の画面状態をキャプチャ
orca click "#run-tests" # UI要素をクリック（Computer Use）
orca fill "#prompt" "検索機能を実装して" # プロンプト欄に入力
さらにOrcaはモバイルcompanionアプリ（iOS/Android）とSSHワークツリーを備え、外出先からエージェントの進捗監視・追加指示ができ、リモートサーバー上のworktreeでエージェントを走らせることもできる。「1時間かかるリファクタリングを依頼して外出し、終わったらスマホで結果を確認して追加指示を送る」——並列エージェント運用が物理的なデスクから解放される。
7. 並列エージェント運用の落とし穴と3層の使い分け指針
並列エージェントは強力だが、無条件に速くなる魔法ではない。運用してみると見えてくる落とし穴と、3層をどう使い分けるかの判断軸を最後に整理する。
並列エージェント運用の落とし穴
第一に、worktreeの数だけディスクが線形に膨らむ。各worktreeは独立した作業ディレクトリを持つため、大規模リポジトリで10本のworktreeを並走させると、リポジトリサイズの数倍のディスクを消費しうる。不要になったworktreeはこまめに削除する運用が要る。
第二に、API・レート制限の競合。Claude CodeとCodexを別worktreeで動かしても、同じアカウントを使えば従量課金やレート制限は共有される。並列度を上げるほど、推論コストとレート上限が律速になる。Orcaは使用量トラッキングでこの可視化を助けるが、上限そのものは各サブスクリプション側の制約だ。
第三に、そして最も本質的なのが、レビュー負荷の集中。並列エージェントは「書く」速度を上げるが、「レビューする」速度は人間側にボトルネックが残る。5体のエージェントが5本の差分を上げてくれば、レビュー対象も5倍になる。Orcaのdiff注釈・集約レビューはこの緩和を狙った機能だが、最終的な品質責任は人間に残る。並列度は「自分がレビューをさばける本数」で決めるのが現実的だ。
- ・worktreeは使い終わったら削除する。放置するとディスクとブランチが際限なく増える。
- ・並列度は「同時にレビューできる差分の本数」を上限に設定する。書く速度よりレビュー速度が律速。
- ・各CLIエージェントの認証情報（APIキー・OAuthトークン）はローカル管理。BYOS型ゆえ鍵の扱いは自己責任。
- ・SSHワークツリーを使う場合は、リモート側のSSHキー・権限管理を別途整備する。
3層の使い分け：結局どれを選ぶべきか
- ・実行環境（ADE / Orca）：Claude Code・Codexなど既製エージェントを複数同時に監督したい。ロジックは書かず、艦隊の指揮所が欲しい。
- ・フレームワーク（LangGraph / CrewAI）：エージェントの内部ロジック（状態遷移・役割分担・ガードレール）を自分で設計・制御したい。
- ・自律エージェント（OpenHands / Devin）：タスクを丸ごと任せてPRまで自律で作らせたい。コードを書く「手」が欲しい。
- ・組合せ：フレームワークで作った自律エージェントをCLI化し、ADE（Orca）で複数並走させる——3層は垂直に積める。
多くのチームにとっての現実解は「まずADE層から入る」ことだ。Claude CodeやCodexの契約を既に持っているなら、Orcaで2本のworktreeを切り、系統B（別タスク分担）を試すのが最も学習コストが低い。git worktreeの感覚に慣れてから、系統A（fan-out競争）や、フレームワーク層での自作エージェント、自律エージェントの組み込みへと段階的に広げるのがよい。
逆に、単一のアシスタントで足りる小規模プロジェクトに並列エージェントは過剰だ。Cursor単体やClaude Codeのターミナル直接利用で十分な場面に、worktree運用のオーバーヘッドを持ち込む必要はない。並列エージェントは「同時に進めたい独立タスクが常に2つ以上ある」開発体制で初めて元が取れる。
まとめ
- ・「並列エージェント」は実行環境（ADE）・フレームワーク・自律エージェントの3層で意味が変わる。混同すると比較が噛み合わない。
- ・Orca（★約16,000・MIT）はADE層。既製CLIエージェントをgit worktreeで隔離し、1画面で並列実行・監督する指揮所。
- ・LangGraph・CrewAIはフレームワーク層で「並列」の対象はプロセス内のノード。Orcaの代替ではなく、作ったエージェントをOrcaで走らせる組合せ対象。
- ・OpenHands・Devinは自律エージェント層。Orcaはこれらを動かす側で、競合ではなく「複数の手を監督する頭」。
- ・落とし穴はディスク肥大・レート制限競合・レビュー負荷。並列度は「レビューできる本数」で決めるのが現実的。
AIエージェントが量産モードに入った2026年、必要なのは「もう1つのアシスタント」ではなく「艦隊全体を見渡す指揮所」だ。そして技術選定で最初にすべきは、自分が欲しいのがADEなのか、フレームワークなのか、自律エージェント本体なのかを見極めることだ。Orcaはこの3層のうち最上位——並列エージェントを実際に走らせて監督する実行環境——を、git worktreeという枯れた仕組みの上に構築した。公開から数ヶ月で★約16,000に達したスピードは、この「指揮所」への需要の大きさを映している。
まずは既存のClaude Code契約でworktreeを2本切り、並列エージェントの手触りを確かめるところから始めてほしい。3層の地図を持っていれば、次に足すべきピースがフレームワークなのか自律エージェントなのか、迷わず選べるはずだ。
参照ソース
- stablyai/orca — GitHub — 公式リポジトリ。READMEに「fan one prompt across five agents」「worktree-native」など並列エージェントの設計思想と対応エージェント一覧、インストール手順が網羅されている。
- Orca Releases（チェンジログ） — 「毎日出荷する」Orcaの事実上の最新機能一覧。バージョンと新機能の追加状況はここで確認できる。
- Orca — onOrca.dev — 公式サイト。worktrees / terminal / design-mode / ssh / agents など各機能の詳細ドキュメント。
- LangGraph — GitHub — フレームワーク層の代表。エージェントをグラフのノードとして状態管理・分岐・永続実行する設計。
- OpenHands — GitHub — 自律エージェント層の代表。OSSの自律ソフトウェアエンジニアで、Orcaから1ペインで走らせられる。
