Orca 実践入門 - AIコーディングエージェントをworktreeで並列に走らせるADE

コーディングエージェントを使っていると、作業時間の内訳が変わってきます。書いている時間より、待っている時間のほうが長い。1本のエージェントに指示を出して、3分待って、結果を読んで、また指示を出す。その3分をどう使うかが効率を決めるようになってきました。

素直な解決策は「同時に何本も走らせる」ことです。ただし同じ作業ディレクトリで複数のエージェントを走らせれば、お互いのファイルを踏み合って壊れます。そこで git worktree を使ってタスクごとにディレクトリを分ける、という運用に行き着くのですが、今度はworktreeが10個並んだときの管理が手作業では回らなくなります。

Orca は、この「worktreeを配りながら複数エージェントを走らせる」という運用そのものをアプリケーションにしたものです。この記事では、Orcaが何をするツールなのか、worktreeモデルの具体、実務で最初に詰まる依存関係の扱い、リモート実行の選択肢、そして導入前に知っておきたい注意点までを、公式ドキュメントとGitHubリポジトリを出典に整理します。

Orcaとは何か

Orcaは、複数のCLIコーディングエージェントを、それぞれ隔離されたgit worktreeの中で同時に動かすためのデスクトップアプリケーションです。Claude Code、Codex、Cursor CLI、OpenCode、Gemini、GitHub Copilot CLIなど、ターミナルで動くエージェントであれば基本的に何でも載せられる、という設計になっています。

まず事実関係を並べておきます。

リポジトリが公開されたのが2026年3月17日で、そこから5か月ほどで5万スターを超えています。組織名が stablyai なのに対して著作権表記が Lovecast Inc. になっている点は少し紛らわしいのですが、いずれも公式サイトとリポジトリの記載どおりです。

「IDE」ではなく「ADE」と名乗っている

Orcaは自らを ADE（Agent Development Environment）と呼んでいます。公式サイトの表現を借りると、「IDEはあなたのために作られた。ADEはあなたとあなたのエージェントのために作られた」という立て付けです。

言葉遊びに見えますが、実際に設計の中心は違うところにあります。エディタが主役でターミナルが下に付いている従来のIDEに対して、Orcaは「worktreeの一覧」が主役で、その中にターミナル・エディタ・ブラウザ・差分ビューがぶら下がる構造をしています。左サイドバーに並ぶのはファイルツリーではなくタスク（worktree）で、それぞれの行が「いまエージェントが何をしているか」を表示します。

なお公式サイトのメタキーワードには Conductor alternative という語が明示的に含まれています。同種のworktree管理ツールを意識した立ち位置であることは、開発側も隠していません。

インストール

デスクトップ版は各OS向けのバイナリが配布されています。パッケージマネージャからも入ります。

# macOS (Homebrew)
brew install --cask stablyai/orca/orca
 
# Arch Linux (AUR) — ソースからビルドする場合は stably-orca-git
yay -S stably-orca-bin

直接ダウンロードする場合は onorca.dev/download から、macOSはDMG、Windowsはインストーラ（.exe）、LinuxはAppImage / deb / rpm が選べます。GitHub Releasesには Orca-1.4.188-arm64-mac.zip、orca-ide_1.4.188_amd64.deb、orca-ide-1.4.188.x86_64.rpm といった成果物が並んでいます。

初回起動時にホームディレクトリへのアクセス許可を求められ、~/.claude や ~/.codex といった既存のエージェント設定を検出してインポートを提案してきます。Claude Codeについては、どこかのターミナルで一度ログインしてあれば ~/.claude を自動で拾うため、Orca側で追加の認証作業は不要です。

アップデートは既定で安定版を追従します。「Check for Updates」を修飾キー付きでクリックするとRC版やパフォーマンスビルドに切り替えられる、という隠しオプションもドキュメントに書かれています。

最初の3エージェントセッション

公式ドキュメントの入口が「Your first 3-agent session」という章になっているあたりに、このアプリの思想が出ています。手順は次のとおりです。

1. サイドバーの「Add Repo」からローカルリポジトリを追加する。Orcaがgitの状態を読み、デフォルトブランチをbase refとして登録する。
2. リポジトリ名の横の「+」でタスク名を入力し、分岐元（start-from ref、通常は origin/main）を選んでworktreeを作る。
3. 生成されたworktreeのターミナルに出るエージェント選択ボックスから、Claude CodeやCodexを選ぶ。Orcaが正しい作業ディレクトリでエージェントを起動する。
4. 手順2〜3をあと2回繰り返し、同じプロンプトを3つのworktreeに投げる。
5. worktreeのタブを右端や下端にドラッグしてペインを分割し、3本を同時に眺める。
6. それぞれの差分ビューを比べ、良かったものにコメントを付けてコミット・プッシュする。残りはワンクリックで削除する。

「同じ課題を3本のエージェントに競争させて、勝った実装だけをマージする」という使い方が公式のチュートリアルになっている、というのがOrcaの立ち位置をよく表しています。ドキュメントのRecipesにも「Race three agents on the same task」という項目が独立して用意されています。

worktreeモデルを理解する

Orcaの中身を理解するうえで、worktreeの扱いが一番重要です。ここが分かれば残りは付属機能と言ってもいいくらいです。

base ref と start-from ref

モデル自体はシンプルです。

• リポジトリごとにbase refがある（通常 origin/main）
• worktreeごとにstart-from refがある（何から分岐したか）
• worktreeはそれぞれ独自のブランチ、独自のディスク上のファイル、独自のエージェントターミナルを持つ

start-from refとして選べるのは、リポジトリのbase ref、別のローカルブランチ（レビュー中のPRの上に作業を積む場合に使う）、特定のコミットSHA、既存のリモートブランチ（Orcaが自動でfetchする）の4種類です。

重要なのは、ここで作られるものが本物のgit worktreeだという点です。独自のサンドボックスではないので、ターミナルから git status も git rebase も普通に効きますし、Orcaの外で git worktree add したものもサイドバーに現れます。gitのメンタルモデルをそのまま持ち込めるので、この手のツールにありがちな「ツールを覚え直す」コストが小さくなっています。

worktreeが何をしているかを内部から知りたい場合は、Gitの内部構造入門やGitのmergeとrebaseの使い分けも合わせて読むと、Orcaが裏でやっていることの解像度が上がります。

作成は非同期、削除はブランチごと

Create Worktreeダイアログを送信するとダイアログは即座に閉じ、git fetch と git worktree add はバックグラウンドで進みます。サイドバーに進捗行が出て、チェックアウトが終わるとタブがターミナルに切り替わります。作成中に別のworktreeへ移動しても構いませんし、途中でキャンセルもできます。大きめのリポジトリでworktreeを量産するときに、ここが同期処理だと体験が壊れるので、妥当な設計です。

削除時はディレクトリとブランチの両方を消します。ただしgitが未マージのコミットを検出した場合はローカルブランチを保持し、確認ステップを挟みます。

ブランチ名の決まり方

既定ではワークスペース名からブランチ名を導出します。GitHub PR、Linear / Jiraのissue、GitLab MRからworktreeを作った場合は、その作業項目に由来する名前になります。Linear連携では、Linear自身が提案するブランチ名をそのまま使う挙動になっている、という細かい配慮も入っています。

面白いのは絵文字の扱いで、ワークスペース名にSlack形式のショートコード（:rocket: など）を書けて、表示名には絵文字が残り、gitのブランチ名を導出する段階で読める形（ロケットの絵文字なら rocket）に書き換えられます。

実務で最初に詰まる場所は node_modules と .env

worktreeを使ったことがある人なら、この段落が一番知りたいところだと思います。新しいworktreeはクリーンなチェックアウトなので、gitignoreされているものが全部ありません。node_modules も .env も .cache も無い状態で、エージェントに「テストを走らせて」と言っても動きません。

Orcaはこれを3つの手段で埋めます。用途がはっきり分かれています。

1. Worktree Shared Paths（Settings → Repository、ユーザーごとの設定）: プライマリチェックアウトから各worktreeへパスを実体化する。macOSではAPFSのクローンコピー、それ以外ではシンボリックリンク。
2. orca.yaml の worktree.sharedDirectories（リポジトリにコミットする設定）: 共有したいgitignore対象ディレクトリの一覧。コピーではなく共有・シンボリックリンク。node_modules や .cache のような「大きくて再生成可能なツリー」向け。
3. .worktreeinclude（リポジトリルート、コミットする）: 各worktreeにコピーするgitignore対象のファイル/ディレクトリ一覧。.env やローカル設定のように、worktreeごとに自分のコピーを持つべきもの向け。

設定はこう書きます。

worktree:
  sharedDirectories:
    - node_modules
    - .cache

.env
.env.local
.vscode/settings.json

挙動の細部で押さえておくべき点がいくつかあります。

• sharedDirectories に書いたパスは、プライマリチェックアウトにディレクトリとして実在し、かつgitignoreされている必要があります。gitで追跡されているパスや存在しないパスはスキップされます。
• orca.yaml の設定はユーザーごとのWorktree Shared Pathsに加算されます。置き換えではありません。
• .worktreeinclude は現時点でリテラルパスのみ対応です。globや否定パターンは警告付きでスキップされます。
• すでに共有・リンク済みのパスは .worktreeinclude からの再コピー対象になりません。

node_modules をシンボリックリンクで共有する方式には副作用もあります。worktreeごとに依存バージョンが違うブランチを扱っている場合、共有された node_modules は当然食い違います。ブランチ間で依存が動く可能性がある期間は、sharedDirectories から外して各worktreeでインストールさせるほうが安全です。この判断はOrcaが肩代わりしてくれる部分ではないので、自分のリポジトリの性質に合わせて決める必要があります。

ターミナルの実体は xterm.js

READMEには「Ghostty-class terminals with WebGL rendering」と書かれています。これを読んで「Ghostty本体を組み込んでいるのか」と思うと少しずれます。ドキュメントのTerminalの章には、こう明記されています。

Orca's terminal is the same xterm.js-based terminal VS Code uses, with a few additions tuned for AI-agent workflows.

つまり実体はVS Codeと同じxterm.jsベースで、そこにAIエージェント向けの追加機能が乗っているという構成です。「Ghostty級」という表現が指しているのは、初回起動時にGhosttyのテーマ・フォント・カーソル設定をインポートできるという互換性のほうです。Warpのテーマディレクトリからテーマを取り込む機能も別に用意されています（macOSでは ~/.warp/themes を走査）。

xterm.js自体にWebGLレンダラのアドオンがあるので「WebGL rendering」という記述と矛盾するわけではないのですが、ターミナルエミュレータの実装そのものを乗り換えたわけではない、という点は把握しておいたほうがいいでしょう。

エージェント運用の観点で効いてくるのは、次の3つです。

• タブのステータス表示: 実行中・入力待ち・完了・完了だが未読、をタブが区別して表示します。ペインを10個並べたときに「どれが自分の返事を待っているか」が一目で分かるのは、実用上かなり大きい差です。
• OSC 52によるクリップボード書き込みを既定で許可: tmux、Neovim、fzf、Zellijなど多くのTUIはOSCシーケンスでコピーします。SSH越しでもローカルと同じようにコピーが効きます。
• Cmd-Fでスクロールバック検索: 大文字小文字の区別、正規表現、マッチ間の移動に対応しています。

主なショートカットは次のとおりです。

tmuxでペインを並べて運用している人なら、Claude Code に別 tmux ペインを覗かせる小ネタでやっているような「隣のペインの状況をエージェントに伝える」工夫が、Orcaでは構造として最初から入っている、と考えると分かりやすいと思います。

AIの差分にコメントを付けて投げ返す

エージェントが書いたコードのレビューは、「全部読んで、直したいところをチャットに文章で書き起こす」という作業になりがちです。ファイル名と行番号を手で写している時点で無駄が多い。

OrcaのAnnotate AI Diffは、差分ビューの任意の行にマークダウンでコメントを付けて、まとめてエージェントに送り返す機能です。GitHubのPRレビューと同じ操作感で、宛先がエージェントになっている、と思えばだいたい合っています。

隣接する機能としてAttributionがあります。差分のどの部分が人間の手によるもので、どの部分がエージェントの出力なのかを追跡する仕組みです。エージェントの出力に自分で手を入れて、そのあと再度エージェントに渡す、という往復をしていると「これは自分が書いた行だったか」が分からなくなるので、地味ですが効きます。

コミット、プッシュ、PR作成、CIチェックの待機まで、worktreeの行の中でそのまま完結します。GitHub、Linear、Jira、GitLabの連携があり、issueやPRからworktreeを起こす動線も用意されています。

Design Mode: 画面上の要素をクリックしてプロンプトに落とす

worktreeごとにChromiumウィンドウが付いてきます。開発サーバをそのworktreeで立てて、そのworktree専用のブラウザで見る、という形です。

Design Modeはそのブラウザの上で動く機能で、ツールバーのトグルを入れるとカーソルが要素ピッカーに変わります。UI要素をクリックすると、次の情報がまとめてアクティブなエージェントのプロンプトに添付されます。

• その要素のHTML（outerHTMLと周辺の少し広い範囲）
• 計算済みのCSS（色、フォント、余白）
• 切り取られたスクリーンショット
• ソースマップが利用可能なら、該当するファイルと行番号

「このボタンの余白がおかしい」という指摘を、スクリーンショットを撮ってドラッグして説明文を書いて、という手順抜きでエージェントに渡せます。フロントエンドの細かい調整をエージェントに任せる場面で、往復回数がはっきり減る種類の機能です。

4つの実行形態

Orcaは「どのマシンでエージェントを動かすか」を4通りから選べます。ここはドキュメントの Ways to run Orca に整理されています。

SSHワークツリーとRemote Orca Serverの違いが分かりにくいので、公式の比較を要約しておきます。

• SSHワークツリー: 実行時の所有はノートPC側のOrcaにある。切断してもホスト上でエージェントは走り続けるが、接続できるクライアントはそのノートPC1台。
• Remote Orca Server: 所有はリモートマシン側。セッション状態が完全に保持され、ノートPC・Web・モバイル・自動化から同じ状態を共有できる。

ヘッドレスなLinuxサーバで動かす場合は、サーバ側で次のように起動します。

orca serve --pairing-address <到達可能なホスト名またはIP>

Cloud VMはSettings → Experimentalで有効化する実験的機能で、対応プロバイダとしてVercel Sandbox、Fly、Modal、SSH、ローカルDockerが挙げられています。リポジトリ内の orca.yaml とライフサイクルスクリプトで環境を定義する方式です。

VPSを持っている人にとっては、SSHワークツリーが一番現実的な入口だと思います。手元のMacBookのファンを回さずに、既存の開発サーバでエージェントを走らせて、UIだけ手元で見る、という構成が追加のサーバを立てずに作れます。

Orca CLI: エージェント自身にOrcaを操作させる

Orcaで一番「ADE」らしい部分がここです。orca コマンドが用意されていて、エージェント自身がOrcaを操作できるように作られています。

まず疎通を確認します。

command -v orca
orca status --json

主なサブコマンドを用途別に並べると、こうなります。

orca worktree ps                                  # 一覧
orca worktree create                              # 作成
orca worktree current                             # 現在のworktree
orca worktree rm                                  # 削除

orca terminal list
orca terminal read
orca terminal send --text "continue" --enter
orca terminal wait --for tui-idle
orca terminal split --direction vertical

orca goto --url https://example.com
orca snapshot
orca click --element @e3
orca fill --element @e1 --value "sample@example.com"
orca screenshot

このほかに、モバイルエミュレータの操作（orca emulator tap など）、スケジュール実行（orca automations）、成果物の共有（orca artifacts share）が用意されています。

つまり「エージェントに別のエージェント用のworktreeを作らせる」「エージェントに自分の画面を撮らせて確認させる」といった構成が、シェルコマンドの範囲で書けます。エージェントをスクリプトから駆動する話はClaude Code を長時間自律で走らせるでも扱いましたが、Orcaの場合はIDE側の状態そのものがCLIから触れる対象になっている、というのが違いです。

worktreeチェックポイント

各worktreeにはコメント欄があり、CLIから更新できます。

orca worktree set --worktree active \
  --comment "バリデータの分岐を修正、テストは通過。次はE2Eの更新" \
  --workspace-status in-progress \
  --json

ステータスは todo / in-progress / in-review / completed（あるいは独自ID）から選べます。ドキュメントでは「人間の協力者をループに保つためのパターン」と説明されていて、実装の節目、仮説の検証完了、ブロッカーに当たったタイミングなどで書き込むことが推奨されています。

10本のエージェントを走らせているとき、それぞれのターミナルをスクロールして読み返すのは現実的ではありません。1行の要約をエージェント自身に書かせておく、というのは素直な解法です。

オーケストレーション（実験的）

Settings → Experimentalで有効化する多エージェント調整レイヤーもあります。Run（名前空間と調整役の受信箱）、Task（作業項目）、Dispatch（実行試行）、Message（受信箱に届くメッセージ）、Decision gate（調整役が持つ質問）という構成要素からなり、TaskはDAG構造で管理されます。

orca orchestration run-create --objective "説明文" --json
orca orchestration task-create --spec "仕様" --task-title "タイトル" --json
orca orchestration worker-start --task <taskId> --worktree current --agent codex --json

Taskのステータスは pending / ready / dispatched / completed / failed / blocked の6種類です。実験的機能なので、本番運用のワークフローをここに寄せるのは時期尚早ですが、「エージェントの群れをどう構造化するか」という問題に対する一つの回答として見る価値はあります。

モバイルコンパニオン

iOS（App Store / TestFlight）とAndroid（GitHub Releasesで配布されるAPK、2026年8月26日時点で 0.0.44）にコンパニオンアプリがあります。デスクトップとペアリングして、エージェントの状態を見る、使用量を確認する、アカウントを切り替える、追加の指示を送る、といった操作ができます。

エージェントが完了したときに通知を受け取れるので、「5分かかる処理を投げて席を立つ」という運用が成立します。Remote Orca Serverと組み合わせると、デスクトップを閉じていてもセッションが生き続けます。

テレメトリとプライバシー

ローカル開発環境に入れるツールなので、ここは確認しておくべきところです。ドキュメントの記載を要約します。

送信するもの:

• アプリ起動などのライフサイクルイベント
• リポジトリの追加方法（リポジトリ名やURLではない）
• どのエージェント種別を起動したか（プロンプトや出力ではない）
• エラーの分類（生のメッセージやスタックトレースではない）
• ホワイトリスト化された設定変更（フィーチャーフラグとUX設定のみ）

送信しないと明記されているもの:

• ファイルパス、リポジトリ名、ブランチ名、URL、コミットメッセージ
• エージェントのプロンプト・応答・ターミナルの内容
• 生のエラーメッセージやスタックフレーム
• アカウント情報、IPアドレス
• UI入力の自由記述テキスト

紐付けは「ランダムなローカルID」に対して行われ、アカウントやメールアドレスとは結びつけないとされています。送信先はPostHog Cloud（米国リージョン）です。

オプトアウトは3通りあります。

# 環境変数のどちらかを設定する
export DO_NOT_TRACK=1
export ORCA_TELEMETRY_DISABLED=1

GUIからは Settings → Privacy の「Share anonymous usage data」をオフにします。DO_NOT_TRACK という業界共通の環境変数を尊重しているのは好印象です。

使う前に把握しておきたいこと

良いところだけ並べても判断材料にならないので、導入前に見ておくべき点を挙げます。

READMEに「we ship daily, so this list is perpetually behind（毎日リリースしているので、この一覧は常に遅れている）」と書かれています。実際、GitHub Releasesを見ると v1.4.183 が8月15日、v1.4.188 が8月22日と、1週間で5リリース出ています。追いつくのは楽しい反面、「先週のドキュメントが今週合っていない」ことは起こりえます。

2026年8月26日時点でオープンなIssueは4,603件です。5万スターのプロジェクトとしては不自然な数字ではありませんが、「機能要望も不具合報告も全部Issueに流している」状態であることは把握しておいたほうがいいでしょう。READMEも機能要望をIssueで受け付ける方針を明記しています。

これはOrcaの問題ではなくworktreeの性質ですが、10本走らせれば作業ツリーが10個できます。node_modules を共有しない設定にしていれば、その分だけ倍々に増えます。公式サイトのデモ画面にも「1.2 GB」というディスク使用量の表示が出ています。

Orcaはエージェントを提供しません。自分のClaude MaxやChatGPT Proのサブスクリプションをそのまま使う「bring your own agent / subscription」方式です。3本並列で走らせれば、当然3倍の速度でレート制限に近づきます。Orcaはステータスバーに使用量と制限までの距離を表示しますが、制限そのものを緩めてくれるわけではありません。トークン消費の考え方についてはClaude Code のトークンを理解するも参考になります。

デスクトップアプリはMITライセンスで無料です。Enterpriseページには価格の記載がなく、「導入とセキュリティに関する直接サポート」「組織レベルの設定」を問い合わせベースで提供する形になっています。トップページの「Used by builders from」に並ぶLinear、Uber、Vercel、Stripe、Airbnb、Perplexityのロゴは、それらの企業に所属する個人開発者が使っているという趣旨の表現で、企業としての採用や導入契約を示すものではない点は読み分けが必要です。

どんな人に向くか

向いているのは、すでにコーディングエージェントを日常的に使っていて、「1本ずつ順番に待つ」ことに限界を感じている人です。特に、複数のエージェント（Claude CodeとCodexなど）を併用していて、同じ課題を投げ比べたい人には効きます。Codex CLIやOpenCodeを併用している人なら、切り替えのコストが消えるだけでも価値があるはずです。

Windowsユーザーにとっては別の意味もあります。Orcaは公式にWindowsをサポートしていて、ターミナルはPowerShell / コマンドプロンプト / WSLから選べ、WSLファイルシステム上では自動的に wsl.exe 経由で起動します。CLIエージェントをWindowsで扱いやすくする器としても機能します。

向いていないのは、エージェントを1日に数回しか使わない人です。worktreeの管理コストが、得られる並列度に見合いません。既存のIDEとターミナルで足ります。また「ツールが毎週変わるのが苦痛」という人にも、現時点の更新ペースは合わないと思います。

Neovimやtmuxで自分の環境を作り込んでいる人は微妙なところです。Orcaがやっていることの多くは、worktreeを切るシェル関数とtmuxのセッション管理で再現できます。それを自分で書く時間と、Electronアプリを1つ増やすコストの比較になります。ただ、Design ModeとAnnotate AI Diff、そしてモバイルからの操作は自作では割に合わない部分なので、そこに価値を感じるかどうかが判断軸になりそうです。

まとめ

Orcaは「複数のコーディングエージェントを並列に走らせる」という運用課題に、git worktreeを中心に据えて答えたデスクトップアプリです。

• 本物のgit worktreeを使うので、gitの知識がそのまま通用する
• orca.yaml の sharedDirectories と .worktreeinclude で、依存関係とローカル設定の欠落を埋められる
• ターミナルの実体はxterm.js。「Ghostty級」はテーマ互換の話
• ローカル / SSH / Remote Orca Server / Cloud VM の4形態から実行環境を選べる
• orca CLIでエージェント自身にIDEを操作させられる
• MITライセンス、無料。エージェントは自分のサブスクリプションを持ち込む

エージェントを並列に走らせる運用がこれから当たり前になるとしたら、その器がIDEのままでいいのか、という問いに一つの実装で答えを出しているツールです。すでにエージェントを日常的に使っていて待ち時間が気になっているなら、試す価値は十分にあります。

参考リンク

• Orca 公式サイト
• Orca ドキュメント
• Worktrees（Orcaモデル）
• Your first 3-agent session
• Ways to run Orca
• Orca CLI overview
• Terminal
• Design Mode
• Privacy & Telemetry
• stablyai/orca（GitHub）
• Orca リリース一覧
• README 日本語版