CursorのClaude Code拡張からOrcaに乗り換えて分かったこと ― 一人・gitなし・Claudeだけなら、中身はほぼ同じだった

2026年10月6日

1. イントロダクション

技術の概要と背景

Orca は、Claude Code や Codex などの AI エージェントを動かすことを中心に作られたデスクトップアプリです。ワークスペース(作業場所)ごとにターミナルを並べてエージェントを走らせ、その状態を一覧で見られます。git リポジトリなら、ワークスペースごとに別ブランチの作業フォルダ(git worktree)を作り、複数のエージェントに並行して作業させることもできます。

筆者はもともと、Cursor に Anthropic 公式の Claude Code 拡張機能(以下、拡張)を入れて使っていました。「すごく良いエディタがある」と聞いて Orca に乗り換え、いまは私用PCと会社PCの両方で使っています。

なぜ注目されているのか(そして、筆者が感じた温度差)

AI エージェントを複数同時に走らせる使い方が広がり、エディタよりも「エージェントの管理」を中心に置いたアプリが注目されています。Orca もその1つです。

実際に使ってみると、PC によって感じ方がまったく違いました。

	私用PC	会社PC
使っているエージェント	Claude と Codex の両方	Claude だけ(アカウントがそれしかない)
作業の管理	Web サービス開発を GitHub の Issue で管理	GitHub はまだない。作業フォルダも git 管理していない
Orca の感想	便利	悪くなったわけではないが、メリットも感じない

会社PCでは、結局ターミナルで Claude Code にお願いし、そのエージェントが子エージェント(サブエージェント)を作って……という、Cursor のときと同じ動きになりました。

そこでこの記事では、「複数のエージェントを使わない・並列にしない・git 管理しないなら、Cursor の拡張で十分なのでは?」という疑問を、実測で確かめます。

2. 詳細説明

技術の基本原理

Orca の中心にあるのは、次の3つの仕組みです。

ワークスペース = 作業場所の単位: git リポジトリなら、ワークスペースごとに別ブランチの作業フォルダ(git worktree)を作ります。ファイルの変更が混ざらないので、複数のエージェントを同時に走らせられます。git リポジトリでないフォルダも「folder」としてワークスペースにできます。ただし、別ブランチの作業フォルダは git の機能なので作れません。folder でも2つ目のワークスペースは作れるようです。計測に使った PC では、計測の対象とは別の git リポジトリでないフォルダに、ワークスペースが2つ登録されていました。ただし、どちらも同じフォルダを指していて、ファイルは分かれていませんでした。
ターミナルは常駐プロセスが持つ: 今回の検証で分かったことですが、Orca のターミナルは、アプリ本体とは別の常駐プロセス(%LOCALAPPDATA%\Orca\daemon-host\<版>\Orca.exe)の配下で動いていました。ワークスペースを「Sleep(休止)」にしておけば、後でターミナルとエージェントの会話ごと再開できる仕組みと関係していると考えられます。
エージェントを外から操作できる CLI: orca コマンドで、ターミナルの作成・読み取り・入力、ワークスペースの作成、内蔵ブラウザの操作などができます。エージェント自身がこの CLI を呼んで、別のエージェントを起動したり監督したりすることもできます。

主要な機能と特徴

Orca の CLI(1.4.220)には、公開されているコマンドが239件ありました(orca agent-context --json で一覧を取得できます)。主なものを、何が前提になっているかで分けると次のようになります。

機能	何ができるか	前提
ワークスペース(`worktree`)	作業場所の一覧・作成、状態(todo/in-progress など)とコメントのカード	別ブランチの作業フォルダを作るのは git が前提(folder でも、同じフォルダを指すワークスペースは作れるとみられる)
ターミナル(`terminal`)	ターミナルの作成・分割、出力の読み取り、入力の送信	なし
オーケストレーション(`orchestration`)	まとめ役のエージェントが、複数のワーカーに作業を配り、質問と完了報告を管理する	複数のエージェント
GitHub Issue・Linear との紐づけ	ワークスペースに Issue 番号を付ける(`--issue`)、Linear の Issue を読み書きする	外部サービス
定期実行(`automations`)	プロンプトを決まった時刻にエージェントへ自動で実行させる	なし
内蔵ブラウザの自動操作	Orca の中のブラウザをエージェントが操作する(80件)	なし
デスクトップアプリの操作(`computer`)	ほかのアプリの画面を読み取り、クリック・入力する	なし
セッションの全文検索(`search`)	過去のエージェントの会話を全文検索し、再開コマンドを得る	なし(設定で有効にする必要あり)

ワークスペース・オーケストレーション・Issue との紐づけといった中心の機能が、「複数のエージェント」「git」「外部サービス」を前提にしていることが、会社PCで良さを感じにくかった理由ではないか、というのがこの記事の見立てです。

3. 使用例

具体的な適用例

私用PC(Orca が活きる側)

研究で、Claude と Codex に同じ課題を並行して走らせています。ワークスペースごとにターミナルが分かれているので、どちらが何をしているかを一覧で見られます。
Web サービスを、GitHub の Issue で管理しながら作っています。Orca では、ワークスペースに Issue 番号を紐づけることもできます(orca worktree create --issue <番号>)。

会社PC(Orca の良さが出にくい側)

作業フォルダは git 管理していないので、別ブランチの作業フォルダを作ってファイルを分けることができません。
エージェントは Claude だけです。1つのターミナルで Claude Code に頼み、並行作業が必要なら Claude Code 自身がサブエージェントを作ります。
つまり、Orca に求めているのは「ターミナル1つ」とほぼ同じです。

成功事例とその影響

会社PCでも、次の使い分けは役に立ちました。

やりたいこと	使うもの
中断した作業の続きをやる	同じワークスペースで `claude --resume`。または、ワークスペースを閉じずに Sleep にしておき、再開時にターミナルと会話ごと戻す
別の作業を順番にやる	同じワークスペースで新しいセッション(`claude` を新しく起動、または `/clear`)
別の作業を同時にやる	git リポジトリなら新しいワークスペース(別ブランチの作業フォルダ)。git リポジトリでないなら、同じワークスペースにターミナルを足す

ただ、--resume も /clear もサブエージェントも Claude Code 自身の機能なので、Cursor の拡張から起動した Claude Code でも使えるはずです。ここが「メリットも感じない」の正体だと考え、次の章で実測しました。

4. 実測による検証

実験のコード・生データ・詳しい手法は experiments/2026-10-06-cursor-extension-vs-orca-solo/ にあります。

検証した仮説と実験設計

記事の主張を、次の3つの測れる問いに置き換えました。

実験	問い	主な仮説
1. 常駐コスト	Claude Code を1体だけ待機させたとき、Orca(`orca terminal create --command claude` で起動)と Cursor(拡張のパネル)で、メモリと CPU はどれだけ違うか	合計のメモリの比(Orca ÷ Cursor)が 0.8〜1.25 に収まる
2. 機能の棚卸し	Orca の機能のうち、会社PCの条件で使えるものはいくつあり、そのうち Cursor に相当する手段がない「Orca 固有」のものはいくつか	Orca 固有で、かつ会社PCの条件で使える機能グループは2つ以下
3. 同じ Claude Code か	Cursor の拡張が起動する Claude Code と、Orca が起動する `claude` は、同じプログラム・同じ設定で、同じように起動しているか	違いは入出力の形式だけ

実験環境は、Windows 11 Home(論理 CPU 12個)、Orca 1.4.220、Cursor 3.23.12 + Claude Code 拡張 2.1.289、Claude Code CLI 2.1.290、Node v24.19.0 です。

計測に使ったのは筆者の PC 1台で、次の状態を「会社PCの条件」として扱いました。Codex のアカウントは Orca に登録されておらず(orca account list で0件)、GitHub CLI(gh)にもログインしていません(gh auth status の終了コードで確認)。git 自体は入っていますが、対象にしたこのブログのフォルダは git 管理していません。Android のエミュレータや WSL、SSH で接続する先も用意していません。なお、計測に使った Cursor は、Cursor のアカウント(無料プラン)にログインしていました(Orca の account list が返す利用状況で確認)。Cursor 自身の AI 機能の常駐分が、Cursor 側のメモリに含まれている可能性があります。

実験2では、Orca の各コマンドの説明(コマンド名・概要・必須の引数)を、事前に決めて保存したキーワードの規則で機械的に分類しました。

前提	キーワードの例
git が必要	`git`・`branch`・`checkout`・`commit`
外部サービス・他のマシンが必要	`github`・`linear`・`remote`・`ssh`
複数のエージェントが前提	`codex`・`orchestration`・`worker`・`dispatch`
追加のツール・OS が必要	`emulator`・`android`・`ios`・`wsl`

どのキーワードにも当たらないコマンドを「前提なし」とし、グループ内のコマンドの過半数が「前提なし」なら、そのグループを「会社PCの条件で使える」としました。Cursor に相当する手段があるかの判定は、分類の結果を見る前に書いて保存しました。根拠に使ったのは、Cursor の本体にあるコマンド ID、拡張の package.json、claude --help の出力の3つだけです。

実行手順と結果

すべて node run-experiment.js <段階> で再実行できます(npm の依存はありません)。前提は次のとおりです。

Windows で、Orca と Cursor が既定の場所(%LOCALAPPDATA%\Programs\ の下)に入っていること。
拡張にログイン済みで、claude が PATH にあること。
Orca が起動していて、対象のフォルダがワークスペースとして登録されていること。フォルダの場所は -blog <パス> で指定します(既定は筆者のパスです)。フォルダには CLAUDE.md が必要です。
Orca のターミナルで動く Claude Code の中から実行すること。実行している Claude Code 自身を計測から除く処理が、これを前提にしています。
cursor0 の前に Cursor を終了しておくこと。

実際に results.json を作ったときと同じ順番は次のとおりです。実験3の identity は、その時点で動いている claude.exe の起動引数も記録するので、Cursor のパネルを開いたまま、最後に実行します。

cd experiments\2026-10-06-cursor-extension-vs-orca-solo
node run-experiment.js inventory                     # 実験2(読み取り専用のコマンドだけを実行)
node run-experiment.js resident --step orca          # 実験1: Orca に計測用のターミナルを作って計測し、閉じる
node run-experiment.js resident --step cursor0       # 実験1: Cursor を起動して0体の状態を計測
# Cursor のコマンドパレットで「Claude Code: Open in New Tab」を実行
node run-experiment.js resident --step cursor1       # 実験1: 拡張のパネルで1体の状態を計測
node run-experiment.js identity --scan-transcripts   # 実験3(パネルを開いたまま実行。セッション記録の先頭を読むので、本人の了承を得て付ける)
node run-experiment.js env-extra                     # 実験3の補足(権限の設定、folder のワークスペース、gh のログイン状態だけを記録)
node run-experiment.js aggregate                     # results.json を作る

実験1 常駐コスト

各アプリの関連プロセスの Private Bytes(そのプロセスだけが使うメモリ)を、2秒間隔で31回取得し、中央値をとりました。関連プロセスは、アプリのインストール先にある実行ファイルから起動したプロセスと、その子孫すべてです。Orca については、ターミナルを動かす常駐プロセスとその子孫も含めました。一方で、この実験を実行していた Claude Code(Orca のターミナルで動いていた)とその子孫と、計測の前から Orca の中で動いていた別のエージェント2体(2体で 1048.3MB)は除きました。ただし、計測の前から開いていたターミナル4つ(うち3つでエージェントが動作)のシェルは含めています。

各状態1回ずつの計測です。単位は MB(1,048,576 バイト単位)、CPU はマシン全体に対する%です。

状態	アプリ本体	Orca の常駐プロセス	ターミナル	エージェント	合計	CPU
Orca・0体	1225.3	144.7	284.5	0	1654.5	0.339%
Orca・ターミナルで1体	1233.8	151.1	358.3	436.9	2180.0	0.406%
Cursor・0体	1872.2	—	0	0	1872.2	1.724%
Cursor・拡張のパネルで1体	2040.3	—	0	383.6	2423.9	0.471%

(各区分は区分ごとの中央値を丸めた値で、合計や増加量は丸める前の値から計算しています。そのため、表の値で計算した結果と 0.1MB ずれることがあります。)

1体待機時の合計の比(Orca ÷ Cursor)は 0.899、エージェント部分の比は 1.139 で、どちらも「ほぼ同じ」とみなす範囲(0.8〜1.25)に入りました。事前に決めた数え方では、仮説は支持されました。
ただし、数え方を変えると結果も変わります。上の合計には、計測の前から開いていたターミナル4つ分のシェル(Orca・0体のターミナル 284.5MB)が入っています。計測用のターミナル1つだけを数えると、比は 0.782 で範囲から外れ、Orca のほうが2割以上軽くなります。
副指標の Working Set(共有しているメモリも重ねて数える値)で同じ比をとると 0.697 で、Orca のほうが約3割少なくなります。Working Set は、OS が物理メモリから外した分を数えないなど、その時点のメモリの状況にも左右されるので、事前に Private Bytes を主な指標と決めていました。また、Cursor は Orca を起動したままの状態で計測しています。
1体を足したときの増え方は、Orca が +525.6MB、Cursor が +551.8MB でした。Cursor ではエージェント本体(383.6MB)に加えて、アプリ本体も +168.2MB 増えました。パネルを表示した分の可能性がありますが、Cursor の0体の計測は起動から約90秒後だったため、起動直後の処理が残っていた影響と切り分けられていません。
待機中の CPU は、どの状態もマシン全体の2%未満でした。ただし、Cursor の0体の状態(1.724%)は2%に近い値でした。

Orca と Cursor の4つの状態について、常駐メモリの内訳を示した横棒グラフ

実験2 機能の棚卸し

公開コマンド239件を24のグループに分け、Orca 自体を動かすための4グループ(起動、エージェント向けの案内、スキル、プロファイル)を除いた20グループを数えました。

	グループ数
会社PCの条件で使えないもの(git、外部サービス・他のマシン、複数のエージェント、追加のツール・OS のどれかが前提)	11
会社PCの条件で使えるもの	9
├ Cursor + Claude Code 拡張 + Claude Code CLI に相当する手段がある	3(フックの管理、Orca のメモリ使用量の確認、フォルダの登録)
├ 相当する手段がない(Orca 固有)	3(定期実行、内蔵ブラウザの自動操作、デスクトップアプリの操作)
└ 判定が分かれる	3(セッションの全文検索、ターミナルの操作、ワークスペースの管理)

「Orca 固有で、かつ会社PCの条件で使える機能グループは2つ以下」という仮説は支持されませんでした(3つありました)。
分類が実際の動きと合っているかを確かめるため、このブログのフォルダで、状態を変えない25件のコマンドを実行しました。24件(96%)が期待どおりでした。外れた1件は、オーケストレーションの一覧で、空を期待していたところに、Orca が自動で作った「旧形式の閲覧用」の項目が含まれていたものです。
この96%は、結果を見た後で判定式の誤りを直した値です(Codex のアカウントの有無を判定する式が、利用状況の欄の文字列に誤って反応していました。直す前は 23/25)。また、25件のうち4件は Orca 自体を動かすためのグループのコマンドで、分類の妥当性の確認にはなっていません(それを除くと 20/21)。確かめたのは一覧を返すコマンドが成功するかどうかが中心で、期待は計画のときに手で決めたものです。
セッションの全文検索は、設定で有効にするまで使えない状態でした(orca search --index-status が enabled: false)。
「相当する手段がある」としたフックの管理は、根拠が拡張のコマンド(markSessionUnread。セッションの状態をタブに表示する)だけで、仕組みも違うので、最も弱い判定です。

Orca の CLI の機能グループを会社PCの条件で仕分けたツリー図

実験3 同じ Claude Code か

項目	Cursor の拡張	Orca(実験で CLI から起動したもの)
実行ファイル	拡張に同梱された `claude.exe`(2.1.289)	PATH 上の `claude.exe`(2.1.290)
設定の置き場所	`~/.claude`(共通)	`~/.claude`(共通)
起動時の引数	`--output-format stream-json --verbose --input-format stream-json --max-thinking-tokens 31999 --permission-prompt-tool stdio --setting-sources=user,project,local --include-partial-messages --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages`	`--dangerously-skip-permissions`

版の違いはパッチ番号だけで、設定の置き場所も同じでした。~/.claude/projects/ のセッション記録43件のうち、拡張から起動したものが29件、CLI から起動したものが14件で、2つのプロジェクトでは両方が同じフォルダに並んでいました。このため、サブエージェントやスキルも同じものが読まれるはずです(推論で、直接は確かめていません)。
Orca は ~/.claude/settings.json の13種類のイベントに自分のフックを登録していました。同じ設定ファイルを読むので、このフックは Cursor の拡張から起動した Claude Code でも呼ばれるはずです。ただし、フックのファイルは Orca の環境変数を確かめる作りなので、Orca の外では何もしないと考えられます(どちらも推論です)。
「違いは入出力の形式だけ」という仮説は支持されませんでした。拡張は、入出力の形式に関わる3つの引数(-output-format・-input-format・-verbose)のほかに、9つの引数を足していました。その1つの -permission-prompt-tool stdio は、権限確認の送り先をパネルにするものです。Claude Code のユーザー設定では権限の既定のモード(permissions.defaultMode)が未設定(確認するモード)で、このブログのフォルダには、それを上書きするプロジェクト・ローカルの設定ファイルもありません。そのため、拡張では確認がパネルに出ると考えられます(確認の表示そのものは記録していません)。
実験で Orca の CLI から起動した Claude Code には、権限確認を省く -dangerously-skip-permissions が付いていました。計測後に Orca の中で動いていた claude.exe 3つのうち2つ(この実験を実行していた会話を含む)にも付いていて、1つには付いていませんでした。どう起動したかの記録はないので、「Orca がエージェントとして起動すると付き、ターミナルに手で claude と打つと付かない」というのは推測です。
この引数は、Orca の設定ファイル(%APPDATA%\orca\profiles\local-default\orca-data.json)の agentDefaultArgs に、Claude を起動するときの既定の引数として入っていました。同じ設定には30種類のエージェントの既定の引数が並んでいて、Codex には -dangerously-bypass-approvals-and-sandbox が入っていました。Orca の初期値なのか、以前に筆者が変えたのかは確認できていません。

Cursor の拡張と Orca が claude.exe を起動する流れと、共通の ~/.claude の比較図

自分の環境で起動の引数を確かめるには、Claude Code を起動した状態で次の PowerShell を実行します。

Get-CimInstance Win32_Process -Filter "Name = 'claude.exe'" | Select-Object ProcessId, CommandLine

結果から言えること・言えないこと

言えること

一人・1体なら、今回の各1回の計測では、合計のメモリはどの数え方でも Orca のほうが軽い結果でした。ただし、数え方と指標によって「ほぼ同じ」から「Orca が2〜3割軽い」までの幅があり、1〜2割の差は誤差と区別できません。エージェント部分だけを比べると Orca のほうが重く(比 1.139)、重さの大半はアプリ本体でした。エージェント1体はどちらでも 400MB 前後でした。
中で動いているのは同じ Claude Code(パッチ番号違い)で、設定と記録の置き場所も同じです。会社PCで「Cursor のときと同じ動きになった」のは、この結果と整合します。
違いが出たのは起動の仕方、特に権限確認の扱いでした。拡張は確認の送り先をパネルにする引数を付け、Orca の CLI から起動したものは確認を省く引数を付けていました。使い心地の差は、アプリの性能よりもこうした設定の差から来ている可能性があります。
一方で、Orca の強みが出るのは複数のエージェント・並列・git のときだけ、という当初の見立ては言い過ぎでした。事前に決めた判定では、一人でも使える Orca 固有の機能が3つありました。

言えないこと

実験1は各状態1回ずつの計測で、起動にかかる時間も測っていません。1〜2割の差は誤差と区別できません。「ほぼ同じ」になるのは事前に決めた数え方の場合で、計測用のターミナルだけを数えたり、Working Set で比べたりすると、Orca のほうが軽い側に外れます。
実験2は CLI のコマンドを「機能」の代わりに数えています。カードを並べて見る画面や Sleep のような、画面にしかない機能は数えていません。キーワードの規則と相当する手段の判定には、作った人の判断が入ります。たとえば定期実行は、Claude Code の /loop(セッションの中での繰り返し)と /schedule(クラウドで動く定期実行)を相当する手段と見れば「判定が分かれる」になります(claude --help に載っていないので、事前に決めた規則では根拠に数えませんでした)。その場合、固有は2つになりますが、「判定が分かれる」4つのうち1つでも「相当する手段がない」と見れば3つ以上になるので、仮説は支持とも不支持とも決められなくなります(判定保留)。
Orca 固有の3機能は、folder のワークスペースで実際に動かしてはいません。たとえば定期実行は、ワークスペースを指定しないと実行のたびに新しいワークスペースを作る作りで(CLI の説明による)、folder でどう動くかは確かめていません。
実験3は、ほぼ同じ版(パッチ番号違い)・同じ設定の置き場所であることを確かめただけで、モデルの応答が同じになるかは確かめていません。

5. 利点と課題

メリットとデメリット

一人・git なし・Claude だけの環境に限った比較です。

	Orca	Cursor + Claude Code 拡張
メモリ(1体待機時、Private Bytes)	2180.0MB(計測用のターミナルだけを数えると 1895.5MB)	2423.9MB
メモリ(参考、Working Set)	2266.5MB	3252.2MB
中の Claude Code	同じ(パッチ番号違い。設定の置き場所も同じ)	同じ(パッチ番号違い。設定の置き場所も同じ)
権限確認	CLI から起動したものは省いていた(Orca の設定の値)	確認の送り先がパネル
Orca 固有の機能	定期実行、内蔵ブラウザの自動操作、デスクトップアプリの操作(事前の判定で3つ)	なし(Cursor 自身の AI 機能は、Cursor のアカウントが前提なので数えていない)

技術の限界とその克服方法

会社PCで Orca の良さを引き出すには、条件を足す必要があります。作業フォルダを git 管理にすればワークスペースで作業場所を分けられ、GitHub を使えば Issue とワークスペースを紐づけられます。
固有の機能は、頼めば使える準備が整っていました。Orca のスキル(orca-cli・orchestration・computer-use)が ~/.claude/skills/ に入っていたので、Claude Code に「Orca の内蔵ブラウザで画面を確認して」と頼めば、Orca の CLI を使える状態でした(実際に頼んで試してはいません)。筆者の会社PCでの使い方(ターミナルで普段どおり頼むだけ)では、これらの機能を使う場面はありませんでした。
権限確認の扱いは自分で確かめておきます。Orca の設定ファイルの agentDefaultArgs で、エージェントを起動するときの既定の引数を確認し、会社のルールに合わせて変えておくと安心です。

6. 将来展望

今後の発展可能性

Claude Code 自身も、Orca と重なる機能を持ち始めています。今回使った Claude Code 2.1.290 の claude --help には、バックグラウンドでセッションを動かす --bg、その一覧・接続・出力の表示(agents・attach・logs)、セッションごとに git worktree を作る --worktree がありました。エージェント側が並列実行や作業場所の分離を持つほど、「エージェントを動かすための入れ物」としての Orca の差は小さくなっていくと考えられます。

他の技術との相互作用

その分、Orca の価値は、ほかの技術とつなぐ部分に移っていくはずです。

Claude・Codex など、複数の会社のエージェントを同じ画面で管理すること
GitHub・Linear の Issue と作業場所を結びつける作業の管理
内蔵ブラウザやデスクトップアプリの操作のような、エージェントの手の届く範囲を広げる機能

7. まとめ

要約と結論

一人・git なし・Claude だけの環境では、Orca と Cursor の拡張は、中身が同じ Claude Code で、メモリは Orca が同等か軽い程度でした。会社PCでの「悪くなったわけではないが、メリットも感じない」という印象は、実測の結果とも整合します。
違いが出たのは、権限確認の扱いなどの起動の設定でした。
Orca には一人でも使えそうな固有の機能(事前の判定で3つ。定期実行、内蔵ブラウザの自動操作、デスクトップアプリの操作)がありましたが、筆者の会社PCでの使い方では使う場面がありませんでした。

どちらを選ぶかの目安は次のとおりです。

当てはまるもの	おすすめ
複数のエージェント(Claude と Codex など)を使う	Orca
同時に複数の作業を走らせる(git 管理している)	Orca
GitHub・Linear の Issue と作業を結びつけたい	Orca
定期実行・ブラウザやアプリの自動操作をエージェントに任せたい	Orca
どれにも当てはまらず、コードを読み書きしながら Claude に頼みたい	Cursor + Claude Code 拡張で十分

会社PCでも、git 管理や GitHub を導入したタイミングで、Orca の良さを改めて試してみるつもりです。