📌 この記事の要約

• 作業ごとに Worktree を分けて並行作業
  Orca は、Codex や Claude Code などの AI エージェントを作業ごとに分けて動かせる環境。Git の Worktree を使い、依頼ごとに独立した作業場所を持てるため、複数の作業が混ざりにくい。

• Issue や PR のリンクが作業の入口に
  GitHub の Issue や PR から作業場所を作れるため、何のための作業かが最初から結びつき、着手の負担が軽くなる。

• Orca CLI で作業を横に増やせる
  元の作業から子の作業場所を作り、別の AI に担当させられる。互いの結果を待たずに進められる仕事で特に効果を発揮する。

• 外出先でも iPhone から作業を前に進められる
  iOS アプリから自宅 PC の Orca に接続し、進み具合の確認や AI への返答ができる。筆者は Tailscale で接続しているが、PC の電源と Orca の起動は必要。

• 筆者の運用は「1 Issue = 1 Window」
  macOS 上の Orca で、仕様の確定からコーディング、タスク管理まで Claude Opus 5.5 に任せている。結果はサイドバーの一覧と Mac の通知で確認する。

はじめに

AI に何かを頼み、返事を待つ間に別の用事を思い出す。もう一件頼みたいが、同じ画面で会話を重ねると、どの依頼がどこまで進んだか分かりにくくなる。私にとって、AI と作業する際の悩みは「どう頼むか」だけではなく、「複数の作業をどう置いておくか」になっていた。

そこで使っているのが Orca である。Orca は、Codex や Claude Code など複数の AI コーディングエージェントを、一つのアプリで並行して動かせる開発環境だ。Git の Worktree を使い、作業ごとにファイルや AI との会話を分けて管理できる。開発者向けの製品だが、私が気に入っているのは複雑な設定そのものではない。仕事の依頼を一件ずつ置き、必要なら別の場所でも同時に進め、外出中も状況を確認できる体験である。

この記事では、私が Orca を使って感じたことを、専門用語をなるべくほどきながら紹介する。取り上げるのは「作業を分けること」と「作業を広げること」の二つだ。後半では、私が実際に任せている作業や結果の確認方法、使用環境も実際の画面とあわせて紹介する。

1. AI との並行作業で困ったのは、依頼の管理だった

自分だけで作業するときは、一つを終えてから次へ移るほうが考えやすい。AI に作業を任せるようになると、流れが変わる。一件を頼んでいる間に、別の件の資料を見たり、次の依頼を考えたりできる。私には、複数の作業が同時に進む状態が自然になった。

たとえば記事を書く日なら、ある依頼では資料を確認してもらい、別の依頼では構成を相談する。開発中なら、一方で修正案を調べてもらい、もう一方で別の問題を確認してもらう。待ち時間をすべて自分の手作業で埋める必要はない。

ただ、同時に頼めることと、見失わずに管理できることは別だ。依頼を一つの画面に詰め込むと、前の作業の文脈を引きずる。後で戻ったときに「これは何のための会話だったか」と読み直す時間も増える。机の上に複数の書類を重ねたまま、別々の人に仕事を頼んでいる感覚に近い。

私が Orca で助かっているのは、この書類にそれぞれ専用の机を用意できるところだ。AI に並行して頼むことを前提に、作業を分けて眺められる。もちろん、どんな仕事でも同時に進めればよいわけではない。判断が互いに依存する仕事なら順番が必要だ。それでも、独立した用事を無理に一列へ並べなくてよくなった。

2. Orca の Worktree で、作業ごとに場所を分ける

Orca では、作業ごとに Worktree という作業場所を作れる。私にとって、その Worktree は「この件だけの作業机」である。記事制作と別の修正を分けておくと、戻ってきたときも何をしていたか思い出しやすい。

裏側では Git（ファイルの変更履歴を管理する仕組み）の Worktree（同じプロジェクトの作業用ファイルを、別の場所に用意する仕組み）を使う。Orca の公式資料によると、各 Worktree は、それぞれのファイル、ブランチ（変更を分けて管理する単位）、AI エージェントの操作画面を持つ。同じファイル群を一つの場所で使い回すより、別々の作業が混ざりにくい。

一つのプロジェクト
├─ 作業場所 A：記事を考える
│   └─ AI と相談・編集
└─ 作業場所 B：別の修正を調べる
    └─ 別の AI と相談・編集

私の感覚では、Window ごとに小さなサンドボックスを持つようなものだ。「この依頼では、ここにあるものを見て進めてほしい」と場所ごと渡せる。途中で別の作業に移っても、最初の作業を片付けてから画面を切り替える必要がない。

ただし、ここでいうサンドボックスは、作業ファイルを分けるという意味である。厳密な権限隔離や、秘密情報へのアクセス制限まで自動で保証する言葉ではない。AI に何を触らせるかは、普段どおり確認したい。私が価値を感じるのは、依頼単位で「今どこで何をしているか」が見えることだ。

この構造は、開発以外の作業にも通じる。たとえば複数の記事や調査を並行するとき、テーマごとに資料と会話を分けると、頭の切り替えが楽になる。Orca 自体は Git で管理したプロジェクトを扱う道具なので、誰でもすぐに普段のメモ帳と同じように使えるわけではない。それでも、作業ごとに場所を分ける発想は、私の日々の AI 利用を大きく変えた。

3. GitHub の Issue・PR から作業を始める

Orca でもう一つ良いと感じるのは、GitHub の Issue や PR のリンクを作業の入口にできることだ。Issue は「これをやりたい、直したい」という依頼票、PR は「こう変更したので確認してほしい」という変更確認票だと考えると分かりやすい。

私が新しい作業を始めるとき、対象のリンクから Window を立てられる。そうすると、何のための作業かが最初から結びつく。Orca の Worktree 資料にも、作業場所の作成時に GitHub の PR などを関連づける仕組みが案内されている。GitHub 連携の資料では、Issue や PR から作業場所を作る流れも説明されている。

これが地味に効く。AI に「この件を進めて」と頼む前に、どのフォルダを開くか、どの作業の続きかを探す時間が減るからだ。作業票、AI との会話、変更結果が同じ場所を向く。後から自分が戻ったときにも、入口のリンクが目印になる。

リンクを貼ればすべて自動で正しく進む、という話ではない。依頼内容が曖昧なら、AI への指示も曖昧になる。それでも、最初の一歩が「作業票を開く」になったことで、私には着手の負担が軽くなった。

4. Orca CLI で別の AI に独立した作業を任せる

一件を進めている途中で、「この確認は別に進められる」と気づくことがある。ここで便利なのが Orca CLI だ。CLI は、文字でコマンドを入力して Orca を操作する仕組みである。公式の CLI 資料には、そこから新しい Worktree を作り、AI を起動する方法が載っている。

たとえば、ある記事の制作中に、二つの公式資料をそれぞれ確認したいとする。確認項目を決めておけば、別々の Worktree で調査を進め、結果をそろえてから本文の構成を考えられる。AI エージェントから Orca CLI を使えば、元の作業に関連づけた子の Worktree を作り、別の AI に担当させる流れも組める。ただし、Worktree の親子の関連づけと、Git の分岐元は別の設定だ。

元の作業：記事を作る
├─ 子の作業場所：資料を確認
└─ 子の作業場所：構成を検討
         ↓
   結果を持ち寄る

一件の作業を進めながら、独立した確認を別の AI に任せられる。私はこの「横に広げられる」感覚が、とにかく良いと思っている。何を並行させるかは自分で判断してもよいし、AI に「分けられる作業があれば別の作業場所で進めて」と頼むこともできる。依頼を受けた AI が作業の段取りを考え、必要な場所を増やせる。

実際の開発でも、この使い方をしている。ある Issue の作業中、関連する二つの PR が、統合先のブランチとコンフリクト（変更の衝突）を起こしていた。そこで Issue の Window にいる Claude Code に「Orca の子でコンフリクトを直して」と頼んだ。すると PR ごとに子の Window が二つ立ち上がり、それぞれが解消を進めた。親の Window には、どの子がどの PR とブランチを担当しているかが表で示されるので、任せた作業の割り振りを後から確認しやすい（6 章の画面キャプチャ中央。キャプチャでは内容をマスクしている）。

ここで大事なのは、同じ Worktree の同じファイルを複数の AI が同時に書く話ではないことだ。分けた作業には、それぞれ別の Worktree を用意する。これにより、同じ作業用ファイルへの同時書き込みを避けやすくなる。ただし、最後に変更を統合するときには、調整が必要になることもある。最後に結果を持ち寄って確認する手間は残るが、その手間も「どの作業から来た結果か」が見えているぶん扱いやすい。

横に増やすほど必ず速くなるわけでもない。分ける準備と結果の確認に時間がかかる仕事なら、最初から一件ずつ進めたほうがよい。私がまず見るのは、「互いの結果を待たずに進められるか」である。そこが成り立つとき、Orca の並行作業は気持ちよく機能する。

5. iPhone から進捗を確認し、外出先でもAI に返答する

Orca の体験で、とくに気に入っているのがモバイルだ。Orca にはiOS 向けのモバイルアプリがあり、2026年9月時点ではベータ版として提供されている。自宅の PC で AI が作業している間、私は iPhone から状態を見たり、返答が必要なときに短く指示したりできる。

たとえば外出前に資料確認を頼んでおく。移動中に iPhone で進み具合を見る。AI が「この点はどちらを優先するか」と聞いていれば、そこで返事をする。帰宅するまで会話が止まり続ける必要はない。机の前にいる時間だけが、AI と仕事を進める時間ではなくなった。

私の環境では、PC と iPhone を Tailscale でつないでいる。Tailscale は、離れた端末同士を安全な経路でつなぐためのサービスだ。外出先から自宅の PC に接続できるようにしておくと、手元にあるのは iPhone だけでも、実際の作業は PC 上で続けられる。この「作業の本体は手元の PC にある」という感覚が、私は好きだ。

Orca が Tailscale を必須にしているわけではない。公式のモバイル資料では、Orca Relay を使ったペアリングや、同じネットワーク・Tailscale などを通じた接続が案内されている。いずれの場合も、接続先の Orca が稼働し、スマートフォンから到達できる状態が必要だ。接続方式によって設定は違うが、共通するのは PC 側の Orca に到達できること だ。PC の電源やアプリが止まれば、iPhone だけでローカルの作業を続行できるわけではない。

モバイルは、デスクトップの画面を小さくしただけでもない。進行状況を確認し、AI からの質問に答え、必要なら変更内容を見る。私が外で実際にしたい操作に寄っている。作業の続きを一からスマートフォンで組み立てるより、「止まっている一件を前に進める」ことに向いていると感じる。

オープンな製品で、iOS アプリまで用意し、既存の接続手段とも組み合わせられる。この作り込みは、使っていて強く印象に残った。ただし、ここで書いたのは私の運用であり、通信環境や端末構成によって使い心地は変わる。

6. 筆者の実際の使い方：任せた作業・待ち時間・結果の確認

ここからは、私が普段の開発で Orca をどう使っているかを具体的に紹介する。

使用環境

Orca は更新頻度がかなり高い。この記事の画面や挙動は、執筆時点のものとして読んでほしい。

実際に AI へ任せた作業と、その分け方

私は仕様の確定、コーディング、タスク管理のすべてを Claude Opus 5.5（Medium エフォート）に任せている。モデルを作業の種類で使い分けることはしていない。

作業の分け方も単純だ。タスクは基本的にすべて GitHub の Issue で管理し、Issue ごとに Orca 内でエージェントを立ち上げる。つまり「1 Issue = 1 Window」である。作業の単位は Issue の時点で決まっているので、Orca の中であらためて分け方を考えることはほとんどない。4 章で紹介した子の Window は、作業中にコンフリクト解消のような独立した用事が出てきたときに使う。

待ち時間に進めていること

AI が作業している間、私は次のようなことをしている。

• 他のメンバーの Pull Request のレビュー
• 新機能の仕様の確定
• ローカルで使っている自作ツールの新機能開発

そして、コーヒーなどを飲んだり、目を閉じて休憩したり、同僚と雑談したりもする。AI に任せた時間を、すべて別の作業で埋める必要はない。手を止めて頭を休める時間にできるのも、並行作業の良さだと感じている。

結果の確認方法

結果の確認は、主に二つの方法で行う。

一つは左のサイドバーだ。各 Window の作業状況と最新の結果が一覧で並ぶので、どの Issue が終わり、どれが動いているかをひと目で確認できる。もう一つは Mac の通知である。作業が終わったり、AI が返答を求めたりすると通知が届くので、それを合図に該当の Window を開く。

使い心地は、Herdr や tmux のようにターミナルを並べて作業するスタイルに近い。それをアプリの画面で直感的に扱える。

筆者の Orca の作業画面（2026年9月30日時点、一部情報をマスク）。左：Issue ごとの Window 一覧と結果のサマリー。中央：Claude Code（Opus 5.5、Medium エフォート）の作業画面。この画面では、子の Window を二つ立ち上げて PR のコンフリクト解消を任せている。右：Window 専用のブラウザで、該当の Pull Request を確認している。

なお、画面下部の「bypass permissions on」は、Claude Code がファイル編集やコマンド実行のたびに許可を求める確認を省略するモードである。筆者は、作業内容を把握している自分のリポジトリに限って使っている。初めて試す場合は、通常の確認ありのモードから始めることをおすすめする。

画面右側のブラウザも、私が気に入っている機能だ。Orca では Window ごとに専用のブラウザを開ける。AI が作業した Window の中で、そのまま PR の差分や GitHub 上の状態を確認できる。依頼、作業、確認が一つの Window の中で完結するわけだ。

7. Orca を試す前の準備と、最初の一件

Orca を使い始めるなら、まず Orca 本体と、利用する AI エージェントの設定や認証を済ませておく。そのうえで、最初から何件も同時に走らせず、一件の作業から試すと分かりやすい。まず「この記事の資料を調べる」「この修正の原因を探す」のように、一件だけ選ぶ。その作業のために Window を作り、AI に頼む。結果を見てから、別の一件を増やす。私はこの順番が分かりやすいと思う。

Orca は Git で管理したプロジェクトを中心に設計されているため、準備なしで日常のあらゆる作業を扱えるわけではない。非エンジニアが使う場合は、まず Git と Worktree の基本を理解しておくと、作業場所の作成や結果の確認を進めやすい。それでも、操作の目的は単純だ。「依頼を一件ずつ分け、終わったら結果を確認する」。そこから始めれば、専門用語の暗記が先に来る必要はない。

おわりに

私が Orca を気に入っているのは、AI が何倍も速く働くと約束してくれるからではない。複数の依頼にそれぞれ居場所があり、今どれが動いているかを見渡せるからだ。必要なら Orca CLI で独立した作業を増やせる。机を離れたあとも、iPhone から状況を見て、止まっている会話を進められる。

使っていて思うのは、Orca は「部下が作業している様子」をそのままインターフェースにして、AI と人間をつないでくれる OSS だということだ。米マイクロソフトの牛尾剛さんも、著書『部下としてのAI 世界一流エンジニアの進化術』（文藝春秋）などで AI との働き方を語っている。AI は自律的に動くが、仕事のきっかけを作るのはやはり人であり、人間はその成果に責任を持たなければならない。私はこの考えに強く共感している。

ソフトウェアエンジニアとして見ると、Orca は「Issue から依頼する → AI が作業する → 同じ Window の専用ブラウザで人が確認する」というライフサイクルを自然に作ってくれる。だから扱いやすく、AI を使った開発を前に進めてくれる良いツールだと思っている。

AI と並行して作業するなら、まず一件ずつ置き場所を作る。これが、私にとって Orca から得た一番大きな Tips である。

【著者プロフィール】 小田 和弥 / GMO天秤AI株式会社 おだ かずや 筆者

GMO天秤AI フルスタックエンジニア。GMO天秤AIの新規機能開発から、AWS インフラの IaC 化まで一貫して担当。 AIエージェントを 50 体近く同時並行で動かしながら、開発・レビュー・テストで堅牢で信頼性を担保したソフトウェアを作ることが得意。 直近 4 か月で 13 リポジトリ・約 1,300 コミット。RAG／ファイル取り込みの設計開発、CI/CD 基盤の開発など、様々な側面にて開発を行う。