Claude Code と Codex、どちらも手元に置いていると「次はどっちで行くか」の判断と切り替えが日課になってきます。
Orca は、その手動切り替え運用を終わらせるための管理基盤です。
インストールからエージェント登録、フロントエンド／バックエンドを分けた並列実行のシナリオ設計まで、そのまま自分のプロジェクトに持ち込める形で手順を追います。
「次のタスクはどのエージェントで？」という問いに疲れてきた
タブを3つ4つ開いて、どのタブがどのブランチだったか確認して、エージェントに「さっきの続きで」と再説明する。
この「切り替えコスト」は1回では大したことないですが、1日に何度も繰り返すと認知負荷として確実に積み重なります。
もうひとつ見落とされがちなのが、 直列実行のボトルネック です。
エージェントをひとつずつ順番に動かしていると、前のタスクが終わるまで次が始まりません。
フロントエンドの実装が終わるのを待ってからバックエンドに着手する、という流れは「エージェントが賢くなった」という事実と相性が悪い。
道具が優秀になったのに、使い方が直列のままでは恩恵が半減します。
個別エージェントの記憶管理やプラグイン拡張については別の記事で扱いました。
今回はその「次のステップ」として、複数エージェントを並列で走らせる運用基盤の話をします。
その答えのひとつが Orca （stablyai/orca）です。
Orca とは何か——ADE という発想と、フリートを支える git worktree の仕組み
Orca は「ADE（Agent Development Environment）」と自ら名乗っています。
IDE がコードを書く人間の作業環境であるなら、ADE はエージェントたちを管理する人間の作業環境です。
エージェントを「使う」ツールではなく、複数のエージェントを「管理する」レイヤーとして位置づけるのが核心です。
では、並列実行の土台はどこにあるか。
Orca は各エージェントを 独立した git worktree の上で動かします。
worktree は「同じリポジトリを複数のディレクトリに同時チェックアウトする」Git の機能で、普通に使うと手動管理が面倒です。
Orca はそのライフサイクルを全部引き受け、各エージェントの作業空間を完全に分離した状態で管理します。
エージェントが互いのコードに干渉せず、別々のブランチで自由に変更を加えられる設計です。
エージェントがどれだけ賢くなっても、互いの作業が干渉し合っていては並列の意味がありません。
worktree による分離がフリート運用の実用性を支えています。
MITライセンスのOSSである点も重要です。
Orca 自体は無料で、Claude や Codex の自分のサブスクリプション（APIキー）をそのまま使います。
ベンダーロックインなしに複数エージェントを束ねられる、ということです。
対応範囲の広さも、実務で選ぶ理由のひとつになります。
- プラットフォーム: macOS・Windows・Linux のデスクトップアプリ、iOS/Android のモバイル Companion アプリ、SSH経由のリモートワークツリーに対応
- 対応エージェント: Claude Code・Codex・Grok（xAI）・Cursor CLI・GitHub Copilot CLI・Cline・Goose など40種以上。特定エージェントに縛られない管理基盤として機能する
「40種以上の対応エージェント」の意味は「全部使う」ではなく、「今使っているエージェントの組み合わせをそのまま持ち込める」という点にあります。
今のワークフローを捨てずに並列管理に移行できる、ということです。
ローカルに Orca を立ち上げてエージェントを登録するまで
macOS なら Homebrew で一行です。
# macOS（Homebrew）
brew install --cask stablyai/orca/orca
# Windows: 公式サイト（https://onorca.dev）から exe インストーラーをダウンロード
# Linux: AppImage・deb・rpm パッケージを公式サイトから取得（コマンド名は orca-ide）
初回起動後にまず確認したいのが、エージェントの自動検出です。
Orca は起動時にシステム上のエージェントCLIを探しに行きます。
Claude Code・Codex・Grok がすでにインストールされていれば、Settings → Agents のリストに自動で現れます。
検出されなかった場合は、ターミナルで手動起動できるかを先に確認してください。
# 各エージェントCLIが手動で動くか確認する
claude --version
codex --version
コマンドが見つからなければ、そのCLIがPATHに通っていない可能性があります。
macOS では Orca のCLI自体が ~/.local/bin に置かれることがあるため、シェルの設定ファイルにパスが通っているかも合わせて確認しましょう。
Settings → Agents の画面から手動でPATHを追加することもできます。
エージェントが検出できたら、次に 権限モードの切り替え をしておきます。
デフォルトの Yolo モードはエージェントが確認なしにコマンドを実行するモードです。
本番に近いコードを触るなら、Manual モードに切り替えてエージェントの操作を承認しながら進める運用をおすすめします。
Settings → Agents → Permission Mode から変更できます。
リポジトリの登録は、サイドバーの Add Repo（最新版では Create メニュー）からリポジトリのパスを指定するだけです。
登録後、リポジトリ名の横の「＋」ボタンを押すと worktree 作成のダイアログが開きます。
ブランチ名を入力して使用するエージェントを選択すれば、その worktree 上でエージェントが起動します。
エージェントが起動しない場合はタブの Restart チップから再起動を試してください。
worktree が作れない場合は git fetch origin でリモートの最新状態を取得してから、別のブランチ名で試してみましょう。
フロントエンドとバックエンドを別エージェントに任せて並列で走らせる
具体的なシナリオで考えてみます。
Webアプリのリニューアルで「検索フォームのUI刷新」と「検索APIのエンドポイント追加」を同時に進めたいとします。
Claude Code をフロントエンド担当（UI実装・Design Mode活用）、Codex をバックエンド担当（API・DB層）として分担させる構成です。
ブランチはこのように切り分けます。
main
├── feature/frontend-search-ui ← Claude Code が担当
└── feature/backend-search-api ← Codex が担当
重要なのは、 タスクの独立性を最初に確認する ことです。
フロントエンドのコンポーネント実装とバックエンドのエンドポイント実装は、基本的に互いを待たずに進められます。
ただし「APIのリクエスト・レスポンスの型定義」は共通仕様として先に決めておく必要があります。
型定義ファイルだけ先に main にマージしておくか、どちらの worktree からも参照できる共通の場所に置く設計にすると、後で衝突しません。
エージェントへの指示はそれぞれの worktree のターミナルに入力します。
# Claude Code（feature/frontend-search-ui worktree）への指示例
SearchForm コンポーネントを src/components/SearchForm.tsx に実装してください。
デザインは既存の InputField コンポーネントのスタイルに合わせ、
API仕様は docs/api-spec.md の /api/search エンドポイントを参照してください。
# Codex（feature/backend-search-api worktree）への指示例
/api/search エンドポイントを src/api/search.ts に実装してください。
リクエスト・レスポンスの型は src/types/search.ts を参照し、
既存の /api/products エンドポイントの実装パターンに合わせてください。
両エージェントが並列で動いている間、Orca のUIでは各 worktree の状態が一覧で確認できます。
エージェントが作業中かどうかの状態記号がリアルタイムで更新されるので、タブを行き来する必要がありません。
モバイル Companion アプリを使えば、席を離れているあいだもエージェントの完了通知を受け取れます。
フォローアップの指示をスマートフォンから送ることもできるので、外出中でも作業が止まりません。
成果物の確認は Annotate AI Diff 機能を使います。
差分ビューの任意の行にコメントを付けてエージェントに送り返せるので、「この関数の引数名を変えて」「エラーハンドリングが抜けている」といった修正指示を Orca から離れずに出せます。
レビュー・コミット・プッシュまでは Orca の画面内で完結でき、PRの作成もアプリ内のGitHub連携機能からそのまま操作できます。
画面をまたぐ回数が減るだけで、地味に体験が変わります。
手動切り替え運用と比べて何が変わるか——導入して気づくこと
Qiita の実使用レポートに「cmux から切り替えると、worktreeとエージェントの対応をUIで一覧できる。タブを行き来してブランチを確認する手間がなくなる」という感想が書かれていました。
読んだ段階では地味に聞こえますが、毎日エージェントを複数操作している人には「確認するために切り替えなくていい」という変化が思いのほか効きます。
手動切り替え運用では、①ブランチ確認のためにターミナルを探す、②worktree の状態を頭で把握し直す、③エージェントにコンテキストを再説明する、という3ステップが都度発生していました。
Orca 導入後はこのループがUIの一覧に集約されます。
タブもターミナルの手動管理も、worktree の作成・削除の煩雑さもなくなります。
一方で、 消えないコストと新たに生まれるコスト もあります。
worktree が増えるとディスク使用量が増えます。
大きめのリポジトリで複数の worktree を同時に走らせると、ストレージへの影響は無視できません。
また、並列で走った成果物をどの順番でマージするか、コンフリクトが出たときにどちらを優先するか、というマージ戦略の設計コストは Orca を使っても消えません。
管理レイヤーを担ってくれる一方で、設計判断は人間が持ち続けることになります。
「まだ早い人」の条件も正直に書いておきます。
git を使っていないプロジェクトが中心の場合、AIエージェントを1タスク1インスタンスで十分に使えている段階の場合、ローカルのディスクやメモリリソースが限られている環境の場合——この3つに当てはまるなら今すぐ移行する必要はありません。
逆に、複数タスクを並列化したい・エージェントの切り替えがじわじわ面倒になってきた、という実感が出てきたタイミングが導入の目安です。
まず試すなら「1リポジトリ・2エージェント」から始めるのがいいです。
フロントエンドとバックエンドのような依存関係が少ないタスクを選ぶと、並列実行の感触がつかみやすいです。
MITライセンスの無料OSSなので、入れるコストは低く、合わなければ戻せます。
株式会社ホコサキは山口県宇部を拠点に、Web制作・業務システム開発・AI活用支援を手がけています。
Claude Code や Codex を実務に組み込んだ経験をもとに、エージェントの並列運用設計からプロジェクト導入まで対応しています。
ご相談は お問い合わせ からどうぞ。