[Orca] worktreeを増やしすぎて破綻した私を救ったツール

こんにちは。

前回に引き続き、git worktree の話です。

前回の記事で「worktreeを使えばAIを並列に走らせられる」と散々おすすめしておいて何なのですが、正直に白状すると、あの運用はわりと早い段階で破綻しました。

worktreeが3つくらいまでは良いんです。5個を超えたあたりから、こうなります。

• 「あれ、このディレクトリって何のissueのやつだっけ？」
• 「今どこでAIが走ってて、どれが終わってる？」
• 毎回 npm install して .env.local をコピーするのが普通に面倒
• 終わったやつを消し忘れて、ディスクとターミナルのタブが埋まっていく

前回作った wt() シェル関数、あれで解決した気になっていましたが、あくまで「作る」ところだけの解決だったんですよね。worktreeの本当の面倒くささは、作った後にありました。

今回は、そこを丸ごと引き受けてくれた「Orca」というツールの話をします。

結論から言うと

Orcaは「worktreeを、AIエージェントの作業単位として管理する」ためのツールです。

生の git worktree が「ディレクトリを作るところまで」をやってくれるのに対して、Orcaは「作る → 依存関係をセットアップする → AIを起動する → issueと紐づける → 状態を一覧で見る → 片付ける」までを1つのモデルとして扱ってくれます。

前回の記事で書いた不満が、だいたい全部消えました。

Orcaとは何か

デスクトップアプリ本体と、orca というCLIのセットです。私はほぼCLIから叩いています。

一番の特徴は、worktreeが「Orcaの管理下にある一級の概念」になっていることだと思います。生のGitだと worktree はただのディレクトリですが、Orcaでは1つ1つが名前・ブランチ・紐づくissue・起動中のターミナル・親子関係といったメタデータを持ちます。

実際に私の環境で orca repo list を叩くと、こうなっています。

$ orca repo list
975a0fca-...  product-a  /Users/kenji/GitHub/product-a
62cfff78-...  product-b  /Users/kenji/GitHub/product-b
d09741b6-...  product-c  /Users/kenji/GitHub/product-c
ea2411cd-...  product-d  /Users/kenji/GitHub/product-d
784c4cc5-...  product-e  /Users/kenji/GitHub/product-e
5760a31d-...  product-f  /Users/kenji/GitHub/product-f

リポジトリをOrcaに登録しておくと、以降はそのリポジトリに対して worktree を生やせるようになります。

以降、この記事に出てくる出力は私の環境の実物ですが、案件のリポジトリ名は product-a のように伏せています。実際は受託・自社プロダクトが入り混じった、普通に業務で使っているリポジトリだと思ってください。

何が解決したのか

1. worktreeの置き場所が勝手に整理される

前回の記事で、私はリポジトリの隣に corporate-site-feature-a みたいに並べる運用を紹介しました。あれ、リポジトリが1つなら良いんですが、リポジトリが6個あると ~/GitHub が地獄になります。

Orcaは worktree を専用の場所に、リポジトリ名/worktree名で切って置いてくれます。

~/orca/workspaces/
  product-a/
    issue-170-2/
    issue-357/
    issue-358/
    issue-359/
  product-b/
    issue-95/
    issue-138/
    issue-200/
    issue-202/

私は worktree名をissue番号にする運用に落ち着きました。issue-357 を見れば、GitHubのissue #357 の作業だと一発で分かります。~/GitHub 側は元のリポジトリだけが並んだ綺麗な状態のまま保てます。

2. 作った瞬間にAIが起動する

これが決定打でした。

orca worktree create \
  --repo name:product-a \
  --name issue-357 \
  --issue 357 \
  --agent claude \
  --prompt "issue #357 の対応をお願いします"

このコマンド1発で、worktreeが作られ、ターミナルが立ち上がり、その中でClaude Codeが起動して、プロンプトまで投げ込まれた状態になります。

前回の私は「worktree作って、cdして、npm installして、.env.localコピーして、claude起動して、プロンプト打つ」を手でやっていました。それが1行です。--agent には codex や gemini なども指定できて、~/.orca/agent-hooks/ を覗いたら claude / codex / cursor / gemini / copilot / devin / grok あたりのフックが一通り並んでいました。エージェントの乗り換えが激しいこの界隈で、ここが抽象化されているのは地味にありがたいです。

3. セットアップフックで npm install 問題が消える

前回「node_modulesと.env.localが付いてこないのが最大の落とし穴」と書きました。Orcaにはリポジトリごとにセットアップフックを定義する仕組みがあり、--setup run を渡すと worktree 作成時に走ります。

要するに、私が手で書いた wt() シェル関数がツール側の機能として用意されているということです。自作のアレは役目を終えました(ちょっと寂しい)。

4. issueと紐づく

--issue 357 を渡しておくと、Orcaのメタデータに残ります。--linear-issue でLinearのチケットも紐づけられるようです(私はGitHub issueしか使っていないので、こちらは試していません)。

$ orca worktree list
975a0fca-...::/Users/kenji/orca/workspaces/product-a/issue-357  refs/heads/issue-357
displayName: issue-357
parentWorktreeId: null
childWorktreeIds: []
linkedIssue: 357
comment:

linkedIssue が残るので、「このディレクトリ何だっけ？」が完全になくなりました。あと parentWorktreeId / childWorktreeIds という項目があって、worktree同士に親子関係を持たせられます。大きめの機能を分割して進めるときに効くやつだと思いますが、私はまだ使いこなせていません。

5. 全worktreeの状態が一覧で見える

個人的に一番よく叩いているのがこれです。

$ orca worktree ps
product-a refs/heads/issue-357  live:2  pty:yes  unread:yes
/Users/kenji/orca/workspaces/product-a/issue-357
preview: ... (ターミナルの最新出力がここに出る)

product-a refs/heads/issue-359  live:2  pty:yes  unread:yes
/Users/kenji/orca/workspaces/product-a/issue-359
preview: ...

product-b refs/heads/issue-202  live:2  pty:yes  unread:yes
/Users/kenji/orca/workspaces/product-b/issue-202
preview: ...

live:2 が生きているターミナルの数、unread:yes が「まだ自分が見ていない出力があるよ」の印です。複数のリポジトリをまたいで、今どこで何が走っているかが1画面で分かります。 上の出力、実は私の環境の実物なのですが、product-a と product-b を同時に走らせている状態です。前回の運用ではこれ、絶対に管理しきれませんでした。

ターミナルをCLIから触れる

もう1つ、じわじわ効いてくるのがターミナル操作系です。

# 出力を読む
orca terminal read --worktree ...

# 入力を送る
orca terminal send --worktree ... --input "テストも通しておいて"

# 終了/アイドルを待つ
orca terminal wait --worktree ...

何が嬉しいかと言うと、AIエージェント自身がこれを叩けるんですよね。つまり「親のAIが、別worktreeの子AIに指示を出して、終わるのを待って、結果を読む」ということが成立します。

実際 orca orchestration 配下には、エージェント間のメッセージング、タスクの作成とディスパッチ、依存関係、決定ゲート、コーディネーターループ……とかなり本格的な仕組みが並んでいます。

正直に言うと、私はここまではまだ使いこなせていません。 今は「人間が司令塔で、各worktreeのAIは独立して動く」くらいの素朴な使い方に留めています。以前書いたClaude CodeのAgent Teamsと考え方が近いので、いずれちゃんと試して記事にしたいところです。

余談：Orcaにはブラウザ操作やiOS/Androidエミュレータ操作、デスクトップアプリのアクセシビリティ操作(computer use)まで生えていて、正直「どこまで行くんだこれ」となります。ここは今回の主題から外れるので割愛しますが、E2Eの確認までAIに閉じさせたい人には刺さりそうです。

生のworktreeと何が違うのか

前回の記事と地続きで整理します。

「worktreeを作るだけ」なら生のGitで十分です。 Orcaが効いてくるのは、リポジトリを複数またいで、issue単位で、AIを何体も並列に走らせ始めてからです。逆に言うと、そこに行くまでは要らないと思います。

正直なところ(気になっている点)

いつも通り、良いことばかりではないので正直に書きます。

コマンドが多すぎる。 orca --help を初めて見たとき、正直ちょっと引きました。worktree、terminal、orchestration、browser、computer、emulator、automations……。全体像を掴むのに時間がかかります。私も未だに --help を見ながら叩いています。

Orcaに乗ると、生のworktreeを直接触らなくなる。 これは良し悪しです。楽になる代わりに、Orca管理下のworktreeを生の git worktree remove で消したりすると、当然メタデータ側と食い違います。ツールに寄せる以上は一貫して寄せる、という覚悟が要ります。

結局、人間がボトルネックになる。 並列度を上げれば上げるほどAIの出力は増えますが、それをレビューするのは自分1人です。私の場合、同時に走らせるのは3〜4本が限界でした(これは完全に個人の処理能力の話です)。ツールがいくら並列を許しても、レビューが追いつかなければ意味がないので、ここは今も試行錯誤中です。

当然ながらトークンは食う。 3体並列で走らせれば、単純に3倍溶けます。当たり前ですが最初に驚いたので書いておきます。

まとめ

• 生の git worktree の面倒くささは「作る」ことではなく 「作った後の管理」 にあった
• Orcaは worktree を「AIエージェントの作業単位」として管理してくれるツール
• 置き場所の自動整理、セットアップフック、--agent での同時起動、issue紐づけ、orca worktree ps での全体把握 —— 前回書いた不満がだいたい消えた
• 一方で、コマンドは多いし、並列度を上げると人間のレビューが先に限界を迎える
• worktreeが3つまでなら生のGitで十分。複数リポジトリ × issue単位 × 並列AI になってきたら検討する価値あり

前回の記事で「モデルを乗り換えるよりworktreeを覚えた方が体感の改善が大きかった」と書きましたが、Orcaはその延長線上にあるツールです。派手さはないですが、足回りが整うと結局そこが一番効きます。

……と、ここまでツールの話をしてきましたが、実は並列AI開発で一番効いたのはツールではありませんでした。 リポジトリ側が並列に耐える作りになっているかどうか、こっちの方が圧倒的に効きます。マイグレーションのタイムスタンプ1つで並列が崩壊したりするので。

その話は長くなるので、次回、私たちが AGENTS.md とリポジトリ構成でやっていることとして書きます。

同じようにworktreeを増やしすぎて破綻した方の参考になれば幸いです！それではまた！