AIコーディングエージェントの並列実行にOrcaが選ばれる理由

Claude Code や Codex を 1 つ動かすだけなら、ターミナルを開いてプロンプトを入れれば済みます。ところが「リファクタリングとバグ修正と検証スクリプトの作成を同時に進めたい」と思った瞬間に、話は一気に面倒になります。同じワーキングツリーで複数のエージェントを走らせればファイルが競合し、git worktree を切れば今度は worktree ごとに依存関係を入れ直す羽目になります。

対処法として広く知られているのが git worktree を使った並列化です。日本語でも運用ノウハウの記事は充実していて、worktree の切り方や .env の配り方まで丁寧に書かれたものが多数あります。ただし、そこから先の「では、どのツールに乗るべきか」という問いに答えてくれる情報はあまりまとまっていません。手動運用を続けるのか、専用ツールを導入するのか、導入するならどれなのか。この判断材料が散らばっているのが現状です。

この領域で 2026 年に入ってから急速にスターを集めているのが、Stably AI が公開している stablyai/orca です。Orca は自らを IDE ではなく ADE（Agent Development Environment） と位置づけ、複数の AI コーディングエージェントをそれぞれ独立した git worktree で走らせ、ターミナル・エディタ・ブラウザ・差分レビューまでを 1 つのアプリケーションに束ねます。

もっとも、git worktree でエージェントを隔離するという発想自体は Orca 固有のものではありません。類似 OSS も同じ隔離単位を採用しています。差が出るのは worktree の外側にどこまで統合されているか と プロジェクトの更新状況 の 2 点です。

本記事では、Orca の基本情報とリポジトリ指標、worktree ネイティブ設計の中身、対応エージェントと統合機能の範囲、SSH・モバイル・CLI といったデスクトップ外への展開、そして vibe-kanban・claude-squad・Crystal との比較を経て、採用前に確認しておきたい判断ポイントまでを整理します。

なお本記事は、公開されている README・公式サイト・公式ドキュメント、および GitHub API から取得したメタデータのみに基づいて構成しています。ローカル環境へのインストールや実行による動作検証は行っていないため、パフォーマンスや使用感の評価は含みません。数値はいずれも 2026 年 8 月 28〜29 日時点で取得した値です。

AIコーディングエージェントの並列実行で詰まるポイント

ツールの話に入る前に、「並列実行支援ツールが何を解決する道具なのか」を先に定義しておきます。単一エージェント運用から複数エージェント運用に移すと、おおむね次の 5 つが詰まりどころになります。

• 同一ワーキングツリーでのファイル競合: 2 つのエージェントが同じリポジトリで同時にファイルを書き換えると、片方の編集がもう片方の前提を壊します。git のコンフリクト以前に、テストが何を検証しているのか分からなくなります
• worktree ごとの依存関係・環境変数の再構築: git worktree add で作られるのはクリーンなチェックアウトです。node_modules もビルドキャッシュも .env も入っていないため、worktree を切るたびに再インストールと再配置が発生します
• 進捗の把握が難しい: 3 つのエージェントを走らせると、どれが待機中でどれが完了したのかを追うためにターミナルのタブを行き来することになります。離席して戻ってきたときに「どれが止まっていたのか」が分からなくなりがちです
• 差分レビューがターミナルの外に分散する: エージェントの出力を確認するにはエディタや GitHub を開き直す必要があり、「この行はこう直してほしい」というフィードバックを返す経路も別に用意しなければなりません
• アカウントとレートリミットの管理: 複数エージェントを並列で回すと、サブスクリプションのレート上限に当たる頻度が上がります。どのアカウントがいつリセットされるのかを把握できないと、待ち時間が読めません

この 5 つは、以降のセクションで Orca のどの機能が対応するのかを 1 つずつ突き合わせていきます。逆に言えば、この中に自分の困りごとが含まれていないのであれば、Orca は守備範囲外のツールということになります。

OrcaとはどんなOSSか｜基本情報と位置づけ

Orca は、Stably AI（サンフランシスコ拠点、Y Combinator 支援）が MIT ライセンスで公開しているデスクトップアプリケーションです。公式サイトは onorca.dev、ソースコードは stablyai/orca で公開されています。

基本情報

GitHub API から取得したリポジトリのメタデータは以下のとおりです。

このリポジトリはアーカイブされておらず（archived: false）、他リポジトリのフォークでもありません（fork: false）。ライセンスも MIT が明示されているため、ライセンス未設定リポジトリにありがちな利用条件の不透明さはありません。README にも「Orca is free and open source under the MIT License.」と記載されています。

数値の読み取りとしては、リポジトリ作成が 2026 年 3 月 17 日、本記事執筆時点が 8 月末ですから、公開からおよそ 5 か月で 56,102 スターという速度になります。一方でオープン中の issue が 4,778 件積み上がっている点も同時に事実として押さえておく必要があります。この 2 つの数字の解釈は、後半の採用判断のセクションで扱います。

README は多言語で用意されており、中国語・日本語・韓国語・スペイン語・フランス語・ポルトガル語版が同梱されています。日本語で概要を把握したい場合は、リポジトリ内の docs/readme/README.ja.md が起点になります。

ADEという位置づけ

Orca が自らを説明するときに使うのが ADE（Agent Development Environment）という語です。公式サイトのスローガンは「Ship 100x With The Agent IDE」、README のキャッチコピーは「The AI Orchestrator for 100x builders.」となっており、いずれも「人間がコードを書くための環境」ではなく「複数のエージェントを走らせて束ねるための環境」という立て付けになっています。

具体的には、README が挙げる中心的なユースケースが「Run Codex, ClaudeCode, OpenCode or Pi side-by-side — each in its own worktree, tracked in one place.」です。同時実行（side-by-side）、それぞれ専用の worktree（each in its own worktree）、一箇所での追跡（tracked in one place） の 3 点が、従来の IDE との差分にあたります。

従来の IDE は「1 人の開発者が 1 つの作業ツリーを編集する」ことを前提に最適化されてきました。エージェントを 3 つ 5 つと並べる前提に置き換えると、必要になるのはコード補完の賢さよりも、隔離・監視・比較・マージの導線です。ADE という呼び方は、この前提の置き換えを示すためのラベルだと理解すると分かりやすくなります。

なお、日本語で「ORCA」を検索すると医療系のレセプトコンピュータが上位に出てきますが、本記事で扱う Orca はそれとは無関係な、AI コーディングエージェント向けの OSS です。

Orcaの中核｜git worktreeでエージェントを隔離する仕組み

Orca の設計の中心は git worktree です。公式ドキュメントの worktree モデル では、各タスクが git worktree によってリポジトリのディスク上の個別コピーを持つと説明されており、各 worktree は「独自のブランチ」「ディスク上の独自のファイル」「独自のエージェントターミナル」を独立して保有します。

先に挙げた詰まりどころのうち、同一ワーキングツリーでのファイル競合はこの隔離によって構造的に解消されます。エージェント A が触るファイルとエージェント B が触るファイルは物理的に別ディレクトリにあるため、そもそも競合しません。

重要なのは、Orca では worktree が「git のコマンドで作るディレクトリ」ではなく アプリケーション全体のスコープ単位 になっている点です。エージェントターミナルもエディタも組み込みブラウザも、すべて選択中の worktree にスコープされます。ターミナルだけが worktree ごとに分かれていて、エディタは常にプライマリチェックアウトを見ている、という状態にはなりません。

worktreeの作成からアーカイブまでの流れ

公式ドキュメントは worktree のライフサイクルを 5 段階で説明しています。

1. 作成: タスク名、ブランチの分岐元、GitHub / Linear / Jira などのリンクを指定して作成します。作成処理はバックグラウンドで実行され、ダイアログはすぐ閉じます
2. 作業: エージェント・エディタ・ターミナルが当該 worktree の隔離環境にスコープされた状態で作業します
3. レビュー: 作業開始時点の ref と比較した差分を確認します。AI によるアノテーション支援があります
4. 出荷: コミット・プッシュ・PR チェックの管理をインラインで実行します
5. アーカイブまたは削除: worktree と関連ブランチを削除します

ブランチ名は workspace 名や GitHub PR、Linear、Jira、GitLab の情報から自動的に導出されます。手動で指定したい場合は Advanced オプションから設定できます。削除時は worktree ディレクトリとブランチの両方が対象になりますが、未マージのコミットが残っている場合は git がローカルブランチを保持するため、作業内容がいきなり消える構造にはなっていません。

また、Orca の外部で git worktree add によって作成した worktree も、Orca 側に認識させて同じ画面で管理できます。既に手動での worktree 運用を回しているチームが、既存の worktree を捨てずに移行できる設計になっています。

依存関係とキャッシュをworktree間で共有する3つの方法

手動での worktree 運用で最も面倒なのが、クリーンチェックアウトゆえの依存関係の欠落です。Orca はこの点に対して 3 つの補完機構を用意しており、公式ドキュメントによればこれらは加算的に重ねて使えます。

出典: Worktrees — Orca Docs

この 3 つの使い分けは、共有してよいものとworktree ごとに独立させたいものの切り分けとして理解できます。node_modules のように再構築可能で巨大なものは worktree.sharedDirectories で共有し、.env のように worktree ごとに書き換わりうるものは .worktreeinclude でコピーして独立させる、という整理です。なお .worktreeinclude はリテラルパスのみを解釈し、glob や否定パターンは無視される点に注意が必要です。

裏を返せば、worktree の数だけディスクを消費する構造そのものは変わりません。共有できるのは gitignore 済みの再構築可能なツリーであり、リポジトリ本体のチェックアウトは worktree ごとに存在します。大規模なモノレポで 5 つも 10 つも worktree を並べる想定なら、ディスク容量は導入前に見積もっておくべき項目です。

対応エージェントとOrcaの機能範囲

「自分が使っているエージェントが乗るのか」は、この種のツールを検討するときに最初に確認したい点です。

対応エージェントとアカウント運用

公式の 対応エージェント一覧 によれば、Orca は「any CLI agent」を対象としており、40 以上のエージェントがプリセットとして登録済みです。README にも「Works with any CLI agent — if it runs in a terminal, it runs in Orca.」と記載があり、ターミナルで動くものであれば動作対象という方針が示されています。

プリセットとして名前が挙がっているのは Claude Code、Codex、Grok、Cursor、GitHub Copilot、OpenCode、Amp、Gemini、Devin、Goose、Cline、Continue、Kiro、Qwen Code など多岐にわたります。Claude Code と Codex については、単にターミナルで起動するだけでなく、より深い統合が用意されているとされています。プリセットにないエージェントも、Settings → Agents からカスタム設定を編集して登録できます。

アカウント周りでは、再ログインなしでアカウントを切り替える機能（hot-swap）と、Claude / Codex の使用量とレートリミットのリセットタイミングを確認する機能が README に挙げられています。これは先に挙げた アカウントとレートリミットの管理 という詰まりどころへの直接的な対応にあたります。

サブスクリプションの扱いについては、リポジトリの description に「Run any coding agent with your own subscription.」とあるとおり、自分のサブスクリプションで各エージェントを動かす前提の設計です。ただし、特定プランで具体的に何ができるかを明示した記述は公式ドキュメント上に見当たらなかったため、本記事ではプラン別の可否については断定しません。実際の利用可否は、各エージェント提供元の利用規約と合わせて確認してください。

ターミナル・エディタ・ブラウザ・レビューの統合

Orca が類似ツールと差をつけているのは、worktree の外側に何を持っているかです。README の Features に挙げられている主要機能を、先に整理した詰まりどころと対応づけると次のようになります。

この表から読み取れるのは、Orca が狙っているのが「worktree を切る作業の自動化」ではなく、エージェントに指示を出してから差分をレビューして PR にするまでの往復を、アプリケーションの外に出さずに完結させることだという点です。ターミナルとエディタとブラウザと GitHub を行き来する回数を減らすことが、統合の主目的になっています。

このアプローチには裏返しのコストもあります。ターミナル・エディタ・ブラウザをすべて内包するということは、既に使い込んでいる自分のターミナルエミュレータやエディタの設定を、Orca 側に持ち込めない部分が出てくることを意味します。既存の開発環境を強くカスタマイズしているほど、統合の恩恵と移行コストのバランスを見る必要が出てきます。

デスクトップの外へ｜SSHワークツリー・モバイル・Orca CLI

Orca のもう 1 つの軸が、ローカルのデスクトップアプリで完結しない設計です。

SSH ワークツリーは、高スペックのリモートマシン上でエージェントを実行する機能です。自動再接続とポートフォワードに対応しており、ローカルマシンのリソースが不足する場合や、社内の共有マシンで実行したい場合の選択肢になります。ヘッドレスな Linux サーバーで動かす運用については、リポジトリ内の docs/reference/headless-linux-server.md に orca serve を使ったガイドが用意されています。

モバイルコンパニオンは、iOS と Android 向けに提供されているアプリです。エージェントの完了通知を受け取り、スマートフォンから追加の指示を出せます。長時間動くタスクを走らせておき、離席中に完了通知を受けて次の指示を返す、という使い方が想定されています。

そして Orca CLI は、実行中の Orca をシェルからスクリプト化するためのインターフェースです。公式ドキュメントは CLI の目的を「script Orca from a terminal, manage worktrees, control agent terminals, automate the built-in browser, and install agent skills」と説明しています。

公式ドキュメントに掲載されているコマンド例を、worktree 操作から引用します。

orca worktree ps --json
orca worktree create --repo id:<repoId> --name my-task --issue 123 --json
orca worktree current --json
orca worktree rm --worktree id:<id> --force --json

出典: CLI Overview — Orca Docs

エージェントターミナルの制御も CLI から可能です。

orca terminal list --json
orca terminal send --text "continue" --enter --json
orca terminal wait --for tui-idle --timeout-ms 30000 --json
orca terminal create --worktree path:/projects/app --command "npm test" --json

出典: CLI Overview — Orca Docs

組み込みブラウザの自動化にも同じ CLI が使えます。

orca goto --url https://example.com --json
orca snapshot --json
orca click --element @e3 --json
orca screenshot --json

出典: CLI Overview — Orca Docs

すべてのコマンドに --json が用意されている点が示しているとおり、この CLI の主な想定利用者は人間ではありません。README には「Agents drive Orca too」という記述があり、エージェント自身が Orca を操作することが前提に置かれています。orca terminal wait --for tui-idle のように「別のエージェントの完了を待つ」コマンドが存在するのは、その意図の表れです。オーケストレーションの詳細は /docs/cli/orchestration に別ページが用意されています。

インストールについては、README の Install 節に以下の記載があります。

# macOS (Homebrew)
brew install --cask stablyai/orca/orca

# Arch Linux (AUR) — or stably-orca-git to build from source
yay -S stably-orca-bin

出典: stablyai/orca — Install

このほか、macOS（arm64 / x64 の dmg）・Windows（exe）・Linux（AppImage）の直接ダウンロードが onorca.dev/download から提供されています。Windows 版のコード署名は SignPath.io / SignPath Foundation の提供によるものです。

類似OSSとの違い｜vibe-kanban・claude-squad・Crystalとの比較

冒頭で触れたとおり、git worktree でエージェントを隔離するアプローチ自体は Orca 固有のものではありません。ここでは主要な類似 OSS 3 件と、比較の参考としてクローズドソース製品 1 件を並べます。

比較表

各リポジトリの数値は 2026 年 8 月 29 日時点で GitHub API から取得した値です。

補足として、Conductor（conductor.build）という macOS ネイティブの並列エージェント管理アプリも同じ領域に存在します。ただしこちらはクローズドソースであり、ソースの改変や自ホストができないため、本記事では GitHub 指標を伴う比較対象には含めず、選択肢の 1 つとして名前を挙げるにとどめます。

比較表で特に注目したいのが 最終 push の列 です。vibe-kanban は 2026 年 4 月 24 日以降、Crystal は 2026 年 2 月 26 日以降、公開リポジトリへの push が確認できません。この状況を裏づける情報として、vibe-kanban については開発元 Bloop の事業終了が伝えられており、Crystal については description そのものに「(Crystal is now Nimbalyst)」と記載され、Nimbalyst への改称・移行が示されています。事業終了や改称の経緯自体は二次情報ですが、各リポジトリの description と最終 push 日という一次情報でも同じ方向の事実が確認できるという点が判断材料になります。

なお、更新が止まっていることは即座に「使えない」を意味しません。vibe-kanban は Apache-2.0 で公開されておりコミュニティによる保守が続く可能性がありますし、Crystal も後継の Nimbalyst が存在します。ここで確認すべきなのは、そのプロジェクトが今後もアップストリームから機能追加を受け取れる見込みがあるかという点です。

条件別の選び分け

上記の表を、選定条件の側から整理し直すと次のようになります。

タスクボードでチームの作業を可視化したい場合は、vibe-kanban のアプローチが最も直接的です。カンバン形式でエージェントのタスクを並べる思想は、既存のプロジェクト管理ツールに近い運用感になります。ただし更新状況は上記のとおり確認が必要です。

ターミナル内で完結させたい場合は claude-squad が候補になります。tmux セッションと worktree を組み合わせた TUI として軽量で、既存のターミナル環境やキーバインドを崩さずに済みます。一方で GUI を持たないため、差分レビューやブラウザ連携、モバイル監視は範囲外です。ライセンスが AGPL-3.0 である点は、社内でのライセンス基準がある場合に必ず確認すべき項目です。

デスクトップアプリとして統合環境ごと乗り換えてよい場合は Orca が該当します。ターミナル・エディタ・ブラウザ・レビューを 1 つのアプリに集約する代わりに、既存の開発環境からの移行が発生します。

リモート実行やモバイルからの監視が要件に含まれる場合は、比較対象の中では Orca が SSH ワークツリーとモバイルコンパニオンの両方を持つ唯一の選択肢です。ここは統合範囲の広さがそのまま差になっている部分です。

エージェント自身にツールを操作させたい場合も Orca が候補になります。--json 前提の CLI を通じて worktree 作成からターミナル制御、ブラウザ操作までをスクリプト化できる設計は、他の 3 件には見られない特徴です。

Orca採用前に確認したい判断ポイント

ここまでは機能面を見てきました。採用するかどうかを決めるには、プロジェクトの健全性と運用条件を別途確認する必要があります。良し悪しを断定できる材料ではないため、以下では事実と、それをどう解釈しうるかを並べます。

開発の勢いとメンテナンス状況の読み取り方

Orca のリリース状況を リリース一覧 から拾うと、2026 年 8 月下旬だけでデスクトップ版が 3 本（v1.4.188 / v1.4.190 / v1.4.191）、Android 版が 2 本公開されています。最新のデスクトップリリースは v1.4.191（2026-08-28）で、リポジトリの最終 push とも一致します。README にも「we ship daily, so this list is perpetually behind. The changelog is the real feature list.」と記載があり、日次でリリースする開発体制であることが明示されています。

この速度は、バグ修正や機能追加が早く届くというメリットとして読めます。同時に、破壊的変更や仕様変更の頻度も高くなりうることを意味します。バージョンを固定して長期間動かしたいチームと、常に最新を追いたいチームでは、この特性の受け止め方が変わります。

もう 1 つの数字がオープン中の issue 4,778 件です。これは「開発速度に対して issue の処理が追いついていない」とも、「ユーザー数が急増しており報告が集まっている」とも読めます。どちらの解釈が妥当かを判断するには、自分たちが使いたい機能領域の issue がどう扱われているかを個別に確認するのが確実です。スター 56,102 に対して 4,778 という比率自体は、急成長中の OSS では珍しい水準ではありません。

そして、リポジトリ作成が 2026 年 3 月 17 日である以上、公開からまだ 5 か月ほどの若いプロジェクトです。長期運用の実績が蓄積されている段階ではないため、業務クリティカルなワークフローの中心に据えるかどうかは慎重に判断する余地があります。

ライセンス・運営体制・テレメトリ

ライセンスは MIT です。商用利用・改変・再配布に対する制約が緩く、社内ツールとして組み込む際のハードルは低い部類に入ります。前述の claude-squad が AGPL-3.0 であることと比べると、この差は選定に直接効いてきます。

運営体制は、Stably AI という企業が主導する OSS です。Y Combinator の支援を受けたスタートアップである点は、開発リソースが投入されている裏づけとして読める一方、企業の方針転換によってプロジェクトの位置づけが変わりうるリスクも同時に意味します。ただし MIT ライセンスであるため、方針が変わった場合にコミュニティがフォークして継続する選択肢は制度上残されています。この構造は、先に見た vibe-kanban のケース（開発元の事業終了後も OSS としてコードが残る）と同じ性質のものです。

テレメトリについては、匿名の利用データを収集する旨が README に記載されており、収集内容とオプトアウトの手順は プライバシー・テレメトリのドキュメント にまとめられています。社内ポリシーで外部への利用データ送信に制約がある場合は、導入前にこのページを確認してオプトアウト手順を把握しておくのが確実です。

ディスク消費は、前半で触れたとおり worktree の数に比例します。共有機構を使っても gitignore 済みの再構築可能なツリーを共有できるだけで、リポジトリ本体のチェックアウトは worktree ごとに存在します。大規模リポジトリを扱う場合は、並列数の想定と手元のディスク容量を先に突き合わせておくべきです。

どんなチームにOrcaが向くか

ここまでの内容を、判断の形にまとめます。

Orca が向いていると考えられるケース

• Claude Code や Codex など複数の CLI エージェントを日常的に併用しており、1 つのエージェントでは手が足りていません
• 既に git worktree を手動で切って並列運用しており、依存関係の再インストールや進捗把握のコストに限界を感じています
• 差分レビューとエージェントへのフィードバックの往復を、同じアプリケーション内で完結させたいと考えています
• ローカルマシンのリソースが不足しており、SSH でリモートマシンにエージェントを逃がしたい要件があります
• 離席中もエージェントを動かし、モバイルから完了確認と追加指示を出したいワークフローがあります
• エージェント自身にツール操作をさせるオーケストレーションを組みたいと考えています
• 社内のライセンス基準として MIT のような寛容型ライセンスが求められています

慎重に判断すべきケース

• ターミナル完結の軽量な構成で足りており、GUI 統合の必要性が薄い場合（claude-squad のような TUI のほうが移行コストが小さくなります）
• ターミナルエミュレータやエディタを強くカスタマイズしており、既存環境を維持したい場合
• 公開から 5 か月の若いプロジェクトを業務クリティカルな導線に据えることに懸念がある場合
• 日次リリースの変更頻度が、社内の検証・承認プロセスと噛み合わない場合
• 外部への匿名利用データ送信に社内ポリシー上の制約があり、オプトアウトの可否を先に確認する必要がある場合
• 大規模モノレポで多数の worktree を並べる想定があり、ディスク容量の見積もりが未確認の場合

最初に確認すべきこと

導入検討の入口としては、まず worktree モデルのドキュメント を読み、worktree.sharedDirectories と .worktreeinclude で自分のプロジェクトの依存関係とシークレットをどう配るかを設計できるかを確かめるのが実務的です。使いたいエージェントが乗るかどうかは 対応エージェント一覧 で、社内ポリシーとの整合は テレメトリのドキュメント で確認できます。エージェント自身に Orca を操作させる構想があるなら、CLI Overview が設計の起点になります。

AI コーディングエージェントの並列実行はまだ手法が固まりきっていない領域で、ツールの側も 2026 年に入ってから急速に入れ替わっています。この状況では「最も高機能なものを選ぶ」よりも、自分たちが今どの詰まりどころで止まっているのかを言語化し、それを解く道具かどうかで判断するほうが確実です。本記事の冒頭で挙げた 5 つの詰まりどころのうち、いくつが自分たちに当てはまるか。そこから逆算すれば、Orca に乗るべきか、より軽量な選択肢で足りるか、あるいは当面は手動運用のままでよいかが見えてくるはずです。

関連情報

AI エージェントを前提とした開発体制の設計や、社内向けツールの選定・構築についてご相談を承っています。ご検討中の方は お問い合わせフォーム からお気軽にお問い合わせください。要件が固まる前の整理段階からご相談いただけます。